Hi Leute! Erstmal danke dass ihr diese Forum betreibt! Hat mir schon sehr oft aus der Patsche geholfen! ^^ Ich bin noch relativ unerfahren im Ugang mit Atmel controllern und brauche deshalb eure Hilfe. Seit einiger Zeit versuche ich für den MX5 eines Freundes mit einem separaten Steuergerät seine Klappscheinwerfer autonom anzusteuern da in der Schweiz wieder einmal des Strassenverkehrsgesetz geändert hat und er nun zusätzlich Tagfahrlichter in seinen KSW's drin hat. Ziel der ganzen Steuerung ist es im Grunde genommen mit den Klappscheinwerfern an drei Positionen zu fahren und an der richtigen Stelle das entsprechende Licht einzuschalten. So viel dazu... Mein grosses Problem: Die Hardware haben wir überprüft. Die nötigen Signale kommen passend an und die Ausgänge schalten die richtigen Komponenten (mit Testsoftware getestet -> Funktion OK). Mit dem Hauptprogramm habe ich aber rein gar keine Reaktion! Ich programmiere mit dem Atmel Studio 6.0, device ist ein Atmega8535. Für mich sieht es fast so aus, als ob die Eingänge gar nicht eingelesen würden. Habe das Programm als Word-Dokument angehängt. Gruss Creasy
:
Verschoben durch User
Im MX5 hast du doch nur einen Steuereingang und einen Meldeausgang an den Klappmotoren. Und mitten in der Bewegung des Stellmotors kannst du schlecht anhalten, die Geschwindigkeit der Verstellung ist nit vorhersagbar. Konstruiert euch lieber ein TFL in die Blinker-/Standlichtleuchten, wenn's schon ein Umbau ohne Standardteile werden soll. Für das rechtliche müßt ihr ja eh sorgen.
:
Bearbeitet durch User
Pascal Meier schrieb: > Ziel der ganzen > Steuerung ist es im Grunde genommen mit den Klappscheinwerfern an drei > Positionen zu fahren Du hast nur einen Endschalter für die Stellung oben, und einen für die Stellung unten, und scheinbar dreht der Motor immer in dieselbe Richtung. Es fehlt zumindest ein Endschalter in der Stellung "halb eingeklappt" falls das wirklich euer Ernst sein sollte, mit solchen von aussen nur als kaputt erkennbaren Scheinwerfern rumzufahren. Ohne Schaltplan mit Ein- und Ausgängen wird das niemand verstehen, und du selbst hast durch die unzureichende Dokumentation offenbar ebenfalls schon den Überblick verloren. Bloss weil es DOCX heisst, bildet das noch lange keine Dokumentation. Üblich ist bei Klappscheinwerfern als Tagfahrlicht, daß das Standlicht nicht dunkel (5W) sondern hell (21W) leuchtet, in dem dort Doppelfadenglühlapen verbaut werden und der Klappscheinwerfer zu bleibt. So habe ich es bei meinen Klappscheinwerfern umgebaut, und es war dazu nur eine Brücke im Lichtschalter zu setzen.
Mein Gott, dieser Sourcecode ist eine absolute Zumutung. Ich wollte ja helfen, aber so - nein danke! Einrückung, Kommentare, Stil und Struktur verletzen die elementaren Regeln der µC-Programmierung. Wegschmeißen, Grundlagen anlesen und von vorne anfangen ist der einzige Tip, den ich da geben kann. Sorry.
Also... Zur Hardware: Die Klappscheinwerfer wurden so angepasst, dass die TFL stirnseitig im Scheinwerfer montiert wurden. Sprich die Positionen sind neu: KSW geschlossen / KSW auf Stellung TFL (irgendwo zwischen geschlossen und halb offen) / KSW offen. Die Scheinwerfer und alles drum und dran, also die kpl. Hardware wurde bereits so angepasst dass es funktioniert. Die Stellmotoren werden über je zwei Relais so bestromt, dass sie in beide Richtungen fahren können. Die Position der Stellmotoren wird über Schleifkontakte an einer Messingscheibe detektiert. Diese wurde so angepasst dass die dritte Stellung (Stellung für TFL) nun auch existiert. Die Eingänge aller Schalter liegen an Port A an. Die Eingänge für die Signale der Stellmotoren liegen an Port C an (je zwei PIN pro Motor, detektion per Signale 01 00 10 ). Die Relais werden per Transistoren an den Ausgängen (kompletter PortB) geschaltet. Besten Dank schon mal an alle die sich bereits die Mühe gemacht haben den Beitrag anzusehen ;-)
Ich bin mir bewusst dass der code nicht allzu professionel daher kommt… Aber im Grunde genommen war ich der Meinung dass uns der alte Zeltner das schon ordentlich beigebracht hat in der Ausbildung ;-) Naja sei's drum. Ich werde mich bemühen das ganze zu strukturieren und es dann bei Gelegenheit nochmals posten. Danke jedenfalls dass du zumindest die Absicht gehabt hast zu helfen... Gruss PM
PascalMeier schrieb: > dass uns der alte Zeltner > das schon ordentlich beigebracht hat in der Ausbildung Nein hat er nicht. Es ist eine Katastrophe. So kurz vom Überfliegen: > while(PINC&0x0f<<15) & hat Präzedenz vor <<. Also ergibt der Code keinen Sinn. Aber selbst wenn es umgekehrt wäre, würde der Code auch keinen Sinn ergeben. Du solltest es dir nochmals überlegen, ob du an sicherheitskritischen Teilen rumschraubst und damit mein Leben gefährdest.
bake schrieb: > hilf doch mal lieber anstatt zu jammern und meckern. Nicht bevor der Threadstarter den Code, den man sicher in 100 Zeilen abhandeln könnte, neuschreibt. Der Code ist eine Zumutung.
Kotzi schrieb: > den man sicher in 100 Zeilen abhandeln könnte Eher in 20 relevanten Zeilen. Pascal Meier schrieb: > Die Eingänge aller Schalter liegen an Port A an. So was nenne ich Dokumentation. Spitze ! > Die Eingänge für die Signale der Stellmotoren liegen an Port C an (je > zwei PIN pro Motor, detektion per Signale 01 00 10 ). Und wie wollt ihr die Mittelstellung für TFL detektieren ? Ich dachte, ihr hättest dafür gesorgt. 00 ist sicher nicht die Mittelstellung, denn 00 gab es vorher schon. > Die Relais werden per Transistoren an den Ausgängen (kompletter PortB) > geschaltet. Warum greift ihr dann immer weider auf dieselben Bits zu, egal ob ihr rauf oder runter fahren wollt ? Steckt dort der Programmfehler ?
PascalMeier schrieb: > Ich bin mir bewusst dass der code nicht allzu professionel daher kommt… > Aber im Grunde genommen war ich der Meinung dass uns der alte Zeltner > das schon ordentlich beigebracht hat in der Ausbildung ;-) Nicht wirklich. Ich empfehle erst mal das Erstellen eines Zustandsautomaten. Der ist perfekt um die Logik erst mal vorab festzulegen, noch ehe man eine Zeile Code schreibt. Steht die Zustandsmaschine, dann wird codiert, aber nicht vorher. http://www.mikrocontroller.net/articles/Statemachine Für die Tastenentprellung würde ich auf den PeDa Entprellcode zurückgreifen, aber da gibt es mehrere Lösungen. Allerdings: sicher nicht so, wie du das implementiert hast - das ist ziemlicher Mist. Bei einer Zustandsmaschine, die automatisch eine Taktung ins Programm einbringt, kann man diese Taktung recht zwanglos zur Entprellung gleich mitbenutzen. > Naja sei's drum. Ich werde mich bemühen das ganze zu strukturieren und > es dann bei Gelegenheit nochmals posten. Bei dem Code bringt strukturieren auch nicht viel. Den Code kannst du getrost wegwerfen und verlierst dabei nichts. Viel zu umständlich, viel zu kompliziert, viel zu unübersichtlich. Kein Wunder, dass du dabei keine Fehler mehr siehst bzw. findest. Das geht zb mit einer Zustandsmaschine wesentlich eleganter und übersichtlicher. Und wenn man sich die auf dem Papier in Form einer Zeichnung (wie im Link) vorbereitet, dann versteht man sie auch problemlos bzw. kann die Logik bereits testen, ohne 1 Zeile Code geschrieben zu haben. Und PS: in einer derartigen Skizze arbeitet man nicht mit Pinbezeichnungen sondern mit logischen Konstrukten wie zb 'Endschalter oben zu' oder 'Endschalter oben offen' (genau deswegen kann man die nämlich vorab auf dem Papier testen, indem man einfach mal Szenarien durchspielt. Setz dich hin, leg eine Münze in den aktuellen Zustand und denk dir was aus, was passiert. Dann arbeitest du die Zustandsmaschine ab und siehst nach was passiert bzw. welche Aktionen auf deinem Papier dafür vorgesehen sind. Sei auch fies und denk dir Szenarien aus, in denen der Benutzer Schalter betätigt, während ein Motor gerade verfährt. Wenn das auf dem Papier alles zufriedenstellend behandelt wird, dann bist du soweit das Programm dafür zu schreiben)
:
Bearbeitet durch User
Hallo. Soweit ich weiß, gibts sowas fertig. Hab mal so eine Steuerung in einem amerikanischen RX-7-Forum gesehen. Da hatte man ein Poti für die gewünschte Stellung. Christian_RX7
OK. Nochmals Danke für die geleistete Hilfe. Auch wenn es euch überraschen mag, das ganze ist aus einem Flussdiagramm zu einem Struktogramm, zu dem Gebrösel das ihr mit so viel Hingabe zerreisst geworden... ;-) Da ihr aber definitiv die cracks seid und nicht ich, nehme ich mir euren Rat zu Herzen und versuch das ganze nochmals neu aufzubauen. Halt eben diesmal strukturiert. Danke auch für den Tipp mit dem Unsinn in der while-Schlaufe: while(PINC&0x0f<<15) Schönen Abend noch und Gruss P.M.
Pascal Meier schrieb: > OK. Nochmals Danke für die geleistete Hilfe. Auch wenn es euch > überraschen mag, das ganze ist aus einem Flussdiagramm zu einem > Struktogramm, zu dem Gebrösel das ihr mit so viel Hingabe zerreisst > geworden... ;-) Das zeigt mir eigentlich nur, dass dieses ganze Flussdiagramm, Struktogramm, PAP-Gedöns nicht viel taugt, sobald die Dinge ein wenig größer werden. Denn wenn dieses Flussdiagramm Mist ist, ist auch das entstehende Programm Mist. Es ist schon ok, vorab seine gedanken zu ordnen. Und es ist auch ok derartige Diagramme zu zeichnen. Das Problem ist nur, dass man diese Diagramme nicht ordentlich vereinfachen kann, weil man in dem ganzen Gewusel von Linien, die von einer Box zur nächsten gehen, keine größeren Strukturen mehr erkennen kann, die man zusammenfasst. Und genau so sehen dann nachher auch die Programme aus. Zumindest bei unerfahrenen Programmierern.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.