Einfachste USART ansteuerung funktioniert nicht.

[Peter S. (schoells)]

Hallo!

Also es tut mir leid, dass ich wahrscheinlich der 100ste bin, der diese 
Frage im Forum postet; aber trotz langer Recherche hier im Forum konnte 
ich den Fehler im Code nicht finden.

Eigentlich bin ich ja strikt nach dem Tutorial vorgegangen, aber es 
funktioniert einfach nicht.

Also: hier mal der mein Code:
----


#define F_CPU 1000000UL
#define BAUD 4800UL

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error BAUDRATEN ERROR!
#endif

#include <avr/io.h>
#include <stdlib.h>

void uart_init(void)
{
  UBRRH = UBRR_VAL >> 8;
  UBRRL = UBRR_VAL & 0xFF;

  UCSRB = (1<<RXEN)|(1<<TXEN);
  UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}

int uart_putc(unsigned char d)
{
    while (!(UCSRA & (1<<UDRE)))
    {
    }

    UDR = d;
    return 0;
}


uint8_t uart_getc(void)
{
    while (!(UCSRA & (1<<RXC)))
        ;
    return UDR;
}

int main(void)
{
  uart_init();
   DDRA  = 0xFF;             //
   DDRB  = 0xFF;             //
   PORTB = 0x03;             // Statusleds,  AVR arbeitet

  while (1)
  {


    if ( (UCSRA & (1<<RXC)) )
    {
      uint8_t c;
      c = uart_getc();
    uart_putc(c);

      PORTA = c;
    }
    else
    {

    }
  }
  return 0; // never reached
}
----

Zu den Randbedingungen:

µC: ATmega16
Ich spreche ihn über das Atmel Evaluations-Board V 2.0.1 an (bzw. 
programmiere den µC auch mit diesem (via ISP Schnittstellenadapter - mit 
AVRDude (AVR8 Burn o Mat v2)

Den String sende ich mittels hTerm als auch mit einem von mir 
programmierten Tool (in VB.net - erfolgreich getestet mittels virtual 
Serial Port) an das Board (und ja, natürlich nutze ich die RS232 
Schnittstelle zum ansprechen des µC und nicht die ISP Schnittstelle - 
des weiteren sind auch die Jumper für die Ansteuerung von RX und TX 
richtig gesetzt).

Danke im Voraus für die Hilfe!

lg
Peter

Ich bitte um eure Hilfe - allein schaffs ich glaub ich nicht - nach 3h 
Fehlersuche fast am verzweifeln.

[Oliver J. (skriptkiddy)]

Stimmt denn die Baudrate?

Funktioniert die Hardware?

Hast du ein Oszi zur Hand?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter S. schrieb:
> aber trotz langer Recherche hier im Forum konnte
> ich den Fehler im Code nicht finden.
Wenn man den Fehler im Code partout nicht findet, ist es oft so, dass 
der Fehler nicht im Code ist...

> Ich bitte um eure Hilfe - allein schaffs ich glaub ich nicht
Steck mal den uC aus und brücke dann dort die Pins RX und TX. Und jetzt 
gibst du ein Zeichen im Terminalprogramm ein und kontrollierst, ob du es 
zurückbekommst. Eine positive Gegenprobe ist, wenn du keines mehr 
zurückbekommst, sobald du die Brücke wieder aufmachst (sonst ist lokales 
Echo aktiv, dann müsstest du für jedes ausgegebne Zeichen 2 gleiche 
zusückbekommen).
Wenn das geht, dann funktioniert mal deine Hardware bis und vom uC.
(Es könnte allerdings noch sein, dass RX und TX vertauscht sind...)

> - nach 3h Fehlersuche fast am verzweifeln.
Du hast aber ein niedriges Frustniveau...  :-o

[Peter S. (Gast)]

> Stimmt denn die Baudrate?
Die ist mit 4800 im Terminal Prog eingestellt

> Hast du ein Oszi zur Hand?
Nein leider - ist nicht im Budget :(

>> Ich bitte um eure Hilfe - allein schaffs ich glaub ich nicht
>Steck mal den uC aus und brücke dann dort die Pins RX und TX. Und jetzt
gibst du ein Zeichen im Terminalprogramm ein und kontrollierst, ob du es
zurückbekommst. Eine positive Gegenprobe ist, wenn du keines mehr
zurückbekommst, sobald du die Brücke wieder aufmachst (sonst ist lokales
Echo aktiv, dann müsstest du für jedes ausgegebne Zeichen 2 gleiche
zusückbekommen).
Wenn das geht, dann funktioniert mal deine Hardware bis und vom uC.
(Es könnte allerdings noch sein, dass RX und TX vertauscht sind...)
Danke für diesen Tip!
Bin gerade bei der Arbeit, werd dies aber sofort probieren, wenn ich 
zuhause bin.

Da jedoch das Board 2 Tage alt ist, und der µC 2 Wochen hoffe ich doch, 
dass es kein Hardwarefehler ist....

---
Was ich noch anführen möchte:
Ich verwende als Verbindung zum Board ein USB to RS232 Kabel. Könnten 
sich darin eigentlich Bugs verstecken. Der Treiber wurde richtig 
installiert und die COM Schnittstelle wird erkannt. (Betriebssystem 
Windows 7 - 64bit) - und beschreiben lässt sich der µC ja auch mit 
diesem Kabel.

[Edi R. (edi_r)]

Täusche ich mich, oder ist nirgendwo der globale Interrupt 
eingeschaltet? Ich finde nirgendwo das "sei();"

[Arne (Gast)]

Edi R. schrieb:
> Täusche ich mich, oder ist nirgendwo der globale Interrupt
> eingeschaltet? Ich finde nirgendwo das "sei();"

Wozu soll das bei Polling gut sein?

[Karl H. (kbuchegg)]

Peter S. schrieb:

> Da jedoch das Board 2 Tage alt ist, und der µC 2 Wochen hoffe ich doch,
> dass es kein Hardwarefehler ist....

Darum gehts nicht.
Aber zwischen µC und PC ist ein Kabel und das gibt es in 2 Ausführungen. 
Einmal mit den Adern gekreuzt und einmal gerade durchverbunden. Wenn du 
das falsche hast, dann geht nichts.
Mit dem Test kannst du erst mal fststellen, ob soweit alles in Ordnung 
ist.

Dann: Für deine weiteren Tests nimmst du vom µC aus erst mal nur das 
Senden in Betrieb. D.h. dein µC sendet ständing und in einer Schleife 
ein bestimmtes Zeichen (zb ein 'x'). Bei deinem Test müssen schon 2 
Dinge klappen, Empfangen und Senden. Senden könntest du relativ leicht 
testen aber Empfangen kannst du nur über Umwege durchprüfen. Also lass 
es fürs erste weg und konzentrier dich auf die Dinge, die du prüfen 
kannst.
Lass deinen µC in einer Schleife ein 'X' senden. Zur Not kann man das 
UART-Signal auch mit einer LED vom µC-Pin bis hin zum Stecker, Kabel und 
PC verfolgen. Bei 4800 Baud sieht man die LED noch wunderbar flackern.

[Michael (Gast)]

Peter S. schrieb:
> #define F_CPU 1000000UL

Läuft deine CPU auch mit der angegebenen Frequenz (Quarz, Fuse-Bits)?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Michael schrieb:
> Läuft deine CPU auch mit der angegebenen Frequenz (Quarz, Fuse-Bits)?
Am PC würde auch mit der falschen Baudrate irgendwas ankommen, wenn 
die Hardware passt.

[Peter S. (Gast)]

>> #define F_CPU 1000000UL
>Läuft deine CPU auch mit der angegebenen Frequenz (Quarz, Fuse-Bits)?

jop, sollte damit laufen. Habe bei der Taktfrequenz nichts umgestellt - 
und der ATmega16 läuft ja von Haus aus mit 1MHz.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter S. schrieb:
> und der ATmega16 läuft ja von Haus aus mit 1MHz.
Oha, interner Takt und RS232...
Viel Glück damit.

[Markus O. (pipimaxi)]

Lothar Miller schrieb:
> Peter S. schrieb:
>> und der ATmega16 läuft ja von Haus aus mit 1MHz.
> Oha, interner Takt und RS232...
> Viel Glück damit.

naaaja, 1MHz und 4800er Baudrate sollte drin sein.
An deiner Stelle würde ich erstmal das Senden µC->PC testen, kannst auch 
zum minimalen Debug ne LED an die TX Strippe hängen und das Senden in 
einer While-Schleife mit nem kleinen Delay zyklisch ablaufen lassen.
Es sollten Unterschiede in der Helligkeit der LED erkennbar sein, wenn 
das Ding sendet.

MfG

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Markus Oberle schrieb:
> naaaja, 1MHz und 4800er Baudrate sollte drin sein.
Die absolute Geschwindigkeit tut nichts zur Sache, wenn die 
Abweichung (des Taktes an sich) zu groß ist...

[Markus O. (pipimaxi)]

Lothar Miller schrieb:
> Markus Oberle schrieb:
>> naaaja, 1MHz und 4800er Baudrate sollte drin sein.
> Die absolute Geschwindigkeit tut nichts zur Sache, wenn die
> Abweichung (des Taktes an sich) zu groß ist...

Jitter, Temperaturdrift....alles Käse :D
Aber ja, mit dem ATmega168 mit internen 8MHz Takt und 115200 Baudrate 
hatte ich auch schon so meine Probleme, aber mit Oszi lässt sich das 
recht schnell detektieren.
Auftrag erkannt: Quarz anbringen!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Markus Oberle schrieb:
> aber mit Oszi lässt sich das recht schnell detektieren.
Glück gehabt. Aber Peter S. schrieb:
>> Hast du ein Oszi zur Hand?
> Nein leider - ist nicht im Budget :(

Ein Oszi zu haben, ist, wie wenn man beim Autofahren den 2. Gang 
einlegen gelernt hat: man kommt einfach schneller ans Ziel... ;-)

[ziegenpeter (Gast)]

Wenn ich das richtig verstehe, würde aber eine zu große Abweichung des 
Taktes, sich hauptsächlich in falschen Zeichen bemerkbar machen 
(vorausgesetz die Abweichung ist nicht 1 kbps zu 10 kbps oder sowas). 
D.h. mann hätte immer noch die möglichkeit zu sehen, dass überhaupt was 
übertragen wird.

Und ob am µC was ankommt, kann man auch recht einfach über z.B. eine LED 
rausfinden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

ziegenpeter schrieb:
> Wenn ich das richtig verstehe, würde aber eine zu große Abweichung des
> Taktes, sich hauptsächlich in falschen Zeichen bemerkbar machen
Wie schon gesagt: Ja.
> (vorausgesetz die Abweichung ist nicht 1 kbps zu 10 kbps oder sowas).
Das ist egal. Dann kommen schlimmstenfalls nur falsche Zeichen an.

[Peter S. (schoells)]

Erstmal danke für die vielen Tipps.
Hab eure Ratschläge befolgt - das sind die Ergebnisse:

1) RX und TX an USB to Serial Kabel gebrückt: Gesendetes Zeichen = 
empfangenes Zeichen --> Kabel OK

2) RX und TX nach Max232N gebrückt: Gesendetes Zeichen = empfangenes 
Zeichen

3) RXD und TXD Pins direkt am µC verbunden.
Ich empfange irgendwelche Zeichen, wenn ich diese Verbindung durchführe.
Auch die Leds, die ich an den PORT A pins angeschlossen habe leuchten 
Teilweise.

