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
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
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 
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.
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.
Given that we’re working in a constrained, low-cost environment, I expect that not using a filesystem would be the norm. This ain’t no linux system 
Yes there is USB access to the external flash. We haven’t written the abstraction layer for writing to Flash yet, but we’ll be basing it off of Arduino’s EEPROM.h, at least to start, since that’s a syntax that folks familiar with Arduino would be comfortable with.
The port to nuttx is complete.
You should be able to run telnet to it, read/write files on it’s flash and from the PC and used the usb serial port.
Memory is really tight! you will need to add -Os to the Make.defs if you turn on Debugging.
Please let me if you have any issues.
David
Hi David,
Excelent work, you did it very fast, congratulations again!
I’m looking forward to get my SparkCore to test it.
NuttX on SparkCore will open door to much more applications, it will be a nice platform for IoT and Hard Real Time Applications.
BR,
Alan
Sorry to revive an old conversation, but just wanted to mention that you can do this without a 4K buffer if you use a logical->physical page mapping on the flash.
This is the scheme I use in my flashee library to change bytes in a sector while leaving the others intact:
As well as avoiding the use of large buffers, this spreads the wear over all unused sectors. Of course the downside is performance since you always write a 4KB page for any change, but that’s the price to pay when working within the constraints of the flash device.
(The library also provides a storage scheme that allows updates to be done virtually inplace, requiring only only 2 bytes to be written for each byte change.)
cool! I like it. Do you think it will work with a FAT file system?
Yes!! I incorporated the fsFAT library into flashee, and made a demo app - https://community.spark.io/t/flashee-eeprom-library-eeprom-storage-in-external-flash/5241/5
FAT support worked for the demo, but of course I imagine we’d need to do some more rigorous testing. I recently fixed a fairly significant bug in flashee where the data was corrupted after a power cycle. (It was a one-liner - some missing metadata, but I write a suite of tests to first show the presence of the bug and then validate the fix.)
