Author Topic: multicore microcontrollers  (Read 6316 times)

0 Members and 3 Guests are viewing this topic.

Offline mikicebeTopic starter

  • Newbie
  • Posts: 5
  • Country: sk
multicore microcontrollers
« on: August 03, 2017, 08:18:22 pm »
Hi,

I've been looking at some microcontrollers and came across multicore microcontrollers such as Xcore-200, Propeller... I have never used any of these and haven't seen any of them being implemented much. It's probably because a dedicated DSP or some other digital system is probably more powerful replacement if computational power is needed, and it is probably easier to implement, has more support, is cheaper and so on... Still I was wondering what's the general opinion on them, whether someone used them and has some more insight, and why you see them so little. I'm sure there are some projects where these would be a good fit and running multiple threads in a huge embedded system sounds interesting.  8)
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1738
  • Country: us
Re: multicore microcontrollers
« Reply #1 on: August 03, 2017, 09:30:04 pm »
I've used the Propeller. It's an interesting architecture with eight independent 32-bit CPU cores called "cogs". Each cog has 2K of local RAM and can access 32K of RAM shared by all of the cogs. Access to the shared RAM is by a round-robin mechanism called the hub where each cog gets one shot at the shared RAM every eight cycles of the hub.

The original high-level language is called Spin, although they now support C. Spin is an interpreted language and the interpreter itself is stored in ROM on the chip and can be loaded into RAM and executed on any of the eight cogs. The interpreter fetches tokenized Spin instructions out of shared RAM, so the largest program has to fit in the 32K of shared RAM. You can also write code in PASM assembly language that runs natively on the cogs (and much faster than Spin).

The propeller has no interrupts and no built-in peripherals. There are 32 I/O ports and peripherals such as UARTS, I2C, and SPI are implemented in software on one or more cogs. Parallax maintains a library of company-written and third-party components that implement most of the common peripherals. High-speed peripherals, such as Ethernet and USB, are not possible.
"That's not even wrong" -- Wolfgang Pauli
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13818
  • Country: gb
    • Mike's Electric Stuff
Re: multicore microcontrollers
« Reply #2 on: August 03, 2017, 11:25:53 pm »
The propeller has no interrupts and no built-in peripherals. There are 32 I/O ports and peripherals such as UARTS, I2C, and SPI are implemented in software on one or more cogs. Parallax maintains a library of company-written and third-party components that implement most of the common peripherals. High-speed peripherals, such as Ethernet and USB, are not possible.
The XMOS devices use a similar concept, but much faster, so they can do usb,ethernet etc. as software peripherals. They use a version of C with extensions to support the parallelism.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #3 on: August 03, 2017, 11:42:06 pm »
I am not an xCORE/xC expert by any means, since I have only been using them for a couple of months. Their strengths and weaknesses can be understood and predicted from the architecture documents on the website.

I found them very easy to use for my purpose, with an excellent development environment. I was demonstrating proof-of-principle code within 1-2 days of starting. Once I had understood the tools and what they were telling me, and then tweaked my code, I increased the speed by a factor of 2 - which I regard as an impressively small increase.

The company has been around for a decade, appears well funded, and the technology is based on concepts that have been tried and validated since the 70s (CSP) and 80s (Transputer/Occam). CSP has been extremely influential - and continues to be influential since its concepts are appearing in modern languages such as Go.

The StartKit costs ~£12 (Digikey, Farnell), the dev tools are free.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1913
  • Country: ca
Re: multicore microcontrollers
« Reply #4 on: August 04, 2017, 02:25:38 pm »
I have used LPC43XX parts, they have 2 or 3 cores, any they are Cortex M, with fantastic peripherals, and lots of good software for them. :)

try to stick to ARM, because your choices would be wast
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline mikicebeTopic starter

  • Newbie
  • Posts: 5
  • Country: sk
Re: multicore microcontrollers
« Reply #5 on: August 05, 2017, 09:06:26 am »
The propeller has no interrupts and no built-in peripherals.

That confuses me, no interrupts. I thought of each core as if it was a individual microcontroller with all of the same concepts (interrupts, timers, ect..), where on each I could run a single sequence of code and pass data between the cores. I guess there's a different way how I should comprehend this??
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13818
  • Country: gb
    • Mike's Electric Stuff
Re: multicore microcontrollers
« Reply #6 on: August 05, 2017, 09:28:57 am »
The propeller has no interrupts and no built-in peripherals.

That confuses me, no interrupts.
The idea is that instead of interrupting the flow of code on a single core, you have a dedicated core to handle the time-critical tasks
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #7 on: August 05, 2017, 09:54:20 am »
The propeller has no interrupts and no built-in peripherals.

