Einfachste USART ansteuerung funktioniert nicht.

Stimmt denn die Baudrate?

Funktioniert die Hardware?

Hast du ein Oszi zur Hand?

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

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

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 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. schrieb:
> und der ATmega16 läuft ja von Haus aus mit 1MHz.
Oha, interner Takt und RS232...
Viel Glück damit.

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

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

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!

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

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?

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.

So noch einige Infos:

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

1

int main(void)

2

{

3

  uart_init();

4

  while (1) 

5

  {

6

7

  uart_putc('A');

8

  }

9

  return 0; // never reached 

10

}

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.

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.

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

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

Leitung 2 und Leitung 3 könnten vertauscht sein.

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

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

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

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

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

Dieses USB2RS232 Kabel hab ich in verwendung:

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

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

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

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

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.

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

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?

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)

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

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

Verbindung zwischen MAX232 und den Pins am µC existiert

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.

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

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

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

Funktionierts jetzt?

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

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

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

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

1

#define F_CPU 1000000UL

2

#define BAUD 4800UL

3

4

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

5

#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))

6

#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

7

8

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))

9

  #error BAUDRATEN ERROR!

10

#endif

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

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

So, ich poste jetzt einfach mal die fuse bits.

Bin gerade nochmal am datenblatt durchblättern.

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

Blinkt die LED denn im erwarteten Takt?

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

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

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

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.

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

1

#define F_CPU 1000000

2

3

[...]

4

5

int main(void)

6

{

7

  [...]  

8

  while(1)

9

  {

10

    _dalay_ms(500);

11

    LED_AN;

12

    _dalay_ms(500);

13

    LED_AUS;

14

  }

15

}

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

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

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

Ja

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

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

1

#define F_CPU 16000000UL

2

#define BAUD 1200UL

3

4

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

5

#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))

6

#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

7

8

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))

9

  #error BAUDRATEN ERROR!

10

#endif

11

12

#include <avr/io.h>

13

#include <stdlib.h>

14

15

void uart_init(void)

16

{

17

  UBRRH = UBRR_VAL >> 8;

18

  UBRRL = UBRR_VAL & 0xFF;

19

20

  UCSRB = (1<<RXEN)|(1<<TXEN);

21

  UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);

22

}

23

24

int uart_putc(unsigned char d)

25

{

26

    while (!(UCSRA & (1<<UDRE)))

27

    {

28

    }

29

30

    UDR = d;

31

    return 0;

32

}

33

34

35

uint8_t uart_getc(void)

36

{

37

    while (!(UCSRA & (1<<RXC)))

38

        ;

39

    return UDR;

40

}

41

42

int main(void)

43

{

44

  uart_init();

45

   DDRA  = 0xFF;             

46

   DDRB  = 0xFF;             

47

   PORTB = 0x03;             

48

49

  while (1)

50

  {

51

52

53

    if ( (UCSRA & (1<<RXC)) )

54

    {

55

      uint8_t c;

56

      c = uart_getc();

57

    uart_putc(c);

58

59

      PORTA = c;

60

    }

61

    else

62

    {

63

64

    }

65

  }

66

  return 0; // never reached

67

}

Es Tut sich jedoch noch immer nichts...

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

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

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?

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?

Wie setzt du deine Fuses?

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

Hallo!

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

lg

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

Ok.... mit welchem compiler arbeitest du?

MWS schrieb:

> Versuche anhängendes .hex

so eben probiert - funktioniert leider auch nicht :(

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.

Ne, funktioniert noch immer nicht

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

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

> 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

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

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

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

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

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

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.

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.

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

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!

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.

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

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

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!

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

gern geschehen ;)

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