sleepy_dog at gmx.de
sleepy_dog at gmx.de
Fri Feb 22 03:06:54 CET 2019
Ah, you were quicker. Fair points, yeahs younds like a strict /
philosophical thing. I guess the M4 allows one, in typical use scenario,
more easily than the thing that's "made to run Linux", to be real-time.
(I've recently made a lot of tests with different Linux configs with
regards to real-time, and gotten some sour taste of that :D)
I guess I consider M4 automatically to be "more realtime" is because I
can get not only more predictable, but also far smaller guaranteed
maximum time intervals for stuff, even the RT linux kernel patch can't
beat the granularity from what I remember. And it's also nicer
implementation wise to do something low level, bare metal with a bunch
of interrupts and stuff on an M4 than to mess in Linux kernel space
(which is a wild forest on its own, and then, some interfaces change all
3 months (okay, 3.5))
I guess you could use the bigger cortexes also as bare metal, I have not
looked into that, and the temptation to use all the readily available,
broad functionality that Linux offers is just too damn strong ;) Why
write drivers if there are already well tested ones for almost everything...
Am 22.02.2019 um 02:48 schrieb Brian Willoughby:
> 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