Diese Ergebnisse machen mich irgendwie stutzig...
Die gesamte Hardware funktioniert (Kabel, Max232N, ext.) und anscheinend 
der µC auch.

Was kann ich sonst noch machen?

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> 3) RXD und TXD Pins direkt am µC verbunden.
> Ich empfange irgendwelche Zeichen, wenn ich diese Verbindung durchführe.
> Auch die Leds, die ich an den PORT A pins angeschlossen habe leuchten
> Teilweise.

Nimm mal den µC aus dem Sockel und teste nochmal ob ein Echo kommt.

[Peter S. (schoells)]

So noch einige Infos:

1) Hab meine "main" folgendermaßen abgehändert:

int main(void)
{
  uart_init();
  while (1) 
  {
  
  uart_putc('A');
  }
  return 0; // never reached 
}

Der µC sollte nun durchgehend ein "A" senden - es kommt jedoch nur 
machmal ein "A" an, ansonsten irgendwelche andren Zeichen. Gut, könnte 
ein Problem mit der Baud Rate sein - OK - aber wenigstens sender der µC 
was.

2) Hab den Tipp von Oliver J. befolgt:
>Nimm mal den µC aus dem Sockel und teste nochmal ob ein Echo kommt.

Habe die entsprechenden Ports gebrückt. Wenn ich nun vom PC etwas senden 
- dann kommt nichts zurück. Manchmal kommt was ein (ca. 3 Zeichen) auch 
wenn ich NICHTS sende.
Wo kann denn da ein Problem bei der Fassung liegen?

Übrigends: hab extra nochmal nach dem MAX232N gebrückt. Zeichen kommen 
fehlerfrei zurück.

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Habe die entsprechenden Ports gebrückt. Wenn ich nun vom PC etwas senden
> - dann kommt nichts zurück. Manchmal kommt was ein (ca. 3 Zeichen) auch
> wenn ich NICHTS sende.
> Wo kann denn da ein Problem bei der Fassung liegen?

Das Kabel könnte falsch belegt sein. Das könnte erklären, dass ein 
Kreuzen hinter Dem MAX232 kein Echo erzeugt.

[Peter S. (schoells)]

Hmm, welche könnten da falsch belegt sein?
Wie ist die richtige Vorgangsweise, um den Fehler zu finden?

[Oliver J. (skriptkiddy)]

>Hmm, welche könnten da falsch belegt sein?

Leitung 2 und Leitung 3 könnten vertauscht sein.

[Dietrich L. (dietrichl)]

Peter S. schrieb:
> hab extra nochmal nach dem MAX232N gebrückt

Bei den vielen Test ist vielleicht etwas Verwirrung entstanden.
Was heißt "nach"? Welche Seite ist das?

Stelle doch noch mal alle Tests und die Ergebnisse übersichtlich 
zusammen.

Du weißt ja hoffentlich: brücken sollte man nur, wenn eine Seite nicht 
mehr angeschlossen ist. Sonst gibt es Kurzschluss. Auch wenn eventuell 
nichts zerstört wird, ist zumindest das Testergebnis zweifelhaft...

Also:
- Brücken von RXD und TXD am Kabel zum PC: Stecker ziehen (= MAX232 
abklemmen)
- Brücken von RXD und TXD am µC: µC entfernen

Gruß Dietrich

[spess53 (Gast)]

Hi

Nur mal so: Masseverbindung zwischen deinem Board und PC existiert? Also 
PIN5 der Steckverbinder verbunden?

MfG Spess

[Peter S. (Gast)]

Also nochmal zu meinen Ergebnissen:

1) Usb2RS232: Usb mit PC verbunden: RS232 pin 2 und 3 verbunden (max232 
nicht angeschlossen): Gesendetes zeichen = empfangenes Zeichen

2) Usb2Rs232 an max232 angeschlossen: uC entfernt: send und receive pin 
verbunden: gesendetes zeichen = empfangenes zeichen

