I’ve got a project on an ATMega that uses an SD card reader and a software serial port as well as the standard serial port. Not unsurprisingly, it runs short of memory (despite the tricks of poking strings into program space). It occurred to me that I might get some memory back if I had an ICSP to serial adaptor. These seem to not actually exist as a thing, but I wondered if the USB Serial light adaptor ( SKU: DFR0164) would run backwards, taking data on the MISO pin and presenting it to the serial output. Any ideas?
2 Likes
Hey,
Welcome to the forum!
Just to confirm, your project is already using all of the serial ports and you were looking to debug/tap into the SPI comms instead of serial?
You’d be able to program some device such as the adapter you were looking at to convert between the two protocols then read it on a PC.
Could you free up a serial connection and tap into your project from that point (still using some serial to USB converter)? I imagine it would save a ton of dev time.
1 Like
Hi Liam
Development time isn’t a problem. I’ve looked through my schedule for years ahead, and my funeral isn’t listed. 
There is only one serial port on the ATMega. I’ve dedicated that to the highest priority task. I used a software serial port for the next highest task. It worked ok until the file system for the SD card was loaded, then things got weird. Since the aim of the project is to record data to the SD card, that bit has to stay. If I can use the adaptor backwards, and if the SPI library (already loaded for the SD card reader) doesn’t take up more memory when used this way than the software serial driver, then I’ll have a winner.
I’m not looking to reprogram the adaptor. I note that it has an SPI connector and is used to program devices such as the ATMega. Just wondering if I simply drive the SPI, will the data turn up at the serial port. For $3, it’s worth a try.
Peter.
3 Likes
What is the weirdness that you are seeing? Are you sure it’s a memory problem? This sort of issue can be related to sharing of timers, and changing to a different software serial library that uses timers differently (or not at all) solves the problem.
4 Likes
Hi Jeff.
The code uploads, but does not always run or runs with odd behaviour such as variables being overwritten with garbage, counters having funny values, state machines having unknown states…
Memory usage is at about 70% (of 2k), but opening a file on the SD card will create a 512 byte buffer. I expect that the software serial port will have a 32 byte buffer plus some space for processing.
I’m rewriting to minimise variable use, particularly string buffers (one global dogsbody string instead of several locally declared strings), as well as looking at hardware fixes.
Peter.
4 Likes
