Compiler/TMS320F28388D: SFO v8 index library usage

Hi,

Pierre Bouchet1 said:

Why are there different lib files depending on the Bit-field vs Driverlib approach? Since they are compiled libraries why does it matter how it was implemented? 

We have different versions library for bitfield and driverlib due to implementation specific limitations. Initially bitfield version only was available which could not be used with driverlib based code.

Pierre Bouchet1 said:

I'm not familiar with the concept of an "index library". What is the "Index lib for DriverLib based SFO lib" and what do I need it for?

Index library is created to link appropriate library to a project. E.g. in case SFO we have COFF and EABI versions of the library. The index library is actually linked to the project which in turn links to appropriate library based on project configuration. For COFF based project, COFF version of library will be linked while for EABI based project, index library will link EABI version of library to the project. 

For more details on index library, refer to section 7.5 of Assembly Language Tools Guide

PFB the description from the tools guide

When several versions of a single library are available, the library information archiver can be used to
create an index library of all of the object file library versions. This index library is used in the linker in
place of a particular version of your object file library. The linker looks at the build options of the
application being linked, and uses the specified index library to determine which version of your object file
library to include in the linker. If one or more compatible libraries were found in the index library, the most
suitable compatible library is linked in for your application.

Thanks

Vasudha

Hi Vasudha,

Thank you for the information regarding index libraries.

Vasudha Bhadoria said:

We have different versions library for bitfield and driverlib due to implementation specific limitations. Initially bitfield version only was available which could not be used with driverlib based code.

Why can't the bitfield version be used with the driverlib based code in the case where it is generated with the same ABI?

Regards,

Pierre

Hi,

Pierre Bouchet1 said:

Why can't the bitfield version be used with the driverlib based code in the case where it is generated with the same ABI?

The bitfield and driverlib uses different memory addressing styles. The bitfield library can not be used without adding bitfield headers in the driverlib project.

The bitfield lib requires application code to declare below variable which is used in lib implemetation. Since driverlib uses different peripheral register addressing style, same lib cannot be used.

volatile struct EPWM_REGS *ePWM[] = {0, &EPwm1Regs, &EPwm2Regs};

Thanks

Vasudha

Vasudha,

Thank your for this information.

However:

1. Since it's just an array of pointers, couldn't you just pass it the base addresses of the register files?
2. As discussed an older thread (here) the ePWM variable is not actually used, so as long as the symbol is defined it should work fine, even if you simply declare it as an int or whatever.
3. I just went ahead and tested the driverlib version in my project where I'm not using driverlib. It works perfectly fine and the results of the calibration are identical to the results with the bitfield version.

Regards,

Pierre

Hi,

Pierre Bouchet1 said:

I just went ahead and tested the driverlib version in my project where I'm not using driverlib. It works perfectly fine and the results of the calibration are identical to the results with the bitfield version.

yes that's correct. The driverlib version of the library can be used with both bitfield and driverlib. Since the bitfield version could not be used with driverlib projects we had to add a driverlib version as well. But for maintaining backward compatibility we are providing the bitfield version as well.

Thanks

Vasudha