ATtiny2313 verschluckt Zeichen beim Senden

[Jürgen S. (jsachs)]

Hallo,

ich versuche gerade unter linux den I2C sniffer aus einem Thread von 
hier ans laufen zu bringen.

Im Prinzip kann ich das Programm compilieren, in den Tiny laden und sehe 
auch die Startmeldung. Allerdings nur zum Teil.
Er verschluckt mir immer Teile von den zu sendenden Daten.

Also die Baudrate stimmt, ich sehe ja zum Teil was ich sehen will.
Als Takt habe ich den internen 8MHz und einen Externen 8MHz Quarz 
versucht.
Als Baudrate schon 38400, 19200 und nun 9600. Ohne Änderung
Das ganze betreibe ich in einem Pollin Eval Board.
Ein ATmega32 geht in dem Board problemlos, also schließe ich mal die 
Hardware aus.


Ich bin mit meinem Latein am Ende.
Ich habe das Programm schon komplett von Interrupt auf "Polling" beim 
Senden umgestellt und Interrupts aus. Gleicher Effekt.

Ich stürze mich gleich aus dem Keller Fenster oder lege mich hinter den 
Zug...

Ich versuche jetzt noch ein Miniprogramm und werde das noch Posten, 
damit Ihr keine Glaskugel braucht.

Achja, ich nutze natürlich AVR-GCC, bin mir aber nicht sicher ob das 
eher unter "Elektronik" gehört...

Gruss
Juergen

[Jürgen S. (jsachs)]

So, ich habe das eben nochmals mit einem mini program und einem zweiten 
ATtiny2313 geprüft. Gleiches Ergebnis.

Ich erhalte z.B. nur "1247adghknqst"

Einen Baudratenquarz habe ich nicht. Aber 38400 sollte normalerweise ja 
ohne gehen. Hatte ich noch nie Probleme mit den ATmega32, zumindest bei 
externem Quarz.

Nachfolgend der Code. Wie gesagt eine "Verzweiflungstat"

#include <avr/pgmspace.h>
//#include "main.h"
//#include "uart.h"
//#include "i2csniff.h"

#define nop() asm("nop;")
#define _BVC(x) ((0<<x))


void uart_putc(char c)
{
   while ( ! ( UCSRA&_BV ( UDRE ) ) )
    {
        nop();
    }

    UDR = c; 
}

void initUart ( uint16_t baud )
{
    uint16_t ubrr = ( uint16_t ) ( ( ( uint32_t ) F_CPU / ( 16UL * baud ) ) - 1 );

    UBRRH = ( uint8_t ) ( ubrr << 8 ) & 0x0F;
    UBRRL = ( uint8_t ) ( ubrr & 0xFF );

    UCSRA = _BVC(U2X) | _BVC(MPCM);

    UCSRB = _BV ( RXEN ) | _BV ( TXEN ) | _BV( RXCIE ) | _BVC(UCSZ2);

    UCSRC = /*_BV ( URSEL ) |*/ _BVC(UMSEL) | _BV ( UCSZ1 ) | _BV ( UCSZ0 ) | _BVC(USBS) | _BVC(UPM1) | _BVC(UPM0) | _BVC(UCPOL);

    //uartClearRxBuffer();

}

int main( void )
{
  // init trigger output
  //DDRD  |= (1<<5);

  /*
   *  Initialize UART library, pass baudrate and AVR cpu clock
   *  with the macro 
   *  UART_BAUD_SELECT() (normal speed mode )
   *  or 
   *  UART_BAUD_SELECT_DOUBLE_SPEED() ( double speed mode)
   */
  initUart( 9600 ); 

  //init_i2c();
  //sei();
  //uart_puts("I2C-Sniffer" LINEFEED);
  //uart_puts_p(PSTR("This is a test"));
  uart_putc('1');
  uart_putc('2');
  uart_putc('3');
  uart_putc('4');
  uart_putc('5');
  uart_putc('6');
  uart_putc('7');
  uart_putc('8');
  uart_putc('9');
  uart_putc('a');
  uart_putc('b');
  uart_putc('c');
  uart_putc('d');
  uart_putc('e');
  uart_putc('f');
  uart_putc('g');
  uart_putc('h');
  uart_putc('i');
  uart_putc('j');
  uart_putc('k');
  uart_putc('l');
  uart_putc('m');
  uart_putc('n');
  uart_putc('o');
  uart_putc('p');
  uart_putc('q');
  uart_putc('r');
  uart_putc('s');
  uart_putc('t');
  uart_putc('u');
  
  while(1){};
  /*
   * Transmit string from program memory to UART
   */
  //uart_puts_P("String stored in FLASH\n");
    //i2c_sniff();
    for(;;){}      // avoid warning (but never reached)
}

[Karlheinz (Gast)]

Hallo,

Jürgen Sachs schrieb:
> #define _BVC(x) ((0<<x))
und auch
> while ( ! ( UCSRA&_BV ( UDRE ) ) )

was soll das ???

Dieser Code, den du uns da zeigst, ist nie gelaufen - weder im Compiler 
noch im Attiny.

[Georg A. (georga)]

> was soll das ???

Naja, BVC ist etwas unkonventionell, aber deutet halt an, dass das Bit 
eine 0 sein soll.

