Attiny 441 UART

Stefan Gast #3926941
Lesenswert?
• ▲
▼ 
Hallo,

Ich verzweifle gerade an einem Attiny 441.

den Artikel 'serielle Schnittstelle fehlerhaft, ATtiny441' habe ich 
gelesen und das Programm daraus benutzt. Der tiny ist im 
Auslieferungszustand CKDIV8 ist gesetzt.
An Port A Pin 3 hängt eine LED.
An RX0/TX0 hängt ein USB Konverter mit prolific Chip, RX/TX verbunden 
erzeugt auf dem Terminal ein Echo.
RX/TX Verbindung zum tiny mehrmals gecheckt und vertauscht.
Mit einkommentiertem Code in main blinkt die Led.
Das toggeln in der ISR bzw. das Echo funktioniert nicht.

mein code :

1
#define F_CPU           1000000UL 

2
#define UART_BAUD_RATE  9600UL

3


4
#include <avr/io.h>

5
#include <avr/interrupt.h>

6
#include <util/delay.h>

7


8
void UART_Init( unsigned int baud )

9
{

10
  int UBRR_value = 51; // (F_CPU/(baud*16))-1; //UBRR setzen

11
  

12
  UBRR0H = (unsigned char) (UBRR_value >> 8);

13
  UBRR0L = (unsigned char) UBRR_value;

14
  

15
  UCSR0B = (1<<RXEN0)|(1<<TXEN0)|(1<<RXCIE0); //RX, TX, RXinterrupt aktivert

16
  

17
  UCSR0C = (1<<UCSZ01)|(1<<UCSZ00); //Frame format: 8N1

18
}

19


20
void UART_Transmit( char data )

21
{

22


23
  while( !( UCSR0A & (1<<UDRE0)) );   //auf leeren transmitbuffer warten

24
  UDR0 = data;                        //daten in buffer legen und senden

25
}

26


27
ISR (USART0_RX_vect)

28
{

29
  PORTA ^= 1<<PA3;  

30
    

31
  char daten = UDR0;

32
  UART_Transmit(daten);

33
}

34


35


36
int main(void)

37
{

38
  DDRA  = 1<<DDRA3;

39
  PORTA = 0;  

40
  

41
  UART_Init(UART_BAUD_RATE);

42
  sei(); //Interrupt reset

43
  while(1)

44
  {

45
    //PORTA ^= 1<<PA3;

46
    //_delay_ms(500);

47
  }

48
}


Sieht irgendwer wo der Fehler ist.

Stefan
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Cyblord -. #3926944
Lesenswert?
• ▲
▼ 
Die 441/841 haben remapbare UART Pins. Hast du die korrekten RXD0 und 
TXD0 kontaktiert? Sollten PA1 und PA2 sein.



UBBR kannst du direkt als WORD beschreiben und dir den Hi Low Quatsch 
sparen. ist übersichtlicher und weniger Fehlerträchtlig.

so:

1
UBRR0=51;


Ohne in das DB zu sehen: Für 8N1 habe ich noch nie eine Änderung in 
UCSR0C vornehmen müssen. Was setzt du da für Bits?

Schonmal in deiner main ein UART_Transmit ausgeführt? Ob da was ankommt?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #3926952
Lesenswert?
• ▲
▼ 
Wenn man eine UART in Betrieb nimmt, ist es eine extrem gute Idee, erst 
mal mit der Datenrichtung AVR->PC anzufangen. Und zwar nur mit dieser 
Datenrichtung.

Alles was zunächst damit zu tun hat, dass der AVR was empfangen muss, 
ist nichts weiter als ein Stochern im Nebel, wenn es nicht funktioniert. 
Die reine Datenrichtung AVR->PC ist da wesentlich besser geeignet. Unter 
anderem auch deswegen, weil man am AVR ein Dauersenden programmieren 
kann und man sich dann mit einer LED auf Hardware Fehlersuche begeben 
kann, wo eine eventuelle falsche Auskreuzung in den Verbindungen drinnen 
ist. LED samt Vorwiderstand nach GND verschalten und mit dem heissen 
Ende der LED vom Tx Pin ausgehend das Signal verfolgen. Ist man am 
Signal drauf, sieht man die LED bei einigermassen kleinen Baudraten 
(9600 geht auf jeden Fall) wunderbar flackern.

1
....

2


3


4
int main()

5
{

6
  ...

7


8
  UART_Init(UART_BAUD_RATE);

9


10
  while( 1 ) {

11


12
    UART_Transmit( 'x' );

13


14
    ev. noch ein _delay_ms( 100 );

15
  }

16
}


Damit macht man sich auf die Fehlersuche, bis man am PC im Terminal die 
'x' sieht. Wenn das klappt, dann klappt im Regelfall auch die umgekehrte 
Richtung auf Anhieb.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan Gast #3927094
Lesenswert?
• ▲
▼ 
Cyblord ---- schrieb:
> Die 441/841 haben remapbare UART Pins. Hast du die korrekten RXD0 und
> TXD0 kontaktiert? Sollten PA1 und PA2 sein.

