SPRUHJ1I January 2013 – October 2021 TMS320F2802-Q1 , TMS320F28026-Q1 , TMS320F28026F , TMS320F28027-Q1 , TMS320F28027F , TMS320F28027F-Q1 , TMS320F28052-Q1 , TMS320F28052F , TMS320F28052F-Q1 , TMS320F28052M , TMS320F28052M-Q1 , TMS320F28054-Q1 , TMS320F28054F , TMS320F28054F-Q1 , TMS320F28054M , TMS320F28054M-Q1 , TMS320F2806-Q1 , TMS320F28062-Q1 , TMS320F28062F , TMS320F28062F-Q1 , TMS320F28068F , TMS320F28068M , TMS320F28069-Q1 , TMS320F28069F , TMS320F28069F-Q1 , TMS320F28069M , TMS320F28069M-Q1
Even though the entire InstaSPIN library is executed from ROM, there are a few functions that need to be loaded and run from users' memory. These functions are the interface from the library to the hardware peripherals, as shown in Figure 9-1. All functions related to the driver object (HAL_Obj) interface to the hardware and need to be placed in user's memory. The performance data will depend on where these user's functions are implemented. This section shows performance data when all users' functions are placed and run out of RAM.
From a CPU performance standpoint, loading and executing users' functions from RAM presents the biggest advantage since RAM does not require wait states. On the other hand, loading users' functions to RAM consumes volatile memory space, so users would have to consider total available RAM for variables. The stack utilization and pins used by the library is independent of where the users' code resides, RAM or FLASH.