Multi-core MCu's - Page 1
Forum section: electronics / general

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 25, 2013, 12:10:54 pm
content: I was looking into the Propeller 8-core (cog) MCU and found the idea of true multi tasking excellent.I was not so taken with the actual solutions of Propeller. So:Are there any other MCU's that do hardware multi-core processing?I do mean MCU's not MPU's - so I expect some built in memory and IO and around the 48-pins range (or so).It is for a R&D Robot project.Thanx,Marc

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 25, 2013, 12:15:09 pm
content: XMOS do some powerful low-cost multicore devices.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 25, 2013, 05:40:12 pm
content: XMOS looks very promising. Thanx!

author: nctnico
author_rank: Super Contributor
timestamp: April 26, 2013, 05:49:37 pm
content: NXP has some dual core ARM controllers (LPC4300 series). These also have an FPU which could make it a lot easier to do some hefty processing. Perhaps its better to use a high end board like a Beagle board. In R&D projects you might want to concentrate on the real problems first and optimise / miniaturize later.

author: flynnjs
author_rank: Contributor
timestamp: April 26, 2013, 07:39:17 pm
content: Freescale Xgate coprocessor?

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 29, 2013, 07:25:11 am
content: Quote from: nctnico on April 26, 2013, 05:49:37 pmI do agree on having a heavier board for R&D, I think you would want to keep the architecture the same (so you can use code you tested during R&D phase?). I understand that the Beagle Board runs Linux and that is not the platform I'm looking for. I'm also looking for low-cost. I am familiar with PIC and AVR...Quote from: flynnjs on April 26, 2013, 07:39:17 pmNice! Thanx.

author: ptricks
author_rank: Frequent Contributor
timestamp: April 29, 2013, 12:36:26 pm
content: MCU like PIC and AVR really don't have anything they would be doing that requires more cores. The chips are so cheap that it is easier to just add another chip for the task and programming is much easier that way too.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 29, 2013, 12:42:55 pm
content: Quote from: ptricks on April 29, 2013, 12:36:26 pmYes, that is one option that crossed my mind also - especially when I read this thread about bottom dollar MCU's. One aspect that I am not sure on is how you would coordinate these separate MCU's into doing one 'task'. With multi-core MCU's I was hoping that there would be some 'services' for that - and with XMOS and Propeller there seem to be.So how would you propose that these separate MCU's communicate to each other or a central brain?

author: ptricks
author_rank: Frequent Contributor
timestamp: April 29, 2013, 12:57:23 pm
content: Quote from: obiwanjacobi on April 29, 2013, 12:42:55 pmIt is hard to say without knowing the target application. If you wanted to sync code operation you could do it with clock signals, almost all MCU support that option. If you wanted to do it based on a task each chip was performing you could use a single pin for passing messages between the chips.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 29, 2013, 02:42:49 pm
content: Its for a R&D Robot project. The (ultimate) idea is to have modules that do their own processing that can be plug-&-play'ed into the system. Think of a single leg as module that manages its own movement of several servos/motors. Or a set of sensors as module that provide directional proximity detection. Or a video camera that interprets the video signal and fires events for certain (configurable) conditions.I figured I would have a bus running through the robot that would communicate on an (more) abstract command level. Each module would know if that command was for them or not and how to interpret that command into the specifics for that module.A central brain would coordinate the different tasks among the modules. This would be the multi-core MCU - one core for coordinating each type of sub-system (movement, sensors/feedback). But I was also planning on experimenting with running separate cores for each algorithm. So location awareness, path finding, sensor interpretation and such. But this might change once I start writing this code and experimenting with this setup.Also all these MCU's would be as small as possible.One of the safest ways to use 'multi-threading' is not to share state and use message based communication. So in that sense - using separate MCU's and a central Bus would fit just fine.Any suggestions are most welcome.

author: free_electron
author_rank: Super Contributor
timestamp: April 29, 2013, 02:54:44 pm
content: Take a small fpga and instantiate as many soft cores as you want. Some cores are really tiny

author: c4757p
author_rank: Super Contributor
timestamp: April 29, 2013, 02:56:52 pm
content: Quote from: free_electron on April 29, 2013, 02:54:44 pmI second this.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 29, 2013, 03:20:51 pm
content: I am sure that is a fine solution. Problem is that I do not have a clue about FPGA's (sort-of, kind-of know what they are, but that's about it).Steep learning curve to get started with FPGA's??I know about software writing at all levels (assembly, C/C++/C# etc).

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 29, 2013, 05:09:15 pm
content: Quote from: obiwanjacobi on April 29, 2013, 03:20:51 pmVery.FPGAs would not be a very appropriate solution for this type of problem.Multiple processors, multiple cores or multiple tasks on a sufficiently powerful single processor are all better solutions.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 29, 2013, 05:13:56 pm
content: Quote from: mikeselectricstuff on April 29, 2013, 05:09:15 pmPfjew!

