2 ms·
Eh, if you're doing anything in the background on an RPi, timing intensive operations like I2C or SPI get really buggy. Years ago, I had to add a retry function
by petsfed 3y ago
Eh, if you're doing anything in the background on an RPi, timing intensive operations like I2C or SPI get really buggy. Years ago, I had to add a retry function to basic, 3-byte I2C transactions on an RPi, because even something as simple as that was still getting bumped pretty often. These days, I'm more likely to just use a microcontroller for all of those operations, and then use an FTDI cable to let the micocontroller report its results up to the RPi. That's always been easier than setting up something like DMA on an RPi.
Granted, I write microcontroller firmware for a living these days, but I still use RPis and Arduinos for proof-of-concept work because of the simplicity of the toolchains.
- yjftsjthsd-h 3y agoI thought Linux had better support for realtime workloads these days? I mean, yes, I would still prefer a dedicated micro, but if you need a Real Computer in the mix it might be possible to get better results out of it.
- petsfed 3y agoI mean, yes and no. But it also gets into "who is it for?" and while you can do things better, eventually you reach a point where its easier to just do it the right way.
- petsfed 3y agoI mean to say, at the point where the I2C library user has to seriously think about patching their kernel, the strengths of the RPi as an out-of-the-box embedded computer are pretty much negated. If you have to do actual embedded engineering things, then the RPi becomes just another SoC dev board.
- joshish 3y agoProbably, but if you think about the final 20% of the workload in optimizing, I think it's safe to say one will be immensely more grueling than the other just by the nature of it. Not to say that your original comment didn't have merit; the beauty of hobby projects is that you can completely skip the last 20%.