So I would love to have some feedback/input before moving into the actual design of the board itself!
Would you like to be seeing the MicroSD card underneath the Core?
So it’s like there will be a Female header on the top to plug the core in and male leads on the bottom to plug it back to the bread board
Or a breakout in some form where you can jump wires to the core just like other breakout boards?
I’m thinking this is not so ideal if you want to start off immediately after buying one cos you still need to jump wires.
A kind where you directly plug it to the left side of the core (Analog pins side) and it all the wiring done for you on the PCB itself
Just a raw PCB but thinner than the norm of 1.6mm and the holes are slightly smaller than the male leads.
What you do is you will attach it to the core with a little force before attaching back to the breadboard. That way, we minimize the space used compared to adding headers…
Other suggestions?
I’m going to leave the level shifter (4050) out since the core is already running off 3.3v.
There’s no point in this shield if the level shifter is included since there’s already microSD shields with level shifters existing
My vote is for option 1. Sammiching the microSD between the core and the breadboard (without much force) is an awesome way to go. I assume you insert the microSD underneath the core USB connector?
I never feel good forcing any sort of connection. Too much stress over time could break something.
I was thinking under the USB connector since I have my cores oriented on the breadboard so that the USB connector sticks out the side and gives me more prototyping room on the board.
Cool. I would put the microSD holder on the top side of the PCB to make it easier to insert and remove when it’s all on the breadboard. There should still be a ton of clearance above it.
That R1 looks to be a little bit in the way of the card… maybe move R1 over by R2 and just put D1 in the corner.
There’s another thread where we’ve talked about adding an 8 pin memory device as well, probably FRAM based… but there might be enough room to put a couple different versions on there SRAM, FRAM etc… and just not populate any of them for the low cost version of this board. It would be a waste not to include them, attached to the SPI bus.
@RWB, the only ones i found on TI is a MSP430 with FRAM inside. Maybe that’s not what we are looking for?
Did a search of fram on Digikey and i got:
Filtering down the search results to SPI + 8SOIC gives me around 62 results
Only 2 chip in specific for 2Mbit, SPI, 8 SOIC and good availability
Only 1 chip in specific for 1Mbit, SPI, 8 SOIC and good availability
Only 1 chip in specific for 512Kbit, SPI, 8 SOIC and good availability
Only 2 chip in specific for 256Kbit, SPI, 8 SOIC and good availability
etc…
Seems like the choice are not too many and SOIC gives more option and slightly lower price for the same thing compared to an SOP.
Definitely won’t mind adding the footprint for users to add on their own fram but we might need to see which package is most popular for all to solder easily at home
Wow, I still got that messed up after kind of thinking about it... I should have looked at the mirror reference designators harder. I use Cadence OrCAD more than Eagle, and their default top is blue and bottom is red
I would connect it by default because the only thing someone might use is this shield. IF they have to use another device on the SPI bus, it will need it's own CS/SS pin connection anyway. Also the CS/SS pin is controlled separately by the user's implemented library, not by the SPI class (even thought the SPI Class initializes the SS pin). I can see some issues with using multiple libraries that assume they are going to be the only one's on the bus. Some work will need to be done by the user for those to work, but they will still need your shield to have some connections. If you wanted to add some zero ohm resistor jumpers that might not be a bad idea, or even a resistor footprint with a skinny 8 mil trace between the pads shorting it out that would allow a user an easy way to cut, and reconnect. Many ways to do this. The FRAM is going to need a separate CS connection apart from the A2 pin. I would suggest D2.
Go big or go home! Keep it to a package that people can easily solder themselves to upgrade and add more memory if they need it. Maybe the shield doesn’t even have any soldered on by default to save cost.
Exactly WHICH FRAM is debatable. And it MIGHT be necessary to connect the HOLD pins… in case of CC3000 interrupts and stuff. Honestly it could get quite messy with the code at that point though… since it wouldn’t be something a standard library is going to be able to add. You’d need to make the CC3000’s ISR set the HOLD pin low… and also I’m not sure how that would work with the SPI class. I’m guessing that’s what the HOLD pin is for anyway. The other option is to disable interrupts while reading/writing memory. Is this automatically already handled in the SPI class?
We are gonna need more inputs from the firnware guys
Hmm… how many would be good? I’m thinking anything bigger would fit the microSD better!
Maybe like 2-3 of the SOIC should fit comfortably in the free space left.
@BDub i’m looking at a few posts with people interfacing FRAM --> Arduino and tying the HOLD and WP pins to High, effective not using the pins for control
Well, just a guide but we can get it exposed if required but not explicitly tied to any pins but with pads to do so if required!
Seems like the FRAM 8 SOIC has standardized pin-out across the 3 Main manufacturers.
The pinout is the same for the External flash as well. Seems like having this footprint on the board might be really useful for everyone! You can add an FRAM or even another External Flash similar to that used in the core.
Only difference is in the Width of the SOIC of 2 kinds.
Thanks for the inputs so far! Much more fun and easier to get things running with the community
Yeah with no explanation as to why they chose that path. I'm guessing just because they didn't want to deal with it. Plus arduino doesn't have any background tasks... well if you define some interrupts it technically would. So I'm guessing they just didn't want to deal with it. It's funny I went and looked for a while and I'm not finding any app notes on how and why to use the HOLD input.
Maybe someone can chime in on how interrupts affect the SPI data transfer, if at all.
The SPI hold pin is used when you have multiple devices on an SPI bus and you need to arbitrate access amongst them. It puts the IC that has hold pulled low in a state so that it ignores the SPI clock and data input and forces the output to high-Z and pauses the current transaction. When hold is brought high again, the current operation resumes where it left off.
There are a bunch of ways to use it, but one simple way is that the CS for the IC on the SPI with high-priority or the one that is interrupt driven is connected to the other IC’s hold inputs, so that when the the priority IC is chip selected, the other ICs are in hold. When the high-priority/interrupt-driven IC is done and its CS goes high, the other ICs come out of hold.
Yeah I caught that in a couple datasheets that it basically does what it says, puts the current READ/WRITE operation on HOLD… but WHY? What’s the practical application? No mention of this.
I2C has something commonly known as Clock Stretching where you can basically stop clocking the device and put it on HOLD essentially as well. Great for when you get a high priority interrupt. I just don’t know enough about how the SPI hardware is done on the Spark to intelligently say it pauses or keeps clocking if a high priority interrupt comes along. Based on that answer, we’ll know what to do with the HOLD input
Core?
core pins.
