• Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 1208 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Thoughts on register layout for the eUSCI on the MSP432

Eric Decker
Expert 1420 points
Other Parts Discussed in Thread: MSP430F5438A, MSP430F2618, MSP430F1611

This is something for the designers to think about for the future.  Please pass it on.

I've been working with various flavors of the msp430 (msp430f1611, msp430f2618, msp430f5438a) and have recently switched over to the msp432p401r.

In the course of all this work I have some thought on how the registers are layed out for the eUSCIs on the msp432 and would like to share them.  Having a different register layout (one that is more consistent) would greatly simplify what the s/w driver writers have to deal with when writing software for these modules.  

  • Avoid replication of code (important when one is supporting the code over long terms)
  • Simpler register layouts simplifies what one has to keep track of.  Now what is that register offset again?

Sameness is good, difference generates code and has to be dealt with.

Current layout:

Here is how I would have done it.  Where possible I've kept the same offset for registers that behave the same..

  • Guru 303850 points
    The MSP432 eUSCI register layout must be compatible with other MCUs with eUSCI modules.

    This not only avoids replication of code (which is important when one is supporting the code for multiple families over the long term), but also simplifies what one has to keep track of.
  • in reply to Clemens Ladisch
    Expert 1420 points

    Okay, I see you are arguing that there is benefit to maintaining consistency with other eUSCI modules.

    But why?  The code doesn't directly port.  The msp432 references everything via structures.  You can't reuse 430 code, its a completely different ISA).  The I/O system is different, etc.

    Because the module is referenced via pointers and structures, that takes care of any differences there might be in register layout between the msp432 and previous implementations.

    I really don't see how replicating the old physical layout really buys you anything.

    If you want to insist on the register layout MUST be compatible with other MCUs (which inherently are msp430s), I'd like you to explain why you think this is required.  What does it actually buy you?  How would it work?  How does that allow one to reuse code and save time?

  • in reply to Eric Decker
    Guru 303850 points

    The default header file uses CMSIS-style structures, but MSP430-compatible definitions are still available in msp432‍p401r_classic.h, which allows to reuse old code for those modules.

  • in reply to Clemens Ladisch
    Expert 1420 points

    Clemens Ladisch said:

    The default header file uses CMSIS-style structures, but MSP430-compatible definitions are still available in msp432‍p401r_classic.h, which allows to reuse old code for those modules.

    yes and there is such a file describing what the basics of the chip look like for any of the chips.  This hides what the actual details are from the code at the first level.

    If the structure of the registers is cleaned up to allow better software (such as I suggested), these changes are still hidden wrt the naming which is what the previous code needs.

    so any changes to the h/w still allow using the old code because it can be hidden by header files.  So that's orthogonal to what I originally was talking about.

    cleaning up the h/w architecture results in s/w that lays down better, is simpler, and easier to maintain because it doesn't have to deal with different ideosyncrocies that are currently there.

    now this is somewhat moot, because TI isn't going to change the current h/w.  But the point is maybe just maybe , they might clean it up in the future.  What's weird is they had a structure in the msp430f5438a that was pretty clean and symetric.  Not sure why the msp432 has it different again.

  • in reply to Eric Decker
    Guru 303850 points

    Changing the register offsets could break old code; it is perfectly valid to take the address of the first register and access the other ones with fixed offsets (see TI's driverlib). And any "cleanup" would require yet another module type (USCI → eUSCI → xUSCI?).

    Making the A/B modules more consistent would be a good thing, but apparently, this doesn't outweigh the incompatibilities and confusion it would introduce.

  • in reply to Clemens Ladisch
    TI__Guru 59221 points
    Thank you both for the feedback and discussion.

    Best Regards,
    Chris
  • in reply to Clemens Ladisch
    Expert 1420 points
    changing register offsets wouldn't break old code. Old code uses header files that correspond to those devices. New h/w would have fixed register offsets and would use a different header file that described that configuration.

    fixing things that are confusing doesn't add to confusion but rather fixes it.

    Keeping things the same when it is confusing and cause issues in the software because it might make things more confusing seems silly. just a thought.

**Attention** This is a public forum