XC16 v1.70- oder Ich mache komische Sachen mit Pointer

[Aaron K. (aaron_b_k)]

Hi Leute,
ich habe ein Problem mit einer Funktion...

_Funktion in MPLAB_

Im Grunde sieht die Funktion so aus:

static char data_read_buf[100]; //buffer for queueing data to be read
static int read_cnt = 0; //counter icnrements through data_red_buf

void i2c_drv_read_data_get(int* data) {

    *data = data_read_buf[read_cnt++];
    if (read_cnt == 100)read_cnt = 0;

    return;
}

In das Read-Buffer werden Daten welche via I2C empfangen werden 
zwischengespeichert. Das Funktioniert soweit auch (das Array füllt sich 
mit Daten ungleich 0). Die oben dargestellte Funktion soll nun diese 
Daten element für element in "int* data" schreiben.
Auch das Inkrementieren durch die Elemente funktioniert tadellos.
Jedoch nimmt *data nicht die Werte aus data_read_buf an, sondern 
verbleibt bei 0.

Ich verwende hier einen PIC24hj128gp202 mit der MPLAB X IDE v5.50 mit 
dem xc16 v1.70 compiler.

Ich weiß jetzt nicht ob es am Debugger liegt. Kann die Werte leider nur 
im Debug-Modus auslesen, da ich sonst keine Daten/Info-Ausgänge habe.

_Funktion mit online Compiler klappt_

Ich habe eine ähnliche Funktion in einem online c-compiler testweise 
ausgewertet. Diese verhält sich so wie sie soll...

#include <stdio.h>

int data_array[]={0, 100, 200, 300, 400};

void foo(int* data){
    
    static int i=0;
    *data = data_array[i++];
    if(i>=5)i=0;
    
    return;
}

int main()
{
        
    int i=0;
    for(i=0;i<5;i++){
        int tmp;
        foo(&tmp);
        printf("%i\n", tmp);
    }

    return 0;
}

Diese Funktion gibt dann aus:

0
100
200
300
400

_eigentliche Frage_

Habe ich iwo einen Fehler gemacht? Kann mit jemand das Verhalten 
erklären?

[uff basse (Gast)]

Aaron K. schrieb:
> Habe ich iwo einen Fehler gemacht?

Eine Deklaration

  int irgendwas;

ist fast immer scheisse wenn man die Registerbreite bzw. die
Architektur des Zielsystems nicht kennt. Kann dein online-
Compiler das riechen was du willst?

[Aaron K. (aaron_b_k)]

An welcher Stelle genau sollte, das ein Problem darstellen?

Ich verwende bei beiden Beispielen nur int-Variablen, es wird nichts 
bitwise manipuliert, also ist dier Registerbreite doch völlig egal.

Bei meiner Frage gehts ja auch darum, warum es in der online IDE funzt, 
aber in MPLAB nicht. Ist ja an sich der selbe Code in beiden Fällen. Nur 
iwie tut die MPLAB-Funktion nicht was sie soll und ich weiß nicht warum 
...

[Mombert H. (mh_mh)]

Aaron K. schrieb:
> Habe ich iwo einen Fehler gemacht? Kann mit jemand das Verhalten
> erklären?

Das ist schwer zu beantworten mit den Infos die du uns gegeben hast. 
Dein "online c-compiler" Beispiel weist einige Unterschiede auf zu 
deinem ursprünglichen Beispiel. Z.B. static char data_read_buf[] vs. int 
data_array[].

[Simon (Gast)]

Aaron K. schrieb:
> Bei meiner Frage gehts ja auch darum, warum es in der online IDE funzt,
> aber in MPLAB nicht. Ist ja an sich der selbe Code in beiden Fällen. Nur
> iwie tut die MPLAB-Funktion nicht was sie soll und ich weiß nicht warum
> ...

