Polling wastes clock cycles when firmware has to access the sensor to read data that is discarded because the sensor reading has not updated. With multiple sensors and tasks comes multiple subroutines and interrupt routines to manage them, increasing code size. Complex code requires some form of real- time operating system (RTOS) to manage all these separate tasks. The RTOS can be a simple firmware application written by the software engineer or an off-the- shelf product. The RTOS manages the different firmware tasks to make sure each individual task starts and finishes within the time necessary for the application to operate properly. If many tasks need to be managed by the RTOS, it is beneficial for the application for tasks to finish in as few clock cycles as possible. This prevents different tasks from delaying each other. When an interrupt is received, the time it takes to complete the interrupt service routine is mostly a combination of three factors: 1. The clock cycles required to recognize the interrupt and begin to vector to the interrupt service routine. If the task is lower priority than the task that is running, this will be delayed until the present task is complete. This is application dependent
2. The clock cycles required to save the context of the present CPU state and vector to the interrupt service routine. This is architecture dependent and outside of the control of the software engineer 3. The clock cycles required to execute the interrupt service routine. This depends upon both the complexity and the efficiency of the code written by the software engineer The more efficient the firmware, the less likely a conflict will occur between tasks that need to finish within a certain period. Flash firmware update memory requirements Systems that need to be reliably updated in the field require twice the estimated flash program memory needed for the application. This is because the flash memory must be large enough to contain both the existing flash firmware and the updated firmware. However, it is common for small systems running only from internal flash program memory to halt code execution while the firmware update is being received over the network. This can be unacceptable for mission- critical applications and is contrary to the target of efficient firmware – i.e., code that is stopped is running at zero percent efficiency!
Executing firmware while updating flash A high-performance microcontroller that can execute firmware while updating the on-chip flash memory is the Microchip Technology PIC32MZ2048EFH144T-I/PH microcontroller (Figure 1). The PIC32MZ2048EFH144T-I/PH is based on the MIPS32 M-Class core architecture with a floating point unit (FPU) that targets complex interrupt-driven IoT endpoints. It has 2 megabytes (Mbytes) of program memory flash and 512 kilobytes (Kbytes) of SRAM. It also has 160 Kbytes of boot flash. The PIC32MZ2048EFH144T-I/PH core can run as fast as 252 megahertz (MHz) over a -40°C to +85°C temperature range, and at 180 MHz over -40°C to +125°C. Operating voltage is a low 2.1 volts to 3.6 volts. It has nine 32-bit capture/compare timers to support complex firmware as well as measuring external signals. External serial ports include nine UARTs and five I2C ports. There are six SPI ports that also support the audio I2S interface. A 12-bit analog-to-digital converter (ADC) with 48 inputs can measure voltages from precision analog sensors. With these many serial ports and ADC inputs, the PIC32MZ2048EFH144T-I/PH can interface with many external sensors, making it appropriate for complex sensor-based IoT
How to perform firmware updates without halting firmware execution
Written by Bill Giovino
Internet of Things (IoT) sensor- based applications are expanding, and so too is the size and complexity of the microcontroller firmware in the IoT endpoint. This firmware must become more efficient to speed execution, which is one reason flash firmware updates in the field are a necessity. However, securely updating firmware in the field usually requires halting execution of firmware while the update is in progress. Depending on the architecture, the size of the update, and network speed, this can be accomplished in as quickly as a minute or as long as an hour. For critical applications this delay can be unacceptable. This article explains the considerations for updating interrupt-driven firmware in the field and the need to keep executing application firmware while the update is in process. It then introduces the PIC32MZ2048EFH144T-I/PH
microcontroller from Microchip Technology and shows how it can be used to execute firmware while simultaneously receiving updated firmware over a network. The importance of firmware updates Firmware is updated for four main reasons: to correct bugs in the code, to add or improve features, to make adjustments to system security, and to make firmware more efficient. Code efficiency is measured by the number of clock cycles it takes to perform a specific task or thread. The fewer clock cycles to perform a task, the more efficient the code, which speeds execution and usually (not always) reduces code size. This is especially true for IoT sensor-based endpoints as these applications are interrupt-driven and so must quickly switch context whenever a sensor or peripheral generates an interrupt.
Two factors affecting the efficiency of interrupt-driven IoT applications are the efficiency of the architecture, and the efficiency of the code. While it is impractical to change the architecture of a microcontroller in the field, it is practical and normal to update the microcontroller firmware to improve efficiency. Sensor-based firmware is almost always interrupt-driven. Intelligent sensors connected to a microcontroller serial port can generate an interrupt to the microcontroller to halt normal execution so the firmware can vector to an interrupt service routine for that particular sensor. This is more efficient than sensors that need to be periodically polled to determine if the sensor reading has new data to transmit. The advantage of an interrupt- driven sensor strategy is that the microcontroller only spends clock cycles on reading the sensor when there is useful data to receive.
we get technical
50
51
Powered by FlippingBook