3) Usb2Rs232 an max232 angeschlossen: uC entfernt: am IC sockel werde 
die anschlüsse von RXD und TXD pins des uC verbunden (kurzgeschlossen). 
Zeichen wird gesendet, aber keines kommt am PC an.

4) Usb2Rs232 an max232 angeschlossen: uC angeschlossen: RXD und TXD 
werden verbunden: uC sendet irgendwelche zeichen

5) Dauersenden des uC des Zeichens 'A': es kommen zeochen am PC an, aber 
nur zwischendurch wird ein A empfangen (event. Problem m. Baudrate)

Ich hoffe, dass die Verwirrung nun beseitigt ist.

[Dietrich L. (dietrichl)]

Peter S. schrieb:
> 2) Usb2Rs232 an max232 angeschlossen: uC entfernt: send und receive pin
> verbunden: gesendetes zeichen = empfangenes zeichen
>
> 3) Usb2Rs232 an max232 angeschlossen: uC entfernt: am IC sockel werde
> die anschlüsse von RXD und TXD pins des uC verbunden (kurzgeschlossen).
> Zeichen wird gesendet, aber keines kommt am PC an.

Wenn bei 2) der MAX232 noch an der Leitung zum µC angeschloosen war, 
kann das nur heißen: falsche Verbindung zum µC.

Wenn bei 2) der MAX232 von der Leitung zum µC abgeklemmt war: an den 
Leitungen zum µC hängt noch was anderes, z.B. ein Kurzschluss o.Ä.

Also mit fällt da nur ein Verdrahtungsfehler ein.

Gruß Dietrich

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> 2) Usb2Rs232 an max232 angeschlossen: uC entfernt: send und receive pin
> verbunden: gesendetes zeichen = empfangenes zeichen

Welche pins des MAX232 hast du verbunden?
10-12 oder 13-7

[Peter S. (schoells)]

>Peter S. schrieb:
>> 2) Usb2Rs232 an max232 angeschlossen: uC entfernt: send und receive pin
>> verbunden: gesendetes zeichen = empfangenes zeichen

>Welche pins des MAX232 hast du verbunden?
>10-12 oder 13-7

10-12 hab ich gemssen / die werden auf dem Board mittels Jumper zum µC 
geschlossen

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> 10-12 hab ich gemssen / die werden auf dem Board mittels Jumper zum µC
> geschlossen

Du hast also Pin12 mit Pin10 verbunden, in dem du JP1 und JP2 auf der 
MAX232-Seite verbunden hast?

Wenn ja dann liegt der Fehler in der Verdrahtung oder der MAX232 ist 
defekt oder vielleicht verkehrt herum im Sockel.

Klingel mal das Kabel durch, ob PIN2 und PIN3 1:1 durchverdrahtet und 
nicht gekreuzt sind. Das Pollinboard erwartet nämlich eine 1:1 
Verdrahtung.

Gruß Oliver

[Peter S. (schoells)]

>Du hast also Pin12 mit Pin10 verbunden, in dem du JP1 und JP2 auf der
>MAX232-Seite verbunden hast?
Ja, genau so hab ichs gemacht

>Wenn ja dann liegt der Fehler in der Verdrahtung oder der MAX232 ist
>defekt oder vielleicht verkehrt herum im Sockel.
Max232 ist richtig im Sockel

>Klingel mal das Kabel durch, ob PIN2 und PIN3 1:1 durchverdrahtet und
>nicht gekreuzt sind. Das Pollinboard erwartet nämlich eine 1:1
>Verdrahtung.
Wie kann ich das genau feststellen, ob es sich um eine 1:1 Verdrahtung 
handelt?

[Peter S. (schoells)]

Dieses USB2RS232 Kabel hab ich in verwendung:

http://www.lindy.de/usb-seriell-konverter-lite/42855.html#eDescription

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Dieses USB2RS232 Kabel hab ich in verwendung:
>
> http://www.lindy.de/usb-seriell-konverter-lite/428...

Also wenn das direkt am Board steckt, dann ist das schonmal korrekt. 
Direkt anschließen entspricht einer 1:1-Verdrahtung 
(Verlängerungskabel).

Gruß Oliver

[Peter S. (schoells)]

Ja, steckt direkt am Board.

Habe das Kabel gerade ausgemessen:

U Pin 3 (TX) gegen Pin 5 (GND) bei durchgehendem Senden eines Zeichens: 
0,3V

U Pin 3 (TX) gegen Pin 5 (GND) wenn nichts gesendet wird: 0,03V

[Oliver J. (skriptkiddy)]

Liegen am MAX232 5V an (PIN16)?
Liegen am MAX232 die von ihm erzeugten +-10V an (Pin2 und Pin6)?

Wenn die Spannungen da sind, dann versuche mal das:

Entferne mal JP1 und lege mal 5V an PIN10 des MAX232 an. Und miss mal 
jetzt mal die Spannung an PIN7. Mach das ganze nochmal mit 0V an PIN10.


Dabei sollte ungefähr sowas rauskommen:


PIN10  |  PIN7
-------+--------
  5V   |  -10V
  0V   |  +10V

Könnte auch betragsmäßig etwas weniger als 10V sein. Wenn das 
funktioniert, dann arbeitet der MAX232 in µC-Senderichtung und sollte 
Zeichen vom µC an den Rechner weiterleiten sofern denn:
- Baudrate stimmt auf beiden Seiten
- Die Verbindung vom MAX232 zum µC einwandfrei ist


Lass mal ein Licht im Sekundentakt blinken, dann siehst du, ob der Takt 
und somit die Baudrate mit dem übereinstimmt, was im Quellcode angegeben 
ist.


Gruß Oliver

[Peter S. (schoells)]

Also, zwischen Pin 16 (Vcc) und Pin 15 (GND) liegen 0V an.

Ebenfalls zwischen Pin 2 (Vs+) und Pin 15 (GND) liegen 0V an.

Hab mit ausgebauten µC gemssen.

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Also, zwischen Pin 16 (Vcc) und Pin 15 (GND) liegen 0V an.

Das Board wird doch versorgt. Richtg?

Wenn ja, dann scheint der MAX232 keine 5V vom 7805 abzubekommen. Vllt 
ein Haarriss auf der Platine. Dann könnte es helfen, an PIN16 des MAX232 
mal direkt an 5V anzuschließen. 5V kann man z.B. am 40-Poligen 
Wannenstecker abgreifen (36, 38, 40).

Gruß Oliver

[Peter S. (schoells)]

Aber wieso funktioniert dann das senden/empfangen, wenn ich JP1 mit JP2 
verbinde?

Würde der RS232 keine Spannung haben, würde das doch nicht 
funktionieren?

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Aber wieso funktioniert dann das senden/empfangen, wenn ich JP1 mit JP2
> verbinde?

Dachte das funktionert nicht. Sorry

Ist dein Multimeter kaputt? Denn diese Spannungen (5V 10V -10V) müssen 
am MAX232 anliegen, sonst könnte das nicht funktionieren.

OK.

Also funktioniert die Übertragung bis zur TTL-Seite des MAX232.

Klingel mal durch ob die Verbindung vom MAX zum µC existiert (bitte 
Versorgungsspannung entfernen)

[Peter S. (schoells)]

ACHTUNG MESSFEHLER!

Sorry, hab nein kleinen Messfehler begangen (Multimeter war auf AC)

U Pin 16 (Vcc) Pin 15 (GND): 5,03V
U Pin 2 (Vs+) Pin 2 (GND): 9,06V
U Pin 2 (Vs-) Pin 6 (GND): -8,63V

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> 5) Dauersenden des uC des Zeichens 'A': es kommen zeochen am PC an, aber
> nur zwischendurch wird ein A empfangen (event. Problem m. Baudrate)

Die Verbindung wird also auch da sein.

Ok.


Lass mal eine LED im Sekundentakt blinken...

[Peter S. (schoells)]

