C-Programmierung

Hab' mir Dein C-Demo-Programm mal angesehen. Im Prinzip sieht das vom System so aus, dass es eigentlich funktionieren müßte, wobei Du von den "Reproduzierbarkeiten" der empfangenen Funkensignale noch sehr viel Gottvertrauen drin hast. Mir fehlt hier ein bißchen die Hysterese, damit auch bei einer kleinen Verschiebung des Nullpunkts die Fahr-Quadranten (vorwärts/rückwärts) noch berücksichtigt werden.

Aber jetzt mal ein paar Sachen im Detail:

Du verwendest von den Timern her ein anderes System als ich. Das funktioniert hier in diesem Demo-Fall, weil Du nur einen einzigen Motor berücksichtigst. Aber wenn Du zwei Motoren verwenden willst, dann klappt das nicht.
Und zwar löscht Du den Timercounter bei jeder steigenden Flanke des Empfängersignals. Und diesen gelöschten Wert (=0) schreibst Du dann in das Zählerregister, wo Du Dir den Timerwert für die steigende Flange merkst. Ich würde also empfehlen, das Löschen des Timers beim Status "steigende Flanke empfangen" zu eleminieren. Lass den Timer fröhlich munter im Kreis zählen, also zwischen 0 und 255. Nach 255 beginnt er automatisch wieder bei 0. Und wenn Du einen Wechsel des Emfpängersignals von 0 auf 1 feststellst, dann merkst Du Dir den aktuellen Zählerwert, so wie Du das jetzt auch schon tust.

Einen Fehler wird die Empfänger-Pulserkennung machen. Und zwar wenn Du die Software startest und genau in diesem Augenblick der Empfänger schon auf "1" ist. In dem Zählerstatus 0 reagierst Du nämlich darauf, dass eine 1 am Empfängersignal vorhanden ist, aber nicht ohne die Vorbedingung, dass vorher eine 0 war. Das klappt erst nach der ersten Runde mit einem Zählerpuls. Sobald einmal ein Zählerpuls erkannt worden ist, dann stimmt die Arbeitsschleife.
Meine Empfehlung daher:
Mach' einen Status mehr in Deine Status-Maschinerie. Und zwar:
Status=0: Auf ein 0-Signal vom Empfänger warten. Wenn erhalten: Status wird auf 1 geseetzt
Status=1: Auf das 1-Signal warten. Wenn erhalten: Timerwert merken, Status wird 2
Status=2: Auf das 0-Signal warten. Wenn erhalten: Timerwert merken . Status wird 3
Status =3: Prüfen, ob die Timerwerte plausibel sind. Wenn ja, dann eine separate Auswertung für die Motoren aufrufen.
Egal ob das Empfängersignal nun was brauchbares (0.8ms bis 2,2ms) geliefert hat, der Status wird jetzt wieder auf 0 zurückgesetzt.

Du prüfst also im Prinzip zweimal ab, ob das Signal auf 0 geht. Im Status 2 um aktiv zu erkennen, ob das Empfängersignal jetzt genau in diesem Augenblick von 1 auf 0 gefallen ist, und dann anschließend wieder im Status 0, um ja ganz sicher zu sein, dass hier nicht irgendeine blöde Vorbedingung zu einem Fehl-Signal geführt hat. Beim erstmaligen Aufruf der Routine (=Start des Fahrtreglers) kommt also keine Fehlauslösung des Motors oder der Waffe zustande)

Soweit mal zur Systematik der Empfänger-Signal-Erkennung. Wichtig ist, siehe oben, dass Du das Rücksetzen des Timers eleminierst, sonst kannst Du das zweite Empfängersignal nicht erkennen bzw. erfassen.

Was Du mal versuchen solltest: Blockweise Ausgliederung der Funktionalitäten. Also ein paar Subroutinen bilden, die dann von der Main-Schleife aus aufgerufen werden.