Hast du denn data_read_buf[] mal mit Pseudo-Werten bei der 
Initialisierung gefüllt, und geguckt was dann passiert?
Bzw. was passiert mit data nach dem schreiben? Kann es sein, dass das 
Kopieren einfach weg-optimiert wird?

[DerEgon (Gast)]

void i2c_drv_read_data_get(int* data) {
    *data = data_read_buf[read_cnt++];
    if (read_cnt == 100)read_cnt = 0;
    return;
}

Welchen Sinn soll das "return" hier haben? Was würde die Funktion 
machen, wenn das da nicht steht?

[Wilhelm M. (wimalopaan)]

Aufruf aus ISR? non-volatile?

[Gelangweilter (Gast)]

Aaron K. schrieb:
> In das Read-Buffer werden Daten welche via I2C empfangen werden
> zwischengespeichert.

Lass mich raten: Mit einem Interrupt?

[Aaron K. (aaron_b_k)]

DerEgon schrieb:
>

> void i2c_drv_read_data_get(int* data) {
>     *data = data_read_buf[read_cnt++];
>     if (read_cnt == 100)read_cnt = 0;
>     return;
> }
>

>
> Welchen Sinn soll das "return" hier haben? Was würde die Funktion
> machen, wenn das da nicht steht?

Ist einfach eine gute Angewohntheit selbst bei einer Void-Funktion ein 
return reinzusetzen. Damit jeder weiß hier ist die Funktion zu ende und 
es wurde nichts vergessen (ende ist hier auch wirklich vorgesehen)

[Aaron K. (aaron_b_k)]

Gelangweilter schrieb:
> Aaron K. schrieb:
>> In das Read-Buffer werden Daten welche via I2C empfangen werden
>> zwischengespeichert.
>
> Lass mich raten: Mit einem Interrupt?

Nope habe nicht einen einzigen Interrupt am laufen. Alles via Polling.

[Wilhelm M. (wimalopaan)]

Dann zeige mal den Caller, bisher haben wir nur den Callee gesehen.

[J. S. (jojos)]

falsche/fehlende forward Deklaration beim Aufrufer?

[DerEgon (Gast)]

Aaron K. schrieb:
> Ist einfach eine gute Angewohntheit selbst bei einer Void-Funktion ein
> return reinzusetzen.

Nee. Ist keine gute Angewohnheit, sondern überflüssig und irritierend. 
So, als ob der Programmierer sich nicht sicher ist, was er da eigentlich 
will.

Mit der gleichen Argumentation könntest Du hinter jedes if() auch einen 
leeren else-Zweig packen, um klarzumachen, daß der da nicht 
versehentlich vergessen wurde:

if (a == 4)
{
  printf("A ist vier\n");
}
else
{ };

Oder in einem switch-Statement jeden unbenutzten Wert einzeln aufführen 
und/oder einen leeren default-Zweig einfügen.

[Mombert H. (mh_mh)]

Ich finde, dass es eine gute Angewohnheit ist (wenn es konsquent überall 
gemacht wird). Dann kann ich auf den ersten Blick sehen, wo die Ausgänge 
aus der Funktion sind und kann sehr einfach den Datenfluss 
zurückverfolgen, ohne jede Funktion von Anfang bis Ende durchgehen zu 
müssen.

[DerEgon (Gast)]

Es ist überflüssig, denn auch das Ende einer Funktion ist ein "Ausgang". 
Immer.

[Gelangweilter (Gast)]

Aaron K. schrieb:
> Nope habe nicht einen einzigen Interrupt am laufen. Alles via Polling.

Na dann, nächste Stufe:


Aaron K. schrieb:
> Im Grunde sieht die Funktion so aus:

Zeige die Originalfunktion, und nicht eine frei erfundene Lügenfunktion!

[Mombert H. (mh_mh)]

DerEgon schrieb:
> Es ist überflüssig, denn auch das Ende einer Funktion ist ein "Ausgang".
> Immer.

