multicore microcontrollers - Page 1
Forum section: electronics / general

author: mikicebe
author_rank: Newbie
timestamp: August 03, 2017, 08:18:22 pm
content: 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.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 03, 2017, 09:30:04 pm
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 03, 2017, 11:25:53 pm
content: Quote from: Sal Ammoniac on August 03, 2017, 09:30:04 pmThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: August 03, 2017, 11:42:06 pm
content: 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 impressivelysmallincrease.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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: August 04, 2017, 02:25:38 pm
content: 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

author: mikicebe
author_rank: Newbie
timestamp: August 05, 2017, 09:06:26 am
content: Quote from: Sal Ammoniac on August 03, 2017, 09:30:04 pmThat 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??

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 05, 2017, 09:28:57 am
content: Quote from: mikicebe on August 05, 2017, 09:06:26 amThe 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

author: tggzzz
author_rank: Super Contributor
timestamp: August 05, 2017, 09:54:20 am
content: Quote from: mikicebe on August 05, 2017, 09:06:26 amThat's basically right, although some details will vary.Many realtime operations are conceptually FSMs like:Code: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 endOfCharacterFor 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.

author: legacy
author_rank: Super Contributor
timestamp: August 05, 2017, 02:04:06 pm
content: I believe that a "Cop0" (as the exceptions/interrupts unit is called in MIPS terminology) that allows nested interrupts is the worst caseNested 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?)

author: legacy
author_rank: Super Contributor
timestamp: August 05, 2017, 02:08:36 pm
content: Infineon has a32-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

author: legacy
author_rank: Super Contributor
timestamp: August 05, 2017, 02:09:52 pm
content: Already talked aboutAurix, thus you can see the old topic.

author: tggzzz
author_rank: Super Contributor
timestamp: August 05, 2017, 02:36:53 pm
content: Quote from: legacy on August 05, 2017, 02:04:06 pmThere'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"

author: legacy
author_rank: Super Contributor
timestamp: August 05, 2017, 04:04:44 pm
content: LOLwell 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 correctionbut 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 interruptsProbably something interesting

author: tggzzz
author_rank: Super Contributor
timestamp: August 05, 2017, 04:12:07 pm
content: Quote from: legacy on August 05, 2017, 04:04:44 pmWell, 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.

author: rstofer
author_rank: Super Contributor
timestamp: August 05, 2017, 04:50:18 pm
content: Quote from: legacy on August 05, 2017, 02:04:06 pmThe 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.htmlNote 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.

author: Cerebus
author_rank: Super Contributor
timestamp: August 05, 2017, 04:56:24 pm
content: Quote from: Sal Ammoniac on August 03, 2017, 09:30:04 pmThere's something a little disturbing about a product from "Parallax Incorporated" from those of us who remember the file "The Parallax View".

author: Jeroen3
author_rank: Super Contributor
timestamp: August 05, 2017, 05:12:36 pm
content: 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.TheiPhone motion coprocessoris 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.

author: tggzzz
author_rank: Super Contributor
timestamp: August 05, 2017, 05:28:46 pm
content: Quote from: Jeroen3 on August 05, 2017, 05:12:36 pmThat'salwaysa problem, particularly with C/C++, for the reasons explained inhttps://www.eevblog.com/forum/microcontrollers/techniques-for-writing-non-blocking-code/msg1273010/#msg1273010The software is at least as important as the hardware, and there far fewer good options. (But there are manymanymulticore hardware options!)

author: legacy
author_rank: Super Contributor
timestamp: August 05, 2017, 07:40:02 pm
content: I wonder how can guys program the Parallella/Epiphany board ...Ok, it's ARM A9 + FPGA + Epiphany, and Epiphany comes with "only" 16-cores coresnot so many, but enough to make problem to arise in a way that they can be magnifiedI 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.

author: mikicebe
author_rank: Newbie
timestamp: August 05, 2017, 08:29:21 pm
content: Yes, I can imagine it can become quite a mess when developing with chips which combine completely different hardware for each 'core'.But if the api is built well...

author: Jeroen3
author_rank: Super Contributor
timestamp: August 05, 2017, 09:11:20 pm
content: 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.

author: tggzzz
author_rank: Super Contributor
timestamp: August 06, 2017, 09:27:54 am
content: Quote from: mikicebe on August 05, 2017, 08:29:21 pmAnd 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.

author: tggzzz
author_rank: Super Contributor
timestamp: August 06, 2017, 10:15:55 am
content: Quote from: Jeroen3 on August 05, 2017, 09:11:20 pmIn 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" in1986(Smalltalk and Objective-C), and continue to use it regularly.