On Sat, Dec 4, 2021 at 10:26 PM Keith Emery k.emery.nbn@internode.on.net wrote:
spkmodem-recv software. If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates?
I don't think that the speed of the SPI bus would have any noticable effect, as it's still several orders of magnitude faster than the rates that spkmodem deals with. Looking through the code, I've determined that the protocol is as follows: - 200 Hz tone when idle - Each character is sent out bit by bit as a 2 kHz tone for 5ms for a 1 bit and a 4 kHz tone for 5 ms for a 0 bit (which works out to 200 baud) - 1 kHz tone for 5 ms signalling the end of the character
However, the SPI bus typically runs at tens of MHz, which should be plenty enough to have no effect on spkmodem transmission. Even if it did slow down the instruction retrieval rates by a significant amount, the most likely effect would just be prolonging the length of each tone, as that appears to be the most timing sensitive code. Also, the tones are generated by the (emulated) PIT timer, which, once programmed, should produce the set frequency independent of everything else. Since each bit is mapped to different frequencies, the actual baud rate it is running doesn't technically matter, and the receiving code should only be looking for changes in frequency to decode the data.
Based on this I think spkmodem-recv and/or the methods of recording the output are more likely to blame. The spkmodem-recv code is very picky about the format of the recorded signal, as it implements its own decoding directly from the sampled audio data. I've looked at its code and it's sort of a mess, and it is somewhat difficult to understand the decoding algorithm at first glance. From some initial analysis I think it's also picky about the exact timings and possibly even the volume of the tones, but it looks like there are some defines at the top which appear to be thresholds of some sort. You could try messing around with those to see if they change anything, but it would take me a bit more time to figure out exactly how the decoding algorithm works.
Regards, Nicholas