Es gibt bei allen deinen Funktionen einen logischen und sinnvollen Weg 
die Funktion am Ende (letzte Zeile) zu verlassen?

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Dann zeige mal den Caller, bisher haben wir nur den Callee gesehen.

Sry. Was meinst du mit Caller/Callee?? Kann mit den Begrifflichkeiten 
nichts anfangen.

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> Wilhelm M. schrieb:
>> Dann zeige mal den Caller, bisher haben wir nur den Callee gesehen.
>
> Sry. Was meinst du mit Caller/Callee?? Kann mit den Begrifflichkeiten
> nichts anfangen.

Caller = Aufrufer

[Aaron K. (aaron_b_k)]

Gelangweilter schrieb:
> Aaron K. schrieb:
>> Nope habe nicht einen einzigen Interrupt am laufen. Alles via Polling.
>
> Na dann, nächste Stufe:
>
>
> Aaron K. schrieb:
>> Im Grunde sieht die Funktion so aus:
>
> Zeige die Originalfunktion, und nicht eine frei erfundene Lügenfunktion!

Das ist meine Originalfunktion.

static char data_read_buf[100]; //buffer for queueing data to be read
static int read_cnt = 0; //counter icnrements through data_red_buf

void i2c_drv_read_data_get(int* data) {

    *data = data_read_buf[read_cnt++];
    if (read_cnt == 100)read_cnt = 0;

    return;
}

int main(void) {

    TRISAbits.TRISA0 = OUTPUT;
    TRISAbits.TRISA1 = OUTPUT;

    i2c_drv_init();

    int i = 0;
    for (i = 0; i < 0xffff; i++)continue;
    for (i = 0; i < 0xffff; i++)continue;
    for (i = 0; i < 0xffff; i++)continue;

    int data_bridge = 0;
    int data_temperature = 0;

    while (1) {

        if (i2c_drv_manager() == 1) {

            for (i = 0; i < 0xffff; i++)continue;

            LATAbits.LATA1 = 1;
            pressure_sensor_start_measurement();
            LATAbits.LATA1 = 0;

            int tmp = 0;
            i2c_drv_read_data_get(&tmp);
            data_bridge = tmp << 8;
            i2c_drv_read_data_get(&tmp);
            data_bridge += tmp;

            i2c_drv_read_data_get(&tmp);
            data_temperature = tmp << 3;
            i2c_drv_read_data_get(&tmp);
            data_temperature += tmp >> 5;

            tmp = 0;
        }
    }

    return 1;
}

Der I2C_manager arbeitet im Grunde die I2C-Tasks ab. Der funktioniert 
soweit auch.

pressure_sensor_start_measurement setzt die Tasks die notwendig sind um 
Daten aus einem Sensor zu lesen. Auch das funktioniert soweit tadellos.

Das Problem entsteht wie gesagt erst an der Stelle, wo die Daten aus 
einem Software-Read-Buffer via Pointer an eine andere Adresse kopiert 
werden. (die void i2c_drv_read_data_get(int* data) Funktion). um genau 
zu sein macht dort soweit ich das bewerten kann nur die Zeile...

*data = data_read_buf[read_cnt++];

...Probleme. Da genau hier der Wert des Pointers 0 bleibt, während im 
Array an gegebener Stelle Werte ungleich 0 stehen.

[/c]

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Aaron K. schrieb:
>> Wilhelm M. schrieb:
>>> Dann zeige mal den Caller, bisher haben wir nur den Callee gesehen.
>>
>> Sry. Was meinst du mit Caller/Callee?? Kann mit den Begrifflichkeiten
>> nichts anfangen.
>
> Caller = Aufrufer

Ist das nicht der Fuktionsname?

Aber was ist dann ein CAllee??? Tippfehler?

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> int tmp = 0;
>             i2c_drv_read_data_get(&tmp);

