If statement wird nicht ausgeführt trotz korrektem Vergleich? (TMS320F28388D)

[DenDen (Gast)]

Hallo zusammen

Auf dem Communication Manager eines TMS320F28388D führe ich den lwIP 
Stack um TCP Packete zu empfangen. Wird ein Packet empfangen kopiert die 
entsprechende Callback-Routine die Daten in einen Puffer `buffer` und 
signalisiert einer Schleife in `main()` mittels flag `command_available` 
dass es Daten zu verarbeiten gibt.

In `main()` wird dann die Routine `processCommand()` aufgerufen welche 
sich das erste Byte von `buffer` anschaut. Ich kann nicht nachvollziehen 
weshalb der if branch niemals ausgeführt wird, obwohl das erste Byte in 
`buffer` 0 ist? (s. dazu auch das angehängte Video einer Debugging 
Session).

Hier sind relevante Codeausschnitte:

void processCommand(){
    uint8_t command_code=buffer[0];
    /*
    switch(command_code){
        case STOP_ALL:
            IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                            STOP_ALL, (uint32_t)readData, 0);
            IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
            break;
        case BUCK_ENABLE_ALL:
            IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                            BUCK_ENABLE_ALL, (uint32_t)readData, 0);
            IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
            break;
        default:
            break;
    }
    */
    if(command_code==(uint8_t)(0)){
        IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                        STOP_ALL, (uint32_t)readData, 0);
        IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
        return;
    }
    else{
        IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                        STOP_ALL, (uint32_t)readData, 0);
        IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
        return;
    }
}

uint8_t buffer[512];                    //a buffer storing the last received bytes
bool command_available=false;           //indicates whether a new command has been received via TCP

[Norbert (Gast)]

Wie wird denn buffer gefüllt? Interrupt? Volatile!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

DenDen schrieb:
> kann nicht nachvollziehen weshalb der if branch niemals ausgeführt wird
Das wird der Compiler wegoptimiert haben, denn der Code macht doch beide 
Male das selbe. Oder wo müsste ich den Unterschied suchen?

[Thomas Z. (usbman)]

der Optimizer hat erkannt dass beide Zweige gleich sind

ups zu langsam

[Irgend W. (Firma: egal) (irgendwer)]

DenDen schrieb:
> Ich kann nicht nachvollziehen
> weshalb der if branch niemals ausgeführt wird, obwohl das erste Byte in
> `buffer` 0 ist?

Warum sollte das gemacht werden? Der Programmcode ist in beiden Fällen 
der gleiche. Einmal reicht. Im Zweifelsfall schau dir mal den erzeugten 
Assembercode an...

[Falk B. (falk)]

DenDen schrieb:
> uint8_t buffer[512];

Geht das auf der CPU? Die kleineren Piccolo-Brüder, die ja den gleichen 
(ähnlichen?) CPU-Kern haben, können als kleinste Einheit nur 16 Bit 
adressieren, da gibt es kein uint8_t.

[Tom (mantabit)]

Norbert schrieb:
> Wie wird denn buffer gefüllt? Interrupt? Volatile!

Hier ist die entsprechende Routine:

// TCP received callback function is called when new data was received on COMM_PORT
err_t tcp_recvd_cb(void* arg, struct tcp_pcb* tcppcb, struct pbuf* p,err_t err){
    //payload being NULL indicated that the TCP connection has been terminated
    if(p->payload==NULL||p->len==0){
        connection_active=false;
        // close the pcb
        tcp_close(tcppcb);
        // listen to new connections again
        tcp_accept(welcoming_socket_pcb,accept_cb);
        return ERR_OK;
    }
    else{
        if(err==ERR_OK){
            // -- process the data in p , p is NULL if the remote host terminated the connection --
            memcpy(buffer,p->payload,p->len);
            u16_t bytes_read=p->len;
            //indicate that a new command is available for processing in the buffer
            command_available=true;
            // -- indicate that bytes were read and we are ready to receive more data --
            tcp_recved(tcppcb,bytes_read);   //indicate that no_bytes_read were read and we are ready to receive more data
            // -- echo the received data back
            tcp_write(tcppcb,buffer,bytes_read,TCP_WRITE_FLAG_COPY);
            return ERR_OK;
        }
        else{
            //wait forever and preserve debug state
            while(1);
        }
    }
}

Lothar M. schrieb:
> DenDen schrieb:
>> kann nicht nachvollziehen weshalb der if branch niemals ausgeführt wird
> Das wird der Compiler wegoptimiert haben, denn der Code macht doch beide
> Male das selbe. Oder wo müsste ich den Unterschied suchen?

