Upgrading to v3.3
Upgrading to v3.3.x from v3.2.x will take some effort and this page will document the items that will need to evaluated and potentially adjusted in the application. The biggest change is the HAL implementation requiring a modification to adjust behavior to match the expected behavior of the interface in v3.3.x.
The previous version of this document was "Upgrading to v3.2" for users migrating from an earlier version (anything prior to v3.1.x). If migrating from one of these earlier versions to v3.3 one should jump right to the updated porting documentation v3.3 and skip the v3.2 migration.
The HAL interfaces have been simplified by moving device specific protocol logic from the HAL implementation and keeping it with the core library. This means the hal only has to perform the basic steps to open and configured the peripheral and then to send/receive bytes or drive the i/o line.
There are now two classes of HALs - native and protocol. Native HALs are those that do not require an additional intermediate layer for interpretation. These are assigned to the ATCAIface->hal element. HALs that perform a higher level protocol interpretation over a physical interface are assigned to the ATCAIface->hal element while the underlying physical interface is assigned to the ATCAIface->phy element. When porting the library and the target requires the use of one of the interpreted HALs the only layer that requires porting is the physical layer (e.g. the SWI_UART HAL only requires the uart hal to be ported)
See hal/README.md for more details about the new architecture
The ATCADevice structure is now a single structure that does not rely on dynamic memory elements assigned to it's elements. This means a user of the library can allocate the structure they will be using in their application statically and external to the library as long as they assign the correct configuration and hal structures.
This API has always been an internal API not meant for external use - however if it was being used then some updates have been made - due to the structures of the HALs it is no longer prudent to call the atwake, atidle, and atsleep functions directly. Since device specific logic has been moved into the library the application should instead call the atcab_wakeup, atcab_idle, atcab_sleep functions which will perform the proper operation for a given device.
Some structures and their elements had updates to reflect industry recommendations and
corporate values. All the changes other than those to the structure ATCAIfaceCfg should
be transparent to library integrations