Und was erwartest Du, was hier passiert?

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> Wilhelm M. schrieb:
>> Aaron K. schrieb:
>>> Wilhelm M. schrieb:
>>>> Dann zeige mal den Caller, bisher haben wir nur den Callee gesehen.
>>>
>>> Sry. Was meinst du mit Caller/Callee?? Kann mit den Begrifflichkeiten
>>> nichts anfangen.
>>
>> Caller = Aufrufer
>
> Ist das nicht der Fuktionsname?
>
> Aber was ist dann ein CAllee??? Tippfehler?

Nein. Callee ist "der Aufgerufene"

[Programmierer (Gast)]

Aaron K. schrieb:
> void i2c_drv_read_data_get(int* data) {
>     *data = data_read_buf[read_cnt++];
>     if (read_cnt == 100)read_cnt = 0;
>     return;
> }

Wäre diese Funktion nicht so viel einfacher:

int i2c_drv_read_data_get(void) {
  int c = read_cnt;
  read_cnt = read_cnt == 99 ? 0 : read_cnt + 1;
  return data_read_buf[c];
}

Wozu die Schnippselei mit dem Pointer?

Mombert H. schrieb:
> DerEgon schrieb:
>> Es ist überflüssig, denn auch das Ende einer Funktion ist ein "Ausgang".
>> Immer.
>
> Es gibt bei allen deinen Funktionen einen logischen und sinnvollen Weg
> die Funktion am Ende (letzte Zeile) zu verlassen?

Fast immer. Besser in den seltenen Fällen, wo das nicht so ist, ein "/* 
unreachable */" ans Ende schreiben. Besser den häufigen Standardfall 
einfach machen als überall etwas redundantes hinzuschreiben...

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> pressure_sensor_start_measurement setzt die Tasks die notwendig sind um
> Daten aus einem Sensor zu lesen. Auch das funktioniert soweit tadellos.

FreeRTos?

[Simon (Gast)]

Welche Optimierung hast du eingeschaltet?
da
int data_bridge = 0;
int data_temperature = 0;

nicht weiter genutzt werden, könnte das ganze Gespeichere ignoriert 
werden.

versuche mal die beiden Variablen global und volatile zu deklarieren.

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Aaron K. schrieb:
>> int tmp = 0;
>>             i2c_drv_read_data_get(&tmp);
>
> Und was erwartest Du, was hier passiert?

Ich möchte die Daten in tmp zwischenspeichern und den beiden variablen 
data_bridge und data_temperature zuweisen.

Die empfangenen i2c Bytes sind wie folgt aufgabaut:

Bit   | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
------|---|---|---|---|---|---|---|---|
Byte 1| Flags | High Byte Pressure    |
Byte 2| Low Byte Pressure             |
Byte 3| High ByteTemperature          |
Byte 4|Low Byte Te| Dont care         |

Ich muss dei Daten quasi wieder zusammenkleben. Lässt sich sicherlich 
ohne tmp lösen, ist so finde ich einfach und tuts auch.

[Aaron K. (aaron_b_k)]

Simon schrieb:
> Welche Optimierung hast du eingeschaltet?
> da
> int data_bridge = 0;
> int data_temperature = 0;
>
> nicht weiter genutzt werden, könnte das ganze Gespeichere ignoriert
> werden.
>
> versuche mal die beiden Variablen global und volatile zu deklarieren.

Optimierungsstufe 0 also quasi keine Optimierung. Aber ich versuche das 
mal.

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> Wilhelm M. schrieb:
>> Aaron K. schrieb:
>>> int tmp = 0;
>>>             i2c_drv_read_data_get(&tmp);
>>
>> Und was erwartest Du, was hier passiert?
>
> Ich möchte die Daten in tmp zwischenspeichern und den beiden variablen
> data_bridge und data_temperature zuweisen.

> Ich muss dei Daten quasi wieder zusammenkleben. Lässt sich sicherlich
> ohne tmp lösen, ist so finde ich einfach und tuts auch.

