-
• #2
Yes, it should be totally fine. Software SPI is used for FS on a few platforms and works fine on those.
If the MOSI pin isn't changing, and is sometimes, are you sure you haven't just wired it to the wrong pin on the SD card?
Also, using D11 for CS is a bit scary, because that's shared with the button on the Thingy?
-
• #3
Also, using D11 for CS is a bit scary, because that's shared with the button on the Thingy?
Yes it is. I just unsoldered the button to avoid conflicts.
are you sure you haven't just wired it to the wrong pin on the SD card?
I am. In addition, I tried to remove the SD card just to be 100% sure there isn't any electrical conflict.
driving the SPI directly from prompt (
ThingySpi.write(0xAA)
) gives the exact waveform on the MOSI pin. CallingE.connectSDCard(ThingySpi, CS)
,E.unmountSD();
,fs.appendFile(File,data)
or evenE.openFile(File)
has no action on MOSI pin.MOSI=D4;//P0.04 MISO=D3;//P0.03 SCK=D2;//P0.02 CS=D11;//P0.11 var ThingySpi = new SPI(); var csvLogFile="logFile.csv"; function Init() { // Wire up up MOSI, MISO, SCK and CS pins (along with 3.3v and GND) ThingySpi.setup({mosi:MOSI, miso:MISO, sck:SCK}); E.connectSDCard(ThingySpi, CS); } function csvLogSD(s) { try{ if(fs.appendFile(csvLogFile,s)==true) console.log("log saved"); }catch(err){ console.log("error writing to SD.. trying unmount+remount"); E.unmountSD(); E.connectSDCard(ThingySpi, CS); } }
-
• #4
You could try compiling with the THINGY52 target just in case there's some pin conflict from something else?
I wouldn't expect
connectSDCard
orunmountSD
to clock any data out of SPI at all, but obviouslyfs.appendFile
should. My goto command for testing the SD card is alwaysfs.readdirSync
-
• #5
I was not aware that the Thingy52 was supported!! Thanks Gordon, I'm going to try compiling this target and post the results here.
-
• #6
Unfortunately I have the exact same behaviour than previously, I'm afraid this is not a pin conflict.
How can I verify that the
fs
is using the correct SPI ? -
• #7
Assuming the SCK pin is going up and down you could be pretty sure it's the correct software SPI I'd have thought.
-
• #8
Is that possible that pin P0.11 (
D11
) has inverted polarity regarding the state set bydigitalWrite
?I reverted to the generic
nrf52dk
build and retried. This time I got something on MOSI.... I really don't know what happened. Nothing changed since my first tests except, I flashed theTHINGY52
binary then flashed once again theNRF52DK
binary...
Anyway now the SDcard is accessible from Espruino!I really dislike when problems resolve by themselves... this is very frustating...
1 Attachment
-
• #9
Ahh, yes that's it - so if you used the Thingy build with different pins then it should be fine.
Pins V0..V3 work transparently via the IO expander and might be fine for CS. Also the 4 MOS transistor pins might be possible to hook up if you can get to the opposite side of them.
Hi,
I am trying to use a FS on SD Card with a NRF52. I compiled the image for the
nrf52dk
target , taking care to add thefilesystem
feature to it. this works (I have access to functionE.connectSDCard()
).I am using software SPI (
var ThingySpi=new SPI();
):MOSI=D4
MISO=D3
SCK=D2
CS=D11
This doesn't work. CS pin correctly goes down when a communication occurs, SCK line sends multiple pulses (8 at a time) but nothing goes out of MOSI. By calling getPinMode it tells me that the pin is "output", that seems to be correct for a software SPI.
By calling
digitalWrite()
I can correctly put it high or low. edges are very clean (verified with a scope).Then I tried to call
ThingySpi.write(0xFF)
and this time, the data correctly went out of MOSI.My question is then: Can the SD/FS module run on top of software SPI?
ps: The same setup on another board (by example my STM32F4DISCOVERY with a custom build with added
filesystem
feature) works perfectly.