Verbindung zwischen MAX232 und den Pins am µC existiert

[Peter S. (schoells)]

Oliver J. schrieb:
> Peter S. schrieb:
>> 5) Dauersenden des uC des Zeichens 'A': es kommen zeochen am PC an, aber
>> nur zwischendurch wird ein A empfangen (event. Problem m. Baudrate)
>
> Die Verbindung wird also auch da sein.
>
> Ok.
>
>
> Lass mal eine LED im Sekundentakt blinken...

Mein Hauptproblem (vorerst) ist nicht das Problem mit der BAUD Rate, 
also dass nur Zwischendurch ein A empfangen wird.

Mein Problem ist, dass wenn ich RXD und TXD Pin am Sockel meines µC 
verbinde, und dann vom PC ein Zeichen sende, dieses Zeichen nicht 
empfangen wird.

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Mein Problem ist, dass wenn ich RXD und TXD Pin am Sockel meines µC
> verbinde, und dann vom PC ein Zeichen sende, dieses Zeichen nicht
> empfangen wird.

Mach mal ein Foto vom Board. Beide Seiten bitte. Kann ruhig etwas höher 
aufgelöst sein.


PS. vielleicht hilft es auch alle betreffenden Lötstellen mal 
nachzulöten (eventuell kalte Lötstelle).

[Julian R. (tuefftler)]

Also nach dem, was man hier so liest, würd' ich auf einen defekten 
MAX232 tippen...(NUR EINE VERMUTUNG!)
Hast du eventuell einen zweiten da?

julian

[Oliver J. (skriptkiddy)]

Julian R. schrieb:
> Also nach dem, was man hier so liest, würd' ich auf einen defekten
> MAX232 tippen...(NUR EINE VERMUTUNG!)
> Hast du eventuell einen zweiten da?
>
> julian

Der scheint zu funktionieren. Er bekommt ja ein Echo, wenn der RX und TX 
auf der TTL-Seite kurzschließt.

Gruß Oliver

[Oliver J. (skriptkiddy)]

Funktionierts jetzt?

[Peter S. (schoells)]

>Julian R. schrieb:
>> Also nach dem, was man hier so liest, würd' ich auf einen defekten
>> MAX232 tippen...(NUR EINE VERMUTUNG!)
>> Hast du eventuell einen zweiten da?
>>
> julian

>Der scheint zu funktionieren. Er bekommt ja ein Echo, wenn der RX und TX
>auf der TTL-Seite kurzschließt.

>Gruß Oliver

Also, ich glaub schon dass der MAX232 funktioniert - wie gesagt, es gibt 
ein echo, wenn ich RX und TX kurzschließe.

@Oliver - Bilder sind jetzt hochgeladen

Der Bug muss irgendwo zwischen MAX232 und µC liegen (der µC müsste 
eigentlich OK sein)

[Peter S. (schoells)]

>Der Bug muss irgendwo zwischen MAX232 und µC liegen (der µC müsste
>eigentlich OK sein)

So
hab jetzt nochmal genauer die Sockelpins von RXD und TXD kurzgeschlossen 
(Lötverbindung).

Das gesendete Zeichen = das empfangene Zeichen am PC

d.h.: es kann eigentlich nur mehr am µC liegen - also am Programm 
Code... Nur warum funzt es nicht?

[Thomas R. (Gast)]

Hallo,
eventuell ist dein USB-Seriell-Umsetzer sehr baudratenkritisch?
Mit 10MHz Clock am Atmel triffst du die Baudrate nicht genau.
Falls du einen "Baudratenquarz" zur Hand hast, würde ich es mal damit 
probieren.
Falls kein passender Quarz zu Hand ist, würde ich es mit 1200Baud 
probieren, eventuell sind die Fehler dann weg oder viel seltener.

[Peter S. (schoells)]

> Mit 10MHz Clock am Atmel triffst du die Baudrate nicht genau.

Läuft aber mit 1MHz. Ist das hier mit der Baudrate gleich kritisch?

#define F_CPU 1000000UL
#define BAUD 4800UL

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error BAUDRATEN ERROR!
#endif

Eigentlich überprüfe ich ja mit diesem Code, ob die Abweichung der 
Baudrate noch ok ist, oder?

[Thomas R. (Gast)]

Du lässt mit diesem Code 1% Fehler zu.
Verträgt dein USB-Teil diesen Fehler?
Sorry wegen 10MHz :-)

[Oliver J. (skriptkiddy)]

Die meisten Funktionsprobleme bei UART sind auf MCU-seitig falsch 
eingestellte Baudrate zurückzufühen. Die Baudrate wird bei dir per 
Präprozessor abhängig von der F_CPU berechnet. Wenn F_CPU nicht mit dem 
realen Prozessortakt übereinstimmt, dann stimmt auch die Baudrate nicht. 
Läuft denn dein AVR wirkilch mit 1 MHz? Sind es eventuell 8MHz oder 
sogar die 16 MHz vom Quarz?

Prüfe das mal nach, indem du eine LED blinken lässt.

Gruß Oliver

[Thomas R. (Gast)]

Oder läuft statt dem Quarz der interne RC-Oscillator mit so ungefähr 
1MHz? Fuse-Bits?

[Peter S. (schoells)]

So, ich poste jetzt einfach mal die fuse bits.

Bin gerade nochmal am datenblatt durchblättern.

[Peter S. (schoells)]

Peter S. schrieb:
> So, ich poste jetzt einfach mal die fuse bits.
>
> Bin gerade nochmal am datenblatt durchblättern.

Also lt. Datenblatt S.25

"The device is shipped wick CKSEL = 0001 and SUT=10. The default clock 
source seting ist therefore the 1 MHz Internal RC Oscillator with 
longest startup time".

Und lt. zuvor gepostetem Bild, passen ja meine fuses....

[Thomas R. (Gast)]

Beim ATMEGA32 gilt:

The device is shipped with CKSEL = “0001” and SUT = “10”. The default 
clock source setting is
therefore the 1 MHz Internal RC Oscillator with longest startup time. 
This default setting ensures
that all users can make their desired clock source setting using an 
In-System or Parallel
Programmer.

[Peter S. (schoells)]

Thomas R. schrieb:
> Beim ATMEGA32 gilt:
>
> The device is shipped with CKSEL = “0001” and SUT = “10”. The default
> clock source setting is
> therefore the 1 MHz Internal RC Oscillator with longest startup time.
> This default setting ensures
> that all users can make their desired clock source setting using an
> In-System or Parallel
> Programmer.

Jop - genau das gilbt beim ATmega16 auch. Also sollte er mit 1MHz 
laufen, wenn ich das richtig verstehe

[Thomas R. (Gast)]

Dann benutzt du also den RC-Oszillator!?!
Wahrscheinlich reicht dessen Genauigkeit nicht für den UART.
Auf deinen Platinenfotos sind doch so schöne Quarze und du verwendest 
sie nicht!

[Peter S. (schoells)]

Thomas R. schrieb:
> Dann benutzt du also den RC-Oszillator!?!
> Wahrscheinlich reicht dessen Genauigkeit nicht für den UART.
> Auf deinen Platinenfotos sind doch so schöne Quarze und du verwendest
> sie nicht!

Na ja, dass ist ne andere Sache - hab mich nocht nicht genau genug damit 
beschäftigt, wie ich die Quarze des Boards verwenden kann. Einfach fuses 
umstellen?

Die Dokumentation des ATMEL Evaluation Boards ist nicht sehr gut. Auf 
dem Board sind 2 16MHz und 1 8MHz Quarz. Die Frage ist, wie ich die 
anwähle.

[Oliver J. (skriptkiddy)]

Blinkt die LED denn im erwarteten Takt?

[Peter S. (schoells)]

