GHz Microcontrollers? You Bet!

[ali_asadzadeh]

I knew it! NXP would F**k ST, finally, If they manage to produce some 0.8mm BGA tough!

[tggzzz]

We pretty much agree; I'm concentrating on some of the imperfections that plague us and make porting unpleasant.

If I design a device around an MCU and program it in C in a reasonable way (most code portable, the only non-portable stuff clearly defined and well isolated), switching to a different MCU from a different vendor IS possible, and may not take much time. I'll have some porting to do for the non-portable parts, but that's mostly straightforward if I did things right in the first place. If the MCUs are on a similar architecture, that's even more straightforward, but even when they aren't, that's usually not a huge deal (unless I really used very specific features ALL over the place... which I avoid doing, or if I do, that'll be on a very small design needing a lot of optimization, and if it's small, rewriting it would take a lot less time anyway.)

If I design for an FPGA in VHDL, and again structure my code properly, porting it to a different FPGA is not that big a deal. If I used some specific IPs from one FPGA, I'll just port those parts to use equivalent IPs for the other. Done. I also usually write VHDL so that it can even be synthesized trouble-free on an ASIC if needed, and again, modulo just replacing specific IPs with corresponding ones, or implementing them.

In both those cases there is a practical limitation which makes porting more difficult: the specific peripherals in MCUs, and the specific CLBs and primitive blocks in FPGAs (e.g. SERDES or multiport RAM). If you can write in pure HDL and not make use of specialised features on a specific family, then that problem isn't serious.

In addition, with FPGAs the toolset is very much a key part of the manufacturer's competitive advantage.

As I said above, I don't know exactly what license(s) apply to xC. If the language reference is free to use, and if third parties have a right to develop xC compilers, I'll consider xC "open". The XMOS xC compiler itself doesn't necessarily have to be open source. Now if XMOS doesn't allow any third party to use/implement xC, I'll consider it "closed", and my developments in xC would be forever tied to XMOS products. I'll really have to check about that!

I doubt xC is free in any sense other than beer.

I haven't seen it for any other manufacturer's products, but that goes with the territory of being a pioneer. It is an important commercial consideration.

XMOS did at one stage have a device which was (IIRC) seven xCORE plus one ARM core, all of which could be programmed in xC. Since xC is C underneath, I guess they were opening the door to having conventional libraries executing in the ARM core.

[Marco]

anything that one could use to build a development board under 2"×2" for under $30 retail price?

A 16 bit wide ddr3l ic isn't going to prevent you from meeting those requirements. 

[mikeselectricstuff]

If you want a flash based MCU the flash brings severe speed constraints, even if paired with a reasonable amount of cache. Use ROM or RAM for the code and gigahertz MCUs are not a problem. A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM. While most MCU applications only need the MCU to run at a few megahertz, a lot of potential applications open up if you can get cheap MCUs that will compute fast enough to do some serious signal processing.

1MByte flash 1000MIPS, no cache to get in your way, nowhere near the top of the range.
https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103

When you hit a brick wall, change direction!

Only 2 of 40 "XUF..." parts in stock .

[tggzzz]

If you want a flash based MCU the flash brings severe speed constraints, even if paired with a reasonable amount of cache. Use ROM or RAM for the code and gigahertz MCUs are not a problem. A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM. While most MCU applications only need the MCU to run at a few megahertz, a lot of potential applications open up if you can get cheap MCUs that will compute fast enough to do some serious signal processing.

1MByte flash 1000MIPS, no cache to get in your way, nowhere near the top of the range.
https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103

When you hit a brick wall, change direction!

Only 2 of 40 "XUF..." parts in stock .

My post merely offered a specific counter-example to coppice's general contention.

[SiliconWizard]

the STM32H745I-DISCO > $80.  My SBCs are cheaper than that.

You might take a look at the stm32h743 nucleo board  ($27usd) : https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-H743ZI2/497-19452-ND/10130892

The H755 has a Nucleo board, and it's $29.

https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html#sample-and-buy