That confuses me, no interrupts. I thought of each core as if it was a individual microcontroller with all of the same concepts (interrupts, timers, ect..), where on each I could run a single sequence of code and pass data between the cores. I guess there's a different way how I should comprehend this??

That's basically right, although some details will vary.

Many realtime operations are conceptually FSMs like:
Code: [Select]
task() {
    initialSetup();
    while (1){
        event = waitUntilEvent();
        switch (event) {
            case eventX:
                    doSomethingX();
                    break;
            case eventY:
                    doSomethingY();
                    break;
        }
    }
}

For a UART eventX might be bitReceived and eventY might be endOfCharacter
For a telephone exchange eventX might be receiverLifted and eventY might be numberReceived.
And events can also be messages from other cores.

If you only have a single core then typically bitReceived might be a hardware line that causes an interrupt, an ISR creates the event and puts it in a queue then ISR returns, finally the event is"picked up" from the queue by the waitForEvent() function.

Without interrupts there is no ISR and no queue; the waitForEvent function simply spinloops looking at the bitReceived and endOfCharacter inputs. When either occurs the function returns and processing continues. The spinloop tends to implies that each core is dedicated to a single peripheral, but that need not be the case in practice.

In some devices the spinloop might not even be a loop; the core might sleep until an event occurs - but that is merely a power consumption optimisation.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: multicore microcontrollers
« Reply #8 on: August 05, 2017, 02:04:06 pm »
I believe that a "Cop0" (as the exceptions/interrupts unit is called in MIPS terminology) that allows nested interrupts is the worst case

Nested means:
you are inside an interrupt service routing, another interrupt happens, and you want to serve it, thus you suspend the current ISR, and you to go the next (and so on?  :palm: :palm: :palm: )
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: multicore microcontrollers
« Reply #9 on: August 05, 2017, 02:08:36 pm »
Infineon has a 32-bit multi-core TriCore™. Yes, three cores inside the chip. It's used in automotive, and there is an arduino-like board to experiment.

I don't like Infineon, I just want to give you the news  :D
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: multicore microcontrollers
« Reply #10 on: August 05, 2017, 02:09:52 pm »
Already talked about Aurix, thus you can see the old topic.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #11 on: August 05, 2017, 02:36:53 pm »
I believe that a "Cop0" (as the exceptions/interrupts unit is called in MIPS terminology) that allows nested interrupts is the worst case

There's an argument to the effect that if you are going to use interrupts you might as well "go the whole hog" and "you might as well be hanged for a sheep as a lamb" :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: multicore microcontrollers
« Reply #12 on: August 05, 2017, 04:04:44 pm »
LOL  :-DD

well on old MIPS ... pipelined-R3K (so, everything is older than MIPS32) has also a strange behavior if interrupts happen during a branch: PC is saved into EPC, but sometimes you are not sure if it points to the next instructions (PC+=4) or to the current instruction (PC+=0) since the pipeline was interrupted on a delayed slot to serve the Cop0. To know if you have to correct the returning address ... you have to check a cop0's register in order to know if you have to apply/not-apply the correction

but if you have already enabled the interrupt and there is a cache miss in the meanwhile ... something magic happens and the control of the whole core is lost into arbitrary path.

Thus, you can understand that is an hardware problem due to the nature of the pipeline. Of course it's an implementation problem, solved in modern chips, paying with more complexity ...  but, I still wonder what would happen if we made the cop0 allowed to have nested interrupts

Probably something interesting  :D


« Last Edit: August 05, 2017, 04:06:30 pm by legacy »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #13 on: August 05, 2017, 04:12:07 pm »
LOL  :-DD

well on old MIPS ... pipelined-R3K (so, everything is older than MIPS32) has also a strange behavior if interrupts happen during a branch: PC is saved into EPC, but sometimes you are not sure if it points to the next instructions (PC+=4) or to the current instruction (PC+=0) since the pipeline was interrupted on a delayed slot to serve the Cop0. To know if you have to correct the returning address ... you have to check a cop0's register in order to know if you have to apply/not-apply the correction

but if you have already enabled the interrupt and there is a cache miss in the meanwhile ... something magic happens and the control of the whole core is lost into arbitrary path.

Thus, you can understand that is an hardware problem due to the nature of the pipeline. Of course it's an implementation problem, solved in modern chips, paying with more complexity ...  so, I wonder what would happen if we made the cop0 allowed to have nested interrupts

Probably something interesting  :D

Well, if you are interested in a high probability of bveing hanged, consider a page fault during an operand fetch, causing a TLB miss, and while fetching the TLB entry a page fault occurs. And then there are ECC errors and fixups, or page faults while saving the internal state during entry to an ISR.

Oh, the fun and games you can have with multi-word instructions on big iron machines. How we laughed trying to replicate and isolate those.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9906
  • Country: us