Thomas R. schrieb:
> Hallo,
> eventuell ist dein USB-Seriell-Umsetzer sehr baudratenkritisch?
> Mit 10MHz Clock am Atmel triffst du die Baudrate nicht genau.
> Falls du einen "Baudratenquarz" zur Hand hast, würde ich es mal damit
> probieren.
> Falls kein passender Quarz zu Hand ist, würde ich es mit 1200Baud
> probieren, eventuell sind die Fehler dann weg oder viel seltener.

1200 Baud funktioniert auch nicht

[Peter S. (schoells)]

Oliver J. schrieb:
> Blinkt die LED denn im erwarteten Takt?

Wie genau soll die LED blinken lassen? Einfach mit delay?

[Thomas R. (Gast)]

Peter S. schrieb:
> Einfach fuses
> umstellen?

Ja.
Auf deinem Board verwendet dann der ATMEGA16 den Quarz Q3.

[Peter S. (schoells)]

Thomas R. schrieb:
> Peter S. schrieb:
>> Einfach fuses
>> umstellen?
>
> Ja.
> Auf deinem Board verwendet dann der ATMEGA16 den Quarz Q3.

Hmm. Ist ja dann ein "External Crystal Osciallator"

Lt. Datenblatt des ATmega16 auf S.26 gibts da aber als Frequency Range 
nur den max. Wert 3-8Mhz. Q3 ist jedoch ein 16Mhz.

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Wie genau soll die LED blinken lassen? Einfach mit delay?
ja

#define F_CPU 1000000

[...]

int main(void)
{
  [...]  
  while(1)
  {
    _dalay_ms(500);
    LED_AN;
    _dalay_ms(500);
    LED_AUS;
  }
}

Wenn die LED dann im Sekundentakt blink, ist der Takt ca. 1Mhz.

[Thomas R. (Gast)]

For resonators, the maximum frequency is 8 MHz with CKOPT unprogrammed 
and 16 MHz with CKOPT programmed.

F_CPU 16000000UL

Wenn die LED dann 1 mal/Sekunde blink, ist der Takt genau 16Mhz.

[Peter S. (schoells)]

Thomas R. schrieb:
> For resonators, the maximum frequency is 8 MHz with CKOPT unprogrammed
> and 16 MHz with CKOPT programmed.
>
> F_CPU 16000000UL
>
> Wenn die LED dann 1 mal/Sekunde blink, ist der Takt genau 16Mhz.

Kannst du mir sagen, wie ich die fuse bits genau setzen muss?

[Peter S. (schoells)]

Peter S. schrieb:
> Thomas R. schrieb:
>> For resonators, the maximum frequency is 8 MHz with CKOPT unprogrammed
>> and 16 MHz with CKOPT programmed.
>>
>> F_CPU 16000000UL
>>
>> Wenn die LED dann 1 mal/Sekunde blink, ist der Takt genau 16Mhz.
>
> Kannst du mir sagen, wie ich die fuse bits genau setzen muss?

Liege ich in der Annahme richtig, wenn ich die Fuse Bits wie folgt 
setze:

CKSEL = 1111
SUT = 11

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Liege ich in der Annahme richtig, wenn ich die Fuse Bits wie folgt
> setze:
>
> CKSEL = 1111
> SUT = 11

Ja

[Thomas R. (Gast)]

Ich glaube, das ist ok, müsste aber selbst nachschauen.
Ich habe den ATMEGA16 schon lange nicht mehr gehabt...

[Peter S. (schoells)]

Oliver J. schrieb:
> Peter S. schrieb:
>> Liege ich in der Annahme richtig, wenn ich die Fuse Bits wie folgt
>> setze:
>>
>> CKSEL = 1111
>> SUT = 11
>
> Ja

CKOPT ebenfalls 1, oder?

P.S.: Brenne grad das Programm zum LED Blinken lassen. Ergebnisse folgen 
gleich

[Thomas R. (Gast)]

Peter S. schrieb:
> CKOPT ebenfalls 1, oder?

ja

[Peter S. (schoells)]

> Wenn die LED dann im Sekundentakt blink, ist der Takt ca. 1Mhz.

Also mir kommt vor, als würde die LED 1s leuchten und 1s aus sein.
Damit passt die Taktfrequenz anscheinend nicht - werd jetzt mal die fuse 
bits umstellen.

[Thomas R. (Gast)]

mit
F_CPU 16000000UL
passt das doch.
mit
F_CPU 1000000UL
müsste sie 16* pro sek blinken

[Peter S. (schoells)]

Thomas R. schrieb:
> mit
> F_CPU 16000000UL
> passt das doch.
> mit
> F_CPU 1000000UL
> müsste sie 16* pro sek blinken

Ne, ich hatte noch 1Mhz eingestellt.

So, hab jetzt die Fuse bits geändert und nochmal mein ursprüngliches 
Porgramm draufgespielt

#define F_CPU 16000000UL
#define BAUD 1200UL

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error BAUDRATEN ERROR!
#endif

#include <avr/io.h>
#include <stdlib.h>

void uart_init(void)
{
  UBRRH = UBRR_VAL >> 8;
  UBRRL = UBRR_VAL & 0xFF;

  UCSRB = (1<<RXEN)|(1<<TXEN);
  UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}

int uart_putc(unsigned char d)
{
    while (!(UCSRA & (1<<UDRE)))
    {
    }

    UDR = d;
    return 0;
}


uint8_t uart_getc(void)
{
    while (!(UCSRA & (1<<RXC)))
        ;
    return UDR;
}

int main(void)
{
  uart_init();
   DDRA  = 0xFF;             
   DDRB  = 0xFF;             
   PORTB = 0x03;             

  while (1)
  {


    if ( (UCSRA & (1<<RXC)) )
    {
      uint8_t c;
      c = uart_getc();
    uart_putc(c);

      PORTA = c;
    }
    else
    {

    }
  }
  return 0; // never reached
}

Es Tut sich jedoch noch immer nichts...

[Thomas R. (Gast)]

Hast du auch im AVR-Studio
Project -> ConfigurationOptions
auf 16000000Hz gestellt?

[Peter S. (schoells)]

Thomas R. schrieb:
> Hast du auch im AVR-Studio
> Project -> ConfigurationOptions
> auf 16000000Hz gestellt?

Im AVR 5 - Configuration Manager? Nein, hab da nichts umgestellt

[Thomas R. (Gast)]

Ich verwende AVR-Studio 4 und kenne 5 nicht.
Was passiert, wenn du den 16MHz-Quarz auslötest?
Wenn der ATMEGA dann weiter läuft, läuft immer noch der interne 
Oscillator.
Dann würden die Fuse-Bits nicht stimmen.

[Peter S. (schoells)]

Hmm - irgendwo müsste ich doch die Frequenz des Quarzes eingeben können. 
Wird doch im Makefile benötigt... Könnte hier der Fehler liegen?

[Thomas R. (Gast)]

Im AVR 4 passiert das hier: Project -> ConfigurationOptions
und im Source mit
#define F_CPU 16000000UL
Beides muss gleich sein...sonst weiss man nicht, welches letztendlich 
verwendet wird.
AVR 5 kenne ich nicht.

[Oliver J. (skriptkiddy)]

1. Hast du nun endlich mal ein Licht blinken lassen?


2. Wie programmierst du (mit welcher Software)?
   --> packe mal den Projekt als zip und poste ihn hier


3. Mit welcher Software flasht du den AVR?

[Peter S. (Gast)]

Hallo.

1) ja, hab ich gemacht (siehe post oben)

2) avr studio 5

3) mit avrdude

Ich bin gerade am dachstein ein bisschen ausspannen. Werd das projekt am 
do posten. Lg

[Oliver J. (skriptkiddy)]

Wie setzt du deine Fuses?

[Julian R. (tuefftler)]

Oliver J. schrieb:
> Wie setzt du deine Fuses?

