4 ms·
If it has their insanely broken i2c implementation, it wouldn't matter if it cures cancer. Look into the linux driver for stm32 i2c driver. more curses per com
by dmitrygr 8y ago
If it has their insanely broken i2c implementation, it wouldn't matter if it cures cancer.
Look into the linux driver for stm32 i2c driver. more curses per comment than any other driver. they are ALL deserved.
- ohazi 8y agoiirc, their SPI hardware is also a little wonky. The designer seems to have assumed that the only thing you'd ever want to read from in receive-only mode is an SPI flash chip, so it eagerly tries to fill the receive buffer every time you read. So you might be trying to do a single word read from some device, but you'll see a dozen reads on a scope trace. The only way that I've found to get around this is to run a dummy transmitter. Transmit as many zero bytes as you'd like to read, and then it'll run the receiver in lock-step. This would have all been reasonable if it were documented, but it wasn't at the time.
- scoutt 8y agoWhile I agree that I2C is mostly broken and filled with workarounds (at least in the STM32F103x family), the SPI in master mode (as I understand you are referring to) works fairly well. To receive data you have to send clock pulses. Sending clock pulses also means that you are transmitting (zeroes in your case), but there is no way to escape from that since it's the way SPI works. SPI in STM32 is very precise with timings and general behavior. Take a look on how some seasoned users implement SPI to do VGA graphics: https://www.artekit.eu/vga-output-using-a-36-pin-stm32/ https://www.artekit.eu/vga-output-using-a-36-pin-stm32/
- dmitrygr 8y agoI think the parent was talking about using SPI in bidirectional mode (one shared wire for both tx and rx). In that case indeed it is hard to only read a fixed small number of bytes