Look-up Tabelle wird nicht anständig gelesen

[Stephan (Gast)]

Hallo!

Vorweg: ich wünsche ein frohes neues Jahr!


Folgendes, hochkomplexe Softwarekonstrukt, verwirrt mich:

const unsigned char tabelle[] = {0x01,0x10,0x20,0x30,0x10,0x20,0x30,0x20,0x30};

void show_values(void)
{      
  unsigned int i;  
  
  for (i=0; i<6; i++)
  {      
      uart_putc(tabelle[i]);
  }

Denn die Ausgabe liefert nur sechs Nullen!

Wenn ich aber die Schleife verkürze, also i<5 oder noch kürzer, werden 
die korrekten Wert der Tabelle ausgegeben, also 0,1,2,3,4

Woher kommt sowas?!

[Peter II (Gast)]

Stephan schrieb:
> korrekten Wert der Tabelle ausgegeben, also 0,1,2,3,4

wie kommst du auf diese werte? Ich kann keinen Bezug zu den Hexzahlen 
herstellen.

[Stephan (Gast)]

Peter II schrieb:
> wie kommst du auf diese werte? Ich kann keinen Bezug zu den Hexzahlen
> herstellen.

Oh shit, tschuldige.
Die Ausgabe lautet natürlich 1,0,20,30... bei der gegebenen Tabelle.

[Peter II (Gast)]

Stephan schrieb:
> Oh shit, tschuldige.
> Die Ausgabe lautet natürlich 1,0,20,30... bei der gegebenen Tabelle.

das kann auch nicht sein.

[Stephan (Gast)]

Peter II schrieb:
> das kann auch nicht sein.

Jetzt aber.. 1,10,20,30 (hex)
Bzw. 1,16,3,48,16 (dec)

[Mladen G. (mgira)]

unsigned int als index fuer ein Byte Array?

Meine C Zeiten sind lange vorbei, meine aber mich zu erinnern dass dein 
index wohl besser auch ein byte ist, da C einfach nur die Index 
"groesse" (Datentyp) mit dem Indexwert zu Arrayoffset Addresse addiert.

[Stephan (Gast)]

Stephan schrieb:
> Jetzt aber.. 1,10,20,30 (hex)
> Bzw. 1,16,3,48,16 (dec)

ICH DREH GLEICH AM RAD!!

[SkyperHH (Gast)]

Was macht Funktion uart_putc(...); aus den Werten?

Wenn die Zahlen in ASCII Zeichen überzsetzt werden, kommen für die Werte 
der Tabelle folgende "Sonderzeichen" zu stande:

{0x01,0x10,0x20,0x30,0x10,0x20,0x30,0x20,0x30};
  SOH, DLE,  SP,   0, DLE,  SP,   0,  SP,   0

[Peter II (Gast)]

Mladen G. schrieb:
> Meine C Zeiten sind lange vorbei, meine aber mich zu erinnern dass dein
> index wohl besser auch ein byte ist, da C einfach nur die Index
> "groesse" (Datentyp) mit dem Indexwert zu Arrayoffset Addresse addiert.

nein das ist schon so ok. Byte gibt es in C nicht. Und ein index darf 
sogar negativ sein.

[Stephan (Gast)]

SkyperHH schrieb:
> Was macht Funktion uart_putc(...); aus den Werten?

Werden ohne Übersetzung in den Ringbuffer gelegt und gesendet.

[Schlumpf (Gast)]

Stephan schrieb:
> ICH DREH GLEICH AM RAD!!

pruuuust ;-)

So, jetzt konzentriere dich mal, atme ein, und aus und dann gaaaaaanz 
langsam.....

[SkyperHH (Gast)]

Aha... und Empfangen tut das ein Terminal am PC?

[Stephan (Gast)]

Schlumpf schrieb:
> So, jetzt konzentriere dich mal, atme ein, und aus und dann gaaaaaanz
> langsam.....

Zu viel Kaffee.

SkyperHH schrieb:
> Aha... und Empfangen tut das ein Terminal am PC?

Genau!

