I tried to read through the SD-library and the underlying libraries trying to find that line of code that shows
apparently it seems that switching the Chip-select-pin is done by another command.
I'm asking this because user aattig has problems to get an thermocouple SPI-multiplexer working together with an SD-card which both use SPI
chip-select is active low.
So my question is should any SPI-code switching chip-select to HIGH if it has ended communication?
And is the SD-library doing so? or do I have to execute certain operations to make the SD-library switch chip-select HIGH?
Several days ago I played around with SD and Ethernet. All my struggles with "failing SD" where not related to the CS handling - adding manual digitalWrites didn't help at all. All the problems come from low remaining memory. Even if I thought theres "plenty" SRAM left. Finally the sketch worked also with a pretty large file readed from SD and forwarded to ETHERNET - a file large enough never to fit in UNOs SRAM - so I'm pretty confident that CS handling of SD (and Ethernet) - works fine. Have you formated the SD card as adviced in [url]https://forum.arduino.cc/t/dont-format-sd-cards-with-os-utilities/222016/48[/url]
I don't know. My question here was invoked by the thread of user aattig.
Would this problems occur as soon as the SD-card-socket is attached elcetrically to the Arduino without software-initialising the SD-Card?
If yes this is not the case. If the software-initialisation of the SD-card is out-commented reading the SPI-bus for the analog-multiplexer is possible.
The user in that thread was using an Adafruit shield for the SD card, which does release MiSO properly.
That thread at one point discusses the possibility that the problem was caused by reading the multiplexer shield using an interrupt, which potentially would occur while the SD card was being accessed. which almost certainly occurs while the SD card is being accessed because the interrupt is being triggered by timer0 and would occur at 1.024mS intervals on an UNO.
imho is soft SPI no solution to the unknown problem. Find the root cause.
Ideas (ordered top down)
a) usage of pins / which bus member is using what pin
b) running out of SRAM. When I'm right, each open SD file will need 512 SRAM - which will not be seen in your globals as it is done after file open(?). Therefore - don't waist memory on large buffers (indeed this was my former issue), use c-strings instead of Strings, ... leave as much SRAM as possible. The SD card might start misbehaving before it really crashes.
c) check the used libraries ... (to be honest, I don't believe that SD.h is your problem)
I'll check if I can add a third SPI component to my test UNO, but I'm pretty confident it will work if it doesn't need to much SRAM.
I've added to my SD Logger, NTP + Webserver sketch two MAX7219 (daisy chained, using CS pin 8) with 14 segment digits,
and all 3 HW(!) SPI modules are working like planned.
nearly all resources are needed:
Sketch uses 30972 bytes (96%) of program storage space. Maximum is 32256 bytes.
Global variables use 1471 bytes (71%) of dynamic memory, leaving 577 bytes for local variables. Maximum is 2048 bytes.
again, remember the SD Card will need a lot of SRAM when the file is open...