to cut off its supply and enable it again. It might be beneficial to be able to power-cycle the SD card, e.g. EDIT: I used ceramic capacitors (3x 22 ♟, 1x 10 ♟, 1x 1 ♟, 1x 100 nF) close to the SD card and separated from the main supply rail by a 1 Ω resistor and measured a transient voltage drop from 3.30 V to 3.22 V for about 100 µs when inserting the card, which is fine. The SD card will draw significant currents when plugging in, which might cause a brown-out for both the SD card and other components. Use large buffer capacitors placed right at the SD card (e.g. (I solved it by sending the data to a "dummy" slave with the CS pin of this dummy/virtual slave unconnected - that way the microcontroller can deal with the CS lines by itself.)Īlso, start without using any other slaves until the initialization sequence works well, then you may re-enable the other slaves (after the initialization or even during initialization). one byte 0xFF), then you can communicate with other slaves. So: CS low, exchange data with SD card, CS high, send dummy data (e.g. Otherwise, the SD card will keep the DO/MISO ((master in slave out)) output active and cause two slaves to drive/short-circuit the MISO line! If you share the SPI bus with other slaves, always send another "dummy" byte (or more) with the CS line inactive (high) after each communication to the SD card before accessing other slaves. only using different chip select (CS) lines), I would not recommend it - it saves you some trouble to use separate SPI buses. All the libraries I've seen are not real-time capable and can take quite some time to execute, at least from my understanding, so here we are.)Īlthough it is possible to share the SPI bus with SD card and other slaves (e.g. (For example, I had a real-time microcontroller system that only has small periodic time slots in which I can perform SD card logging tasks and start/evaluate SPI sequences. Instead, you can use tools like HxD or the dd command on Linux ( Windows versions are available as well) to read/copy the raw data. However, the disadvantage is that you can't simply read the data with a file explorer. If you can't use the libraries for some reasons, you can also initialize the SD card on your own (which is what I describe here) and write to the SD card blocks/sectors directly without a (proper) file system or with your own one. SdFat (for Arduino, but might be portable).If you can, I would suggest stopping here and giving them a try, because you probably don't need to deal with low-level things: There are several libraries that significantly simplify accessing the SD card, using a proper file system so that the files can be read easily with a file explorer on the computer. I also was able to transfer files to and from TERATERM and you can type ^Z on teraterm and it ends the transfer.SDUC (ultra capacity, > 2 TB) cards don't support SPI according to the specifications. But can always use LOAD and UNLOAD to send hex files, which includes the checksum in each line. Of course, the characters are truncated to 7 bits and I added this in the same way as the CON, so can't send binary files. On the receiving machine PIP TEST.TXT=RDR:Īnd it transferred the file! No need to patch xmodem, this is CP/M running out of the box. On the sending machine PIP PUN:=LOREM.TXT,EOF: (sends a ^Z at the end) Added in Serial1 and linked it to the PUN and RDR CP/M calls. (or directly, but I zapped some other boards a while back inadvertently linking 3V and 5V boards, so prefer the robustness of RS232). The ESP32 is cheap enough you can flash a couple of boards, and then link them with cheap RS3232 to TTL modules. Meanwhile, tiny little hack I have wanted to do for years - file tranfers between CP/M machines using PIP. Quick perusal through the code, I dunno, 20 to 50 lines need changing.ĭeep inside the code thinking about how to incorporate the working ESP32 SD code. And then there are slight differences in the way functions are called, eg in runCPM to append a fileį = SD.open((char *)filename, O_WRITE | O_APPEND) And there are two SD.h files that are different, so need to tell the compiler which one is being used (more ifdefs). There are some syntax changes, for instance, no need to declare which pins are which as these are fixed. what would it take to port this code into the RunCPM? Lots of #ifdefs I suspect. Ok, on the arduino IDE once ESP 32 is installed, File/Examples/ESP32 examples,/SD(esp32)/SD_Test., this appears to be the official SD code for the ESP32, and indeed it works fine for every SD card I can find. Works with sandisk and kingston, not with no-name sd cards. Simple test for writes - start MBASIC, write a one line program and then save it. More experiments August 2nd regarding the SD card and ESP32.
0 Comments
Leave a Reply. |