Meine Empfehlung:
- Die Initialisierung der Ports etc. in eine "Sub Init()" legen. Diese Sub dann von der Hauptroutine aus einmal anspringen. (=> Müßte auch in meinem Demo-Programm für Dich so gemacht sein)
- In der Hauptschleife "While(1)" dann die Abfrage der Empfängersignale legen. Also die ganzen Zeilen der Empfängersignale zunächst mal in eine Sub legen und dann von der Hauptschleife aus einmalig abarbeiten
- Die Ansteuerung der Motoren würde ich nicht in die Auswerteroutine von dem Empfängersignal legen, sondern separieren. Heißt: In der Hauptschleife aus kommt der Aufruf von dem Empfängersignal (s.o.). Danach rufst Du eine zweite Subroutine auf, die Dir die Motoren ansteuert. Z.B. "Sub SetMot1()". In dieser Routine beginnst Du mit einer if-Anweisung damit, den Status von dem Empfängersignal abzufragen. Wenn der (laut meiner obigen Empfehlung) aktuell gerade auf Statuswert=3 liegt, dann heisst das, dass aktuell gerade eine steigende und fallende Empfängersignalflanke eingetroffen ist. Also ist das was da, was ausgewertet und verarbeitet gehört. Also dürfen jetzt die Motoren entsprechend der Timerwerte angesteuert werden. Wenn der Empfängersignal-Status anders als 3 ist, dann gibts hier in dieser Subroutine nichts zu tun. Somit Rücksprung zur Main-Schleife und weiter auf die Empfängersignale warten.
Als Gag: In dieser Motoren-Auswerteroutine kannst Du jetzt den Status von 3 zurück auf 0 setzen. Praktisch als Quittierung für die Empfänger-Signalroutine, dass jetzt die beiden Timerwerte überprüft und ausgewertet wurden und ab sofort wieder mit dem Einlesen der Empfängersignale begonnen werden darf.

Soweit verständlich, wie ich das meine? Wenn nicht, dann einfach nachfragen, bin da nicht beleidigt oder genervt, wenn ich es mit anderen Worten noch einmal mache.

Zitat

Bei deinem Code hab ich bislang noch Schwierigkeiten, mich durch die über 1600 Codezeilen durchzuwurschteln und die für mich wichtigen Zeilen zu finden. Besonders, weil die PIC-Befehle zum Teil auch anders sind.

Ja, verständlich. Ich habe zwar sehr viel in Blöcken und Subroutinen programmiert und meinen Dokumentation macht auch sehr viel aus, aber es sind halt im Laufe der Zeit sehr viele Änderungen und Verbesserungen mit eingeflossen. Geräde die Gägs mit der Parametrierung per PC machen die Sache halt u.U. schwieriger zu Erfassen, weil ich verschiedene Betriebsmoden berücksichtigen muss.

Zitat

Wenn ich dann den Hebel leicht nach vorne bewege geht diese aus. Mehr nicht. Beim Hebel nach hinten ändert sich nichts.

Kannst Du bei Deinem Entwicklungssystem die Sache debuggen?
Dann setz' mal einen Breakpoint auf "elseif", wo Du die Auswertung machst. Also dann, wenn sowohl eine steigende als auch fallende Flanke erkannt wurde. Dann den Wert von den beiden Timern abfragen. Liegt die Differenz in dem erwarteten Bereich, wo Du derzeit Deine (festen) Grenzen für die Vorwärtsfahrt, Neutralstellung und Rückwärtsfahrt gelegt hast?

Möglich Fehlerursachen:
- Der Timer läuft nicht zyklisch bzw. hört dann bei 255 auf (=> Initialisierungssache)
- Der Timer ist ein 16bit- und nicht ein 8bit-Timer
- Die Zeitdefinition mit den Prescalern ist falsch und die Zyklusschleife von dem Timer ist nicht 4ms
- Die Differenz von der Start- und Stopzeit des Timers passt nicht zu den definierten Grenzen für die Erkennung der Vorwärts- Neutralstellung und Rückwärtsfahrt.

Hier bei diesen Grenzen ist noch ein Systemfehler, weil Du keinen "Neutralbereich", sondern eine feste Grenze hast, wo die Neutralstellung ist. Da wirst Du höchstwahrscheinlich nie genau die Neutralstellung treffen. Der Motor wird immer entweder vorwärts oder rückwärts fahren. Aber egal, laut Deinem o.g. Fehlerbild ist da noch was anderes faul.... Lies mit dem Debugger einfach mal die Werte aus, die sich für die Start-/Stop-Differenz ergeben, wenn die Funke auf Neutralstellung , auf Vollgas vorwärts und auf Vollgas rückwärts ist. Ich denke, da kannst Du das dann schon herausfinden, wo der Bug im Programm ist.

Wegen Subroutinen:
Sorry, ich dachte, das Prinzip wäre bekannt. Aber umso besser, wenn Dir das anderweitig schon jemand erklärt hat.

Zitat

Will dich ja nicht zu Tode fragen!

Wäre kein Problem. Hauptsache es geht von dem know-how etwas an die Jugend weiter....

Die C++ - Programmierer am PC können natürlich aus dem Vollen schöpfen, was Speicherplatz und RAM angeht. Da muss Du Deinen Bruder u.U. ein bißchen bremsen, wenn er das Programm umstricken will.

Also: Frag ruhig !