Sorry, die Routine müsste eigtl. folgendermassen lauten (die beiden 
branches sind nicht gleich):

void processCommand(){
    uint8_t command_code=buffer[0];
    /*
    switch(command_code){
        case STOP_ALL:
            IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                            STOP_ALL, (uint32_t)readData, 0);
            IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
            break;
        case BUCK_ENABLE_ALL:
            IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                            BUCK_ENABLE_ALL, (uint32_t)readData, 0);
            IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
            break;
        default:
            break;
    }
    */
    if(command_code==(uint8_t)(0)){
        IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                        STOP_ALL, (uint32_t)readData, 0);
        IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
        return;
    }
    else{
        IPC_sendCommand(IPC_CM_L_CPU1_R, IPC_FLAG0, IPC_ADDR_CORRECTION_ENABLE,
                        BUCK_ENABLE_ALL, (uint32_t)readData, 0);
        IPC_waitForAck(IPC_CM_L_CPU1_R, IPC_FLAG0);
        return;
    }
}

Das Problem bleibt leider bestehen.

[Phantomix X. (phantomix)]

Ich weiß nicht inwiefern dein Chip Ähnlichkeiten zum TMS320F2808 hat, 
mit dem hab ich damals in der Diplomarbeit gearbeitet.

Schau dir bitte mal sizeof(char) an. Beim 2808er sind das nämlich 16 
Bit, d.h. der Chip kann keine kleineren Dateneinheiten verarbeiten 
(evtl. Bits einzeln noch)

bei

uint8_t command_code=buffer[0];

könnte es also sein, dass du in Wirklichkeit 16 Bits deines Datenstromes 
in command_code speicherst (wobei ich mich dann frage, weshalb es 
überhaupt ein uint8_t gibt, das solle dann nämlich nicht definiert sein 
um solche Fehler zu vermeiden)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

DenDen B. schrieb:
> Das Problem bleibt leider bestehen.
Ich würde mir hier jetzt mal den zugehörigen vom Compiler erzeugten 
Assemblercode ansehen...

[Phantomix X. (phantomix)]

Hat der Chip ein Daten-Caching? Vielleicht hat die CPU was anderes im 
Cache als der DMA im Hintergrund vom Ethernet ins RAM geschrieben hat? 
kopfkratz

[Tom (mantabit)]

Ok, wenn ich via TCP '0000' sende befinden sich im Speicher tatsächlich 
die falschen Werte (vier mal b'00110000' stat b'00000000'), siehe auch 
Bild im Anhang.

Die Variablenvorschau in CCS zeigt allerdings 'unsigned char 0' an.

[Christian E. (cerker)]

0x0011000 = 0x30 = 48 ist der ASCII-Code von '0'.
Du sendest also "0000" als Text.

Die Variablenvorschau interpretiert wohl char als einen .. Char. Das ist 
das Zeichen '0', nicht die Zahl 0.

[Tom (mantabit)]

Christian E. schrieb:
> 0x0011000 = 0x30 = 48 ist der ASCII-Code von '0'.
> Du sendest also "0000" als Text.
>
> Die Variablenvorschau interpretiert wohl char als einen .. Char. Das ist
> das Zeichen '0', nicht die Zahl 0.

Das ist es, vielen Dank!

Der `uint8_t` wird als `unsigned char` definiert weshalb mir die 
Variablenvorschau `0` anzeigt:

#elif defined(_TMS320C6X) || defined(__ARM_ARCH) || defined(__ARP32__) || \
      defined(__PRU__)    || defined(__C7000__)
    typedef   signed char   int8_t;
    typedef unsigned char  uint8_t;
    typedef          short  int16_t;
    typedef unsigned short uint16_t;
    typedef          int    int32_t;
    typedef unsigned int   uint32_t;

Das Problem ist also nicht der uC Code sondern das Python Skript, 
welches die Daten sendet.

[Falk B. (falk)]

DenDen B. schrieb:
> unsigned char 0'

char ist aber auf dieser CPU-Familie 16 Bit breit!

[Tom (mantabit)]

Falk B. schrieb:
> DenDen B. schrieb:
>> unsigned char 0'
>
> char ist aber auf dieser CPU-Familie 16 Bit breit!

Der Communication Manager besitzt eine ARM Cortex M4 Architektur (der 
Chip besitzt einen ARM CM und zwei C28 CPUs).