[nctnico]

IMHO having cheap evaluation boards is just a non-issue. I happily pay more for an evaluation board if that means getting more features and the design files. Starting out with a low cost part is the wrong path anyway.

[Nominal Animal]

The H755 has a Nucleo board, and it's $29.

https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html#sample-and-buy

The only distributor, Arrow, tells me "This product is currently not available for order on arrow.com".

IMHO having cheap evaluation boards is just a non-issue. I happily pay more for an evaluation board if that means getting more features and the design files. Starting out with a low cost part is the wrong path anyway.

Oh, but our use cases are completely different.  With these things, I make experimental stuff that I hope other hobbyists can replicate, as there may not be an actual market for a finished product.

The actual use case I have in mind, is a dual-core microcontroller that could control three or four TMC2209 stepper drivers.  The faster core would take care of USB and interrupts, including end-stop state changes, and trace Bézier curves to produce the correct step order sequence, as well as the approximate velocity along that axis at each step. The slower core would run hard realtime, and emit the steps at the correct intervals per the interstep velocity.  For Cartesian configurations, it'd allow true curve paths with very quiet operation.  The order (and direction) of each step determines the actual path, the intervals the velocity, acceleration, and jerk. Right now, I can implement the faster core on a Linux machine, and transfer the step-velocity data via USB no problem, but the interrupts cause timing jitter I'd rather avoid.  Obviously, this is just a slow-burn hobbyist research project, so I want to use cheap existing development modules to find out if it works well enough in practice.

[nctnico]

The interrupt jitter can be avoided by making the stepper driver interrupt a higher priority one. The ARM Cortex M cores support nested interrupts so you can interrupt an interrupt routine. The only limit is the total number of CPU cycles you have available.

[tggzzz]

The interrupt jitter can be avoided by making the stepper driver interrupt a higher priority one.

That might work for one interrupt source, but what if you have several "high prioriry" sources.

So, rather than "avoided", don't you mean "reduced"? Optionally with "to an acceptable degree"?

[SiliconWizard]

The H755 has a Nucleo board, and it's $29.

https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html#sample-and-buy

The only distributor, Arrow, tells me "This product is currently not available for order on arrow.com".

Damn. AVNET had like 5 boards available a couple hours ago: https://www.avnet.com/shop/emea/products/stmicroelectronics/nucleo-h755zi-q-3074457345641678914/
looks like the online store is currently having a problem though...

ST is playing tease with those new boards it seems.

[nctnico]

The interrupt jitter can be avoided by making the stepper driver interrupt a higher priority one.

That might work for one interrupt source, but what if you have several "high prioriry" sources.

So, rather than "avoided", don't you mean "reduced"? Optionally with "to an acceptable degree"?

No. I mean avoided. In the end you have a limited number of X cycles you can divide over Y processes. By design you assign an amount of resources to each process. So if you have various high priority tasks you make sure that -by design- each task can be handled in time. This design process doesn't involve any 'what if' fiction. I have various projects/products which do exactly this (multiple realtime tasks).

[Nominal Animal]

The interrupt jitter can be avoided by making the stepper driver interrupt a higher priority one.

Interesting!  I haven't checked yet which of the microcontrollers I already have allow a timer interrupt to have a higher priority than some of the hardware-related interrupts, but if they do, this is an excellent option.  I admit, in my stupidity/newbieness, I kind of assumed the interrupt priorities were fixed, not adjustable.

(Trinamic TMS2209 have the nice feature that the STEP/DIR interface supports level change as the STEP trigger, meaning that the STEP output pin only needs to change state once per step.  For typical stepper drivers, you need two state changes.)

The microcontroller I'm most comfortable with is an NXP Kinetis K20 (Teensy 3.2, 72 MHz Cortex-M4), which seems to support 16 priority levels without any restrictions I can immediately find. 