[Schlumpf (Gast)]

Stephan schrieb:
> Werden ohne Übersetzung in den Ringbuffer gelegt und gesendet.

... und dann am PC von einem Terminalprogramm empfangen und 
dargestellt???

[Peter II (Gast)]

Stephan schrieb:
>> Was macht Funktion uart_putc(...); aus den Werten?
>
> Werden ohne Übersetzung in den Ringbuffer gelegt und gesendet.

und ist der Ringpuffer auch gross genug?

[Stephan (Gast)]

int i;
i=0;

uart1_putc(tabelle[i]);
i++;
uart1_putc(tabelle[i]);
i++;
uart1_putc(tabelle[i]);
i++;
uart1_putc(tabelle[i]);
i++;
uart1_putc(tabelle[i]);
i++;
uart1_putc(tabelle[i]);
i++;
uart1_putc(tabelle[i]);

liefert das richtige Ergebnis....

[Schlumpf (Gast)]

Stephan schrieb:
> Genau!

Und was stellt das Terminalprogramm dar? Ich vermute mal ASCII-Zeichen? 
oder? :-)

[Stephan (Gast)]

Schlumpf schrieb:
> Ich vermute mal ASCII-Zeichen?

Nein, Asciizeichen sind Müll bzw unlesbar.
Dezimal und Hex ist lesbar. Ich benutzt HTerm.

[Stephan (Gast)]

Peter II schrieb:
> und ist der Ringpuffer auch gross genug?

Der ist groß.

[SkyperHH (Gast)]

Ok, Dir ist schon klar, das alles ASCII-Zeichen kleiner als 0x1f - 31d 
reine Steuerzeichen sind... wie Sie das Terminal umsetzt, bzw. sie 
überhaupt anzeigt, keine Ahnung... 0x20 - 32d ist Space, also ein 
Leerzeichen, ist also auch nichts zu sehen...

Einziges sichtbares Zeichen ist 0x30 48d, das entspricht der "0" ...

[Mladen G. (mgira)]

Peter II schrieb:
> nein das ist schon so ok. Byte gibt es in C nicht. Und ein index darf
> sogar negativ sein.

Kommt darauf an ;)

Ob es bytes etc. gibt, liegt an der HW.
Klar, wenn ein usigned byte genauso "breit" ist wie ein unsigned int (16 
bit), dann passt das natuerlich.
Ansonsten passt das aber nicht.

Muesste nochmals in der Literatur nachschlagen, aber Array Indizes 
sollten m.E. folgerndermassen berechnet werden:

Array Adresse + (Index * Datenbreite)

[Peter II (Gast)]

Mladen G. schrieb:
> Muesste nochmals in der Literatur nachschlagen, aber Array Indizes
> sollten m.E. folgerndermassen berechnet werden:
>
> Array Adresse + (Index * Datenbreite)

nein nicht ganz:

Array Adresse + (Index * sizeof( Datentype ) )

[JojoS (Gast)]

Stephan schrieb:
> int i;
> i=0;
>
> uart1_putc(tabelle[i]);
>

>
> liefert das richtige Ergebnis....

Ist jetzt aber geschummelt weil uart1_putc statt uart_putc.
Falsche Bitrate?

[Mladen G. (mgira)]

Peter II schrieb:
> nein nicht ganz:
>
> Array Adresse + (Index * sizeof( Datentype ) )

Eben, hast es nur anders ausedrueckt ;)

Wenn dieser C Dialekt auf dieser HW aber doch 8 Bit Bytes unterstuetzt, 
dann sollte man auch ein Byte als Index verwenden, das war es worauf ich 
hinaus wollte.

[Stephan (Gast)]

SkyperHH schrieb:
> Einziges sichtbares Zeichen ist 0x30 48d, das entspricht der "0" ...

Das verwendete HTerm zeigt alles an, in Hex, Dez, Ascii


Ich bin aber weiter mit meinen Forschungen und es kommt hinzu:

  for (i=0; i<5; i++)
  {      
    uart1_putc(tabelle[i]);
  }

