• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 536 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.

Compiler/TM4C1294KCPDT: Why char = 0x0

Genatco
Guru 55913 points
Part Number: TM4C1294KCPDT

Tool/software: TI C/C++ Compiler

Big problem converting serial received hexadecimal values via (char) into integer >65535 when compiler is changing 0x00 into 0x0. So 262144 or 0x40000 changes into 400 loosing base 16 shifted places 0x00. If we shift the sum of all 3 serial bytes (4, 0, 0) then 262144 results but any integers <65535 are then incorrect. We need the compiler to stop messing with hexadecimal zero and 255 (0xff) so NUL remains 0x00 and not being morphed to 0x0 that is base 16 being truncated.

Can we tweak (char) NULL to be 0x00 and not 0x0? we can live 0xff being 0x0 as long as the system knows the difference when instructions test for char 0xff.

  • 0
    Guru 55913 points

    Example above the outside world transmits 0x40000 into UART receiver. As you can see (yellow) that ain't what was put into C+ storage array cells. Also printed by the functions monitor (above) and confirmed via reading back of variable the array cells previously written. When NULL 0x00 is being replaced by 0x0 at the system level the outside world reality has been compromised. 

  • 0 in reply to Genatco
    TI__Guru**** 249680 points

    Unfortunately, I don't understand your problem.  Please pick one function that has this problem.  For the source file that contains this function, please follow the directions in the article How to Submit a Compiler Test Case.  In addition, please indicate the following:

    • The name of the function
    • A detailed description of how it acts now
    • A detailed description of how it should act instead

    Thanks and regards,

    -George

  • 0
    TI__Guru 72500 points

    BP101,

    I assume the screen shot you posted is the output from a TM4C129x serial port and you are expecting 00 instead of 0. Is this right? If this is the case, the problem is not the compiler changing 0x00 to 0x0 (after all, they are the same thing), it is how you format the printf (or UARTprintf). Instead of using %x for the format, use %02x. That specifies each number will be printed with a minimum of 2 characters and with the leading zero. Check your C language reference guide for more information on formatting printf output. 

  • 0 in reply to Bob Crosby
    Guru 55913 points

    Bob Crosby said:
    I assume the screen shot you posted is the output from a TM4C129x serial port and you are expecting 00 instead of 0. Is this right?

    That is only half the problem then since UARTprintf() also converts 0xff into 0x0. The 0x400 actually produces 1024 in a GUI number box so it is dropping a nibble only when 0x00 assumes a NULL occurs.  Oddly module include <stddef.h> NULL=0, perhaps your on the right path and it is module level issue and not the compiler hexadecimal default behavior. Notice too project properties ARM Hex section has several methods of array output formats and that is not set to anything at present. 

  • 0 in reply to Bob Crosby
    Guru 55913 points

    Some how UARTpritf() was modifying the buffer array cell reading it but now 0x80000 produces decimal 524288, it would not do that last night. So it's good enough for this very large integer that requires 3 hex bytes to produce.

    Thanks Bob!