Hallo Profis ! Ich bin µC-Anfänger und beschäftige mich gerade mit UART. Meine Frage: Der µc(Atmega16) ist via max232 an der COM - Schnittstelle vom Notebook angeschlossen. Wenn ich versuche, ein einzelnes Zeichen vom Notebook (via Hterm) an den µC zu senden, so reagiert dieser mit dem oben angehängten Testcode nicht wie gewünscht (die LED am PORT A geht nicht an). Versuche ich ein Zeichen vom µC an das Notebook zu senden, so kommen teilweise nicht die gewünschten sondern komische Zeichen an. Wo hat sich hier der Fehler eingeschlichen ? Danke mfg Claus
Claus **** schrieb: > Versuche ich ein Zeichen vom µC an das Notebook zu senden, so kommen > teilweise nicht die gewünschten sondern komische Zeichen an. Kümmere dich darum zuerst. Solange die Richtung µC->PC nicht sauber funktioniert, ist irgendwo der Wurm drinn. Es hat keinen Sinn, sich mit dem Empfangen zu beschäftigen, solange dieser Wurm nicht dingfest gemacht wurde. Die Richtung µC->PC ist viel leichter zu debuggen als die umgekehrte Richtung. Und wenn die Richtung µC->PC sauber funktioniert, kannst du die Hardware als Fehlerursache weitgehend ausschliessen. Im Moment kannst du gar nichts ausschliessen. Was heist also "teilweise"?
Wo hast Du denn den Code her? So wie er aussieht sollte er nicht kompilieren.
>so reagiert dieser mit dem oben >angehängten Testcode nicht wie gewünscht Ist ja auch kein Wunder wenn man alle Funktionskörper in main() reinpackt. Compiliert das wirklich so? Eine C Datei hat die Endung .c und nicht .txt
poste mal bitte den kompletten code also copy&paste ausm AVR studio oder dem editor die funktionen haben nix in einer main zu suchen funk_1 { } funk_1 { } funk_1 { } main { while(1) { loop } } dann setzt enablest du zwar den UART empfänger .. aber das wars danna uchschon du musst den UBRR setzen und das format festlegen vieleicht hier nochmal anfangn : http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Der_UART dort steht alles was man für uart brauch
Angehängte Dateien:
-
Unbenannt.png
1 KB
Hallo,
Als Anhang habe ich das Empfangene vom Pc mitgesendet. (µP->PC)
hier nun der Code zum Senden den ich verwende (vom Tutorial):
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit
4000000"
#define F_CPU 4000000UL // Systemtakt in Hz - Definition als unsigned
long beachten >> Ohne ergeben Fehler in der Berechnung
#endif
#define BAUD 9600UL // Baudrate
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 =
kein Fehler.
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu
hoch!
#endif
#include <inttypes.h>
#include <avr/io.h>
#include <stdint.h>
int main(void)
{
UCSRB |= (1<<TXEN); // UART TX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1
UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
//****************************************
uint8_t i;
for(i=1;i<5;i++){
while (!(UCSRA & (1<<UDRE)))//warten bis senden möglich
{
}
UDR = 'x';
}
//main
}
mfg claus
^^hauptsächlich vom Tutorial, den unteren Teil habe ich selber zusammen "gebastelt" ( -> meine ersten Gehversuche)
holger schrieb:
> in main() reinpackt. Compiliert das wirklich so?
Mit dem gcc schon.
Der hat eine Erweiterung: lokale Funktionen
Hallo, sieht nach falscher Baudrate aus. Dein Mega16 läuft auch wirklich mit einem 4MHz Quarz und nicht etwa mit dem internen RC-Oszillator? Der ist üblicherweise nicht genau genug. Gruß aus Berlin Michael
holger schrieb: >>so reagiert dieser mit dem oben >>angehängten Testcode nicht wie gewünscht > > Ist ja auch kein Wunder wenn man alle Funktionskörper > in main() reinpackt. Compiliert das wirklich so? > > Eine C Datei hat die Endung .c und nicht .txt ich habe den Code in eine .txt kopiert, der von der .c ist identisch
Zum Bild. Du schickst 5 Bytes und dein PC denkt er hätte 8 Bytes empfangen. Da stimmt was mit deiner Baudrate nicht.
Claus P. schrieb:
> ich habe den Code in eine .txt kopiert, der von der .c ist identisch
Lass in Zukunft den Quatsch.
Wenn du einen Anhang machst, dann häng das c File an.
Ist für dich weniger Arbeit und die Forensoftware bereitet ein C-File
als Anhang durch Syntax-Highlighting auf, was auch für uns angenehmer zu
lesen ist.
*.txt -> Bääääh
*.c -> Win-Win Situation
Karl heinz Buchegger schrieb: > Zum Bild. > > Du schickst 5 Bytes und dein PC denkt er hätte 8 Bytes empfangen. > Da stimmt was mit deiner Baudrate nicht. ich verwende derzeit diese Schaltung: http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART Kann der Fehler auch durch nicht genau Elkos auftauchen ? mfg
>ich verwende derzeit diese Schaltung: Das ist erstmal uninteressant. Uns interessiert, wie Du den Takt erzeugst bzw. ob Du den internen RC-Oszillator verwendest. >Kann der Fehler auch durch nicht genau Elkos auftauchen ? Nicht diese Elkos in diesem Zusammenhang.
Was benutzt Du zum compilieren und zum flashen? AVR-Studio? Zeig mal die Einstellungen der Fuse-Bits.
Angehängte Dateien:
-
fuses.png
13 KB
Ahem schrieb: > Was benutzt Du zum compilieren und zum flashen? > AVR-Studio? > Zeig mal die Einstellungen der Fuse-Bits. Ich verwende AVR-Studio mit AVR-GCC . Zum Flashen verwende ich das Gerät "JTAG ICE". Der Atmega 16 arbeitet mit dem internen RC-Oszillator
Angehängte Dateien:
-
fuses_online.JPG
51 KB
Claus P. schrieb: > Ahem schrieb: >> Was benutzt Du zum compilieren und zum flashen? >> AVR-Studio? >> Zeig mal die Einstellungen der Fuse-Bits. > > Ich verwende AVR-Studio mit AVR-GCC . > Zum Flashen verwende ich das Gerät "JTAG ICE". > > Der Atmega 16 arbeitet mit dem internen RC-Oszillator sry, jetzt ist es das richtige Bild
also wenn da steht "Ext. Clock", dann ist das weder RC-Oszi noch ext. Quarz sondern du müsstest einen Takt einspeisen sonst läuft er überhaut nicht. Sascha
Jau. Mein Vorredner hat den Finger schon in die Wunde gelegt. Komisch ist aber doch, das überhaupt was rausgekommen ist. Entweder Du bastelst einen externen Oszillator ran oder einen Quarz und zwei 22pF Kondensatoren. Guck im Datenblatt wie das geht. Im zweiten Fall musst Du noch die Fuse ändern. Was hast Du denn für eine Platine? Oder Breadboard oder was?
Hallo, solche Anzeigen bekommt man vom AVR-Studio gern, wenn der ISP-Takt sehr dicht an CPU-Clock/4 ist. Also z.B. neuer AVR mit 1MHz Takt und 250kHz ISP-Clock. Ist leider auch eine sehr gute Gelegenheit, die Fuses richtig zu zerlegen. Fällt allerdings sofort auf, weil die Device-Signatur nicht zuverlässig lesen kann. ISP-Clock auf die nächste Einstellung unter 200kHz (beim Dragon 125kHz, beim STK500 war es was um 115kHz. Im Main-Reiter ein paarmal Read Signature, es muß IMMER die richtige gelesen werden. Dann kann man nach den Fuses usw. schauen. Die Fuses sind nie alle 0xFF oder 0x00, da hat er Schrott gelesen! Wenn man dann schreibt, hat man große Chancen, einen AVR zu haben, der nach HV-Programming schreit... Gruß aus Berlin Michael
Ahem schrieb: > Jau. Mein Vorredner hat den Finger schon in die Wunde gelegt. > Komisch ist aber doch, das überhaupt was rausgekommen ist. > > Entweder Du bastelst einen externen Oszillator ran oder einen Quarz und > zwei 22pF Kondensatoren. Guck im Datenblatt wie das geht. > Im zweiten Fall musst Du noch die Fuse ändern. > Was hast Du denn für eine Platine? Oder Breadboard oder was? ^^Ich verwende ein Steckbrett von Conrad, dann werde ich die zweite Möglichkeit wählen und mir einen Quarz mit den Kondensatoren zulegen inzwischen vielen herzlichen Dank für Deine- Eure mithilfe mfg, Claus
Hallo, versuch mal, uns die tatsächlichen Fuse-Einstellungen zu zeigen, dann sehen wir weiter. Du wirst zwar letztlich einen Quarz brauchen, auf dem Steckbrett erstmal rumzuspielen gaht aber durchaus auch so. Auch mit dem UART. Gruß aus Berlin Michael
Angehängte Dateien:
-
error.png
23 KB
Michael U. schrieb: > Hallo, > > versuch mal, uns die tatsächlichen Fuse-Einstellungen zu zeigen, dann > sehen wir weiter. > Du wirst zwar letztlich einen Quarz brauchen, auf dem Steckbrett erstmal > rumzuspielen gaht aber durchaus auch so. Auch mit dem UART. > > Gruß aus Berlin > Michael ich habe jetzt probiert die Fuses neu zu lesen, jedoch erhalte ich immer die gleiche Ausgabe wie beim Bild, dass ich euch geschickt habe. Zudem kommen derzeit immer komische Fehlermeldungen, wenn ich den Code ausführen will (siehe Anhang) Gruß Claus
Hallo, gut, da muß mal jemand ran, der ein JTAG benutzt um zu sagen, was da noch zu retten ist. Kommt JTAG an einen AVR ran, der laut Fuse ja ohne Takt ist? Gibt es da sinnvolle Fehlermeldungen oder tut der nur so als ob? Die Meldungen sind bei den Fuseeinstellungen logisch. Wenn die Fuses wirklich so stehen, würde ja ein externer Takt an XTAL1 erstmal dafür sorgen, daß man mit dem Mega16 überhaupt wieder sinnvoll reden kann. Mal als dumme Frage meinerseits (STK200 - Ponyprognutzer, jetzt Dragon(nur ISP genutzt, STK500): warum gibt viel Geld für ein JTAG-ICE aus, wenn man mit mit µC anfängt (geht nicht gegen Dich Claus P., interessiert mich wirklich)? Man ist auf AVR mit JTAG angewiesen, belegt sich Portpins, die dann fehlen. Warum nicht ein normaler ISP-Programmer mit USB? Gruß aus Berlin Michael
Michael U. schrieb: > Hallo, > > gut, da muß mal jemand ran, der ein JTAG benutzt um zu sagen, was da > noch zu retten ist. > > Kommt JTAG an einen AVR ran, der laut Fuse ja ohne Takt ist? > Gibt es da sinnvolle Fehlermeldungen oder tut der nur so als ob? > > Die Meldungen sind bei den Fuseeinstellungen logisch. > > Wenn die Fuses wirklich so stehen, würde ja ein externer Takt an XTAL1 > erstmal dafür sorgen, daß man mit dem Mega16 überhaupt wieder sinnvoll > reden kann. > > Mal als dumme Frage meinerseits (STK200 - Ponyprognutzer, jetzt > Dragon(nur ISP genutzt, STK500): warum gibt viel Geld für ein JTAG-ICE > aus, wenn man mit mit µC anfängt (geht nicht gegen Dich Claus P., > interessiert mich wirklich)? > Man ist auf AVR mit JTAG angewiesen, belegt sich Portpins, die dann > fehlen. > > Warum nicht ein normaler ISP-Programmer mit USB? > > Gruß aus Berlin > Michael Hallo, hab jetzt mal alles neu gestartet, das Studio kommt zum JTAG, jedoch kann ich jetzt nicht einmal mehr eine LED einschalten, obwohl keine Fehlermeldungen auftauchen, nur Warnungen und das Programm lässt den Code auch starten, aber die LED geht trotzdem nicht an. Gruß Claus
Claus P. schrieb: > Michael U. schrieb: >> Hallo, >> >> gut, da muß mal jemand ran, der ein JTAG benutzt um zu sagen, was da >> noch zu retten ist. >> >> Kommt JTAG an einen AVR ran, der laut Fuse ja ohne Takt ist? >> Gibt es da sinnvolle Fehlermeldungen oder tut der nur so als ob? >> >> Die Meldungen sind bei den Fuseeinstellungen logisch. >> >> Wenn die Fuses wirklich so stehen, würde ja ein externer Takt an XTAL1 >> erstmal dafür sorgen, daß man mit dem Mega16 überhaupt wieder sinnvoll >> reden kann. >> >> Mal als dumme Frage meinerseits (STK200 - Ponyprognutzer, jetzt >> Dragon(nur ISP genutzt, STK500): warum gibt viel Geld für ein JTAG-ICE >> aus, wenn man mit mit µC anfängt (geht nicht gegen Dich Claus P., >> interessiert mich wirklich)? >> Man ist auf AVR mit JTAG angewiesen, belegt sich Portpins, die dann >> fehlen. >> >> Warum nicht ein normaler ISP-Programmer mit USB? >> >> Gruß aus Berlin >> Michael > > Hallo, > > hab jetzt mal alles neu gestartet, das Studio kommt zum JTAG, jedoch > kann ich jetzt nicht einmal mehr eine LED einschalten, obwohl keine > Fehlermeldungen auftauchen, nur Warnungen und das Programm lässt den > Code auch starten, aber die LED geht trotzdem nicht an. > > Gruß > Claus PS: Den JTAG gab es bei unserer alten Schule zum Selberbauen. Das Programm dafür wurde von einem ehemaligen Lehrer programmiert. Und somit hat er letzendlich ca. 15€ gekostet. Bis jetzt gab es mit dem JTAG keine Probleme. Da ich ein blutiger Anfänger bin, wäre ich auch um Ratschläge, Tutorials usw. die mir den Anfang erleichtern sehr dankbar. Sollte ich besser auf eine andere Harware umsteigen ?
Also, jetzt muss ich doch mal schlucken. Gulp. Erst hast Du ein JTAG ICE und dann so ein Selbstbau von Deinem Lehrer. Das macht es uns aus zweierlei Gründen nich einfacher. Zum einen hätten wir das gerne vorher gewusst. Zum anderen sind alle Leute hier, die Deinen Lehrer kennen, gerade ohne Internet im Amazonas-Dschungel im Urlaub. Trotzdem erstmal ganz ruhig. >Sollte ich besser auf eine andere Harware umsteigen ? Nein. Erstmal nicht. Und vor allem nicht jetzt wieder die Software wechseln. Nimm den Code von 09.07.2009 17:31 und gut. >hab jetzt mal alles neu gestartet Das war eine gute Idee. Soll man aber auch nicht zur Gewohnheit werden lassen. >nur Warnungen "nur" ist gut. Aber das wäre doch vielleicht hilfreich gewesen. Was meinst Du wozu Warnungen da sind? Was im Moment eine Frage aufwirft ist, wie Du überhaupt die Fuses auslesen konntest. Anscheinend reicht ein JTAG dafür. Kann das jemand bestätigen. Ansonsten müsste Dein Screenshot von 09.07.2009 18:43 nämlich (ohne Deine Schuld) falsch sein. Wenn ich das zuletzt richtig gesehen habe ist die BOOTRST-Fuse verhagelt, da er irgendwie in den Bootloader will. Du solltest erstmal wieder die Fuses so hinbiegen, das der Normalzustand erreicht ist. Das kannst Du im Datenblatt nachschauen. Wenn ich das recht sehe, dann muss hier jemand ran, der sich mit JTAG-Debugging besser auskennt. Versuch dann mal das Programm zu kompilieren und zu flashen. Gib uns alle Meldung und auch Warnungen und Fehler an. Dann sehen wir weiter.
Ahem schrieb: > Also, jetzt muss ich doch mal schlucken. Gulp. > > Erst hast Du ein JTAG ICE und dann so ein Selbstbau von Deinem Lehrer. > Das macht es uns aus zweierlei Gründen nich einfacher. Zum einen hätten > wir das gerne vorher gewusst. Zum anderen sind alle Leute hier, die > Deinen Lehrer kennen, gerade ohne Internet im Amazonas-Dschungel im > Urlaub. > > Trotzdem erstmal ganz ruhig. > >>Sollte ich besser auf eine andere Harware umsteigen ? > Nein. Erstmal nicht. > Und vor allem nicht jetzt wieder die Software wechseln. > Nimm den Code von 09.07.2009 17:31 und gut. > >>hab jetzt mal alles neu gestartet > Das war eine gute Idee. Soll man aber auch nicht zur Gewohnheit werden > lassen. > >>nur Warnungen > "nur" ist gut. Aber das wäre doch vielleicht hilfreich gewesen. Was > meinst Du wozu Warnungen da sind? > > Was im Moment eine Frage aufwirft ist, wie Du überhaupt die Fuses > auslesen konntest. Anscheinend reicht ein JTAG dafür. Kann das jemand > bestätigen. > Ansonsten müsste Dein Screenshot von 09.07.2009 18:43 nämlich (ohne > Deine Schuld) falsch sein. > > Wenn ich das zuletzt richtig gesehen habe ist die BOOTRST-Fuse > verhagelt, da er irgendwie in den Bootloader will. > > Du solltest erstmal wieder die Fuses so hinbiegen, das der Normalzustand > erreicht ist. Das kannst Du im Datenblatt nachschauen. > > Wenn ich das recht sehe, dann muss hier jemand ran, der sich mit > JTAG-Debugging besser auskennt. > > Versuch dann mal das Programm zu kompilieren und zu flashen. > Gib uns alle Meldung und auch Warnungen und Fehler an. > > Dann sehen wir weiter. Hallo, ENDLICH, habe die Fuses neu gesetzt und nun funktioniert das Senden vom µP -> PC ohne Fehler, die Zeichen kommen richtig an. Nun meine nächste Hürde: UART PC->µP Muss dabei etwas bestimmtes beachtet werden ? Gruß Claus
mit jtag kann man teils verfuste AVRs auch wiederbeleben ^^ also auch wenn zB ein falscher quarz gewählt wurde das ist das entspannte daran ich glaube der TE sollte man schaltplan + firmware des jtag clones mal hier reinhauen ,oder ? ^^ beim uart empfang ist das genauso (1<<RXEN) |(1<<TXEN) so sind beide an du must jetz natürlich sobald daten ankommen das UDR register auslesen dafür eignet sich gut der interrupt zum testen kann man das aber in der main mal erledigen wenn später andere dinge ausgeführt werden ist vlt keine zeit in der main die daten umzuschaufeln wenn du jetz bei eingeschaltetem empfänger anstatt zu schreiben einfach das UDR ausließt sollte es schon funktionieren
Hi ich liebe C.... Nun gut, is nich meine Welt, trotzdem versuch ich mal ein wenig beizutragen. Schließlich hab ich auch mal angefangen und so meine Probleme mit RS 232 gehabt. Du solltest dir einen Empfangsbereich, einen Ringpuffer anlegen. 1.Byte hat die Basisadresse. Außerdem brauchst du einen Zähler für Lese- und Schreibadresse. Diese Werte sind zuerst gleich. Kommt ein Byte, ( Interrupt ! ) schreibst du dies auf die aktuelle Adresse (Basisadresse + Bytezähler schreiben) und setzt den Schreibzähler eins hoch. Hast du einen Puffer von 10 Bytes, prüfst du den Zähler und setzt in Fall der erreichten Grenze alles wieder auf den Anfang. Im Programm prüfst du Schreibzähler mit Lesezähler. Sind sie gleich, is nix da. Bei Ungleichheit Daten aus Puffer holen und in die vorgesehenen Bereiche eintragen. Danach gleiche vorgehensweise wie mit Schreibzähler. Wenn dein Datentransfer Ok ist, kannst du vielleicht ein nützliches Programm gebrauchen, was dir die Variablenwerte zur Laufzeit deines Controllers anzeigt. Ich hab mir dafür eines in Delphi geschrieben, vielleicht interessierts. Es ist gepackt, weil auch eine Dokumentation dabei ist. Viel Spas damit. Ich denke, die Assemblerroutinen wirst du entweder einbinden oder nach C umsetzen können. Wär nett, wenn ich mal ne Info bekomme, ob das Tool verständlich ist. Ich hab's programmiert, deshalb ist's für mich klar, doch ich weiß nicht, ob andere damit klarkommen. Gruß oldmax
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.