liefert ein korrektes Ergebnis,

  for (i=0; i<5; i++)
  {      
    uart1_putc(tabelle[i]);
    _delay_ms(10);
  }

liefert nur Nullen!
Graue Wolken tun sich auf...

[Schlumpf (Gast)]

Stephan schrieb:
> Stephan schrieb:
>> Jetzt aber.. 1,10,20,30 (hex)
>> Bzw. 1,16,3,48,16 (dec)

Warum wird dann aus einer 20hex eine 3dez?

[Peter II (Gast)]

Mladen G. schrieb:
> Wenn dieser C Dialekt auf dieser HW aber doch 8 Bit Bytes unterstuetzt,
> dann sollte man auch ein Byte als Index verwenden, das war es worauf ich
> hinaus wollte.

das ist aber falsch. Denn die Speicher-Adressen sind 16bit. Auch wenn es 
eine 8bit cpu ist.

[SkyperHH (Gast)]

Dann runter mit der Hose, zeige uns mal die Funktion --> 
uart1_putc(...);

[Fachmann (Gast)]

In dem code sind keine Fehler, ausser das nur 5 zeichen aus dem Array 
angezeigt werden.

Um alle zu zeigen muss man das tun.

for (i=0; i<10; i++)
  {
      uart_putc(tabelle[i]);
  }

[Stephan (Gast)]

Schlumpf schrieb:
> Stephan schrieb:
>> Stephan schrieb:
>>> Jetzt aber.. 1,10,20,30 (hex)
>>> Bzw. 1,16,3,48,16 (dec)
>
> Warum wird dann aus einer 20hex eine 3dez?

Fipptehler.

[Stephan (Gast)]

SkyperHH schrieb:
> Dann runter mit der Hose, zeige uns mal die Funktion -->
> uart1_putc(...);

void uart0_putc(unsigned char data)
{
  uart0txcounter++;
    unsigned char tmphead;    
    tmphead  = (UART0_TxHead + 1) & UART_TX_BUFFER_MASK;    
    while ( tmphead == UART0_TxTail ){
        ;/* wait for free space in buffer */
    }
    UART0_TxBuf[tmphead] = data;
    UART0_TxHead = tmphead;
    UART0_CONTROL    |= _BV(UART0_UDRIE);    /* enable UDRE interrupt */
}

[Rufus Τ. F. (rufus)]

Mladen G. schrieb:
> dann sollte man auch ein Byte als Index verwenden, das war es worauf ich
> hinaus wollte.

Das ist kompletter Unfug. Meinst Du, ein Array aus mehr als 256 Bytes 
wäre nicht möglich?

[Justus S. (jussa)]

Stephan schrieb:
> void uart0_putc(unsigned char data)
> {
>   uart0txcounter++;
>     unsigned char tmphead;
>     tmphead  = (UART0_TxHead + 1) & UART_TX_BUFFER_MASK;
>     while ( tmphead == UART0_TxTail ){
>         ;/* wait for free space in buffer */
>     }
>     UART0_TxBuf[tmphead] = data;
>     UART0_TxHead = tmphead;
>     UART0_CONTROL    |= _BV(UART0_UDRIE);    /* enable UDRE interrupt */
> }

von einer Funktion uart0_putc() war bis jetzt nie die Rede...

[Stephan (Gast)]

Justus Skorps schrieb:
> von einer Funktion uart0_putc() war bis jetzt nie die Rede...

Ich sollte auf Koffeinfreien Kaffee umsteigen. Der µC hat UART, die 
Funktionen dazu sind -bis auf den Index- alle gleich.

[Stephan (Gast)]

Stephan schrieb:
> Der µC hat UART

Der µC hat 4 UART

[Schlumpf (Gast)]

Stephan schrieb:
> SkyperHH schrieb:
>> Dann runter mit der Hose, zeige uns mal die Funktion -->
>> uart1_putc(...);

Gefragt war nach uart1_putc() !
                     -

[SkyperHH (Gast)]

