This is a code example demonstrating the new features of the Power Board Visualizer V3 software. This demo is designed using dsPIC33AK512MPS506 Digital Power PIM.
With the introduction of new A-core devices that natively support 32-bit and 64-bit data types, including single and double precision floating point numbers, PBV had to be upgraded to handle these data types using the same underlying hardware layers as before. For more information please refer to the users guide.
This document is intended as a supplement to the user's guide. The user's guide can be found here.
- Power Board Visualizer GUI
- MPLAB® X IDE v6.25
- MPLAB® X IPE v6.25
- MPLAB® XC-DSC Compiler v3.21
- Microchip Code Configurator v5.8.2 or greater
- dsPIC33AK512MPS506 Digital Power PIM, Part-No. EV42F30A
- Digital Power Development Board, Part-No. DM330029
- Peak Systems CAN-FD USB dongle, Part-No. IPEH-004022
- Mikroelektronika Click board High Speed CAN Transceiver, Part-No. MIKROE-2334
- DB9 cable to connect the Peak Dongle to the Click board.
This section will guide the user on how to do hardware setup, program the device and run the demo.
For UART the hardware required is minimal. Along with the DP-PIM and Digital Power Development board, A USB- C cable is needed to power the Digital Power Development Board as well transfer data from DP-PIM. The DP-PIM has MCP2221A USB to UART/I2C serial converter. This means that no additional hardware is needed for UART commuincation.
Steps:
- Insert the DP-PIM to the J1 header on the Digital Power Development Board.
- Connect the microusb cable to the J3 connector on the DP-PIM
For CAN-FD additonal hardware is needed in the form of a CAN transciever and a PEAK CAN FD dongle.
Steps:
- Insert the DP-PIM to the J1 header on the Digital Power Development Board.
- Connect the microusb cable to the J3 connector on the DP-PIM or J2 connector on Digital Power Development Board.
- Insert can transciever click board on J10 connector on the Digital Power Development Board.
- Connect the CAN FD dongle using a DB9 cable to the click board.
- Open MPLAB X IPE
- Select the device on the DP-PIM: dsPIC33AK512MPS506.
- Memory Model: Single Partition
- Select the debugger/programmer.
- Connect the debugger/programmer to the J9 connector on the Digital Power Development Board
- Click on the connect button.
- You will see in the Output window your target device in the form of these two messages. o Target voltage detected. o Target device dsPIC33AK512MPS506 found.
- Go to the downloaded Folder of the demo, and select the \Hex File\PBV_V2_demo.X.hex
- Program the device.
- Wait for Program/Verify Complete message.
- Disconnect programmer from the connector.
If the Power Board Visualizer is not installed, Install the Power Board Visualizer. The setup wizard will guide through the process of installation.
Navigate to the downloaded project, and open the file gui\Power Board Visualizer Demo.xml
Click on COM? button on the bottom, and the connected devices will be listed. Select the one that is connected with your system, and the data should appear.
This section aims to describe the provided code example along with guiding the user on how to setup the peripherals using MCC
Here is the important files in the project along with brief description of the files
dspic33ak512mps-PBV-v3-dmo.X
│ main.c --> System Initialize and invokes the scheduler
│ main_tasks.c --> All processes are defined as tasks, and invoked in main_tasks.
│
├───mcc_generated_files --> These drivers are generated from MCC. Each folder represents a peripheral
│ ├───can
│ ├───crc
│ ├───system --> All system settings including clock settings and pinout macros
│ ├───timer
│ └───uart
└───sources --> All the files on top of MCC drivers/Peripheral Initialization
│ project_settings.h
│
├───app --> All the files for PBV commuincation
│ app_PBV_CAN.c
│ app_PBV_CAN.h
│ app_PBV_config.c
│ app_PBV_config.h
│ App_PBV_Demo_Frame_Map.c
│ App_PBV_Demo_Frame_Map.h
│ app_PBV_interface.c
│ app_PBV_interface.h
│ app_PBV_UART.c
│ app_PBV_UART.h
│
├───config
│ config.h --> The file where the CAN-FD or UART physical Layer can be selected
│
├───device
│ dev_led.c
│ dev_led.h
│
└───os --> A simple scheduler. All processes are defined as tasks, and invoked in main_tasks.c
os.c
os.h
os_reset.c
os_reset.h
os_scheduler.h
os_scheduler_100us.c
os_scheduler_1ms.c
os_sys_time.c
os_sys_time.h
os_timer.c
os_timer.h
os_watchdog.c
os_watchdog.h
readme.md
Open the project in MPLAB X IDE. Click on MCC button on the top Right Corner. And then you will be greeted by the following screen.
Click on each block and you will see a graphical interface on how to setup the peripheral. Pin view in the bottom shows the pin mapping. Many peripherals on the dsPIC are connected to Peripheral Pin Select(PPS) Module. PPS allows the user to connect peripheral to any device pin. Click on each Device name and the associated PLIB to see the available configurable options.
The code example is built upon a simple operating system. This operating system takes in a system tick of 100us, and defines each process as Tasks. All of the tasks are called in main_tasks.c
This code example is designed to work with UART and CAN-FD. and the option to select the underlying phsical layer is selected at compile time. By default the code example works with UART. Go to config/config.h and change the PBV_CANFD to 1 and PBV_UART to 0, and build and recompile the code.
// PBV working with CAN OR UART
#define PBV_UART 1
#define PBV_CANFD 0
The same Api works regardless of the underlying phsyical layer. The App_PBV_Demo_Frame_Map provides an example on how the driver can be used to map to a PBV frame and unframe the data.
All the files in app folder repesent different abstraction layers and files used in PBV transmission and receive
├───app
│ app_PBV_CAN.c
│ app_PBV_CAN.h
│ app_PBV_config.c
│ app_PBV_config.h
│ App_PBV_Demo_Frame_Map.c
│ App_PBV_Demo_Frame_Map.h
│ app_PBV_interface.c
│ app_PBV_interface.h
│ app_PBV_UART.c
│ app_PBV_UART.h
This is the main application file. Here there are tasks that run at different frequencies checking for any received messages and triggering sending of messages.
This provides a mechanism to abstract away the underlying physical layer by using function pointers, that point to different physical layers depending upon which layer is selected.
These implement the PBV state machine of RX and TX, as well as link data that is received by peripherals to application.
This is where the framing/deframing and transmission happens for UART frames. The fundamental difference between this and CAN-FD frames is that CAN-FD defines a strategy for framing and deframing data, and PBV follows that strategy. UART is a point to point byte by byte transfer of data. To build a frame on top of it, another layer is needed where the data is framed/deframed and trasnmitted. It defines an additional statemachine
This is a parallel file to app_PBV_UART. This abstracts the MCC driver api.
How these files stack up can be explained by following abstraction layers
The ineraction of these files as well the sequence of events in sending and receving messages can be seen in these sequence diagrams. app_PBV_CAN_UART represent app_PBV_CAN and app_PBV_UART as one entity in the diagrams to maintain uniformity.
| Event | Explaination |
|---|---|
| 1.1 | The main applications signals app PBV interface to check if there are any new messages |
| 1.2 | app PBV interface triggers app PBV CAN to check if there are any messages |
| 1.3 | app PBV CAN calls on the lower level mcc drivers to check if any new messages are received |
| 1.4-1.5 | as no new messages are received the information is propogated back |
| 1.6 | Power Board Visualizer sends a message to the embedded system |
| 1.7 | As the message is a standard CAN-FD frame, the deframing and processing is done at the mcc layer. The message is deframed and stored as bytes at mcc layer |
| 1.8-1.9 | The interface layer checks if there are any new messages |
| 1.10-1.11 | the message is linked to the main application object |
| 1.12-1.14 | the main application can then read message from the linked message and do further processing |
| Event | Explaination |
|---|---|
| 2.1-2.3 | The main applications signals app PBV interface that there is a message ready to be sent |
| 2.4-2.5 | mcc layer frames and transmits data |
| 2.6-2.7 | transmit status is propogated back to interface layer |
| 2.8-2.9 | message sent confirmation from the main application layer |
| Event | Explaination |
|---|---|
| 3.1 | The main applications signals app PBV interface to check if there are any new messages |
| 3.2 | app PBV interface triggers app PBV UART to check if there are any messages |
| 3.3 | app PBV UART calls on the lower level mcc drivers to check if any new bytes that are received |
| 3.4-3.5 | as no new messages are received the information is propogated back |
| 3.6 | Power Board Visualizer sends a message to the embedded system |
| 3.7 | the app PBV UART is informed that there is a frame that is to be processed |
| 3.8 | mcc layers stores raw bytes as per the allocated buffer |
| 3.9-12 | app PBV UART reads frame, deframes it, and stores the data |
| 3.13-3.17 | the main application can then read message from the linked message and do further processing. the message is linked to the main application object after successful read |
| Event | Explaination |
|---|---|
| 4.1-4.2 | The main applications signals app PBV interface that there is a message ready to be sent |
| 4.3 | app PBV UART frames and passes partial frame to mcc |
| 4.4 | mcc transmits the frame piecemeal |
| 4.6-4.8 | message sent confirmation from the main application layer |
These are the state machines for main application transmitting and receiving.
As UART framing and deframing is done in seperate state machines, these two are documented.
