Porting NuttX to Spark Core

Up until @acassis’s post I didn’t know what NuttX was -_- Now that I do, this sounds like an awexome project.

BTW, you can program the Spark Core with a JTAG programmer directly in a super fast amount of time, maybe 1 - 4 seconds, depending on the size of the application. I’m sure USB will be an option as well, you don’t necessarily have to program it over Wifi.

Of course I am glad to submit patches for NuttX. Will try then.
Looking forward to your work here, can’t wait to enjoy the Spark Core with this RTOS.

Hi @BDub, I’m glad to bring NuttX to you knowledge.
I think the best way to program Spark Core initially will be JTAG for sure.

Currently I’m using OpenOCD in other projects (see in my blog: http://acassis.wordpress.com), then I suppose it will not be an issue. I suppose you also already uses OpenOCD right?

1 Like

@acassis I’m not at the firmware debugging state with Spark Core yet, but I have a STLINK/V2 and have been using their Windows utility to do some initial programming via JTAG. I’m currently installing Ubuntu 12.04 on a spare laptop to get DFU-UTIL working. I’m sure it won’t be long before I give OpenOCD a spin :wink:

Ok I am interested in jumping on the wagon. I used Nuttx on one of my last projects and would love! to use it again. Let me know where and how I can help.

I have asked Greg for a home the the SparkCore in the tree:

http://groups.yahoo.com/neo/groups/nuttx/conversations/topics/4346

Hi David,
welcome aboard. I think all pieces are put on the table: librae ported NuttX for a STM32F103C8 board (maple board from leaflabs) and I integrated CC3000 driver on NuttX. Now we just need the SparkCore to tie these pieces.

There still much work to fix some CC3000 BUGs, but I didn’t test using a new CC3000 firmware from TI, maybe some these BUGs were fixed.

I’m looking forward to get a SparkCore to test NuttX on it.

1 Like

Hi Alan,

Sorry I did not make the connection to “Alan” at the nuttx discussion at yahoo. Please forgive me for that.

Thank you for the CC3000 contribution to the nuttx tree!

I just ordered CC3000BOOST from the ti store and a maple mini from http://www.aliexpress.com/snapshot/273786734.html

I plan to mod the mini to the sparkCore V1. I guess it is a race if my SparkCore shows up before the maple does.

Hi David,
don’t worry about it.

Your idea to connect Maple Mini pins to CC3000BOOST is very clever, this way when Spark Core arrive (if it arrive later) then you will have already NuttX working on it.

I hope SparkCore arrive soon, it will be nice get the power of NuttX on it!

Hi Alan,

Have you asked to be a beta tester or for some early hardware? May be we should…

Hi David,
No, I didn’t :frowning: and I don’t know if it is too late.

Maybe @zach could tell me if there is space for a beta tester, but more focused on NuttX port.

Sorry guys, would love to help, but we don’t have any extra Cores to share!

No problem @zach! I suppose there is not more boards for beta tester.

I hope my SparkCore arrive soon to let me test it. []'s Alan

Hi Alan,

I have created a big board sparkBB, that takes a maple mini, and a CC3000BOOST and breaks out the Tx, Rx to connect to a FTDI TTL-232RG-VREG3V3-WE for the console and wires in the LEDs, serial flash and a Jlink compatible Jtag… I just sent it out for fab and the parts are on order. I am working on the spark tree that Greg placed in nuttx.

David

1 Like

Hi David,
Did receive your maple and cc3000 module?
Your idea is very good this way you don’t need to use wires to connect these boards. I have to wait SparkCore to arrive. Please let me know about your progress as you get things working and count on me case you need help.

Hi Alan,

I have had some success. I layed out the big board to avoid “breadboard” wiring issue. But the circuit boards just shipped and my impatience got the best of me. As you can see http://nscdg.com/spark/sparknotbb.jpg

I have submitted patches to Greg, that support the CC3000 as a device and I am able to telnet into my spark proto…

The code still need a lot of work, but for the most part is is working!

Alha,

David

1 Like

Hi David,

Very nice, congratulations!

Now I need to update the CC3000 driver to work with Freescale Freedom board because these modification stopped it to work :slight_smile:

Are you using default NuttX telnet application?

BR,

Alan

Sorry about breaking it. Yes almost stock. The only difference is pulling it in from the cc3000 app folder and it uses the #include nuttx/wireless/cc3000/include/sys/socket.h, Which we should be able to pull in using the
-isystem setting in the Make.defs that Greg was talking about here:

http://groups.yahoo.com/neo/groups/nuttx/conversations/messages/4595

I still have more cleanup to do. One thing that did come up and I am wondering why it has not come up with the spark team is: The limited RAM and the choice of the MicrochipTech_SST25VF016B-75 serial flash. It has a HW sector size of 4K and for requires a buffer of that size to do any write operations. On a 20K ram device that is a lot.

David

Hi David,

Don’t worry, “you’ve got to crack a few eggs to make an omelette”, I’m glad you for your great work integrating CC3000 in the NuttX on the right way.

Unfortunately the decision to use a 4KB sector size for serial flash is done, then maybe in the next hardware revision we could suggest @zach to use a serial flash with 512 bytes sector instead and/or a microcontroller with more RAM.

Currently I’m using Kinetis KL25Z128 microcontroller in my projects (16KB), but now I’m planning to move to a better model because I could face memory limitations. Now I think “32KB should be enough for anybody” (citing Bill Gates here. s/32/640/).

Just to throw some light here:
That 4KB sector size is for Sector-Erase on the Serial Flash and not for write operation so we don’t need a buffer of 4KB to do any write operation. The SST Serial Flash selected for the Spark board supports both Byte-Program and Auto Address Increment Word-Program. So for writing bytes to a selected page, send a sector-erase command to erase the 4KB page and then do a byte/word write sequentially. Refer to the datasheet - “Table 5: Device Operation Instructions” for the complete list of commands. Hope this helps.

2 Likes

It is true that if you simply write to the device, you don’t need to buffer sectors in memory. But file systems typically do “read-modify-write operations”. In that case, you do still need a 4K buffer. Suppose I want to change 5 bytes in the center of a 4KB sector, perserving the other 4091 bytes. I would have to (1) read the full sector into memory, (2) modify the 5 bytes in the memory copy, (3) erase the 4KB sector in FLASH, then (4) write the entire 4KB sector back to FLASH. Pretty expensive! But that is what file systems need to do all of the time.

Of course, for performance reasons you would not want to write the 4KB data back to FLASH on each tiny, byte read-modify-write. So file systems will keep at least one sector buffer in memory for each open file. Maybe another sector buffer for other non-file FLASH accesses (like the MBR or FAT). So typical use of something like a FAT file system could easily require more buffering than is available on that part. Which is a very sad limitation.

The only solutions are: (1) Don’t use a standard file system, (2) Replace the MCU with one that has more memory, or (3) Replace that FLASH with one that has smaller erase units (pages?).

The first option is good for some applications, but not for others. Of the remaining two, the last option seems the more reasonable.