I can test this, but haven't the time to yet, so wanted to ask ahead of starting testing whether I have much hope of success.
I want to get a Pi (Pi3, Pi3A, Pi Zero W) with the 2019(approx) era BCM chip to send some "real timed" pulses from a GPIO pin.
Real time in this context means that the time between rising and falling edges must be within the region of >20us and <55us, where it is in that region doesn't matter.
I've had an atmega328p and/or an attiny84 sending these sort of controlled length pulses trivially, using "cli()" to disable other interrupts during the time if I wanted to be really consistent, but even with random clock or serial related interrupts happening at various times an oscilloscope trace showed that in the very worst case scenarios pulses were always consistent to within 5us or so of the desired time. But those devices have no operating system, they just run a realtime C program and nothing else.
Realtime in my use case also means a string of these pulses must be able to be sent, 300 or so, such that there is no delay >55us between the rising and falling or falling and rising edges. Witin the pulses if the OS's timesharing scheduler delays parts of my C code at random times by several tens of us then, it won't matter, but a bigger delay would be a problem. After the bunch of pulses is done, I don't mind if the schedular delays by randomly added 10s or even hundreds of milliseconds before other bits of my C code run.
I can also perhaps specify that I'd be ok if I have a chance of being delayed by more than 55us small enough to arise less than once per 1000 such 300 pulse pulse-trains sent, then that is ok. Though I'd rather be certain that every pulse train sent would be free of excessive delays. When I say <1 in 1000 I am not making any assumption about whether the time intervals between the pulse trains is 10s of ms, seconds, or even minutes.
I would be looking to write a C program using the bcm2835 library by MikeM from AirSpayce (https://www.airspayce.com/mikem/bcm2835/). I've used that before for GPIO control and it worked very nicely for me.
I cannot use special function enabled pins (I2C, SPI...) for this, this needs to be able to be done from any ordinary GPIO.
Is there much hope of getting "realtime" in this sense when using a C program with the bcm2835 library, running as sudo, on a Pi3 era Pi, using the typical Raspbian default OS?
And, the next bit I can't test as I haven't got any more recent Pi types to hand, if there is a decent hope then will this act still hold true for mroe recent higher performance Pi types, including the latest Pi 5 where I understand that GPIO control is now all done via a new piece of Raspberry Pi Foundation designed silicon.
Thank You
I want to get a Pi (Pi3, Pi3A, Pi Zero W) with the 2019(approx) era BCM chip to send some "real timed" pulses from a GPIO pin.
Real time in this context means that the time between rising and falling edges must be within the region of >20us and <55us, where it is in that region doesn't matter.
I've had an atmega328p and/or an attiny84 sending these sort of controlled length pulses trivially, using "cli()" to disable other interrupts during the time if I wanted to be really consistent, but even with random clock or serial related interrupts happening at various times an oscilloscope trace showed that in the very worst case scenarios pulses were always consistent to within 5us or so of the desired time. But those devices have no operating system, they just run a realtime C program and nothing else.
Realtime in my use case also means a string of these pulses must be able to be sent, 300 or so, such that there is no delay >55us between the rising and falling or falling and rising edges. Witin the pulses if the OS's timesharing scheduler delays parts of my C code at random times by several tens of us then, it won't matter, but a bigger delay would be a problem. After the bunch of pulses is done, I don't mind if the schedular delays by randomly added 10s or even hundreds of milliseconds before other bits of my C code run.
I can also perhaps specify that I'd be ok if I have a chance of being delayed by more than 55us small enough to arise less than once per 1000 such 300 pulse pulse-trains sent, then that is ok. Though I'd rather be certain that every pulse train sent would be free of excessive delays. When I say <1 in 1000 I am not making any assumption about whether the time intervals between the pulse trains is 10s of ms, seconds, or even minutes.
I would be looking to write a C program using the bcm2835 library by MikeM from AirSpayce (https://www.airspayce.com/mikem/bcm2835/). I've used that before for GPIO control and it worked very nicely for me.
I cannot use special function enabled pins (I2C, SPI...) for this, this needs to be able to be done from any ordinary GPIO.
Is there much hope of getting "realtime" in this sense when using a C program with the bcm2835 library, running as sudo, on a Pi3 era Pi, using the typical Raspbian default OS?
And, the next bit I can't test as I haven't got any more recent Pi types to hand, if there is a decent hope then will this act still hold true for mroe recent higher performance Pi types, including the latest Pi 5 where I understand that GPIO control is now all done via a new piece of Raspberry Pi Foundation designed silicon.
Thank You
Statistics: Posted by Infraviolet — Sat Jan 13, 2024 4:06 am — Replies 0 — Views 10