tiny4313 uart sendet erst nach reset

[Roland H. (blacksmoke85)]

habe folgendes problem. habe für den uart ein protokoll geschrieben das 
kommandos entgegennimmt und dann wieder zurücksendet. dieses tut auch 
soweit. nun bin ich auf folgendes problem gestoßen:
wenn ich versorgungsspannung wegnehme und nach ner zeit wieder anlege, 
kommt es manchmal vor, dass der tiny erst nach drücken von reset auf 
eine anfrage reagiert.
soweit ich weiß, sollte aber der tiny nach dem einschalten von haus aus 
einen reset durchführen. tiny deffekt ?

braucht das init() eine mindestwartezeit bevor dieser benutzt werden 
kann ?


hat jemand eine erklärung dafür ?

[Brat (Gast)]

Warum hältst du dich nicht an die Netiquette und beachtest z. B. die 
Groß-/Kleinschreibung?

[spess53 (Gast)]

Hi

Wie sehen die Einstellungen für Takt und SUT (Fuses) aus?

MfG Spess

[Roland H. (blacksmoke85)]

getaktet wird er mit einem externen Quatz mit 16MHz

         F_CPU = 16000000

die fuses sehen im makefile so aus:

AVRDUDE_WRITE_LFUSE = -U lfuse:w:0xef:m
AVRDUDE_WRITE_HFUSE = -U hfuse:w:0xdf:m
AVRDUDE_WRITE_EFUSE = -U efuse:w:0xff:m

[Karl H. (kbuchegg)]

Roland Höck schrieb:

> hat jemand eine erklärung dafür ?

Zeig mal dein Programm.

Du musst immer bedenken, dass eine UART Übertragung eine Abfolge von 
Zuständen auf diversen Leitungen ist. Diese Leitungen haben aber nach 
dem Anlegen der Spannung aber schon Pegel, noch ehe die entsprechende 
Hardware dafür konfiguriert wurde. D.h. nach dem Einschalten kann es 
schon mal sein, dass irgendeine Hardware zb einen Fehlerzustand meldet, 
der nur daraus resultiert, dass die Hardware schon auf die Pegel an den 
Leitungen angesprochen hat obwohl du das noch gar nicht wolltest. Bei 
Interruptpins ist das zb genau dasselbe.

Wenn dein Programm sich jetzt aber nicht mehr von alleine aus einem 
derartigen Fehlerzustand rausmanövrieren kann, dann sieht es so aus, als 
ob alles hängt.

Daher: wie sieht das Programm aus.

[Roland H. (blacksmoke85)]

hier der relevante code

[Karl H. (kbuchegg)]

Woher kommen die Kommandos?
Sendet der Sender bereits, wenn du den Tiny einschaltest?


Das hier

int8_t befehl_speichern(uint8_t *Data_Array)
{
  uint8_t Zaehler = 0;
  uint8_t UART_block = 0;
  uint8_t buffer = 0;
  Data_Array[2]=0;

  for(int i = 0;i<=9;i++)
  {
    Data_Array[i]=0;
  }

  while((Zaehler < (Data_Array[2])+4))       // solange noch nicht letzter Block
  {
    UART_block = rx_block();               // rx_block -> UART_Block holen
    if(UART_block & FS)                     // wenn FS == 1
    {
      Zaehler = 1;
      Data_Array[Zaehler-1] = UART_block; // Ziel ID in Data_Array[Zähler-1] speichern
    }
    else                                    // wenn FS == 0
    {
      if(Zaehler == 2)
      {
        buffer = UART_block;            // Type in Data_Array[Zähler-1] speichern
        buffer >>= 3;                   // um 3 nach rechts schieben -> type steht jetzt ganz rechts
        Data_Array[Zaehler-1]= buffer;
        Zaehler++;
        UART_block &= 0x07;             // length in Data_Array[Zähler-1] speichern
        Data_Array[Zaehler-1] = UART_block;
      }
      else
      {
        Data_Array[Zaehler-1] = UART_block; // Data(Z-3) in Data_Array[Zähler-1] speichern
      }
    }
    Zaehler++;
  }

  Zaehler = 0;                                // while Ende
  return 0;
}

