• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 759 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

28377D CAN register definitions

Roger Périat
Expert 2040 points

Hi all,

I'm actually creating a HAL for 28377D for our application and was wondering why TI does not deliver a header file for CAN register definition (as e.g. F2837xD_adc.h for ADC).
Instead of this, the CAN example uses the can.c in /driverlib which uses can_hw defines. This approach is different and uses BaseAddress + Offset to access the registers. The other peripherals are accessed by using a big struct / union definition as: AdcaRegs.ADCSOC0CTL.all

Did I miss something? If not, will TI deliver headers for CAN too, or will CAN be treated different? Or is this (CAN) approach the "new" approach which will be used in future for other peripherals too?

Thank you for sharing your ideas!

Best regards,

Roger

  • 0
    TI__Mastermind 30255 points
    Roger,

    The CAN on F2837x is a new CAN module for C2000 devices. Our recommended programming model for this peripheral is the driverlib style that you identified. We will also be providing more driverlib support for peripherals in the future.

    The reason we do not have the bit-field structures for this module is the bus interface behaves differently than other buss' to allow a byte peripheral to be mapped to a C28x device. Having said that, we are looking at solutions to allow the bit-field structure method as well. It will be some time before it is available as a compiler change is required to make it robust. I would suggest moving forward with the driverlib style.

    Best Regards,
    Chris
  • 0 in reply to Christopher Chiarella
    Expert 2040 points
    Thank you Chris for answering this!
    Roger