Mit dem AVR kann ich Dir leider nicht helfen, ich habe bisher erfolgreich einen Bogen um diese Prozessoren machen können. Aber Alex und Gizmo sind da recht fit, vielleicht können sie Dir ein paar Empfehlungen geben, wie Du den Debugger einen Tritt geben kannst.
Ohne Debugger kannst Du eine Softwareentwicklung vergessen. Früher habe ich das auch mit Try-Error-Methode machen müssen, weil ich keinen Debugger hatte. (EProm geschossen, in die Schaltung eingesetzt, ausprobiert, entnommen, EProm gelöscht, nächster Versuch....)

Mit dem Takt von den Timer kannst Du einen ganz primitiven Test machen: Mach ein kleines Demoprogramm, das immer im Kreis läuft. Wenn der Timer exakt auf Null steht, dann schalte eine LED ein. Wenn der Timer auf 128 steht, dann schalte die LED wieder ab. Mit dem Oszi dann die LED abfragen und schon hast Du die echte Timer-Taktfrequenz.

Zitat

Ich werde mich morgen erstmal an die Subroutinen wagen. Dann kommen wahrscheinlich die Fragen.

Ja, gib' dann bescheid.
Mit dem System, wie man den Timerwert auf die PWM des Motors umsetzt, da werde ich wohl noch ein paar Worte und eine Zeichnung dazu verlieren.
Gib' einfach bescheid, wenn Du wieder "aufnahmebereit" dafür bist. Aber wenn die Timererfassung noch nicht klappt (s.o.), dann bringt der nächste Schritt noch nichts.

(1) Flüchtig drüber gehuscht sehe ich erstmal keinen "Bock". Genauere Analyse wäre notwendig...

(2) Embedded Programmieren ohne Debugger ist böse. Nach der Trial & Error Methode hab ich das früher auch gemacht. Mittlerweile hab ich aber sogar 2 JTAG mkII...

(3) Ausser den angesprochenen Debuggern von Atmel gibt es auch noch die für die Bastler die dann besonders günstig sind wenn man löten kann.
http://www.usbprog.org/index.php/Hauptseite
http://gandalf.arubi.uni-kl.de/avr_projects/evertool/index.html
http://www.olimex.com/dev/avr-usb-jtag.html
http://www.miklobit.com/JTAG_TWICE.530+B6Jkw9Mw__.0.html
...

Bei den meisten wird ein JTAG mkI emuliert. Zugegeben, das ist schon etwas angegraut, aber zum günstigen Einstieg in das Debugging reicht es in der Regel und kompatibel zum aktuellen AVRstudio müssten auch noch alle sein...

(4) Behalte das mit den Bits löschen und setzen ruhig bei, lieber zuviel als zuwenig, denn das ist guter Stil wenn es nicht auf jedes Byte Flash ankommt. Das Gleiche gilt für lokale Variablen. Da sollte man sich angewöhnen die immer mit einem definierten Zustand zu initialisieren...

(5) Genau wie bei den Bits sollte man sich auch angewöhnen Konstanten als DEFINES auszulagern. Das macht es übersichtlicher und man muss nur an einer zentralen Stelle den Parameter ändern...

(6) Den Port würde ich wie die Timer über die Bit Defs laden. Also in etwa so:

PORTB ^= (1 << PB4) | (1 << PB2) | (1 << PB0);

(7) PWM würde ich wie hier schon gemacht IMMER über die Hardware Einheiten machen, denn so läuft das auch sauber im Hintergrund weiter wenn man im Vordergrund was anderes machen muss. Eine stabile PWM in Software nachbilden die frei von Jitter und den ganzen Dreckeffekten ist, wird eh böse. Falls die OCs nicht reichen lieber 1,24 EUR in einen dickeren AVR investieren...

[8] Periodische Signale würde ich über die ICPs einlesen. Ist wie bei (7) das Gleiche bloß quasi anders rum. Mit etwas Geschick und Hardware Hacking kann man übrigens auch mit einer ICP ALLE Kanäle eines Empfängers auswerten, egal wie viele das sind. Entweder man greift am Receiver das Summensignal per Hack ab, hat Glück und der Receiver gibt es von sich aus heraus oder aber mit Aussenbeschaltung am AVR...

(9) Das ist zwar unschön, aber manchmal kann es sich lohnen ein Programm im AVR Simulator zu testen...

Ich hab' jetzt das Programm noch nicht angesehen. Aber "trocken" eine Anmerkung dazu: Wenn Du im Debuggen bist, dann läuft das Empfängersignal eiskalt weiter. Das heißt, dass Du durch das "Ansehen" der Variablen inzwischen Zeiten bekommst, die jenseits der Brauchbarkeit sind. => Dies also mal beachten.