Ok... da fehlt aber noch was, die ISR die den Puffer ausliest und 
übeträgt, die Initalisierung des Puffers... usw.

[Karl H. (kbuchegg)]

Wie wärs erst mal die Rungbufferausgabe durch eine stink normale zu 
ersetzen? Dann kannst du dich erst mal davon überzeugen, dass die 
Arrayzugriffe klappen, anstatt da von einem Problem zum anderen zu 
hampeln.

[Mladen G. (mgira)]

Rufus Τ. Firefly schrieb:
> Das ist kompletter Unfug. Meinst Du, ein Array aus mehr als 256 Bytes
> wäre nicht möglich?

Genau darum ging es doch.
Mit 8 Bit Adressen waere genau da schicht im Schacht, die Formel fuer 
die Addressarithmetik nutzt ja die Breite des Datentyps.

[Schlumpf (Gast)]

Wer oder was ist denn "uart0txcounter" ?
Eine globale Variable? Vermutlich wird an ihr dann auch noch im 
Interrupt und ggf anderen Stellen rumgeschraubt?

Wenn ja, dann mach die mal bitte "Volatile".

[Stephan (Gast)]

SkyperHH schrieb:
> Ok... da fehlt aber noch was, die ISR die den Puffer ausliest und
> übeträgt, die Initalisierung des Puffers... usw.

Karl Heinz schrieb:
> Wie wärs erst mal die Rungbufferausgabe durch eine stink normale zu
> ersetzen?

Bin ich dabei.

Was mich allerdings wirklich verwundert:

  for (i=0; i<5; i++)//kurze Schleife
  {      
    uart1_putc(tabelle[i]);
  }  
  
  uart1_putc(tabelle[i]);
  i++;
  uart1_putc(tabelle[i]);
  i++;
  uart1_putc(tabelle[i]);
  i++;
  uart1_putc(tabelle[i]);

liefert das richtige Ergebnis vom ersten bis zum letzten 
Tabelleneintrag,

  for (i=0; i<6; i++)//lange Schleife
  {      
    uart1_putc(tabelle[i]);
  }  
  
  uart1_putc(tabelle[i]);
  i++;
  uart1_putc(tabelle[i]);
  i++;
  uart1_putc(tabelle[i]);
  i++;
  uart1_putc(tabelle[i]);

liefert für die ersten 6 Tabelleneinträge Nullen, danach aber korrekte 
Werte. Riecht mir irgendwie nicht nach UART-Problem.

[JojoS (Gast)]

Doch eher UART bzw Buffer Problem. Sonst müssten ja auch bei der langen 
Schleife die ersten fünf Zeichen richtig ankommen.
Theorie: die Zeichen laufen erst in den Buffet bevor gesendet wird. Bei 
5 (oder sogar nur 4?) Zeichen ok, bei mehr geht etwas kaputt.

[SkyperHH (Gast)]

Ich würde eher auf Zeiger-Fehler tippen...

[OldMen (Gast)]

Stephan schrieb:
> liefert für die ersten 6 Tabelleneinträge Nullen, danach aber korrekte
> Werte.

Das glaubt Dir keiner. Mit i<5 soll es gehen, mit i<6 nicht?
Änderst Du evt. noch andere Codezeilen, wenn Du i<6 programmierst?
Übersetzt Du auch die richtige Datei?

[Stefan E. (sternst)]

Mladen G. schrieb:
> Mit 8 Bit Adressen waere genau da schicht im Schacht, die Formel fuer
> die Addressarithmetik nutzt ja die Breite des Datentyps.

Nein. Die Breite des Datentyps geht als Zahl in die Berechnung ein. Das 
hat rein gar nichts damit zu tun, in welcher Breite die Berechnung und 
Indexierung durchgeführt wird.

[Stephan (Gast)]

OldMen schrieb:
> Das glaubt Dir keiner. Mit i<5 soll es gehen, mit i<6 nicht?
> Änderst Du evt. noch andere Codezeilen, wenn Du i<6 programmierst?
> Übersetzt Du auch die richtige Datei?

