<div style="color:black;font: 10pt Arial, Helvetica, sans-serif;">Murray,
<div><br>
</div>
<div>I guess I am speaking generally. I read sections of the datasheet for the new $4 USD RP2040 based Pico and the Broadcom manual for the SoC on the Pi 1. I see that the Pi 1 and the new Pico have hardware interrupt controllers in the SoC. Aren't those "true" interrupts? Maybe the later Pi versions use Broadcom chips that don't have an interrupt controller built in.</div>
<div><br>
</div>
<div>Interrupts aren't always a good thing. Interrupts are very bad for fast, heavily pipelined host processors with extraordinarily good branch prediction. For those architectures, polling is better. But for an SoC, I would be surprised if there were no hardware interrupts.</div>
<div><br>
</div>
<div>The Pi 1's system timers may have to be restarted after each interrupt, which is not the kind of repeating interval interrupt that I was expecting. I may be misunderstanding the Broadcom documentation.</div>
<div><br>
</div>
<div>Learning stuff.</div>
<div><br>
</div>
<div>Later,</div>
<div>John Swindle</div>
<div><br>
<br>
<div style="font-family:arial,helvetica;font-size:10pt;color:black"><font size="2">-----Original Message-----<br>
From: Murray Altheim via DPRGlist <dprglist@lists.dprg.org><br>
To: dprglist@lists.dprg.org<br>
Sent: Fri, Feb 19, 2021 6:49 pm<br>
Subject: Re: [Dprglist] PID-tuned Clock in Python?<br>
<br>
<div dir="ltr">On 20/02/21 8:43 am, John Swindle via DPRGlist wrote:<br clear="none">> Folks:<br clear="none">> <br clear="none">> Looks like I stuck a stick in an ant hill.<br clear="none"><br clear="none">Hi John,<br clear="none"><br clear="none">All in good fun... I take their very generous guidance seriously,<br clear="none">and it's very much appreciated.<br clear="none"><br clear="none">[...]<br clear="none">> Regarding a sync, Murray added an external interrupt to time <br clear="none">> the loop (not to timestamp the sensors together as I am doing).<br clear="none">> For the loop timing, why not use the hardware timers built into<br clear="none">> the local interrupt controllers instead of an external source?<br clear="none">> Maybe I'm wrong here (because I haven't tried it, and I don't<br clear="none">> need to try it), but all of the local interrupt controllers <br clear="none">> that I've read about have hardware timers that can be programmed<br clear="none">> to give repeating interrupts. I see that this is available on<br clear="none">> Android. I read that the Android average timing will be the <br clear="none">> programmed timing unless the ISR takes more time than the <br clear="none">> interval between interrupts. One interrupt can be posted, but a<br clear="none">> second interrupt at the same level is discarded if the first has<br clear="none">> not been cleared. Makes sense.<br clear="none"><br clear="none">I'm not sure what you mean by an interrupt controller in the context<br clear="none">of what I'm doing (or maybe you're speaking more generally). I've got<br clear="none">a Raspberry Pi-based robot that doesn't have any other devices onboard<br clear="none">except say, my motor controller (which is I2C-based) and some sensors.<br clear="none">I added the Itsy Bitsy M4 (Cortext M4) as the second CPU/device, which<br clear="none">is providing me that external clock.<br clear="none"><br clear="none">But I don't have any other devices on the robot, and as we know the<br clear="none">Raspberry Pi doesn't have "true" interrupt support, only the RPi.GPIO<br clear="none">and pigpio libraries that permit listening on a GPIO pin, with a<br clear="none">callback. So it's like an interrupt, but not. It polls the pin.<br clear="none"><br clear="none">I was trying to find the polling rate (which I think even I provided<br clear="none">in a message a few weeks ago, something like 5-50µs) but couldn't<br clear="none">locate the source. I'm not sure how this compares with the ST<br clear="none">microcontroller boards that David uses for his robots, but even while<br clear="none">a Raspberry Pi running Linux is a time-sharing OS, it is still a<br clear="none">pretty quick CPU (generally 1.2-1.4GHz, compared with ~16-240MHz on<br clear="none">microcontrollers) so the clock speed is certainly sufficient.<br clear="none"><br clear="none">Talking about the performance of two main libraries for dealing with<br clear="none">GPIO pins on the Pi I found this:<br clear="none"><br clear="none"> "Both libraries perform well for frequencies of up to 5 KHz with<br clear="none"> accuracy above 99%. The accuracy of the Rpi.GPIO library<br clear="none"> deteriorates over 5 KHz and at 50 KHz it is incapable of performing<br clear="none"> this task.<br clear="none"><br clear="none"> The PIGPIO library performs comparably better, with its accuracy<br clear="none"> being above 99% for frequencies up to 20 KHz. Above that frequency,<br clear="none"> its performance gradually deteriorates and at 110 KHz it cannot<br clear="none"> read correctly any phrase at all."<br clear="none"><br clear="none"> <a shape="rect" href="https://raspberrypi.stackexchange.com/a/120614" target="_blank">https://raspberrypi.stackexchange.com/a/120614</a><br clear="none"><br clear="none">So there are hardware limitations but really, as David and Karim have<br clear="none">rightly noted, this is more of a hardware architecture question. A<br clear="none">Pi is not a microcontroller, and it has its own idiosyncracies. That<br clear="none">doesn't make it unsuitable for robotics (clearly, as it is very widely<br clear="none">used) but it has limitations, just as do microcontrollers. They're just<br clear="none">different sorts of limitations. It's all trying to figure out what one's<br clear="none">requirements, predilections, goals, etc. are, and finding the right<br clear="none">balance.<br clear="none"><br clear="none">A Raspberry Pi-compatible SBC with real interrupts is something I've<br clear="none">been looking for for about a year now. I've bought a few oddball boards<br clear="none">trying to find something that hits the sweet spot, but nothing yet;<br clear="none">there always seems to be some hitch. Recently Kipton mentioned that cool<br clear="none">STM32MP157A-DK1 hybrid microcomputer/microcontroller board which might<br clear="none">just work:<br clear="none"><br clear="none"> <a shape="rect" href="https://www.mouser.com/ProductDetail/STMicroelectronics/STM32MP157A-DK1/?qs=9r4v7xj2LnkgRwGGD4%252BIjQ%3D%3D" target="_blank">https://www.mouser.com/ProductDetail/STMicroelectronics/STM32MP157A-DK1/?qs=9r4v7xj2LnkgRwGGD4%252BIjQ%3D%3D</a><br clear="none"><br clear="none">I'm still thinking about that as it's NZ$106, something that shouldn't<br clear="none">end up gathering dust on my shelf if it doesn't work out... I like having<br clear="none">cool things lying around my playroom as much as the next boy, but it can<br clear="none">get a bit expensive...
<div class="yqt0240679150" id="yqtfd56178"><br clear="none"><br clear="none">Cheers,<br clear="none"><br clear="none">Murray<br clear="none"><br clear="none">...........................................................................<br clear="none">Murray Altheim <murray18 at altheim dot com> = = ===<br clear="none"><a shape="rect" href="http://www.altheim.com/murray/" target="_blank">http://www.altheim.com/murray/ </a> === ===<br clear="none"> = = ===<br clear="none"> In the evening<br clear="none"> The rice leaves in the garden<br clear="none"> Rustle in the autumn wind<br clear="none"> That blows through my reed hut.<br clear="none"> -- Minamoto no Tsunenobu<br clear="none">_______________________________________________<br clear="none">DPRGlist mailing list<br clear="none"><a shape="rect" ymailto="mailto:DPRGlist@lists.dprg.org" href="mailto:DPRGlist@lists.dprg.org">DPRGlist@lists.dprg.org</a><br clear="none"><a shape="rect" href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br clear="none"></div>
</div>
</font></div>
</div>
</div>