Nach meiner Ansicht ist der C-Ausdruck korrekt. (also keine zwei "=="....)

Wie gesagt, hab' Deinen Code jetzt nicht angesehen. Aber kann es u.U. sein, dass das "Setzen" des Timers ein paar Zyklen verlangt und Du zu schnell bist?

Dass man das Timerregister nicht auslesen kann, das glaube ich nicht. Scheidet als Ursache aus.
Dass der Timer "im Kreis" läuft und nicht bei Endanschlag nach 4ms aufhört, das ist auch gewährleistet, oder?

Tja,... dann gehen mir die Ideen aus.

Zitat

Also diese "|" verknüpfungen hab ich vergessen. Ist glaub ich ne UND-Verknüpfung oder?

Nein, müßte eine ODER-Verknüpfung sein.

UND wäre das "&".

Etwas verwirrt bin ich über das Setzen des Ports. Ok, ich kenne den Atmel jetzt nicht. Aber wenn die LED z.B. am Port B0 dranhängt, kannst Du nicht einfach sagen

PB0 = 1;

Dann wird das Bit 0 vom Port B gesetzt und die LED müsste leuchten. Entsprechend dann

PB0 = 0;

zum Ausschalten.

Das mit der UND/ODER-Verknüpfung und der Negierung von Deinem Bitsetz-Kommando checke ich ehrlich gesagt nicht. (Liegt vielleicht auch daran, weil ich mir den C-Käse weitgehend selbst erarbeitet habe und ich von der Denke her aus Modula2 und VisualBasic komme. )

Zitat

"Standard-C-konform"

Ok, das kann sein. Ich bin mit den PIC-Prozessoren halt ein bißchen "betriebsblind" und mache es so, dass ich es verstehe und es funktioniert.

Aber jetzt checke ich das mit dem "1 << Bitnummer", warum das so gemacht ist. Danke für den Hinweis. (Wieder was gelernt). Aber trotzdem finde ich es eigenartig, dass man hier über den Shift-Befehlt geht, wenn man eigentlich schon weis, welches Bit man gerne gesetzt bzw. gelöscht hätte. Hm...

Replikator: Du bist bei dem komischen Shift-Befehl dabei, was der macht und warum das so kompliziert ist? (=> würde ansonsten gerne meine Erkenntnis hier zum Besten geben... )

Das mit den Bits manipulieren ist richtig so gemacht. Das hat den grandiosen Vorteil dass man sich nicht jedesmal überlegen muss wie der HEX, OKT oder BIN Wert für den Port aussehen muss. Ausserdem muss man sich so keine Gedanken machen was mit den anderen Bits am Port ist, denn die werden so nicht beinflusst. Genau deswegen toggelt man ein Bit z.B. mit einem XOR auch so: PORTB ^= (1 << PB5); Da der Shift Befehl mit statischen Werten wie hier vom Präprozessor gleich in die richtigen Zahlen gewandelt wird, kostet das nachher auf der CPU keinen einzigen Taktzyklus. Ist also sehr elegant diese Arbeitsweise...

"|" ist ein bitweises ODER. Ein großer Unterschied zum logischen ODER "||" oder gar zu einem UND "&" oder analog "&&"!

Je nachdem ob deine LEDs HI oder LO aktiv angeschlossen sind musst du halt eine der beiden Varianten wählen. 50/50 Chance... :]

Zitat

Original von Replikator

Genau darum hab ich das in der Art übernommen, hehe So ist man auf der sicheren Seite!

Ich nutze diese Schreibweise:

PORTx = 0xf1

nur einmal beim initialisieren der Ports.

Alles anzeigen

Naja, ich möchte hier keine Grundsatzdiskussion anfangen. Aber wenn ich schon weis, dass ich den Portausgang vom Bit 5 setzen oder löschen muss, dann kann ich ja gleich das Bit hinschreiben und muss nicht erst das Bit0 setzen/löschen und 5 mal shiften, bis es an der richtigen Position ist.
Wahrscheinlich bin ich von den PIC-Prozessoren auch zu sehr verwöhnt, weil da für jedes Portbit ein separater Befehl zur Verfügung steht, um dieses Bit an Ort und Stelle sofort zu setzen/löschen, ohne sich um die anderen Portbits kümmern zu müssen.

Zitat

Das du nochmal was von mir lernst hätte ich ja im Leben nicht gedacht...

Lernen kann man immer was....
Zu Arroganz oder Hochnäsigkeit, weil man ein paar Jahre mehr Berufserfahrung hat, gibt es eigentlich nie einen Anlass. Jeder "säuft" im Laufe seines Lebens mal ab, so dass ihn die Anderen im know-how überholen.