From Silicon Labs: Kernel 201: Instructor Application & Electron App

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 Instructor Application & Electron App and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Kernel 201 Instructor Application

The instructor application is designed to be run by the instructor of a Kernel 201 class, or in the case of someone following along this blog post, by a user. The application communicates via Proprietary Wireless with all of the Thunderboard Sense 2s running the Kernel 201 Application in a one-to-many fashion. When the instructor application sends out a command, it acts as a broadcast to all devices listening. Since the Thunderboard Sense 2s are running Dynamic Multiprotocol, it is possible the radio may be operating in Bluetooth mode when the instructor application broadcasts a message. To mitigate this, the instructor application will actually transmit out the same message multiple times in an attempt to ensure all boards receive the message. The instructor application also can receive data from all Kernel 201 Applications. This is why the Kernel 201 Application only transmits data once every 10 seconds, rather than whenever it receives commands.

Note: It is worth noting that even with the multiple broadcasts, it is still possible for a Kernel 201 Application to miss a Proprietary Wireless message. In a real-world application where missing messages is not acceptable, a basic transmit-ack scheme would help or the use of a more complex wireless stack such as SiLab’s Connect Networking Stack. For this application, in order to keep the wireless portion simpler, it is acceptable for messages to be missed.

The entire instructor application acts as a translator between the Electron App and the Proprietary Wireless stack. When a user sends a command in the Electron App, a LAB_MSG_s packet is built up in the Electron App and sent to the instructor application via serial. The instructor application then takes that data and transmits it out using the RAIL API. When data is received via Proprietary Wireless, the instructor application receives the RAIL packet and then sends the data it received via serial to the Electron App. This allows the instructor application to operate without knowing too many details about the command packets.

Proprietary Wireless Task

The Proprietary Wireless task design in the instructor application is slightly different than the Proprietary Wireless task in the Kernel 201 Application. In the instructor application the Proprietary Wireless task only handles the receive events. Transmit events are triggered by the VCOM task in the instructor application. 

1. RAIL interrupt fires and the labPropRadioEventHandler() function is called. This function determines that a packet has been received, tells RAIL to hold the packet and sends the packet pointer to the Proprietary Wireless task via a Task Message Queue to be processed.
2. The labPropRxTask() runs due to the message being received and calls labPropRadioRxData() to process the RAIL packet.
3. The function labPropRadioRxData() toggles the LED to signal a packet has been received, then it uses the RAIL Peek function to pull out the data from the packet. The use of the peek function replaces the need for a memcopy or similar to pull data from the packet. After the data has been read from the packet, the RAIL packet is released.
4. The function labVCOMTx() is called to send the data that was pulled out of the RAIL packet to the Electron App. The function then puts the data into the transmit ring buffer and triggers the VCOM transmit where it sends one byte at a time. After every byte is transmitted, the interrupt fires and if there’s more data in the ring buffer to send, the next byte is sent. If there is no more data to send, the transmit operation stops.
5. After the data was loaded into the ring buffer, the labVCOMTx() function returns while the transmit is occurring and the Proprietary Wireless task goes back to pending on the Task Message Queue.

CLICK HERE TO KEEP READING

Source: https://www.silabs.com/community/blog.entry.html/2019/08/16/kernel_201_instructorapplicationelectronapp-HHad

Looking to integrate Silicon Labs products with your design? Our Applications Engineers offer free design and technical help for your latest designs. Contact us today!