Er sollte seine Fuses mit BURN O MAT setzen, warum er jedoch das 
Häckenzeug benutzt anstatt den Letzten Tab mit Oscillatoroptions, 
verstehe ich ned!
Des letzt Bild auf folgender Seite zeigt, dass er das ganze Fuses 
gewurstelle auch mit drei Mausklicks erledigen könnte:
http://tuefftler.de/miko_1-1-4.html

julian

PS: des mit dem MAX232 war nur so ne Vermutung, weil er geschrieben 
hatte:
Peter S. schrieb:
> 3) RXD und TXD Pins direkt am µC verbunden.
> Ich empfange irgendwelche Zeichen, wenn ich diese Verbindung durchführe.
> Auch die Leds, die ich an den PORT A pins angeschlossen habe leuchten
> Teilweise.
Darum hatte ich geglaubt, der MAX232 wäre hin!

[USART-Gast (Gast)]

Hast du mal ins Datenblatt geschaut:
UBBR=fosc/(16*Baud)-1 (reichelt Datenblatt Version für den atmega 16 im 
dip - seite 140)

Das passt nicht zu deiner Formel.

Gruß
  Gast

[Peter S. (Gast)]

USART-Gast schrieb:
> Hast du mal ins Datenblatt geschaut:
> UBBR=fosc/(16*Baud)-1 (reichelt Datenblatt Version für den atmega 16 im
> dip - seite 140)
>
> Das passt nicht zu deiner Formel.
>
> Gruß
>   Gast

Also ich jab mich strikt ans avr-gcc tutorial aus dem Forum gehalten. 
Werd diese Änderung am donnerstag durchführen.


@USART-GAST
hab mir gedacht, wenn ich die fuses per hand setze (16 Mhz siehe oben) 
dann dann nichts schiefgehen. Vielleicht war meine Annahme ja Falsch.

Lg

[Oliver J. (skriptkiddy)]

USART-Gast schrieb:
> Hast du mal ins Datenblatt geschaut:
> UBBR=fosc/(16*Baud)-1 (reichelt Datenblatt Version für den atmega 16 im
> dip - seite 140)
>
> Das passt nicht zu deiner Formel.
>
> Gruß
>   Gast

Mit der Formel aus dem Datenblatt würden einfach die Nachkommastellen 
abgeschnitten werden. Sprich wenn 39.9 das exakte Ergebnis wäre, dann 
wäre das Ergebnis durch den Präprozessor 39. Das macht den Fehler 
natürlich unnötig groß. Wie man offensichtlich sehen kann, wäre 40 
besser geeignet. Da kommt die Formel aus dem Tutorial ins Spiel. Um ab 
x.5 immer aufzurunden, hat man im Zähler einfach noch mal den halben 
Nenner drauf addiert.


Gruß Oliver

[USART-Gast (Gast)]

Das Tut. habe ich mir vorhin mal angesehen.
Ich habe bisher mit der Formel aus dem Datenblatt gearbeitet, jedoch per 
Hand. Da habe ich dann wohl selbst immer richtig gerundet. Gut, es waren 
bisher auch erst drei verschiedene UBBRs (1MHz-2400Baud; 8MHz-2400Baud; 
8MHz-9600Baud). Alles mit internem Takt auf den Mega8535s. Funktioniert 
wie es soll, nur die IR-Übertragung macht teilweise ein paar Probleme, 
aber das gehört hier nicht hin ;)

Und die Formel aus dem Tut. mal einfach:
UBBR=fosc/(16*Baud)-0.5
Aber das wäre ja zu einfach. Hätte ich auch gleich sehen können. Aber 
das der Präprozessor nicht rundet, sondern abscheidet muss man einfach 
wissen. War bei mir nicht der Fall.

[Peter S. (schoells)]

Hallo!

Anbei mein Projekt Ordner aus dem AVR5 Studio.
Ich hoffe, das dass Problem jetzt gefunden wird.

lg

[Peter S. (schoells)]

In den Eigenschaften ist mir noch aufgefallen, dass bei meinem µC im 
Projekt unter Speed "0" aufscheint.

Könnte das der entscheidende Bug sein?

[MWS (Gast)]

Peter S. schrieb:
> Ich hoffe, das dass Problem jetzt gefunden wird.

Ein Problem hast Du doch schon, da muss man keins mehr finden, Du 
möchtest daß die Lösung gefunden wird. ;D

Peter S. schrieb:
> Die ist mit 4800 im Terminal Prog eingestellt

Bei Win7 bin ich mir nicht sicher, aber üblicherweise musst Du die 
Baudrate in der Systemsteuerung für die entsprechende Com-Schnittstelle 
einstellen. Einstellungen im Terminal dürften ohne Wirkung sein.

[Peter S. (schoells)]

MWS schrieb:
> Peter S. schrieb:
>> Ich hoffe, das dass Problem jetzt gefunden wird.
>
> Ein Problem hast Du doch schon, da muss man keins mehr finden, Du
> möchtest daß die Lösung gefunden wird. ;D

Tja, da hast du vollkommen recht...

> Peter S. schrieb:
>> Die ist mit 4800 im Terminal Prog eingestellt
>
> Bei Win7 bin ich mir nicht sicher, aber üblicherweise musst Du die
> Baudrate in der Systemsteuerung für die entsprechende Com-Schnittstelle
> einstellen. Einstellungen im Terminal dürften ohne Wirkung sein.

Hab im Gerätemanager nachgeschaut - war tatsächlich eine falsche 
Baudrate eingestellt - hab sie auf die gewünschten 1200 Bit/s geändert, 
aber ohne Erfolg. Problem besteht noch immer

[MWS (Gast)]

Poste doch mal den letzten C-Code als auch das erzeugte Hexfile.
Wie schnell rennt der µC denn jetzt im Moment ? Int. RC oder ext. Quarz, 
Fuses immer noch wie hier ?
Beitrag "Re: Einfachste USART ansteuerung funktioniert nicht."

[Peter S. (schoells)]

MWS schrieb:
> Poste doch mal den letzten C-Code als auch das erzeugte Hexfile.
> Wie schnell rennt der µC denn jetzt im Moment ? Int. RC oder ext. Quarz,
> Fuses immer noch wie hier ?
> Beitrag "Re: Einfachste USART ansteuerung funktioniert nicht."

So, aktuelle Einstellung ist auf Int. RC 8MHz.

Fuses, und Projekt Files (C Code, HEX Code, ext) siehe Anhang

[MWS (Gast)]

Hier passiert Dein Fehler, das .hex von Dir, wobei's egal ist, ob aus 
dem Debug oder Release Verzeichnis genommen:

  out  p20,r1
  ldi  r24,k0C
  out  p09,r24

Lädt das UBRR-Register mit 0x000C, entsprechend 38.4kBaud

Das hier von mir auf Basis Deines Quelltextes compilierte .hex ist 
dagegen richtig:

  ldi  r24,k01
  out  p20,r24
  ldi  r24,kA0
  out  p09,r24

UBBR = 0x01A0 = dec 416 = 1200 Baud
Keine Ahnung, was Du da machst.

Versuche anhängendes .hex

[Peter S. (schoells)]

Ok.... mit welchem compiler arbeitest du?

[Peter S. (schoells)]

MWS schrieb:

> Versuche anhängendes .hex