Was an dem while syntaxmässig falsch sein soll, sehe ich gerade nicht...

[Peter D. (peda)]

Jürgen Sachs schrieb:
> Ich erhalte z.B. nur "1247adghknqst"

Ich würd mal sagen, Dein Empfänger ist zu langsam und verliert Zeichen.

Setze mal die Baudrate runter.
Wenn es ein Fehler im Sender wäre, müßten dann die Lücken noch größer 
werden.

[Jürgen S. (jsachs)]

Also was an dem while falsch sein soll, weis ich nicht.

Das "_BVC()" benutze ich nur, wenn ich immer ein komplettes Register 
stetze, es aber Bits gibt die NULL sein müssen.
So kann ich alle Bits aufführen und weis ich habe nichts vergessen.

Ist quasi das Gegenstück zu "_BV()"
Find ich übersichtlicher.

Das Programm läuft sehr wohl im Compiler und im Tiny.

Ich habe das Programm gestern noch modifiziert, das es nach jedem Byte 
eine gehörige Pause einlegt. Selbes Ergebnis. Baudrate war nur 9600.

Als Serielle Benutze ich FTDI USB Wandler. Ich habe bisher nur gute 
Erfahrungen damit gemacht mit einem Mega32.
Wie gesagt mit einem ATmega32 geht das ja. Aber ich mache gleich mal 
einen gegen test.
Tiny aus dem Board raus, MEga rein und und Program drauf (neukompilieren 
natürlich)

[Jürgen S. (jsachs)]

So, gegen test gemacht mit mega32 und es geht auch nicht richtig.
Also mit ner echten Seriellen geprüft und siehe da es geht.

Nun Frage ich mich, wieso ich damit seit 2 Wochen Problemlos RS232 
debuggen konnte ?!??!

Danke erst mal
Juergen

[Jürgen S. (jsachs)]

Und hier kommt die Lösung kopfvordiewandhau

Ich kann unter linux mit minicom das Device "dev/ttyUSB0" mehrfach 
öffnen.
Und irgendwie habe ich das gestern Abend versehentlich gemacht, statt 
eines auf USB0 und eines auf USB1.

Logisch das die sich um die Daten gestritten haben.

Manchmal sollte man in der NAcht einfach ne Pause machen (schlafen) :-)

Danke nochmal
Juergen

PS: auch wenn jetzt erstmal der Test mit dem I2C sniffer ansteht....

[Peter D. (peda)]

Dann war ja meine Vermutung richtig, daß der Empfänger das Problem ist.

Solchen Quatsch läßt Windows garnicht erst zu. Da gibts den dicken 
Daumen, wenn man die selbe COM nochmal öffnen will.

[Jürgen S. (jsachs)]

Peter Dannegger schrieb:
> Dann war ja meine Vermutung richtig, daß der Empfänger das Problem ist.
>
> Solchen Quatsch läßt Windows garnicht erst zu. Da gibts den dicken
> Daumen, wenn man die selbe COM nochmal öffnen will.

Normalerweise habe ich die Meldung bei der internen Schnittstelle auch.
Daher bin ich ja nicht auf die Idee gekommen da zu suchen.

Gibt es dann auch eine Fehlermeldung.
Ich weis jetzt auch wie das geht :-)
USB Converter ran, minicom öffnen, usb converter abziehen
USB converter ran und wieder in neuem minicom öffnen
Aber der Alte ist ja noch aktiv, erkennt das und macht den auch wieder 
auf....
Nunja

Gegen ein Level 8 Fehler ist kein Betriebssystem sicher ;-)

Juergen

[Georg A. (georga)]

> Solchen Quatsch läßt Windows garnicht erst zu. Da gibts den dicken
> Daumen, wenn man die selbe COM nochmal öffnen will.

Das ist kein Quatsch. Ich finde das im Gegenteil extrem praktisch, hatte 
schon genügend Anwendungen, wo RX und TX getrennte Anwendungen waren...

> Aber der Alte ist ja noch aktiv, erkennt das und macht den auch wieder
> auf....

Dann musst du einen der seltenen Adapter mit Seriennummer haben. 
Normalerweise wird, wenn das Device noch offen ist, beim Einstecken ein 
neues angefangen.

[Peter D. (peda)]

Jürgen Sachs schrieb:
> USB Converter ran, minicom öffnen, usb converter abziehen

Sowas mag Windows garnicht.
Wenn Du ner Applikation die COM unterm Hintern wegziehst, crasht diese.
Die Applikation ruft fröhlich Funktionen mit einem Handle auf, der 
garnicht mehr existiert. Er wird mit dem erneuten Einstecken auch nicht 
wieder existent.

[Jürgen S. (jsachs)]

Windows würde hier vermutlich sogar den COM Port Nummer ändern.
Das Bringt mich immer zur Weisglut.
Mal ist es COM4, dann COM9, dann COM5.... (Gleicher USB Port)

Gruss
Juergen

[Simon K. (simon)]

Jürgen Sachs schrieb:
> Windows würde hier vermutlich sogar den COM Port Nummer ändern.
> Das Bringt mich immer zur Weisglut.
> Mal ist es COM4, dann COM9, dann COM5.... (Gleicher USB Port)
>
> Gruss
> Juergen

Nur wenn du es an einen anderen USB Port einsteckst.