'Multi-core' MSP430?

Jim,

I don't know whether there's ever been a consideration for multiple cores, but it depends on what you mean I/O complexity level. Throwing another MSP430 alleviates the I/O because it has more I/O pins. However, throwing another core on the same package won't help solve that since the I/O pins are likely the same. Have you considered using I/O multiplexers that interface using SPI or another common interface? These usually work nicely as long as there are no timing issues. You're already suggesting having some SPI/I2C communications.

 

Gustavo

Can you describe what is the main reason that you want to have another core?
What type of processor are you using?

Regards,
Piotr Romaniuk, Ph.D.
ELESOFTROM

I’m speaking of timing and interrupt complexity. Obviously, to reduce the power load the MSP430 should be ‘asleep’ most of the time. If you have multiple interrupts waking the processor, ISR design and interrupt management become important.

 

However, it can be very difficult to verify that a particular design will work correctly in all possible timing/event scenarios, particularly with several asynchronous events and time epochs. In more complex cases it’s easier to partition the interrupt processing and test that (relatively) simple design thoroughly than it is to build a test environment for a single processor/interrupt structure.

Jim

Hi Jim,

In my opinion this is not rationale for second core requirement.

Jim Austin said:

If you have multiple interrupts waking the processor, ISR design and interrupt management become important.

Do you suffer from interrupts collision, that results in high latency of their handling?

Jim Austin said:

However, it can be very difficult to verify that a particular design will work correctly in all possible timing/event scenarios, particularly with several asynchronous events and time epochs.

From formal point of view, it is not only very difficult, but impossible to verify this in testing process. You cannot generate all scenarious.
You can prove it only using formal methods, but it is rather useful only for small complexity.

In practice programmer should define rules and constraints that express program correctness. Next, he should develop the firmware in the way that the rules are assured.
Of course, errors happen so further testing on many levels (static code analysis, code inspections, testing the scenarious, etc.) must be performed.
You can describe parameters of your code in min and max sense and prove it by code analysis.

If you think about reliable firmware that is not simple, you should consider using RTOS. There is a sort of standard mechanisms designed for multithread software development. Their behaviour is known and you can predict how your software will work.

According to multicore and complex software, it is better to split it into separated microcontrollers and connect by some effective interface.
Please read:
The Art of Designing Embedded Systems ISBN: 978-0-7506-8644-0
http://www.inetintel.com/embeddeddocs/EBooks/The%20Art%20of%20Designing%20Embedded%20Systems%202e.pdf

There is an interesting chapter about firmware complexity and its impact on the cost and development time. The relation is not linear but rather exponential.

When you decide to use two-MCU structure, please consider how to partition the firmware functionality. The important factor is not only the load of the core but also how many data are shared between two cores. When a lot of information is interchanged between cores you will have problem with interconnecting interface - this would be the bottle neck. This means that split a load 50:50 can be not optimal.

In such architecture you can test each part separately.

Please also remember that protocol design is very important of such design.

Regards,
Piotr Romaniuk, Ph.D.
ELESOFTROM

PS
Did you select some specific model of msp430 that yu plan to use in your design?
What clock frequency you will use? 

Jim Austin said:

Are there major obstacles?

Yes: one very important one: There´s only one bus system on MSPs. That means only one processor core can access flash at a time.
On all multiprocessor systems, each processor has a cache that no tonly decouples the need for ram access from the (usuall ymuch slower) ram, but also allows working on code/data while another core loads data from teh common storage space.
On MSPs, the cpu runs directly from flash and it usually requires only one cycle per flash/ram access. So a second core would at least halve the execution speed of each core. Since the flash can only be so fast. So a seond core would just slow down the total.
Introducing a cache to decouple the cores, would greatly incrase the power consumption and the execution tiem for each instruction. So it would move the result out of the ultra-low-power section. Also, such a cache has most of its effect from the fact that it runs by magnitudes faster than the main memory (while on MSP, the main memory is as fast as the processor already) and that it decouples the cores which require a LOT of time/cycles per instruction (on x86, an integer division is one instruction buttakes up to 49 cycles) while on MSP, the instructions are just as many cycles as there are bus accesses.

So yes, there are obstacles too large to make a dual-core MSP something to consider.

Usually, a 'clever' redesign of the software and its original concept (when not all required features were considered initially) suddenly frees up so many resources that there's space for much more.

Thanks Jens-Michael, that's the useful informed kind of response I was looking for .,,

Jim