I recently got a couple of NXP i.MX RT1062 (Teensy 4, 600 MHz Cortex-M7), but like the i.MX RT1170 on the topic at hand, RT1062 is a "crossover processor" with lots of peripherals, and the complexity of a full computer processor. It too seems to support 16 priority levels, according to the datasheets nested vectored interrupt controller description, but I am not sure what kind of latencies the other subsystems may cause; it is a complex beast.  The higher clock rate does mean that even if there are some unavoidably higher-priority interrupt sources or other sources of unexpected latencies, they should be short enough to not matter much.

[jhpadjustable]

The actual use case I have in mind, is a dual-core microcontroller that could control three or four TMC2209 stepper drivers.

Isn't that what timer/counter hardware is for?

I know that many STM32 timer registers can be reloaded by DMA on request of several selectable timer events, which is great if you have enough lead time to buffer them up. Maybe the Kinetis has similar capabilities?

[Siwastaja]

Interrupt jitter is a total non-issue for motor control, on any modern ARM Cortex anything, I would dare to say even including Cortex-M0, maybe excluding some very special high-tech micromachining applications. Maximum current change rate defined by motor inductance, and physical inertia are orders of magnitude more.

Interrupt priorization is trivial, and we are talking about tens of nanoseconds of jitter, in systems which need to be controlled at ~ tens to hundreds of microseconds intervals.

A typical case is that the timer hardware controls PWM, handles sudden overcurrent events, and the interrupt is triggered once per PWM cycle, or say, 20 kHz.

I have actually never seen a problem with interrupt latency nor jitter, even when designing software-defined DC/DC converters, with 10-20x higher switching frequency. That's why the dedicated peripherals exist - you won't bit-bang control signals in an interrupt.

I do see the theoretical appeal of the XMOS systems, but I have never encountered an actual use case, yet. When I do, I'll be happy to try them out.

My latest large project is something that the XMOS architecture would handle quite poorly. A lot of theoretical combined MIPS, but I would hit the classical problems of parallelization, trying to force such homogenous architecture, where every single core is relatively low-performance.

A single-core Cortex-M7 MCU seems to be a good match for such a heterogenous project:
* 1st priority interrupt, pre-empting everything else, safety shutdowns everything from multiple peripheral trigger sources,
* 2nd priority interrupt runs a 250kHz software DC/DC dual-phase buck converter feedback control loop
* 3rd priority interrupts run two separate 20kHz 3-phase BLDC motor control loops
* 4rd priority interrupts control the state machine to configure DMA and control readout of 18 (!) MEMS inertial measurement devices, in a matrix of three shared SPI buses and six shared chip select lines, each producing data at 1kHz.
* Said 4rd priority interrupt demotes its priority by calling a software interrupt whenever the inertial data has been collected to run a 250Hz motion estimation control loop
* Finally, 3D time-of-flight cameras are triggered by free-running code, their data is compensated with sensor calibration data, lens blur and flare compensation model (basically combinations of small convolution kernel, box blur, and some lookup tables) is ran, and data is converted to point clouds for motion planning.

All the interrupts take about 5% of the CPU, or about 30% when the buck converter is running. The last item is computationally expensive, and requires the "oomph" of 400MHz M7, with all the algorithms running from the core-coupled RAM. And this is something which is difficult to parallelize properly, but having enough single-core performance to run the heavy algorithm from bog standard C implementation (without too much optimization tricks) shortens the development time.

I run caches disabled. All even remotely timing critical code easily fits the ITCM memory.

[tggzzz]

The interrupt jitter can be avoided by making the stepper driver interrupt a higher priority one.

That might work for one interrupt source, but what if you have several "high prioriry" sources.

So, rather than "avoided", don't you mean "reduced"? Optionally with "to an acceptable degree"?

No. I mean avoided. In the end you have a limited number of X cycles you can divide over Y processes. By design you assign an amount of resources to each process. So if you have various high priority tasks you make sure that -by design- each task can be handled in time. This design process doesn't involve any 'what if' fiction. I have various projects/products which do exactly this (multiple realtime tasks).

That looks like "reduced to an acceptable degree", which is a perfectly acceptable engineered design. I've done that too