ist potentiell gefährlich.
Nachdem ich die Einrückungen korrigiert habe, sieht man recht gut, dass 
es für den Fall, dass der Sender bereits fleissig am Senden ist, 
durchaus den Fall gibt, dass das erste empfangene Zeichen eben kein 
gesetztes FS haben kann und dass du dann Gefahr läufst, ober den Weg

    if(UART_block & FS)                     // wenn FS == 1
    {
    }
    else                                    // wenn FS == 0
    {
      if(Zaehler == 2)
      {
      }
      else
      {
        Data_Array[Zaehler-1] = UART_block; // Data(Z-3) in Data_Array[Zähler-1] speichern
      }
    }
    Zaehler++;

ganz einfach dein Array zu überlaufen.

Wie ist das Protokoll aufgebaut? IMHO ist das nicht so gut 
implementiert. Wenn es eine dezidierte Start-Kennung gibt, die auch 
sicher erkannt werden kann, dann fängt eine Auswertung besser damit an, 
dass man erst mal genau auf diese Startkennung wartet und alle anderen 
Bytes verwirft. Erst dann, nachdem die Startkennung erhalten wurde, 
beginnt man damit diverse Buffer mit den Zeichen zu füllen.

.....

  // auf die Startkennung warten
  do
  {
    c = rx_block();
  } while( !( c & FS ) );
  Data_Array[0] = c;

  // das erste Byte ist da, das nächste Byte ist die Länge
  Len = rx_block();
  Data_Array[1] = Len;

  if( Len > 8 )
    return Fehler;

  // jetzt diese Anzahl an Bytes einlesen
  for( i = 0; i < Len; i++ )
    Data_Array[i+2] = rx_block();
...

Voraussetzung ist, dass das hier

     .... c & FS ....

absolut eindeutig ist, und in den Daten nicht vorkommen kann. Denn dann 
kann man den Anfang eines Datensatzes nicht mehr eindeutig erkennen und 
dann ist man in solchen Fällen sowieso in der Breduille. Mit etwas Glück 
kann einen vielleicht die dann mglw. fehlerhafte Länge aus dem 
Schlamassel rausholen, aber garantiert ist das nicht, und es lassen sich 
immer Fälle konstruieren, in der die ganze Übertragung hängt und auch 
nicht mehr von alleine auf die Füsse fällt.

[Roland H. (blacksmoke85)]

im prinzip soll ja wenn ein FS kommt das array neu befüllt werden.
wo ist das nicht gut implementiert ?

das protokoll ist folgendermaßen aufgebaut


bit: 7   6 - 0        7   6 -3   2 - 0       7   6 - 0
     FS | ID         FS | Type | length     FS | Data0  ....


für den fall, dass die nachricht nicht komplett empfangen wird, wartet 
der tiny einfach. nach einer gewissen zeit, sendet dann der master die 
nachricht erneut, und es kommt wieder ein FS -> Zähler = 1 -> Array wird 
neu befüllt

theoretisch wird zuerst der tiny eingeschaltet und dann gesendet.

FS soll den Framestart signalisieren und nur im Block ID "1" ansonsten 
"0" sein

[Karl H. (kbuchegg)]

Roland Höck schrieb:
> im prinzip soll ja wenn ein FS kommt das array neu befüllt werden.
> wo ist das nicht gut implementiert ?

Wenn dir eine Startkennung, aus welchem Grund auch immer, verloren geht, 
kann es dir passieren, dass du dir das Array und den nachfolgenden 
Speicher mit Bytes flutest.

Siehe den Alternativcode, der dieses Problem nicht hat. Wenn dort eine 
Startkennung verloren geht, dann wird alles weitere was reinkommt bis 
zur nächsten korrekt erkannten Startkennung verworfen.

[Karl H. (kbuchegg)]

Roland Höck schrieb:

> FS soll den Framestart signalisieren und nur im Block ID "1" ansonsten
> "0" sein


Das war nicht die Frage.
Die Frage lautet: kann diese Bitkombination auch in den Datenbytes 
vorkommen?

Denn wenn es das kann, dann kannst du dir das FS-Bit auch gleich in die 
Haare schmieren. Es ist zu nichts nütze.

[Roland H. (blacksmoke85)]

ah ok jetz versteh ich schon was du meinst. natürlich soll es auch von 
mir aus so sein, das er bis zum nächsten FS alles verwirft und dann erst 
anfängt. hab jetz die Zeile

UART_block = rx_block()

