How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
The basic internals of the dsPIC33CH512MP508 chip on the Curiosity development board. Note that the cores can run completely independently, as each has its own program and data memories and a complete set of measurement and communication circuits. When required, the two processors can communicate with each other via ‘mailboxes’ or DMA.
In Part 1 I described using the Microchip Code Configurator (MCC) tool to create software for the dsPIC33CH dual-core microcontroller ‘Curiosity’ board (187-6209) : the two on-chip processors blinked their ‘Hello World’ messages. It’s time to get down to ‘Bare-Metal’.
Loading and running the Slave processor from FORTHdsPIC
The MCC is a great tool for getting something going: the GUI simplifies the task of setting up the many configuration bits and control registers that determine how the two processors talk to each other. There are many, many options and trying to work out what you need for a particular application from the datasheets can put you off the whole idea. Even though I planned to go down the bare-metal route, examining the files produced by the MCC enabled a much greater understanding of what had to be done. It also revealed possibilities I hadn’t thought of such as a library of Slave programs stored in the Master Flash memory, each loaded and run when required by the Master program.
Master and Slave
The two processors may be independent, but they’re sure not equal. Perhaps the terms Master and Slave are not acceptable nowadays: too many historical and not-so-historical connotations. How about Manager and Specialist? Take for example, a mobile robot application. The Specialist processes the sensory input data into a form the Manager can understand, such as obstacle located at range X and bearing Y. The Manager takes this information and makes a decision on avoidance action. It might also use this data to construct a map of the robot’s surroundings, while sending change-direction commands to the Specialist. The latter will calculate new wheel motor speeds and input these into a PID control loop which generates PWM signals that actually drive the motors. In simple terms, the Specialist processor is fast, enabling it to run these algorithms in real-time, and it possesses the bulk of the sensor/actuator interfaces. The Manager can be slower but needs a large program memory for its ‘strategic’ decision-making and supervisory functions. The dsPIC33CH is designed for just this sort of situation – see the block diagram above. I’ll now revert back to the original terminology, Master/Slave, simply to avoid unnecessary confusion when reading the product literature.
The Master memory
All the chip’s non-volatile Flash program memory is allocated to the Master: the Slave making do with volatile Program RAM or PRAM. This has a number of consequences:
- While the processors can run independently, the Slave does rely on the Master to load its PRAM with program code from Master Flash memory on power-up.
- The Master is in charge of all the Slave’s Configuration settings held in Flash memory, with all the GPIO pins defaulting to ‘ownership’ by the Master. The Configuration registers are programmed at compile/assembly time and cannot be changed by software.
- From power-up, the Slave is held in shut down until its enable flag bit SLVEN in register MSI1CON, controlled by the Master, is set. This is usually done immediately after the Master program has successfully programmed the Slave PRAM. Access to the PRAM from the Master is disabled while SLVEN is set.
- The Master can stop the Slave at any time by clearing SLVEN, thus regaining access to the PRAM. As I shall discuss later this allows re-programming of the Slave by the Master’s software ‘on-the-fly’ – a very useful feature for FORTHdsPIC.
The basic memory map for the Master processor is shown in Fig. 1. Relative to the single-core version of FORTHdsPIC, the only new features are the blocks of Flash memory allocated to Slave code. The Slave does have enough program memory, but only just adequate data RAM to run its own copy of the Forth system, allowing it to run Forth applications. I decided against shoehorning it in because the general idea is for the Slave code to run as fast as possible, requiring ‘bare-metal' coding. The ‘library’ of Slave programs begins at location 0x10000 in Flash memory, with 4Kbytes allocated to each item. Each program can actually be any size as it’s starting address is set manually in MPLAB before the overall project including Master and Slave components is assembled by XC16. The screen shot below shows the Properties window open for the main project FORTHdsPIC Curiosity.
Creating the Flash program code
Go to the Downloads section below and download the following code files:
- Configuration code for FORTHdsPIC-DC 1.0
- Assembler source code for Slave test 1 (DC_Test_S1.s)
- Assembler source code for Slave test 1 (DC_Test_S2.s)
The first task was to create a version of FORTHdsPIC_Curiosity source code containing the Master and Slave configuration data together with a new Forth word definition: LSLAVE, the Slave bootstrap loader. A Main project based on this source code was then created on MPLAB X for the device dsPIC33CH512MP508. So far, so normal. For my Hello World test program to run on the Slave, I created a short piece of assembler code to blink LED2 (GPIO RE1) on the Curiosity board. Ah, first deviation from normality: a line in the Master configuration code needs to be included giving the Slave ‘ownership’ of pin RE1. The Slave configuration code attached to the Slave program just consists of clock settings. Clock start-up code is only slightly different from the Master’s, reflecting the fact that the latter runs at 90MIPS compared to the Slave’s 100MIPS.
A new project was created formed around the source code file DC_Test_S1 and the device part number dsPIC33CH512MP508S1. It is essential that the device number with suffix S1 is selected. This project is also classified as ‘Secondary’ not ‘Main’. A second Slave project DC_Test_S2 was put together and is identical to the first, except that it blinks the LED faster(!). Its purpose was to check out the ability to switch the Slave’s function using software run on the Master.
Properties window for the Main project. To link the two Slave projects to the Main, FORTHdsPIC_Curiosity, select Secondaries Category and click on Add Secondary Project… The location addresses in Flash for each can be set here. Make sure ‘Build’ is ticked for both projects.
Slave bootstrap loader
Go to the Downloads section below and download the following code file:
- Assembler source code for LSLAVE word
When I read some of the early product literature about the dual-core dsPIC, I gained the (erroneous) impression that the bootloader for the Slave PRAM was built-in to the chip, and ran ‘automatically’ after power-up reset. Wrong. It all has to be written as part of the Master software. Frantic searching of the programming manuals revealed only two clues as how to do this: two new assembler language instruction codes ldslv and vfyslv. The former transfers a 24-bit instruction code from Flash memory to PRAM; the latter verifies that the transfer has been executed correctly. I suspected that there was more to this than simply copying a block of data from one address to another and I was right. The assembler doesn’t just write a single binary image of the Slave code to Flash memory: it breaks up the image into sections, mostly 512 instructions long, each with a header of three 16-bit words providing target PRAM address information for the bootloader. Forth word LSLAVE performs the following functions:
- Pops a 24-bit address of a Slave app stored in Master Flash memory and its ID number (between 1 and 16) from the Forth Parameter stack.
- Checks the new ID against a variable containing the ID of the last app loaded. If the app is already loaded, the program/verify code is skipped, and the Slave restarted.
- If the app is different, the ID variable is updated and a full program/verify cycle is performed.
- The VERFERR bit in the MSI1STAT register is checked to see if a verify error occurred. If set, the Slave restart code is skipped and 0 pushed onto the Parameter stack to signal the error.
- If there is no error, the Slave is restarted and -1 pushed onto the Parameter stack.
LSLAVE has been added to the FORTHdsPIC-DC system vocabulary. Minor modification would allow it to be incorporated in the software for any dsPIC33CH-based system.
Go to the Downloads section below and download the following code files:
- Forth source code for dual-core LED blink test 1 (Slave1.txt)
- Forth source code for dual-core LED blink test 2 (Slave2.txt)
We’re talking about the user’s Master program here; the one coded in Forth that runs in parallel with the Slave app. In this Hello World case, it blinks LED 1 at 1Hz. But before it does that, it executes LSLAVE and sets the Slave running its blinking LED 2 task. Notice the code that checks the load failed flag on the stack and sends an appropriate message to the user terminal.
|Master Program||Slave Program||Slave Program ID||Flash Address|
Dual-Core Operation & Development
I envisage a suite of Slave programs stored in the Flash memory, each of which can be selected and run by the Master program as required. For example, a set of real-time DSP routines such as an FFT, digital filters or even AI neural networks.
A new Slave app can be developed using the Master processor without FORTHdsPIC. As the Slaves are programmed in assembler code, all that’s needed in the way of tools are the MPLAB X IDE and XC16 assembler/compiler. Once the code is debugged, adjustments may be made for Slave operation such as introducing code to operate the inter-processor MSI interface. The whole FORTHdsPIC_Curiosity project is then rebuilt including the new Slave project, and the code Flashed into program memory. Master programs in Forth can be run in RAM during development and then moved to Flash to make the system truly ‘embedded’, that is, operational from power-up.
Next time in Part 3
The next item on the agenda is inter-processor communication via the MSI hardware. There aren’t many dual-core applications that don’t need an exchange of data between the processors!
Microchip application note: AN2721 Getting Started with Dual Core
Microchip dsPIC33CH MSI manual: Master Slave Interface (MSI) Module
Microchip manual DS70595C: Section 3. Data Memory
If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues. To see my back catalogue of recent DesignSpark blog posts type “billsblog” into the Search box above.