Ohne Flachs!
Auch wenn ich ohne Ringbuffer sende, also

  while (!(UCSR1A & (1<<UDRE1)))  /* warten bis Senden moeglich */
    {
    }                             
    UDR1 = c;                      /* sende Zeichen */

verwende, werden bei der langen Schleifenversion aus der Schleife heraus 
nur Nullen gesendet!

[Stephan (Gast)]

static const unsigned char tabelle[10] = {0x10,0x20,0x30,0x40,0x50,0x60,0x70,0x80,0x90};

void show_values (void)
{      
  unsigned int  i;  
  i = 0;
  
  for (i=0; i<=3; i++)
  {      
    rausdamit(tabelle[i]);
  }    
}  
  
void rausdamit(char c)
{
  while (!(UCSR1A & (1<<UDRE1)))  /* warten bis Senden moeglich */
    {
    }                             
    UDR1 = c;                      /* sende Zeichen */
}

Das ist nun alles. und immernoch das gleiche: lange Schleife: schlecht, 
kurze Schleife: gut.

[Peter II (Gast)]

mache mal ein sleep in die lange schleife. Nicht das deine Baudrate 
nicht richtig stimmt und der sync verloren geht.

[Stephan (Gast)]

Peter II schrieb:
> mache mal ein sleep in die lange schleife

Hab ich schon gemacht. Das führt dazu, dass selbst bei kleiner Schleife 
nur Nullen rauskommen! Verwirrung weicht Verzweiflung.

[SkyperHH (Gast)]

Welche Baudrate zum senden? Was für einen Quarz verwendest Du?

[Schlumpf (Gast)]

Stimmt deine Abfrage, ob der UART sendebereit ist?

[Justus S. (jussa)]

willst du nicht mal endlich den ganzen Code posten, anstatt immer nur 
Bruchstücke?

[Stephan (Gast)]

SkyperHH schrieb:
> Welche Baudrate zum senden? Was für einen Quarz verwendest Du?

38,4k, 16MHz

Schlumpf schrieb:
> Stimmt deine Abfrage, ob der UART sendebereit ist?

Normal senden tut er ja ohne Murren.

[Schlumpf (Gast)]

Stephan schrieb:
> Normal senden tut er ja ohne Murren.

Na ja aber wenn deine Abfrage immer "true" ist, dann sendet er, sobald 
er in die Funktion kommt. Ist zu dem zeitpunkt aber der vorangegangene 
Sendevorgang noch nicht abgeschlossen, dann.....

Und hast du parallel noch irgendwelche Interrupts am laufen?

[Stephan (Gast)]

Schlumpf schrieb:
> Und hast du parallel noch irgendwelche Interrupts am laufen?

Ja, Windows!

Ich habe 0 Ahnung, warum, aber nach An-und-Ausmachen von Windows klappt 
es plötzlich. 2h für die Tonne!
Danke für die Unterstützung!

[SkyperHH (Gast)]

Die 0,2% Fehlerrate sollten nicht das Problem sein...


Stephan schrieb:
> SkyperHH schrieb:
>> Welche Baudrate zum senden? Was für einen Quarz verwendest Du?
>
> 38,4k, 16MHz

[Schlumpf (Gast)]

Stephan schrieb:
> Ja, Windows!

Ach du Schreck ;-)

[Stephan (Gast)]

Schlumpf schrieb:
> Ach du Schreck ;-)

Das ist wie mit dem Alkohol. Es schadet nur aber man kann auch nicht 
ohne.

[Schlumpf (Gast)]

Stephan schrieb:
> Das ist wie mit dem Alkohol. Es schadet nur aber man kann auch nicht
> ohne.

Aber Alk macht mehr Spass ;-)

[Stefanus (Gast)]

War das ein Witz mit dem reboot? Oder läuft es jetzt tatsächlich 
problemlos?

[Stephan (Gast)]

Stefanus schrieb:
> War das ein Witz mit dem reboot? Oder läuft es jetzt tatsächlich
> problemlos?

Leider kein Witz! Alles gut! Vielleicht hatte AVRStudio einen Pups quer.