[Siwastaja]

Your XMOS will have measurable jitter as well. Maybe in picoseconds, but it exists, if from nothing else, from analog domain.

So there is no fundamental difference whether something is reduced 10x or 1000x below acceptable limit. The result is the same.

[tggzzz]

Interrupt jitter is a total non-issue for motor control, on any modern ARM Cortex anything, I would dare to say even including Cortex-M0, maybe excluding some very special high-tech micromachining applications. Maximum current change rate defined by motor inductance, and physical inertia are orders of magnitude more.

Interrupt priorization is trivial, and we are talking about tens of nanoseconds of jitter, in systems which need to be controlled at ~ tens to hundreds of microseconds intervals.

I'm sure you are right about it not being a problem in this case.

The higher priority interrupt will cause jitter in completion of the lower priority interrupt. That may well be acceptable; fine

I do see the theoretical appeal of the XMOS systems, but I have never encountered an actual use case, yet. When I do, I'll be happy to try them out.

My latest large project is something that the XMOS architecture would handle quite poorly. A lot of theoretical combined MIPS, but I would hit the classical problems of parallelization, trying to force such homogenous architecture, where every single core is relatively low-performance.

Amdahl's law is still valid

A theoretical advantage, if any, doesn't preclude other perfectly acceptable solutions. Use a good enough tool for the job at hand.

There's still value of knowing about the advantage, so that you can make use of it where beneficial. The right tool for the job, and all that.

I run caches disabled. All even remotely timing critical code easily fits the ITCM memory.

I'm pleased to learn disabling caches is possible; it hasn't been on some of the processors I've seen in the past

[tggzzz]

Your XMOS will have measurable jitter as well. Maybe in picoseconds, but it exists, if from nothing else, from analog domain.

So there is no fundamental difference whether something is reduced 10x or 1000x below acceptable limit. The result is the same.

Drat. Got me there

The jitter cannot be less than one clock cycle; 10ns for a core, 4ns for i/o at maximum clock rate. I/O will also take some time to cross the internal interconnect fabric, but if you use the per-port timer that can be discounted.

[Siwastaja]

I run caches disabled. All even remotely timing critical code easily fits the ITCM memory.

I'm pleased to learn disabling caches is possible; it hasn't been on some of the processors I've seen in the past

AFAIK at least all STM32 MCUs - I would guess all Cortex M7 MCUs in general, as well, since the cache subsystem is from ARM, not ST - all boot with cache disabled. You have to specifically enable it. I just never do that. I sometimes do enable MMU to protect from accidental write to the instruction RAM areas.

AFAIK all relevant M7 MCUs have significant amounts of core-coupled memory as well, so I find very little use for cache. Maybe for some super massive programs that won't fit the ITCM, yet require improvement in average runtime, especially compared to running out of an external (Q)SPI flash. A large UI using a crappy, bloated UI library would likely be a good example. And quite frankly, if the program is so huge (say, 100K) that it won't fit ITCM, the average performance would be what matters, not worst case latency. If it has a timing-critical part, that would be, again, placed in the ITCM.

[tggzzz]

I run caches disabled. All even remotely timing critical code easily fits the ITCM memory.

I'm pleased to learn disabling caches is possible; it hasn't been on some of the processors I've seen in the past

AFAIK at least all STM32 MCUs - I would guess all Cortex M7 MCUs in general, as well, since the cache subsystem is from ARM, not ST - all boot with cache disabled. You have to specifically enable it. I just never do that. I sometimes do enable MMU to protect from accidental write to the instruction RAM areas.

AFAIK all relevant M7 MCUs have significant amounts of core-coupled memory as well, so I find very little use for cache. Maybe for some super massive programs that won't fit the ITCM, yet require improvement in average runtime, especially compared to running out of an external (Q)SPI flash. A large UI using a crappy, bloated UI library would likely be a good example. And quite frankly, if the program is so huge (say, 100K) that it won't fit ITCM, the average performance would be what matters, not worst case latency. If it has a timing-critical part, that would be, again, placed in the ITCM.

