Moinsen Ich bastel mir grade ne kleine Platine für meine Octavia, die sich bisher um den Wischwasserstand, Bremsbelägekontakt, Heckscheibenheizungstimer kümmert... Nun möcht ich noch den Blinker dazu - also das er wenn ich ihn antippe 3mal blinkt und wenn ich ihn halt beim loslassen auch sofort aufhört - natürlich soll die eine seite auch sofort aufhören wenn ich auf der anderen blinke... Im gegensatz zu allen Schaltungen die ich bisher gefunden habe, möcht ich aber nicht die Vorhandenen Kabel zerschneiden sondern meine Platine nur parallel zum Blinkerhebel klemmen... so erspar ich mir Probleme bei TÜV - denn der mag es garnicht wenn man was dazwischen klemmt - hat aber nix dagegen wenn man was dazuklemmt... ;) Ich hab also einen ATMega16 für die Aufgabe gewählt - denn wer weiß, was noch alles dazu kommt... :D An Leitungen im Auto hab ich: 1. vom Blinkerrelais zur Blinkerhebel (schon die fertigen Blinkerimpulse, wenn geschaltet... Der Blinkerhebel verbindet also nur die Lampen mit dem Relaiskontakt) 2. Blinkerleitung Rechts 3. Blinkerleitung Links zu dem µC geht einmal die Blinkerleitung Links und einmal die Blinkerleitung Rechts... und weg geht auch die Blinkerleitung Links bzw. die Blinkerleitung Rechts... Frage ist jetzt halt nur, wie setze ich das um? Er muss ja erkennen, wie lange ich wann halte... und alles... Währe cool wenn euch dazu etwas einfällt... denn ich stehe da grade leider total aufm Schlauch... Achja, ich programmiere mit BascomAVR - also währe es absolut genial wenn ihr jetzt nich Assembler postet würdet... Weil davon hab ich bisher keine Ahnung... ;) Also, besten Dank für eure Hilfe - ich hoffe ja einfach mal das ihr mir mal wieder helfen könnt!!! bye, Micha!
:
Verschoben durch Moderator
ich denke, dass es etwas schwieriger sein wird, einfach "etwas dazu" zu hängen/schalten. als erstes müsstest du wissen, wie die lampen am relais angeschlossen sind: wird einfach ein +12V beim leuchten angelegt und beim nicht-leuchten die leitung offen gehalten oder wird die leitung auf 'minus' gezogen, oder sind die lampen am 'plus' fix und mit dem relais werden sie auf 'minus' gezogen; für diese variante, brauchst du aber einen grösseren lasttreiber (MOSFET). wenn du aber die relais ansteuern willst, musst du ebenfalls guckn, dass du keinen kurzen machst, wenn du deine schaltung dazu hängst: ist halt so, wie wenn du aus einer stecktose ein kabel in die andere steckdose führst: es kann gut gehen, aber auch nicht rauch... ohne schaltplan, oder wissen, wie was in deinem Octavian verbunden ist, sind uns die hände zum helfen gebunden. ich würde an deiner stelle, die steuerdrähte an das relais mit einem stecker halt doch auftrennen, deine schaltung dazwischen schalten, und wenn du zu Tüv musst, nimmste einfach deine schaltung für den besuch raus.
Ich möchte sie aber nicht rausnehmen... Mal davon abgesehen, das ich ja versucht habe es zu erklären - hier nochmal... Stark vereinfacht sieht es so aus: O-------[RELAIS]-----[Blinkerschalter]------[Blinker_Links]-----O + `------------[Blinker_Rechts]--´ - Also es kommt halt das Pulsierende Signal vom Blinkerrelais beim Blinkerschlater an und dieser schaltet das dann auf die Blinkerlampen für rechts oder Links... Alternativ gibt es noch Warnblinklicht - aber das is direkt im Blinkerrelais (Blinkerrelais und Warnblinklichtschalter sind zusammen)....
Das hatten wir doch eben...? http://www.mikrocontroller.net/forum/read-1-113815.html#113815 http://www.mikrocontroller.net/forum/read-1-271626.html#271626 ...
Moinsen Hannes... Hab die beiden Links von dir grade mal komplett gelesen - problem ist nur das beide nicht wirklich weiterhelfen... Der erste ist zwar vom Prinip her schon sehr hilfreich und hat mir auch einige neue Aspeckte was die Programmiersprachen angeht eingebracht, aber leider is die Lösung nicht die von mir angestrebte... ;) Also, mal ganz von Vorne... :D Stromlaufplan und Schaltplan häng ich an... Wobei bei letzterem nur die Sachen Interessant sind die von den Kontakten Blinker weggehen... Die anderen Sachen sind alle für andere Funktionen... Nun zum Blinker selbst... Genauso wie in dem Thread von Stephan T. sieht auch bei mir das Signal aus (kein Wunder denn er fährt einen Golf4 und ich einen Octavia - der auf dem Golf4 basiert)... Also wie dort schon geschrieben läuft wird am Blinkerschalter das Pulsierende Signal vom Blinkerrelais nur noch auf die Glühlampen geschaltet... Natürlich möchte - wegen dem Tüv und der Versicherung darf ich es auch nicht anders - die Leitungen nicht trennen... Also auch nur horchen und je nachdem Eingreifen (so wie bei Stephan zum Schluss ja auch)... Zu der Sache mit dem Tüv... Einer meiner Mituser im Octavia-Forum war letztens mit seiner Schaltung beim Tüv (möchte diese aber verkaufen und das zu einem Preis den mir das ganze nicht wert ist... daher mein selbstbau) und hat dort erfahren das vom Tüv aus nichts gegen diese Schaltung spricht, so lange bei einem Ausfall noch das normale Blinken möglich ist und nichts an der Blinkfrequenz geändert wird... Da dies bei meinem Vorhaben und meiner Art das umzusetzen kein Problem ist, sollte auch der Tüv keine Probleme machen... Der Tüvler hatte wohl extra nochmal auf Nachfragen in seinen Vorschriften geguckt und somit sollte das absolut kein Problem sein egal zu welchem Tüv man in D fährt!! Nun wieder zurück... Im Gegensatz zu Stephan möchte ich jedoch nicht immer min. 3mal Blinken... Folgende Situationen sollen erkannt und geschaltet werden können: 1. Blinkerhebel wird gehalten (z.B. abbiegen) --> keine Reaktion vom µC 2. Blinkerhebel wird für <500ms angetippt (z.B. Spurwechsel auf der Autobahn) --> Blinker wird für 3 Impulse gehalten 3. Blinkerhebel wird für >500ms angetippt (z.B. bedanken bei anderen Verkehrsteilnehmern fürs reinlassen oder so) --> keine Reaktion vom µC Sollte alles nicht schwer zu erkennen sein, da das Blinkersignal ja direkt mit High beginnt und ein Impuls länger wie 500ms ist... (laut StVZO ist eine Blinkfrequenz von 1Hz bis 1,5Hz vorgeschrieben - währen ja min. 750ms zwischen zwei Impulsen) Nur wie zum Teufel programmier ich das? Mir würde ja die Theorie schon reichen (Programmlaufplan) aber ich finde einfach keinen Anfang... Denn wenn man den Blinkerhebel innerhalb der 500ms wieder loslässt soll das Relais natürlich sofort wieder gehalten werden - also währe ein "waitms 500" schonmal absolut unpassend an der Stelle, da dann ja evtl. ein Aussätzer im Blinksignal währe... Mal davon abgesehen, das ja alle anderen Aufgaben vom µC solange zurückgestellt werden müssen, damit auch wirklich alle Zeiten eingehalten werden denn jede Zeile sorgt ja wieder für eine Verzögerung... Zum Halten für die 3Impulse, das würd ich nur ungern über eine Zeitkonstante machen... Denn ich habe ja eh den Eingang an dem der Impuls anliegt (bzw. zwei Eingänge - links und rechts) und kann somit auch zählen bis die Entsprechende Anzahl an Impulsen erreicht ist! Zu dem Gedanken der in dem anderen Thread schon kam, was passiert wenn man in die andere Richtung blinkt aber die Lampen in der Pegel grade auf LOW ist und es somit nicht erkannt werden kann... Das is ja egal... denn wenn der Pegel auf LOW ist sind die Birnen ja eh aus... Sobald der Pegel dann auf HIGH umspringt, wird es ja erkannt und der Blinker der vom µC gehalten wurde geht aus - dafür geht er dann in die andere Richtung an - je nachdem wie lange der Hebel gehalten wurde - oder auch nicht... Gibt es Eigentlich ein gutes Programm zum Zeichnen von Programmlaufplänen? So, hoffe ich hab das jetzt gut erklärt bekommen und hoffe das noch jemand Interesse daran findet oder mich zumindest etwas unterstützt... Besten Dank - schon alleine dafür das ihr euch den ganzen Text hier durchgelesen habt... Micha!
Zitat: 2. Blinkerhebel wird für <500ms angetippt (z.B. Spurwechsel auf der Autobahn) --> Blinker wird für 3 Impulse gehalten 3. Blinkerhebel wird für >500ms angetippt (z.B. bedanken bei anderen Verkehrsteilnehmern fürs reinlassen oder so) --> keine Reaktion vom µC Zitat Ende Daraus ergibts sich dass garkein Controller benötigt wird und auch keine Schaltung. Das macht natürlich sowohl die Schaltung als auch das Programm besonder einfach und sogar die Programmiersprache ist völlig egal. Also Mega16 einfach in die Schublade legen bis er irgendwann mal für was Sinnvolles gebraucht wird. bye Frank
Wieso wird keiner Benötigt? Irgendwer muss ja dafür sorgen, das der Blinker für die 3Impulse gehalten wird...
nö, da steht bei kleiner 500ms kein Controller und bei grösser 500ms auch nicht. Das deckt doch Alles ab, oder? bye Frank
Hallo Micha. Ich sehe in dem Wechseln von Links nach Rechts oder umgekehrt bei Blinkgeber aus, schon ein Problem, da nicht erkannt wird, ob die andere Richtung getastet wurde. Die einzige Möglichkeit zu erkennen, ob der Hebel betätigt wurde ist, das er bei Blinkgeber an immer noch betätigt ist und das ist nicht umbedingt gewollt. Ich hab auch schon überlegt, ob es eine Hardwarelösung gibt, um die Blinkschalter doppelt zu nutzen, also einmal normal für die Blinker und dann noch für die Schaltung, aber noch keine wirkliche Lösung gefunden. Also überlegen und warten, ob noch jemand eine Antwort auf unsere Fragen kennt. CU Bernd
@Frank: Wer lesen kann ist klar im Vorteil.<kopfschüttel> Wie wäre es mal mit konstruktiven Vorschlägen. CU Bernd
> Achja, ich programmiere mit BascomAVR - also währe es absolut genial > wenn ihr jetzt nich Assembler postet würdet... Nunja, von BASCOM habe ich keine Ahnung. Daher ist es wohl besser, wenn ich mich etwas zurück halte. Einen funktionierenden Algorithmus für deinen Wunsch kann ich dir nicht geben, denn (wie schon genannt) das Betätigen des Blinkschalters wird nur in der Ein-Phase des Blinkgebers erkannt. Da ich selbst kein Interesse an einer solchen Schaltung habe (auch nicht an Carmodding allgemein), sehe ich auch keinen Grund mehr, meine Zeit für sowas zu verplempern. Anfangs ging es mir darum, zu zeigen, dass solch einfache Steuerungen mit Assembler einfacher realisierbar sind als mit BASCOM. Inzwischen habe ich es aber aufgegeben, mich mit BASCOM-Anhängern anzulegen. Soll jeder so programmieren wie er mag. Ich ziehe aber ASM mit einer soliden Zeitbasis dieser Warteschleifenprogrammierung (waitms 500) vor. ...
Wieder ein sehr gutes Beispiel, daß man mit der unsäglichen Warteschleifenprogrammierung nicht vernünftig strukturieren und programmieren kann. Leute, schmeißt doch den Warteschleifenprogrammierungsquatsch schnellstens über Bord. Dann ist die Lösung ganz einfach: Man fragt alle 10ms die Eingänge ab und zählt in je einer Variable, wie lange sie aktiv waren. Erreicht eine Variable 50 sind die 500ms um. Das 10ms-Raster kann man gleichzeitg dazu nehmen, die Zeit für 3 * Blinken zu zählen. Da hier nichts anderes zu tun ist, kann man ausnahmsweise doch eine Warteschleife nehmen, aber nur um die 10ms zu erzeugen. Aber besser man nimmt nen Timer, damit im MC noch andere Sachen hinzugefügt werden können. Peter
Hallo Peter. Damit haben wir aber immer noch nicht das Problem des "sauberen" Signals gelöst und der Blinkschaltererkennung nach dem ersten Einschalten. CU Bernd
"Damit haben wir aber immer noch nicht das Problem des "sauberen" Signals gelöst" Warum, wenn die An-Zeit > 500ms ist, dann gehts doch. Man muß allerdings alle 3 Anschlüsse auswerten, d.h. auch den Ausgang des Blinkgebers, damit die Blinkpausen nicht als Losgelassen fehlinterpretiert werden. Man kann auch weniger als 10ms Zeitraster nehmen. Die 10ms können ja bedeuten, daß der Taster schon 10ms losgelassen wurde, ehe man das Relais für das 3* Blinken zuschaltet. Diese 10ms Auszeit dürften aber kaum stören. Das Relais wird in jedem Falle erst nach erkanntem Loslassen eingeschaltet, sonst könnte man ja das Loslassen nicht erkennen. Peter
Moinsen Jungs... Also um ganz ehrlich zu sein, von Bascom bin ich auch nicht mehr wirklich angetan... Aber ich kann mit den Hochsprache einfach wesentlich besser umgehen wie mit Assembler - könnte daran liegen das ich seit Jahren PHP und Perl programmiere... Das die Warteschleifen nicht perfekt sind, is mir auch klar... daher sach ich ja das muss ohne... Eine kleine Bitte noch an alle, die keine Lust auf Konstruktive Beiträge haben: Lasst das posten doch bitte gleich sein - bringt euch und mich nicht wirklich weiter... erst recht nicht wenn die Beiträge darauf basieren, das ich die Wörter "vom µC" vergessen habe... augenroll Also, zu dem beim aus nicht erkannt... ich denke das is ein Bug mit dem man noch am ehesten leben kann - sollte aber natürlich auch nicht sein... Man könnte ja das Blinkerrelais so umbauen, das es nicht zwischen 12V und GND schaltet sondern zwischen 12V und 1V... Halt zwischen 12V für Lampe an und einer Spannung, bei der die Lampen noch nicht leuchten - so könnte man auch diesen Zustand mit dem µC ermitteln - Oder man baut den Blinkerhebel um - also die strippen ab und ein an jeden Ausgang ein Doppelrelais wofür dann ein Kontakt für die Originalblinkerschaltung ist und ein Kontakt für den µC - so ist es möglich noch zu blinken wenn die Schaltung ausfällt und es ist auch möglich mit dem µC jeden Schaltungszustand zu erkennen... Aber langsam werden es dann doch irgendwie ein paar relais zu viel und ein wildes geklapper... XD bye, Micha...
@Micha, also nochmal ganz langsam zum Mitschreiben: Blinkgeber, Lampe 12V 0V Losgelassen 12V 12V Gedrückt 0V 0V Gedrückt Peter
Hallo. Ich habe jetzt das "saubere" Signal hingekriegt, wenn auch mit ein paar ms Verzögerung beim Ausschalten, aber ich glaub damit können wir leben. Ich habe einfach eine Diode in Sperrrichtung und parallel dazu einen Elko an die Leitung zum Blinkschalter gebaut und es funktioniert. Man muss bloss noch die genaue Grösse des Elkos rausfinden, dann ist das Ganze kein Prob mehr. CU Bernd
@Peter: Das is ein Gedanke - aber ich meine wenn er losgelassen ist, haben wir auch nur Masse - werd ich morgen mal nachmessen im Auto...
@Bernd, "Ich habe jetzt das "saubere" Signal hingekriegt" Wenn ich bloß wüßte, wovon Du sprichst. Für mich ist alles eindeutig zu erkennen und nirgends ein Signal schmutzig. Peter
Mahlzeit... @Peter: Ja, du hast recht - wie ich so am messen war wurde mir auch irgendwie klar, das du rechthaben musst - sonnst würde der ganze Blinker ja nicht funzen... XD Blinkgeber, Lampe 12V 0V Losgelassen 12V 12V Gedrückt 0V 0V Gedrückt Nur in wieweit uns das jetzt beim antipppen in die andere Richtung in der Aus-Fase weiterhilft weiß ich noch nicht... bye, Micha...
@Peter: Ist doch ganz einfach, wenn der Blinkerhebel betätigt wird, egal welche Seite, ist das erste Signal was kommt HIGH, danach gehts im Blinkertakt, LOW HIGH LOW HIGH...usw. Wenn man jetzt in der LOW-Phase die andere Seite betätigt, wird das nicht erkannt, wie auch, da der Blinker im ausgeschalteten Zustand ja auch LOW ist. Die Problemlösung wäre, wenn das Signal nicht pulsiert, bzw. von HIGH auf LOW usw. wechselt, sondern nur das Highsignal durchkommt, wenn der Schalter betätigt wird, das ist dann ein sauberes Signal mit dem man vernümpftig arbeiten kann. CU Bernd
@Bernd "Wenn man jetzt in der LOW-Phase die andere Seite betätigt, wird das nicht erkannt, wie auch, da der Blinker im ausgeschalteten Zustand ja auch LOW ist." Ich sehe immer noch kein Problem, wenns aus ist, ists doch egal. Es gibt bestimmt exate Vorgaben, aber gefühlsmäßig würde ich sagen, die Pausen sind wesentlich kürzer, als die Leuchtphasen, unter 300ms. Die Reaktionszeit eines Menschen ist aber über 300ms, d.h. innerhalb der Betätigungszeit gibt der Blinkgeber wieder Saft und dann kann man das auswerten. Peter
Hallo Peter, Blinkgeber, Lampe 12V 0V Losgelassen 12V 12V Gedrückt 0V 0V Gedrückt? oder vieleicht doch losgelassen? was meinst Du denn, was an der Lampe anliegt, wenn der Blinkgeber 0V liefert, und der Schalter nicht gedrückt ist? Und übrigens, auch wenn die Reaktionszeit eines Menschen über 300 ms liegt, so kann er trotzdem einen Kontakt kürzer als 300 ms betätigen, dazu ist nämlich gar keine Reaktion nötig, nur Aktion. Gruß, Heiko
Ich denke, dass ich eine Lösung gefunden habe, siehe Anhang. Aktiviert wird das Nachblinken durch kurzes Antippen des Blinkschalters. Man muss den Blinkschalter noch während der ersten Hellphase wieder ausschalten, wird die erste Dunkelphase erreicht, wird das Nachblinken sofort deaktiviert. Auch durch Gegenblinken oder Warnblinken wird das Nachblinken deaktiviert. Die Installation des KFZ wird nicht aufgetrennt. Zum Ansteuern werden die Leitungen: 49a (Blinkgeber-Blinkschalter) L (Blinkschalter-linke Seite) und R (Blinkschalter-rechte Seite) benötigt. Die Anschlussbelegung des Tiny12 ist im Quelltext beschrieben. Das gesamte Modul benötigt vom KFZ folgende Leitungen: Plus 12V (Klemme 49 am Blinkgeber) 49a vom Blinkschalter/Blinkgeber L vom Blinkschalter R vom Blinkschalter GND (Fahrzeugmasse, 31) Die Arbeitskontakte der Relais müssen +12V (Klemme 49 vom Blinkgeber) mit den Kontakten L bzw. R des Blinkschalters verbinden. Das Nachblinken übernimmt der AVR. Die 5V-Versorgung des AVRs sollte mit einer KFZ-tauglichen Schaltung erfolgen, ein 7805 reicht dazu nicht, der wird ohne weitere Schutzmaßnahmen von Störspitzen zerstört. Die Parameter: - Nachblinkperiode (und damit die Frequenz), - Anzahl der Blinkimpulse, sowie die - Sperrzeit (Verhindern von Nachtriggern) und die - Entprellzeit lassen sich im Quelltext einstellen. Der Tastgrad beträgt 50%, Hellphase und Dunkelphase sind also gleich. Das Programm ist für den Tiny12 und hat 190 Bytes (95 Befehle) in Assembler. Der Quelltext ist kommentiert. ...
Angehängte Dateien:
-
blink01.jpg
96 KB
Geprüft wurde das Programm mit einer Testschaltung auf Steckbrett. Dabei wurde der ISP-Brenner und die "Brennzange" gleich als Stromversorgung "von oben" missbraucht. Ich halte es für möglich, dass die Relais durch entsprechende Profets (High-Side-Switch) der BTS-Serie ersetzt werden können. Ich habe allerdings nicht recherchiert, ob die Ausgänge der Profets es vertragen, dass Spannung anliegt, ohne dass der PROFET selbst angesteuert ist. Ich denke aber, dass das gehen müsste. Konstruktive Kritik am Programm ist willkommen... ...
Hi Hannes, wenn ich den Code richtig verstehe, kann man das Nachblinken nicht vorzeitig ausschalten, wenn man lediglich in der Dunkelphase den Blinker gegenläufig betätigt?! Gruß Micha
Hast du es mit Hardware überprüft? Oder ist es eine logische Schlussfolgerung bei der Analyse des Programms? Das Abschalten in der Dunkelphase funktioniert meiner Meinung nach. Das Abschalten in der Hellphase (des AVRs) funktioniert im Testaufbau (noch) nicht, da noch keine Rückwirkung der klappernden Relais auf die Klemmen L und R realisiert ist. Denn ein angezogenes Relais legt ja +12V (49) auf die Klemme L bzw. R, was für den AVR so aussieht, als hätte jemand L oder R betätigt. Wird dann (von Hand) die andere Richtung betätigt, so sieht der AVR 49a, L und R gleichzeitig auf H und schaltet ab. Das Ausschalten sollte also in der Hellphase und in der Dunkelphase des Nachblinkens möglich sein. ...
Das ist ja lustig... (oder traurig?) 13 Downloads des Quelltextes innerhalb 10 Stunden 18 Downloads eines nichtssagenden Fotos innerhalb einer Stunde... Man scheint sich also inzwischen auch hier lieber ein buntes Bildchen (100kB) anzuschaun als einen Text (11kB) zu lesen... ;-) ...
Hallo Hannes. Erstmal muss ich dir mal herzlich Danken, das du dich hinsetzt und ein Problem versuchst zu lösen, das eigentlich nicht deins ist, RESPEKT. Ich werde vielleicht noch heute, bzw, im Laufe der Woche, dein Programm mal hardwaremässig testen. Vielleicht (hoffentlich) ist es ja der Problemlöser. CU Bernd
Nunja, ich bin davon nicht dümmer geworden. Aber Dank gebührt vor allem Peter. Seine Hinweise sollten auch den eingefleischten BASCOMer in die Lage versetzen, das Problem zu lösen. Allerdings sollte man dazu die Wait-Funktion meiden. ...
Ich habe noch etwas damit herumgespielt und Dioden von den Ausgängen zu den Eingängen eingebaut, die die Rückwirkung der Relais auf die Eingänge nachbilden. Dabei ist mir aufgefallen, dass doch noch etwas faul war: Der Nachblinker blinkte beim Ausschalten auf der Gegenseite weiter. Das zusätzliche Löschen des Blinkzählers (warum habe ich das nicht gleich gemacht, in meinem "Manuskript" (auf Papier) steht es ja drin) schafft nun Abhilfe. Allerdings ist das Manuskript viel umständlicher ausgefallen als der jetzige Code. Ich bin aber sicher, dass man die Aufgabe noch eleganter lösen kann. Nun sind es 96 Worte, also 192 Bytes und 16 benutzte Register (eigentlich nur 12). Eigentlich könnte man noch die SREG-Sicherung entfernen, denn beim Auftreten des Timer-Interrupts ist das Hauptprogramm schon lange fertig und schläft bereits. Die ISR kann dem Hauptprogramm also keine Flags verwurschteln. Ich lasse die SREG-Sicherung aber "anstandshalber" drin. @Michael M.: Danke für deinen Hinweis, ich denke, dass du das hier genannte Problem gemeint hast. ...
So, erstmal danke an Hannes... Hab mir den Quelltext grade saugt und auch schon überflogen... sieht klasse aus! Werd jetzt mal gucken, das ich den auf meinen ATMega16 umgesetzt bekomme - denn der hängt ja schon im Auto, warum also noch einen einbauen? ;) Was mir allerdings noch nicht so ganz gefällt is die Tatsache, das der µC die Blinkimpulse generiert - das wird der Tüv nicht mögen (sollt er es überhaupt merken)... Aber ich denke mal er findet es niemals raus... Find es aber schon klasse, das hier Leute wirklich so 100% uneigennützig mithelfen und sogar nen komplettes Programm schreiben und dann auch noch so super kommentieren! Das is wirklich nicht überall so - Hut ab!! Gruß, Micha (der jetzt endlich dauerhaft I-Net hat und nicht mehr nur auf Arbeit oder bei nem Kameraden surfen kann)
Nunja, 'n Tiny12 kostet bei Reichelt 1,25 Euro. Warum sollte ich das mit einem Mega16 machen? Wegen Umsetzen auf vorhandenen Mega16: Das, was jetzt in der Mainloop steht, wird nur einmal nach jedem Interrupt aufgerufen (danach wird bis zum nächsten Interrupt gepennt). Es lässt sich also ohne Weiteres mit in die ISR aufnehmen. Wenn man dann noch einige Variablen in das SRAM auslagert, bleiben noch genug Register für andere Aufgaben übrig. Das gesamte Blinkprogramm kann dann in einem Timer-Interrupt (Timer0-Überlauf, Timer1-Compare oder Timer2-Überlauf) als eigenständiger Task laufen.Die gesamte Routine kommt mit weniger als 100 Takten pro Durchlauf aus und rennt alle 10ms. Das macht bei 1MHz Prozessortakt weniger als 1% Prozessorbelastung. Es bleiben also noch 99% Rechenzeit für andere Tasks übrig. Bei vernünftiger Verwaltung von Registern und SRAM merkt die restliche Software im Mega16 diesen Job garnicht. ...
Moin Hannes... Ich wollte dir das nicht zum Vorwurf machen... Hast schon recht - aber du wirst es ja denk ich genauso sehen, das der ATMega16 das ruhig auch noch mit machen darf - oder? ;) Aber, sagmal könntest du den Programmlaufplan auch nochmal mit posten? Denn mit dem Assembler code alleine komm ich grade nicht wirklich klar - obwohl ich den anderen Thread und auch so ziemlich alles was darin an Docus und co ist gelesen habe... Oder ich bin grade einfach zu verplant... gradevonanachtschichtkomm bye, Micha...
Einen Programmablaufplan gibt es nicht wirklich. Es ist ein "Schmierzettel" (Bleistft), auf dem in Textform bzw. Tabellenform die verschiedenen Eingangszustände aufgelistet sind und die Schlussfolgerungen vermerkt sind, was bei jedem Zustand zu tun ist. Als "Zustand" werden die 5 benutzten Bits gewertet, also die 3 Eingänge und die 2 Ausgänge. Damit ich nicht alle 32 möglichen Zustände auswerten muss, habe ich das noch etwas optimiert. So sind z.B. die übrigen Bits nicht mehr relevant, wenn 49a auf L geht. Denn 49a geht nur dann auf L, wenn der Blinkschalter "zu lange" betätigt wurde oder wenn der Warnblinker aktiviert wird. Sicher hätte ich die "Zustände" auch mittels Formeln der Schaltalgebra notieren können, aber darin bin ich nicht besonders fit. Auch fehlen mir auf dem PC im normalen Textmode die erforderlichen Zeichen. Das Grundmuster, wie die Zustände zu werten sind, hat ja Peter schon weiter oben aufgelistet. In den Kommentaren zu meinem Quelltext ist das viel genauer erklärt als in meinem "Manuskript". Es ist aber auch möglich, dass du mit diesem Programmierstil noch Verständnisprobleme hast. Es geht dabei nicht um die Sprache, sondern um den Stil. Ich programmiere hier nicht Aktionen, die mit Warteschleifen aneinander gereiht werden, so wie das viele Einsteiger hier machen. Ich programmiere mir zuerst mittels eines Timer-Interrupts eine solide Zeitbasis, sozusagen den "Herzschlag" des Programms. Dies ist in diesem Falle 100Hz bzw 10ms. In diser ISR lese ich den Zustand ein und entprelle ihn. Das Entprellen ist nötig, da durch die Trägheit von Relais und Lampen zwischendurch Zustände auftreten können, die eigentlich nicht der Realität entsprechen. Das Entprellen der Einzelbits (wie ich es sonst mit der Entprellung nach Peter D. mache) wäre hier störend, weil sie verzögerte Bits auch verzögert übernimmt. Deshalb entprelle ich hier den gesamten Zustand und übernehme Änderungen erst nach einer gewissen (einstellbaren) Zeit. Eine richtige saubere Entprellung ist das auch noch nicht (stelle ich gerade fest!), dazu müsste ich auch den Neuwert sichern und erst übernehmen, wenn er lange genug stabil bleibt. Werde ich bei Gelegenheit noch ändern, geht aber erstmal auch so. Nun werden "Wartezeiten" für die Sperrzeit und für das Erzeugen der (Nach-)Blinkimpulse benötigt. Ein "WAIT xyz" würde aber das gesamte Programm anhalten. Sowas tut man nicht. Also nutze ich dafür Software-Timer (Register, Variablen vom Typ Byte), die in der Timer-ISR verwaltet werden. Die Sperrzeit wird nur dann runtergezählt, wenn sie nicht schon Null ist (Überlauf ins Negative vermeiden). Jeder Programmteil, der die Sperrzeit setzen oder nachsetzen muss, setzt sie einfach auf den Startwert. Jeder Programmteil, der während der laufenden Sperrzeit "warten" muss, der wartet nicht, sondern wird einfach übersprungen. Vielleicht kann er ja beim nächsten mal ausgeführt werden. Ähnlich ist es mit dem Blinktaktgeber. Viele Einsteiger würden programmieren: - Licht an, - Warteschleife, - Licht aus, - Warteschleife... Mach' ich aber nicht. Ich habe ja schließlich die Timer-ISR alle 10ms. Darin zähle ich einfach (über einen Vorteiler) den Blinkzähler runter und nutze das untere Bit des Blinkzählers als "Blinkzustand". Damit der Blinker aber auch ausgeschaltet werden kann, mach' ich das nur, wenn der Blinkzähler nicht Null (abgelaufen) ist. Soll geblinkt werden, dann wird der Blinkzähler einfach auf die doppelte (Pausen zählen ja mit) Anzahl der benötigten Blinkimpulse gesetzt, und die ISR macht den Rest. Muss das Blinken abgewürgt werden, dann ist nur der Blinkzähler zu löschen (was ich in der ersten Version vergessen hatte). Man kann Sperrzeit und Blinkzähler auch als "Zustände" betrachten. Sie haben dann den Wert "inaktiv" (abgelaufen) oder "aktiv" (mit realem Wert bis zum Ablauf). Eine Wartezeit wird eben nicht dadurch realisiert, dass man "wartet", sondern dadurch, dass man stattdessen etwas anderes (sinnvolleres) tut. Ich bin sicher, dass man diesen Programmierstil auch mit einer Hochsprache realisieren kann, ich selbst ziehe aber aus Gründen der Einfachheit und Eindeutigkeit beim AVR ASM vor. Da habe ich alle relevanten Hardware-Informationen aus "erster Hand" (Datenblatt), und muss mich nicht mit einer (schlecht gelungenen, weil übertrieben und nicht transparent) BASCOM-Umsetzung herumärgern, für die ich auch noch bezahlen soll. Den PC programmiere ich allerdings in BASIC. Wenn du es also in einer Hochsprache umsetzen willst, dann mach Folgendes: Schreibe dir aus Peters Posting und meinen Kommentaren die Zustände (Bitmuster an den Ports) heraus (auf Papier), auf die reagiert werden muss. Formuliere dann die daraus resultierenden (Re)Aktionen. Dann müsstest du den PAP selbst erstellen können. ...
gg Mit Warteschleifen hab ich es auch nicht unbedingt... nur fällt mir das Umdenken verdammt schwer... Ich habe bisher nur PHP und Perl progammiert - was beides mit Zeit eigentlich garnichts am Hut hat... es läuft ja einfach alles der Reihe nach ab... Und diese Zeit Geschichten kosten mich im mom wirklich Nerven... Genauso wie das Erstellen von Programmablaufplänen... aber ich werds gleich trotzdem versuchen... werd aber erstmal noch die Freisprecheinrichtung zuende mit meinem CarPC verlöten... Eine Frage noch... Denn dazu find ich in meinem Bascom Buch grade nicht so richtig... Haben die Timer Vorrang vor der Mainschleife? Weil da steckt bei mir ja auch noch ein bisschen was drin und das würde ja den Zeitplan wieder durcheinander bringen, wenn es die Timer ausbremst... Dann müsste ich das ja während des blinkens z.B. auch noch aussetzen lassen...
Die Timer lösen Interrupts aus. Wenn nicht gerade eine andere laufende ISR oder gesperrte Interrrupts im Hauptprogramm den Aufruf der Timer-ISR verhindert, dann hat die ISR Vorrang. Nur leider fehlt BASCOM die Transparenz. Sonst könnte man mal nachschauen, welche Hardware-Ressourcen vom Programm wie verwendet werden. Für die Arbeit an der Hardware eines Controllers abstrahiert mir BASCOM zu sehr (eine Eigenschaft, die bei der Arbeit unter einem Betriebssystem wiederum sehr erwünscht ist!). Deshalb nehme ich für AVRs (wo man ja Hardware pur programmiert) lieber ASM. In ASM ist alles transparent, einfach und übersichtlich. Es gilt ausschließlich das Datenblatt des Controllers (sehen wir mal die Befehlsbeschreibung als Teil des Datenblatts). ...
Moinsen... (warum is das eigentlich immer so spät - oder früh? - wenn ich schreibe??? Also, ich hab mich den kompletten Abend damit auseinandergesetzt... Hatte erstmal ein bisschen mit dem Timer zu schaffen - war ja das erste mal das ich den benutzt hab... Und hab dann versucht quasi den Quelltext von Hannes und meinem danach gezeichneten Ablaufplan das ganze zu programmieren... nur irgendwo hab ich da jetzt nen Fehler eingebaut... und ich find ihn einfach nicht - meine Hoffnung ist, das ihr den findet (daher hab ich auch den geänderten Schaltplan und den Quelltext angehängt)... Hardwaremässig ist alles ok... Hab schon mim Multimeter gemessen, ob das passt und mit nem kleinen Testprogramm hab ich mir auch schon vom µC auf Console ausspucken lassen, was wo anliegt... Also muss es wohl oder übel ein Softwarefehler sein... XD
Sorry, ich kann weder deinen Stromlaufplan noch dein Programm nachvollziehen. Das ist mir alles zu konfus. Erstmal zur Hardware: Die 3 Eingänge des AVRs benötigen Spannungsteiler (je 2 Widerstände) mit einem Schutz vor Überspannung (Widerstand 10k zwischen Spannungsteiler und Eingang, um mittels interner Schutzdioden den Strom und damit die Spannung zu begrenzen oder Z-Diode zwischen Eingang und GND). Mehr nicht! Die 2 Ausgänge gehen über Widerstände 1k auf die Basis der NPN-Transistoren, welche das Relais mit Freilaufdiode schalten. 1k deshalb, weil damit der Transistor stark übersteuert wird und sicher in die Sättigung geht. Das sorgt für geringe Uce und lässt den Transistor kalt. Bei 22k hätte ich Bedenken, dass der Transistor nicht voll in die Sättigung geht. Von den Relaiskontakten werden nur je ein Schließer benötigt (keine Wechsler). Dieser verbindet die Klemme 49 (+12V vor dem Blinkgeber) mit dem Blinkschalter rechts bzw. links. Mehr nicht!! Zieht ein Relais an, schaltet es das Licht einer Seite direkt an (unter Umgehung des Blinkgebers). Damit die Relais nicht "kleben" können, müssen sie für KFZ-Betrieb geeignet sein, also eine starke Rückstellfeder haben (das bedingt einen niedrigen Spulenwiderstand und damit einen relativ hohen Spulenstrom), sowie ausreichende Kontaktbelastung und geeignetes Kontaktmaterial. Also "KFZ-Relais". Andere Kleinrelais mit 10..20mA Spulenstrom sind für Dauerbetrieb unbrauchbar, auch wenn deren Kontakte mit 8A angegeben sind. Irgendwann kleben deren Kontakte (hoher Einschaltstromstoß durch Kaltleitereigenschaft der Glühlampen). Da der "Zustand" die 3 Eingänge und die 2 Ausgänge (also alle 5 Bit) umfasst, wäre es töricht, Eingänge und Ausgänge auf verschiedene Ports zu legen. Alle 5 Leitungen der Blinkgeschichte gehören also auf einen Port. Schau dir mal im Datenblatt die I/O-Register DDRx an. Das sagt mehr als tausend (sinnlose, weil unnötig kompliziert) Config-Anweisungen. Mit "ddrb=0H18" dürfte die Datenrichtung einfacher und nachvollziehbarer steuerbar sein, aber das fällt nun schon unter Software... Ich kann also deine Beschaltung der Relaiskontakte und die Aufgabe der Transistoren Q5..Q7 und ihrer Drumherumbeschaltung nicht nachvollziehen. Auch sehe ich keine Eingangsspannungsteiler, von denen ja (alleine für die Blinkerei) drei erforderlich sind. Die Beschaltung deines Spannungsreglers kann funktionieren, muss aber nicht. Ich hätte dazu für Dauerbetrieb im KFZ nicht besonders viel Vertrauen. Über dieses Thema ist aber in der Vergangenheit schon oft diskutiert worden. Software: Jedem Maschinencode des AVRs ist exakt ein ASM-Befehl (incl. Parameter wie Konstanten, Register und/oder Adressen) zugewiesen. Auch eine Hochsprache muss Maschinencode erzeugen, es gibt sogar Hochsprachen, die ASM-Code erzeugen, der anschließend assembliert wird. Das bedeutet, dass man auch bei Benutzung einer Hochsprache den Ablauf etwas im Auge haben sollte, denn wir programmieren keinen PC mit Betriebssystem und unendlichen, verschwenderisch nutzbaren Ressourcen, sondern einen AVR ohne jegliches Betriebssystem (also direkt an der Hardware) und mit sehr knappen Ressourcen. Beim PC nutzt man Hochsprachen, um sich nicht um die (recht unterschiedliche) Hardware kümmern zu müssen. Beim AVR sind Hochsprachen nur sinnvoll, wenn man es auch ohne kann (Jeder gute C-Programmierer (Mikrocontroller!, nicht PC...) versteht auch ASM). Auch ein maximal getakteter, überdimensionierter Controller kann einen ungünstigen Programmierstil (durch unbekümmertes Drauflosprogrammieren, wie beim PC leider üblich) nicht kompensieren. So ist alleine die Tatsache, dass du Eingänge und Ausgänge auf getrennten Ports hast, schon ein erheblicher Mehraufwand in der ISR, denn die Zustandsvariable umfasst ja auch die Ausgangsbits, sonst könnte man ja das Blinken per Blinkschalter nicht vom eigenen Nachblinken unterscheiden. Du nutzt das "Jobflag" Zustandcheck. Sinn eines Jobflags ist es, das der "Auftraggeber" (die ISR) dem "Auftragnehmer" (Mainloop) mitteilt, dass ein neuer Auftrag vorliegt. In der ISR wird das Flag also nur gesetzt, keinesfalls gelöscht, das darf nur das abarbeitende Unterprogramm. Erkennt die Mainloop das gesetzte Flag, ruft es den "Job" (das Unterprogramm, das den Job erledigt) auf, welches den Job erledigt und das Flag löscht, damit der Job nicht nochmal gemacht wird. Deine Auswerterei kann ich im Moment nicht nachvollziehen, dazu ist mir BASCOM zu fremd und der Code zu konfus. Allerdings habe ich festgestellt, dass mein Programm auch noch viel zu umständlich arbeitet, mal sehen, ob ich Zeit und Lust finde, es zu optimieren. Fazit: Schaffe erstmal eindeutige, nachvollziehbare Hardwarebedingungen und fange danach mit der Software nochmal von vorn an. Vergiss nicht, dass die Software ja in die Software für deine anderen Features integriert werden muss, das ist mitunter (bei ungünstigem Programmierstil) garnicht so einfach. ...
Ich habe es nochmal anders aufgebaut. Es läuft jetzt komplett in der Timer-ISR und benötigt 9 Register. Es ist jetzt also leicht als "Zusatzjob" in ein anderes Programm mit größerem AVR integrierbar. Ein ISR-Durchlauf dauert maximal weniger als 60 Takte (grob überschlagen). Da die ISR nur alle 10ms aufgerufen wird, beträgt die Prozessorauslastung weit unter 1%. Ich hoffe, dass nun das Umschreiben auf BASCOM besser funktioniert. ...
Ich will euch nicht entmutigen, aber die StVZO schreibt für Fahrtrichtungsanzeiger vor, dass sich die Blinkfrequenz bei Ausfall einer Glühbirne signifikant zu ändern hat. Dem Fahrer soll damit angezeigt werden, dass etwas nicht in Ordnung ist. Nur so als Anmerkung.
Das macht sie ja beim normalen Blinken (Kurvenblinken) immer noch, denn da wirkt ja der normale Blinkgeber. Beim "Nachblinken" wird die Last nicht geprüft, aber das ist ein Feature, welches ja nur selten und nur zusätzlich wirkt. Die Information des Fahrers über einen Defekt ist also weiterhin durch das Kurvenblinken gewährleistet. ...
Angehängte Dateien:
Das Thema ist etwas älter, greife dieses dennoch mal auf. Die ursprüngliche Frage bezieht sich auf Skoda, also VAG. Ein „Tip“-Blinker ( Komfortblinker ) lässt sich mir Arduino, bzw 328, sehr gut realisieren. Im Audi A4 und A6 ist der Blinker im Warnblinkerschalter untergebracht. Dieser bietet Platz satt für eine, auch etwas komplexere, Elektronik. Basis ist ein 328. Die Blinker werden über MosFet geschaltet. Die Strom- und Spannungsüberwachung läuft über einen INA 219. Der Strom wird bei jedem Blinkcyclus gemessen, 100 ms nach dem Einschalten. Wird der Sollwert für I nicht erreicht, reduziert sich die Blinkerfrequenz auf 1/2. Erfasst wird auch die 5 W Glühbirne an der Seite. Der Sollwert I wird Spannungsabhängig gemessen sodass die Erkennung zwischen 10-15V problemlos läuft. Integriert ist noch ein Accelerometer der zum einen bei einer Vollbremsung die Warnblinker 5 Cyclen laufen lässt, zum anderen, bei ausgeschalteter Zündung, eine Lageänderung erkennt und die Alarmanlage auslöst. Zusätzlich wird die Spannung überwacht. Unterschieden wird zwischen dem Öffnen einer Tür und einem eventuell nachlaufenden Lüfter. Beim Einschalten der Zündung werden die Blinker seitengetrennt geprüft. Der Impuls ist kurz, lässt die Glühbirnen nicht leuchten, reicht aber und eine Strommessung durchzuführen. Sollte eine Glühbirne defekt sein, blinkt die entsprechende Seite 4x in schneller Folge. Der Accelerometer muss so eingesetzt werden dass er möglichst waagerecht liegt um den vollen Messbereich zu nutzen. In meinem Fall sind es ca 22 Grad. Der Warnblinker Button und das Signal der Zentralverriegelung laufen über ISR um auf jeden Impuls sofort zu reagieren. Gruß
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.