Wo wird denn Dein Buffer data_read_buf gefüllt. Das fehlt immer noch ...

[Simon (Gast)]

Simon schrieb:
> versuche mal die beiden Variablen global und volatile zu deklarieren.
>
>
>
>       if (!have_newpost_anchor && (!topic_last_read_at ||
> topic_last_read_at < 1656070342000)) {
>         document.write('<a name="new" id="new"></a>');
>         have_newpost_anchor = true;
>       }

oder gucke dir den generierten Assembler-Code an, da siehst du auch gut 
was passiert.

[Simon (Gast)]

Wilhelm M. schrieb:
> Wo wird denn Dein Buffer data_read_buf gefüllt. Das fehlt immer noch ...
>
deshalb fragte ich:

Simon schrieb:
> Hast du denn data_read_buf[] mal mit Pseudo-Werten bei der
> Initialisierung gefüllt, und geguckt was dann passiert?
> Bzw. was passiert mit data nach dem schreiben? Kann es sein, dass das
> Kopieren einfach weg-optimiert wird?

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Aaron K. schrieb:
>> Wilhelm M. schrieb:
>>> Aaron K. schrieb:
>>>> int tmp = 0;
>>>>             i2c_drv_read_data_get(&tmp);
>>>
>>> Und was erwartest Du, was hier passiert?
>>
>> Ich möchte die Daten in tmp zwischenspeichern und den beiden variablen
>> data_bridge und data_temperature zuweisen.
>
>> Ich muss dei Daten quasi wieder zusammenkleben. Lässt sich sicherlich
>> ohne tmp lösen, ist so finde ich einfach und tuts auch.
>
> Wo wird denn Dein Buffer data_read_buf gefüllt. Das fehlt immer noch ...

//receive---------------------------------------------------------------------//

/*
 * triggers receiving of I2C1
 *
 * @since 1.0.0
 * @category hardware
 * @param {byte} ptr to location where the data will be stored
 * @returns {void}
 * @example 
 * 
 * int data;
 * ...
 * while(i2c_drv_receive_get_check!=TRUE)continue; //wait until data is ready
 * i2c_drv_receive_get(&data); //get data
 * 
 */
static int i2c_drv_data_get(void) {

    static int i = 0;
    data_read_buf[i++] = I2C1RCV;
    if (i == 100)i = 0;

    return TRUE;
}

Das Buffer wird hier gefüllt. Es geht aber wie gesagt darum, dass die 
Daten nicht an den Wert des Pointers kopiert werden. :)

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> Wilhelm M. schrieb:

>> Wo wird denn Dein Buffer data_read_buf gefüllt. Das fehlt immer noch ...

>

> static int i2c_drv_data_get(void) {
> 
>     static int i = 0;
>     data_read_buf[i++] = I2C1RCV;
>     if (i == 100)i = 0;
> 
>     return TRUE;
> }
>

>
> Das Buffer wird hier gefüllt. Es geht aber wie gesagt darum, dass die
> Daten nicht an den Wert des Pointers kopiert werden. :)

Oh man, und wo / wie wird das aufgerufen?

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Aaron K. schrieb:
>> Wilhelm M. schrieb:
>
>>> Wo wird denn Dein Buffer data_read_buf gefüllt. Das fehlt immer noch ...
>
>>

> 
>> static int i2c_drv_data_get(void) {
>>
>>     static int i = 0;
>>     data_read_buf[i++] = I2C1RCV;
>>     if (i == 100)i = 0;
>>
>>     return TRUE;
>> }
>>

>>
>> Das Buffer wird hier gefüllt. Es geht aber wie gesagt darum, dass die
>> Daten nicht an den Wert des Pointers kopiert werden. :)
>
> Oh man, und wo / wie wird das aufgerufen?

Wie gesagt, dass funktioniert alles soweit... Es geht wirklich nur darum 
warum der Wert des Pointers nicht geändert wird. Aber falls es hilft 
schicke ich gerne noch den restlichen code :)

