Hallo, ich habe ein Empfangsproblem mit Uart. Das ganze war mal wesentlich nuetzlicher, aber zur Problemfindung habe ich es inzwischen soweit reduziert. Ich empfange mit einem AtMega32 auf 16MHz Daten ueber RS232 (mit einem MAX232 gewandelt) und gebe ein paar Kontrolldaten (genauer: MCUCSR bei einem Reset) per seriell aus. Die Daten vom AtMega kommen sauber beim Rechner an. Ob die Daten vom Rechner sauber beim Uart angekommen, ist im Moment gar nicht so wichtig, denn sobald ich sende, springt der AtMega sporadisch teilweise mitten in den Resethandler. Als Resetgrund ist keiner zu finden (MCUCSR = 0), Spannung ist stabil, Resetpin ist inzwischen auf VCC gezogen und gegen GND stabilisiert. Inzwischzen ist auch nicht mal mehr der RXC-Interrupt an, aber die Sprungfehler treten trotzdem auf. Sobald ich aber den UART-Empfaenger ausschalte, tritt das Problem nicht mehr auf. Vllt hat einer von euch Muße, sich den Code mal anzugucken und mir zu sagen, warum die Sprungfehler auftreten. Wenn Unklarheiten bestehen, bitte Fragen, ich beantworte alles ;) Gruss Surma
> LDI tmp, (1<<TXEN)|(1<<RXEN);|(1<<RXCIE)
Das mit dem Semikolon geht so durch den Assembler?
Naja, wenn du keinen RXC Handler hast, dann setz RXCIE auch nicht;)
Die Auskommentierten Zeilen sind drin, damit ihr wisst, was ich probiert habe. Haette ich vllt vorher sagen sollen. Das ist ja eigentlich das ueberraschende. Obwohl der Interrupt ausgeschaltet ist, und es keine Interruptroutine mehr gibt (ist ja auch auskommentiert), springt der Atmega trotzdem mitten in den Resethandler (oder eben auch an Anfang). Ich seh den Elefanten im Raum nicht, glaub ich
gewöhn dir gleich folgendes an: zu jedem programm gehört eine vollständige interrupt-tabelle. unbenutzte interruptadressen bekommen dort direkt einen RETI, dann gibts keine probleme falls so ein interrupt einmal unbeabsichtigt ausgelöst wird. diese tabelle wegzulassen macht nur sinn wenn das programm keine interrupts benutzt (CLI und fertig) oder der speicher so knapp ist, daß man nur dort die fehlenden drei words abknipsen kann. wenn du fertig bist damit probier nochmal und wenn nicht geht zeige nochmal.
>Obwohl der Interrupt >ausgeschaltet ist, Ist er nicht. > und es keine Interruptroutine mehr gibt (ist ja auch >auskommentiert), Meinst du das hier? ;rxc_handler: ; RETI Also da solltest du wenigstens noch UDR lesen. Sonst wird der Interrupt endlos ausgelöst.
> LDI tmp, (1<<TXEN)|(1<<RXEN) ;|(1<<RXCIE) <--- !!! Der Receiver ist an, der Interrupt jedoch nicht. Somit wird kein Interrupt fuer ein emfpangenes Byte ausgeloest und die Daten in UDR einfach ueberschrieben (laut Datenblatt des M32) > gewöhn dir gleich folgendes an: zu jedem programm gehört eine vollständige interrupt-tabelle. Das klingt in der Tat recht vernuenftig. Ich habe jetzt jeden der restlichen Vektoren mit RETI gefuellt - das Problem bleibt leider bestehen.
da fehlt am anfang schon mal sowas wie ein ldi temp,0 - man sollte nicht davon ausgehen, daß R16 beim µC start 0 ist. LDI tmp,HIGH(ramend) ; Setting up Stack OUT SPH,tmp LDI tmp,LOW(ramend) OUT SPL,tmp so kenne ich das... wieso aktvierst du bei "hang" die interrupts wieder? und wie schaut die ausgabe von deinem programm auf dem PC aus, also was kommt korrekt an und was nicht?
Ich hoffe du brennst auch die richtige HEX Datei;) So weit ich weiß schaltet AVRStudio diese nicht automatisch für dich auf ein neues Projekt um.
>So weit ich weiß schaltet AVRStudio diese nicht automatisch für dich auf ein neues Projekt um. Ich arbeite auf Linux mit AVRA als Assembler und avrdude als "Brenner"(?). Ich habe schon sichergestellt, das die richtige Datei gebrannt wird. > da fehlt am anfang schon mal sowas wie ein ldi temp,0 Okay, das wusste ich nicht, hilft dem Problem aber auch nicht weiter, da die Daten die ankommen, ja gar nicht von Relevanz sind. > wieso aktvierst du bei "hang" die interrupts wieder? Das ist an sich ein ueberbleibsel von einer vorhergegangenen Version. Sollte aber nicht wirklich Schaden, oder? Ich hab jetzt die beiden Sachen natuerlich trotzdem behoben, das Problem bleibt bestehen. Zu dem, was ich Empfange: Ich schicke dem M32 absteigend die Werte von 255 bis 0, immer und immer wieder. Zwischen jedem Byte ist eine Wartezeit von 20us. Benutzt wurde der angehaengte, korrigierte Code. Der M32 sendet folgendes (hexadezimal, bei 9600 8N1): > 01 00 FF ; Power-On reset, MCUCSR geloescht, Ende des RST-Handlers erreicht > 02 00 FF ; Ich hab den Resetknopf gedrueckt... > FF FF 00 00 FF FF 00 00 FF FF > 00 00 FF FF 00 00 FF Da sieht man schon, das 2x hintereinander FF gesendet wird, was heisst, dass 2x mitten in die RST-ISR gesprungen wird. Danach auch einige male an den Anfang der selbigen.
das könnte auch eine fehlinterpretation des PC-uart auf irgendwelche wirren signale sein. wirklich verstehen kann ich es im moment nicht, aber wenn du 1-2 tage wartest hab ich ein ähnliches testprogramm für einen mega32.
Fuer ein Testprogramm, dass nicht aus meiner Feder stammt, waere ich natuerlich sehr dankbar. Ich haenge seit 3 Wochen an diesem Problem (wobei ich erst heute den genauen Fehler herausdestilliert habe). Ich habe uebrigens statt FF auch schon 0xAA als Kontrollwert rausgeschrieben, um eben genau zufaellige Dateninterpretationen auszuschliessen. Dies funktioniert genau so (oder eben nicht...) Danke fuer die Muehe
Hi! >SBI UCSRA, TXC Tut das Not? >LDI tmp,HIGH(MAXRAM-1) Was bitte ist MAXRAM? Ist das in deiner "m32def.inc" so drinn? Lasse mal das "sei" weg. Bekommst du dann immernoch Resets? Wenn ja, dann wohl von "Extern" oder µC def. Übrigens vor Datenausgabe sollte man testen obs Register frei ist, so in der Art "sbis UCSRA,UDRE" Viel Erfolg, Uwe
>Lasse mal das "sei" weg. Bekommst du dann immernoch Resets? Bringt leider nix. >Wenn ja, dann wohl von "Extern" oder µC def. Gegen Extern spricht doch eigentlich das ich keine Resets bekomme wenn RXEN aus ist. Außerdem ist der Reset pin auf VCC gezogen, und die Spannung hat keine nennenswerten Einbrüche. Oder überseh ich hier was? Was meinst du mit uC def??
> MAXRAM ist in den neueren Headerdateien von AVR das was > früher RAMEND war was war denn verkehrt an RAMEND? ich hasse es wenn solche vorgabewerte geändert werden! und wenns das gleiche ist, was soll dann das "maxram-1"? schaltung für meinen eigenen COM-test hab ich soweit fertig. mal schauen wann ich das programm dazu fertig bekomme.
> was war denn verkehrt an RAMEND? Keine Ahnung was daran falsch war - aber mein Kollege arbeitet mit avr Studio und hat beim installer die neuen Header mitbekommen - aus kompatibilkitaetsgruenden hab ich die neuen dann auch genommen. Das -1 ist wieder mal nur ein Versuch einen bloedfehler auszuschliessen. Hat eigentlich keinen anderen Effekt als Maxram (bzw RAMEND) ausßer das ich Platz verschwende ;) >schaltung für meinen eigenen COM-test hab ich soweit fertig. mal schauen wann ich das programm dazu fertig bekomme. Cool - ich freu mich drauf. Vielen Dank!
Hi >MAXRAM ist in den neueren Headerdateien von AVR das was früher RAMEND >war Also ich habe die letzte Version des AVR-Studios. Und da ist in keiner Inc-Datei ein 'MAXRAM' enthalten. MfG Spess
Wie dem auch sei - ich hab eben mal die beiden Headerdateien verglichen und beide definieren MAXRAM bzw. RAMEND bei 0x085f.
Hi! >>Lasse mal das "sei" weg. Bekommst du dann immernoch Resets? >Bringt leider nix. Was denn nun, hastes weggelassen und immernoch Reset? Weil, wenn Ja, erzeugt irgendwas Reset, aber es ist kein Int. Das Komische ist, mal kommt 00 00 dann FF FF. Das passt doch nicht. >.equ BAUD=103 ; 16MHz Bist du sicher das er mit 16 MHz rennt? Das RXEN kann eigentlich nichts auslösen, da nichts aktiviert(Int) Einen Max232 oder sowas haste aber dazwischen? nicht das die 9-12V aus der UART den µC Resetten. Ein UART Testprogr. könnte einfach so aussehen: .include "m32def.inc" .def tmp=r16 .equ BAUD=103 ; 16MHz ;.equ BAUD=95 ; 14.7456MHz .cseg .org 0 RJMP rst_handler .org INT0addr RETI .org INT1addr RETI .org INT2addr RETI .org T2CMPaddr RETI .org T2OVFaddr RETI .org T1CAPaddr RETI .org T1CMPAaddr RETI .org T1CMPBaddr RETI .org T1OVFaddr RETI .org T0CMPaddr RETI .org T0OVFaddr RETI .org SPIaddr RETI .org URXCaddr RETI .org UDREaddr RETI .org UTXCaddr RETI .org ADCaddr RETI .org EERDYaddr RETI .org ACMPaddr RETI .org TWIaddr RETI .org SPMaddr RETI rst_handler: CLI LDI tmp, 0 OUT UBRRH, tmp ; Initialize UART LDI tmp, BAUD OUT UBRRL, tmp LDI tmp, (1<<TXEN|1<<RXEN) ;|(1<<RXCIE) OUT UCSRB, tmp LDI tmp, (1<<URSEL|1<<UCSZ1|1<<UCSZ0) OUT UCSRC, tmp IN tmp, MCUCSR ; What caused the reset? OUT UDR, tmp LDI tmp, 0x00 ; Set MCUCSR to zero OUT MCUCSR, tmp IN tmp, MCUCSR ; Has it been really set to zero? _loop1: sbis UCSRA,UDRE ; Wait until ready to send again RJMP _loop1 OUT UDR, tmp LDI tmp,HIGH(MAXRAM-1) ; Setting up Stack OUT SPH,tmp LDI tmp,LOW(MAXRAM-1) OUT SPL,tmp LDI tmp, 0xFF ; Port D as output (doesn't matter acutally) OUT DDRD, tmp OUT PORTD, tmp _loop2: sbis UCSRA,UDRE RJMP _loop2 OUT UDR, tmp hang: sbis UCSRA, RXC RJMP hang in temp,UDR _loop3: sbis UCSRA,UDRE RJMP _loop3 OUT UDR, tmp RJMP hang Das sollte MCUCSR ausgeben, das genullte MCUCSR, dein $FF und jedes empfangene Zeichen senden.(alles ohne Int.) Viel Erfolg, Uwe
er hat sowieso komische definitionen. seine ganzen .org ???adr zeilen erzeugen bei mir fehler.
>Was denn nun, hastes weggelassen und immernoch Reset? Ich habs rausgelassen und immer noch nen Reset >Bist du sicher das er mit 16 MHz rennt? Schon - ich hab nen Quarz dran und den Kerl entsprechend gefused. Kann ich das sonst noch irgendwie testen? >Einen Max232 oder sowas haste aber dazwischen? nicht das die 9-12V >aus der UART den µC Resetten. Ja Max232 ist angeschlossen. Schaltung ist wie in dem Turorial hier im Forum (UART - Tutorial) Danke für das Testprgramm! Habs gleich mal drauf gehauen. Allerdings bekomme ich überhaupt keine Ausgabe wenn ich die Zeilen > sbis UCSRA,UDRE drin lasse. Also auch nicht beim ersten Starten. Kommentiere ich die Zeilen aus sieht das Fehlerbild wieder genauso aus wie vorher. Sieht aus als hätt ich da schon beim senden Probleme - was zumindest die komischen FF FF erklaeren koennte - oder? Die FlowControl am Rechner ist aber aus. >er hat sowieso komische definitionen. seine ganzen .org ???adr zeilen >erzeugen bei mir fehler. Das haengt wieder mit den Headern zusammen - dummerweise. Die haben da auch die ganzen Interruptbezeichnungen geaendert. Ich schau mal das ich die anderen wieder besorge.
Hi >er hat sowieso komische definitionen. seine ganzen .org ???adr zeilen >erzeugen bei mir fehler. Sind eigentlich Definitionen aus der m32def.inc . Trotzdem ist mir schleierhaft wer diesen Schwachsinn empfiehlt. Genauso wie das temp-Geraffel. MfG Spess
okay stelle fest ich bin auch bescheuert... trotz messung mit dem oszi und probeweises vertauschen der TX/RX leitungen bekomme ich kein einziges zeichen zum PC rüber, nicht mal etwas wirres. schlicht und einfach gar nichts. keine ahnung, werds wohl mit einem anderen PC versuchen müssen, kann sein daß hyperterminal und XP mit der COM1 nicht so sonderlich gut funktioniert.
nachtrag: funzt jetzt. klein plan wieso oder wieso vorher nicht, geht sogar nach neustart des PC wieder. sogar mit 115k, maximum vom eingesetzten MAX232N. moving on...!
Btw.: Weil du grad von Hyperterminal sprichst. Weiß nicht ob ihr´s schon kennt aber am Windowsrechner benutz ich Realterm, das laesst deutlich mehr Einstellungen zu als das std. Hyperterminal, und zeigt vor allem an, an welchen Pins was anliegt.
so... DONE! das programm was dranhängt kann interruptgesteuerte UART kommunikation mit vollen 115kbaud (8N1). der µC flackert die ganze zeit mit einer LED in blau rum (irgendwas muß der ja machen), man kann blind irgendwelche strings eingeben die vom µC in einem buffer abgelegt werden (maximal 255 zeichen). die zeile wird mit enter abgeschlossen (ASCII-13), der µC reagiert darauf mit dem rücksenden der eingegeben zeichenkette und die LED wird kurz rot. danach wird der buffer gelöscht und man kann das ganze eine machen solange man spaß dran hat. die AVR initialisation kann sich jeder biegen wie er will, ich hab die jetzt nicht entfernt. die LED ist eine RGB LED mit gemeinsamer kathode, anoden liegen: rot-PB1, blau-PB2, grün-PB4. die gemeinsame kathode liegt an PB3 (OC0) um das ding später vielleicht noch per PWM dimmen zu können falls ich die timerprogrammierung irgendwann noch hinkriege. zu dem beschrienen fehler: ich hatte ähnliche probleme und crashes, das liegt irgendwie an der interrupttabelle. mit der verkrüppelten ist alles okay, alles mit RETIs gefüllt crasht. der UDRIE interrupt darf auch nur solange aktiviert sein, wie noch zeichen zu senden sind. wenn man ihn ständig aktiviert bekommt man ihn auch ständig reingewürgt - bremst den µC natürlich kräftig aus. ich hab den UDRIE trotzdem genommen weil ich mir davon maximale geschwindigkeit erhoffe. man kann ein neues zeichen in UDR bereitstellen während das vorhergehende noch gesendet wird und der UART kann sich das ohne verzögerung holen. die buffer sind da um z.b. kommandoeingaben entgegennehmen zu können, das ist aber noch nicht fertig. die eingaberoutine kann im moment nur alles ankommende in sich hineinsaugen, sie reagiert außer auf enter auf keinerlei steuerzeichen. erstmal alles nur soweit daß vielleicht das problem hier vom tisch ist.
Vielen Vielen Dank! Bin leider grad auf Arbeit und kanns nicht ausprobieren aber ich werde mich gleich heut nachmittag ransetzten und dann berichten obs geht, und sicher noch die eine oder andere Frage haben ;)
Da faellt mir ein. Ben, magst du mir noch mal deine beiden Fuse-Bytes dazugeben? Einfach, damit ich mal die genauen Unterschiede rausarbeiten kann.
an den fuses ist nichts besonderes dran. HF quarzoszillator+67ms+1K, JTAG abgeschaltet, BOD mit 4V aktiviert, bootblock und lockbits ungenutzt. auf keinen fall halt SPI abschalten oder den reset-pin deaktivieren, sonst brauchst du hinterher einen HV progger.
Hi! >Allerdings bekomme ich überhaupt keine >Ausgabe wenn ich die Zeilen >> sbis UCSRA,UDRE Dann stimmt irgendwas anderes nicht, du musst mindestens 1 Zeichen bekommen weil: : : OUT UCSRC, tmp IN tmp, MCUCSR ; What caused the reset? >>> OUT UDR, tmp ein Zeichen ausgeben muss, weil keine Abfrage da ist. Danach musst du unbedingt warten bis das Senderegister frei ist-> sbis UCSRA,UDRE macht genau dieses(soll es jedenfalls). Wenn UDRE nicht gesetzt ist, ist auch das Datenregister nicht frei! Du machst irgendwas anderes oder dein µC spinnt. Viel Erfolg,Uwe
@Ben So ich habe dein Programm ausgiebig getestet. Aber leider ist das Problem nicht vom Tisch. Dein Programm funktioniert bei mir genauso wie dus beschrieben hast, man kann strings eintippen und per Enter senden etc. alles schön unf auch ohne Resets. Aber sobald ich wirklich schnell sende, also nicht per Tastatureingabe sondern per Script, resetet sich der uC wieder. Wenn man länger eine Taste gedrückt hält bekommt man den Reset auch "hin" - aber nicht so sicher wie wenn man das ganze automatisch machen lässt. Ich habe mir ein kleines C Programm geschrieben das alle 500 us ein Zeichen rausschickt um das ganze zu testen. Ich hab in dein Programm folgenden kleinen Code in die Initialisierung reingebaut um mit dem Oszi (oder wahlweise LED) zu sehen wenn er den Reset durchführt.
1 | ldi r16,0xFF |
2 | out PORTC, r16 |
3 | |
4 | call delay100ms |
5 | call delay100ms |
6 | call delay100ms |
7 | call delay100ms |
8 | |
9 | ldi r16,0x00 |
10 | out PORTC, r16 |
Vielleicht kannst du ja bei dir mal schaun ob das auch passiert
(zumindest mit Taste gedrückt halten geht ja recht fix zu testen. Nach n
paar sekunden kommt der Reset da eigentlich recht zuverlaessig ;) )
@Uwe
>Du machst irgendwas anderes oder dein µC spinnt.
Ja das glaub ich schon lange ;) . Nur dumm das alle 6 die ich
ausprobiert haben spinnen.
Ich schau mir deine Variante morgen nochmal genau an irgendwas muss ich
da je verbaut haben...
urks dummer fehler :-/ ist mir beim testen nicht aufgefallen. das programm hatte keine deutliche reset-anzeige, habe nun einen LED-farbwechsel beim start eingebaut damit man einen unbeabsichtigten reset erkennt. fehler war einfach, bin in der RX ISR eine zeile verrutscht. :-(( ---[schnipp]--- lds r16,rx_bytes ;load number of bytes already in the buffer cpi r16,255 ;is the buffer already full? breq us_rxc_ex ;unfortunately yes! -> exit, received data is lost push r16 ---[schnapp]--- so gehört das hin. der fehler war daß das push vor dem sprung stand, was beim überlauf des buffers den stack durcheinanderwirft. der reti schießt das ding dann auf den mond. jetzt crasht jedenfalls nichts mehr, kann eine taste eine minute lang festhalten ohne daß sich das ding stören läßt. im anhang das korrigierte program, evtl. kann ein mod das fehlerhafte ein paar beiträge weiter oben dann löschen.
Danke fuer die Ueberarbeitung. ... ich wuerde ja gerne schreiben das es geht ... aber dem ist leider nicht so. Es ist wieder wie du beschrieben hast, und ich habe auch keine Abstuerze mehr wenn ich eine Taste gedrueckt halte, mit meinem Testprogramm bekomme ich aber immer noch resets der Uc. Ich hab das Testprogramm fuer Windows und Linux mal angehaengt einfache Konsolen exe mit 3 Parametern. Der erste ist der Com port, Der zweite die Zeit in us (bei Linux) und ms(bei Windows) die zwischen dem Senden der Zeichen vergehen soll. Der Dritte Parameter ist die Baudrate 115200 oder 9600. Bsp.: SendMassData_win COM1 10 9600 Gesendet werden dann in einer endlosschleife die Werte 255 bis 0 und dazwischen immer eine 0. mit 8N1 keine Flowcontrol. Interessant ist das bei deinem Programm meiner Meinung nach deutlich weniger Resets vorkommen als in meinem Testprogramm, und auch weniger als in deiner ersten Version. Desweiteren werden die Resets haufiger je kuerzer die Pause zwischen den gesendeten Bytes sind, ebenso bei einer hoeheren Baudrate. Jemand noch ne Idee woran das liegen kann?
hab dein proggy einfach mal gestartet. kann keinen reset feststellen, die LED flackert fleißig vor sich hin und der µC reagiert periodisch "sogar" auf den ASCII-13 mit dem zurückschicken der daten. die 10ms kommen mir aber mehr als 10ms vor... dein proggy erreicht keine 100 bytes/sec. und selbst das wäre auch wenig, bei 115 kbaud sollten mindestens 8kb/s drin sein.
Okay - Danke fuers testen! Ja sind etwas mehr als 10 ms. 1. weil in einem rutsch 2 Bytes rausgeschickt werden und nach jedem gewartet wird (0 + eigentliches Byte) und zweitens brauch ja auch die Routine n bisschen Zeit(Vor allem durch die Consolen Ausgabe...) Ich nehm halt die std C Sleep() routine. Wenns bei dir nicht resetet dann kanns ja nur noch meine Schaltung sein... ich werd mich mal dran machen nen Schaltplan zu zeichnen.
...anbei nochmal die Windowsvariante ohne Consolen Ausgabe - die sollte dann zumindest in der Nähe der angegebenen Sleep Zeit sein
negativ. verhält sich genauso wie das erste programm. auch ohne resets. her mit deiner schaltung.
Angehängte Dateien:
-
Schaltung01.png
2,8 KB
... so dann bin ich mal gespannt.. ich hoffe ich hab keine Fehler reingemalt dies gar nicht gibt..
Hi Bist du sicher, das Pin5 des Sub-D-Steckverbinders mit VCC verbunden ist? MfG Spess
doch hast du. pin5 am sub-d9 ist sicher nicht Vcc... der max232 muß auch richtig verschaltet sein sonst würde kein einziges zeichen durchgehen. ich würde eher auf sowas wie ein instabile stromversorgung oder so tippen. hast du den AVcc mit verschaltet?
Arg man sollte Schaltungen nicht schnell zeichnen... Stromversorgung ist die 5 V Leitung von nem Rechner Schaltnetzteil und nochmal mit nem 4700 uF Kondi dazwischen. Das "sollte" eigentlich Stabil sein. Was meinst du mit AVcc??
Hi
>Was meinst du mit AVcc??
Der ATMega hat zwei Versorgungsspannungsanschlüsse (VCC und AVCC). Beide
sollten angeschlossen und mit einem Kondensator versehen sein.
MfG Spess
das programm dudelt hier immer noch rum, ich bin inzwischen leicht genervt von dem blauen blinken neben dem pc-monitor aber habe noch immer keinen reset gesehen.
@Ben
Danke fuer den Langzeit test!!!
Ich seh schon - ich habs irgendwo verbockt. Ich muss nur noch finden
wo!!
> Beide sollten angeschlossen und mit einem Kondensator versehen sein.
Hatte ich nicht - hab ich jetzt. War aber leider nicht des Raetsels
Loesung.
hm kein plan... :-/ mach mal ein bild von deinem aufbau oder/und probier es mal mit einem externen netzteil. mein µC hier läuft in seiner späteren angedachten anwendung, versorgt mit einem 7805 aus einem kleinen 12V bleiakku.
Ich werd die Schaltung jetzt nochmal komplett neu aufbauen und mir doch
mal noch nen neuen Atmega besorgen, und dann werd ich mal n Foto von der
Schaltung hochladen.
Ich hoffe dann findet sich der Fehler.
> oder/und probier es mal mit einem externen netzteil.
Noch Externer als n Rechner Netzteil??
na ich meinte eine vom PC getrennte stromversorgung. ein labornetzteil oder sowas.
Achso! Ein Labornetzteil hab ich leider nicht. Aber an dem Rechnernetzteil hängt nur die Schaltung kein Rechner oder so. Ich habs ja auch vorher schon mit nem Standart 12 V Netzteil und nem 7805 er als Spannungsregler aufgebaut. Das Rechnernetzeil hatte ich eigentlich nur aufgabaut um eben Spannungsversorgungsprobleme auszuschließen. Was mir allerdings jetzt beim Nachmessen aufgefallen ist, ist das die Spannung mit ca 100Hz um 0,2 V schwankt, und zwar sobald ich den Atmega in die Schaltung stecke. (Sowohl beim 7805 als auch beim Rechnernetzteil) Egal wie dick die Kondis sind, die ich zum puffern dazwischen hänge. Ist das Normal?
Angehängte Dateien:
-
Schaltung_bild.JPG
3,6 MB
Hab die Schaltung mit nem neuen Atmega nochmal aufgebaut. Der Fehler besteht immer noch. Foto ist anbei.
3.6mb... glückwunsch, der dank der mods ist dir sicher...
> Was mir allerdings jetzt beim Nachmessen aufgefallen ist, ist das die
Spannung mit ca 100Hz um 0,2 V schwankt
das ist auf jeden fall doof.
Hi Mal so auf den ersten Blick: An die Stromversorgungsanschlüsse gehören 100nF Keramik-Cs, keine Elkos. Was macht der Widerstand in der VCC-Leitung? MfG Spess
> 100nF Keramik-Cs, keine Elkos.
meinst du an alle (also zwischen GND VCC der uCs)?
arg... ich sollte mich mal einloggen dann kann ich auch editieren... der Widerstand in VCC ist der Pullup, wenn ich da nen Taster anschließe. Hab ihn gleich drinnen gelassen - der sollte ja keinen schaden machen oder?
an beide pins Vcc und AVcc gehören keramik-abblock-Cs. 100nF an ARef gegen masse können auch nicht schaden.
Okay hab die Elkos gegen 100nF Kerkos ausgetauscht und noch einen an Aref gegen Masse gepackt. Fehler bleibt
ICH HABS... Ben hat mich mit dem Kondi gegen Aref drauf gebracht. Ein 100 nF Kondi gegen Masse an den RXC - dann ist Ruhe
Hi >ICH HABS... >Ben hat mich mit dem Kondi gegen Aref drauf gebracht. >Ein 100 nF Kondi gegen Masse an den RXC - dann ist Ruhe ?????? Womit ist Ruhe? MfG Spess
Mit den Resets der uC. Dann lauft Bens Programm bei mir wies soll, und mein Servo zuckt auch nich mehr bloed rum. Saemtliche Anzeigen im Resethandler vermelden: Kein reset mehr.
Hi >Mit den Resets der uC. Dann lauft Bens Programm bei mir wies soll, >und mein Servo zuckt auch nich mehr bloed rum. RXC heisst soviel wie 'RX complete' und das ist ein Interrupt, an den man keine C hängen kann. Falls du RXD meinst, dann ist dort ein C dort vollkommen fehl am Platz. Also Problem nicht gelöst. MfG Spess
aeh ja sry - RXD - den PIN an Port D eben. N Kondi am Interrupt wird schwierig ;) Nich geloest - aber es geht doch jetzt *m...t* - oder fliegt mir das ganze bei hoeren Baudraten dann wieder um die Ohren?? :( Habe im Moment 9600 Baud, und keinerlei Datenverluste (zumindest kommt bei Bens Programm das am anderen Ende an was eingegeben wurde...) Sobald ich den Kondi rausziehe - zeigt das Oszi wieder resets an - stecke ich ihn rein bleiben sie aus. Vielleicht bringt das jemanden auf ne Idee wo der eigentliche Fehler liegen kann. Ich bin mit meinem Latein schon lange am Ende und ehrlich gesagt grad froh das es geht. Aber ich will mir natuerlich ungern ne zukuenftige Fehlerquelle in die Schaltung bauen.
Hi
>Pin 5 mit Kabel auf GND gezogen. Muss da noch mehr?
Auch auf der PC-Seite?
MfG Spess
du meinst meine RS232 Buche am Rechner ist im Kaputt? Oder wie soll ich das verstehen?
Hi >du meinst meine RS232 Buche am Rechner ist im Kaputt? >Oder wie soll ich das verstehen? Nein. Nur, ob du eine Masseverbindung von deinem MAX bis zu PC hast. MfG Spess
?? Da ich keinen Plan hab was du grade meinst - wahrscheinlich nicht. Also Pin15 vom Max232 liegt auf GND und der Pin5 der RS232 Buchse eben auch. Oder muss ich Pin5 durchziehen auf GND vom Max232. verwirrt sei Sorry wenn ich mich grad bloed anstelle - aber ich weiß echt nicht was du meinst.
Hi Es sollte eine Verbindung zwischen der Masse deines Boards und Pin5 des Steckverbinders am PC vorhanden sein MfG Spess
siehe Foto von der Schaltung oben. Das weisse Kabel ganz links an der RS232 Buchse geht von Pin5 der Buchse zu GND. Meinst du das?
Gut!
> Bist du sicher, das die Masseverbindung der RS232 OK ist?
Ja dann ist die Masseverbindung in Ordnung. Danke fuer die Geduld.
Hi
>Danke fuer die Geduld.
Das ist nicht das Problem, mich interessiert die Lösung.
MfG Spess
Glaub mir mich auch ;) Ich hab nur wirklich keine Idee mehr die ich beisteuern kann. Ich sitze seit 6 Wochen an der Schaltung, und hab sie mittlerweile sicher 10 mal neu aufgebaut, und alle Teile ausgewechselt. Mir ist es ehrlich gesagt unbegreiflich was da schief laufen soll. Der Anschluss der Buchse kann es eigentlich auch nicht sein, da das Problem auch auftritt wenn das Signal nicht vom Rechner kommt sondern von einem AD - Wandler. (Der soll naemlich eigentlich da hin - irgendwann mal wenn alles geht...)
hmmm eine lösung ist das noch nicht. nur ein hinweis darauf, daß es nicht am programm liegt sondern irgendwas an der beschaltung des µC nicht optimal ist. das ding fängt sich offensichtlich bei RX irgendwelche störungen ein welche den absturz auslösen. wieso? kann ich von aus auch nicht sagen, weiß ich nicht.
Mir ist beim suchen nach Max232 Schaltugen grade folgender Schaltplan im Roboternetz aufgefallen: http://www.rn-wissen.de/index.php/Bild:Avrtutorial_grundschaltung_max232.gif der ja meinem Aufbau ziemlich aehnelt. Aber warum sind hier VCC und GND des Max232 nicht angeschlossen macht man das nicht? Ich habe einen Max232N wie der angeschlossen ist kann man ja oben sehen.
Hi >Aber warum sind hier VCC und GND des Max232 nicht angeschlossen macht >man das nicht? Und was ist das in der rechten, oberen Ecke? MfG Spess
> Und was ist das in der rechten, oberen Ecke?
das sind Pin 2 und 6 VCC und GND sind PIN15 und 16 - die habe ich bei
mir nochmal extra angeschlossen. Ohne die macht der Max232 bei mir auch
nur zicken.
Aber in kaum einem Schaltplan den man im Netz findet sind die
eingezeichnet. Im Datenblatt werden sie angeschlossen.
Hi >das sind Pin 2 und 6 VCC und GND sind PIN15 und 16 - die habe ich bei >mir nochmal extra angeschlossen. Ohne die macht der Max232 bei mir auch >nur zicken. Ich meine die rechte, obere Ecke des Schaltplans . MfG Spess
.. boa sauber uebersehen. Sorry! Okay dann ist der Max232 aber auch richtig angeschlossen. Ich weiß echt nicht mehr wo der Fehler liegen kann. Hat jemand vielleicht n Foto von ner Funktionierenden Schaltung (Mit nem Atmega und nem Max), dann kann ich da nochmal schaun was ich anders habe. Danke!
ich find keinen echten unterschied zu meiner schaltung, außer daß ich den atmega in einer gelöteten fassung habe und der max232 auch gelötet (auf einer tochterplatine) ist. getaktet ist der AVR bei mir mit 11.0592MHz, wenn deine 14 oder was das war ein baudratenquarz sind sollte es da aber auch keine probleme geben. was mich erstaunt ist, daß das ding bei dir crasht - wenn du nur wirre zeichen empfangen würdest okay, aber crashen dürfte er eigentlich nicht wenn du mein programm 1:1 übernommen hast. zumal das bei mir wirklich stabil läuft. ob das vielleicht ein problem mit deinem breadboard ist? kann ich mir zwar eigentlich nicht vorstellen, aber man soll ja nichts ausschließen.
Danke fuers checken! Der Quarz ist ein 14,745 quitsch... also ein Baudratenquarz. Dein Programm hab ich eins zu eins übernommen, nur die Baudratennummer auf meinen Quarz angepasst und noch PORT C bei nem Reset auf High gesetzt und nach den LED befehlen wieder runter, weil ich das am Oszi besser sehe, als die LED resets. [avrasm] ldi r16,0xFF out PORTC, r16 call ledgreen ... call delay100ms ldi r16,0x00 out PORTC,r16 [\avrasm] Wenns das Steckbrett ist rast ich aus... Aber ich hab hier irgendwo noch n altes von ner anderen Firma rumfliegen, ich kanns ja mal testen. Ansonsten kann es sich ja nur noch um die Spannungsquelle handeln, wobei ich die ja mit den Rechnernetzteil ausschliessen wollte. Na gut ich hab hier noch nen LM 338 rumfliegen. Ich bau damit nochmal was auf, und schick n Foto. ... oder saemtliche Atmega bestellungen die ich in den letzten 3 Monaten getaetigt habe sind hinuber... sehr unwahrscheinlich
ich glaube nicht daß die ICs hinüber sind. jedenfalls nicht bis ich es besser weiß. wenn du magst kannst du ja mal so einen aufbau löten, die ICs vielleicht in fassungen damit du diese im falle eines fehlschlages nicht verlierst. oder mußt hinterher wieder ablöten. der einzige unterschied den ich habe ist die stromversorgung. die schaltung in der ich das getestet habe hat später nur zugang zu 12V. folglich wurde das teil aus einem kleinen bleiakku neben dem PC gespeist, der µC und der MAX232 bekommen ihren strom über einen einfachen 7805 festspannungsregler.
7805er hab ich grad nich da. Aber werd mir morgen mal einen holen gehen und ausprobieren. Wenn das nicht hilft werd ich Loeten - wobei ich nur ungern sachen aufloete die schon im Steckbrett nich gehen. Das alte Board ist leider auch von BreadBoard hab ich grad gesehen, wird also nix mit anderer Marke testen. Aber ich glaube auch nicht das die n generellen Fertigungsfehler haben, und das Steckbrett selber hab ich schon ausgetauscht gegen das Gleiche.
hmmm klar, auf dem steckbrett ists einfacher fehler zu korrigieren. ich bau das alles immer auf experimentierplatinen zusammen. viele dinge die man so hat wie relais-ansteuerungen usw. funktionieren grundsätzlich immer und man weiß auch wie man sie ansteuern muß. wie sich der µC elektrisch verhält ist auch klar. sowas funktioniert aufgebaut auch direkt wenn kein aufbaufehler (z.b. transistor falschrum) drin ist. ansonsten halt viel berechnen, weniger probieren. einstellbare widerstände sind sowieso nie verkehrt, die die man braucht sind sowieso nie da wenn man sie braucht. 90% der verbauten teile kommen bei mir auch von ersatzteilspendern. alte pc-netzteile und die chassis von neueren röhrenbildschirmen z.b. sind sehr ergiebig. braucht etwas mehr zeit beim suchen/auslöten und im zweifel funktionsfähigkeit feststellen, aber als bonus findet sich auch hier und da mal ein verwendbarer kühlkörper oder transistor-isolationsmaterial... spulen und kerne... und wenns dann beim einschalten doch mal explodiert hält sich der finanzielle schaden in grenzen.
So hab die Schaltung jetzt mit nem 7805er aufgbaut - und Ueberraschung es geht immer noch nicht... :(
> Dann lauft Bens Programm bei mir wies soll, und mein Servo zuckt > auch nich mehr bloed rum. Hast du das Servo bei deinen Tests angeschlossen? Servos können wunderschönen Schmutz auf der Versorgungsspannung verursachen. Vor allen Dingen, wenn sie anlaufen.
könnte sein, vielleicht mal mit einem dicken elko nach dem 7805 probieren. vielleicht so 4700µF. ich glaubs zwar nicht, möchte aber auch nicht ausschließen, daß der servo es schafft die µC versorgung kurz unter BODlevel zu ziehen. das würde einen reset auslösen.
Der Servo haengt an ner Extra Stromversogung. Und zum testen von Bens Programm hab / hatete ich ihn gar nicht dran.
Hab mir das STK500 jetzt mal bestellt. Mal schaun vielleicht laesst sich der Fehler damit dann finden. Ich halt euch auf dem laufenden.
So einge Zeit vergangen - aber die Schaltung ist mittlerweile auf Platine gelötet, und als Fazit bleibt nur zu sagen: Es war dann wohl doch das Steckbrett, das den Fehler verursacht hat. Auf dem STK500 hat der Code (wie zu erwarten) ohne Resets funktioniert. Auf Platine gelötet funktioniert das ganz auch. EInzige Änderung zu der Schaltung die ich hier gepostet habe: Nach dem Maxen kommen noch Filter (hab ich vom STK Schaltplan abgeschaut) aber ich glaube nicht, das die die Resettst verhindern. Damit kann ich nur den Ratschlag wiederholen der hier mehrfach kam: Gleich auf Platine, hätte viel Zeit und Nerven gespart. Danke nochmal allen die mir hier geholfen haben - auch wenns schon n weilchen her ist.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.