So it kept thinking all day and night about WHAT IF the user (rather me during testing :p) placed the shield in the reverse direction?!
It seriously bothers me so…
Looking at the visual analysis, it seems like the uSD/FRAM shield will be safe from any damage if you reverse the placement
Also, if you are a shield designer, this might be helpful:
The pins highlighted in RED are HOT which means if there’s a circuit connected to it, there’s a chance of current flowing through. So just do a check and see what’s the connection like.
I hope you like the effort put in for this shield!
Hows your library coming along? I’ve just started trying to modify my code to use the FRAM for the database of fingerprints and the SD for the log file… problem is my code has grown to over 2500 lines not including the 7 libraries and i cant remember what does what!
@kennethlimcp, sorry about the delays. Lots of family stuff and as you know, happy wife, happy life!
I will be posting the SharpMem/FRAM libray as well as some other FRAM libraries I tested. Oddly, though I could get the SharpMem stuff working with the FRAM, I had problems with the other libraries which worked just fine on an Adafruit 64K FRAM breakout. My guess is that I’m missing something simple. I should have stuff up on my github later today.
@kennethlimcp, I have finally posted the SharpMem/FRAM display library here. The code is setup for a 400x200 display but that can be changed easily. I have tested it on a 128x128 display as well.
Ok so trying to update my fingerprint reader to use this shield… I noticed something that may cause me an issue.
im planning on using @BDub code from above (post# 136) but if i set the SPI up and call SPI.begin and don’t specify a pin it defaults to A2. the way i got around this previously (as its in a few libraries this way) was to make sure nothing was connected to A2, so i put the digole on A0 and the SD on A1. my thoughts are if we are spitting out random stuff to the SD card we will corrupt it pretty quickly, if not brick the card by writing to the bits you shouldn’t, i dont know if it happens or not, but i don’t want to risk it!
Now the dilemma, the SD card is hardwired to A2…
whats the best way to go about this? can we map CS to a no-broken out pin so we dont loose a ‘spark’ pin? or is there a way to create instances so we can have SPI_Digole that is for the digole and is a mode 3 whatever and on A0, and a SPI_SD thats mode 0 at clk/4 on A2 and a SPI_FRAM thats set mode 0 clk/4 on D3
also,
has anyone converted the test code into a library for this shield? i think its pretty much all there, Im going to make a start on it now… but be warned… I’m still learning so it wont be perfect!
If you call SPI.begin(D2); for example, it should set D2 as the SS output pin and set it HIGH. The Core's SPI library should not takeover A2 as a digital output anymore and you should be able to use it as an analog input.
That said, your user library that requires a SS pin needs to be aware of the new D2 output and set it LOW whenever you are talking on the bus, and back HIGH after you're done.
@kennethlimcp this is sweet! Nice to see this kind of progress on a community driven shield. How much was the stencil and what was the turnaround? It would be cool to get the tooling for this cheap enough for home based small batch assembly runs. That looks like the same panelization as the Spark Core, so if made at Spark’s CM they probably have the tooling ready to go… which is nice.
Yep thats what i figured, what about for the likes of @timb digole library, it manually controls the CS pin defined and calls SPI.begin(); defaulting to A2…
Is there a pin we can map to thats not broken out? that way we dont waste another pin?
Im running out of time before i leave for Italy, @kennethlimcp ill PM you the library i have so far, its based on the arduino EEPROM library with @BDub 's functions from the test code above… ill give it a very quick test in the WebIDE then its all yours!
I'm not seeing the problem I guess... if you just map your code/library to use the A2 pin for CS/SS then you have not wasted two pins for this function no matter if you call SPI.begin() or SPI.begin(A2)
If you use any other pin and don't specifically call SPI.begin(ANY_OTHER_PIN); then you are now initializing A2 as a digital output and setting it high when you call SPI.begin(). That said, you can still call analogRead(A2); thereafter and it will reinitialize A2 as an analog input. Beware if doing this, that any analog circuitry you have hooked up to A2 is going to be subjected to a HIGH output for a brief period of time (this could be fatal, which is why I added the ability to call SPI.begin(ANY_PIN) to the core-firmware )
the problem as i see it, its probably me thats wrong…
If i call SPI.begin for the digole display it will set A2 as CS, even though i want to use A0
then for the SD card, i want to use A2
and the FRAM uses D2 and D3
and i need to pick one for the RFID reader too
timb’s library calls SPI.begin(); so SPI is now set for A2, even though i set CS as A0.
A2 will be driven low each time the library calls SPI.transfer to write to the display. even though we are manually doing the CS low on A0
same goes for writing to the FRAM and RFID…
so if A2 is going low, then we are writing to both the display and the SD card… see what i mean
@Hootie81, @kennethlimcp, I wrote a lot of the Digole library with timb. He gave me editing privileges so I modified the code in the repo to use SPI.begin(_SS) where _SS is passed in the constructor.
I was going to say the problem is just that the library needs to be updated to be more dynamic now that the Spark core firmware allows it to be. And it looks like @peekay123 has your back on this one Thanks PK!
)