www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART verursacht Reset(?)


Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  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;)

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo ist deine Interrupt-Tabelle ?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zeig das programm nochmal wie es jetzt aussieht.

Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bitteschoen :)

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Friedrich Wessel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MAXRAM ist in den neueren Headerdateien von AVR das was früher RAMEND 
war

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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??

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie dem auch sei - ich hab eben mal die beiden Headerdateien verglichen 
und beide definieren MAXRAM bzw. RAMEND bei 0x085f.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
er hat sowieso komische definitionen. seine ganzen .org ???adr zeilen 
erzeugen bei mir fehler.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...!

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ben ___ (burning_silicon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da faellt mir ein.
Ben, magst du mir noch mal deine beiden Fuse-Bytes dazugeben? Einfach, 
damit ich mal die genauen Unterschiede rausarbeiten kann.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.
ldi r16,0xFF
  out PORTC, r16

  call delay100ms
  call delay100ms
  call delay100ms
  call delay100ms

  ldi r16,0x00
  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...

Autor: Ben ___ (burning_silicon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...anbei nochmal die Windowsvariante ohne Consolen Ausgabe - die sollte 
dann zumindest in der Nähe der angegebenen Sleep Zeit sein

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
negativ. verhält sich genauso wie das erste programm. auch ohne resets. 
her mit deiner schaltung.

Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... so dann bin ich mal gespannt..
ich hoffe ich hab keine Fehler reingemalt dies gar nicht gibt..

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Bist du sicher, das Pin5 des Sub-D-Steckverbinders mit VCC verbunden 
ist?

MfG Spess

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aeh sorry - ne der ist natuerlich auf GND

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na ich meinte eine vom PC getrennte stromversorgung. ein labornetzteil 
oder sowas.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: surma (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab die Schaltung mit nem neuen Atmega nochmal aufgebaut. Der Fehler 
besteht immer noch.
Foto ist anbei.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 100nF Keramik-Cs, keine Elkos.

meinst du an alle (also zwischen GND VCC der uCs)?

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
an beide pins Vcc und AVcc gehören keramik-abblock-Cs. 100nF an ARef 
gegen masse können auch nicht schaden.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay hab die Elkos gegen 100nF Kerkos ausgetauscht und noch einen an 
Aref gegen Masse gepackt. Fehler bleibt

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ICH HABS...

Ben hat mich mit dem Kondi gegen Aref drauf gebracht.
Ein 100 nF Kondi gegen Masse an den RXC - dann ist Ruhe

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Bist du sicher, das die Masseverbindung der RS232 OK ist?


MfG Spess

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pin 5 mit Kabel auf GND gezogen. Muss da noch mehr?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Pin 5 mit Kabel auf GND gezogen. Muss da noch mehr?

Auch auf der PC-Seite?

MfG Spess

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du meinst meine RS232 Buche am Rechner ist im Kaputt?
Oder wie soll ich das verstehen?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
?? 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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Es sollte eine Verbindung zwischen der Masse deines Boards und Pin5 des 
Steckverbinders am PC vorhanden sein

MfG Spess

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Meinst du das?

Ja.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut!

> Bist du sicher, das die Masseverbindung der RS232 OK ist?

Ja dann ist die Masseverbindung in Ordnung. Danke fuer die Geduld.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Danke fuer die Geduld.

Das ist nicht das Problem, mich interessiert die Lösung.

MfG Spess

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist beim suchen nach Max232 Schaltugen grade folgender Schaltplan im 
Roboternetz aufgefallen:

http://www.rn-wissen.de/index.php/Bild:Avrtutorial...

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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.. 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!

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So hab die Schaltung jetzt mit nem 7805er aufgbaut - und Ueberraschung 
es geht immer noch nicht... :(

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Servo haengt an ner Extra Stromversogung.
Und zum testen von Bens Programm hab / hatete ich ihn gar nicht dran.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir das STK500 jetzt mal bestellt. Mal schaun vielleicht laesst sich 
der Fehler damit dann finden. Ich halt  euch auf dem laufenden.

Autor: surma (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.