Raspberry Pi Forums

I'm new to Raspberry and Python. I usually program controllers in Assembly running on Microchip processors running at 40 mhz. I know good assembly code is faster than compiled Python but Python is running on a 1+ Ghz chip (Pi 3) so I'm wondering if Python would have the ability to do what I need.

I need to track noiseless pulses (almost square wave) at up to 1300 Hz and generate a symmetrical square wave output at twice the input frequency (2600 Hx max).

Any estimates on whether a Pi 3 running Python could keep up with that?

I know that would not be too hard to do with hardware oneshots but there are some other requirements that preclude that.

Thanks for any good estimates or even guesses.

You will need to clarify.

Could you give some pseudo code?

In it's simplest form it would go something like this:

Initial cycle setup:
Detect rising edge of input
Start timing the input pulse
Wait for next rising edge of input
save period of input pulse
restart input pulse timer at zero
Wait for falling edge of input pulse

Operating Loop:
A. Set output pulse pin high
start output pulse timer at 1/4 period of input pulse width and start output pin timer
While input pulse pin = low
if output pulse timer = zero, reset output pulse pin low
Wend
Save input pulse timer value
restart input pulse timer at zero.
Set output pulse pin high
load output pin pulse timer with 1/4 of input pulse period and start output pin timer
While input pin = high
If output pin timer = zero, reset output pin low
Wend
Goto A.

I am hoping that the hardware timer in the 2837 chip can be used to decrement the two timers in this code, otherwise it will have to be done in software, probably inside the two while-wend loops.

Do you think this would run at an input pulse rate of 1300Hz?

Hope this is adequate to make a stab at it.\,

Thanks.

Okay, so you need an instant response without averaging.

Python will be able to keep up.

However there is a variable interrupt latency in the region of 50-100 µs between a GPIO level change and the userland process being notified. There will be an additional variable delay caused by the Python engine itself. In total that might introduce a jitter in the region of say 100-200 µs. On top of that there will be infrequent and unpredictable (in length) delays caused by the multi-user and multi-tasking nature of Linux.

You'll have to try and see if the result is acceptable.

As a matter of interest could you time-shift the response? I.e. track the input but introduce a 100 or so milliseconds delay?

Thanks joan, that helps a lot.

I don't think a 100 - 200 uS jitter would be a problem but a 100ms offset might possibly cause a problem with the following electronics. This is a fix for an ABS/Stability control in an automotive application. The original wheel speed sensor is gone and replaced with a different rear drive train. The new wheel sensor has only half the triggers per turn as the original, hence the need for this solution. It all depends on whether the ECU is responding to single pulse periods in real time or not. Come to think of it, if it is, the jitter might be worse than a 100ms offset.

Depending on the car's ECU, this might be overkill. It might be adequate to just trigger a fixed output pulse width on both the leading and trailing edges of the input pulse if the input pulse is more or less symmetrical.

You sound pretty knowledgeable about the Pi3. Is it possible to get the program to auto start on power-up of the Pi?

It would be pretty easy to get it autostarted. It's a normal computer, so if your desktop can do it, chances are the Pi can do it, ambient a bit slower.

Leadfoot wrote:Depending on the car's ECU, this might be overkill. It might be adequate to just trigger a fixed output pulse width on both the leading and trailing edges of the input pulse if the input pulse is more or less symmetrical.

Python for anti-lock brakes? The pi itself is not rated for safety critical applications, but Python itself for real time safety critical applications, ten times so!

The Pi seems overkill for this. An Atmel (as in most Arduinos) would be better suited and cheaper.

Leadfoot wrote:This is a fix for an ABS/Stability control in an automotive application.

Don't use a Pi then unless using bare metal, and even then I would suggest a dedicated micro rather than a Pi.

I understand the objections to Pi in safety critical applications. This is a situation where I'm in a time crunch to complete this temporary fix on a one-off project car before leaving on a 8000+ mile trip. Eventually it will be implemented on a custom PCB running machine code on a Microchip metal. But I gotta have this done and installed in 2 weeks. The Pi3 looks to be the quickest path to do that and it's better than no ABS/ASC at all which is what I've got now. But the real driver is that without the ABS/ASC functional, the ECU disables cruise control. I can do without ABS but the cruise control is a must have for this trip.

See if you can source something like an Arduino Pro Mini locally. The software will be simpler and more reliable. The Arduino IDE makes things quite easy.