Ich sitze jetzt seit 6 Stunden vor diesem Problem und bin langsam am
verzweifeln
Grundidee war das ein Timer mit 2 Compare-Interrupts 2 Motoren steuern
kann.
Beide Routinen sind absolut identisch. Inzwischen habe ich sogar einen
zweiten Timer spendiert, der exakt eingestellt ist, wie der erste.
Motor 1 läuft super / Motor 2 macht, was er will
if(TCNT1<OCR1B&&checkbit(PINA,PA3)&&!checkbit(az_status,1))// Wenn drehrichtung identisch aber direktion bit falsch / direction bit setzen
154
setbit(az_status,1);
155
if(TCNT1<OCR1B&&checkbit(PINA,PA2)&&checkbit(az_status,1))// wenn Drehrichtung anders herum und direktion bit gesetzt / direction Bit löschen.
156
clearbit(az_status,1);
157
}
158
}
Während der AZ-Motor tut, wie er soll kann ich den ho-Motor ein mal
ansprechen fährt er links herum und ich stoppe während des Hochfahrens,
schaltet er ein. Danach kann ich mit dem Sollbyte machen was ich will,
interessiert nicht mehr. Az funktioniert weiterhin ungestört. Fahre ich
ihn rechts herum an fährt er hoch und stoppt abrupt am Ende der PWM.
Dabei macht es keinen Unterschied, ob der Timer nun OCR3B ist oder
OCR1C. In Beiden Fällen die gleiche Grütze.
Nur der Vollständigkeit halber hier noch den Sollbyte-Manipulator
nach 10 Stunden und nac
h dem ich das Programm nun 5 mal neu geschrieben habe habe ich das
Problem gefunden.
Das Programm funktioniert wenn die Variable nicht ho_status heißt.
(jetzt heißt sie ho_statusbyte.
Ich habe zur Sicherheit alle meine Dateien nach dem Eintrag ho_status
durchsuchen lassen und kann jetzt sagen, dass bei mir keine zweite
Variable so heißt.
Ich würde mich etwas besser fühlen, wenn ich wüsste warum die Variable
nicht ho_status heissen darf.
Bei solchen Codeschnipseln gibt es hier immer große Jubelschreie:
Juhu, wir dürfen wieder das große Rätselraten beginnen.
Ooch wie schön, erstmal den unbekannten Compiler rauskriegen, die
unbekannte MC-Familie und den unbekannten MC-Chip.
Was ist wo und wie deklariert, was ist sonst noch so im Programm.
Ooch wie schön, nen Haufen unbekannter Unterfunktionen und Macros.
Ooch wie schön, der Compiler bricht nach 1000 Errors ab, weil ihm so
viele wichtige Informationen fehlen.
Nicht so große Rätselfreunde könnten sich daher leicht hinreißen lassen
zu:
Solche Hellseher-sein-müssen-Postings sind voll forn Ar***.
Peter
> Juhu, wir dürfen wieder das große Rätselraten beginnen.> Ooch wie schön, erstmal den unbekannten Compiler rauskriegen,
avr-gcc (GCC) 4.1.2 (WinAVR 20070525) ist meines wissens nicht soo
unbekannt
> dieunbekannte MC-Familie
Es ist mir neu das Variablennamen aus C-Programmen im Programmspeicher
der uC Familie abgelegt werden.
> und den unbekannten MC-Chip.
dito
> Was ist wo und wie deklariert, was ist sonst noch so im Programm.
Nichts was nicht funktionieren würde ...
> Ooch wie schön, nen Haufen unbekannter Unterfunktionen und Macros.
Oh in der Tat! Ganze 3 Makros und die sind auch noch hier aus dem
Tutorial!
> Ooch wie schön, der Compiler bricht nach 1000 Errors ab, weil ihm so> viele wichtige Informationen fehlen.
Welche Errors? Wenn ich wenigstens nur ein einziges "warning" hätte gäbe
es zumindest einen Anhaltspunkt.
> Wie und wo waren/sind die Variabeln deklariert?
volatile unsigned char als globale Variable im main.c
@Peter Dannegger
Nur für mich zum Verständnis:
Wie bekommt man eigentlich ein, in den uC-Chip ladbares hex-file anhand
dessen man die Funktion oder Fehlfunktion des Programmes testen kann,
wenn der Compiler nach nach 1000 Errors abbricht, weil ihm so viele
wichtige Informationen fehlen?
> avr-gcc (GCC) 4.1.2 (WinAVR 20070525) ist meines wissens nicht soo> unbekannt
Davon steht aber in Deinem ersten Posting nichts. Und darum geht es.
> Ganze 3 Makros und die sind auch noch hier aus dem Tutorial!
Dann schreib's dabei. Das Forum wird auch von Leuten genutzt die das
Tutorial nicht kennen (Welches eigentlich, gibt sicherlich mehrere hier)
und das nicht sofort sehen.
In dem Controller können auch Fehler sein, die dazu führen, daß Dein
Interrupt nicht korrekt ausgeführt wird. Kann man natürlich nur
beurteilen wenn man weiß welchen Controller Du verwendest.
Der Compiler könnte Fehler enthalten. Vielleicht ist WinAVR20070525 kein
guter Stand.
Alles Gründe warum diese Infos wichtig sein könnten.
Wenn Du das ganze Projekt posten würdest könnte man dem Fehler
vielleicht finden. Nur mit dem Code-Schnipsel ist es recht
unwahrscheinlich.
--
Dirk
Es ist sogar recht unwahrscheinlich dass jemand den Fehler finden würde,
wenn ich das ganze Projekt posten würde, denn es läuft auf einem Mega88
ganz problemlos, obschon ich dort jetzt auch die ho_status-Variable
sicherheitshalber umbenannt habe, es sei denn er baut auch die komplette
Hardware nach, was wohl als Hilfestellung unzumutbar ist.
Der Interrupt wird ja korrekt ausgeführt, der Inhalt einer der beiden
Variablen ist lediglich fehlerhaft, was keinen Sinn macht, wenn beide
genau gleich bearbeitet werden.
Dabei spielt es keine Rolle ob die Variablen in einem oder in zwei
unterschiedlichen Interrupts abgearbeitet werden. Es macht aber einen
Unterschied, ob die Variable ho_status oder ho_statusbyte heißt. Das hat
einfach nichts mit uC-Familie, uC-Typ noch mit Makros usw zu tun,
allenfalls könnte es mit dem Compiler zu tun haben.
> Davon steht aber in Deinem ersten Posting nichts. Und darum geht es.
Nein, geht es nicht, es sei denn Herr Dannegger hätte an seinem Post 7
Stunden und 47 Minuten gearbeitet ...
> allenfalls könnte es mit dem Compiler zu tun haben.
Und auch den hast Du erst genannt, als sich Peter beschwert hat.
Ich wollte Dich auch nur darauf hinweisen, daß Du einfach zu wenig
Informationen in Deinem Posting hattest.
Auch wenn natürlich Deine weiteren Postings darauf hindeuten, daß das
Problem nichts mit der Hardware zu tun hat, ging es Peter wohl auch um's
Prinzip.
> Es ist sogar recht unwahrscheinlich dass jemand den Fehler finden würde,> wenn ich das ganze Projekt posten würde [...] es sei denn er baut auch die> kompletteHardware nach
Du sagst doch selbst, daß Du nicht glaubst, daß die HW schuld ist. Wozu
also nachbauen?
Mit dem ganzen Projekt könnte man das auch mal durchbauen und Hex und
ASM-Code der Variante mit ho_status und der mit ho_statusbyte
vergleichen.
Wenn der Name wirklich einen Unterschied ausmachen soll dann müsste auch
der ASM-Code bzw. das generierte Bin/Hex-File unterschiedlich sein.
cerberus wrote:
>> Davon steht aber in Deinem ersten Posting nichts. Und darum geht es.> Nein, geht es nicht, es sei denn Herr Dannegger hätte an seinem Post 7> Stunden und 47 Minuten gearbeitet ...
Was meinst Du mit den 7 Stunden und 47 Minuten ?
Daß es überhaupt um einen AVR geht, hast Du erst 3 Tage nach meinem Post
rausgerückt, im Post vom 15.06.2008 12:31.
Ob Dein Problem mit der Namensgebung zusammenhängt oder mit anderen
gleichzeitig gemachten Änderungen (auch Compileroptionen), kann man
nicht beurteilen.
Vielleicht hast Du auch irgendwelche Macros definiert, die gleich
heißen.
Oder nicht sichtbare Zeichen in den Codezeilen.
Oder ....
Mit dem gesamten Code, der GCC-Version und dem Makefile hätte man das
aber leicht herausfinden können.
Peter
cerberus wrote:
> Oh in der Tat! Ganze 3 Makros und die sind auch noch hier aus dem> Tutorial!
Na aber hallo, gehts Dir noch gut?
Du erwartest also allen Ernstes, daß jeder sämtlichen Code im Forum
auswendig kennt?
Ich hab den AVR 1997 kennen gelernt, da war hier nichts mit Tutorial.
Ich hab auch nicht die Zeit, dann später etwas zu lesen, worüber ich
schon längst Bescheid weiß.
> Welche Errors? Wenn ich wenigstens nur ein einziges "warning" hätte gäbe> es zumindest einen Anhaltspunkt.
Unbekannte Macros erzeugen haufenweise Folgefehler, probiers aus.
> volatile unsigned char als globale Variable im main.c
Diese Zeile gibt auch nur Compilerfehler.
Ist es denn so schwer, den exakten Quelltext zu posten?
> Wie bekommt man eigentlich ein, in den uC-Chip ladbares hex-file anhand> dessen man die Funktion oder Fehlfunktion des Programmes testen kann,> wenn der Compiler nach nach 1000 Errors abbricht, weil ihm so viele> wichtige Informationen fehlen?
Na eben.
Ich konnte das ja nicht und das war meine Rede.
Daß Du es konntest, weil Du alle fehlenden Informationen hattest, hilft
mir nicht einen Pups beim Lösen Deines Problems.
Peter