Can you specify that certain parts of the code and data are nailed down in ITCM/DTCM? The last processor I looked at with that ability was the i960, and that mechanism was crude!

Since 1986 there have been so many significantly different classes of ARM processor, that I've lost track of the details

[Siwastaja]

Can you specify that certain parts of the code and data are nailed down in ITCM/DTCM? The last processor I looked at with that ability was the i960, and that mechanism was crude!

Since 1986 there have been so many significantly different classes of ARM processor, that I've lost track of the details

Of course. GNU tools have no issue, and they've been the same for decades I think, and should work the same for any vendor, any CPU.

I define the ram sections in the linker script:

Code: [Select]

...
  ram_itcm   (rwx)      : ORIGIN = 0x00000000, LENGTH = 63K
  ram_vectors(rwx)      : ORIGIN = 0x0000FC00, LENGTH = 1K  /* last 1K of ITCM dedicated for relocated vector table*/
...
  rom_b1s0 (rx) : ORIGIN = 0x08000000, LENGTH = 128K
...


. = ALIGN(8);

    _TEXT_ITCM_I_BEGIN = LOADADDR(.text_itcm);

    .text_itcm :
    {
        _TEXT_ITCM_BEGIN = .;
        *(.text_itcm)
_TEXT_ITCM_END = .;
    } >ram_itcm AT>rom_b1s0


Then in C runtime initialization, before main():

Code: [Select]

uint32_t* text_itcm_begin  = (uint32_t*)&_TEXT_ITCM_BEGIN;
uint32_t* text_itcm_end    = (uint32_t*)&_TEXT_ITCM_END;
uint32_t* text_itcm_i_begin = (uint32_t*)&_TEXT_ITCM_I_BEGIN;

while(text_itcm_begin < text_itcm_end)
{
*text_itcm_begin = *text_itcm_i_begin;
text_itcm_begin++;
text_itcm_i_begin++;
}

Then the function definitions:

Code: [Select]

void __attribute__((section(".text_itcm"))) delay_us(uint32_t us)
{
...
}

I'm sure you can get the compiler to generate the startup code, and so on, but I write it myself since it's trivial. It leaves some options open, for example, if I want to boot something up really quickly, and initialize the RAM from flash later.

I think that having full control of your tools and what goes where is... easy. Easier than having to guess. Yes, need to learn the linker script syntax, but OTOH you can just copy-paste from a previous project, mostly.

[tggzzz]

I think that having full control of your tools and what goes where is... easy. Easier than having to guess. Yes, need to learn the linker script syntax, but OTOH you can just copy-paste from a previous project, mostly.

As with many things, it is "what you gain on the swings you lose on the roundabouts".

Once you are over the learning curve, being explicit is very comforting

I will say that the xCORE/xC learning curve was much shorter and sweeter than I was expecting. The datasheets and tutorials were short simple, explicit and I found zero "gotchas". Some of the ARM and GCC documentation isn't quite like that

Maybe people not used to "thinking parallel" and in terms of "events" and "messages" would find it more difficult to get started. The only stumbles I made were due to my sloppy thinking and to when it is beneficial to use the xC asynchronous message interface. Can't blame the tools for those: PEBCAK!

[coppice]

Maybe people not used to "thinking parallel" and in terms of "events" and "messages" would find it more difficult to get started.

Most people who really struggle with parallel thinking on day one never seem to get very good at it. Its something that really seems to divide people into capable and non-capable groups.

[tggzzz]

Maybe people not used to "thinking parallel" and in terms of "events" and "messages" would find it more difficult to get started.

Most people who really struggle with parallel thinking on day one never seem to get very good at it. Its something that really seems to divide people in capable and non-capable groups.

With hardware, both analogue and digital, it isn't even a question as to whether you "think parallel" from the start. Thinking sequentially only comes later, after clocks and registers are introduced.

I wonder if future software courses will gradually move over to introducting concepts that way. I'll probably be dead by then!