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?
>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
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
>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 ;)
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.
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??
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?
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
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?
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
>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.
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.
> 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.
> 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.
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.
