This is the my final blog in a series of 5 blogs for the At The Core Design Challenge. It will describe my finished design for my idea that I presented in my 1st blog post. Describes how I implemented my idea on the PSoC62S4 kit.
This blog presents the Design, code and operation of my idea running on the PSoC62S4 kit. The entire project uses only the Pioneer kit and a USB connection to a PC running Tera Term. The system is implemented using firmware on the two cores, that use the Capsense buttons, ALS and Thermistor sensors. The firmware on each core communicate with each core over IPC Pipes. The code project lives on my GitHub repo mentioned laterj in this blog.
As I've pointed out my Idea involves running A barebones piece of firmware on the CM0+ core and FreeRTOS running on the CM4 core. The who point of this challenge is to use the recently released version of Modustoolbox 3.0 to design and implement a project using the dual core new features. This was a real challenge for me but I managed to learn and am still learning about features of the Modus embedded development toolchain.
I used snippets of code from my previous blogs to implement my final design described in the next section.
FINAL DESIGN
SYSTEM DIAGRAM
DATAFLOW Description
In the system diagram, I have indicated the Data flow in two directions
- FROM M4 to M0+
- FROM M0+ to M4
- Lets follow the DATA FROM M4 to M0+
- ON M4
- The main module creates the 3 task using the RTOS scheduler.
- Priorities are set for each task.
- The Tasks communicate to each other over QUEUES by sending command messages.
- When A CAPSENSE Button is pressed:
- The CAPSENSE task determines which button is pressed. I used a lot of the same logic from the FreeRTOS section in blog#4..
- The SCAN and PROCESS functionality is implemented using a message queue to send SCAN or PROCESS messages from the task callbacks to the main loop of the task.
- in the main loop when the scan timer fires a SCAN callback is called, which places a SCAN command in the message queue.
- in the SCAN code the scan is done on all the CAPSENSE widgets.
- The scan callback sends a PROCESS command to the message queue.
- In the PROCESS code:
- Gets all the Capsense Widgets and determines which button has been pressed.
- Then, task creates two messages and sends the message to the appropriate QUEUE.
- MESSAGE1 -- contains which button (ALS(btn0) or (TEMP(btn1)) has been pressed and sends the message to the PRINT task to be printed on the terminal.
- MESSAGE2 -- contains a GET command to indicate which sensor (ALS or TEMP) to get a value from
- The PRINT task reads message queue and prints the message.
- The ENDPOINT task:
- Reads the message queue
- Pulls out the button pressed (ALS or TEMP)
- Constructs a message indicating which sensor to get the value from and calls the ipc endpoint to send the message.
- The CAPSENSE task determines which button is pressed. I used a lot of the same logic from the FreeRTOS section in blog#4..
- ON M0+
- the ENDPOINT callback
- Reads the PIPE
- interprets the message to determine which sensor to use to get a value.
- calls the appropriate sensor function to get the sensor value.
- When the data is received it follows the path described next
- Lets follow the DATA FROM M0+ to M4
-
- ON M0+
- Once the sensor value is received from the sensor function a return message with the sensor name and the value is generated.
- This message is sent to the SEND ENDPOINT
- The SEND ENDPOINT sends the message to CM4 over the Send PIPE
- ON M4
- The receive endpoint reads the message
- Constructs print message from the message contents that was just read.
- Sends the message to the print queue.
- The PRINT task reads message queue and prints the message.
The Project
PROJECT NAME: MY_Dual-CPU_GetToTheCores
The project was started by making a new application using the Semaphore template and giving it the project name mentioned above.
I added code to the M4 and M0+ projects to implement FreeRTOS, CAPSENSE, ALS &Thermistor sensors used in my design and testing blog#4.and IPC PIPES , I used code from the Migrated PIPE example project describe in Blog#3.
This a breakdown of what code is part of the firmware on each core.
On M0+:
- IPC PIPES
- Thermistor and Ambient Light Sensors
On M4:
- IPC PIPES
- FreeRTOS
- Task Scheduler
- QUEUES
- CAPSENSE BUTTONS
I then added the necessary components these using the library manager from the IDE
Now Build the Project and debug it.
The Project Code on my GitHub repo
I'm still working on the project But I thought to put the code up on my GitHub repo, instead of taking up space here on the blog. It is a work in process and your welcome to take a look at it if you have an interest.
MY_Dual-CPU_GetToTheCores
CONCLUSION
WHAT did I learn?
- Dual core programming usiing MTB 3.0
- Debugginf Dual Core Firmware using MTB 3.0
- IPC semaphores and Pips
- FreeRTOS Schedular,Queues and Timers
- CAPSENSE
- More ModusToolbox tips and tricks.
Problems I had to overcome?
- Migrating to ModusToolbox from 2.4 to 3.0
- working with multiple versions of ModusToolbox on the Same PC
- I have MTB 2.4 and MTB3.0 running on my PV
- Understanding the New Project structure for Dual Core Projects in MTB 3.0
How does MTB3.0 compare to MTB2.X??
- Dual core structure of the project allows for better debugging.
Future Enhancements
- Implement UART send receive to my my PSoC62S2 WIFI pioneer kit
BLOG#1-Introduction |
Blog#2--Design |
Blog#3- Migrating an example MTB 2.x to version 3.x |
BLOG#4-Testing |
BLOG#5-Implementation and Challenge Conclusion |
Top Comments