durch

do
{
     UART_block = rx_block();
while( !( UART_block & FS ) );

ersetzt und werde das nachher testen und hoffen das es damit erledigt 
ist

und das Protokoll ist so gebaut, dass das vorderste bit immer für FS da 
ist. und wird auch für nichts anderes benutzt. also stehen mir für 
daten,... jeweils 7 bit zur verfügung. FS = 1 taucht wirklich nur am 
anfang der Nachricht auf

[Karl H. (kbuchegg)]

Im Zweifelsfall:
Wenn möglich, sieh zu, dass du den Rückkanal der UART dazu benutzen 
kannst, da Statusmeldungen auszugeben.
Dann kannst du die Empfangsroutine soweit pimpen, dass du über die 
Rückmeldungen nachvollziehen kannst, was der Tiny eigentlich kriegt und 
wie er es auswertet.

[Karl H. (kbuchegg)]

Roland Höck schrieb:

> ist. und wird auch für nichts anderes benutzt. also stehen mir für
> daten,... jeweils 7 bit zur verfügung. FS = 1 taucht wirklich nur am
> anfang der Nachricht auf

Sehr gut!
Da hast du den Fuss in der Tür, wie du empfangene Bytes auf jeden Fall 
auf den Recordanfang synchronisieren kannst (solange es keinen 
Übertragungsfehler gibt, aber lass uns jetzt mal nicht den Teufel an die 
Wand malen).

[Roland H. (blacksmoke85)]

genau den sinn hatte ja FS (Framestart) ja am anfang. habs soweit vorher 
ja schon getestet, er hat die nachrichten auch immer zuverlässig 
interpretiert und geantwortet.

[Karl H. (kbuchegg)]

Vergiss auch nicht auf eine Plausibilitätsprüfung für die Länge.
Geh immer vom schlimmsten Fall aus: Irgendwas ist grauslich schief 
gegangen und deine Empfangsroutine fängt an, Bytes die eigentlich 
Datenbytes sind mit den Steuerinfortmationen zu verwechseln. Was auf 
keinen Fall passieren darf: das dein Programm der Meinung ist, da 
müssten jetztz 58 Bytes daher kommen, weil es durch den Fehler ein Byte 
mit dem Wert 58 kriegt, wenn es eigentlich die Länge erwartet. Denn in 
dem Fall bügelst du dir dann dein Array, bzw. den dahinterliegenden 
Speicher über den Haufen. Und ab da werden dann keine Wetten mehr 
angenommen, was da alles passiert.

Eine robuste Empfangsroutine (bzw. Protokoll) überlebt es auch, wenn man 
mitten im Betrieb das Kabel rauszieht und wieder einsteckt. D.h. eine 
robuste Empfangsroutine kann sich auch mitten in eine bereits laufende 
Übertragung einklinken und kommt nicht durcheinander.

[Roland H. (blacksmoke85)]

das protokoll war vorher eigentlich sauber geplant, und es wurden auch 
gewisse fehlersituationen berücksichtigt.

habe genau das gleich protokoll wie in meinem pap geplant jetzt auf der 
neuen grundlage gebaut also mit warten auf FS und siehe da. es is auch 
noch ein effizienterer code raus gekommen ohne viele if abfragen

und soweit ich das bisher sagen kann scheint der gut zu funktionieren.
parität wird ja übrigends in der folgeroutine überprüft und aussortiert

die länge ist ja eigentlich bei mir immer plausibel, da ich vom 2. block 
die letzten 3 bit dafür her nehme, als maximal 7 sein kann

do            // warten bis FS
{
    UART_block = rx_block();
}while( !( UART_block & FS ) );
Zaehler = 1;
Data_Array[Zaehler-1] = UART_block;
Zaehler++;
UART_block = rx_block();
buffer = UART_block;          // Type in Data_Array[Zähler-1] speichern
buffer >>= 3;               // um 3 nach rechts schieben
Data_Array[Zaehler-1]= buffer;
Zaehler++;
UART_block &= 0x07;             // length in Data_Array[Zähler-1] speichern
Data_Array[Zaehler-1] = UART_block;
Zaehler++;
while((Zaehler < (Data_Array[2])+4)) 
{
   UART_block = rx_block();
   Data_Array[Zaehler-1] = UART_block;
   Zaehler++;
}