4 ms·

It's sad how the software stacks have gotten to this point where toggling a pin is so horribly inefficient. And there's no good reason it has to be. - Instead

by ambrop7 10y ago

It's sad how the software stacks have gotten to this point where toggling a pin is so horribly inefficient. And there's no good reason it has to be. - Instead of filesystem operations there could be ioctl, which is still safe from the OS perspective (yes there is overhead compared to direct register manipulation but much less than putting strings into the /proc filesystem). - With a real-time kernel combined with understanding of the scheduling and relevant concepts (e.g lock memory), it should be possible to achieve much better latencies, possibly on the order of tens of microseconds. I'm not sure how much variance there invariably will be due to processor cache or other sources but I suspect it's too little for most people to care. - Finally, does anyone have an idea about the possibility of handling interrupts in user space? I don't mean "second-level" (bottom-half) handlers, but the raw interrupt handlers, without any overhead of scheduler or work queue in front of your code. Sure there are more things to be careful about like making sure you're acknowledging an interrupt but that's a given. Doesn't it mostly boil down to the kernel setting up appropriate context like virtual memory within the ISR? Do CPU designs prevent doing this? Saying to "leave the real-time things to microcontrollers" is basically giving up. Hardware should be as general-purpose as possible and this also applies to being able to do real-time things. I'm not saying the PRUs are not useful, but they are a very awkward solution for probably most real-time programming problems that are not currently easily solvable with just the main CPU. These things use a custom assembly language and there isn't even a C compiler for them! I would be much happier with an integrated ARM microcontrollers.

revelation 10y ago
There is a C compiler for the PRUs, but frankly you're missing the point if you're asking for that, the whole reason of their existence is to manage processes that require extremely deterministic timing. You might update your C compiler, find something is compiled differently and now all the timings are off. They are not so much meant as microcontrollers, they are for things you would otherwise have to do on an FPGA to get the timing reliably correct. Tens of microseconds just don't cut it. Some areas such as realtime ethernet protocols require nanosecond-accurate packet insertion. The summary of why things are the way they are is that modern operating systems and CPUs value throughput over everything.
- ambrop7 10y ago
  Let me reiterate, I don't think the PRU is a problem. But it's just about the many orders of magnitude in the real-time latency achievable with the PRU and achievable with the CPU under the default software stack. I shouldn't have to use the PRU for every problem that has some real-time requirements, I should be able to use the actual real-time abilities of the CPU. There are many benefits to being able to do so (e.g. portability, less effort). Real-time is not a binary thing, there's a whole spectrum. In many cases compiling real-time code is a non-issue.

by ambrop7 10y ago

revelation 10y ago

There is a C compiler for the PRUs, but frankly you're missing the point if you're asking for that, the whole reason of their existence is to manage processes that require extremely deterministic timing. You might update your C compiler, find something is compiled differently and now all the timings are off. They are not so much meant as microcontrollers, they are for things you would otherwise have to do on an FPGA to get the timing reliably correct. Tens of microseconds just don't cut it. Some areas such as realtime ethernet protocols require nanosecond-accurate packet insertion. The summary of why things are the way they are is that modern operating systems and CPUs value throughput over everything.

ambrop7 10y ago
Let me reiterate, I don't think the PRU is a problem. But it's just about the many orders of magnitude in the real-time latency achievable with the PRU and achievable with the CPU under the default software stack. I shouldn't have to use the PRU for every problem that has some real-time requirements, I should be able to use the actual real-time abilities of the CPU. There are many benefits to being able to do so (e.g. portability, less effort). Real-time is not a binary thing, there's a whole spectrum. In many cases compiling real-time code is a non-issue.