TI Example with Beckhoff Slave Sample Code (type incompatibility)


I use the AM335x SYSBIOS Industrial SDK V1.00.00.03.

To read and write to the ESC (PRU-ICCS) there are some functions defined like the "HW_EscReadIsr()". This function is called from the Beckhoff Slave Sample Code e.g. for PDO_OutputMapping. Now there is some discrepancy for the used pointer type of data source. In the file "tieschw.c" the function is implemented with UINT8* but the Slave Sample Code calls it with MEM_ADDR* type as defined in the Slave Sample Code Application guide from Beckhoff. MEM_ADDR is defined as UINT16.

Any idea why this is done that way?

Code does compile but shows up some incompatible type warnings.


  • Hi,

    In ecat_def.h - we do not select CONTROLLER_32BIT or CONTROLLER_16BIT - this implies MEM_ADDR is defined as UINT8. Did you use ecat_def.h from SDK v1.00.00.03?

  • In reply to PratheeshGangadhar:


    Sorry - the above comment applies to SDK v1.00.00.04 which will be live in couple of days time. So this was an issue which got fixed in upcoming SDK release.

  • In reply to PratheeshGangadhar:


    I have used the ecat_def.h file from the Beckhoff Slave Stack Sample Code patched with the patch from TI (TI_ECAT.patch, SDK V1.00.00.03). "CONTROLLER_16BIT" is set to "1". And therefore "MEM_ADDR" is set to UINT16.
    Should "CONTROLLER_16BIT" be set to "0"? (But Controller is 16Bit isn't it? Is ESC access 8Bit?)

    "HW_EscRead()" should handle the pointer as it has to be (i.e. type cast) but function prototype should be "HW_EscRead(MEM_ADDR *pData, ....)"?

    I'm a bit confused...

  • In reply to Pruf:

    For SDK v1.00.00.03 - please use the ecat_def.h obtained after patching. This leads to type cast warning, however won't affect any functionality. This warning is fixed in newer SDK.

    Here controller is 32-bit (Cortex-A8) and access to ESC is possible in 32/16/8 bit data. TI ESC HAL code (tiescbsp/hw.c) currently does not support 32-bit/16-bit accesses for ESC register access for simpler handling. So in the latest version it is decided to use 8-bit mode to remove typecast warnings and confusion.

    When we support CONTROLLER_32BIT/16BIT and ESC_32BIT_ACCESS/ESC_16BIT_ACCESS - I agree that function prototype needs to be updated to use MEM_ADDR* for pData.

    Thanks for the feedback.