Nein, natürlich nicht! die Drähte hängen an P7,B0. Ich kann es zwar 
heute nicht mehr testen aber ich denke das war's.
Vielen Dank,natürlich auch an alle anderen!
Stefan
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan Gast #3929713
Lesenswert?
• ▲
▼ 
Hallo,
nachdem das Problem mit der UART ja dank cyblord schnell geklärt war nun 
das Nächste. Sobald ich die Uart enable
UCSR0B = _BV(TXEN0);
lassen sich an PA1 und PA2 keine Pullups mehr aktivieren, egal in 
welcher Reihenfolge ich initialisiere. Laut Datenblatt sollte ja kein 
Override stattfinden (PA1.PUOE = TXEN0 • !U0MAP).
Hat jemand einen Tip?
Hier jetzt mal nur die releventen Teile des Code in einer Funktion 
zusammengefasst, mir ist klar das auch noch entprellt werden muss.



1
int main (void)  {

2
  // usart

3
  UBRR0  =  51;

4
  REMAP |= _BV(U0MAP);  

5
  // UCSR0B = _BV(TXEN0);

6
  

7
  // led

8
  DDRA    =   _BV(DDRA3);  

9
  

10
  // switch

11
  DDRA    &= ~_BV(PIN1);

12
  PUEA    |=  _BV(PIN1);

13
  PCMSK0  |=  _BV(PIN1);

14
  GIMSK   |=  _BV(PCIE0);  

15
  

16
  set_sleep_mode (SLEEP_MODE_IDLE);    

17
  sei();

18
  

19
  while (1) {

20
    // while (!(UCSR0A & _BV(UDRE0)));

21
    // UDR0 = 'm';

22
    

23
    PORTA ^=  (1<<PA3);

24
    sleep_mode();

25
  }

26
  

27
}

28


29
ISR (PCINT0_vect) {

30
  PORTA ^=  (1<<PA3);

31
  

32
  // while( !( UCSR0A & _BV(UDRE0)) );

33
  // UDR0 = 'i';

34
}


Stefan
Antwort Zitieren Bearbeiten Löschen Beitrag melden
spess53 Gast #3931099
Lesenswert?
• ▲
▼ 
Hi

>lassen sich an PA1 und PA2 keine Pullups mehr aktivieren, egal in
>welcher Reihenfolge ich initialisiere. Laut Datenblatt sollte ja kein
>Override stattfinden (PA1.PUOE = TXEN0 • !U0MAP).

>ich kann im Datenblatt nichts erkennen,das darauf hinweist. Im Notfall
würde ich zu einer Hardware Lösung greifen und externe Pullups auflöten.

Datenblatt:

Bit 4 – RXENn: Receiver Enable
Writing this bit to one enables the USART Receiver. When enabled, the 
receiver will override normal port operation for
the RxDn pin.

MfG Spess
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Cyblord -. #3931137
Lesenswert?
• ▲
▼ 
MagIO2 schrieb:
> Darf ich mal ne Zwischenfrage stellen?
>
> Womit programmierst du den 441er? Im Studio 6.2 lässt er sich nicht mit
> einem SDK500 kompatiblen Progger programmieren und AVRdude kennt ihn
> auch nicht!

Also ich progge regelmäßig den 841 und habe dazu einfach die Configdatei 
des avrdude angepasst. Es gibt hier im Forum sogar 2 Threads zum 841 wo 
diese Anpassungen rumschwirren. Einfach mal danach suchen.

@spess:

Dass der UART die Ports überschreibt ist klar, aber hier werden, nach 
dem remap, vom UART ungenutze Ports anscheinend überschrieben.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Stefan Gast #3934417
Lesenswert?
• ▲
▼ 
spess53 schrieb:
> Bit 4 – RXENn: Receiver Enable
> Writing this bit to one enables the USART Receiver. When enabled, the
> receiver will override normal port operation for
> the RxDn pin.

Hallo spess53,
ich habe aber damit gerechnet das er mir dann nur den PB2 überschreibt 
denn das ist ja der RX. Und (PA1.PUOE = TXEN0 • !U0MAP) deutet ja 
irgendwie darauf hin das Atmel das wohl auch so geplant hatte.

MagIO2 schrieb:
> Womit programmierst du den 441er?

Hallo MagIO2,
ich benutze den ISP MKII. Ich denke mal das dein 'kompatibler' so 
kompatibel dann nicht ist. Vielleicht kann man ja die Firmware upgraden. 
Ich hab im 2.6 auch Probleme mit einem 'kompatiblen' ISP MKII.

Cyblord ---- schrieb:
> Dass der UART die Ports überschreibt ist klar, aber hier werden, nach
> dem remap, vom UART ungenutze Ports anscheinend überschrieben.

blöd das, ich hätte gerne optional den AC0 benutzt. Zumindest scheint ja 
mein Code korrekt zu sein. Na ja man kann nicht alles haben. 
Erstaunlicherweise ist dazu nichts im Internet zu finden.

Stefan
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren