brianw at audiobanshee.com
Fri Feb 22 02:48:49 CET 2019
As is true with many technical terms, the definition of “real time" varies from one group to another. The answer is probably more philosophical than anything else.
In a general sense, “real time” means that the latency between a real-world event and the computer response to that same event is fixed and therefore predictable. However, in practical terms, there are many different processor designs, and often the most advanced features make it difficult to predict the response time. These days, we usually won’t accept a processor that has zero modern features, so there is always a little unpredictability, but hopefully the margin is small. Another practical consideration is that different operating systems - Linux, RTOS, bare-metal - have different response times. Yet another practical consideration is that some firmware developers use (bad) coding styles that significantly affect the response time - both by longer latencies as well as with less predictable latencies.
For all of the reasons above, it can be difficult to know when to apply the term “real time” and when to just say “embedded” (even the term, embedded, has too many definitions). In the case of ARM Cortex processor variations, the fact that they have a specific Real-time model, Cortex-R, should make it easy to decide when to use the term and when not to use it.
Another general guideline that might be worth considering is that bare-metal embedded firmware is usually closer to real time than Linux or other high-level operating systems. In that sense, it might be reasonable to label any embedded processor as “real time” in comparison to a Linux alternative. However, the reason I object to the term is that an average open source developer could easily create firmware for the Cortex-M4F that is very poor with regard to real-time performance, so it doesn’t seem safe to call it real time unless you have a proven set of firmware to measure.
That’s a good link, although it’s a little difficult to read.
p.s. I’ve worked with firmware for the PIC, which is an 8-bit microprocessor, where the original firmware developer was so bad that the performance was decidedly *not* real-time. One might argue that a processor as simple as the PIC18F should always be considered real time. However, in this example, the original developer allocated memory inside an interrupt, and otherwise had so many layers of unnecessary complexity that the firmware was completely unreliable and couldn’t even handle 5 kHz sample rates (certainly nowhere hear 44.1 kHz for audio). Thankfully (for the client), I rescued this firmware and made it real-time performant.
On Feb 21, 2019, at 5:01 PM, Declare Update <declareupdate at gmail.com> wrote:
> Brian, I had never considered that an M4 might not be “real time”. what do you mean by this? I found this https://www.design-reuse.com/articles/26106/cortex-r-versus-cortex-m.html but it didn’t clear it up much.
> On Feb 21, 2019, at 6:44 PM, Brian Willoughby <brianw at audiobanshee.com> wrote:
>> Interesting. I wouldn’t call the Cortex-M4 a “real-time” MCU. Embedded, certainly, but not Real-Time. I think you’d have to look at the Cortex-R4F for real-time.
>> I’m still (sort of) waiting for the open source community to support either the TMS320 DSP family or the SHARC DSP family. The Aleph was Blackfin, but that’s only about half way to SHARC or TMS320 DSP performance.
>> On Feb 21, 2019, at 12:47 PM, sleepy_dog at gmx.de wrote:
>>> may be of interest for some:
>>> There is a discovery board for $ 69,- with this new STMicro processor, 512MB RAM, audio codec, SPDIF connectors and other stuff.
>>> The processor has a dual core ARM Cortex A7 @ 650 MHz which can run Linux, and one Cortex M4 with FPU @ 209 MHz, LCD TFT controller...
>>> Lots of audio projects shenanigans could be done with that - which is probably also true for the raspberry pi family - but having a real-time MCU (the M4) also integrated seems nice for some stuff.
More information about the Synth-diy