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.

  • Resolved

Need help converting AVR code to MSP430

Prodigy 190 points

Replies: 2

Views: 3067


I am starting a project that may require the use of an MSP430 core (due to the release of the CC430). I need to make use of an LCD screen, and I am familiar with interfacing with a serial port so the LCD that I chose was from New Haven display with the ST7565 drivers (128x64 pixels). I am using the MSP430f2618 since I had a friend with some spares and an evaluation board. I can handle the electronics end but I am having a tough time converting this example code ( produced by adafruit  to work with my MSP 430.
If anyone can help me with some tips such as how to get <avr/pgmspace.h> to either work with the MSP430 using the CCSv4 (Code Composer Studio version 4) or how to convert everything that this does in the program to something a bit more generic. If you want to be truly amazing and convert it for me can you please comment on what you changed so I can understand the process (either give a man a fish or teach him how to actually do c well).

Thanks for any feedback,
Jake G.

  • The AVR uses Harvard architecture while hte MSP uses Von-Neumann architecture.

    The main difference is that on an AVR, code and data are in two different address areas. YOu can imagine it as having only 16 bit addresses, but the fact that you're fetching code for execution or accessing data for any operation implicitely adds a 17th bit to the address. it is not possible to execute code i data ram and it is not possible to manipulate data in the code area.
    But since it is necessary to copy some initialisation data from flash to ram at typical code startup, and adding flash to the data space for this task is simply stupid, the AVRs have some spicial commands for loading data from code area into a register.

    pgmspace.h contains some macros and supplementary functions which allow defining constant data to be stored in code flash an not copied to data space at startup. When accessing these, you'll need to use special macros too, to fetch the data from code space into a register first before working with it.

    For functions such as printf, there are even special versions printf_P, since the code just gets a 16 bit pointer to the format string and does not kow whether the string is in data space or program space. so then printf_P version will assume program space and load teh format string differently.

    On MSP, code and data are in the same address space and both can be reached and manipulated with the same instructions. You can execute code in ram, and loading data doesn't care whether the source is in ram or flash (yet you cannot simply write to flash. The processor will try but fail)

    You can simply remove most of the macro wrappings which are defined in pgmspace.h from the code. Or rewrite the macros so that they just return the provided parameter.
    Some, however, may be useful to adapt, such as the PSTR() macro. Depending on the used compiler, it shall instruct the compiler to put a constant into the code segment instead of the data segment. For the program execution this makes not difference at all on MSPs (on AVRs it does), but you'll save some ram as it won't be copied from flash to ram at startup.



    would be changed to something like

    printf (({static char const __c[] __attribute__ ((__progmem__))) = ("test"); __c;}));

    in AVRGCC. So a

    #define PSTR(s) ({static char __c[] __attribute__ ((section(".text.constants"))) = (s); __c;})

    is a good replacement for MSPGCC. For CCE/IAR it must be altered to something similar.
    But then, mspgcc does this kind of optimization automatically, as it is transparent to the code on MSPs. It will, however (I tested it right now) , generate better readable assembly listing output because each of the texts will get its own label and is placed near the function calling it rather than ending up in big heap of constants. OTOH it prevents automatic joining of identical strings. A matter of taste and need. Not necessary for your project.


    Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.

    Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.
    I'm sorry that  I can no longer provide help  in the forum or by private conversation.

  • In reply to Jens-Michael Gross:

    Thanks for the response it was very informative and helped me learn a bit more about c.  I am sure this could be a solution if I wanted to solve it that way,  I simply rewrote some existing code I had to fit the LCD change in a simpler way.  So the problem is solved thanks for the help and the lesson .^^


    Thanks again,

    Jake G.

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.