so eben probiert - funktioniert leider auch nicht :(

[MWS (Gast)]

Peter S. schrieb:
> Ok.... mit welchem compiler arbeitest du?

Hab's gerade durch AVR-Studio5 geschickt auch das produziert richtige 
Einstellungen für UBRR, im Gegensatz zum .hex von Dir.

[Peter S. (schoells)]

MWS schrieb:
> Peter S. schrieb:
>> Ok.... mit welchem compiler arbeitest du?
>
> Hab's gerade durch AVR-Studio5 geschickt auch das produziert richtige
> Einstellungen für UBRR, im Gegensatz zum .hex von Dir.

Also, das ist sehr strange...

Aber, ich habe einen Fehleransatz.
Hab gerade in die while schleife einfach ein Dauersenden des Zeichens 
eingetragen.
Bei Baud 1200 Bit/s kam nur am Anfang das richtige Zeichen an - danach 
irgendetwas....

Hab das die Databits im Terminal auf 7 geändert - und siehe da, das 
richtige Zeichen kam immer an.

Ich werde jetzt meinen oben geposteten Code mit 7 Databits testen - mal 
sehn, ob er dann funktioniert.

[Peter S. (schoells)]

Ne, funktioniert noch immer nicht

Aber generell irrtiert mich das, mit den 7 data bits...

[MWS (Gast)]

Auf welcher Baudrate steht das Terminal ?

[Peter S. (schoells)]

MWS schrieb:
> Auf welcher Baudrate steht das Terminal ?

1200 Bit/s


Weiters:
Hab im AVR Studio alles nochmal durchsimuliert. Mir fällt auf, das es 
das URSEL bit nicht setzt (siehe Grafik oben). Das könnte doch auch auf 
ein Problem hindeuten...

[MWS (Gast)]

Peter S. schrieb:
> Hab im AVR Studio alles nochmal durchsimuliert. Mir fällt auf, das es
> das URSEL bit nicht setzt (siehe Grafik oben).

Doch, wird schon gesetzt.

23:         UCSRC = (1<<URSEL)|(3<<UCSZ0);
+0000003C:   E886        LDI       R24,0x86       Load immediate
+0000003D:   BD80        OUT       0x20,R24       Out to I/O location

0x86 = URSEL 0x80 + UCSZ1 0x04 + UCSZ0 0x02

[Peter S. (schoells)]

> Bei Baud 1200 Bit/s kam nur am Anfang das richtige Zeichen an - danach
> irgendetwas....
>
> Hab das die Databits im Terminal auf 7 geändert - und siehe da, das
> richtige Zeichen kam immer an.
>
> Ich werde jetzt meinen oben geposteten Code mit 7 Databits testen - mal
> sehn, ob er dann funktioniert.

Hab das nochmal durchprobiert - das Ergebnis wie oben beschrieben war 
NICHT reproduzierbar.

Vielmehr viel mir auf, dass bei mehrmaligen ändern der Baudrate (von 600 
auf 1200) nach manchen Änderungen dir richtigen Zeichen empfangen 
wurden.
Sprich

1x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
2x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
3x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
4x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
5x Ändern von 600 auf 1200 Bit/s: RICHTIGES ZEICHEN EMPFANGEN
6x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
7x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
8x Ändern von 600 auf 1200 Bit/s: irgendwas empfangen
9x Ändern von 600 auf 1200 Bit/s: RICHTIGES ZEICHEN EMPFANGEN

Ich glaub, dieser Hterm Terminal funzt nicht richtig.... oder ich hab da 
nen ziemlichen Bug in meinem System

[MWS (Gast)]

Peter S. schrieb:
> Vielmehr viel mir auf, dass bei mehrmaligen ändern der Baudrate (von 600
> auf 1200) nach manchen Änderungen dir richtigen Zeichen empfangen
> wurden.

Der interne RC kann schon ordentlich neben der Spur sein, für einen 
Frequenzzähler hab' ich mal 8.3MHz einsetzen müssen.

Normalerweise sollten 2400 Baud mit dem internen RC keinerlei Problem 
darstellen, nur angenommen 8.3MHz / (16*(UBRR+1)) = 1244 Baud, ein 
Fehler von 3.7%, was schon über der Grenze ist. Eine instabile 
Stromversorgung könnte dem dann den Rest geben.

Würd' mal versuchen #define F_CPU 8000000UL nach oben und unten 
anzupassen. Eine Alternative wäre OSCCAL zu ändern, das könnte über 
Taster im laufenden Betrieb gemacht werden.

Vernünftigste Sache wär'n Quarz.

[Peter S. (schoells)]

> Vernünftigste Sache wär'n Quarz.

Hab ich auch schon probiert (siehe Beiträge oben).
Hat aber ebenfalls nicht funktioniert....

[Peter S. (schoells)]

Nochmal mit 16Mhz externen Quarz probiert.

Also, ich sende durchgehend ein Zeichen "A".

Folgendes Empfange ich:
AAAAAAAPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP

wenn ich dann auf 7 datenbits ändere:
*<5><5><5><5><5><21><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5>
<5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5>
<5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5>
<5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5>
<5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5>
<5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5><5>
<5><5><5><5><5><5><5>

wenn ich wieder auf 8 datenbits ändere:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

[MWS (Gast)]

Peter S. schrieb:
> Die Dokumentation des ATMEL Evaluation Boards ist nicht sehr gut. Auf
> dem Board sind 2 16MHz und 1 8MHz Quarz. Die Frage ist, wie ich die
> anwähle.

Du scheinst mir über das Vorhaben-Stadium nicht hinaus gekommen sein.

Schau' Dir den Schaltplan an, der Mega16 müsste in Sockel IC6 sitzen und 
dann ist Q3 dafür zuständig, der 16MHz haben sollte.

Hier kannst Du nochmal schauen, ob Deine Einstellungen stimmen, befor Du 
ihn "brickst":
http://www.engbedded.com/fusecalc/

Für 16MHz sollte CKOPT programmiert sein.

Peter S. schrieb:
> Nochmal mit 16Mhz externen Quarz probiert.

Alles kontrolliert ? Fuseeinstellungen ?
RXD/TXD auf dem Board durchgemessen, keine Verbindungen zu Stellen, wo 
keine sein soll ? ATM16 steckt als einziger µC drin ?

[Peter S. (schoells)]

> Schau' Dir den Schaltplan an, der Mega16 müsste in Sockel IC6 sitzen und
> dann ist Q3 dafür zuständig, der 16MHz haben sollte.
Sitzt dort wo er soll - F_CPU hab ich jetzt auf 16MHz (da ichs ja mit 
ext. Quarz wieder mal versuche)

> Für 16MHz sollte CKOPT programmiert sein.
Ok, der ist Anscheinend bei mir nicht programmiert....

> Alles kontrolliert ?
Mehr als doppelt - MAX232 funzt / wenn ich RXD, TXD im Sockel 
kurzschließe ohne µC kommen auch alle Zeichen wieder zurück

> Fuseeinstellungen ?
Grad nochmal gepostet

> RXD/TXD auf dem Board durchgemessen, keine Verbindungen zu Stellen, wo
> keine sein soll ?
Ja, passt alles

> ATM16 steckt als einziger µC drin ?
ja

[Peter S. (schoells)]

Peter S. schrieb:
>> Für 16MHz sollte CKOPT programmiert sein.
> Ok, der ist Anscheinend bei mir nicht programmiert....

Ah, grad gesehen - natürlich ist der aktiviert (also 0)

[MWS (Gast)]

Anhängend ein verbindlich funktionierendes .hex mit derselben 
Funktionsweise wie Dein Code. ATM16@16MHz@1200Baud. Hier getestet und 
läuft.

[MWS (Gast)]

Auch Dein Originalcode läuft hier einwandfrei, nur angepasst auf 16MHz.
Compiliert mit AVRStudio4, Optimierung -Os.

[Dietrich L. (dietrichl)]

Noch ne Frage:
Beim Terminal gibt es neben "Baudrate" und "Anzahl Bits" auch noch 
"Anzahl Stop-Bits" und "Parity". Ist das richtig (= wie beim µC) 
eingestellt?

Gruß Dietrich

[Peter S. (schoells)]

MWS schrieb:
> Auch Dein Originalcode läuft hier einwandfrei, nur angepasst auf 16MHz.
> Compiliert mit AVRStudio4, Optimierung -Os.

Danke! Funktioniert aber nicht bei mir... Verdammt, ich find den Fehler 
nicht...

> Beim Terminal gibt es neben "Baudrate" und "Anzahl Bits" auch noch
> "Anzahl Stop-Bits" und "Parity". Ist das richtig (= wie beim µC)
> eingestellt?

Stop-Bits: 1
Parity: None
Data Bits: 8
Baud: 1200 B/s

also das sollte schon zusammenpassen.

[Peter S. (schoells)]

HEUREKA!

Es funktioniert!


Aufgepasst der Fehler war folgender:

Ich hab an der 40-poligen Pfostenleiste eine Platine mit meinen Leds 
angesteckt. Und da waren RXD und TXD noch an ein versuchs LCD 
angeschlossen...
Da steckte das Problem!

Aber:
Im Atmel Evaluations-Board steht folgendes:
"Für umfangreiche Anwendungen sind nahezu alle verfügbaren Ports der 
Microcontroller wie Ports PA,PB,PC und PD auf eine 40(39)-pol. 
Pfostenleiste (Extension-Port) geführt und so leicht zugänglich. Mittels 
der Jumper JP1-8 und JP9-12 können die Ein- bzw. Ausgänge der Ports so 
geschaltet werden, dass diese Ports ENTWEDER mit den auf der Platine 
befindlichen LEDs, Taster oder den AC-Summer verwendet werden oder auf 
die Pfostenleiste geführt werden."

Warum, wenn es die Jumper gibt, werden die dann doch auf die 
Pfostenleiste geleitet?? Das versteh ich nicht ganz.

[Peter S. (schoells)]

Danke nochmal an alle, die mir bei der suche nach der Lösung dieses 
Problems behilflich waren!

[MWS (Gast)]

Peter S. schrieb:
>> RXD/TXD auf dem Board durchgemessen, keine Verbindungen zu Stellen,
>> wo keine sein soll ?
> Ja, passt alles

Peter S. schrieb:
> Ich hab an der 40-poligen Pfostenleiste eine Platine mit meinen Leds
> angesteckt. Und da waren RXD und TXD noch an ein versuchs LCD
> angeschlossen...

Hmm, das war dann aber die erste und einzige Erwähnung im ganzen Thread 
über eine angeschlossene Schaltung an der Extensionleiste.

Daß die RXD/TXD Pins dauerhaft an die Leiste gehen war nach Durchsicht 
des Schaltplans klar. Deshalb auch meine Frage ob noch andere 
Verbindungen bestehen.

Peter S. schrieb:
> Mittels
> der Jumper JP1-8 und JP9-12 können die Ein- bzw. Ausgänge der Ports so
> geschaltet werden, dass diese Ports ENTWEDER mit den auf der Platine
> befindlichen LEDs, Taster oder den AC-Summer verwendet werden oder auf
> die Pfostenleiste geführt werden."

Wie soll ein zweipoliger Jumper hier in der Lage sein, etwas 
umzuschalten ?

[Peter S. (schoells)]

Hallo!

Sorry, hab die Anmerkungen anscheinend falsch verstanden.... Tut mir 
leid dass ich vielen Leuten im Forum Zeit geraubt habe, da ich dieses 
Detail unterdrückt habe.

Peter S. schrieb:
>> RXD/TXD auf dem Board durchgemessen, keine Verbindungen zu Stellen,
>> wo keine sein soll ?
> Ja, passt alles

Das hab ich anscheinend falsch verstanden - hab nur das Atmel Evaluaions 
Board durchgemessen...

Wie gesagt - nochmals vielen Dank für die Hilfe!

[Oliver J. (skriptkiddy)]

MWS schrieb:
> Hmm, das war dann aber die erste und einzige Erwähnung im ganzen Thread
> über eine angeschlossene Schaltung an der Extensionleiste.

"Error 40" nennt sich das - glaub ich.

[Peter S. (schoells)]

Oliver J. schrieb:
> MWS schrieb:
>> Hmm, das war dann aber die erste und einzige Erwähnung im ganzen Thread
>> über eine angeschlossene Schaltung an der Extensionleiste.
>
> "Error 40" nennt sich das - glaub ich.

na ja - ich behaubte, DAU ist ein wenig übertrieben - GNU währ eher 
angebracht... Hab die Verbindung zum 40er Pfosten eigentlich erstellt, 
um den Fehler besser einzukreisen....

Ging nach hinten los.

Wie gesagt - danke noch mal an alle. Ich hoffe ich kann aus den Fehlern 
lernen. Und wer weis, vielleicht kann ich ja mal in einigen Monaten 
etwas konstruktives im Forum beitragen, nach dem ich mich einigermaßen 
in die Materie eingearbeitet habe...

Zu meiner Verteidigung: bin kein Elektrotechniker - bin Maschinenbauer, 
also nochmal sry, wenn solche Verständnisfehler (wie bei den Jumpern) 
passieren...

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> na ja - ich behaubte, DAU ist ein wenig übertrieben
Ich sagte lediglich: Der Fehler sitzt 40 cm vor dem Bildschirm. Nichts 
von Dumm.

Gruß Oliver

[Peter S. (schoells)]

Oliver J. schrieb:
> Peter S. schrieb:
>> na ja - ich behaubte, DAU ist ein wenig übertrieben
> Ich sagte lediglich: Der Fehler sitzt 40 cm vor dem Bildschirm. Nichts
> von Dumm.
>
> Gruß Oliver

ok - kenn den ERROR 40 nur als Synonym für DAU...
Aber Oliver, ich kann dir vollkommen zustimmen.

Danke nochmal für deinen Einsatz bei der Lösungssuche!

[Oliver J. (skriptkiddy)]

Peter S. schrieb:
> Danke nochmal für deinen Einsatz bei der Lösungssuche!

gern geschehen ;)