/*
 * manages events of i2c_drv. Has to be called periodically (higher frequency than i2c events)
 *
 * @since 1.0.0
 * @category hardware
 * @param {void}
 * @returns {void}
 * @example none
 */
int i2c_drv_manager(void) {

    static int i = 0;

    if (busy_flag == FALSE) {
        return 1;
    }

    switch (cmd_buf[i]) {

            //transmit
        case I2C_DRV_CMD_TX_START:
            if (i2c_drv_start_set_check() == TRUE) {
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_TX_RESTART:
            if (i2c_drv_restart_set_check() == TRUE) {
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_TX_STOP:
            if (i2c_drv_stop_set_check() == TRUE) {
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_TX_ACK:
            if (i2c_drv_ack_set_check() == TRUE) {
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_TX_NACK:
            if (i2c_drv_nack_set_check() == TRUE) {
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_TX_DATA:
            if (i2c_drv_data_set_check() == TRUE) {
                break;
            } else {
                return 0;
            }

            //recieve
        case I2C_DRV_CMD_RX_ACK:
            if (i2c_drv_ack_get_check() == TRUE) {
                i2c_drv_ack_get();
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_RX_NACK:
            if (i2c_drv_nack_get_check() == TRUE) {
                i2c_drv_nack_get();
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_RX_DATA:
            if (i2c_drv_data_get_check() == TRUE) {
                i2c_drv_data_get();
                break;
            } else {
                return 0;
            }

            //general
        case I2C_DRV_CMD_END:
            break;
    }

    //skip first cmt incremention, then increment every time
    static int first_flag = TRUE;

get_next_instruction:
    if (first_flag == TRUE) {
        first_flag = FALSE;
    } else {
        i += 1;
        if (i == 100)i = 0;
    }

    //transmit
    switch (cmd_buf[i]) {

        case I2C_DRV_CMD_TX_START:
            i2c_drv_start_set();
            return 0;
            break;
        case I2C_DRV_CMD_TX_RESTART:
            i2c_drv_restart_set();
            return 0;
            break;
        case I2C_DRV_CMD_TX_STOP:
            i2c_drv_stop_set();
            return 0;
            break;
        case I2C_DRV_CMD_TX_ACK:
            i2c_drv_ack_set();
            return 0;
            break;
        case I2C_DRV_CMD_TX_NACK:
            i2c_drv_nack_set();
            return 0;
            break;
        case I2C_DRV_CMD_TX_DATA:
            i2c_drv_data_set();
            return 0;
            break;

            //recieve
        case I2C_DRV_CMD_RX_ACK:
            if (i2c_drv_ack_get_check() == TRUE) {
                i2c_drv_ack_get();
                goto get_next_instruction;
                return 0;
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_RX_NACK:
            if (i2c_drv_nack_get_check() == TRUE) {
                i2c_drv_nack_get();
                goto get_next_instruction;
                return 0;
                break;
            } else {
                return 0;
            }
        case I2C_DRV_CMD_RX_DATA:
            if (i2c_drv_data_get_check() == TRUE) {
                i2c_drv_data_get();
                goto get_next_instruction;
                return 0;
                break;
            } else {
                return 0;
            }

            //general
        case I2C_DRV_CMD_END:
            busy_flag = FALSE;

            return 1;
            break;
    }

    return 1;
}

[Wilhelm M. (wimalopaan)]

Ich vermute jetzt mal, dass Du eigentlich ein FIFO erstellen wolltest. 
Das gibt Dein Code aber nicht her. Wenn also die Daten vom I2C langsamer 
eintreffen als Deine main-loop, dann geht es eben nicht, weil der Leser 
aus der FIFO den Schreiber in die FIFO überholt.

Edit: Bzw. Deine main-loop wir ggf. sogar verlassen!

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
>  *
>  * @since 1.0.0
>  * @category hardware
>  * @param {void}
>  * @returns {void}
>  * @example none
>  */

Schönes Beispiel für falsche (Doku-) Kommentare

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Ich vermute jetzt mal, dass Du eigentlich ein FIFO erstellen wolltest.
> Das gibt Dein Code aber nicht her. Wenn also die Daten vom I2C langsamer
> eintreffen als Deine main-loop, dann geht es eben nicht, weil der Leser
> aus der FIFO den Schreiber in die FIFO überholt.

Dei Main kann nicht schneller sein als der manager daten bereitstellt. 
Da die Daten erst aus dem Buffer ausgelesen werden, wenn die letzte 
Nachricht über den Manager vollständig abgearbeitet wurde.

Und ja es ist Fifo/Ringbuffer. Aber auch das stellt kein Problem dar. 
Wie ich bereits erwähnt habe...

Ich möchte Daten aus einem Buffer, welche ungleich null sind an den Wert 
eines Pointers kopieren. Das funktioniert jedoch nicht, weil die Daten 
die als Wert des Pointers abgespeichert nach wie vor 0 betragen, obwohl 
im eigentliche Buffer Daten ungleich 0 sind...

Zugegeben das Fifo ist etwas eigensinnig gecodet. Aber es funktioniert 
beim debuggen tadellos :) Es handelt sich hierbei eher um eine 
Auswertung eines Sensors. Aus dem Grund sind solche Feinheiten (wie ein 
gut lesbares/wartbares FIFO) auf später aufgeschoben.

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Aaron K. schrieb:
>>  *
>>  * @since 1.0.0
>>  * @category hardware
>>  * @param {void}
>>  * @returns {void}
>>  * @example none
>>  */
>
> Schönes Beispiel für falsche (Doku-) Kommentare

Danke wird verbessert. Vier Augen sehen immernoch mehr als 2 ;)

[Aaron K. (aaron_b_k)]

Wilhelm M. schrieb:
> Ich vermute jetzt mal, dass Du eigentlich ein FIFO erstellen wolltest.
> Das gibt Dein Code aber nicht her. Wenn also die Daten vom I2C langsamer
> eintreffen als Deine main-loop, dann geht es eben nicht, weil der Leser
> aus der FIFO den Schreiber in die FIFO überholt.
>
> Edit: Bzw. Deine main-loop wir ggf. sogar verlassen!

int main(void) {

    TRISAbits.TRISA0 = OUTPUT;
    TRISAbits.TRISA1 = OUTPUT;

    i2c_drv_init();

    int i = 0;
    for (i = 0; i < 0xffff; i++)continue;
    for (i = 0; i < 0xffff; i++)continue;
    for (i = 0; i < 0xffff; i++)continue;

    int data_bridge = 0;
    int data_temperature = 0;

    while (1) {

        if (i2c_drv_manager() == 1) {

            for (i = 0; i < 0xffff; i++)continue;

            LATAbits.LATA1 = 1;
            pressure_sensor_start_measurement();
            LATAbits.LATA1 = 0;

            volatile int tmp = 0;
            i2c_drv_read_data_get(&tmp);
            data_bridge = tmp << 8;
            i2c_drv_read_data_get(&tmp);
            data_bridge += tmp;

            i2c_drv_read_data_get(&tmp);
            data_temperature = tmp << 3;
            i2c_drv_read_data_get(&tmp);
            data_temperature += tmp >> 5;

            tmp = 0;
        }
    }

    return 1;
}

Wie kann der Main-Loop hier verlassen werden? Einmal in der While kein 
zurück mehr. Gibt kein Goto, Return oder break innerhalb der Schleife. 
Übersehe ich da was ???

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> Wie kann der Main-Loop hier verlassen werden? Einmal in der While kein
> zurück mehr. Gibt kein Goto, Return oder break innerhalb der Schleife.
> Übersehe ich da was ???

Ja, mein Fehler. Hatte Deinen Code falsch im Kopf.

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> Zugegeben das Fifo ist etwas eigensinnig gecodet. Aber es funktioniert
> beim debuggen tadellos :)

Ich kann kein FiFo erkennen.

Und was funktioniert beim Debuggen?

[Aaron K. (aaron_b_k)]

So habe mein Fehler....

In der Main wird der Manager augerufen bevor eine Nachricht in Auftrag 
gegeben wird (pressur_sensor_start_measurement). Dadurch werden zu 
Beginn Daten aus dem Buffer ausgelesen die nocht nicht existent sind.

Ich dachte das ist nicht weiterschlimm (wie gesagt Testlauf) und habe es 
ignoriert. Was dabei logischerweise jedoch auch passiert ist, dass der 
Incrementor für die Buffer-Elemente so immer auf Daten verweist die noch 
nicht ausgelesen wurden...

Also um die Überschrift dieses Threads zu beantworten. Ich habe komische 
Sachen mit Pointern gemacht.

Danke für jeden Beitrag :)

P.S.: Jetzt klappt alles wie es soll :D

[Wilhelm M. (wimalopaan)]

Aaron K. schrieb:
> n der Main wird der Manager augerufen bevor eine Nachricht in Auftrag
> gegeben wird (pressur_sensor_start_measurement). Dadurch werden zu
> Beginn Daten aus dem Buffer ausgelesen die nocht nicht existent sind.

Genau das habe ich gesagt: Du hast keinen FiFo!

[Frank M. (ukw) (Moderator)]

Aaron K. schrieb:

> int i = 0;
>     for (i = 0; i < 0xffff; i++)continue;
>     for (i = 0; i < 0xffff; i++)continue;
>     for (i = 0; i < 0xffff; i++)continue;

Du wirst Dich wundern, was Deine "Verzögerungsschleifen" bewirken, 
sobald Du den Optimierer einschaltest. Diese Schleifen werden dann 
nämlich gnadenlos wegoptimiert.

Übrigens ist das lediglich ein Feature Deines Compilers, wenn er diese 
Schleifen tatsächlich ohne Optmierung stehen lässt. Verlassen kannst Du 
Dich darauf nicht. Code, welcher keinen Effekt hat, kann nämlich vom 
Compiler immer wegoptimiert werden - egal in welcher 
Optimierungsstufe. Von daher sehe ich das mal als nicht-portablen Code 
an.

Aaron K. schrieb:
> Aber es funktioniert beim debuggen tadellos :)

Klar, weil dann eben Dein Code nicht die reinkommenden I2C-Daten 
"überholt", Wilhelm hat das Problem schon vorher einwandfrei erkannt.

Aaron K. schrieb:
> Wie gesagt, dass funktioniert alles soweit...

Wie Du nun gesehen hast, funktionierte das Füllen des Arrays doch nicht 
"soweit" korrekt, weil Du den Parameter "Zeit" einfach nicht 
berücksichtigt hast.

Deshalb ein Tipp für die Zukunft: Versuche zukünftig nicht mehr, den 
Leser durch Behauptungen, die sich im nachhinein als falsch 
herausstellen, in die Irre zu führen und lediglich den Codeschnipsel, wo 
Du den Fehler vermutest, zu posten. Du zwingst sonst den Leser, nur in 
Deine gewünschte Richtung zu denken. Das hat aber keinen Mehrwert - im 
Gegenteil: Du verzögerst damit die Problemfindung.

[Aaron K. (aaron_b_k)]

Jo stimmt alles was du geschrieben hast. Die For-Schleifen werden später 
definitiv durch Timer-Routinen abgelöst. Das war nur der erste Versuch 
Daten aus dem Sensor zu bekommen. Und Timer initialisieren dauert zwar 
nicht lang aber ein paar For-Schleifen iwo reinzuschreiben tuts auch und 
dauert noch weniger lang :D

Zum Thema Thread schreiben. Tipp werde ich beherzigen. :)