rsdio at audiobanshee.com
rsdio at audiobanshee.com
Fri Feb 22 04:37:13 CET 2019
There are so many terms that are poorly defined. I would not assume that “microcontroller” is less than Pentium.
By the way, the Intel Atom is a Pentium chip with embedded-style peripherals, and they call that a “System on a Chip.”
Basically, microprocessor is a broad term for a CPU on a chip, where “micro” is not supposed to be denigrating. A microcontroller simple includes both a microprocessor *and* some peripherals. There’s not a whole lot of difference between uC and SoC, except maybe the latter is assumed to be at least a little more capable.
As to how any bare metal process would not be real time, I’ve seen huge differences. With various processors, and writing interrupt handlers in standard C, I’ve looked at the assembly output of the compiler and saw literally hundreds of instructions to save the context at the beginning of each interrupt. Then, of course, there are hundreds of instructions to restore the previous context at the end of the interrupt.
For some processors, like the PIC, it’s probably best to just write the interrupt routine in pure assembly. Then, only the registers and resources that are actually used need to be saved and restored. For other processors, like the TMS320 DSP, I found that you can stay in standard C, but replace subroutines with smartly-written preprocessor macros (many of which are provided by Texas Instruments), and then suddenly those hundreds of instructions that deal with context are gone. The compiler will then be a lot smarter about saving only the registers that are changed.
My argument is that most people use a high level language like C, and don’t bother to look at the assembly that is generated, so the typical code suffers hundreds of cycles of latency that needn’t be there. I wouldn’t call it “real time” when so much power is wasted. All of this is true even without using an RTOS or Linux, so it has nothing to do with a badly made OS. Although a scheduler can cause similar issues, there can be problems even when there are no threads (no scheduler).
But, yes, you have a point that small MCU chips without cache and without pipelining can be near real time. I just wouldn’t automatically dump them all into the real-time category just because they’re bare-metal. Once you get to out-of-order execution, you certainly can’t call it real-time.
On Feb 21, 2019, at 5:49 PM, sleepy_dog at gmx.de wrote:
> Ditto. How is any bare metal processor not "real-time"? Unless you integrate a badly made OS into your firmware yourself, it's as real-time as it gets. The R4F is only one of the bigger real-timey processors, as opposed to microcontroller? Or is there a context where real-time has a very specific meaning other than it's not impeded by a jittery scheduler?
> That aside, I find it slightly amusing that the stm32F7 or H7 or whichever it was that has an out-of-order pipeline and considerable instruction + data cache and lots of single-cycle float OPs that might give the first Pentiums a run for their money, is also still considered to be a "microcontroller" :D
> I wonder how many football stadiums such a thing would fill in 1960's tech.
> Am 22.02.2019 um 02:01 schrieb Declare Update:
>> 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