Re: multicore microcontrollers
« Reply #14 on: August 05, 2017, 04:50:18 pm »
I believe that a "Cop0" (as the exceptions/interrupts unit is called in MIPS terminology) that allows nested interrupts is the worst case

Nested means:
you are inside an interrupt service routing, another interrupt happens, and you want to serve it, thus you suspend the current ISR, and you to go the next (and so on?  :palm: :palm: :palm: )

The IBM 1130 had nested interrupts whereby a higher priority interrupt could interrupt a lower priority interrupt.  No big deal...  The interesting thing about that CPU is that there is no capability of globally disabling or enabling interrupts.  They are always enabled.  And there was no stack!  The return address was stored in the first word of the called routine.  Reentrant, it wasn't!

They had to use nested interrupts because the card reader is moving the card.  Either the column is read at the proper time or it is missed.  AFAIK, there was no FIFO buffering of the card reader for this low end machine.

My first love was similar to this:
http://computermuseum.informatik.uni-stuttgart.de/dev/ibm1130/ibm1130.html

Note the plotter and then consider AC circuit analysis and Bode' plots.  The system I used had the IBM Electronics Circuit Analysis Program (ECAP).  This was quite helpful to a struggling student.
 

Offline Cerebus

  • Super Contributor
  • ***
  • Posts: 10576
  • Country: gb
Re: multicore microcontrollers
« Reply #15 on: August 05, 2017, 04:56:24 pm »
I've used the Propeller.

There's something a little disturbing about a product from "Parallax Incorporated" from those of us who remember the file "The Parallax View".
Anybody got a syringe I can use to squeeze the magic smoke back into this?
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4090
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: multicore microcontrollers
« Reply #16 on: August 05, 2017, 05:12:36 pm »
I've used the LPC43xx, it has a Cortex M4 and upt to 2 Cortex M0's, at 200 MHz.
A Cortex M0 at 200 MHz basically becomes hardware. You offload all your data hauling to it. And it's the one you keep active in low power mode.

The iPhone motion coprocessor is based on this chip.

Developing for these chips is a bit tricky though, since they are two completely separate cores. Keeping things synchronized requires some effort.
Debugging is also complicated. But I was able to start two keil debug sessions on the thing with an ULink pro, and a J-Link Pro.
« Last Edit: August 05, 2017, 05:16:35 pm by Jeroen3 »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #17 on: August 05, 2017, 05:28:46 pm »
Developing for these chips is a bit tricky though, since they are two completely separate cores. Keeping things synchronized requires some effort.

That's always a problem, particularly with C/C++, for the reasons explained in https://www.eevblog.com/forum/microcontrollers/techniques-for-writing-non-blocking-code/msg1273010/#msg1273010

The software is at least as important as the hardware, and there far fewer good options. (But there are many many multicore hardware options!)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: multicore microcontrollers
« Reply #18 on: August 05, 2017, 07:40:02 pm »


I wonder how can guys program the Parallella/Epiphany board ...

Ok, it's ARM A9 + FPGA + Epiphany, and Epiphany comes with "only" 16-cores cores
not so many, but enough to make problem to arise in a way that they can be magnified  :-//

I am afraid that "legacy" code written in non-concurrent languages is actually "solving the wrong problem".

All begins, in my mind, when I think that one of the SDKs is written in C, but C and C++ are not good at concurrency. I still have to read the documentation, btw.
 

Offline mikicebeTopic starter

  • Newbie
  • Posts: 5
  • Country: sk
Re: multicore microcontrollers
« Reply #19 on: August 05, 2017, 08:29:21 pm »
Yes, I can imagine it can become quite a mess when developing with chips which combine completely different hardware for each 'core'. :scared: But if the api is built well...
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4090
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: multicore microcontrollers
« Reply #20 on: August 05, 2017, 09:11:20 pm »
Object oriented programming should make multi-core embedded software design a bit easier. But you still have to design with the cores from the start.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #21 on: August 06, 2017, 09:27:54 am »
Yes, I can imagine it can become quite a mess when developing with chips which combine completely different hardware for each 'core'. :scared: But if the api is built well...

And what if, as is the case with C/C++, the API is a castle built on sand?

Many smart people have tried this over the decades. Well-chosen applications work well, but there's no sign of a general purpose way of using such devices.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19926
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: multicore microcontrollers
« Reply #22 on: August 06, 2017, 10:15:55 am »
Object oriented programming should make multi-core embedded software design a bit easier. But you still have to design with the cores from the start.

In the context of real-time systems, object-oriented programming is merely syntactic sugar: it changes nothing whatsoever. You have to look at the hardware+software technologies that execute the OOP/OOD programs.

Bear in mind that I have was a very easy convert to the OOP/OOD "cause" in 1986 (Smalltalk and Objective-C), and continue to use it regularly.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf