Hallo, wieder muss ich das Forum bemühen, um eine Klärung meines Problems zu bekommen. Ich betreibe mein ATMEGA32A mit 1MHz internen Oszillator. Leider bekomme ich in Minicom kein Zeichen. Obwohl im regelmässigen Abstand auf der TXD Leitung ein kurzzeitiges Signal erscheint. Ich habe leider keinen Oszi, um nähere Hardwareuntersuchungen anzustellen. Sieht jemand in meinem Quellcode einen Fehler? MfG hue \a
Hi >Ich betreibe mein ATMEGA32A mit 1MHz internen Oszillator. Schlecht. Der interne Oszillator ist für serielle Kommunikation nicht sonderlich geeignet. Nimm einen (Baudraten-) Quarz. >usart_transmit: ... >reti Unterprogramme werden mit 'ret' abgeschlossen. MfG Spess
>Unterprogramme werden mit 'ret' abgeschlossen.
Und mit RETI abgeschossen;)
SCNR
Hallo, am Abschluss einer ISR sollte es nicht liegen, da ich an einer LED PORTA Bit0 sehe, dass die ISR funktioniert. Leider bekomme ich das Zeichen 'U' nicht in den Rechner. Ich benutze einen USB-Seriell Adapter um die Daten zu empfangen. Hat noch jemand eine Idee? MfG hue \a
Hi
>Und mit RETI abgeschossen;)
Nicht wirklich. Aber das setzen des I-Flags kann u.U. für Verwirrung
sorgen.
MfG Spess
Hallo, den Takt habe ich schon einmal auf 16MHz hochgesetzt, und den Code laut Atmel- Datenblatt angepasst. Auch die Reduzierung auf 2400 Baud mit einem relativen Fehler von 0.2% bringt mir die Lösung nicht. hue \a
>Auch die Reduzierung auf 2400 Baud mit >einem relativen Fehler von 0.2% bringt mir die Lösung nicht. 0.2% Fehler hat die Baudrate wenn der Takt 0% Fehler hat. Wenn der Takt 3% Fehler hat kannst du die 0.2% Fehler vernachlässigen.
Hue schrub: > den Takt habe ich schon einmal auf 16MHz hochgesetzt Wie genau hast Du den 'hochgesetzt'? Hoffentlich mit einem externen Quarz oder Quarzoszillator nebst passender Fuses. Abgesehen davon steht der Rest in [1] und [2]. HTH [1] http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART [2] http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART
Hallo, ich komme noch immer nicht weiter, und habe noch folgendes Problem, dass die LED am PORTA,0 mit einer Blinkdauer von 4.16sec doppelt so schnell blinkt, als im Timer1 eingestellt. Also bei einem Interrupt bei 16MHz und Overflow bei 0xFFFF müsste laut Formel die Blinkdauer 8.38sec betragen. Das Blinken wird doch nur angesprungen, wenn 8.38sec rum sind? Wenn meine Betrachtung so richtig sind, dann kann auch mit der Taktung des UART nichts stimmen. Kann mir jemand helfen? MfG HUE \a
Hue \a schrieb: > die LED am PORTA,0 mit einer Blinkdauer von 4.16sec doppelt so schnell > blinkt, als im Timer1 eingestellt. Also bei einem Interrupt bei 16MHz > und Overflow bei 0xFFFF müsste laut Formel die Blinkdauer 8.38sec > betragen. Du sollst keine Formeln anwenden, die du nicht verstehst. Statt dessen sollst du dir klarmachen, wie ein Timer funktioniert, dann brauchst du die Formel nicht. Wenn deiné LED 4.19 Sekunden an ist und dann 4.19 Sekunden aus, dann läuft dein Prozessor nicht mit 16 Mhz sondern mit 1Mhz, denn 1000000/64/65536 = 0.238 Kehrwert davon sind 4.19 Sekunden. Alle 4.19 Sekunden wird daher die ISR angesprungen, in der du die LED umschaltest. Würde dein Prozessor mit 16 Mhz arbeiten, dann würde die ISR alle 0.26 Sekunden angesprungen und damit die LED umgeschaltet werden.
"USB-Seriell Adapter" Ja. Lass des ma bleiben. Die Dinger buggen manchmal. Hatte letztens das gleiche Problem. Pc mit serieller Schnittstelle: fehlerfrei. Laptop mit Adapter: keine Funktion. Anderer Laptop mit gleichem Adapter und gleichen Einstellungen: fehlerfrei.
Hallo, ich habe bei meinen Betrachtungen einen Fehler festgestellt, die hier wieder zur Verwirrung beigetragen haben. Ich takte richtig mit 16MHz nebst passenden Fusebits. Meine Berechnungen sind insofern richtig, da sie die Umschaltfrequenz von TOV berechnen, also einmal an und einmal aus. Dies ergibt eine Laufzeit von 8.38sec. Also 16MHz/(2*1024*65536) und dann invertiert. Daraus schlussfolgere ich, das mein System korrekt arbeitet. Nun habe ich aber immer noch das Problem des Datenaustausches per UART. Ich benutzte einen USB-Seriell-Adapter und bekomme mit den eingestellten Datenübertragungsraten und minicom keinen Verkehr zustande. Hat jemand noch einen Tipp? MfG HUE \a
bla schrieb: > USB-Seriell Adapter" > > Ja. Lass des ma bleiben. Die Dinger buggen manchmal. Hatte letztens das > gleiche Problem. Pc mit serieller Schnittstelle: fehlerfrei. Laptop mit > Adapter: keine Funktion. Anderer Laptop mit gleichem Adapter und > gleichen Einstellungen: fehlerfrei. sorry wegem Doppelposten
Hue \a schrieb: > Also 16MHz/(2*1024*65536) **** Sicher? In deinem zuerst geposteten Programm hast du nämlich einen Vorteiler von 64 und nicht 1024.
1 | ldi r16,(1<<CS10|1<<CS11) |
2 | out TCCR1B,r16 |
1024 / 64 ergibt aber wieder einen Faktor 16 Arbeitet dein System mit 1 Mhz, hast du einen Vorteiler von 64 programmiert und mit 1024 gerechnet, kommen falsche Zeiten raus, die dir duch den Fehlerfaktor 16 vorgaukeln, dass dein System mit 16 Mhz arbeiten würde.
Hallo, ich habe den Vorteiler auf 1024 geändert, da ich sicherstellen wollte, dass alle Datenpakete in der Zeit von 4.19sec bei beliebiger Baudrate ankommen. Ich hatte dies vergessen zu dokumentieren. Ich habe weiterhin das Kommunikationsproblem, habe auch nun einen Rechner besorgt, mit richtiger RS232 Schnittstelle, also ohne USB Adapter: kein Signal vom AVR. Wenn mich jemand sucht, ich bin im Badezimmer... auf dem Fussboden ... und heule. MfG HUE \a
Hi, also laut Datenblatt ist PD1 der TxD Pin. Müsstest du dann nicht auch irgendwann mal in DDRD reinschreiben, dass PD1 ein Ausgang sein soll? Grüße, Michael
>kein Signal vom AVR. Ist denn da auch ein kleines Mäxchen (MAX232) im Spiel? Oder AVR direkt an RS232 angeschlossen?
Hallo, ja ich habe einen Schnittstellenwandler eingebaut. Es liegen am TxD Ausgang auch Pegel an, welche nach 4.19sec (die LED wechselt den Zustand) sich ändern und wieder in Ausgangspegel gehen. Der Pegel liegt bei -8.8V und wird nach 4.19sec positiv für kurze Zeit, ich habe leider keinen Oszi. Das Setzen des Richtungsregisters auf Ausgang am TxD ist nun folgendermaßen: ldi r16,0x02 out DDRD,r16 Leider ohne Erfolg... bin wieder im Bad... MfG HUE \a
Hue \a schrieb: > Hallo, > > ja ich habe einen Schnittstellenwandler eingebaut. Es liegen am TxD > Ausgang auch Pegel an, welche nach 4.19sec (die LED wechselt den > Zustand) sich ändern und wieder in Ausgangspegel gehen. Der Pegel liegt > bei -8.8V und wird nach 4.19sec positiv für kurze Zeit, ich habe leider > keinen Oszi. Das sieht eigentlich gut aus. Was ist mit dem Seriell-Kabel? Hast du das schon durchgemessen bzw. den Loopback-Test gemacht?
Zeigt doch mal den aktuellen Quellcode (vollständig) nebst Fuses(!). Falls es an dem nicht liegt kanns immernoch ein Hardwareproblem sein. Da man letzteres übers Netz schwer beurteilen kann stollten wir mit ersterem beginnen.
Hallo, das Kabel ist ein Nullmodem- Kabel und die Ader RxD und TxD sind messtechnisch geprüft. Ich kann am Ende ja auch den Wechsel des Pegels am Pin 2 messen. MfG HUE \a
Hue \a schrieb: > Hallo, > > das Kabel ist ein Nullmodem- Kabel und die Ader RxD und TxD sind > messtechnisch geprüft. Ich kann am Ende ja auch den Wechsel des Pegels > am Pin 2 messen. OK. Dann Loppback Test: µC aus dem Sockel rausnehmen, TxD mit RxD im Sockel mit einer Kabelbrücke verbinden. Am Terminalprogramm auf der Tastatur klimpern. Was du klimperst muss angezeigt werden. Gegentest: Brücke rausnehmen, das Echo muss aufhören. Wenn das funktioniert, dann ist die Hardware in Ordnung.
Hallo, der Tipp mit dem Loopback Test ist prima, und es hat auch ein lokales Echo gegeben, also erfolgreich gelötet und gesteckt. Aber wie solls nun weitergehen? MfG HUE \a
Ich bin es nochmal, da ich mit Minicom die Verbinung über einen USB Adapter hergestellt habe, muss doch dann die Fehler in meinem Programm liegen. Kann jemand das unabhängig noch einmal ansehen. Es müsste mit 9600 Baud 8,n,1 eingestellt sein, sonst hätte Minicom ja gemeckert. Für Eure zahlreichen Hinweise bin ich schon jetzt recht froh, ich habe wieder viel gelernt. Man lernt ja nie aus.... MfG HUE \a PS: Hier noch das Makefile mit den Fuses.
Hue \a schrieb: > Hallo, > > der Tipp mit dem Loopback Test ist prima, und es hat auch ein lokales > Echo gegeben, also erfolgreich gelötet und gesteckt. > > Aber wie solls nun weitergehen? Damit kann man dann die Hardware abhaken. An der liegts nicht. Auch dein USB Adapter ist damit erst mal aus dem Schneider.
Moin, die Anschlüsse habe ich geprüft, sind korrekt verdrahtet. MfG HUE \a
Hallo nochmals, es scheinen mehrere Bytes anzukommen, ich habe mit einem selbstgeschriebenen Programm auf dem PC immer mehrere Bytes auslesen können, obwohl ich im Assembler nur ein 'U' sende. Das 'U' kommt aber nicht an. Es kommen nur 0x00 an. Hat jemand noch einen Tipp? MfG HUE \a
Hue \a schrieb: > Hat jemand noch einen Tipp? Immer derselbe. Bei diesen Symptomen ist es zu 99% so, dass der µC mit einer anderen Taktrate arbeitet als du denkst. Ich bin jetzt aber ehrlich gesagt zu faul ein Assembler-Testprogramm zu schreiben. In C würdest du eines auf der weiter oben schon verlinkten Troubleshooting Seite finden. > es scheinen mehrere Bytes anzukommen, ich habe mit einem > selbstgeschriebenen Programm auf dem PC immer mehrere Bytes auslesen > können Für die ersten Tests würde ich kein selbstgeschriebenes Programm verwenden. Stichwort: Mehrfrontenkrieg. Du weißt dann nie ob das Problem beim Sender oder beim Empfänger liegt. Auf PC-Seite würde ich zuerst auf eine bewährte, nachweislich funktionierende Lösung wie zb HTerm setzen.
Hallo, ich habe in den Troubleshooting einen Hinweis auf das CLKDIV Bit gefunden und kann es in den Fuses nicht finden. In welchem Register steht das denn? MfG HUE \a
..mehrere Bytes statt nur einem? Das könnte an einer falschen Baudrate liegen. Oder an was anderem :-) Hack doch mal ein kleines Bruteforcetestprogramm zusammen, etwa so wie folgt (in Pseudocode):
1 | main() |
2 | {
|
3 | char pTemp[11]; |
4 | |
5 | // enable tx |
6 | UCSRB = (1 << TXEN); |
7 | |
8 | for (uint16_t ubrr = 0; ubrr < 1024; ubrr++) |
9 | {
|
10 | UBRRH = ubrr >> 8; |
11 | UBRRL = ubrr & 0xFF; |
12 | |
13 | sprintf(pTemp, "..%d..\n", ubrr); |
14 | |
15 | uart_send_string(pTemp); |
16 | _delay_ms(200); |
17 | } |
18 | |
19 | while (1) |
20 | STATUS_LED_TOGGLE(); |
21 | } |
Dessen Ausführung sollte man abwarten können (gut 200 Sekunden Verwartezeit sofern F_CPU halbwegs passt, zzgl. Übertragungszeiten, das ist abwartbar), und irgendwann(tm) sollte dann auch was sinnvolles(tm) im Terminal ankommen. Wenn gar nie nicht nix sinnvolles kommt-> Nochwoanderseinbug. Wenn was sinnvolles kommt (hier: ein funktionierender Wert für UBRR), dann kann man auf F_CPU und co zurückschließen. Hierzuworkstation sieht der Anfang der Ausgabe übrigens so aus:
1 | �����!�h�I�I�I�I�)��ד���u�ץj���Jխ��J�Zū����W�jVT�%I��IʖI�..22..�..23.. |
2 | ..24.. |
3 | ..25.. |
4 | ..26.. |
5 | ..27.. |
6 | ..28.. |
7 | .N29.. |
8 | ^^3`^^ |
9 | ^^sa^^ |
10 | ��cļ����t����DŽ�����T������G�����G�<�#��##|�Bcc|�B� |
..wobei rein rechnerisch die 25 korrekt ist (16MHz, 38400). Also, viel Spaß!
Hallo liebe Forumsleser, dies wird meine letzte Anfrage bezüglich meines Problems sein, ich habe das Thema zu lange strapaziert, ich hätte nur noch eine Bitte, mein gepostetes Datenfile einmal zu untersuchen. Ich habe die Daten vom ATmega32 empfangen, welchen ich wie im Quellcode beschrieben auf 9600Baud, 8 Bit, keine Parität, ein Stopbit eingestellt habe. Dann habe ich auf meinem Rechner ein Programm geschieben, welches die Datenrate von 1 bis fast unendlich laufen lies, und die Ergebnisse des Empfangs in die Datei data.dat geschieben habe. Der Aufbau der Datei ist pro Zeile folgendermaßen: Baudrate Data: 'empfangene Daten' End Ich werde aus den empfangenden Daten nicht schlau, es sind verschiedene Zeichen, meistens mehrere Bytes. Bitte helft mir ein letztes Mal, ich weiss mir keinen Rat mehr. MfG HUE \a
Hue \a schrieb: > Ich werde aus den empfangenden Daten nicht schlau, Im Großen und Ganzen weist Du nach, dass Deine Methode, die Baudrate des PC kontinuierlich zu ändern, Essig ist. Das Ergebnis springt, und zwar immer ziemlich genau dann, wenn eine neue Standard-Baudrate erreicht ist, z.B. bei 2400 und 4803 Baud, Warum der Sprung nicht immer bei dem exakten Erreichen der Standard-Baudrate ist, bleibt wohl ein Geheimnis Deines Programms. Ein weiteres Geheimnis bleibt, warum Du nicht endlich die Methode änderst und einen der gemachten Vorschläge durchführst, sondern stattdessen das weiter betreibst, was weiter oben so schön als Zweifrontenkrieg bezeichnet wurde. Ein C-Programm, das in Verbindung mit einem Terminalprogramm die Baudrate (und diesmal wirklich kontinuierlich) ändert, wurde bereits vorgeführt. Mach das mal. (P.S. Wenn Dein Problem im Handling eines C-Programms liegt („wie kriege ich das ans Laufen?“: das hättest Du in dieser Zeit längst gelöst. Oder in Assembler geschrieben.)
Hurra,
ein Fehler im Quelltext:
ldi r17,LOW(103)
ldi r16,HIGH(103)
out UBRRH,r16
out UBRRL,r17
habe ich ersetzt durch:
ldi r17,103
ldi r16,0
out UBRRH,r16
out UBRRL,r17
Jetzt geht es, also kein Fehler in der Taktung vom Chip! Ich bin
erleichtert,
VIELEN DANK für Eure Hilfen. Wirklich!
MfG
HUE \a
Hi Also im AVR Studio eigenen AVR Assembler/AVR Assembler2 funktioniert die erste Variante definitiv. MfG Spess
Die zweite Version ergibt:
1 | 000018 e617 ldi r17,103 |
2 | 000019 e000 ldi r16,0 |
und die erste genau dasselbe:
1 | 000018 e617 ldi r17,LOW(103) |
2 | 000019 e000 ldi r16,HIGH(103) |
Nicht dass ich irgendetwas Anderes erwartet hätte; nur der Vollständigkeit halber.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.