Comments on: When is single better than multiple? http://www.embeddedinsights.com/channels/2011/03/30/when-is-single-better-than-multiple/ Shedding Light on the Hidden World of Embedded Systems Mon, 28 Jul 2014 16:18:37 -0400 hourly 1 http://wordpress.org/?v=3.0 By: G.L. @ LI http://www.embeddedinsights.com/channels/2011/03/30/when-is-single-better-than-multiple/#comment-6021 G.L. @ LI Sat, 02 Apr 2011 15:17:47 +0000 http://www.embeddedinsights.com/channels/?p=505#comment-6021 It is really depends on how sophistic of the project is. We have been designed products with DSP + microcontroller, but when more features are added to the project and more processing speed is required, it couldn't be handled by this architect, so we have to go to FPGA to do signal processing and microcontroller to do management. It is good to have RTOS used in MC, especially for multi-channel I/O management. RTOS could minimize totally response time for each channel, it is better than a big loop. The big loop MC code is only good for very simple system. It is really depends on how sophistic of the project is. We have been designed products with DSP + microcontroller, but when more features are added to the project and more processing speed is required, it couldn’t be handled by this architect, so we have to go to FPGA to do signal processing and microcontroller to do management.
It is good to have RTOS used in MC, especially for multi-channel I/O management. RTOS could minimize totally response time for each channel, it is better than a big loop. The big loop MC code is only good for very simple system.

]]> By: D.G. @ LI http://www.embeddedinsights.com/channels/2011/03/30/when-is-single-better-than-multiple/#comment-6019 D.G. @ LI Sat, 02 Apr 2011 14:41:04 +0000 http://www.embeddedinsights.com/channels/?p=505#comment-6019 This is exactly what we're examining for our current project. We previously separated DSP and microcontroller, and are looking to combine them for increased power efficiency and overall simplicity of board architecture. The questions for us will be around the cost/benefits of combining the two, partitioning our DSP software architecture so that it can be pre-empted by the RTOS for device context switches in support of UI and I/O. Our DSP previously used power management to go to sleep when not in action; we will need to do some benchmarking to compare the results when folding that functionality into an DSC. TI and Freescale have some families that combine DSP with a context-driven CPU, sometimes using floating point co-processor, sometimes not. This is exactly what we’re examining for our current project. We previously separated DSP and microcontroller, and are looking to combine them for increased power efficiency and overall simplicity of board architecture.

The questions for us will be around the cost/benefits of combining the two, partitioning our DSP software architecture so that it can be pre-empted by the RTOS for device context switches in support of UI and I/O. Our DSP previously used power management to go to sleep when not in action; we will need to do some benchmarking to compare the results when folding that functionality into an DSC.

TI and Freescale have some families that combine DSP with a context-driven CPU, sometimes using floating point co-processor, sometimes not.

]]> By: Eduardo http://www.embeddedinsights.com/channels/2011/03/30/when-is-single-better-than-multiple/#comment-5965 Eduardo Thu, 31 Mar 2011 00:02:13 +0000 http://www.embeddedinsights.com/channels/?p=505#comment-5965 I think MCU applications are so defined right now, that semiconductor vendors are putting out devices very adequately tailored to them. This, in turn, pushes design choices to those devices. Example: very small and low cost DSCs are available now to perform control functions and very little of anything else (for example, communications, maybe some buttons and lower priority comms to ASICs via IIC or SPI). Why? This makes sense in motor control, where power domains are a concern and having an apps processor do the control and other functions may pose a big hardware layout challenge. There is also the problem of distributed processing over a bigger area. In this case, a main processor with several "control slaves" is the norm, this is why smaller DSCs will frequently include CAN and UART communications interfaces. On the other hand, there are control or signal processing applications that do not have this distributed or power domain problem like controlling smaller motors, audio applications, valve control, etc. In this case bigger DSCs are a good choice, but there is also the trend of turning MCU into almost-DSC devices. A great example: the Cortex M4 core. This is an ARM microcontroller core that can easily handle an RTOS but will also do real-time processing with DSP instructions, while outputting a stream of data through the Ethernet port. It is not entirely a DSC as it lacks some of the thing that make it a "formal" DSP core, but it does have the DSP instructions, easing the big signal processing problem to a great degree. I think MCU applications are so defined right now, that semiconductor vendors are putting out devices very adequately tailored to them. This, in turn, pushes design choices to those devices. Example: very small and low cost DSCs are available now to perform control functions and very little of anything else (for example, communications, maybe some buttons and lower priority comms to ASICs via IIC or SPI). Why? This makes sense in motor control, where power domains are a concern and having an apps processor do the control and other functions may pose a big hardware layout challenge. There is also the problem of distributed processing over a bigger area. In this case, a main processor with several “control slaves” is the norm, this is why smaller DSCs will frequently include CAN and UART communications interfaces.

On the other hand, there are control or signal processing applications that do not have this distributed or power domain problem like controlling smaller motors, audio applications, valve control, etc. In this case bigger DSCs are a good choice, but there is also the trend of turning MCU into almost-DSC devices. A great example: the Cortex M4 core. This is an ARM microcontroller core that can easily handle an RTOS but will also do real-time processing with DSP instructions, while outputting a stream of data through the Ethernet port. It is not entirely a DSC as it lacks some of the thing that make it a “formal” DSP core, but it does have the DSP instructions, easing the big signal processing problem to a great degree.

]]>