we were trying to get the best result with software PWM on raspberry pi with Raspbian. We made a python script which starts PWM on a GPIO pin, and observed the results with the oscilloscope.

It didn't do well, the delay wasn't acceptable.

After that we set the realtime priority of our software PWM process to 99 and changed the scheduling to real time round robin, anf later to fifo (1865 is the process pid).

sudo chrt -f -p 99 1865
sudo chrt -r -p 99 1865

It acted the same as before the priority change.

ALL the other processes were run with nonrealtime priorities. However, there were around 3000 interrupts per second going on from the timer and USB.

In this question the answer stated:

... the vanilla kernel handles real time priorities, which gives them higher priority than normal tasks, and those tasks will generally run until they voluntarily yield the CPU

Any ideas why the change of priority didn't have a visible efect? Do real time priorities influence what will happen with the process on interrupts?

  • Then your process did not need/did not benefit from real time priority. No, real time priorities don't affect how interrupts are handled. Python wouldn't be my first choice for real-time either... – vonbrand Feb 12 '13 at 18:09
  • @vonbrand Is it then safe to conclude that my process is the king of user space :). However, the problems that are preventing his real time behavior are happening in kernel space and are therefor not influenced by his ultimate priority as a user space process? – TheMeaningfulEngineer Feb 12 '13 at 22:23
  • This question is a bit borderline here — while setting priorities is something an admin might do, it's more of a developer concern. If you don't get an answer here, consider asking for migration to Stack Overflow or Electrical Engineering. (It would be a typical question for Embedded Programming and Design if that site is ever created.) – Gilles 'SO- stop being evil' Feb 12 '13 at 22:44

I didn't make a visible effect because the process was run in user space and it was given real time priorities in context of other processes in user space.

However, the kernel space was still loaded with interrupts, and when other processes got their (small) share of processor time, they could have initiated a system call which as a result has a migration to kernel space where the real time priorities of our process don't mean anything.

The interrupts were all happening in kernel space, an where therefor also not influenced by the real time priorities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.