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.
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?
@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
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:
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.
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!
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.
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.
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!
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:
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.
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.
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.