I'd be 99% certain it would be fine. I think what you are really testing is the code that breaks up the two chips based on address... and that looks good. That said, I can add another Spider to my breadboard and try it tonight. It would be interesting to see how long it takes to store and retrieve data, and it would also be interesting to see how we could allocate memory for buffers at runtime using these FRAM chips. That's probably more work than I can offer at this point though. You should see my list of things to do... I made some progress on the NFC shield library and testing so I need to get back to that.
With this working, i would like to try making a library from scratch. Have never attempted this but is definitely on my TO-TRY list and the FRAM has limited functions which makes it easy for me to learn!
Will update you guys when i have completed the library and would need to trouble you guys to help scrutinize it.
I’m thinking of some #define so that users can easily set the 2 x FRAM memory size
*launching Eaglecad and starts re-routing the board :D*
My favorite thing about this thread is the time difference between us. There's always lots of progress posted here when I check in the morning and early afternoon.
Take this with a grain of salt… your non-45 degree tracks drive my OCD nuts I’m sure it will work even if it was squiggly though. Just a standard way of doing things, for me.
I think your two solder jumpers look different. Might be good to put them on the same side with a nice silkscreen label J1 & J2 (jumper) or S1 & S2 (strap). I like Sparkfun’s solder jumpers:
Hahaha! Sadly I have OCD as well and I was just too tired to clean it up last night
I spent more time making it neat than testing most of the time. Lol.
Do you know what’s the pad they use? Or I can download their board schematic and take a look
Thanks for the input on this! Gonna look pretty with the solder mask and all
I would love the jumpers on the same side but this might end up with more vias as some traces are on the bottom. I’ll take a closer look later
UPDATE
I’m toying with the idea of just leaving the HOLD and WP tied to high and not changeable by the user. Well i can do so but there’s so many vias that’s gonna be added for that. Thoughts?
Let me justify my decision.
For WP pin:
control writing to a status register
I haven’t thought of a scenario where you want to use a pin to disable the status register due to software not being able to handle it.
For HOLD pin:
This pin is used to interrupt serial input/output without making chips deselect. SO becomes High-Z, SCK and SI become don’t care.
Basically, using the CS pin, you will also be able to achieve the same effect on the FRAM. CS says: SO becomes High-Z. Other inputs from pins are ignored for this time.
Also, for HOLD to work, CS must be held LOW for it to work.
That’s another prerequisite and we will be better off controlling whether the FRAM is selected using their respective CS pin!
Yup, default uses SPI_CLOCK_DIV4. The latest pull request I made to BDub for the microSD library allows for full speed (DIV4) and half speed (DIV8). In your code, after the call to SD.init() or card.init(), add this line to change the SPI clock:
SPI.setClockDivider(SPI_CLOCK_DIV16);
You can try DIV8, DIV16 or DIV32. If none of those work, then there is a different problem.
I am curious about how everyone uses the headers on the Spark. Does everyone just use the male headers supplied with the board or does anyone use female headers with the long pins like an Arduino so that you can stack other boards or jumper wires on top?
Since the Spark has an antenna, and ships with male headers, it’s mostly been the “top dog” in the shield stack up so far. I think if you did it the other way around it wouldn’t be as useful in the breadboard, and you might cover the antenna too much. I usually just plug it in a breadboard and then I have two connection points per pin to work with… even a mini breadboard works well.