author: nctnico
author_rank: Super Contributor
timestamp: April 29, 2013, 09:23:40 pm
content: Quote from: obiwanjacobi on April 29, 2013, 12:42:55 pmDo yourself a favor and don't go down this road especially when you are a beginner. Getting a multi-CPU system to work perfectly is a non-trivial task even for experienced programmers. You need mutexes and semaphores around shared data and all events between the processors happen asynchronously. Its better to run through all the tasks sequentally on one fast CPU. Maybe have 2 threads. One for real-time signal processing and one for generic control.Over the years I've made quite some money cleaning up multi-microcontroller messes and re-designing products (some with up to 13 PICs). IMHO 'if you only have a hammer then everything looks like a nail' seems to apply to you. If PIC & AVR run out of breath you have to move to ARM. Actually you can use the Beagle board and re-use the code on a smaller controller later. Just stick with GCC. I often write & test code on a PC and then use it in a microcontroller project. Debugging on a PC is so much easier and for many projects you don't even need the hardware in the loop. Even better, you can replace the hardware with a simulation which takes the system to the limits so you can check for filter performance, loop stability, etc.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 29, 2013, 10:13:39 pm
content: Quote from: nctnico on April 29, 2013, 09:23:40 pmSo, what is in your experience the most common pitfall and how do you repair these designs?Quote from: nctnico on April 29, 2013, 09:23:40 pmMe too. I write Unit Tests to exercise the code on the PC. What do you use for simulation?

author: MacAttak
author_rank: Unknown
timestamp: April 30, 2013, 12:05:19 am
content: Quote from: obiwanjacobi on April 29, 2013, 10:13:39 pmHonestly, the most common pitfall has got to be engineers that overestimate their own capabilities and think wrongly that parallel processing was appropriate at all in the first place. They paint themselves into a corner and don't realize how deep in shit they really are until it's too late. Repair usually involves ripping all of the multicore code out and replacing it with a more efficient algorithm that does the same job without resorting to multicore.A pretty good rule of thumb: if you think it's easy then you're almost certainly doing it very wrong.That's coming from the software side of things where I spend most of my time. I guess something like nctnico where I have made a small fortune over the years from cleaning up the mess after those designs fail... only in my case it's with high-volume server and desktop applications instead of microcontroller systems. We have a rather large consulting practice that is based on mopping up this kind of mess, and clients are thrilled to pay several hundreds of dollars per hour (often for weeks or months at a time) for the service.

author: vvanders
author_rank: Regular Contributor
timestamp: April 30, 2013, 02:12:35 am
content: As someone who's built their career writing very time critical code shipping across millions of devices listen to nctnico. I've seen a lot of people go down the route of multicore looking for performance gains and inevitably they end up with worse performance due to locking contention/overhead than if they had just paid attention to cache locality and data access patterns.If you want to learn by all means go ahead, but the only functional multithreaded systems I've seen built are people with years of experience(and that doesn't even go into lock free algorithms which are another order of magnitude harder).

author: ptricks
author_rank: Frequent Contributor
timestamp: April 30, 2013, 03:57:18 am
content: Quote from: obiwanjacobi on April 29, 2013, 02:42:49 pmThis system already exist in every modern car, the system is called CAN ,that is a system where you have modules in parts of the car doing their stuff and then reporting to the main controller. When deciding if I want or need multiple cores I make the decision based on how much of the task performed will need access to the same set of peripherals. If I have MCU doing motor control I have no need for that motor control task to be part of the core controllers routines for processing video and finding a MCU to do all of those task on one chip wouldn't be the best design. In some ways you can compare it to a human body, the organs are all independent functions that only require the brain to provide signals while the brain itself doesn't perform the task, imagine a human body that consisted of all the organs consolidated in one organ with the brain still controlling, it wouldn't be good.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: April 30, 2013, 07:19:47 am
content: Thanks everybody. I understand your concerns and shouts of warning. I am an experienced programmer (20+ years) and also have experience in multi-threaded programming - although on a PC. I know assembly, C/C++/C#. I am a 'intermediate-beginner' in electronics though. But I know enough to a basic robot going.The R&D part of this project is to see if I can build a system that is 'plug & play'. I thought that having modules with on-board intelligence connected to a Bus would be a good place to start. Think of these modules as separately sold products with which you can 'assemble' a robot of your own design. So I already have multiple MCU's. Another part of this project is to see if and how distributed intelligence might work. To develop a 'language' that all modules can understand and expresses the problem domain of the robot (control, feedback, interpretation etc).I like the analogy with the human body. It also fits better with the modular concept I seems to be heading to. So perhaps the multi-core MCU will not make it into the design after all. (sorry)PS: I know about I2C, SPI and CAN busses etc. Thanx

author: nctnico
author_rank: Super Contributor
timestamp: April 30, 2013, 07:07:20 pm
content: Quote from: obiwanjacobi on April 29, 2013, 10:13:39 pmUsually its thinking a PIC is suitable for anythingMore serious: the biggest problem is the asynchronous nature of processes running on seperate controllers. That really confuses people. In general its nice to be able to divide a problem into several seperated pieces of software but there needs to be a way to convey data between the processes. In some projects I have uses an sqlite database to share information and multi-cast network messages to send events.