ATtiny2313 verschluckt Zeichen beim Senden

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"

1

#include <avr/pgmspace.h>

2

//#include "main.h"

3

//#include "uart.h"

4

//#include "i2csniff.h"

5

6

#define nop() asm("nop;")

7

#define _BVC(x) ((0<<x))

8

9

10

void uart_putc(char c)

11

{

12

   while ( ! ( UCSRA&_BV ( UDRE ) ) )

13

    {

14

        nop();

15

    }

16

17

    UDR = c; 

18

}

19

20

void initUart ( uint16_t baud )

21

{

22

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

23

24

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

25

    UBRRL = ( uint8_t ) ( ubrr & 0xFF );

26

27

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

28

29

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

30

31

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

32

33

    //uartClearRxBuffer();

34

35

}

36

37

int main( void )

38

{

39

  // init trigger output

40

  //DDRD  |= (1<<5);

41

42

  /*

43

   *  Initialize UART library, pass baudrate and AVR cpu clock

44

   *  with the macro 

45

   *  UART_BAUD_SELECT() (normal speed mode )

46

   *  or 

47

   *  UART_BAUD_SELECT_DOUBLE_SPEED() ( double speed mode)

48

   */

49

  initUart( 9600 ); 

50

51

  //init_i2c();

52

  //sei();

53

  //uart_puts("I2C-Sniffer" LINEFEED);

54

  //uart_puts_p(PSTR("This is a test"));

55

  uart_putc('1');

56

  uart_putc('2');

57

  uart_putc('3');

58

  uart_putc('4');

59

  uart_putc('5');

60

  uart_putc('6');

61

  uart_putc('7');

62

  uart_putc('8');

63

  uart_putc('9');

64

  uart_putc('a');

65

  uart_putc('b');

66

  uart_putc('c');

67

  uart_putc('d');

68

  uart_putc('e');

69

  uart_putc('f');

70

  uart_putc('g');

71

  uart_putc('h');

72

  uart_putc('i');

73

  uart_putc('j');

74

  uart_putc('k');

75

  uart_putc('l');

76

  uart_putc('m');

77

  uart_putc('n');

78

  uart_putc('o');

79

  uart_putc('p');

80

  uart_putc('q');

81

  uart_putc('r');

82

  uart_putc('s');

83

  uart_putc('t');

84

  uart_putc('u');

85

86

  while(1){};

87

  /*

88

   * Transmit string from program memory to UART

89

   */

90

  //uart_puts_P("String stored in FLASH\n");

91

    //i2c_sniff();

92

    for(;;){}      // avoid warning (but never reached)

93

}

> 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...

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.

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)

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

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....

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.

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

> 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.

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.

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

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.