Hallo Forum, ich verwende einen ATMega168 mit 11 MHz Quarz. Ich gebe serielle Strings in einer Endlosschleife aus. Nach dem Einschalten kommen die Strings zunächt rüber, wie sie sollen, dann verschluckt sich die Schnittstelle plötzlich nach ca 1/2..1 Sekunde und verstümmelt die Ausgabe. Dies passiert nicht immer, aber meistens. Als Spannungsversorgung verwende ich ein Labornetzteil ca. 12V mit Strombegrenzung ca 1A, gefolgt von einem 78L05. Ich schalte bei laufendem Netzgerät vor dem 78L05. Weiss jemand, was das sein kann? C-Programm, Fuse-Bits und ein Bild der Datenausgabe habe ich angehängt. Wenn ich im C-Programm das _delay aktiviere, läuft alles Bestens. Ich will aber nicht immer 1 Sekunde warten müssen. Danke für Eure Antworten Hannes
Angehängte Dateien:
-
test_uart.png
949 Bytes -
test_uart_fuses.png
28 KB
Hannes schrieb: > ich verwende einen ATMega168 mit 11 MHz Quarz. Ich hoffe doch, dass es tatsächlich 11.0592MHz sind. Hannes schrieb: > Nach dem Einschalten kommen die Strings zunächt rüber, wie sie sollen, > dann verschluckt sich die Schnittstelle plötzlich nach ca 1/2..1 Sekunde > und verstümmelt die Ausgabe. Dies passiert nicht immer, aber meistens. HaliHallo ist doch aber ganz nett. Da wird eine Dateneins für ein Stoppbit gehalten. D.h. die Taktraten passen nicht. mfg.
Thomas Eckmann schrieb: > Da wird eine Dateneins für ein Stoppbit gehalten. D.h. die Taktraten > passen nicht. Denke ich nicht, da es nur einmal passiert.
genau 11MHz oder eher 11,059 MHz für fehlerfreie Baud bis 230400 Bd bei 250000 Bd hast du 7,8% Fehler ! warum benutzt du nicht die USART Macros ? geht auch in C http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART .equ F_CPU = 4000000 ; Systemtakt in Hz .equ BAUD = 9600 ; Baudrate ; Berechnungen .equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden .equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate .equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" .endif
Joachim B. schrieb: > warum benutzt du nicht die USART Macros ? Die sind total veraltet. Macht man heute so:
1 | #ifndef F_CPU
|
2 | #error F_CPU unkown
|
3 | #endif
|
4 | |
5 | #define BAUD 9600L // HIER AENDERN! MUSS UEBER include stehen!
|
6 | #include <util/setbaud.h> |
7 | |
8 | #ifdef UBRR0H
|
9 | |
10 | #define UART0_UBRRH UBRR0H
|
11 | #define UART0_UBRRL UBRR0L
|
12 | #define UART0_UCSRA UCSR0A
|
13 | #define UART0_UCSRB UCSR0B
|
14 | #define UART0_UCSRC UCSR0C
|
15 | #define UART0_UDRE_BIT_VALUE (1<<UDRE0)
|
16 | #define UART0_UCSZ1_BIT_VALUE (1<<UCSZ01)
|
17 | #define UART0_UCSZ0_BIT_VALUE (1<<UCSZ00)
|
18 | #ifdef URSEL0
|
19 | #define UART0_URSEL_BIT_VALUE (1<<URSEL0)
|
20 | #else
|
21 | #define UART0_URSEL_BIT_VALUE (0)
|
22 | #endif
|
23 | #define UART0_TXEN_BIT_VALUE (1<<TXEN0)
|
24 | #define UART0_UDR UDR0
|
25 | #define UART0_U2X U2X0
|
26 | |
27 | #else
|
28 | |
29 | #define UART0_UBRRH UBRRH
|
30 | #define UART0_UBRRL UBRRL
|
31 | #define UART0_UCSRA UCSRA
|
32 | #define UART0_UCSRB UCSRB
|
33 | #define UART0_UCSRC UCSRC
|
34 | #define UART0_UDRE_BIT_VALUE (1<<UDRE)
|
35 | #define UART0_UCSZ1_BIT_VALUE (1<<UCSZ1)
|
36 | #define UART0_UCSZ0_BIT_VALUE (1<<UCSZ0)
|
37 | #ifdef URSEL
|
38 | #define UART0_URSEL_BIT_VALUE (1<<URSEL)
|
39 | #else
|
40 | #define UART0_URSEL_BIT_VALUE (0)
|
41 | #endif
|
42 | #define UART0_TXEN_BIT_VALUE (1<<TXEN)
|
43 | #define UART0_UDR UDR
|
44 | #define UART0_U2X U2X
|
45 | |
46 | #endif //UBRR0H
|
47 | |
48 | |
49 | static void |
50 | uart_init (void) |
51 | {
|
52 | UART0_UBRRH = UBRRH_VALUE; // set baud rate |
53 | UART0_UBRRL = UBRRL_VALUE; |
54 | |
55 | #if USE_2X
|
56 | UART0_UCSRA |= (1<<UART0_U2X); |
57 | #else
|
58 | UART0_UCSRA &= ~(1<<UART0_U2X); |
59 | #endif
|
60 | |
61 | UART0_UCSRC = UART0_UCSZ1_BIT_VALUE | UART0_UCSZ0_BIT_VALUE | UART0_URSEL_BIT_VALUE; |
62 | UART0_UCSRB |= UART0_TXEN_BIT_VALUE; // enable UART TX |
63 | }
|
Über das Include von <setbaud.h> werden die optimalen Werte ermittelt. Unterstützt der µC auch noch U2X, dann wird das genutzt, um einen noch präziseren Wert für die Baudrate zu laden. Die obigen Defines machen das Ganze noch portabel, damit die Registernamen auf AVRs der älteren (z.B. ATMega8) und der neueren Generation (z.B. ATmega88) einheitlich angesprochen werden können.
Frank M. schrieb: > Joachim B. schrieb: >> warum benutzt du nicht die USART Macros ? > > Die sind total veraltet. ist das die Radig Variante ? kommt mir auch bekannt vor, wollte ich grad nicht posten, aber egal ich vermisse beim TO (und hier) die Zuordnung zu F_CPU aber egal, wenn ich nicht erkenne wie der TO zur Einstellung kommt ist es schwer Tipps zur Entfehlerung zu geben.
Joachim B. schrieb: > aber egal ich vermisse beim TO (und hier) die Zuordnung zu > F_CPU er wird sie wie es üblich ist im Makefile oder den Projekteinstellungen gemacht haben. Wenn sie nicht stimmen würde, dann würde es gar nicht Funktionieren.
Ich verwende natürlich einen 11.0592 MHz Quarz. Da ist UBRR0 = 71 schon richtig. Ansonsten, portabel oder nicht, ist mir voerst wurscht - ich will vielmehr rausfinden, wo dieses Verschlucken herkommt. Passiert immer nur nach dem Einschalten 1 bis 2 mal, dann läuft alles stundenlang ohne Fehler. Im ersten Listing war das delay noch aktiv. Anbei nochmal der Code. Hannes
Joachim B. schrieb: > ist das die Radig Variante ? Weiß jetzt nicht, was Du meinst. Diese veralteten BAUD-Macros schwirren hier irgendwo in irgendeinem Wiki rum und werden immer wieder gekupfert. > kommt mir auch bekannt vor, wollte ich grad > nicht posten, aber egal ich vermisse beim TO (und hier) die Zuordnung zu > F_CPU Er hats anscheinend mit dem Taschenrechner ausgerechnet und dann einfach die errechnete Zahl eingesetzt:
1 | UBRR0L=71; |
Sowas macht man natürlich nicht. Ändert man irgendwann die Prozessor-Taktfrequenz, wundert man sich, warum das Programm nicht mehr läuft. setbaud.h ist daher angesagt. Selbstverständlich gibt setbaud.h auch eine Warnung aus, wenn die erzielte Baudrate zu stark von der gewünschten abweicht:
1 | # warning "Baud rate achieved is higher than allowed"
|
bzw.
1 | # warning "Baud rate achieved is lower than allowed"
|
Die Standard-Toleranz ist 2%, kann aber durch Definition von BAUD_TOL überschrieben werden, z.B.
1 | #define BAUD_TOL 3 // allow 3%
|
2 | ...
|
3 | #include <setbaud.h> |
> aber egal, wenn ich nicht erkenne wie der TO zur Einstellung kommt ist > es schwer Tipps zur Entfehlerung zu geben. Eben. Man hat da auch keine große Lust, nachzurechnen, ob 71 überhaupt der richtige Wert ist. Sowas lässt man vom Preprozessor ausrechnen oder benutzt direkt das richtige Include dafür.
:
Bearbeitet durch Moderator
selbstverständlich steht im makefile F_CPU = 11059200 ohne UL, wie es sich gehört
Hannes schrieb: > selbstverständlich steht im makefile und welche Baudrate macht dir Kummer ? alles Dinge die ich beim drüberschauen vermisst habe Frank M. schrieb: > Eben. Man hat da auch keine große Lust, nachzurechnen, ob 71 überhaupt > der richtige Wert ist. QED :-)
Hannes schrieb: > Ich verwende natürlich einen 11.0592 MHz Quarz. Da ist UBRR0 = 71 schon > richtig. Das Verschleiern bzw. Nicht-Erwähnen von Tatsachen scheint eine große Gabe von Dir zu sein ;-) Welche Baudrate willst Du denn? Was benutzt Du als Empfänger, was zur Ausgabe? Vielleicht einen PC mit einem dämlich programmierten Terminal-Programm, welches sich verschluckt? Oder ist es nur ein serielles Display, welches überläuft? Wenn Du Hilfe willst, sei bitte etwas präziser. Welches delay meinst Du eigentlich? Ich sehe im Source kein auskommentiertes. Da stehen zwei delay-Aufrufe, eins vor der Schleife, eins in der Schleife. Wenn Du das delay vor der Schleife rausnimmst, dann passiert der Fehler? Passiert das auch nach einem Drücken auf den Reset-Taster oder nur nach dem PowerOn? Wie weit kann man das delay vor der Schleife reduzieren, bis der Fehler auftritt?
:
Bearbeitet durch Moderator
serielle Schnittstelle Problem nach dem Einschalten Hannes schrieb: > Als Spannungsversorgung verwende ich ein Labornetzteil ca. 12V mit > Strombegrenzung ca 1A, gefolgt von einem 78L05. Ich schalte bei > laufendem Netzgerät vor dem 78L05. du schreibst viel aber das wesentliche gerade nicht Frank M. schrieb: > Das Verschleiern bzw. Nicht-Erwähnen von Tatsachen scheint eine große > Gabe von Dir zu sein ;-) > > Welche Baudrate willst Du denn? hihi, du hast mein Edit unterbrochen, 2 Seelen ein Gedanke
Frank M. schrieb: > Weiß jetzt nicht, was Du meinst. Diese veralteten BAUD-Macros schwirren > hier irgendwo in irgendeinem Wiki rum und werden immer wieder gekupfert. Was zeterst du denn an den alten Makros rum? Die haben die letzten 20 Jahre funktioniert, jetzt gibt es was neues und plötzlich sind die Scheisse? Hauptsache da kommt 71 raus. mfg.
Es nervt. Es gibt halt immer wieder ganz gescheite, die zu jedem Thama ihre schrägen Diskussionen anfangen müssen... So so. Die nette Herren Joachim B. und Frank M. haben also keine Lust, sich zum Thema zu äussern, weil Ihnen dies und das nicht passt und der TO keinen Präprozessor verwendet. Der TO wollte vermutlich das Ganze so einfach wie möglich darstellen. Keine Lust zum Rechnen? Aber mit ihren tollen Präprozessor-Kenntnisen angeben. UBRR0=71 ist für mich allemal leichter zu verstehen, als mich durch irgendwelche Formeln durchzuhangeln. Wer zu faul zum Rechnen ist, für den hat Atmel im Datenblatt eine Tabelle aufgeführt. Ihr könnt ja Eure Präprozessoren hochzujubeln. Das ist aber ein anderes Thema, als das, um das es hier geht. Auch geht es hier nicht darum, was passiert, wenn man den Quarz austauscht. Aber um das Thema geht es Euch gar nicht. Ihr wollt Euch bestenfalls ellenlang darstellen, das ist mir schon öfters aufgefallen. Es sind halt immer die gleichen.
Thomas Eckmann schrieb: > Was zeterst du denn an den alten Makros rum? Ähem, nix. Hab sie bis vor 4 Jahren auch noch selbst genutzt. ;-) > Die haben die letzten 20 Jahre funktioniert, jetzt gibt es was neues und > plötzlich sind die Scheisse? Von "plötzlich" kann keine Rede sein. Ich rede von der AVR-Libc von 2010. Das ist eine Ewigkeit her. Insbesondere bei hohen Baudraten ist es schon sinnvoll, U2X zur Verdoppelung der Geschwindigkeit heranzuziehen. Damit lassen sich wesentlich genauere Registerwerte erzielen. > Hauptsache da kommt 71 raus. Ja, vielleicht kommt da wirklich 71 raus. Woher soll ich das wissen? Ich kenne noch nicht mal die gewünschte Baudrate.
Die Ausgabe sieht aber sehr merkwürdig aus. Das sich da was verschluckt, könnte ich mir noch vorstellen, wenn nach dem 'Halli' noch andere unverständliche Bytes kommen würden. Aber das da ausgerechnet 1 Byte über den Jordan geht und dann ist Ruhe bis der Text erneut anfängt, kommt mir etwas eigenartig vor. Ich würde mal so was machen
1 | int main( void ) |
2 | {
|
3 | uart_init(); |
4 | |
5 | // _delay_ms(1000);
|
6 | |
7 | serial_print("Test\r"); |
8 | |
9 | for(;;) |
10 | {
|
11 | serial_print("Hallo Forum!\r"); |
12 | _delay_ms(10); |
13 | }
|
14 | }
|
um auszuschliessen, dass da dazwischen ein Reset passiert. Einen ungewollten Reset erkennen zu können, war gerade bei so einfachen Testprogrammen noch nie verkehrt.
:
Bearbeitet durch User
Schon wieder diese Klugschwätzern schrieb: > Es sind halt immer die gleichen. Ja, klar. Deshalb heisst Du jetzt auch "Schon wieder diese Klugschwätzern" und es ist Dein erstes Posting auf µC.net in Deinem beschissenen Leben. Um es klarzustellen: Ich muss hier nicht helfen. Ich habe aber dem TO eine Alternative aufgezeigt (sogar mit fertigem Code), welche er einfach nur in seinen C-Quellcode reinkopieren muss, um anschließend zu testen. Das dauert noch nichtmals 5 Minuten - vielleicht sogar mit der Aussicht, dass das Problem nachher wegen Nutzung von U2X verschwunden ist. Was also hast Du an der Qualität der Hilfestellung auszusetzen? Was ist Dein Beitrag zum Thema? Genau: Gar keiner.
Schon wieder diese Klugschwätzern schrieb: > Es nervt. > > Es gibt halt immer wieder ganz gescheite, die zu jedem Thama ihre > schrägen Diskussionen anfangen müssen... meinst du dich? mich nervt es wenn einer sowas schreibt was den TO keinen Pups weiterbringt > So so. Die nette Herren Joachim B. und Frank M. haben also keine Lust, > Der TO wollte vermutlich das Ganze so einfach wie möglich darstellen. wahnsinnig vereinfacht ohne Baudrate ! > UBRR0=71 ist für mich allemal leichter zu verstehen, als mich durch > irgendwelche Formeln durchzuhangeln. Wer zu faul zum Rechnen ist, für > den hat Atmel im Datenblatt eine Tabelle aufgeführt. OK dann sag mal ob das mit seiner Baudrate klappt > Auch geht es hier nicht darum, was passiert, wenn man den Quarz > austauscht. dann eben nicht, der ist ja auch unwichtig dabei > Aber um das Thema geht es Euch gar nicht. Ihr wollt Euch bestenfalls > ellenlang darstellen, das ist mir schon öfters aufgefallen. und was geschieht hier gerade, du ach so toller Anonymer stellst dich auch gerade irgenwie dar und was hat das zur Lösung beigetragen ?
also, ich fasse zusammen: 1. Ich verwende einen Quarz mit 11.059200 MHz 2. UBRR0=71 kann man ausrechnen oder im Datenblatt nachschlagen. Ich habe das Beispiel absichtlich so kuz wie möglich gemacht. Ansonsten verwende ich auch ein Makro für den PP. 3. Der ATMega soll mit einem anderen ATMega kommunizieren. das geht auch sehr gut, ausser den kurzen Aussetzern nach dem Einschalten. 4. Ich habe mir den Datenstrom mit einem Speicheroszi angesehen und dabei Aussetzer festgestellt. Zur Probe hab ich mir den Datenstrom auf eine Spezielle Terminalsoftware geschickt (Docklight, nix "dämlich programmierten Terminal-Programm") 5. Ein Reset bei laufender Versorgungsspannung löst keinen Fehler aus 6. das Delay kann man auf ca. 900 ms reduzieren. 7. die arroganten Anmerkungen einiger weniger sind "wenig hilfreich", wie Mutti sagen würde. Wenn ihr nichts konstruktives beitragen wollt, dann schreibt halt nichts. Habt ihr nichts besseres zu tun, als hier rumzulästern? Allen anderen vielen Dank Hannes
Angehängte Dateien:
-
baudrate.png
41 KB
Ach ja, 8. Die Baudrate ist 9600. Dazu anbei aus dem Datenblatt.
Hannes schrieb: > die arroganten Anmerkungen einiger soso Hannes schrieb: > Ach ja, 8. Die Baudrate ist 9600 na ja so mal eben zu letzt OK du musst meine Anmerkungen nicht mehr lesen.
Hannes schrieb: > Nach dem Einschalten kommen die Strings zunächt rüber, wie sie sollen, > dann verschluckt sich die Schnittstelle plötzlich nach ca 1/2..1 Sekunde > und verstümmelt die Ausgabe. Dies passiert nicht immer, aber meistens. Hannes schrieb: > 3. Der ATMega soll mit einem anderen ATMega kommunizieren. das geht auch > sehr gut, ausser den kurzen Aussetzern nach dem Einschalten. Also was denn nun? Geht es nach dem Einschalten zunächst und dann setzt es aus oder startet es vermüllt und läuft dann später. Vielleicht kannst du das mal klar stellen?
Hannes schrieb: > 5. Ein Reset bei laufender Versorgungsspannung löst keinen Fehler aus Das glaube ich nicht. Wenn du den Reset (händisch) so hinkriegst, dass er die UART kalt mitten in der Übertragung eines Bytes erwischt, dann sieht das Ergebnis auf der Empfängerseite genau so aus, wie es bei dir aussieht. Oft genug gesehen. Das du ihn da nicht beim ersten mal händisch resetten dabei erwischt, ist nur zu verständlich. Schliesslich verbringt dein Programm die meiste Zeit in einem _delay_ms. Die Wahrscheinlichkeit, dass du per Handauslösung den µC kalt mitten im _delay_ms erwischt ist daher weit höher, dals dass du ihn gerade dann dabei erwischt, wenn auf der UART Bytes rausgehen. Schmeiss einen anderen Text beim Programmstart raus, und dann weisst du es genau. Wenn bei einem derart modifiziertem Programm in der Ausgabe zwar der 'Hickup' aufscheint, aber in der Zeile davor NICHT der Resettext, dann hast du einen Punkt. Aber erst dann.
:
Bearbeitet durch User
ich denke auch, dass ein Reset passiert. Kann man leicht feststellen, so wie Karl Heinz schon sagte. Mich würde interessieren, ob der Programmcode (weiter oben) komplett ist, oder ob Hannes uns nicht alles zeigt. Falls zweiteres, tippe ich auf einen Interrupt ohne passender isr()
Hannes schrieb: > 4. [...] (Docklight, nix "dämlich programmierten Terminal-Programm") Nunja, dieser Eindruck drängte sich aber auf. Immerhin schickst Du nur ein '\r' (also ein CR) und das Terminal-Programm erzeugt trotzdem zusätzlich ein NL ('\n'), indem es eine neue Zeile beginnt. Das ist standardmäßig falsch - kann aber durch entsprechende Einstellungen, die nicht dem Standard entsprechen, so abgeändert werden. Es ging mir auch nur um die spärlichen Infos, die den Leser geradezu dazu zwingen, seine Phantasie spielen lassen zu müssen und auf vollkommen abwegige Gedanken zu kommen. Aber offenbar hast Du Dir den Schuh selbst angezogen mit dem "dämlich programmierten Terminalprogramm", obwohl dazu überhaupt kein Anlass bestand. > 5. Ein Reset bei laufender Versorgungsspannung löst keinen Fehler aus Der Fehler taucht also nur auf, wenn die Versorgungsspannung eingeschaltet wird. Vielleicht ein prellender Schalter? Wie legst Du die Versorgungsspannung an? Durch Einschalten Deines Netzteils oder gibt es da noch einen Schalter vor dem µC? Der Fehler stellt sich nach 120 ausgegebenen Zeichen ein - jedenfalls dann, wenn da obige Fehlerbild immer dasselbe ist. Bei 9600Bd wären es bei 8Bit no parity: 1 Startbit + 8 Bit + 1 Stoppbit = 10 Bit, also 960 Zeichen pro Sekunde. Der Fehler tritt damit nach 120/960 = 0,125 Sekunden auf. Jetzt wäre der Test von Karl Heinz sinnvoll. Die Frage, ob ein vorzeitiger Reset auftritt, sollte man auf jeden Fall klären. Da beim Drücken von Reset bei eingeschalteter Versorgungsspannung kein Fehler auftritt (obwohl ich dabei doch eher die Meinung dazu von Karl Heinz teile), wäre nun auch die Frage nach einem Schaltbild angebracht. Sieht jetzt doch eher nach einem HW-Problem aus. > 7. die arroganten Anmerkungen einiger weniger sind "wenig hilfreich", > wie Mutti sagen würde. Wenn ihr nichts konstruktives beitragen wollt, > dann schreibt halt nichts. Habt ihr nichts besseres zu tun, als hier > rumzulästern? Sehe ich genauso.
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
programmstart_reset.png
1,8 KB
@Mike: Der µC fängt an, korrekte Strings auzugeben, dann nach ca. 1/s kommt ein verstümmelter String, danach kommen nur noch fehlerfreie Strings. @Karl-Heinz: Das ist klar, der letzte String kann u. U. abgewürgt werden. Aber nach dem Reset geht es gleich fehlerfrei weiter. Hier mal mit eigenem String für den Programmstart siehe Bild
Hannes schrieb: > Hier mal mit eigenem String für den Programmstart Und das zugehörige Programm? Welchen Text gibst du aus? Ist das nur 'Programmstart' oder ist das 'Hallo Programmstart'? Ehrlich ich mag nicht mehr dir alles aus der Nase ziehen. Du hast das Problem. NIcht ich. > Aber nach dem Reset geht es gleich fehlerfrei weiter. Ja, das soll vorkommen. Bis zum nächsten Reset. Wenn dein Programm so aussieht, wie ich denke das es aussieht (wovon ich mich aber gerne überzeugen möchte), dann ist die Ausgabe doch recht eindeutig: Du hast Resets im Prozessor. Jetzt muss man halt rauskriegen, warum die da sind. Fangen wir mit dem 90% Treffer an: Blockkondensatoren an der Versorungsspannung?
:
Bearbeitet durch User
Ich vermute, dass du den AVRISP MKII dauerhaft angesteckt hast? Nach Anlegen der Versorgungsspannung zieht der nach kurzer Zeit die RESET-Leitung zum Testen auf Masse.
chris schrieb: > Ich vermute, dass du den AVRISP MKII dauerhaft angesteckt hast? > Nach Anlegen der Versorgungsspannung zieht der nach kurzer Zeit die > RESET-Leitung zum Testen auf Masse. Echt? Klasse! :-)
chris schrieb: > Ich vermute, dass du den AVRISP MKII dauerhaft angesteckt hast? > Nach Anlegen der Versorgungsspannung zieht der nach kurzer Zeit die > RESET-Leitung zum Testen auf Masse. Bingo! mfg.
Angehängte Dateien:
-
uarthardw.png
66 KB
@Frank M das \n erscheint, weil ich es so eingestellt habe, dass nach jedem \r eine neue Zeile beginnt. Es lieft nicht am Terminalprogramm. Den Fehler sieht man auch auf dem Oszi und auch der µC, der eigentlich gedachte RX, erkennt einen Fehler. >Wie legst Du die >Versorgungsspannung an? Per Schalter stabile 12V an den Eingang vom 78L05. Prellender Schalter mit 0.5..1s glaub ich nicht. Anbei ein Plan. Es geht um RXDHOST und RXDHOST. Habe mir auch die 5V Versorgung nach dem Einschalten mit dem Speicheroszi angesehen, schaut absolut normal aus.
Danke an alle! Es war tatsächlich der AVRISP MKII! Ohne den geht alles tadellos. Hannes P.S.: Tut mir leid Karl-Heinz, wenn ich es Dir nicht recht machen konnte. Ich werde an mir arbeiten. Trotzdem Danke.
Gratulation! :-)
:
Bearbeitet durch Moderator
ich habe während der laufenden Ausgabe den Reset gedrückt. Die Platine war laufend unter Spannung. Da ist der Fehler natürlich nicht aufgetreten, jetzt wissen wir auch warum. Danke nochmal alle! Speziellen Dank natürlich an Chris!
Hannes schrieb: > ich habe während der laufenden Ausgabe den Reset gedrückt. Die Platine > war laufend unter Spannung. Da ist der Fehler natürlich nicht > aufgetreten, jetzt wissen wir auch warum. Ja, so eine elende kleine Mistsau! Ich habe diese Nettigkeit mal ins Tutorial aufgenommen: http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#Atmel_AVRISP_MKII mfg.
Hannes schrieb: > Danke an alle! > > Es war tatsächlich der AVRISP MKII! > > Ohne den geht alles tadellos. Hahaha! Der gute AVRISP MKII, der hier immer so gern empfohlen wird. Auf keinen Fall einen Eigenbau-Programmer nehmen, da hat man nur Ärger.... Großes Kino.
Hannes schrieb: > ich habe während der laufenden Ausgabe den Reset gedrückt. Die Platine > war laufend unter Spannung. Da ist der Fehler natürlich nicht > aufgetreten, jetzt wissen wir auch warum. Das passt doch nicht zusammen. Moderator hat sich wohl schon verärgert verabschiedet, aber er hatte Recht: >Das du ihn da nicht beim ersten mal händisch resetten dabei erwischt, >ist nur zu verständlich. Schliesslich verbringt dein Programm die meiste >Zeit in einem _delay_ms. Die Wahrscheinlichkeit ...
@der alte Hanns warum soll das nicht zusammenpassen? Der AVRISP ist es, der nach dem Einschalten in die Suppe spuckt. Resetet man aber über den Resetpin bei laufender Versorgungsspannung, betrifft das nur den µC. Den AVRISP interessiert das nicht solange er nur weiter Saft bekommt.
der alte Hanns schrieb: > Das passt doch nicht zusammen. Das passt sehr wohl zusammen und ist genau die Ursache für den Fehler. Daran hat auch der Moderator, wie alle anderen auch, nicht gedacht. Bis auf einer natürlich! der alte Hanns schrieb: >>Das du ihn da nicht beim ersten mal händisch resetten dabei erwischt, >>ist nur zu verständlich. Schliesslich verbringt dein Programm die meiste >>Zeit in einem _delay_ms. Die Wahrscheinlichkeit ... Das ist auch richtig. Aber in diesem Fall lag es nicht daran. Und es erklärt den Fehler auch nicht. mfg.
> Der AVRISP ist es, der nach dem Einschalten in die Suppe spuckt. richtig > Da ist der Fehler natürlich nicht aufgetreten... falsch Sie müssen nur oft genug drücken, um das Programm ausserhalb des delays, also innerhalb der Ausgabe zu erwischen.
der alte Hanns schrieb: > Sie müssen nur oft genug drücken, um das Programm ausserhalb des > delays, also innerhalb der Ausgabe zu erwischen. Darum geht es doch gar nicht. Auch Karl-Heinz hat, wie alle anderen, bis auf einen, im Nebel gestochert. Aber ich denke nicht, dass er jetzt einen Anwalt braucht. Der Fehler war nicht mit den üblichen Verdächtigen zu erklären. mfg.
:
Bearbeitet durch User
>Auch Karl-Heinz hat ... im Nebel gestochert.
Das finde ich nicht, er hat den Nagel auf den Kopf getroffen, dass
nämlich ein Reset dazwischenkommt; woher, das konnte er nicht wissen,
von MKII war nie vorher die Rede.
Einige Andere hatten seitenlang Baudrate-Berechnungen angestellt.
Thomas Eckmann schrieb: > Auch Karl-Heinz hat, wie alle anderen, bis auf einen, im Nebel > gestochert. Mein Nebelscheinwerfer war aber nicht so schlecht. Die Analyse, das wohl ein Reset daher kommt, war doch goldrichtig. Dass der Reset vom MKII kommt, kann ich nicht riechen. Wohl aber, dass es einen Reset gibt. dem µC ist es ja schliesslich strunzegal, wer den Reset auslöst. Nur dass der vom MKII zufällig genau zum richtigen Zeitpunkt kommt, was man von einem händischen Tippen auf den Reset-Taster wohl nicht behaupten kann. Würde man es oft genug händisch probieren, würde man den µC auch irgendwann mal genau zum richtigen Zeitpunkt abwürgen.
:
Bearbeitet durch User
Karl Heinz schrieb: > Mein Nebelscheinwerfer war aber nicht so schlecht. > Die Analyse, das wohl ein Reset daher kommt, war doch goldrichtig. Nachdem das mit dem Quarz und der Baudrate geklärt war, blieb ja auch nicht mehr viel übrig. mfg.
Karl Heinz schrieb: > Reset auslöst. Nur dass der vom MKII zufällig genau zum richtigen > Zeitpunkt kommt, was man von einem händischen Tippen auf den > Reset-Taster wohl nicht behaupten kann. Würde man es oft genug händisch > probieren, würde man den µC auch irgendwann mal genau zum richtigen > Zeitpunkt abwürgen. Was ich noch sagen wollte, aber vergass: Von daher ist diese Analyse ... > ich habe während der laufenden Ausgabe den Reset gedrückt. Die > Platine war laufend unter Spannung. Da ist der Fehler natürlich > nicht aufgetreten, jetzt wissen wir auch warum. ... einfach nur Quatsch. Der Fehler ist nicht 'natürlich nicht' aufgetreten. Der Fehler ist beim händischen Resetten nicht aufgetreten, weil die Wahrscheinlichkeit für den richtigen Zeitpunkt recht klein ist. > Resetet man aber über den Resetpin bei laufender Versorgungsspannung,# > betrifft das nur den µC. Yep. Und nur der ist wichtig. > Den AVRISP interessiert das nicht solange er nur weiter Saft bekommt. Wen interessiert der AVRISP? Der µC jagt die Daten per UART raus. Was der AVRISP macht, interessiert nicht die Bohne, solange er den µC in Ruhe seine Arbeit machen lässt.
@der alte Hanns Sie haben den Fehler scheints nicht richtig verstanden: Der Fehler gestaltet sich derart, dass nach dem Einschalten ca. 1 s lang korrekte Strings geliefert werden, dann plätzlich ein verstümmelter string und dann gehts normal weiter. Wenn man innerhalb der Ausgabe den Rest drückt, wird natürlich die gerade laufende Ausgabe verstümmelt. Das ist ja klar. Das ist aber kein Fehler. Und danach danach geht es ohne Unterbrechung fehlerfrei weiter. Das ist der Unterschied. Oben beschriebener Fehler tritt nicht mehr auf, solange VCC anliegt. Der Fehler tritt ausschliesslich nach Anlegen von VCC auf, weil der AVRISP immer nach dem Einschalten einen kurzen Puls auf Reset gibt.
an Hannes Lesen Sie Moderators Beitrag von 18:02 gründlich, dann verstehen Sie, was ich meinte.
Hannes schrieb: > @der alte Hanns > > Sie haben den Fehler scheints nicht richtig verstanden: glaub mir. Wir alle haben den Fehler verstanden, nachdem geklärt ist wo er herkommt. Das einzig interessante ist der Weg, wie man aus der originalen Fehlerbeschriebung von ganz oben dann letzten Endes zur eigentlichen Fehlerursache kommt und welche Gedankengänge da involviert sind, bzw. welche Schlussfolgerungen man aus dem geposteten Terminal-Mitschnitt zieht, die einen dann letzten Endes auf die Spur zur eigentlichen Fehlerursache bringen.
:
Bearbeitet durch User
>... einfach nur Quatsch. Der Fehler ist nicht 'natürlich nicht' >aufgetreten. Der Fehler ist beim händischen Resetten nicht aufgetreten, >weil die Wahrscheinlichkeit für den richtigen Zeitpunkt recht klein ist. das hat doch mit Zeitpunkt nichts zu tun. Nochamal: Korrekter Ablauf: Nach Start (durch Reset oder Spannung anlegen): Der µC gibt laufend Strings aus ohne Fehler. Dass natürlich die alte laufende Stringausgabe im Fall eines Resets abgebrochen wird ist ja klar. Aber das ist doch kein Fehler, das ist vollkommen normal: Fehlerhafter Ablauf: Der µC gibt laufend korrekt Strings aus. Plötzlich erscheint ein verstümmelter String, danach geht alles normal weiter. Es geht ausschliesslich darum, ob nach einem Neustart die Ausgabe fehlerfrei durchläuft oder ob ein Holperer auftritt. Dabei ist es völlig unerheblich ob und die Stringausgabe vor dem Reset abgebrochen wurde oder nicht. Wichtig ist, was danach passiert. Was soll denn das mit irgend einem Zeitpunkt zu tun haben? Aber egal - ich will kein Erbsenklauber sein. Wer das anders sehen will, bitteschön. Danke nochmal und schönen Abend Hannes
Das Missverständnis scheint darin zu liegen, dass unter 'Fehler' zweierlei verstanden wird: ich: das Textverstümmeln generell Hannes: das Textverstümmeln exakt 1 Sekunde nach Power-on
ja Hanns. Wobei das Textverstümmeln bzw -abbrechen durch einen Druck auf den Reset jedoch kein Fehler ist. Die alte Textausgabe hort akkurat mit dem -absichtlich - ausgelösten Reset auf. Kein Fehler, da ja gewollt. Ein unabsichtlich ausgelöster Reset erzeugt genau den gleichen Effekt. Aber ungewollt. Und ein Reset unbekannter Herkunft ist natürlich ein Fehler.
Okay.
Wir sind keine
> Erbsenklauber
aber es soll keiner zu uns sagen können
"Ech ben met där onzufreden. Du gähst den Dingen necht genögend auf den
Grond."
Ich wünsche ebenfalls einen Schönen Abend allerseits.
Karl Heinz schrieb: > Das einzig interessante ist der Weg, wie man aus der originalen > Fehlerbeschriebung von ganz oben dann letzten Endes zur eigentlichen > Fehlerursache kommt und welche Gedankengänge da involviert sind, bzw. > welche Schlussfolgerungen man aus dem geposteten Terminal-Mitschnitt > zieht, die einen dann letzten Endes auf die Spur zur eigentlichen > Fehlerursache bringen. Das geht ganz schnell. Als Besitzer eines Avrisp passiert einem das nur einmal (beim ersten Mal sucht man sich noch einen Wolf, danach hat sich diese Erfahrung für immer ins Gedächtnis eingebrannt). Es war nur eine Frage der Zeit bis jemand auftaucht der selber einen avrisp besitzt und bei der Fehlerbeschreibung sofort die richtige Idee hat.
:
Bearbeitet durch User
OK Hanns, is schon klar, danke und schönen Abend!
Bernd K. schrieb: > Es war nur eine Frage der Zeit bis jemand auftaucht der selber einen > avrisp besitzt und bei der Fehlerbeschreibung sofort die richtige Idee > hat. Ja so war es ;) Hab mir das gleich gedacht nach dem Lesen des Eingangspostings, weil im Screenshot zu erkennen war, dass der Programmer ein AVRISP ist. lg Chris
Hi, der AVRISP MK II hat mich auch schon übel genarrt. Da habe ich laaaange rumgesucht, bis ich dem auf die Schliche kam, tagelang! Eine Ungeheuerlichkeit, dass ein Programmer eigenmächtig auf den Controller zugreift! Der hat gefälligst hochohmig zu sein, wenn er nicht aufgerufen wird. Und noch schlimmer ist, dass dieses Verhalten nirgendswo dokumentiert steht. Da war mir doch der simple Eigenbauprogrammer mit dem 74HC244 wesentlich sympathischer! Eine Frechheit, dieses Atmel-Geraffel! Und dann noch 40 Euro ausgeben dafür, dass man sich mächtig Ärger ins Haus holt. Greetz from Old München!
Hallo Hanns, ich hatte solche Probleme, trotz korrekter Software und Baudrate auch mal, so dass ich nun IMMER beide RX TTL-Eingänge mit einen Pullup Widerstand versehe. Beim AVR reicht es auch am RX Eingang den internen Pullup Widerstand zu aktivieren.
:
Bearbeitet durch User
Hi >der AVRISP MK II hat mich auch schon übel genarrt. Da habe ich laaaange >rumgesucht, bis ich dem auf die Schliche kam, tagelang! >Eine Ungeheuerlichkeit, dass ein Programmer eigenmächtig auf den >Controller zugreift! Der hat gefälligst hochohmig zu sein, wenn er nicht >aufgerufen wird. ... Ich benutze den AVR ISP MKII seit über 10 Jahren. Das Verhalten ist mir in der ganzen Zeit nicht, und schon gar nicht unangenehm aufgefallen. Für mich fällt das eher unter Jammern auf hohem Niveau. MfG Spess
Hallo Spess, es hat mit Jammern nichts zu tun, wenn der Programmer eine halbe Sekunde nach Power to the Bauer eigenmächtig den uC resetet und einen dadurch auf die Palme bringt.. Bei 95% aller Anwendungen fällt das nicht auf und stört nicht. Aber wenn doch, dann geht halt die Sucherei los. Woher soll man denn sowas wissen, wenn es nirgends steht. münchnerische Grüsse vom Fred
@Uwe S. Wenn ein MAX232 vorgeschaltet ist, braucht's keine Pullups. Die sind im Eingang vom Maxe schon drin. sicher, ohne Max sollte man Eingänge nie offen lassen, do is definiertes Potential scho wichtig.
Munich Fred schrieb: > Aber wenn doch, dann geht halt die Sucherei los. Woher soll man denn > sowas wissen, wenn es nirgends steht. Steht doch hier im Tutorial: http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#Atmel_AVRISP_MKII mfg.
:
Bearbeitet durch User
Schlaumeier. Weiter oben hab ich vorher gelesen, dass Du das heite erst reingeschrieben hast. Hast Du doch selber geschrieben, oder?
Munich Fred schrieb: > Schlaumeier. > > Weiter oben hab ich vorher gelesen, dass Du das heite erst > reingeschrieben hast. Hast Du doch selber geschrieben, oder? Heute war es schon gestern. Aber lieber spät als nie. mfg.
Angehängte Dateien:
-
ohneAVRISP.png
2,1 KB -
mitAVRISP.png
2,2 KB
Hallo, für alle, die es interessiert, habe ich hier mal mit dem Speicheroszi das Einschaltverhalten mit und ohne angesteckten AVRISP aufgezeichnet und angehängt. Oben jeweils die geschaltete 12V-Spannung vor dem 78L05, unten die Spannung am Reset-Pin vom µC. Grüsse Hannes
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.