Microchip Introduces New Line of Microcontrollers with Dual Core Functionality: The dsPIC33CH Family
The Dual Core Problem
Designing monitoring systems can be difficult when other code also needs to run alongside them, such as graphical user interface (GUI) handling or power control for a motor.
Usually, a monitoring system’s job is to take measurements (speed, voltage, current, etc.), and then relay this information to a handler that determines if these measurements fall outside the expected range. In non-critical situations, this is not an issue—but if the monitoring system was, for example, monitoring a high-powered motor that could cause serious injury, then it would be idea if the monitoring process could be run independently.
This is when dual core systems become beneficial as they can run two processes concurrently with neither process interfering with the other. Well, until they both need to access memory.
Dual cores are great… until they want to use the same resource
Monitoring slow changing data is very easy to handle—but if a signal in the hundreds of kilohertz is being monitored then there is a good chance that the monitoring process needs to access shared RAM often. If the other core is running a GUI then there will be a chance of a bus collision (when both processes want to use RAM at the same time), and so the processor will decide which process should get access. This could lead to the possibility of the monitoring process being suspended which is not an ideal situation.
Dual tasking environments are also tricky when different teams of engineers are assigned to design processes that run on the same core. The first issue is that all code for the processor needs to be gathered in one location and compiled together as all the code will be located in the same memory space. This also causes potential issues with memory collision where the two teams write assembler routines (time critical situations are often handled in assembler) which both use the same RAM register locations.
Of course, the two teams could work in the same room asking each other what they are planning to use and how it will fit together—but anyone who has ever worked in such an environment will know that communication is very easily lost and organization can be as difficult as writing the code, itself. If each team could just pretend they are writing code on their own processor with their own peripherals and RAM / ROM then there would be no collision problems or even a need to keep in constant communication.
But this is the real world and such processors do not exist… or do they?
Introducing the dsPIC33CH family
Microchip has announced a new family of devices, the dsPIC33CH, that aims to solve this dual core problem. This new family of devices is unlike others in that each core is its own system with its own RAM, ROM, and peripherals while each core can talk to each other using Mailboxes and FIFO buffers.
However, one core is designated as the master core and operates at 90 MIPS whereas the secondary core is designated as the salve core which operates at 100 MIPS. The master core is designed to handle non-critical tasks such as GUI handling and user input whereas the slave core is designed to handle time-critical tasks such as power control, motor control, and safety monitoring.
The block layout of the new dsPIC33CH series
The dsPIC33CH includes all the peripherals you would expect to see in Microchip produces with the master core including
- 4 channel PWM with a minimum time base of 250ps
- 1 ADC channel at 3.5 MSPS
- Analogue comparator
- Peripheral Trigger Generator (user programmable system that coordinates peripherals)
- Configurable Logic Cell (Combinational logic functions, flip flop, and up to 32 input sources)
- 2 I2C ports
- CAN-FD – Extension to the CAN bus for automotive systems
- 2 SPI ports
- 2 UART ports
- 2 SENT ports (single wire interface)
- Capture / Compare / PWM
The slave core has fewer communication buses (due to the fact that it is designed to monitor and control) but instead has three ADC inputs, three programmable gate arrays, and eight PWM channels. The master core has 128KB EEC flash for holding the main program, six DMA ports, and 16KB data RAM which makes it useful for running large, bulky programs whereas the slave core has 24KB of program space, two DMA ports, and 4KB of data RAM.
The dsPIC33CH family of microcontrollers could be useful in many applications with safety being key. Currently, Microchip recognizes three main areas where the microcontroller could bring huge benefits: digital power, motor control, and high-performance embedded systems.
Digital power is an area that is concerned with the use of digital systems to control and regulate power. One classic case of digital power is DC/DC buck converters which take a large somewhat unregulated DC voltage and step it down to a smaller voltage (for example, 12V to 3.3V). DC-DC converters are incredibly useful as they are really efficient (little power loss) which directly translates to cooler equipment that has a potentially longer lifespan. But DC/DC supplies are not the only digital power supply; there are also AC/DC digital power supplies.
However, these supplies have some issues that can be difficult to solve including power factor correctionbut the dsPIC33CH will not only be fast enough to control the entire system, the separate cores can work on different problems independently of each other. The master core can be used to control the output voltage from the rectified AC voltage using a switch mode power supply topology whereas the slave core can be used for power factor correction.
Example of the dsPIC33CH being used in an air condittioner – image courtesy Microchip
Motor control is one of the applications that the dsPIC33CH has been aimed at and, with the inclusion of the CAN-FD peripheral, this chip is particularly suited for automotive motor control. Motors commonly found in the automotive industry include pumps and fans—and the failure of these typically results in a broken car.
One problem that seems to be completely unaddressed is the lack of oil level sensors in cars but the dsPIC33CH could potentially be used to solve this. While a sensor cannot be submerged into the oil (if this was the solution then it would have been done already), pump power can potentially be monitored and if the pump consumes less power then it may be due to the lack of fluid in the system.
Of course, motors are not just found in the automotive industry; drones and robotics could seriously benefit from the dsPIC33CH, as well. Drones are notorious for crashing and failing (sometimes spectacularly) and the cause of this is often that one of the motors either spun too fast or not enough (which creates an imbalance in the forces created by the propellers).
The dsPIC33CH could not only be used to receive radio transmissions (as well as navigate) but the slave core could also be made to monitor each motor and make nanosecond decisions to keep the drone stable.
Possible use of the slave and master cores. Image courtesy of Microchip
But could the dsPIC33CH design be beneficial in other applications? For the answer, just look for any application that requires parallel processing where reliability is key. Even in situations where safety is not important, cores that are completely independent can be very beneficial in applications including server networking where the slave core can be used to handle incoming network connections while the master core provides a user interface and monitoring access point. Cars that integrate sensors could use the dsPIC33CH to both provide the user with a graphical user interface all while processing data from ranging sensors using the slave core.
The dsPIC33CH range of microcontrollers offers a dual core system in which the cores work independently but can still message each other to ensure that both systems are working. The inclusion of the CAN-FD bus, the programmable logic arrays, and the many peripherals ensure that this microcontroller is not missing out on any features and the fact that both cores work at 90 MIPS guarantees that current demands from technology will easily be met. But the most important aspect of this system is the relief to engineering teams when they come together at the end to seamlessly put their independently designed code onto the processor.