Forum: Mikrocontroller und Digitale Elektronik Attiny 441 UART


von Stefan (Gast)


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

von Cyblord -. (cyblord)


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?

von Karl H. (kbuchegg)


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.

von Stefan (Gast)


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

von Stefan (Gast)


Lesenswert?

Edit A7,B2.
Stefan

von Stefan (Gast)


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

von Yves (Gast)


Lesenswert?

Hallo Stefan,

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.

von spess53 (Gast)


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

von MagIO2 (Gast)


Lesenswert?

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!

von Cyblord -. (cyblord)


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.

von Stefan (Gast)


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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.