Guten Tag,
das ist mein erster Beitrag auf diesem Forum, darum entschuldigt, wenn
der Post nicht ganz vollständig ist. Ich arbeite gerade an einem
Programm, dessen Ziel es ist, Daten vom PC über den UART fehlerfrei zu
übertragen. Der UART im groben funktioniert, ich kann Daten an den
Mikrokontroller schicken. Allerdings kommen die Fehler immer falsch an,
un zwar systematisch. Schicke ich ein Carriage Return
('\r'=0x0D=0b00001101), erhalte ich ein Y (=0x79=0b01111001). Schicke
ich einen Zeilenumbruch ('\n'=0x0A=0b00001010) kommt ein
Gleichheitszeichen (=0x3D=0b00111101) am MC an.
Was am MC ankommt habe ich mit dem folgenden Programm kontrolliert:
#define F_CPU 16000000L/*Taktfrequenz_ATmega328PB*/
#define Baud 19200L/*_Baudrate->Bitrate/s->seriell*/
#define UBRR_Wert ((F_CPU/(16*Baud))-1)/*_Berechungen*/
#define Baud_Rundung ((F_CPU+8*Baud)/(16*Baud)-1)
#define Baud_Real (F_CPU/(16*(Baud_Rundung+1)))
#define Baud_Fehler ((Baud_Real*1000)/Baud)
#if ((Baud_Fehler<990)||(Baud_Fehler>1010))/*_Sicherung*/
#error Die_Datenuebertragungsgeschwindigkeit_ist_um_+-1%_zu_hoch/niedrig
#endif
#include <avr/io.h>
#include <avr/interrupt.h>/*Ermoeglichung_Interrupts*/
#include <util/delay.h>
#include <string.h>
#include <stdlib.h>
#include <stdint.h>
volatile char byte=0;/*datenbyte_fuer_RX*/
volatile uint8_t flag=0;
void Morsen(void)
{
PORTB&=(~(1 << PORTB5));/*LED1_an->Signal_Morse_-_Start*/
for(uint8_t i=0; i<8;
i++)/*Shiften_Byte_um_alle_8_Byte->Pruefung:Fokus_letztes_Bit*/
{
if (byte & 0x80)/*Pruefung_Bit_an_Stelle_0*/
{
PORTB &=~ (1 << PORTB4);/*D2_Ein->1*/
_delay_ms(500);
PORTB|=(1<<PORTB4);
_delay_ms(500);
}
else
{
PORTB&=~(1<<PORTB3);
_delay_ms(500);
PORTB|=(1<<PORTB3);
_delay_ms(500);
}
byte <<= 1;/*shiften_1_nach_rechts->neues_0._Bit*/
}
PORTB |= (1 << PORTB5);/*LED1_aus->Ende_Byte*/
_delay_ms(500);
flag=0;
}
int main(void)
{
sei();
UCSR0A&=~(1<<FE0);/*kein_Frame_-_Fehler*/
UCSR0A&=~(1<<DOR0);/*kein_Data_-_Overrun*/
UCSR0A&=~(1<<U2X0);/*keine_doppelte_Uebertragungsgeschwindigkeit*/
UCSR0A&=~(1<<MPCM0);/*keine_Multi_-_Prozessor_-_Kommunikation*/
UCSR0B|=(1<<RXCIE0);/*RX_-_Interrupt*/
UCSR0B&=~(1<<TXCIE0);/*kein_TX_-_Interrupt*/
UCSR0B&=~(1<<UDRIE0);/*kein_UDRE_-_Interrupt*/
UCSR0B|=(1<<RXEN0);/*Receiver*/
UCSR0B&=~(1<<TXEN0);/*kein_Transmitter*/
UCSR0B&=~(1<<UCSZ02);/*data_bit=8->[2:0]=011*/
UCSR0B&=~(1<<RXB80);/*kein_9._Datenbit_empfangen*/
UCSR0B&=~(1<<TXB80);/*kein_9._Datenbit_senden*/
UCSR0C&=~(1<<UMSEL01);/*asynchroner_Modus*/
UCSR0C&=~(1<<UMSEL00);
UCSR0C&=~(1<<UPM01);/*keine_Paritaet*/
UCSR0C&=~(1<<UPM00);/*kein_UPE(UCSR0A)-Flag*/
UCSR0C&=~(1<<USBS0);/*ein_Stoppbit*/
UCSR0C|=(1<<UCSZ01);/*8_Datenbits*/
UCSR0C|=(1<<UCSZ02);
UCSR0C&=~(1<<UCPOL0);/*keine_Abstimmung_Bitstelle_-_Clock*/
UCSR0D&=~(1<<RXSIE);/*kein_Start_-_Interrupt*/
UCSR0D&=~(1<<RXS);/*kein_Startbit_Interrupt*/
UCSR0D|=(1<<SFDE);/*Ueberwachung_Startbit*/
UBRR0H=Baud_Rundung>>8;/*Baud=_Bitrate->19,2kBit/s*/
UBRR0L=Baud_Rundung&0xFF;
DDRB=0xFF;/*PORTB->alles_Ausgaenge*/
PORTB=0xFF; /*alle_Ausgaenge=1->Dioden_aus*/
while (1)
{
if(flag)/*Morsen_UDR_von_Anfang_an*/
Morsen();
}
}
ISR(USART0_RX_vect)
{
byte=UDR0;/*speicherung_UDR0->Beendigung_ISR*/
flag=1;/*Morsen*/
}
Aus dem Programm lassen sich alle Einstellungen für den UART und
RXCIE-Interrupt vor der main-Schleife und in der main-Schleife ablesen.
Mein Mikrokontroller ist ein ATmega328PB mit zwei UARTs, ich benutze als
Entwicklungsumgebung AtmelStudio7 als Terminalprogramm HTerm. Die
Baudrate bei HTerm und im MC ist 19,2 kbps (seriell).
Ein bisschen habe ich im Forum schon nach Lösungen für das Problem
gesucht, aber weder ein zweites Stoppbit, noch ein Delay (in der
while(1)) zur Synchronisation des MC auf das Start-Bit noch eine
Überprüfung der Baudrate haben das Problem behoben.
Ich sitze an den Problem schon seit ein paar Tagen. Kann mir bitte
jemand einen Tipp geben, wie ich das Problem der falsch empfangen Daten
lösen kann?
Mit freundlichen Grüßen
Philipp
> UCSR0C|=(1<<UCSZ02);
?
Damit wird UCSZ1 gesetzt, oder?
Philipp K. schrieb: > Allerdings kommen die Fehler immer falsch an, Dann passt ja alles... Sorry, konnte nicht widerstehen. :)
Philipp K. schrieb: > Kann mir bitte jemand einen Tipp geben, wie ich das Problem der > falsch empfangen Daten lösen kann? Fehlt dir vielleicht ein Inverter? Wie sind PC und µC miteinander verbunden?
Bei Dir ist
1 | UBRR0H = ((16000000L+8*19200L)/(16*19200L)-1)>>8 = 0 |
2 | UBRR0L = ((16000000L+8*19200L)/(16*19200L)-1)&0xFF = 51 |
Die Standard Bilbiothek <util/setbaud.h> berechnet die gleichen Werte, deswegen wird es daran nicht liegen. Läuft der Prozessor denn wirklich auf 16 MHz? Das könntest du mit einer Blink-LED im Sekundentakt testen.
S. Landolt schrieb: > Damit wird UCSZ1 gesetzt, oder? Gute Frage. UCSZ02 hat den Wert 2. Ich würde auch gerne wissen, warum dieses Symbol für zwei unterschiedliche Register benutzt wird. Das passt nicht zur Registerbeschreibung im Datenblatt. In UCSR0B befindet sich nur das Bit UCSZ02. In UCSR0C befinden sich die Bits UCSZ00 und UCSZ01.
1 | UCSR0B&=~(1<<UCSZ02); // hier gehört es hin |
2 | |
3 | UCSR0C|=(1<<UCSZ01); // ok |
4 | UCSR0C|=(1<<UCSZ02); // das sollte sicher UCSZ00 heissen! |
Ja, ist aber leider nicht die Fehlerursache, die 1 vom Resetwert wird mit 1 überschrieben, und die Reset-1 von USCZ0 bleibt stehen. Ich habe mich täuschen lassen.
Angehängte Dateien:
Diese Kombination ist "Reserved":
1 | UCSR0D&=~(1<<RXSIE);/*kein_Start_-_Interrupt*/ |
2 | UCSR0D&=~(1<<RXS);/*kein_Startbit_Interrupt*/ |
3 | UCSR0D|=(1<<SFDE);/*Ueberwachung_Startbit*/ |
I'll be darned. Ich finde beim ATmega328PB kein UCSR0D - ist hier vom ATmega324PB die Rede?
Hallo, danke für die Antworten! Ich arbeite mit einem ATmega328PB. Das UCSR0D-Register findet man unter dem Punkt 25.11.5 UART Controll Register and Status Register n D. Wegen der Einstellung des UCSR0D: Anfangs habe ich auch gedacht, dass der Status "Reserved" ist. Zwar habe ich RXSIE aus, dafür aber RXCIE als RX-Interrupt und SFDE als Aktivator der Startbit-Überwachung an. Damit habe ich nur die Startbit_Überwachung an. Ich prüfe gleich noch die anderen Vorschläge. Jeder Vorschlag hilft.
Wolfgang schrieb: > Philipp K. schrieb: >> Kann mir bitte jemand einen Tipp geben, wie ich das Problem der >> falsch empfangen Daten lösen kann? > > Fehlt dir vielleicht ein Inverter? > Wie sind PC und µC miteinander verbunden? Einen Inverter habe ich tatsächlich nicht. Die Signale die ich bekomme sind augenscheinlich aber nicht einmal eine invertierte Variante der Ausgangssignale vom PC. PC und Mikrokontroller verbinde ich mit einem USB-Kabel mit Mikro-USB-Ausgang, den UART des MC's mit einem 9-Poligen RS232-Kabel.
Philipp K. schrieb: > Hallo, danke für die Antworten! > > Ich arbeite mit einem ATmega328PB. Das UCSR0D-Register findet man unter > dem Punkt 25.11.5 UART Controll Register and Status Register n D. Sowas gibt es beim 328PB nicht. Jedenfalls nicht in dem DB von Microchip. Weder das Register, noch einen Abschnitt mit der genannten Nummer.
Danke, c-hater, ich begann an meinem Verstand zu zweifeln. Hatte extra das aktuelle Datenblatt von Microchip heruntergeladen.
Stefan ⛄ F. schrieb: > Bei Dir ist >
1 | > UBRR0H = ((16000000L+8*19200L)/(16*19200L)-1)>>8 = 0 |
2 | > UBRR0L = ((16000000L+8*19200L)/(16*19200L)-1)&0xFF = 51 |
3 | > |
> > Die Standard Bilbiothek <util/setbaud.h> berechnet die gleichen Werte, > deswegen wird es daran nicht liegen. Läuft der Prozessor denn wirklich > auf 16 MHz? Das könntest du mit einer Blink-LED im Sekundentakt testen. Ich habe eine LED im Sekundentakt blinken lassen. Ich habe die Zeit auf die Hunderstelsekunde genau auf 1 s messen können - allerdings mit der Handystoppuhr. Einen Oszi habe ich bei mir gerade nicht. Allerdings ist mein MC mit 16 MHz geliefert worden und seit dem Erhalten habe ich an den Fusebits nicht geändert. Ich gehe von F_CPU=16MHz aus.
Philipp K. schrieb: > PC und Mikrokontroller verbinde ich mit einem USB-Kabel mit > Mikro-USB-Ausgang, den UART des MC's mit einem 9-Poligen RS232-Kabel. Klingt für mich sehr verwirrend. Richtig ist: PC --- USB/RS232wandler --- 9-pol-RS232-Kabel --- RS232/TTL-Wandler -- µC-UART Der RS232/TTL-Wandler kann z.B. MAX232 o.ä sein. Hast Du diesen Aufbau?
c-hater schrieb: > Philipp K. schrieb: >> Hallo, danke für die Antworten! >> >> Ich arbeite mit einem ATmega328PB. Das UCSR0D-Register findet man unter >> dem Punkt 25.11.5 UART Controll Register and Status Register n D. > > Sowas gibt es beim 328PB nicht. Jedenfalls nicht in dem DB von > Microchip. Weder das Register, noch einen Abschnitt mit der genannten > Nummer. Du hast Recht. Ich habe mich auf das Datenblatt 10/2015 gestützt. Allerdings ändert sich nichts am Problem, wenn ich UCSR0D rausnehme. Kennt ihr eine neuere Entsprechung / Verbesserung dafür?
> an den Fusebits nicht geändert. Ich gehe von F_CPU=16MHz aus
Also nach dem aktuellen Datenblatt läuft der ATmega328PB, wie alle seine
Geschwister, ab Werk mit 1 MHz.
HolgerT schrieb: > Philipp K. schrieb: >> PC und Mikrokontroller verbinde ich mit einem USB-Kabel mit >> Mikro-USB-Ausgang, den UART des MC's mit einem 9-Poligen RS232-Kabel. > > Klingt für mich sehr verwirrend. > > Richtig ist: > > PC --- USB/RS232wandler --- 9-pol-RS232-Kabel --- RS232/TTL-Wandler -- > µC-UART > > Der RS232/TTL-Wandler kann z.B. MAX232 o.ä sein. > > Hast Du diesen Aufbau? Nein, diesen Aufbau habe ich so nicht. Mir fehlt der RS232/TTL-Wandler für die Pegelwandlung 15V zu 5V. Diesen werde ich noch hinzufügen müssen. Danke für den Hinweis!
Philipp K. schrieb: > Du hast Recht. Ich habe mich auf das Datenblatt 10/2015 gestützt. Das ist spannend. Auch im entsprechenden Assembler-Includefile existiert das Register. Naja, Microchip halt. Mit der Pflege der Datenblätter hatten sie es noch nie so richtig...
S. Landolt schrieb: >> an den Fusebits nicht geändert. Ich gehe von F_CPU=16MHz aus > > Also nach dem aktuellen Datenblatt läuft der ATmega328PB, wie alle seine > Geschwister, ab Werk mit 1 MHz. Auf der Hochschule haben wir den Mikrokontroller für Timerinterrupt benutzt und dabei immer 16 MHz angenommen. Die Zeitmessung der LED-blink-Dauer über <util/delay.h> und _delay_ms war grob auch richtig. Ich beschäftige mich mal mit der Frequenz weiter.
Angehängte Dateien:
-
Systemtakt.png
110 KB
> immer 16 MHz angenommen
Wie dem auch sei - laut Anhang laufen ab Werk 8 MHz, mit dem gesetzten
CKDIV8 wird 1 MHz daraus.
HolgerT schrieb: > Richtig ist: > > PC --- USB/RS232wandler --- 9-pol-RS232-Kabel --- RS232/TTL-Wandler -- > µC-UART Was soll der Mist? Auf RS232 Pegel Wandeln braucht es nicht. Ein USB zu TTL Serial reicht doch aus. So: https://www.ebay.de/itm/FT232RL-3-3V-5-5V-FTDI-Mini-USB-to-TTL-Serial-UART-Adapter-Module-Cable-Ardu-ino/223727784480?hash=item3417371220:g:zcwAAOSwDF5d366w Die ganze AVR- und Arduino-Welt arbeitet mit solchen Dingern und sie haben noch nie was von RS232 Pegeln gehört weil es die nicht braucht!
c-hater schrieb: > Philipp K. schrieb: > >> Du hast Recht. Ich habe mich auf das Datenblatt 10/2015 gestützt. > > Das ist spannend. Auch im entsprechenden Assembler-Includefile existiert > das Register. > > Naja, Microchip halt. Mit der Pflege der Datenblätter hatten sie es noch > nie so richtig... Soviel zu der hier gern gestellten blöden Frage: "Was sagt denn das Datenblatt?!" SCNR
> Auf der Hochschule haben wir ... 16 MHz ...
Dann wurde ein fertig gekauftes Board mit Resonator oder Quarz benutzt,
und die Fuses waren vom Hersteller entsprechend geändert worden.
jo mei schrieb: > Die ganze AVR- und Arduino-Welt arbeitet mit solchen Dingern und > sie haben noch nie was von RS232 Pegeln gehört weil es die nicht > braucht! Und warum spricht Philipp dann die ganze Zeit von RS232 und einem RS232-Kabel? Weil er vermutlich keinen USB-TTL, sondern einen USB-RS232-Wandler benutzt! Und dann muß er natürlich RS232->TTL wandeln. Und auf diesen Wandler wollte ich hinweisen. Punkt!
Philipp K. schrieb: > PC und Mikrokontroller verbinde ich mit einem USB-Kabel mit > Mikro-USB-Ausgang, den UART des MC's mit einem 9-Poligen RS232-Kabel. Der UART liefert kein RS232-Signal. Wie passiert bei dir genaue die Signalumsetzung vom USB-Signal bis zum RX/TX des ATmega328?
S. Landolt schrieb: > I'll be darned. Ich finde beim ATmega328PB kein UCSR0D - ist hier vom > ATmega324PB die Rede? Guck mal auf meinen Screenshot direkt über deinem Beitrag.
Philipp K. schrieb: > Wegen der Einstellung des UCSR0D: Anfangs habe ich auch gedacht, dass > der Status "Reserved" ist. Zwar habe ich RXSIE aus, dafür aber RXCIE als > RX-Interrupt und SFDE als Aktivator der Startbit-Überwachung an. Damit > habe ich nur die Startbit_Überwachung an. Ach wie gemein! Jetzt sehe ich auch dass die Tabelle unter den drei Bits sich nur auf zwei Bits davon bezieht.
Philipp K. schrieb: > den UART des MC's mit einem 9-Poligen RS232-Kabel. RS232 hat invertierte Pegel. Der Ruhezustand (HIGH) ist -9V, dementsprechend ist LOW dann +9V. Wobei diede USB Adapter oft weniger Spannungshub liefern, als die ursprünglichen +/- 9V.
Ich hänge mal das Datenblatt an, welches das UCSR0D Register beschreibt. Das ist die letzte mir bekannte Fassung von Atmel. Irgendwie habe ich das Gefühl, dass Microchip die Datenblätter im Laufe der Zeit immer kaputter macht.
Das Verschwinden des UCSR0D ist nicht einmal in der 'Revision History' erkennbar. Und mir graust, wenn ich "• Change of document style" und "• New Microchip document number. Previous version was Atmel document 42397 rev.C." lese.
PS: Da ich keinen ATmega328PB zum Ausprobieren habe, stellt sich mir nun die Frage: gibt es dieses Register tatsächlich, und erfüllt es seine Funktion?
Es ist nicht das erste mal. Wir (die Community hier) haben Microchip auch schon mal erwischt, ganze Absätze im neuen Style einfach von anderen AVR kopiert zu haben obwohl sie fachlich gegensätzliche Infos hatten (da ging es um die notwendige Reihenfolge bei Zugriffen auf 16 bit Register). Und als sie die PIN-Diagramme im Arduino Style bunt machten, hatten sie auch einige Fehler eingebaut, wo es vorher richtig war.
S. Landolt schrieb: > Da ich keinen ATmega328PB zum Ausprobieren habe, stellt sich mir nun die > Frage: gibt es dieses Register tatsächlich, und erfüllt es seine > Funktion? Also ich würde mal davon ausgehen, dass das ursprüngliche Atmel-DB die Realität korrekter abbildet, also dass es das Register tatsächlich gibt und es auch seinen Job tut. Beweisen kann ich das derzeit nicht, weil ich ebenfalls keinen 328PB besitze. Aber wie Stefan F. schon korrekt anmerkte, ist das nicht der erste Fall, bei dem Microchip Atmel-DBs nachweislich kaputtredigiert hat. Und aus meiner eigenen Erfahrung mit diversen PICs kann ich hinzufügen, dass die Mikrochip-Datenblätter schon länger grundsätzlich ziemlich Scheisse sind, weil sie viele Fehler enthalten (viel mehr als man es vergleichsweise damals bei Atmel gewohnt war) und außerdem ganz offensichtlich kein sauberes Versionsmanagement und nur relativ selten überhaupt ein Bugfixing dafür erfolgt. Sogar wenn wegen Änderungen der Hardware-Revision eine neue DB-Version erschien, wurden oftmals bereits bekannte und bestätigte Fehler in der Dokumentation nicht behoben.
Philipp K. schrieb: > Einen Oszi habe ich bei mir gerade nicht. Ein Logiganalysator für ein paar Euro reicht völlig. Häng dich damit auf die RX- und die TX-Leitung vom µC und sende einmal vom µC und einmal vom PC das selbe Zeichen und vergleiche. Und zeige deinen Schaltplan. Sonst werden hier morgen noch irgendwelche Atmel Datenblätter von MicroChip diskutiert und deine Übertragung läuft trotzdem nicht.
Angehängte Dateien:
-
Fehler_Device_Signature.png
170 KB
S. Landolt schrieb: >> immer 16 MHz angenommen > Wie dem auch sei - laut Anhang laufen ab Werk 8 MHz, mit dem gesetzten > CKDIV8 wird 1 MHz daraus. Danke nochmal wegen deiner Beharrlichkeit zur Systemfrequenz: Ich habe beim Device Programming in AS7 nochmal nachgeguckt wegen den Fusebits: CKDIV8 ist aktiv, genauso wie von CKSEL[3:0] der interne RC-Oszillator als Quelle ausgewählt ist. Jetzt habe ich im aktuellen Datenblatt von 2018 nachgesehen. Bei F_CPU=1MHz hat der UART des MC eine Fehlerquote von 8,5%. Daher wollte ich die F_CPU auf 8MHz erhöhen wo die Fehlerquote niedriger ist und den CKDIV8-Fuse deaktivieren. Jetzt taucht aber der Fehler auf, dass die Device Signature nicht gefunden werden konnte. So kann ich die Fusebits nicht ändern. Wie kann man diesen Fehler beheben?
Philipp K. schrieb: > Ich habe beim Device Programming in AS7 nochmal nachgeguckt wegen den > Fusebits: CKDIV8 ist aktiv Wie kann das sein, du kannst die Fuses doch gar nicht auslesen! > Daher wollte ich die F_CPU auf 8MHz erhöhen wo die Fehlerquote > niedriger ist und den CKDIV8-Fuse deaktivieren. Jetzt taucht aber > der Fehler auf, dass die Device Signature nicht gefunden werden konnte. Dabei hast du wohl mehr als nur diese eine Fuse geändert. Vielleicht kommst du da noch raus, indem du eine externe Taktquelle an XTAL1 anschließt. Wenn nicht, scheiß den Controller weg oder besorge Dir einen sogenannten "High Voltage" Programmer.
Philipp K. schrieb: > Danke nochmal wegen deiner Beharrlichkeit zur Systemfrequenz: > Ich habe beim Device Programming in AS7 nochmal nachgeguckt wegen den > Fusebits: CKDIV8 ist aktiv, genauso wie von CKSEL[3:0] der interne > RC-Oszillator als Quelle ausgewählt ist. War das Thema nicht schon lange erledigt? Wenn die LED im Sekundentakt blinkt und das Programm so geschrieben ist, dass ein Sekundentakt rauskommen müsste, hat sich die Diskussion um den Systemtakt doch irgendwie erledigt, oder? Philipp K. schrieb: > Ich habe eine LED im Sekundentakt blinken lassen. Ich habe die Zeit auf > die Hunderstelsekunde genau auf 1 s messen können - allerdings mit der > Handystoppuhr.
Angehängte Dateien:
-
Realer_Aufbau.jpg
230 KB -
Schaltplan_UART_PC.jpg
220 KB
my2ct schrieb: > Philipp K. schrieb: >> Einen Oszi habe ich bei mir gerade nicht. > > Ein Logiganalysator für ein paar Euro reicht völlig. Häng dich damit > auf die RX- und die TX-Leitung vom µC und sende einmal vom µC und einmal > vom PC das selbe Zeichen und vergleiche. > Und zeige deinen Schaltplan. Sonst werden hier morgen noch irgendwelche > Atmel Datenblätter von MicroChip diskutiert und deine Übertragung läuft > trotzdem nicht. Anbei schicke ich den den Schaltplan plus ein Foto von dem richtigen Aufbau. Sicher fällt sofort der fehlende RS232-Wandler auf. Ich habe gestern noch schnell versucht im Laden den von Holger empfohlenen MAX233 zu kaufen, kam aber ein paar Minuten nach der Ladenschließung an, sodass ich gerade keinen habe. Um auf Wolfgang einzugehen: Ich schicke das Signal vom PC über HTerm hin zu einem RS232-Kabel, dass mit einem USB-Adapter an den PC angeschlossen ist. Dann schließe ich direkt, bisher ohne den TTL-Wandler, den TX des RS232-Kabels mit dem RX über ein Jumpwire zusammen. Gerade kommen +-9/+-12/+-15 V (unterschiedliche Angaben zum Pegel bei RS-Signal im Internet) am MC-UART an.
Philipp K. schrieb: > Sicher fällt sofort der fehlende RS232-Wandler auf. Allerdings. Du kannst doch nicht einfach mit +/- 9V direkt auf den RxD Eingang des AVR gehen! Der ist jetzt mit hoher Wahrscheinlichkeit kaputt. Abgesehen davon sind die Pegel bei RS232 invertiert. > Gerade kommen +-9/+-12/+-15 V (unterschiedliche Angaben zum Pegel) Wie wäre es mit Messen anstatt zu raten? Nach der Nummer möchte ich meinen Vorschlag mit der Soundkarte zurück ziehen. Mach Dir deinen Laptop nicht kaputt. Aber ich habe noch einen Kauftipp: Besorge Dir bei Aliexpress einen USB Isolator (https://de.aliexpress.com/item/33014611683.html) und einen USB-Hub mit eigenem Netzteil, damit du diese Sachen sicher an den Laptop anschließen kannst.
Stefan ⛄ F. schrieb: > Philipp K. schrieb: >> Ich habe beim Device Programming in AS7 nochmal nachgeguckt wegen den >> Fusebits: CKDIV8 ist aktiv > > Wie kann das sein, du kannst die Fuses doch gar nicht auslesen! > >> Daher wollte ich die F_CPU auf 8MHz erhöhen wo die Fehlerquote >> niedriger ist und den CKDIV8-Fuse deaktivieren. Jetzt taucht aber >> der Fehler auf, dass die Device Signature nicht gefunden werden konnte. > > Dabei hast du wohl mehr als nur diese eine Fuse geändert. Vielleicht > kommst du da noch raus, indem du eine externe Taktquelle an XTAL1 > anschließt. Wenn nicht, scheiß den Controller weg oder besorge Dir einen > sogenannten "High Voltage" Programmer. Ich kann dich beruhigen, der MC funktioniert noch. Gerade habe ich einen neues Programm für ein LED-Blinken daraufgeladen. Auf die Fuses kann ich über AS7->Device Programming->Fuse->LOW.CKDIV8->Programm zugreifen. Ich habe offenbar nichts verstellt, weil von vorein ich keine Device Signature erhalten habe.
Philipp K. schrieb: > Gerade kommen > +-9/+-12/+-15 V (unterschiedliche Angaben zum Pegel bei RS-Signal im > Internet) am MC-UART an. Damit gehen zwei Dinge schief. 1. Der µC bekommt an seinem DIO negative Spannung, die nur durch die Schäche der Ladungspumpe im USB-RS232-Wandler begrenz ist und deshalb den µC wahrscheinlich nicht schädigt. 2. Die Signalpolarität der übertragenen seriellen Signale ist falsch. Es fehlt ein Inverter (s.o.) Miss mal in deinem Aufbau mit einem Multimeter den Ruhepegel an RX und TX vom µC.
Wolfgang schrieb: > Philipp K. schrieb: >> Danke nochmal wegen deiner Beharrlichkeit zur Systemfrequenz: >> Ich habe beim Device Programming in AS7 nochmal nachgeguckt wegen den >> Fusebits: CKDIV8 ist aktiv, genauso wie von CKSEL[3:0] der interne >> RC-Oszillator als Quelle ausgewählt ist. > > War das Thema nicht schon lange erledigt? > Wenn die LED im Sekundentakt blinkt und das Programm so geschrieben ist, > dass ein Sekundentakt rauskommen müsste, hat sich die Diskussion um den > Systemtakt doch irgendwie erledigt, oder? > > Philipp K. schrieb: >> Ich habe eine LED im Sekundentakt blinken lassen. Ich habe die Zeit auf >> die Hunderstelsekunde genau auf 1 s messen können - allerdings mit der >> Handystoppuhr. Da hast Du recht. Ja, anderseits habe ich den internen RC-Oszillator als Taktgeber ausgewählt, der Fuse CKDIV8 ist offenbar auch gesetzt. Auf der Hochschule haben wir allerdings nie externe Clocks angeschlossen und ich habe gerade den Kommilitonen gefragt, der uns die MC besorgt hat. Er meinte, er hätte die Standardversion gekauft.
Philipp K. schrieb: > Er meinte, er hätte die Standardversion gekauft. Was auch immer auf der Standardversion drauf ist... Auf einem Photo von der µC-Platine könnte man nachgucken, ob ein Quarz/Resonator oder gar nichts an den Oszillator-Pins des µCs hängt.
Wolfgang schrieb: > Philipp K. schrieb: >> Er meinte, er hätte die Standardversion gekauft. > Was auch immer auf der Standardversion drauf ist... > Auf einem Photo von der µC-Platine könnte man nachgucken, ob ein > Quarz/Resonator oder gar nichts an den Oszillator-Pins des µCs hängt. Ich habe mir bei Freunden ein Multimeter besorgt und den Ruhezustand von RX TX am MC gemessen. U(RX)=0,14V, U(TX)=0,01V. Außerdem haben wir die Platine XplainedMini(http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega328P-Xplained-Mini-UG-DS50002659B.pdf) auf die Oszilator-Pins (PB6,PB7) geprüft. Der User-Guide besagt, dass eine 16MHz-Clock des Debuggers an den Clockinput-Pin des MC angeschlossen ist.
Philipp K. schrieb: > Der User-Guide besagt, dass > eine 16MHz-Clock des Debuggers an den Clockinput-Pin des MC > angeschlossen ist. Selbst wenn das tatsächlich so wäre (was ich nicht glaube): Das interessiert allerdings den µc kein bissel, jedenfalls solange nicht auch die Fuses so gesetzt sind, dass er diesen Takt benutzt. Und wenn sie so gesetzt sind, dann wird das Target nur laufen, solange der Debugger angeschlossen ist... Eben deshalb glaube ich das nicht. Es ergibt praktisch keinerlei Sinn.
Hi >Außerdem haben wir die Platine >XplainedMini(http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega328P-Xplained-Mini-UG-DS50002659B.pdf) >auf die Oszilator-Pins (PB6,PB7) geprüft. Was hat der ATMega328PB mit dem Controller auf dem XPLAIN-Board zu tun? MfG Spess
Philipp K. schrieb: > Ich habe mir bei Freunden ein Multimeter besorgt und den Ruhezustand von > RX TX am MC gemessen. U(RX)=0,14V, U(TX)=0,01V. Tx müsste im Ruhezustand HIGH Pegel (5V) haben. Ein deutliches Zeichen dafür, dass entweder dein Programm den Pin nicht korrekt initialisiert hat oder dass der Pin kaputt ist. Eingänge (Rx) haben keine definierten Pegel, solange keine Signalquelle angeschlossen ist. Deine gemessenen 0,14V sind daher plausibel aber auch wenig aussagekräftig.
c-hater schrieb: > Philipp K. schrieb: > >> Der User-Guide besagt, dass >> eine 16MHz-Clock des Debuggers an den Clockinput-Pin des MC >> angeschlossen ist. > > Selbst wenn das tatsächlich so wäre (was ich nicht glaube): Das > interessiert allerdings den µc kein bissel, jedenfalls solange nicht > auch die Fuses so gesetzt sind, dass er diesen Takt benutzt. Und wenn > sie so gesetzt sind, dann wird das Target nur laufen, solange der > Debugger angeschlossen ist... > > Eben deshalb glaube ich das nicht. Es ergibt praktisch keinerlei Sinn. Soweit ich den User-Guide richtig verstanden habe, funtioniert der Debugger nur, wenn die mEDBG-Frequenz und die F_CPU gleich sind. Die Frequenz des Debuggers liegt bei mir wegen der Schaltung eines kleinen Widerstandes nahe dem Anschluss Pin für die externe Clock bei F_Debugger=16MHz. Soweit ich das richtig verstanden habe, müssen für einen funktionierenden Debugger dessen Clock (die offenbar auf der Platine angebaut ist) und die F_CPU gleich groß sein. Mein Debugger arbeitet, also muss meine F_CPU=16MHz groß sein (ein abschließender Beweis für mich). Ansonsten ja, der Mikrokontroller arbeitet auch ohne aktiven Debugger die geladenen Programme ab.
Angehängte Dateien:
-
Platine_vorne.jpg
240 KB -
Platine_hinten.jpg
230 KB
Wolfgang schrieb: > Philipp K. schrieb: >> Er meinte, er hätte die Standardversion gekauft. > Was auch immer auf der Standardversion drauf ist... > Auf einem Photo von der µC-Platine könnte man nachgucken, ob ein > Quarz/Resonator oder gar nichts an den Oszillator-Pins des µCs hängt. Anbei zwei Fotos von der Vorder- und Rückseite der Platine. Im Vordergrund ist immer die Stelle, wo nach Angaben des Datenplattes für die Platine der PB7 (XTAL2) sein sollte. Dieser liegt offenbar unter dem Taster. Auf PB6 sollte XTAL1 liegen, diesen Pin habe ich aber bei besten Willen nicht finden können.
Stefan ⛄ F. schrieb: > Philipp K. schrieb: >> Ich habe mir bei Freunden ein Multimeter besorgt und den Ruhezustand von >> RX TX am MC gemessen. U(RX)=0,14V, U(TX)=0,01V. > > Tx müsste im Ruhezustand HIGH Pegel (5V) haben. Ein deutliches Zeichen > dafür, dass entweder dein Programm den Pin nicht korrekt initialisiert > hat oder dass der Pin kaputt ist. > > Eingänge (Rx) haben keine definierten Pegel, solange keine Signalquelle > angeschlossen ist. Deine gemessenen 0,14V sind daher plausibel aber auch > wenig aussagekräftig. Da ist Dir ein Fehler an meinem Messobjekt aufgefallen. Ich habe vergessen den Transmitter anzuschalten, habe einfach das Ausgangsprogramm (habe das UCSR0C- Register mit UCSZ00 verbessert) auf den MC geladen. Die Messung des TX habe ich mit Hilfe einer Diode auf einem Steckbrett nachgeholt: die LED leuchtet, der Ruhezustand des TX ist U=HIGH.
spess53 schrieb: > Hi > >>Außerdem haben wir die Platine >>XplainedMini(http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega328P-Xplained-Mini-UG-DS50002659B.pdf) >>auf die Oszilator-Pins (PB6,PB7) geprüft. > > Was hat der ATMega328PB mit dem Controller auf dem XPLAIN-Board zu tun? > > MfG Spess Hallo, die Beziehung von PB6 und PB7 ist, dass man über diese die Quarzoszillatoren anschließen kann, falls man sich über die Fusebits aus dem MC ausgeschlossen hat. So hat es mir z.B. Stefan empfohlen, nachdem ich versucht habe, den Fuse CKDIV8 zu ändern. Ansonsten hat Peter Z. gerade einen sehr detallierten Plan von der Beziehung ATmega328PB und Xplainedmini in den Chat gegeben. Mfg Philipp
Stefan ⛄ F. schrieb: > Eingänge (Rx) haben keine definierten Pegel, solange keine Signalquelle > angeschlossen ist. Deine gemessenen 0,14V sind daher plausibel aber auch > wenig aussagekräftig. Nach Aufbau sollte da der TX vom USB-Wandler dran hängen
Philipp K. schrieb: > Anbei zwei Fotos von der Vorder- und Rückseite der Platine. Die Platine gefällt mir, so hätten sie man die Arduino Boards gestalten sollen.
Wolfgang schrieb: > Nach Aufbau sollte da der TX vom USB-Wandler dran hängen Wenn das denn der Fall wäre, müsste der Ruhepegel ungefähr 5V betragen. Da er aber nur ein paar mV gemessen hat, muss wohl die Verbindung fehlen, kaputt sein oder der USB-UART Adapter ist kaputt.
Stefan ⛄ F. schrieb: > Wenn das denn der Fall wäre, müsste der Ruhepegel ungefähr 5V betragen. Oder er beträgt 0V, weil der USB-RS232-Wandler -3..12V liefert, die durch die Eingangsschutzdioden des ATmega auf 0V geklemmt werden. Wenn man den USB-RS232-Wandler vom ATmega abzieht, müsste der Ruhepegel der TX-Leitung vom PC irgendetwas negatives liefern.
p.s. ... oder der USB-RS232 Wandler spart bei der negativen Spannung und liefert tatsächlich 0V. Kaputt sein wird das Ding nicht, sonst würden Daten kaum reproduzierbar übertragen werden.
Guten Abend, Danke nochmal für die vielen hilf- und lehrreichen Kommentare hier. ich habe mir heute als TTL-Wandler das Modell MAX3232 gekauft und diesen zwischen das RS232-Kabel und den UART angeschlossen. Die Übertragung ist geglückt. Anmerkung zum MAX3232: zuerst die Versorgungsspannung vom 3.3V-5.0V anlegen und erst dann das RS232-Kabel mit seinen +-12V anschließen. Schließt man das RS232-Kabel zuerst an, brennt der MAX3232 wegen der hohen Spannung durch und ist unbrauchbar. Wegen diesem Fehler ist einer der beiden MAX3232 bei mir draufgegangen. Mit freundlichen Grüßen Philipp
Philipp K. schrieb: > Guten Abend, > > Danke nochmal für die vielen hilf- und lehrreichen Kommentare hier. > ich habe mir heute als TTL-Wandler das Modell MAX3232 gekauft und diesen > zwischen das RS232-Kabel und den UART angeschlossen. Die Übertragung ist > geglückt. > Anmerkung zum MAX3232: zuerst die Versorgungsspannung vom 3.3V-5.0V > anlegen und erst dann das RS232-Kabel mit seinen +-12V anschließen. > Schließt man das RS232-Kabel zuerst an, brennt der MAX3232 wegen der > hohen Spannung durch und ist unbrauchbar. Wegen diesem Fehler ist einer > der beiden MAX3232 bei mir draufgegangen. > > Mit freundlichen Grüßen > > Philipp Da stimmt wahrscheinlich mehr nicht. Normale RS232 Transceiver sind so konstruiert im ausgeschalteten Zustand mit einem aktiven angeschlossenen RS232 Gerät aushalten zu können. Vielleicht besteht zwischen dem PC und dem Netzteil auf der uC Seite ein unzulässiger Fehlerstrom wodurch dann unzulässige Spannungsdifferenzen zwischen PC Masse und uC Masse verursacht werden die dann die zulässigen Maximalwerte des MAX3232 übersteigen. Miss zur Vorsicht mit einem DMM in AC und DC Bereich ob im abgesteckten Zustand zwischen PC und uC Stromversorgung Masse eine messbare Spannung festzustellen ist. In meiner jahrzehntelangen Praxis ist mir ein solcher Fall noch nie passiert. Deshalb ist es wichtig zuerst die plausiblen Ursachen zu eliminieren.
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.