[MWS (Gast)]

Peter S. schrieb:
> Peter S. schrieb:
>>> RXD/TXD auf dem Board durchgemessen, keine Verbindungen zu Stellen,
>>> wo keine sein soll ?
>> Ja, passt alles
>
> Das hab ich anscheinend falsch verstanden - hab nur das Atmel Evaluaions
> Board durchgemessen...

Ja, nur wäre das der Zeitpunkt gewesen zu sagen: "... aber ich hab' da 
noch 'ne Cray 1  dran hängen, davon wisst Ihr noch nix..."

Auch wenn's eigentlich immer wieder das Gleiche ist: Lötbrücke, 
Kabeldefekt oder hoch kreative Auslegung von Angaben seitens des 
Nutzers, so hatte doch der Betrieb mit zusätzlicher Hardware ohne 
Nennung derselben ein neues Niveau.

Und darüber hatte ich mir nur kurz Luft machen müssen, quasi als 
Aaarrrggghhhhh-Ersatz.

[Dietrich L. (dietrichl)]

Auch noch von mir ein Tip:

Zu dem Board gibt es doch auch einen Schaltplan :-)). Den sollte man 
immer greifbar haben! So kann man bei solchen Fragen schnell mal die 
betroffenen Leitungen verfolgen und ist nicht auf Erinnerungen und die 
Deutung von Texten angewiesen.

Allgemein sollte man bei der Fehlersuche an allem zweifeln, Niemandem 
glauben - besonders auch sich selber nicht :-(
Das ist zwar ein etwas destruktives Verhalten, hilft aber in solchen 
Fällen.

Negative Folgen kann das allerdings auch haben: wenn ich z.B. meiner 
Frau gegenüber ebenso reagiere und bei irgendeiner Aussage gleich frage: 
Bist Du Dir sicher? Woher weißt Du das? Verwechselst Du da vielleicht 
was? Das gibt manchmal Ärger :-((

Gruß Dietrich