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.

MSP430FR5949: 20 bit data handling with MSP430 Core

Part Number: MSP430FR5949

Hi, 

I had the following customer question:

How is a 20-bit value stored in FRAM memory...  Does it require 3 bytes or 4 bytes of memory to hold a single 20-bit value? Can you pack 20-bit values end to end or are they padded somehow with 1’s or 0’s?

And how is that memory affected by an instruction for example like an increment or decrement when the value is a 20-bit value, such as decx.A? What happens to the bits that are on either side of the 20-bit value.  Or for that matter, if you copy a 20-bit value into an address location, will it overwrite data that is already there, but outside of the 20-bit range?

I dove into the reference manual and saw that we only have hardware addressing for 8 and 16 bit data, so no 'bit packing' like you can do on some ARM's.

However I got stumped on the 20 bit data and how it is handled.  In the instruction set, I see several instructions have provisions for bits 19:16.  So I thought I would ask rather than shoot from the hip on how adding and subtracting would be handled on the 430 core.  Can the ALU handle a 20 bit result and how is the result stored?

When working with 20 bit values, it is advantageous to do math on 3 8 bit values and take the speed hit, or 2 16 bit values and waste the memory?  Or is it an "it depends" question based on speed/size tradeoffs?

By the way, the customer codes in Assembly so he cares about the nuances of how the bytes are stored and added.

Thanks!  Blake

  • Hey Blake,

    The MSP430 Core can only do operations to data of 16-bits or less. The core has additional provisions for 20-bit addressing only. The opcodeX instructions are used to do the 20-bit addressing handling.

    So to handle data greater than 16-bits, typically in C you just use a long. I think the C compiler will sometimes byte pack words together when choosing compiler priority on space. This does not happen when compiling for speed however.

    If you are doing assembly, its up to the coder if they want to take a space or performance hit for handling greater than 16-bit numbers. Either way, you still have to break data down to 16-bit chunks to be processed. It might be possible to use the CPUX instructions to manipulate data, but I am not aware of anyone having experience doing this or actually doing so.
  • Blake Carpenter said:

    Part Number: MSP430FR5949

    By the way, the customer codes in Assembly so he cares about the nuances of how the bytes are stored and added.

    I am not coding in C, so I don't know how it is handled there. I am coding in assembler (like your costumer), and using 20 bits, regarding address space and/or data.

    All FRAM devices are with 20-bit CPUXv2, and have extended set of assembler instructions for handling 20-bit data. There are also 20-bit so-called address instructions that can execute in one cycle only. For example...

    add.w R5, R6  ; 16-bit adding, will execute in one cycle

    adda R5, R6   ; 20-bit adding, so-called address instruction different from addx.a, will execute in one cycle

    If for example 16-bits integer is not enough (precision/range/whatever), than it can be extended to 32-bits, where number of cycles (performance cost) will be doubled, same as program size. If 20-bits are enough (and from my experience it is not so rare) than will be almost no difference in execution speed and program size.

    There is no difference in working with registers, regarding 8/16/20 bits data. However, regarding memory, there will be some wasted space, because two words with 4-byte/double-word alignment (2 last bits in address must be zero) are used for 20-bit data. Only 20 bits from total of 32 bits will be used, where rest (unused 20-32) will have zero value.

**Attention** This is a public forum