Guten Morgen, ich bitte Euch um Hilfe da ich den Scheduler von Peter Dannegger nicht zum laufen bringe. Arbeitsumgebung: Atmega 644P , AVRisp MKII , AVR Studio 6 Was nicht funktioniert ist dass die Funktion ( MOTOR) nicht durchgelaufen wird. Folgendes habe ich geprüft: .) ISR wird durchlaufen und löst auch aus .) timertick wird gesetzt .) Timer 1 läuft Das Original von Peter habe ich lediglich um die Tastenentprellung erleichtert da ich die nicht brauche. Im Anhang das PGM welches erst im Enstehen ist also nicht fertig. Vielleicht hat jemand die Zeit da mal darüberzulesen und mir zu helfen das Problem zu lösen. Falls mehr Informationen notwendig sind bitte einfach fragen. Danke
Hartmut Burger schrieb: > Das Original von Peter habe ich lediglich um die Tastenentprellung > erleichtert da ich die nicht brauche. Dass jeder ordentlich seinen Namen am Anfang stehen hat, aber nirgendwo ein Hinweis auf Peter steht... Es hat mir gereicht, da habe ich aufgehört zu lesen. Auch ohne deinen Namen wäre es angebracht, Peters Namen irgendwo zu erwähnen.
:
Bearbeitet durch User
Hartmut Burger schrieb: > Folgendes habe ich geprüft: > .) ISR wird durchlaufen und löst auch aus > .) timertick wird gesetzt > .) Timer 1 läuft Hast Du eine LED an Deiner Hardware, die Du vom Scheduler aus toggeln lassen kannst? VG, Frank
Hartmut Burger schrieb: > if(timerremove(Motor));timeradd( Motor, SECONDS( 3 ) ); Was soll der Quatsch? Du löscht es ständig wieder, da kann es nie ablaufen. Und Doppelquatsch: if(); ist für den hohlen Zahn (Code without effect).
Peter Dannegger schrieb: > Und Doppelquatsch: > if(timerremove(Motor));timeradd( Motor, SECONDS( 3 ) ); hihi, zumindest wird nix nach dem ; an der Ausführung gehindert :-)
Nette Gesellschaft hier. Wer Fehler macht wird gehängt und gesteinigt............. Danke für den Hinweis Peter , jedoch geht es auch mit Korrektur nicht. Mir ist bewusst dass DEIN Code schon mehrmals eingesetzt wurde und der auch sicherlich funktioniert. Gerade aus diesen Grund frage ich . Danke für jede Idee.... LG.....
Jede Menge.
if(PowerMotorOFF &&
DigitalInOutDefined);PowerMotorON;_delay_ms(1000);
if(PowerMotorON );ResetMotorschutzON;
if(ResetMotorschutzON && StartSafety ==0);StartSafety
=1;ResetMotorschutzOFF;
oder hier
if (prot_code_FAULT_receicve == prot_BEGIN );USART_SendByte(prot_ACK);
:-)
Was ist eigentlich PowerMotorOFF? Define? Wollte mir jetzt nicht das
ganze Kunstwerk reinziehen.
Erst mal die eigene Arbeit kritisch hinterfragen. Da ist viel zu tun.
Außer fremde Quellen ist nichts wertvolles im Source.
noreply schrieb: > Außer fremde Quellen ist nichts wertvolles im Source. Aber: Er hat's doch immerhin so weit gebracht, daß der zusammengeklaute Kram compiliert. Viele "C-Programmierer" sind ja noch nichtmal dazu in der Lage...
Hartmut Burger schrieb: > Nette Gesellschaft hier. > > Wer Fehler macht wird gehängt und gesteinigt............. Nö. Das passiert nur denen, bei denen man merkt das sie sich nicht mal im ansatz mit der Materie beschäftigen wollen... > if(timerremove(Motor)); Da fängt es doch schon an. Hier im Forum sieht man wirklich viel Code, gerade von Anfängern. Aber ein ; nach einem if hab ich hier in den 4 Jahren die ich hier nun schon lese, noch nicht gesehen. Ein C-Buch hast du gelesen? Nicht alles was man irgendwo im Internet aufschnappt ist auch cool ( z.B. Fratzenbuch), und das gilt auch beim Programmieren. Wenn du in C nicht so Fit bist, dann schreib dinge aus und rücke ein! > if(timerremove(Motor));timeradd( Motor, SECONDS( 3 ) ); Hättest du das ausgeschrieben,
1 | if(timerremove(Motor)); |
2 | {
|
3 | timeradd( Motor, SECONDS( 3 ) ); |
4 | }
|
hättest du diesen fehler gleich gesehen... > if (Startsequence1 == 1 && Startsequence2 == 1); ... ok, es wäre dir nicht aufgefallen... Aber was soll's: Hätte, Hätte, Deutschlandkette. > if (SystemOk == 0 && (DigitalInOutDefined == 0));iniIO(0);_delay_ms(100); > if (DigitalInOutDefined); > if(StartSafety); > if(StartMot); Sorry wenn ich das hier jetzt so sage, aber: Du hast dich 'n feuchten Dreck mit C beschäftigt! Und genau solchen leuten passiert dann sowas: Hartmut Burger schrieb: > Wer Fehler macht wird gehängt und gesteinigt............. Und wenn ich weiter in dem Code rum schaue: Die Einrückung ist grauenhaft! > asm volatile ("nop"); Dafür gibt es ein Makro, das dir von Atmel Studio zur verfügung gestellt wird: _NOP() (#include <avr/cpufunc.h>) Macht das selbe, macht den Code aber lesbarer. Abläufe über delay/nop zu steuern ist nicht schön. Aus der Zeit ist man schon lange raus. Hat man gerne in alten Spielen gemacht. Wird die Hardware schneller, und das nop damit kürzer, hast du plötzlich ein ganz anderes zeitverhalten. Das ist doch grütze! delay ist selten die lösung, aber (fast) immer das Problem. Leere if-else, leere switch-case... 'Tschuldigung, aber den rotzt schau ich mir nicht länger an! Bring den Code soweit in ordnung, das man beim drauf schauen keinen Augenkrebs bekommt, dann können wir nochmal drüber reden. Ach ja: Einfach mal -Wextra einschalten, dann hättest du gesehen das dir der Compiler mit nacktem Arsch ins Gesicht springen will!
1 | Warning suggest braces around empty body in an 'if' statement |
Das kommt bei jedem deiner komischen if(); Hartmut Burger schrieb: > Nette Gesellschaft hier. finde ich auch! :) Hart, aber Fair! Nennt sich: hilfe zur selbst Hilfe! c-hater schrieb: > Aber: Er hat's doch immerhin so weit gebracht, daß der zusammengeklaute > Kram compiliert. Stimmt schon, aber deswegen funktioniert es trotzdem nicht. Ist in etwa so als würde man sagen: Jo, ist schön das du Autoteile geklaut und soweit zusammen gebaut hast, das es wie ein Auto aussieht. Ja, stimmt, es fährt aber trotzdem nicht. Also noch lange kein Grund da jetzt jemandem auf die Schulter zu klopfen, von wegen: "Gut gemacht."
Hartmut Burger schrieb: > Danke für den Hinweis Peter , jedoch geht es auch mit Korrektur nicht. Ich kann nicht hellsehen, was Du wie korrigiert hast. Du mußt nach jeder Änderung den neuen Code als Anhang einsehbar machen.
@Hartmut Siehst Du: Das Schlimmste ist vorbei. Die größten Koniferen des Forums sind leicht zu erkennen: Sie haben auch die größte Schnauze. http://static.twoday.net/siebensachen/images/globi-pfeift.jpg
Das Copyright aus einem Open-Source Quellcode zu entfernen ist allerdings ein ziemlich schlechter Stil. Für mich ist das ein absolutes "no go". Mich wundert ja, das Peter sich nicht beschwert.
Worüber sollte Peter sich auch beschweren? Das Entfernen des (c) schein ja das Einzige zu sein, das funktioniert hat. Und hat der TO nicht spätestens damit die Haftung für die Funktion "seines" Codes übernommen? Zum schlechten Verhalten der Experten in diesem Forum kann ich nur soviel sagen: Wenn jemand was lernen will/soll, dann muß man ihn in kaltes Wasser werfen. Das bedeutet nicht, das man ihn untergehen lässt. Aber ohne nass lernt man nix. An der Reaktion der "Lernenden" kann man dann deren Motivation ablesen.
Falls du dir sicher bist was du behauptest dann suche nach dem Original. Und falls ich da sein CR entfernt hätte dann hättest auch recht. Die HTML Datei ist wohl dabei , und wenn du damit meinst dass ich damit sein CR nicht angegeben habe dann entschuldige ich mich selbstverstänlich.
Danke für all die guten Tips. Im Anhang habe ich all die wertvollen Tips eingearbeitet und das Programm so auf das Wesentliche gekürzt. Leider wird die Funktion Motor nicht ausgeführt. Jemand noch eine Idee , auch harsche Kritik ist willkommen. Danke
Nimm dieser Makros
1 | #define MotorspeedON PORTC |= (1<<PINC1)
|
2 | #define MotorspeedOFF PORTC &= ~(1<<PINC1)
|
3 | #define MotorLinksON PORTC |= (1<<PINC2)
|
4 | #define MotorLinksOFF PORTC &= ~(1<<PINC2)
|
5 | #define MotorRechtsON PORTC |= (1<<PINC3)
|
6 | #define MotorRechtsOFF PORTC &= ~(1<<PINC3)
|
7 | |
8 | |
9 | |
10 | #define IniRearSlow PIND & ( 1 << PIND5 )
|
aus schedule.h raus und in main.c rein. erstens haben die dort nichts verloren (im schedule.h geht es um den Scheduler und nicht um irgendwelche Motorsteuerungen) und zweitens kann man dann auch den Unsinn sehen, den du hier programmierst.
1 | if (MotorRechtsON) |
denn mit diesem Makro
1 | #define MotorRechtsON PORTC |= (1<<PINC3)
|
funktioniert das ganz sicher nicht. Etwas der Form
1 | variable |= ( 1 << Bitnummer ) |
setzt ein bestimmtes Bit in 'variable'. Es ist aber völlig ungeeignet festzustellen, ob ein bestimmtes Bit in 'variable' gesetzt ist. Wenn du im Kommentar schreibst
1 | // wird nicht erreicht
|
... wie hast du das festgestellt? Denn irgendeine vernünftige Aktion (im Sinne einer Entscheidung beim if) darfst du von
1 | if (MotorRechtsON) |
sowieso nicht erwarten. Auch wenn so ein Taskscheduler eine feine Sache ist würde ich dir trotzdem ans Herz legen erst mal ganz ordinär zu arbeiten. Ein Taskscheduler kann nämlich fehlende Basiskentnisse auch nicht ersetzen. Und Bitmanipulationen jeglicher Art, sei es setzen, löschen oder abfragen sind in der µC Programmierung Basiskentnisse. Solange du die nicht im Schlaf beherrscht, hilft dir auch ein Scheduler nicht weiter. Und was noch viel schlimmer ist: solange du die nicht im Schlaf beherrscht, ist es sinnlos ein reales Problem anzugehen. Solange dieses Beherrschen nicht vorhanden ist heißt es: zurück auf die Übungsbank und noch 5 Beispiele mit LEDs und 1 oder 2 Tastern durchprogrammieren. Dazu brauchst du aber erst mal keinen Scheduler.
:
Bearbeitet durch User
Einfach ein gutes und strukturiertes Programmieren lernen und umsetzten. Dann braucht kein Mensch dieses vorgefertigte halbwertige Zeug in dessen Einarbeitung und Anpassung man oft mehr Zeit investieren muss als wenn man es solide selber erstellt und umzusetzen. Die meisten "fertigen" Codes hier dienen eh nur zu Selbstprofilierung der Autoren. Die dann auch noch mit unfreundlichen Kommentaren daher kommen wenn jemand ihren "heiligen" Gral nicht gleich auf Anhieb verstehen.
Axiom schrieb: > Dann braucht kein Mensch dieses vorgefertigte halbwertige Zeug in dessen > Einarbeitung und Anpassung man oft mehr Zeit investieren muss als wenn > man es solide selber erstellt und umzusetzen. So krass würde ich das nicht sehen. Dieser Einfach-Scheduler hat durchaus auch seine Berechtigung als eine Art Minimal-Framework, wie man mit einem Timer Multitasking des kleinen Mannes macht. Anstelle das immer wieder in jedem Projekt neu zu machen, kann es durchaus angenehm sein, da auf einer Basis aufzusetzen. Aber das Problem ist hier ja anders gelagert. Denn auch mit einem Scheduler wird nicht aus einem Anfänger ein Könner. Dieser Scheduler ist nur eine Organisationsform. Das bedeutet aber nicht, dass man seine Basics nicht beherrschen muss. > Einfach ein gutes und strukturiertes Programmieren lernen und umsetzten. Full Ack. Denn wenn man das kann, dann kann man auch einschätzen, wann einem so ein vorgefertigtes Teil einen Mehrwert bringt und wann nicht. Das alles hat aber mit der Überschrift nichts zu tun "AVR Scheduler von Peter Danneger will nicht" Wahrscheinlich ist der Scheduler-Code so ziemlich der einzige in diesem Programm, der tatsächlich funktioniert. Was man von den 10 Zeilen, die vom TO stammen, nicht behaupten kann.
:
Bearbeitet durch User
Jetzt muß ich aber Peter schon in Schutz nehmen. Bis jetzt haben bei mir alle seine von mir adoptierten Beispiele einwandfrei funktioniert und ließen sich meist ohne große Schwierigkeiten anpassen oder Portieren. Nur muß man sich manchmal anstrengen um die feinen Details richtig zu verstehen;-) Grüße, Gerhard
:
Bearbeitet durch User
Der Scheduler ist doch ok, soweit ich ihn überflogen habe. Vielleicht gehört noch etwas Dokumentation dazu. ;-) Als Threadstarter würde ich erstmal die Motoransteuerung programmieren und testen. Im Hauptprogramm kann man das doch wunderschön machen. Dann die Programme im Timerinterrupt einschleifen. Dann mal Deep Dive in den ganzen Sourcecode. ;-) Die Kommunikationsroutinen sperren das Interruptsystem. Den Watchdog habe ich auch nicht begriffen. :-) Dann erst über den Scheduler nachdenken.
Sowas geht auch ohne Interrupts. Das Dilemma liegt daran dass fast jeder anfängt die Programmierung entweder auf PC-Systemn mit objektorientierten Paradigmen zu lernen oder auf Mikrokontrollern mit so selten dämlichen Beispielen wie eine LED blinken zu lassen mit einem _delay Befehl. Mann braucht abgesehen von der Ansteuerung von periphärer HW keine verzögernde Routinen beim programmieren. Man muss einfach ein wenig wie ein Spieleprogrammierer denken. Prozedural.
Nochmals Danke für die wirklich gut gemeinten Tips. @ Karl Heinz : die Makros sind nur zur Kurzversion in der Scheduler.h gelandet : im Anhang habe ich das PGM nach deinen Tips , geändert : der Scheduler funktioniert bei mir leider nicht Zu allen anderen Kommentaren kann ich nur sagen dass ich gerne offen bin für Vorschläge , jedoch ist aller Anfang schwer und alle hier haben einmal von 0 begonnen. Danke
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.