Hallo! Ich stehe vor einem für mich undurchsichtigem Problem... Ich habe in BASCOM ein Programm geschrieben, dass von der Größe her ohne Probleme in einen ATTiny10/11/12 passen sollte! In diesem Programm habe ich einen Interrupt verwendet. Laut Datenblatt S.36 Unterstützt der mC diese auch! Die ganzen Probleme fangen schon bei der Auswahl des Chips bei BASCOM an! Den HW Stack, Soft Stack, Framesize kann ich maximal auf 0,9 stellen... Ansonsten bekomme ich eine Fehlermeldung! Doch mit diesen Einstellungen compiliert er das Programm leider nicht! Er sagt mir z.B. das "Dim Bli As Bit" mit einem ATTiny nicht geht... Warum geht das nicht? Mit meinem AT90S8515 ist das alles kein Problem.... Was ist an den Tinys anders? Ich sende mal die BASCOM-Datei als Anhang mit! Wäre dankbar, wenn mir jemand weiter helfen könnte.... Ich will ja nicht mit Kanonen (AT90S8515 32 I/O etc.) auf Spatzen (benötigt: 5 I/O davon 1 Interrupt) schießen.... Gruß, Stephan
die haben keinen internen sram. ich weiss nicht wie das mit bascpm ist aber mit c laufen die zumindest nicht weil die höheren programmiersprachen eigentlich immer ram voraussetzten. tiny13 wäre ideal für dich - gibts den eigetnlich schon?
Tiny13 soll wohl Ende September, und das ist ja gar nicht mehr lange hin, bei Reichelt zu bekommen sein: http://www.mikrocontroller.net/forum/read-1-87197.html#105980 Gruß Ingo
Hallo Stephan Wende dich doch mal an Mark Alberts (info@mcselec.com), den Betreuer von BASCOM; es gibt (meistens) eine schnell und kompetente Auskunft; dort kann man dir sicher weiterhelfen Günter
Ok, werde mal eine E-mail an Mark Alberts schreiben. Habe aber noch den ATTiny 26 ins Auge gefasst... Der hat auch einen externen Interrupt, nur dort bringt mir Bascom auch wieder Fehlermeldungen: "Line: 1 .EQU not found, probably using functions are not supported by the selected chip [UBRR]" In Zeile 1 steht "Enable Interrupts" Eigentlich sollte er das doch können??? Gruß, Stephan
ubrr ist ein register vom usart. der chip hat wohl keinen aber bascom will das wohl aus irgendeinem grund aktivieren. kann man die verwenung des usart bei bascom irgendwo deaktivieren?
Hi... Versuchs doch einfach mal in Assembler (AVR-Studio), der Befehlssatz steht im Datenblatt und wird in der AVR-Studio-Hilfe oder auch im Instruction-set (ATMEL-Homepage) ausführlich erklärt. Da die Programme für 8-Pin-Tinys eh recht klein ausfallen, behält man auch die Übersicht. Was bezweckt eigentlich der Print-Befehl in deinem Quellcode? Es wäre auch sinnvoll, im Quelltext als Kommentar die Anschlussbelegung anzugeben. Damit kann man sich ein Bild von der angeschlossenen Peripherie machen. Ich kann z.B. nicht nachvollziehen, ob das ein Auto-Blinkgeber oder was auch immer werden soll... Falls du das Projekt mit einem Tiny12 in Assembler realisieren willst, bin ich dir bei den ersten Schritten gern behilflich. ...HanneS... (hannes.lux(at)gmx.de)
Hi... UART?? Das macht wohl der verwendete PRINT-Befehl... Ich habe nix gegen Hochsprachen! Auch nix gegen BASCOM!! Aber ich finde es unerträglich, dass fast alle BASCOM-Beispiele den PRINT-Befehl benutzen, ohne darauf hinzuweisen, dass das eine recht komplexe und ressourcenfressende Angelegenheit ist, die noch dazu extrem zeitkritisch ist und einen präzisen Takt des AVT vorraussetzt! Hochsprachen sind sinnvoll und gut. Aber nicht für den, der meint, ohne das Verständnis von Bits, Bytes, Registern, I/Os und interner AVR-Peripherie AVRs brauchbar programmieren zu können. Und mit Assembler lernt man recht schnell und einfach... ...HanneS...
vor allem wenn man ein print auf einem avr benutzt der überhaupt kein uart hat. das zeigt doch recht schon, dass da grundlagen fehlen. deshalb mag ich bascom nicht. das abstrahiert die hardware zu sehr mit den ganzen fertigen routinen, so dass man keine ahnung mehr hat was eigentlich passiert. da ist gcc besser - da muss man noch selber mit registern und ports rumkleckern
Ich frage mich echt wie es jemand schafft einen uC zu programmieren, aber nichtmal weiß was z.B. ein AND Gatter ist, oder es nichtmal schaffen ein IC aus einem Sockel zu ziehen !!! Und dann wundere ich mich auch nicht, dass genau diese Leute einen ATmega 64 oder 128 in BASCOM programmieren, da das "Hello World" Programm 10kByte groß ist... C ist OK, wenn C nur dass macht, was ich will. Wenn aber standartmäßig der UART schon von der Software verwendet wird, dann bleib ich lieber bei Assembler. Bisher bin ich ganz gut damit klar gekommen, vor allem bei 8051 für den es keinen guten (kostenlosen oder bezahlbaren) Compiler gibt. Beim AVR oder 16bit Controllern sieht es da schon ganz anders aus.
da outet sich noch einer :) aus der basecom hilfe: PRINT Action Send output to the RS-232 port. Writes a string to a file. Syntax PRINT var ; " constant" Remarks Var The variable or constant to print. You can use a semicolon (;) to print more than one variable at one line. When you end a line with a semicolon, no linefeed will be added. The PRINT routine can be used when you have a RS-232 interface on your uP. The RS-232 interface can be connected to a serial communication port of your computer. This way you can use a terminal emulator as an output device. You can also use the build in terminal emulator.
@Tobi Den TINY13 gibt hier und da schon zu kaufen. Wenn du den bei EBAY nicht kriegst, dann versuchs mal hier. www.csd-electronics.de Recht dürftiges Sortiment und der TINY13 ist auch nur in der PI Bauform zu haben. Die Seite wurde in nem anderen Thread schon mal genannt. Die haben aber keine FET's sonst würd ich da mal was bestellen. MFG Basti
@Tobi: Du willst in der Bascom-Hilfe unter "OPEN" nachschauen und dort die Software-UARTS kennenlernen. Markus
Oh, Sorry, Sorry, Sorry!!!! Der Print "AVR" befehl gehört gar nicht zu dem Programm... Habe den nur eingebaut um im Simulator von BASCOM besser sehen zu können, ob mein Interrupt richtig funktioniert... Und jetzt habe ich auch dem Suport von BASCOM das Programms so geschickt... Verdammt!!! Das Programm soll eigentlich nur einen Schaltzustand erkennen und den verlängern... Die angeschlossene Peripherie sind eigentlich nur zwei kontakte von dem "Blinkerhebel" um zwischen rechts und links zu unterscheiden und zwei Mosfets um diesen "Schaltzustand" zu verlängern.... @Hannes Ich habe keine Ahnung von Assembler und müsste mich erst was einarbeiten bzw. mal ein Buch lesen... Würde dann gerne auf deinn Angebot zurück kommen Seit dem der Print befehl weg ist, bekomme ich das Programm ohne Probleme für einen ATTiny26 Compiliert.... Soweit ich mich jetzt belesen habe ist sind die ATTinys für Hochsprachen sowieso nicht wirklich geeignet... Ist das richtig? Gruß, Stephan
@markus wie erklärst du dann das das wohl das problem war? ich kann nur vermuten, dass der sw uart wohl erst initialisert werden muss und der standardmässig versucht den hw uart zu nehmen. und das schlug wohl fehl
sieht nach avr studio aus. müsst damit eigentlich gehen wenn man beide hex files ineinander kopiert. hat bei mir mal ganz gut geklappt
Hi... @Stephan Titz, was hältst du davon, wenn wir (gemeinsam hier im Forum) den Projekt noch mal von vorn beginnen. Diesmal auf einem Tiny12 in Assembler mit AVR-Studio4 (bei mir läuft Version 4.08)? Dazu müsstest du erstmal die zu lösende Aufgabe eindeutig beschreiben, also möglichst so präzies, dass keine Missverständnisse möglich sind. Dies wäre einerseits die Definition der angeschlossenen Peripherie, am besten mit Schaltplan und zusätzlich eine vollständige Pinbelegungsliste und evtl. Signalbeschreibung (Ruhepegel, Aktiv-Pegel). Das AVR-Studio4 kannst du dir auch schon mal runterladen und installieren. Aber das kommt erst später zum Einsatz. Bevor man nämlich mit einer Programmiersprache (egal mit welcher!) beginnt, sollte man die Algorithmen des Programms definiert haben und in Worten, oder besser als Programmablaufplan eindeutig festgeleschrieben haben. Und das nicht im Hinterkopf, sondern auf Papier... Wir könnten hier Schritt für Schritt durchdiskutieren, dabei die Einsteigerhürden des AVR-Studios überwinden, bis hin zum fertigen Programm. Damit ich mich nicht verzettele, muss ich von Anfang an exakt wissen, was das werden soll und wie die Arbeitsweise sein soll... Sieh es als Vorschlag, als Angebot, in ASM einzusteigen. Du wirst sehen, dass (bei kleinen Programmen auf kleinen AVRs) ASM viel einfacher und übersichtlicher ist, als du momentan denkst. Du brauchst dich nicht mit irgendwelchen kryptischen CONFIGs herumzuschlagen, sondern schreibst per OUT einfach die per Datenblatt ermittelten Werte in die zuständigen Register. Als Informationsquellen genügen vorerst die Datenblätter, die Hilfe zu AVR-Studio und diverse Beispielprogramme hier aus dem Forum. @BASCOM-Freaks: Welche Möglichkeiten bietet BASCOM, das Programm als ASM-Datei auszugeben? Gruß... ...HanneS...
@Bastian Wo haben die den TINY13 auf der Seite versteckt? Oder bin ich zu doof zum suchen? Dennis
Danke,....bin doch zu doof. Hat da jemand schon mal was geordert? So von wegen Lieferzeit 1-2Tage??? Kannte den Laden vorher gar nich. Dennis
@Hannes Das Angebot neheme ich gerne an! Doch ich denke, dass ich mir vorerst einen ATTiny12 bei Reichelt bestellen sollte! Werde die Bestellung heute füh raus geben! (ist dann meißtens am nächsten Tag da) Werde mich jetzt mal an Eagel setzen und versuchen mit einem Schaltplan so ein wenig Klarheit zu schaffen! Vielleicht schaffe ich das heute Nacht noch... :) (Bin da nämlich auch ein "Neuling") Werde mit dem Schaltplan die Projektbeschreibung posten. Ich trage erst einmal alles zusammen , was für dich und die anderen in Bezug auf dieses Projekt interessant sein wird, damit von anfang an eine einheitliche Grundlage besteht und Verständigungsproblem minimiert werden können... Ich finde es auch sehr interssant so ein Porjekt von Anfang an "professionell" auf zu ziehen! Beginne jetzt gleich mit den Vorbereitungen.... Ich Programmiere mit dem STK500, sollte also noch AVR Studio auf CD haben. Schon mal danke im Vorraus, Stephan
So eine kleine Übersicht... Hoffe ich habe das alles richtig gemacht bzw. die richtign Bauteile verwendet! Eine Detailierte Beschreibung der Funktion kommt heute früh... Gruß, Stephan
Hi Stephan... Also die "Profi"-Jacke ziehe ich mir nicht an. Ich beschäftige mich auch nur hobbymäßig mit MCs. Also die Ansteuerung der MOSFETs funktioniert so nicht. Das sind P-Kanal-MOSFETs, die brauchen +12V als Bezugspunkt (Source), denen kannst du nicht einfach GND und +5V als Steuerspannung unterjubeln, denn Beides steuert die FETs durch. Du benutzt mal das Symbol V- und mal GND. Das ist für Eagle Zweierlei. Du müsstest dich schon auf ein Symbol festlegen. GND wäre da schon treffender. Deine Spannungsteiler arbeiten ohne Überspannungsschutz. Bist du sicher, dass deine 12V auch immer 12V sind? Im KFZ ist das z.B. nicht der Fall... Nun das Wichtigste: Willst du deine Schaltung in einem Kraftfahrzeug im Gültigkeitsbereich der STVZO (also im öffentlichen Straßenverkehr) betreiben? Dann sehe ich schwarz, denn ich denke mal, dass du das nicht darfst. Dafür wirst du wohl eine Bauartgenehmigung (oder wie immer diese Art der TÜV-Zulassung heißt) brauchen. Als Mangel sehe ich hier, dass die Blinker komplett ausfallen, falls der MC ausfällt. Achja, schau dir mal in Eagle die Export Image -Funktion an ("ex im" eintippen), damit kannst du die Zeichnung als Bilddatei exportieren. Ich lege das immer ins Clipboard und füge das in IRFAN-VIEW ein, wo ich es als GIF speichere. Das ist dann schön handlich für E-Mails oder Forum. Vor allem kann es jeder lesen, auch wenn er kein Eagle hat. ...HanneS...
Hi, Leute wie ihr vielleicht wisst, hehm' ich FastAVR als Programmier"sprache". ist vom Syntax ähnlich. Leider nicht so komfortabel mit Applikationswizzard usw. Hier hat man die Möglichkeit, das erzeugte ASM-File sich anzusehen und ggfls. zu verändern. Einiges geht nämlich auch hier nicht 100%tig i.O. Und - nicht zu vergessen - ist auch teurer. Der Herr Invnacic will 99Euronen haben! ZUr Schaltung: die PMOS sind auch noch falsch angeschlossen.Du musst Du umdrehen (Source/drain), damit, sollte die Ansteuerung korrigiert sein, das auch klappt. Das Du keine K1-Zulassung bekommen würdest, stimmt so nicht! Die kann man einfach beantragen. Nur, ob Du Dir das leisten kannst/möchtest, steht auf einem anderen Blatt. ich würde die Sache nicht so eng sehen. Wie gesagt: ICH . Sorge aber dafür, dass Du eine FailSave mechmik einbaust, die dafür sorgt, das die Blinker auch noch so arbeiten können. Gruß Axel
Habe mich entschlossen, noch keine ATiny12 bei Reichelt zu bestellen. Die Planung sollte erst abgeschlossen sein, damit ich die Bauteile in einem Bestellen kann Habe den Schaltplan noch ein wenig verfeinert... Habe die Mosfets geändert und habe jetzt N-Kanal Fets genommen... Ist doch richtig oder? Die Eingänge habe ich jeweils mit einem 100nF Kondensator entprellt. Die Schaltung soll in einem Auto (spezielle Golf IV) verbaut werden! Das mit dem TÜV ist so eine Sache und ist von TÜV zu TÜV irgendwie unterschiedlich! Es gibt Leute, die diese Steuerung (analoge Bauweise) eingetragen bekommen haben . Wobei ich mir das mit einem mC problematischer vorstellen kann in Bezug auf Ausfälle etc. Wie Axel schon sagte könnte tatsächlich eine FailSave Steuerung ergänzt werden. Wir hätten nach meinem Schaltplan sogar noch einen Pin für so eine Schaltung frei. Wobei dann erstmal wichtig wäre, welche Störungen bei einem mC auftreten können? - kann sich ein mC aufhängen? Wenn ja ist das ein Problem, da ein Erkennen der Störung sehr schwierig sein wird. - kann ein mC falsch rechnen? Wenn ja wird das auch sehr schwierig zu erkennen. - wenn eine Störung mit dem kompletten Ausfall (Tod durch Überspannung, Überhitzung etc. ) des mC gleichzusetzen wäre, könnten wir eine Schaltung nach dem Prinzip der Drahtbruchsicherheit aufbauen. Auf den freien Pin würde also immer eine 1 (+5V) anliegen. Wenn das nicht der Fall ist (mC defekt etc.) müsste der mC überbrückt werden. Es wäre mir sehr lieb, wenn diese FailServe Mechanik ohne Relais auskommt, sondern eher mit Transistoren oder Mosfets arbeitet. Ich hänge gleich auch mal Schaltpläne vom Golf IV als pdf an So nun erstmal zur Funktionsbeschreibung: Der Blinkerhebel schaltet den kompletten Laststrom für die jeweilige Seite (Blinker vorn, seite, hinten) Das sind pro Seite ca. 47W also ca. 4 A. Der Blinktakt wird von einem Blinkrelais generiert, mit dem wir nichts zu tun haben. Wir geben dem Relais nur 12V und 4A (deshalb auch Mofets z.B. BTS436L2  Reichelt) Ich beschreibe nur die Funktion für die linke Seite. Die rechte Seite ist identisch. Wenn ich den Blinkerschalter (links) taste, soll der Blinker (links) drei mal nachblinken. Wenn wir davon ausgehen, dass eine Blinkperiode (an aus) 1 Sekunde dauert, müssten wir dem Blinkrails 2,5 Sekunden Spannung (über die Mosfets) geben. Falls innerhalb von diesen 2,5 Sekunden in die andere Richtung (Blinker rechts) durch tasten des Blinkerschalters (rechts) geblinkt werden soll, muss die Wartezeit für die linke Seite unterbrochen werden und dem Blinkrelais (recchts) 2.5 Sekunden Spannung gegeben werden. Die Unterbrechung wird durch den Interrupt (Int0) erreicht der auf rising edge unterbricht. Falls das Blinken (Blinkerschalter links eingerastet) länger als 3 Perioden dauert (2,5 Sekunden) wird nicht nachgeblinkt. Wenn das Abbiegen beendet ist (Blinkerschalter links wird zurückgestellt) hört das Blinken sofort auf. Pinbelegung ATTiny12 (siehe Schaltplan): PB0 --> Blinker rechts (Signaleingang vom Blinkerschalter) PB1 --> Int0 (Signal vom Blinkerschalter rechts und links) rising edge PB2 --> Blinker links (Signaleingang vom Blinkerschalter) PB3 --> Steuerspannung für MOSFet (Blinker rechts) PB4 --> Steuerspannung für MOSFet (Blinker links) PB5 --> Freier Pin z.B. für FailSave etc.
Hi... Puhhh... - Das iss starker Towak... Also eigentlich fühle ich mich nicht kompetent, Schaltungen zu entwickeln, die im Straßenverkehr sicherheitsrelevante Dinge wie Fahrtrichtungsanzeiger steuern. Daher werde ich nicht spekulieren, wie es geht, sondern nur bemängeln, was mir unsicher erscheint. Fangen wir beim Netzteil an. Ansich ist es (eigentlich) richtig. Aber im Auto sind nunmal 12V alles andere als 12V. Es kann passieren, dass Spannungsspitzen aus dem Bordnetz die Diode und/oder den Spannungsregler zerstören. Wie man das verhindert (Drossel, Varistor) überlasse ich den Fachleuten. Die MOSFETs stimmen nun garnicht mehr. P-Kanal war schon richtig(er), sie müssen aber anders angesteuert werden. Du hast auch einen Denkfehler in der Belastung. Denn Glühlampen sind Kaltleiter, haben also einen Einschaltstrom, der schon mal dem 15-fachen des Nennstroms entspricht. Du brauchst also dicke Klopper. Da kommst du mit normalen KFZ-Relais bedeutend besser weg. Auch diese lassen sich über Treibertransistoren und Schutzdioden per AVR ansteuern. Die Kondensatoren in den AVR-Eingängen bringen garnix, im Gegenteil, sie verhindern... Die alte Ansteuerung war schon besser, nur fehlte da der Überspannungsschutz. Den erreichst du mit zusätzlichen Z-Dioden parallel zu den gegen GND liegenden Widerständen. - AVRs können sich aufhängen - AVRs können durch Spannungsspitzen zerstört werden. Deine Drahtbruchsicherheit per AVR und dessen INT nützt dir nix, abgesehen davon, dass es mit deinem Schaltungs-Vorschlag nie funktionieren kann. - Es wurde ein "failsave" vorgeschlagen, es soll also bei defekter Schaltung der (alte) Normalzustand gesichert werden. Das macht deine Schaltung aber nicht... - Du meinst, der Blinkschalter schaltet 12V Dauerstrom durch. Nunja, das könnte ja sein (ich kenne die Schaltung des Golf nicht), aber bei meinem Trabbi liegt der Blinkgeber vor dem Blinkschalter (zwischen 15 und 49), warum sollte das beim Golf anders sein? Wie du siehst, kommen wir vorläufig nicht dazu, mit dem Programm in Assembler zu beginnen, da die Hardware nicht funktionsfähig ist. Ich denke fast, dass du dir für ein Einsteigerprojekt etwas viel vorgenommen hast. Gehen wir mal anders an die Sache ran. - Du willst, dass das Ding erstmal normal blinkt wie jedes andere Auto auch. - Dann willst du die Blinkzeit verlängern, falls diese unter 3s ist. - Dann willst du die Verlängerung abschalten, falls die Gegenrichtung aktiviert wird. Dazu trennen wir die Blinkanlage nicht auf, sondern "hören mit". Der AVR bekommt also zwei Eingänge, die vom Blinkschalter über entsprechende Spannungsteiler mit Überspannungsschutz kommen. Dann schaltet der AVR über zwei Transistoren mit Freilaufdioden (clamp) zwei Relais, wie sie bei Autoelektrik üblich sind. Die Kontakte der Relais (Schließer) überbrücken dann nur den Blinkschalter, also das eine verbindet 49 mit 49a, das andere verbindet 49 mit 49b. Das wäre schaltungsmäßig schon alles. Das Programm macht nun Folgendes: - Wird ein Eingang aktiv, so wird der Ausgang der Gegenrichtung deaktiviert (falls er nicht aktiv war geht das ins Leere), die Zeit gestartet, eine zweite Zeit gestartet und der eigene Ausgang aktiviert. - Ist die Zeit abgelaufen, so werden alle beide Ausgänge deaktiviert. - Ist die zweite Zeit noch aktiv, wird das Einschalten verhindert, die Zeiten aber neu gestartet. Dies soll erneutes Einschalten durch den Blinktakt verhindern. Und das war es auch schon... Wenn du das mit einem Tiny15 statt mit einem Tiny12 machst, dann bekommste noch ein Poti zum Einstellen der Verzögerungszeit. ...HanneS...
Ok, lassen wir das mal mit dem ganzen Kfz Zeug... Über Probleme der Spannungsversorgung kann man immernoch später den Kopf zerbrechen! Für mich steht sowieso erstmal die Programmierung im Vordergrund. Ich habe jetzt mal die Stromlaufpläne gewälzt und bin zu der Erkenntnis gekommen, dass das ganze nicht so stimmt, wie mir gesagt wurde . Der Blinkgeber kommt vor dem Schalter! So, wie du es gesagt hast. Sorry!!! Damit ist jetzt auch meine ganze Bascom Programmierung über den Jordan und ich muss auch erstmal wieder neu denken. (Ich habe jetzt mal eine Pdf gemacht, die den Stromlaufplan für den Blinker im VW enthält. Nun hätten wir das Problem, dass wir eigentlich gar nicht erkennen, ob der Blinkerschalter betätigt ist, weil wir kein Dauersignal haben . Wir haben anscheinend nur den Blinkertakt! So erkenne ich das zumindest aus dem Stromlaufplan! Oder habe ich da einen Denkfehler? Wie könnte man dieses Problem lösen? Die Kondensatoren waren eigentlich zur Entprellung gedacht . Wobei sie eigentlich parallel mit Vcc (also 5V Dauerplus) zum zu entprellenden Schalter gelegt werden müssten! Oder? Zitat: http://www.rowalt.de/mc/avr/avrboard/05/avrb05.htm Da der AVR schnell genug reagiert, erhalten wir als Folge mehrere Interrupts. Dies ist ein gut bekanntes Problem in der Digitaltechnik, welches ich einfach nicht unerwähnt lassen konnte. Als Problemlösung schaltet man im primitivsten Fall einen 100nF-Kondensator vom INT1-Eingang nach Vcc oder verwendet ein RC-Glied bzw. Monoflop. Das mit den Mosfets werde ich wohl nie verstehen . Dachte mir, nachdem ich diese Seite (http://www.elektronik-kompendium.de/sites/bau/0510161.htm ) gelesen habe und unten die Tabelle gesehen habe, dass es N-Kanal Mosfets sein müssten, weil ich ja mit positiven Spannungen arbeite . Könnte man statt normalen Relais nicht auch elektronische nehmen? Ich würde gerne das Relaisgeräusche vermeiden. Das oben genannte Mofet würde diesen Einschaltstrom (ca. 60A) nicht für die kurze Zeit aushalten? Muss ich bei Kaltleitern immer mit dem 15 fachen Einschaltsrom rechnen? Was wären es für Mosfets, wenn wir es doch auf diese Weise realisieren würden? Hoffe, dass wir bald mit der Programmierung beginnen können ;) Habe AVR Studie 4.07 mittlerweile installiert Es gibt ja doch noch ein paar Hürden zu überwinden. Hatte mir das im Hinterkopf viel viel einfacher vorgestellt Die Idee mit dem AD Wandler und einem ATTiny15 gefällt mir sehr gut! Aber lass das mal langsam angehen . Stelle mir das in Assembler verdammt schwierig vor! Habe das ja in Bascom noch nicht einmal gemacht . ;) Gruß, Stephan!
Hi... Da habe ich nun fast eine Stunde lang eine Antwort getippt und nun war alles umsonst, weil der Server den Thread nicht gefunden hat... Und zum nochmal soviel tippen habe ich jetzt leider keine Zeit. Sorry, dauert also noch... ...HanneS...
Hi... Da ich nun schon zum zweiten mal antworte, mache ich es mir etwas einfacher und kommentiere... > Ok, lassen wir das mal mit dem ganzen Kfz Zeug... Na ohne konkrete Definition der Peripherie kann man kein Programm entwerfen. Das Netzteil kann später optimiert werden, aber die Beschaltung der Eingänge und Ausgänge muss schon festgeschrieben werden. > Der Blinkgeber kommt vor dem Schalter! So, wie du es gesagt hast. Das dachte ich mir... > Nun hätten wir das Problem, dass wir eigentlich gar nicht erkennen, ob > der Blinkerschalter betätigt ist, weil wir kein Dauersignal haben. Genau... Dauersignal brauchen wir aber auch nicht unbedingt. > Wir haben anscheinend nur den Blinkertakt! Stimmt... > Wie könnte man dieses Problem lösen? Indem eine Art "Wiederholsperre" eingebunden wird, die Blinkimpulse eine gewisse Zeit lang ignoriert, wenn die Steuerung aktiviert wurde. > Da der AVR schnell genug reagiert, erhalten wir als Folge mehrere > Interrupts...... Wir nutzen keinen Pin-Interrupt, wir entprellen anders. > Könnte man statt normalen Relais nicht auch elektronische nehmen? > Ich würde gerne das Relaisgeräusche vermeiden. Damit habe ich keine Erfahrung, also kann ich da nichts empfehlen. Fakt ist, dass sich FETs mit Niedervolt-Glühlampen schwer tun. Herkömmliche KFZ-Relais sind zuverlässig, billig (Pollin), und haben eine Trennung zwischen Steuerkreis und Lastkreis. Außerdem tritt kaum Spannungsabfall auf. Und das Klicken wird doch sowiso von der Audio-Anlage übertönt, dürfte also nicht stören. > Das oben genannte Mofet würde diesen Einschaltstrom (ca. 60A) nicht > für > die kurze Zeit aushalten? Muss ich bei Kaltleitern immer mit dem 15 > fachen Einschaltsrom rechnen? Was wären es für Mosfets, wenn wir es > doch auf diese Weise realisieren würden? Das ist ja das Problem. Die Transistoren sterben meist in diesem kurzen Moment... Außerdem würde die Ansteuerung recht aufwendig, da der Bezugspunkt (Source) nicht auf festem Potential liegen würde, sondern am Blinkgeber. Daher: Relais! - Wenn du später ausreichend Wissen erworben hast, kannst du immer noch MOSFETs einsetzen. Aber jetzt möchte ich mich nicht damit verzetteln, denn wir wollen doch eigentlich das Programm beginnen, oder? > Hoffe, dass wir bald mit der Programmierung beginnen können ;) Eben... > Habe AVR Studie 4.07 mittlerweile installiert. > Es gibt ja doch noch ein paar Hürden zu überwinden. > Hatte mir das im „Hinterkopf“ viel viel einfacher > vorgestellt… Das ist normal... > Die Idee mit dem AD Wandler und einem ATTiny15 gefällt mir sehr gut! Mir auch... - Schade dass der Fahrer meines Trabbis (ach das bin ja ich??) sowas nicht braucht. > Aber lass das mal langsam angehen. Stelle mir das in Assembler > verdammt schwierig vor! Habe das ja in Bascom noch nicht einmal > gemacht. ;) Ich halte es in Assembler für einfacher. Denn für Assembler habe ich das Datenblatt, in dem alle Ressourcen (Ports, Timer, ADC...) ausführlich und mit genauer Registererklärung beschrieben sind. Man brauch also nur noch mittels IN und OUT auf die Register zugreifen, um damit zu arbeiten. Es gibt keine kryptischen CONFIG-Anweisungen und weiß der Geier was BASCOM alles bietet. Man arbeitet direkt an der Hardware (und nur an der Hardware). Komplizierter würde es bei Berechnungen mit Fließkomma werden oder bei echter Datenverarbeitung. Aber sowas machen wir ja nicht, wir schalten ja nur. Und dazu gibt es nix Einfacheres als ASM... Nun mal konkret. Setzen wir mal folgende Schaltung voraus: - An der Blinkanlage wird nix unterbrochen, sondern nur "angezapft". - Wir brauchen vom Blinkschalter die 49 (die Leitung vom Blinkgeber) und die beiden Leitungen für links und rechts. Dann noch Masse (GND) und +12V. - Die Arbeitskontakte der Relais werden parallel zu den beiden Zweigen des Blinkschalters geschaltet. - Die Leitungen Links und Rechts werden über Spannungsteiler (mit zusätzlichen Z-Dioden) an zwei Eingänge des Tiny15 gelegt. - Zwei Ausgänge des Tiny15 treiben über NPN-Transistoren die KFZ-Relais gegen 12V (Clamp-Dioden nicht vergessen). - Ein Poti (Trimmpoti, 10...47k linear) zwischen +5V und GND liefert die analoge Steuerspannung für Pin 2 des Tiny15, mit der die Verzögerung eingestellt werden kann. - Eine Spannungsregelung erzeugt aus den 12V die 5V Das Modul brauch also 5 Leitungen zum Auto: - GND (Masse, 31) - +12V (Zündung, 15, oder besser Eingang Blinkgeber, 49) - Eingang Blinkschalter (49a) - Ausgang Blinkschalter Links (L) - Ausgang Blinkschalter Rechts (R) Das Modul enthält: - AVR Tiny15 - Spannungsregelung - 2 Spannungsteiler mit Überspannungsschutz - 2 Schalttransistoren mit Basiswiderständen - 2 KFZ-Relais (Printausführung?) - 2 Clamp-Dioden an den Relais - 1 Trimmpoti - Diverse Keramik-Kondensatoren und Elkos Das Programm muss folgende Jobs erledigen: - Initialisierung der benötigten Ressourcen (Timer0, ADC, Ports, Sleep-Mode, Oszillator-Kalibration) - Bereitstellen einer Zeitbasis mit Timer0-Überlauf-Interrupt - Abfrage der beiden digitalen Steuereingänge - Abfrage des analogen Steuereingangs (Potistellung) - Steuerung der "Schaltzeit" (eine Zählvariable als Timer) - Steuerung der "Wiederholsperre" (eine Zählvariable als Timer) - Abschaltung der Ausgänge, wenn Schaltzeit abgelaufen ist - Abschaltung eines Ausgangs, wenn die Gegenrichtung betätigt wird - Einschalten eines Ausgangs und Aktivieren von Schaltzeit und Wiederholsperre, wenn der Eingang aktiv wird und die Wiederholsperre abgelaufen ist Das Programm gliedert sich in folgende Teile: - Kommentare zum Erklären von Sinn oder Unsinn des Programms - Zuweisung von Konstanten - Zuweisung von Registernamen - Interrupt-Vektoren - Reset-Routine (Initialisierung) - Timer0-Überlauf-ISR (hier läuft das gesamte Programm) - Hauptschleife Die Hauptschleife ist schon fertig: main: sleep rjmp main Denn die Arbeit wird in der Timer0-ISR (Interrupt-Service- Routine) gemacht. ;-))
Hallo Stephan... Ich stelle schon mal einen Schaltungsentwurf zur Diskussion. Also einen ENTWURF, der gerne optimiert werden kann. Es geht also vorerst nur ums Prinzip, noch nicht um die exakte Dimensionierung der Schaltung. ...HanneS...
Hallo Hannes! Die größten Hürden der Vorbesprechung haben wir ja schon geschafft . Ich werde jetzt noch ein paar deiner Zeilen kommentieren und Fragen dazu stellen bzw. sie so bestätigen, wie ich sie verstanden habe, damit wir später nicht aneinander vorbeireden oder ich der übliche Jasager-Schüler bin, der am ende nichts verstanden hat, obwohl es nur an einer Kleinigkeit direkt am Anfang lag. Das Projekt wäre dann fertig, aber ohne jeglichen Nutzen für mich oder für dich. >Indem eine Art "Wiederholsperre" eingebunden wird, die Blinkimpulse >eine gewisse Zeit lang ignoriert, wenn die Steuerung aktiviert wurde. Mit Wiederholsperre meinst du also, dass der mC ein Signal erkennt (rechter oder linker Blinker) und wenn das Signal abgelaufen (LO-Pegel) ist (wir haben ja den Blinktakt (HI LO HI LO etc)) er dann noch eine Zeit x (z.B. 500ms) auf ein eventuelles nächstes Signal (HI-Pegel) wartet. >Wir nutzen keinen Pin-Interrupt, wir entprellen anders. Werde mich mal über entprellen ausreichend informieren! Aber es gibt doch die zwei Möglichkeiten einmal über einen Kondensator zu entprellen und einmal die Möglichkeit, nachdem der Interrupt ausgelöst wurde, die Interrupts auszuschalten und nach einer gewissen Zeit wieder einzuschalten? >Herkömmliche Kfz-Relais sind zuverlässig, billig (Pollin), und >haben eine Trennung zwischen Steuerkreis und Lastkreis. Außerdem >tritt kaum Spannungsabfall auf. Und das Klicken wird doch sowieso >von der Audio-Anlage übertönt, dürfte also nicht stören. Ok, wir werden erstmal Kfz-Relais nehmen. Mir fehlt tatsächlich noch verdammt viel Erfahrung und Know-how. Und an der Programmierung ändert eine spätere Umrüstung auf Mosfets ja auch nichts. >Ich halte es in Assembler für einfacher. Denn für Assembler habe ich >das Datenblatt, in dem alle Ressourcen (Ports, Timer, ADC...) >ausführlich und mit genauer Registererklärung beschrieben sind. Wäre es Sinnvoll, dass ich vor dem Programmierbeginn erstmal das komplette Datenblatt durcharbeite? Oder sind nur gewisse teile sinnvoll? >Die Leitungen Links und Rechts werden über Spannungsteiler (mit >zusätzlichen Z-Dioden) an zwei Eingänge des Tiny15 gelegt. Spannungsteiler um auf 5V zu kommen und die Z-Diode um einen Überspannungsschutz zu gewährleisten? Richtig? >Clamp-Dioden Vielleicht eine dumme Frage aber was sind Clamp-Dioden? In dem Elektronik-Kompendium (http://elektronik-kompendium.de/) habe ich keine Antwort gefunden Wobei ich den Begriff Clamp-Diode schon oft hier im Forum gelesen habe Mach dir jetzt keinen großen Aufwand mit Erklärungen, aber vielleicht hast du einen Link wo ich das selber nachlesen kann? >Ein Poti (Trimmpoti, 10...47k linear) zwischen +5V und GND >liefert die analoge Steuerspannung für Pin 2 des Tiny15, mit der >die Verzögerung eingestellt werden kann. Wäre auch ein 0 ... 10k Poti möglich? Oder warum wählt man ein 10 bis 47k Poti? Wegen der letztendlichen Auflösung? Wonach richten sich diese Werte? >2 Kfz-Relais (Printausführung?) Ich denke das ist die eleganteste Variante. >Interrupt-Vektoren >Oszillator-Kalibration Gib mir bitte noch ein wenig Zeit. Muss noch einige Begriffe klären! main: sleep rjmp main Ok, das scheint ja schon ganz ganz einfach anzufangen! ;) Meinst du es ist sinnvoll, wenn ich erstmal das Tutorial durcharbeite, damit ich wenigstens etwas Ahnung von diesem Element habe? Die Hauptschleife kann ich mir nur so erklären... Der mC schläft ist im Stromsparmodus. Wenn die Interrupt Service Routine abgelaufen ist, wird ja zu dem Programmpunkt gesprungen bei dem sie gerade ausgelöst wurde. Das wäre dann nach dem sleep! Richtig? Rjmp main wird dann wohl heißen, dass er zu dem Label (nach Bascom) main springt. Dort ist der erste Befehl wieder sleep. Also geht der mC bis zum nächsten Interrupt wieder schlafen! Oder? Aber durch was wollen wir den Interrupt auslösen also folglich die ISR starten? Du schreibst das Hauptprogramm läuft in der Timer0_ISR. Wäre da nicht ein Pin Interrupt angebracht? Weil der mC soll ja erst dann anfangen zu denken, wenn er von dem linken oder rechten Blinkereingang ein Signal bekommt?! Oder habe ich da einen Denkfehler? Habe mir noch gerade die Schaltung von dir angesehen und hätte dazu eigentlich noch ein paar Fragen zu ein paar Kondensatoren und Dioden (Clamp-Dioden Habe ich aber oben schon geschrieben). Du verwendest auch vor dem Spannungsregler einen veränderbaren Widerstand! Ist der dafür da, damit der Spannungsregler nicht die ganze Leistung (P= (Uin Uout) * I) alleine verheizen muss? Aber lass uns über die Dimensionierung der einzelnen Größen später Gedanken machen! Willst du mir mal die Eagel-Datei deines Schaltplanes mailen? Die Grundlagen sind ja soweit geklärt und wir können eigentlich mit dem Programmieren beginnen! Oder wo fangen wir an? Bzw. wo soll ich anfangen? Tutorial? Datenblatt? ... Noch ganz kurz was zur Verkehrssicherheit... Wenn unsere Schaltung doch nur mithört und eigentlich nur Kontakte parallel schließt oder öffnet (K1 und K2) dann hätten wir doch beim worstcase immer noch unsere herkömmliche Blinkfunktion! Oder? Grüße, Stephan
ich versuch schonmal ein paar sachen zu erklären: entprellen: geht auch mit dem timer interrupt, indem man z.b eine taste erst als gedrückt anerkennt, nachdem sie mehrere male den gleichen zustand hat. beispiel: wenn die taste bisher immer low war und dann wild zwischen low und high wechselt prellt die noch, nach dem prellen liegt dauerhaft (mehrere ints) high an, also prellen beendet, zustand wieder eindeutig assembler befehle: von atmel gibts eine referenz über alle asm befehle. die datei würd ich mal als pflicht beschreiben wenn man in asm programmiert: link: http://www.atmel.com/dyn/resources/prod_documents/DOC0856.PDF komplette datenblatt des avr durcharbeiten ist meiner meinung nach übertrieben. die sachen die man benutzt sollte man sich aber schon durchlesen um einen eindruck zu bekommen wie das alles abläuft und in welchen registern man was setzten muss oder kann clamp dioden: sowiet ich das verstanden habe werden clamp dioden (ganz normale diode in spezieller verschaltung) bei induktiven lasten eingesetzt. sie werden parallel zur last in sperrichtung geschalten und fangen den strom ab, der durch die eigeninduktion beim abschalten des stroms intgegen der normalen stromrichtung fliesst. dieser strom könnte sonst evtl den mc oder sonstige ic's beschädigen. such mal nach freilaufdioden, unter dem begriff findet sich mehr, ist wohl gebräuchlicher >Interrupt-Vektoren am anfang des pogrammcodes steht eine liste mit sprungbefehlen. einer für jeden interupt. der uC weiss ja nicht, wo jetzt die eigentliche int routine steht, aber er weiss an welcher stelle der sprung befehl zu dieser routine steht, weil das ja fest definiert ist. also spring der controller bei einem interrupt an die passende stelle in der interrupt tabelle und von da fürhrt der sprung befehl dann zur eigentlichen interruptroutine so, von dem rest hab ich keine ahnung, da lass ich die finger von ;) ich hoffe ich konnte soweit schonmal ein paar sachen erklären und hab hoffentlich keinen müll geschrieben =)
Hallo Stephan... Hallo auch Tobi und danke für deine Mithilfe... Dann werde ich auch mal wieder "kommentieren", da gibt es die wenigsten Missverständnisse, auch wenn es den Text aufbläht... > Mit Wiederholsperre meinst du also, dass der mC ein Signal erkennt > (rechter oder linker Blinker) und wenn das Signal „abgelaufen“ > (LO-Pegel) ist (wir haben ja den Blinktakt (HI LO HI LO etc)) er dann > noch eine Zeit x (z.B. 500ms) auf ein eventuelles nächstes Signal > (HI-Pegel) wartet. Ich meine das so: Die Wiederholsperre (gleiche Zeitdauer wie Schaltdauer) wird bei JEDEM Blinkerleuchten wieder auf Startwert gesetzt, läuft also erst ab, wenn der Blinker wirklich aus ist. Der Schaltzähler (und das Einschalten eines Relais) kann nur auf Startwert gesetzt werden, wenn die Wiederholsperre abgelaufen ist. Da beim Setzen des Schaltzählers auch die Wiederholsperre gesetzt wird, kann der Schaltzähler beim nächstfolgenden Blinkimpuls nicht "nachgesetzt" werden. > Werde mich mal über entprellen ausreichend informieren! ... Ja, aber nicht jetzt, bringt uns nur durcheinander. Wir brauchen hier eigentlich nicht entprellen, da wir nur im Zeittakt den Zustand der Blinkleitungen abfragen. Bei der Trägheit der niederohmigen Glühlampen gibt es da keine Störimpulse. > Ok, wir werden erstmal Kfz-Relais nehmen. Mir fehlt tatsächlich noch > verdammt viel Erfahrung und Know-how. Und an der Programmierung ändert > eine spätere Umrüstung auf Mosfets ja auch nichts. Jou, aber da halte ich mich raus... > Wäre es Sinnvoll, dass ich vor dem Programmierbeginn erstmal das > komplette Datenblatt durcharbeite? Im Prinzip ja, aber eigentlich nicht, denn das Datenblatt ist zu umfangreich, als dass man es auf Anhieb komplett verstehen kann. > Oder sind nur gewisse teile sinnvoll? Drucke dir die Tabelle der Befehle und die Tabelle der I/O-Register aus, die brauchst du immer wieder als Referenz. Dann solltest du über den Port Bescheid wissen, über Timer0 und seinen Vorteiler (Timer1 erstmal nicht), sowie über den ADC. Auch das Kapitel über die Interrupt-Vektoren soltest du verstanden haben. Dann solltest du in AVR-Studio ein neues Projekt anlegen, die Befehle aus der Befehlstabelle des Datenblattes in AVR-Studio eintippen und mit F1 die Hilfe dazu aufrufen. Das klärt schonmal viele Fragen. Es lohnt sich auch, über Hilfe, Themen an die Hilfe zum AVR-Assembler heranzukommen und mal die Direktiven anzuschaun. Bei denen funktioniert F1 leider nicht. > Spannungsteiler um auf 5V zu kommen und die Z-Diode um einen > Überspannungsschutz zu gewährleisten? Richtig? Ja, richtig... >Clamp-Dioden Auch Freilaufdioden genannt. Liegen parallel zu Induktivitäten in Sperrichtung und schließen die beim Ausschalten entstehende Induktionsspannung kurz, die sonst den Transistor killen würde. Siehe auch Tobis Erklärung... > Wäre auch ein 0 ... 10k Poti möglich? Oder warum wählt man ein 10 bis > 47k Poti? Wegen der letztendlichen Auflösung? Wonach richten sich diese > Werte? Typisch Missverständnis... Ich meinte ein 10k-Poti. Oder ein 22k-Poti. Oder ein 47k-Poti (darf auch 50k oder 100k haben). Die abgreifbare Spannung ist natürlich 0V bis 5V, denn es ist ja parallel zur Stromversorgung des Tiny15... Es sollte linearen Verlauf haben. Am besten ist ein kleines Trimmpoti für Schraubendreherbetrieb. >2 Kfz-Relais (Printausführung?) > Ich denke das ist die eleganteste Variante. Ja, gabs mal billig bei Pollin. Aber falls die nicht verfügbar sind, gehen auch andere 12V-Relais für 5A...10A, denn das Einschalten der kalten Lampen übernimmt ja immer der Blinkschalter bzw. der Blinkgeber. Das Relais schaltet erst ein, wenn die Lampen schon leuchten... >Interrupt-Vektoren >Oszillator-Kalibration > Gib mir bitte noch ein wenig Zeit. Muss noch einige Begriffe klären! Die Kalibration ist etwas komplizierter, dazu gibt es bei ATMEL eine gute ApplikationsNote, ich weiß aber jetzt die Nummer nicht, habe die bei mir alle umbenannt (sinnvolle "sprechende" Namen). Du solltest aber in der Lage sein, mittels Ponyprog (das nimmst du doch, oder?) das Kalibrationsbyte auszulesen und in die letzten beiden Bytes des Flash- Speichers einzutragen. main: sleep rjmp main > Ok, das scheint ja schon ganz ganz einfach anzufangen! ;) > Meinst du es ist sinnvoll, wenn ich erstmal das Tutorial durcharbeite, > damit ich wenigstens etwas Ahnung von diesem Element habe? In AVR-Studio eintippen und die kontextsensitive Hilfe (F1) bemühen... > Die Hauptschleife kann ich mir nur so erklären... > Der mC „schläft“ ist im „Stromsparmodus“. Nee, kein Stromsparmodus, denn dann würde kein Timer funktionieren. Wir nutzen daher nur den "idle"-Modus... Es geht auch besser, aber wir wollen ja noch was zum Optimieren haben, wird ja sonst langweilig. > Wenn die Interrupt Service > Routine abgelaufen ist, wird ja zu dem Programmpunkt „gesprungen“ bei > dem sie gerade ausgelöst wurde. Das wäre dann nach dem sleep! Richtig? Ja... > Rjmp main wird dann wohl heißen, dass er zu dem Label (nach Bascom) > main springt. Dort ist der erste Befehl wieder sleep. Also geht der mC > bis zum nächsten Interrupt wieder schlafen! Oder? Richtig... Die Labels funktionieren wie in BASIC. Nur dass wir keine Schleifen in Form von "do...loop", "for...next", "while...wend" oder so haben, sondern nur sowas wie "goto" (rjmp). Da gibt es aber auch noch "jmp" und "ijmp", aber nicht bei allen AVRs. Wir haben auch kein klassisches "if...then...else...endif", sondern verzweigen durch bedingte Sprünge, also Sprünge, die nur dann ausgeführt werden, wenn bestimmte Bits im Statusregister (Flags) bestimmte Zustände haben. Die Flags des Statusregisters (SREG) werden durch Vergleiche und Berechnungen beeinflusst. In der Tabelle mit den Befehlen kannst du nachlesen, welche Befehle welche Flags beeinflussen und welche Sprungbefehle (brxx) bei welchen Flags wirken. Auch über die Bedeutung und Funktion der Flags solltest du dich langsam sachkundig machen. > Aber durch was wollen wir den Interrupt auslösen also folglich die ISR > starten? Na durch den Überlauf des Timer0. Damit wir einen vernünftigen Einstellbereich am Poti bekommen, sollte der Timer etwa 25 mal in der Sekunde überlaufen. Der Timer wird vom Prozessortakt über einen Vorteiler getaktet (hochgezählt). Nach dem Wert 255 kommt der Wert 0, und genau dann löst die AVR-interne Logik den Timer0-Interrupt aus. Damit der Timer nicht wieder bei 0 anfängt zu zählen, müssen wir ihn in der ISR auf einen Startwert setzen, der der Differenz zu 256 beträgt. > Du schreibst das Hauptprogramm läuft in der Timer0_ISR. Jou. alle 40ms (also 25 mal je Sekunde) schaut der AVR nach, ob da nicht vielleicht Irgendwer den Blinkschalter betätigt hat... > Wäre da nicht ein Pin Interrupt angebracht? Weil der mC soll ja erst > dann anfangen zu denken, wenn er von dem linken oder rechten > Blinkereingang ein Signal bekommt?! Nö, mit Timer ist das einfacher. Außerdem nehme ich einen Pin-Int nur ungern zum Auswerten mechanischer (prellender) Schalter. > Oder habe ich da einen Denkfehler? Kann schon sein... > Habe mir noch gerade die Schaltung von dir angesehen und hätte dazu > eigentlich noch ein paar Fragen zu ein paar Kondensatoren und Dioden > (Clamp-Dioden Habe ich aber oben schon geschrieben). Du verwendest auch > vor dem Spannungsregler einen veränderbaren Widerstand! Das ist ein Varistor. Er soll mit der Drossel Spannungsspitzen begrenzen. Eigentlich ist das eine Provokation, damit die Profis sich mal dazu äußern sollen... > Ist der dafür > da, damit der Spannungsregler nicht die ganze Leistung (P= (Uin – Uout) > * I) alleine „verheizen“ muss? Nein... > Aber lass uns über die Dimensionierung der einzelnen Größen später > Gedanken machen! Jou... > Willst du mir mal die Eagel-Datei deines Schaltplanes mailen? Kann ich tun, nützt dir aber nicht viel, weil ich nur auf die Symbole geachtet habe, nicht auf die Bauform. So stimmen z.B. die Relais nicht. Auch die Drossel und der Varistor könnten andere Bauform haben. Ich werde die Eagle-Datei aber trotzdem hier mit anhängen. > Die Grundlagen sind ja soweit geklärt und wir können eigentlich mit dem > Programmieren beginnen! Bin eigentlich mit einem Entwurf schon fertig, wollte dir aber nicht die Freude verderben... > Oder wo fangen wir an? Bzw. wo soll ich anfangen? Übe erstmal den Umgang mit AVR-Studio. Projekt anlegen, ganz einfache Programmsequenzen schreiben, assemblieren, im Simulator laufen lassen. Fang aber nicht mit SLEEP an, das muss nämlich vorbereitet werden. Mach dich mit den Ressourcen des Tiny15 vertraut (Workspace-Fenster im AVR-Studio). > Tutorial? > Datenblatt? > ... > Noch ganz kurz was zur Verkehrssicherheit... > Wenn unsere Schaltung doch nur mithört und eigentlich nur Kontakte > parallel schließt oder öffnet (K1 und K2) dann hätten wir doch beim > worstcase immer noch unsere herkömmliche Blinkfunktion! Oder? Genau das war ja mein Ziel. Sonst hätte ich hier nicht mit gemacht! Das Schlimmste, was passieren kann, ist das Klemmen eines Relais. Aber auch ein Blinkschalter kann sich verklemmen... Sorry wegen des schlechten Zeilenumbruchs, ich habe im Editor geschrieben und dadurch sind einige Zeilen zu lang geraten... Gruß... ...HanneS... @Tobi: Schreib mir mal eine Mail, bekommst dann meinen Prog-Entwurf, dann können wir "an einem Strang ziehen" und widersprechen uns nicht bei Erklärungen...
Hallo Hannes, Hallo Tobi! Danke erstmal für die Eagle-Datei! Wollte mich nur noch mal melden... Bin Fleißig am lesen und am Probieren, damit ich, wenn wir das Programm schreiben, nicht ganz so auf dem "Schlauch" stehe. Arbeite gerade das Tutorial auf dieser Seite durch! Und ich kann nur sagen Assembler ist einfach nur ge..! Bei BASCOM habe ich länger gebraucht um bei einem Tastendruck eine LED zum leuchten zu bekommen! Immerhin fange ich an, zu verstehen was ich da überhaupt programmiere! Denke, dass mir nicht mehr all zu viel für unseren gemeinsamen "Start" fehlt. Erschwerend kommt für mich momentan hinzu, dass heute mein e-technik Studium angefangen hat... Ist im Moment eine recht stressige Zeit! Aber nichts desto trotz werde ich bzw. wir an diesem Projekt weiter arbeiten, auch wenn ich jetzt nicht mehr ganz so viel Zeit hinein Investieren kann. Habe nämlich noch keine Ahnung, was morgen und die Tage auf mich zu kommt! Habt bitte Verständniss bzw. Geduld! Gruß, Stephan
Hi... Tja, Stephan, das dauert alles seine Zeit... Ich hatte/habe momentan Probleme mit der Festplatte, daher ist neben vielen Mailadressen auch der Quelltext weg. Aber Tobi hat ihn ja noch, ich denke, der Quelltext könnte bald hier veröffentlicht werden, dann können wir mit der Diskussion beginnen. Alles Gute dann für den Start des Studiums... @Tobi: Wenn es dir nix ausmacht, kannst du mir ja die Dateien zurück schicken... Oder ich warte, bis du sie hier veröffentlichst. ;-)) ...HanneS...
ich hab dir alles rübergeschickt. die ehre, den code beizeiten zu veröffentlichen gebührt natürlich dem autor :)
Danke... Das zeigt wieder mal: Die beste Sicherheitskopie ist die Weitergabe... ;-)) Ich muss jetzt aber erstmal Eagle, AVR-Studio usw. installieren, habe aber im Moment auch nicht allzuviel Zeit... Die Neue Platte (40GB, im Laptop, mit FDISK von WIN98SE partitioniert) macht auch Probleme, musste c: schon wiederholt formatieren. Das nervt natürlich... ...HanneS...
Hi... @Stephan: Da von dir keinerlei Fragen betreffs Inbetriebnahme des AVR-Studio kamen ("wie macht man Dieses oder Jenes?"), nehme ich an, dass du entweder die wichtigsten Hürden genommen hast oder keine Zeit dazu gefunden hast. Egal, ich werde meinen Vorschlag jetzt hier zur Diskussion stellen. Ich habe keine Testschaltung aufgebaut und das Programm nicht im AVR getestet. Es können also noch Fehler drin sein, die wir dann sicherlich finden und auch beseitigen werden. ...HanneS...
Hallo! Meiner Meinung nach, habe ich die wichtigsten Hürden im AVR Studio genommen! Nur das Simulieren bereitet mir oft noch Kopfzerbrechen... Aber daran lässt sich ja noch arbeiten! Es ist halt alles etwas komplexer im Vergleich zu Bascom! Habe das Thema Bascom jetzt ganz abgelegt! Da wir im zweiten Semester in C Programmieren werden, wäre doch eine solche Hochsprache eine vernünfige Ergänzung zu Assembler?! Oder? Werde mir jetzt erstmal deinen Programmcode runterladen und schauen, ob ich das auch alles so verstehe! Würde dan versuche Jede Codezeile zu kommentieren, wie ich sie verstanden habe... Sonst ist der Lerneffekt ja nicht da... Hoffe der Anfangsstress im Studium wird sich in den nächsten Tagen etwas legen...!!! ;) Gruß, Stephan!
Sehe gerade, dass du schon alles ausführlichst kommentiert hast! Das ist absolut Vorbildlich! wow! Kann es sein das AVR Studio keinen ATTiny15 simulieren kann? Bei Simulator Device Setting (oder so ähnlich) ist der ATTiny15 grau unterlegt und nicht anwählbar?! Gruß, Stephan
mir ist gerad noch aufgefallen, dass wz nirgendwo initialisert wird. macht zwar so weit ich das sehe keine probleme (wird nichts ungewollt eingeschaltet) aber nach dem einschalten wird ein wenig sinnlos im interrupt rumgesprungen. das muss ja nicht sein :)
Hi... @Stephan: Müsstest mal hier im Forum nach +microsoft +simulator suchen. Da wird das Problem und die Lösung beschrieben. Kann auch sein, dass du AVR-Studio updaten musst, Version 4.08 oder neuer kann den Tiny15 simulieren... Du solltest dich nicht ausschließlich auf eine Programmiersprache festlegen, denn jede Sprache hat ihre Vorzüge und damit auch ihre Daseinsberechtigung. Zum "Rechnen" und zur "Datenverarbeitung" auf größeren Controllern muss es schon eine Hochsprache wie C oder auch BASCOM sein. Zum "Schalten" und zum direkten Umgang mit Timern, ADC und Interrupts macht sich Assembler besser, da ASM keinen Overhead erzeugt und der Code effizienter ist (gilt NICHT für Rechnerei und Datenströme). Allerdings hilft dir ASM gewaltig beim Verstehen der Controller-Architektur. Da ASM 1:1 in Maschinenbefehle umgesetzt wird, lernt man auch, wie effizient die verschiedensten Algorithmen sind. Dieses Wissen ist beim Umgang mit Hochsprachen unbezahlbar. Man lernt also ganz nebenbei, wie man unsinnige Ressourcenverschwendung in einer Hochsprache vermeidet. @Tobi: Stimmt, die verwendeten Register wurden nicht initialisiert. Das können wir aber im Rahmen der Optimierung tun, wenn Stephan halbwegs hinterher ist und den Code versteht... Ist zwar OT, aber die Partition C: meiner Festplatte hat sich schon wieder verabschiedet. Und wieder beim Kopieren von Dateien auf Laufwek F: (letztes logisches Laufwerk auf der erweiterten Partition). F: ist auch hinüber und enthält eine Menge unlöschbaren Müll, muss also auch formatiert werden. Wenn ich nur wüsste, woran das liegt (FDISK von W98SE??, BIOS vom Lappi??, zu wenig RAM (64MB)??, Festplattenfehler??). Langsam nervt das... Bit- & Bytebruch... ...HanneS...
hast du schon mal scandisk im extra lngsamen modus laufen lassen? vielleicht findet das ja fehler. zu wenig ram sollte das nicht sein, es sei denn der ram hat fehler, dadurch können sich dann auch bitfehler auf der platte einschleichen, die die komplette struktur durcheinander bringen kann. so weit ich mich erninnere hatten auch einige wenige fdisk versionen so ihr macken, am besten mit mit einem anderen (evtl auch kommerziellen) programm versuchen (kann man sich ja vielleicht irgendwo ausleihen ;) sind das die hier? http://www.microsoft.com/downloads/details.aspx?FamilyID=6c050fe3-c795-4b7d-b037-185d0506396c&DisplayLang=en
Hi, mir fiel auf, das der Timer in der Simulation nicht hochzählt und der Interrupt daher nicht aufgerufen wird. Ich verwende die 4.08 Build 338. Axel
<Zitat> ;Bei Vorteiler 1024 muss der Zählumfang etwa 63 betragen (das geht besser, da mehr Spielraum für Änderungen). ;Also entscheiden wir uns für Vorteiler 1024 und Zählumfang 63, der Startwert beträgt demnach 256-63. ldi tmp,256-63 ;Differenz bis zum Überlauf mov tsw,tmp ;in Timer-Startwert (Umweg über tmp, weil tsw als unteres Register kein LDI kann) out tcnt0,tsw </Zitat> ich habe die 256-63 in 255-63 geändert: ist zwar wurscht, jetzt sind es genau 40960 uSek., vorher waren es 40320 uSek. Axel
Hi... @Tobi: Danke für die Tips. Scandisk mit Oberflächenanalyse findet keine Fehler. Ich werde wohl zuerst mal das BIOS updaten. Vielleicht hilft das ja. Falls beim Kopieren auf F wieder alles stirbt, müsste der "Wiederaufbau" schneller gehen, denn diesmal habe ich ein Backup gemacht und auf CD-RW gebrannt... Ich habe eigentlich weder Lust noch Zeit für solche Spielchen, eigentlich müsste man Bill für seinen Murks verklagen... ;-(( Was MDAC betrifft, weiß ich das nicht genau, das wird es wohl sein. Mir ist das Problem und die Lösung in einem anderen Thread aufgefallen, daher verwies ich darauf. Als ich (vor längerer Zeit) bei der Installation von AStudio4.08 Probleme hatte, musste ich WIN98Se total neu installieren. @Axel: Also bei mir zählte der Timer im Simulator hoch, wenn ich mich recht erinnere. Ich schau's mir nachher mal an, Rechner funzt gerade mal (wer weiß wie lange noch...). Wenn nicht, dann haben wir was zu "optimieren". Lass uns aber erstmal warten, bis sich Stephan wieder meldet und die ersten Fragen stellt... ...HanneS...
Ups... Das kommt davon, wenn man während des Schreibens raus geht und sich verquatscht... Hi... @Axel: 255, 256... Hmmm ist in dieser Anwendung eigentlich Wurscht. Ansonsten bin ich der Auffassung, dass 256=0 entspricht und der Interrupt bei Erreichen von 0 ausgelöst wird. Das größere Problem (für den Anfänger) wird sein, den Tiny15 zu überreden, dass er mit 1,6MHz traben soll. gelingt das nicht, so dümpelt er mit unvorhersehbarem Takt um die 1MHz vor sich hin. Der, der den Chip per ISP programmiert, muss dazu ja mit seinem ISP-Programm das Calibrationsbyte aus dem Signature-Bereich lesen und ins Flash schreiben. Und das noch an die richtige Adresse. Aber auch diese Hürde werden wir zu gegebener Zeit nehmen... ...HanneS...
Hallo! AVR Studio läuft jetzt mit dem ATTiny15. Ein Update auf 4.10 hat Abhilfe geschaffen! >Da zum Ansteuern kein Dauersignal zur Verfügung steht, sondern >der Blinktakt des Blinkgebers, muss mit einer "Wiederholsperre" >gearbeitet werden. Diese wird bei jedem Blinken neu auf Startwert gesetzt, >und läuft als Count-down langsam ab. Nur wenn diese abgelaufen ist, >also der Blinker längere Zeit nicht aktiv war, wird das erste >auftretende Blinksignal den Ausgang einschalten und den Schaltzähler >auf Startwert setzen. Wenn ich ganz ehrlich bin, habe ich das mit der Wiederholsperre immer noch nicht so ganz verstanden. Gebe jetzt erstmal wieder, wie ich es verstanden habe. Wir definieren erstmal eine Blinkperiode als HI und LO (also Blinker an und Blinker aus) Mit einem HI-Level wird der Timer gestartet, der als Countdown fungiert. Der Countdown muss also länger als eine Blinkperiode sein, damit er bei dem nächsten HI-Level (zweite Blinkperiode) wieder auf seinen Startwert zurückgesetzt werden kann. Der optimale Countdowntimerzeit wäre also nur unmittelbar länger als die benötigte zeit für eine Blinkperiode. Optimierungsansatz: (Bitte erstmal nur als Vorschlag sehen! Muss ja erstmal das Programm richtig verstehen! Kann auch sein, dass ich da einen Denkfehler habe): Da die Zeit einer Blinkperiode messbar ist könnte man den Reloadwert des Timers dementsprechend anpassen. Oder vom mC ausmessen lassen. Dazu würde ich aber erst mehr schreiben, falls folgende Aussage zutrifft. So wie ich das jetzt verstanden habe z.B. wir haben eine Countdown von 6s, wäre es nicht möglich den Blinker in der Gegenrichtung zu aktivieren oder? Bin mal gespannt, ob ich das so alles richtig aufgefasst habe!? :) Bei der Reset Sprungmarke verstehe ich auch noch einiges nicht. Habe mich da wahrscheinlich auch noch nicht ausreichend informiert. Meine Abendlektüre wird heute das Datenblatt sein. Folgende Schreibweise ist mir irgendwie unklar: ldi tmp,(1<<al)|(1<<ar) Hebe bis jetzt nur Registerwerte gesehen die Binär oder Hexadezimal waren .?! Hat das irgendwas mit der Boolean Formula zu tun? Noch mal kurz zu den Hochsprachen . Denke ich werde jetzt erstmal bei Assembler bleiben und Hochsprachen wie C oder Bascom nur ergänzend benutzen! >Der, der den Chip per ISP programmiert, muss >dazu ja mit seinem ISP-Programm das Calibrationsbyte aus dem >Signature-Bereich lesen und ins Flash schreiben. Und das noch an die >richtige Adresse. Aber auch diese Hürde werden wir zu gegebener Zeit >nehmen... Ich kann auch Parallel High-voltage Programming nutzen... Bringt das in diesem Fall Vorteile? Gruß, Stephan
Hi... Ich glaube, dir ist etwas anderes noch nicht klar: Wir nutzen Timer0 (mit Reload tsw) nicht als Verzögerung allgemein, sondern als eine Art Taktgeber (Uhr). Die eigentlichen Timer realisieren wir als Ablaufzähler in Software, und zwar in Form der beiden Register sz und wz. Diese werden vom Timer runtergezählt (CountDown) und ggf. vom Programm auf Startwert gesetzt. Unsere "Timer" sind also selbstgebastelt und sollten nicht "Timer" genannt werden, da das zu Missverständnissen führen könnte, denn es sind einfache Register, die als CountDown arbeiten. Wir erlauben das Aktivieren eines Relais nur, wenn wz abgelaufen ist (und der Blinkschalter betätigt wird). wz wird aber immer wieder (also alle 40ms) auf Startwert gesetzt, solange eine Blinke (also die Blinkleuchten einer Seite) an ist. Sicher kann man den Startwert auch anders definieren, als mit dem Poti. Das würde das Programm aber komplizierter machen, wodurch es (als Anfänger-Tut.) unübersichtlicher wird. Diese "Optimierungen" kannst du also durchführen, wenn du dazu in der Lage bist... Vorher geht es darum, das hier zu verstehen. Änderungen machen wir später. Gegenrichtung... Du kannst den Blinker jederzeit in Gegenrichtung betreiben, dabei wird auch das andere Relais ausgeschaltet. Allerdings wirkt deine Blinkverlängerung dann nicht, es wird also nur so lange geblinkt, wie der Schalter betätigt ist. In einer späteren Version im Rahmen der Optimierung kann das gerne geändert werden... Die Schreibweise (1<<xy)|(1<<yz)... Das ist ein boolscher Term. Wir schieben eine "Eins" um den Wert von xy nach links und verknüpfen das OR (| ist der Operator für OR, siehe Hilfe zum AVR-Assembler) mit dem Wert, der entsteht, wenn eine "Eins" um yz Stellen nach links geshoben wird. Mit anderen Worten: Wir setzen die Bits xy und (OR) yz. Nun könnte man ja aus dem Datenblatt den BIN-Wert oder HEX-Wert (warum eigentlich nicht gleich dezimal???) ermitteln, der nötig ist, die richtigen Bits im Register zu setzen. Da blickt dann aber ohne Datenblatt niemand mehr durch. Deshalb verwende ich die Bitnamen des Datenblatts (auch in der ...def.inc-Datei von ATMEL definiert) und füge diese in den Quelltext ein. Nun kann man anhand der "sprechenden Namen" (die sind auch noch "verbindlich", da vom Hersteller definiert!) sofort erkennen, welche Bits gesetzt werden, also welche Funktionen geschaltet werden. Ich habe das anfangs auch mit 0x00 oder 0b00001111 gemacht, bis ich von Peter Dannegger (vielen Dank Peter!) gelernt habe wie es besser geht... Ob sich das nun "boolean formula" nennt, kann ich nicht sagen. Ich habe weder Abi noch Studium, nur Polytechnische Oberschule Klasse 10 und Facharbeiter. Hochvolt-Modus... Ist hier eigentlich nicht nötig. Hat aber den Vorteil, dass man damit den Reset-Pin als IN-Pin nutzen kann. Ich nutze ISP, allerdings mein eigenes Programm, ich war da mal zu blöd für Ponyprog und habe deshalb selbst was gebaut (basiert auf den Infos der Datenblätter). Calibration... Damit der Tiny15 mit 1,6MHz tuckert, muss sein persönliches Calibrationsbyte in das I/O-Register OSCCAL geschrieben werden. Dieses hat der Hersteller zum Einen in die letzte Flash-Zelle des neuen AVR (und zwar in das H-Byte und in das L-Byte) gelegt, und fix in den Signature-Bereich, Adresse 0, H-Byte (in den L-Bytes steht der Signature-Code). An den Signature-Bereich kommt nur ein Programmiergerät mit (PC-) Programmiersoftware ran. Per AVR-Programm kommt man da nicht ran. Man muss also mit dem ISP-Programm (Pony?) das Calibrationsbyte auslesen (dafür gibt es irgendwo einen Menüpunkt) und dieses vor dem "Brennen" in die letzten beiden Bytes des Flash-Bereiches (HEX-Dump) eintragen. Nur dann kann der erste Teil der Reset-Routine des AVR-Programms das Byte aus dem Flash lesen und ins OSCCAL-Register schreiben... Für deine Anwendung ist das nicht so relevant, die tuckert auch mit 0,8MHz noch gut. Dann ist eben der Einstellbereich größer... Mein ISP-Programm kalibriert beim Löschen eines Tiny12 oder Tiny15 automatisch, auch bei Mega8 usw., wenn diese auf 2MHz, 4MHz oder 8MHz internen Oszillator "geFUSEt" wurden. Ich möchte es aber nicht empfehlen, da es noch nicht fertig ist (wird es wohl nie). Es wurde auch auf andere Features verzichtet, die bei anderen Programmen Standard sind. Es werden auch nicht alle AVR-Typen unterstützt. Wenn man das EEPROM nutzt oder wenn es etwas präziser sein soll, dann muss die Kalibration schon stimmen. Schau mal bei wwwpunktbrummbaerhannespunktdepunktmd da liegt der Quelltext für einen Modellbau-Fahrtregler mit Tiny12. Das ist dann schon etwas komplexer... Bit- & Bytebruch... ...HanneS...
Hallo Hannes! Sorry, dass es wieder so lange gedauert hat, aber mir wächst hier einiges über den Kopf! >Die Schreibweise (1<<xy)|(1<<yz)... Macht mir immer noch Kopfzerbrechen... >Das ist ein boolscher Term. Wir schieben eine "Eins" um den Wert von >xy nach links und verknüpfen das OR (| ist der Operator für OR, siehe >Hilfe zum AVR-Assembler) mit dem Wert, der entsteht, wenn eine "Eins" >um yz Stellen nach links geshoben wird. >Mit anderen Worten: Wir setzen die Bits xy und (OR) yz. Das kann mein Kopf nicht so richtig verarbeiten... :) Ich habe zwar die passenden Operatoren mit der dazu passenden Beschreibung in der AVR Assembler Hilfe gefunden: Symbol Description ! Logical Not ~ Bitwise Not - Unary Minus * Multiplication / Division % Modulo (AVRASM2 only) + Addition - Subtraction << Shift left >> Shift right < Less than <= Less than or equal > Greater than >= Greater than or equal == Equal != Not equal & Bitwise And ^ Bitwise Xor | Bitwise Or && Logical And || Logical Or Aber irgendwie fehlt mir doch da das Verständnis! >Wir schieben eine "Eins" um den Wert von xy nach links OK, werde es mal so beschreiben, wie ich es verstanden habe bzw. wo ich nicht mehr weiter komme! Wir legen feste, dass der Operator << nach links schieben bedeutet! Mit der Eins wirst du wohl eine logische 1 meinen... Aber jetzt zu meinem Verständnisproblem... Welchen Wert hat xy? Und wo ist der Unterschied zwischen einem Logical Or und einem Bitwise Or (siehe Tabelle)? Du muss dir jetzt nicht den über Act geben und mir das alles erklären... Mir würde es schon reichen, wenn du mir ein paar links bzw. Buchtitel geben könntest, die das irgendwie verständlich beschreiben... Ich habe da irgendwie nur Skripte von irgendwelchen Unis für den Fachbereich Informatik etc. gefunden! Und so etwas verstehe ich einfach nicht! Wie hat dir Peter Dannegger das ganze näher gebracht??? >Wir nutzen Timer0 (mit Reload tsw) nicht als Verzögerung allgemein, >sondern als eine Art Taktgeber (Uhr). Die eigentlichen Timer >realisieren wir als Ablaufzähler in Software, und zwar in Form der >beiden Register sz und wz. Diese werden vom Timer runtergezählt >(CountDown) und ggf. vom Programm auf Startwert gesetzt. Nur nochmal zum Verständnis! Der Timer0 ist unser Taktgeber, der bstimmt, wie schnell gezählt wird, oder? Nehmen wir an, er zählt von 255 (Startwert) es könnte auch 100 sein runter... Bei 0 wird der Timer0 Interrupt ausgelöst... Gruß, Stephan!
bitwise or (| ) verknüpft bit für bit zwei zahlen miteinander. beispiel: zahl1: 01000110 zahl2: 10001100 ergebnis nach bitw. or: 11001110 logical or ( || ) kann nur eins von 2 ergebnissen haben. wahr oder falsch. wahr ist das ergenis, wenn nach dem bitweise or etwas grösser 0 rauskommt. falsch ist es, wenn das ergebnis 0 ist zu dieser zeile: (1<<xy)|(1<<yz) betrachten wir erstmal einen teil (1<<xy) wir haben eine 8bit variable mit einer 1 drin: diese hier: 00000001 jetzt sagen wir xy ist einfach mal 2. dann verschieben wir das ganze 2 mal nach links und füllen richts mit nullen auf: 1. schieben: 00000010 2. schieben: 00000100 das gleiche machen wir jetzt mit dem zweiten teil mit (1<<yz) sagen wir mal yz ist 4, dann ist das ergenis nach mal die eins weiterschieben das hier: 00010000 jetzt werden die beiden werte bitweise oder verknüpft 00000100 | 00010000 ------------ = 00010100 dadurch sind dann letztendlich die beiden bits xy und yz gesetzt.
Ok, so langsam kommt es! Nun mal an einem konkreten Beispiel aus unserer Blinkersteuerung! Mir ist da noch einiges unklar Der Code: ldi tmp,(1<<al)|(1<<ar) out ddrb,tmp lädt das Datenrichtungsregister nach diesem Bitmuster (1<<al)|(1<<ar) Die Variable al steht ja für Ausgang links und hat ja keinen wirklichen Wert Das gleiche gilt für die Variable ar (Ausgang rechts) Siehe Code: .equ el=pb0 ;Eingang links .equ er=pb1 ;Eingang rechts .equ al=pb2 ;Ausgang links .equ ar=pb3 ;Ausgang rechts Eigentlich wollen wir ja folgenden Wert 0b00001100 in das Datenrichtungsregister ddrb laden, da wir ja pb2 und pb3 als Ausgang konfigurieren wollen! Welchen Wert hat denn in unserem Fall al bzw. ar? Wenn ar den Wert 4 und al den Wert 3 hätte würde das ja alles gehen . ar = 4 al = 3 Wir betrachten den ersten Teil: (1<<al) Wir haben wieder unsere 8 bit mit einer 1: 00000001 Diese 1 wird um al (also 3) nach links verschoben. Als Ergebnis erhalten wir: 00000100 Nun betrachten wir den zweiten Teil: (1<<ar) Hier wird die eins um ar also 4 Stellen verschoben! 00001000 Da beide Teile mit einem bitw. Or verknüpft sind bekommen wir als Ergebnis: 00001100 Also den binärwert, den wir in das ddrb schreiben wollen! Aber wo bekommen ar und al die Werte 4 und 3 ??? Gruß, Stephan!
aus dieser zeile: in der datei stehen die ganzen richtigen werte für symbolische namen drin. (nur so nebenbei: portb ist auch nur einsymbolischer name. der uC hat für alles intern nur eine nummer, keinen namen. daher muss es irgendwo eine liste geben, die dazwischen vermittelt.) .include"tn15def.inc" such mal danach im avrstudio verzeichnis nach und schau dir sie mal an. noch einer kleiner fehler: "Diese 1 wird um al (also 3) nach links verschoben. Als Ergebnis erhalten wir: 00000100" man fängt bei bitpositionen bei 0 zu zählen an. du hast einmal zu wenig die eins geschoben. diese steht jetzt an bitposition 2, nicht 3. schieb die 1 einfach mal im kopf wirklich 3 mal. manchmal hilft es sich so etwas wirklich schritt für schritt klarzumachen. wenn man es dann einmal verstanden hat braucht mans ja nicht mehr :) 0. schieben: 00000001 1. schieben: 00000010 2. schieben: 00000100 3. schieben: 00001000
Aha, . Ich glaube jetzt hab ichs In der tn15def.inc steht: ; PORTB .equ PB4 =4 .equ PB3 =3 .equ PB2 =2 .equ PB1 =1 .equ PB0 =0 Und da wir am Anfang des Programms gesagt haben: .equ el=pb0 ;Eingang links .equ er=pb1 ;Eingang rechts .equ al=pb2 ;Ausgang links .equ ar=pb3 ;Ausgang rechts Hat also: al den Wert 2 und ar den Wert 3 Wenn ich jetzt richtig schieben würde bekäme ich als Binärzahl 0x00001100 Und das ist in unserem Fall richtig!!! Der Groschen ist gefallen!!! Danke! Jetzt muss ich nur noch die anderen Booleschen Terme verstehen, aber ich glaube das sollte jetzt klappen! Gebe mich direkt dran . Gruß, Stephan!
Da kommt doch schon die nächste Frage Ich habe zum Beispiel diesen Code: ldi tmp,(1<<aden)|(1<<adsc)|(1<<adfr)+7 ;ADC freilaufend mit Vorteiler 128 einschalten Ich setze also die Bits: aden um den ADC einzuschalten adsc um die erste Konvertierung zu starten adfr um den Freilaufmodus zu aktivieren ich vermute also, dass ich mit +7 den Vorteiler auf 128 setze! Aber wie rechne ich das? Ich müsste ja auf folgenden Binärwert kommen: 0x11100111 Für den Vorteiler 128 muss ich nämlich adps2 adps1 adps0 auf log. 1 setzen . Nun noch eine Frage zu diesem Codeteil: ldi tmp,(1<<adlar)+3 ;also "Left-adjust-result"-Bit setzen und Quelle 3 auswählen was ist mit left-adjust und right-adjust gemeint? Gruß, Stephan
erstmal was formales: zahlen, die du mit 0x am anfang schreibst sind hexadezimal, nicht benär. eine binärzahl schreib man wenn dann mit 0b am anfang. das führt sonst allzuschnell zu missverständnissen. ";ADC freilaufend mit Vorteiler 128 einschalten" wenn du aden, adsc und adfr gesetzt hast, hast du ja 11100000 soviel sollte klar sein. schnapp dir mal den windows taschenrechner im binär modus und mach mal plus 3. 3 in binär ist ja 00000111. wenn du die 3 zu der zahl von oben dazurechnest bekommst du 11100111. genau das, was rauskommen sollte. wenn das zählen oder rechnen im binäen zahlensystem unklar ist kann ich nur auf google verweisen. da sollte sich einiges zu finden. "was ist mit left-adjust und right-adjust gemeint?" ganz sollte das datenblatt lesen nicht verlernt werden auch wenn hier immer alles so schön erklärt wird :) das steht da im kapitel zum adc drin.
Ok, hätte das ganze nicht einfach nur überfliegen dürfen Habe das ganze jetzt so verstanden . Der ADC generiert ein 10-bit tiefes Ergebnis, welches im ADC Daten Register, ADCH und ADCL angezeigt wird. Standardmäßig ist das Ergebnis rechts gerichtet dargestellt. Optional kann es aber auch links gerichtet durch Setzen des ADLAR bits im ADMUX dargestellt werden. Wenn das Ergebnis links gerichtet und nicht mehr als 8 bit Genauigkeit erfordert, ist es hinreichend es zu lesen. Andernfalls, muss zuerst das ADCL gelesen werden, dann das ADCH, um sicher zu stellen, dass der Inhalt des Datenregisters zu der gleichen Umrechnung gehört. Da wir nicht mehr als 8 bit Genauigkeit benötigen, nehmen wir das links ausgerichtet Ergebnis um es direkt auslesen zu können. Somit sparen wir uns also einige Programmierschritte Zwar auf kosten der Genauigkeit, aber das sollte ja bei einem Drehpotentiometer zur Zeiteinstellung keine Rolle spielen Habe ich das richtig verstanden? Nur noch so eine theoretische Frage . Wäre diese Schreibweise auch möglich? ldi tmp,(1<<aden)|(1<<adsc)|(1<<adfr)+0b00000111 statt ldi tmp,(1<<aden)|(1<<adsc)|(1<<adfr)+7 Gruß, Stephan
Hi... Sorry, war unterwegs... @Tobi: Danke... > Wäre diese Schreibweise auch möglich? > ldi tmp,(1<<aden)|(1<<adsc)|(1<<adfr)+0b00000111 > statt > ldi tmp,(1<<aden)|(1<<adsc)|(1<<adfr)+7 Ja, denn ich habe den Vorteiler dezimal zusammengefasst. Hätte ich auch hex machen können, dann wäre es 0x07 gewesen. Richtig sinnvoll wäre aber Folgendes: ldi tmp,(1<<aden)|(1<<adsc)|(1<<adfr)+7|(1<<adps2)|(1<<adps1)|(1<<adps0) Da aber die drei unteren Bits den Vorteiler als "Nummer" repräsentieren, hasbe ich diese zusammengefasst. Bits, die unterschiedliche Features repräsentieren fasse ich nicht (mehr) zu einer Zahl zusammen (weder bin, hex, okt noch dez), sondern nenne ihre Bitnamen im Quelltext, damit ich nicht bei jeder (kryptischen) Zahl im Datenblatt nachschaun muss. Sicher ist es einfacher, "ldi 0b11100111" zu schreiben, aber den Code kann niemand mehr ohne Datenblatt nachvollziehen... Du fragst,was Peter D damit zu tun hat? Nunja, er bemängelte das am Quelltext eines anderen Forum-Teilnehmers. Und ich zog mir diese Jacke an, denn ich war da auch nicht besser! So einfach ist das... Das mit dem ADCLAR hast du richtig erkannt. Ist ein super Feature, was die Classics noch nicht hatten... Ich hoffe, dass ich jetzt nix vergessen habe, Tobi hat ja schon viel geklärt... Gruß... ...HanneS...
>Wir brauchen also 25 Interrupts je Sekunde, also 25Hz. Bei einem Prozessortakt von >1,6MHz brauchen wir alle 64000 Takte einen Timer0-Überlauf. Bei Vorteiler 1:256 >brauchen wir einen Timer-Zählumfang von 250 (das geht). >Bei Vorteiler 1024 muss der Zählumfang etwa 63 betragen (das geht besser, da mehr >Spielraum für Änderungen). >Also entscheiden wir uns für Vorteiler 1024 und Zählumfang 63, der Startwert beträgt >demnach 256-63. So nun habe ich noch ein paar Fragen zur Dimensionierung des Vorteilers! Klar, könnte man das ganze so als gegeben ansehen. Es ist ja auch verdammt gut und deutlich beschrieben! Aber ich würde ganz gerne noch einmal zu allem Kommentare abgeben Fragen stellen und alternative Beispiele auflisten, damit ich das ganze auch tiefgründig verstehe! Noch einmal zum allgemeinen Verständnis. Wir arbeiten mit Timer0! Timer0 macht eigentlich nichts anderes als nach einer gewissen Zeit einen Interrupt auszulösen! Diese Zeit (die Zeit nachdem ein Interrupt ausgelöst wird) kann durch ändern des Vorteilers (Pozessortakt/Vorteiler=Timer0Takt) und durch den Startwert des Timer0 (Bei 255 bzw. 256 (gesehen als 0) läuft er ja über! Löst also einen Interrupt aus) frei konfiguriert werden! Timer0 zählt also ein Register in einem Vordefinierten Takt bis 255 hoch Nehmen wir an, wir wollen 50 Interrupts pro Sekunde haben! Also muss unser Timer0 mit 50 Hz arbeiten Wir nehmen an, wir hätten einen Prozessortakt von 1,5 Mhz. Folglich brauchen wir alle 30000 Takte einen Überlauf! Diese könnten wir mit folgenden Konfigurationen erreichen: Ich spiele jetzt einfach mal jedes Szenario durch: Vorteiler 1: Wir hätten einen Timer Zählumfang von 30000! Das geht nicht, da wir einen maximalen Zählumfang von 255 haben! Vorteiler 8: Wir hätten einen Timer Zählumfang von 3750! Das geht nicht, da wir einen maximalen Zählumfang von 255 haben! Vorteiler 64: Wir hätten einen Timer Zählumfang von 468,75! Das geht nicht, da wir einen maximalen Zählumfang von 255 haben! Vorteiler 256: Wir hätten einen Timer Zählumfang von 117,1875! Das würde gehen, da 117,1875 <= 255 ist! In diesem Fall müssten wir den Startwert auf 256-117 setzen! Vorteiler 1024: Wir hätten einen Timer Zählumfang von 29,296! Das würde gehen, da 29,296 <= 255 ist! In diesem Fall müssten wir den Startwert auf 256-29 setzen! >Wir wollen etwa 5s als Maximum. Das Poti bringt Werte von 0...255. Diese teilen wir durch >2, macht 0...127. >Da kleine Werte sinnlos sind, addieren wir 32 dazu, das ergibt Werte von 32...159. Bei 25 >Hz Timer0-ISR-Takt sind das 1,28s...6,36s, also ein guter Einstellbereich. Diesen Abschnitt verstehe ich irgendwie nicht richtig Das Poti bringt Werte von 0 bis 255, da wir uns auf left-adjusted geinigt haben. Somit haben wir eine Genauigkeit von 8 bit also 1 byte also von 0 bis 255! Aber warum teilen wir durch 2? Um den Einstellbereich zu halbieren? Oder änderst du so nur ungefähr die Einstellobergrenze, weil wir ca. 5s als Maximum angegeben haben? Um genau auf 5s zu kommen wäre doch die Obergrenze 125, oder? Nur eine Verständnisfrage .? Da Hz=1/s haben wir pro Timer-Takt also 0,04s! Wenn er also von 255-32 bis 255 hoch zählt vergehen dann also 1,28s bzw. wenn er von 255-159 hoch zählt 6,36s bis der Timer0-Interrupt ausgelöst wird! Gruß, Stephan!
Hi...
Die Timer-Vorteilerei habe ich jetzt nicht nachgerechnet, die
Gedankengänge sind aber richtig...
In deinem letzten Satz ist folgender Irrtum:
0,04s sind nicht der Timer-Zähltakt, sondern der Timer-Überlauf-Takt,
da sind die "255-32" also schon drin... ;-))
ADC: Das Poti liefert 0...255, uns reicht aber 0...127. Denn einen
höheren Einstellbereich brauchen wir nicht. Außerdem brauchen wir
"Platz im Byte" für den Offset...
Man muss auch nicht immer die höchste erreichbare Auflösung nutzen, die
stimmt eh' nur selten. Oder liest du am Digitalmultimeter auch noch die
letzte Ziffer ab?
Da Werte von 0...25 bei INT-Takt von 25Hz unter einer Sekunde liegen,
können wir diese zum Einstellen nicht gebrauchen. Damit der mechanische
Stellbereich aber nicht verschenkt wird, könnte man einerseits einen
Widerstand zwischen Potianfang und GND schalten, oder einfach per
Software den Bereich verschieben. Dies erreichen wir durch Addition
eines Offsets. Damit dafür im Byte noch Platz ist, hatten wir den
8-Bit-Wert ja durch 2 geteilt, wodurch ein 7-Bit Wert entstand bzw.
noch Platz für eine Addition von max 128 ist. Die Zahl 32 als Offset
hatte ich willkürlich gewählt, es ist ein "runder" Wert (2^5). Wenn
du meinst, der Stellbereich soll erst bei 2s beginnen, dann ändere es
auf 50... Dann reicht der Stellbereich eben bis
(50+127)/25 Sekunden...
> Um genau 5s zu erreichen...
Jou, die Obergrenze wäre 125. Da wir aber mit Binärzahlen arbeiten, ist
125 ein "krummer" Wert. 128 ist "rund" (2^7) und da die 0 mit zählt
geht es eben nur bis 127. 128 wäre dann (bei 7-Bit) wieder 0.
Wir Menschen mögen das Dezimalsystem, also 0...9 und die
Zehnerpotenzen. Das liegt vermutlich daran, dass wir an jeder Hand 5
Finger haben (6 wäre günstiger, denn 12 ist besser teilbar als 10!!!).
Rechner haben aber nur 2 Zustände (binär, dual), weshalb sie
vorteilhaft mit 0 und 1 und Zweierpotenzen arbeiten. Zwinge ich einen
Rechner, dezimal zu rechnen, so rechnet er sich die Werte in binär um,
rechnet binär, und wandelt sie in dezimal zurück, damit wir das nicht
merken... Und das erfordert sehr viel Rechenarbeit, die in einem PC
berechtigt ist, auf die ich aber in einem MC nach Möglichkeit
verzichten möchte. Daher versuche ich, soweit möglich, beim
Programmentwurf binär zu denken...
Das geht natürlich nicht immer, aber wo es geht, da mach ich das.
...HanneS...
"Wir Menschen mögen das Dezimalsystem, also 0...9 und die Zehnerpotenzen. Das liegt vermutlich daran, dass wir an jeder Hand 5 Finger haben (6 wäre günstiger, denn 12 ist besser teilbar als 10!!!)." Wesentlich besser für das Verständnis MC und Binärsystem wären eher 4 Finger gewesen - dann hätten wir statt dem Dezimalsystem das Oktalsystem, kein Mensch würde dem Dezimalsystem mehr als theoretisches Interesse entgegenbringen. Und dann gäbe es auch keine Probleme mit Binär oder Hex (obwohl, Hex würde dann ja wahrscheinlich auch nicht gebraucht, oder?)
Hallo... So nun geht es mit den Verständnisfragen weiter :) Betrachten wir folgenden Code: in tmp,pinb ;den Zustand von den Eingängen einlesen andi tmp,(1<<el)|(1<<er) ;nur die Eingangsbits stehen lassen, Rest auf 0 setzen ich lese also das komplette pinb Register ein Nun mal ein paar Fälle, ob ich das ganze richtig verstanden habe: Da ich ja das komplette pinb Register einlese könnten ja auch noch andere bits auf log. 1 stehen Nehmen wir an pinb = 0b00101001 Da uns ja nur der Eingang links (el) und der Eingang rechts (er) interessiert erstellen wir eine Maske. In unserem Fall 0b00000011 und verknüpfen diese mit einem logischen UND (andi). In unserem Beispiel würden wir also folgendes Ergebnis erhalten: Beide Binärzahlen werden mit einem logischen UND verknüpft: 0b00101001 (haben wir aus unserem pinb Register gelesen) 0b00000011 (haben wir als Maske definiert) --------------- 0b00000001 (erhalten wir durch die UND (andi) Verknüpfung Habe ich das richtig verstanden ? tst wz ;Ist die Wiederholsperre aktiv (ungleich 0)? brne takt1 ;Springe nach "takt1", wenn Wiederholsperre nicht 0 ist, also aktiv ist Der Befehl prüft, ob der Inhalt des Registers (in unserem Fall wz) gleich Null oder negativ ist, indem der Inhalt des Registers wz mit sich selbst UND-verknüpft wird. Dabei bleibt das Register wz unverändert. Wenn der Verglich ungleich 0 (also die Wiederholsperre noch aktiv ist! Sie zählt ja noch runter) ist wird das Zero Flag gelöscht. Der darauf folgende Befehl brne takt1 prüft, ob das Zero Flag 0 ist! Falls es Null ist (was so wäre, wenn die Wiederholsperre noch aktiv ist) wird zu dem Label takt1 gesprungen! Hoffe auch das richtig verstanden zu haben?! Gruß, Stephan!
Hi, Entschuldigung das ich mich einmische, vielleicht ist ja jemand so nett und bringt ein Teil der Erklärungen ins Wikki unter. Ich denke es hilft einigen Leuten weiter. Mfg Dirk
@stephan: hört sich IMO alles korrekt an! @dirk: wäre die frage was für andere relevant sein könnte
Hi... @Stephan: Lassen wir gelten... (Deine Überlegungen stimmen...) @Dirk: Ich bin leider beim Wiki "noch nicht angekommen". Außerdem fühle ich mich nicht kompetent, ein Tutorial zu schreiben. Ich denke auch, dass dieses Projekt nicht gerade zum Nachbau empfohlen werden kann, denn es widerspricht meiner Meinung nach der STVZO. Also meinem Trabbi tu ich das nicht an. Ich bin auch der Meinung, dass man dieses Projekt nicht braucht... Ziel des Projektes ist es lediglich, zu zeigen, dass AVR-Assembler nicht so schwierig ist, wie viele "BASCOMmer" denken, und dass Assembler zum Schalten (nicht aber zum Rechnen) seine Vorzüge hat, da man sieht was man tut... Falls du es für sinnvoll hältst, dann setze doch im Wiki einen Link auf diesen Thread. Denn diesen Dialog (Multilog???) möchte ich nicht zerreißen... Gruß... ...HanneS...
Hallo... So nun vielleicht nochmal was allgemein zu diesem Projekt, damit nicht ganz der Sinn verloren geht... ;) Hannes Kritik an der Verkehrssicherheit (dazu aber später mehr...) ist absolut berechtigt, möchte aber etwas zu dem Projektgrundgedanken sagen um vielleicht alles etwas zu entschärfen! Über den Nutzen diese Projektes lässt sich streiten... Fast alle neuen Mittelklasse bzw. Oberklasse Wagen haben bereits eine solche Ansteuerung des Blinkers... Es ist also nicht ganz so aus der Luft gegriffen. Ob man diesen "Luxus" wirklich braucht ist natürlich fraglich!? Das muss jeder selbst für sich herausfinden. Ehrlich gesagt wäre mir die Zeit mein halbes Armaturenbrett für diesen Luxus auszubauen zu schade Mein Golf hat beulen 15 Zoll Stahlfelgen mit Radkappen und tuckert mit 75 PS ohne Frontspoiler und Heckschurze oder sonstigem Klimbim friedlich über die Autobahn von A nach B . Letztendlich werde ich es natürlich doch machen nicht getrieben, von der Gier ein Super extra Special in meinem Auto zu haben, sondern um den Erfolg nächtelangen Lesens und Denkens real live und in Farbe (gelb ) zu sehen. Ob das dann da drin bleibt steht wieder auf einem anderen Blatt Ich stelle mir nur gerade vor, ich müsste zwei mal zum TÜV fahren, weil z.B. so etwas bemängelt wird. Nun zu dem Grundgedanken Ich unterhielt mich mit einem Bekannten allgemein über die heutige Kfz Technik und die immer weiter zunehmende Verwendung von mC in Autos und die Vernetzung verschiedenster Datenpunkte über Bussysteme wie CAN etc. So kam man irgendwann auch mal auf diese Blinkersteuerung Und ich dachte mir WOW das dürfte doch für einen Anfänger wie mich zu realisieren sein! Zusätzlich haben mich folgende Umstände motiviert In gewissen Foren (Tuning Szene wie es auch immer heißt) gibt es Leute die eine solche Schaltung schon auf gewisse Weise realisiert haben. 1. Kompletter analoger Schaltungsaufbau 2. Als Relaisschaltung (Man wird wohl durch das klackern der verschieden Hilfsrelais für Selbsthaltungen und Timer nervlich ziemlich strapaziert.) Die gerade aufgelisteten Schaltungen werden für verdammt viel Geld ca. 30 bis 40 EUR verkauft. Um direkt dem vielleicht nun aufkommenden kommerziellen Gedanken unseres Projektes entgegenzuwirken möchte ich einbringen, dass dies ein offenes Forum und ein frei zugängliches Projekt ist und sich jeder eine solche Schaltung mit mC, nach diesem bis jetzt rund 70 Beitrag starken Thread, selbst basteln kann Ok, nun weiter zum Grundgedanken . Nachdem mir der oben beschriebene Sachverhalt erklärt wurde waren meine Worte: Ok, das ganze realisiere ich für unter 10 EUR mit mC und dann läuft das gescheit! (Löten muss natürlich jeder selber!) Vielleicht etwas überheblich für einen Anfänger wie mich :) Aber so setze ich mich an BASCOM und fing an zu Programmieren (ich war eigentlich nie BASCOMmer War gerade in meiner Programmiersprachenfindungsphase @ Hannes ;) ), bis ich mit einem Beitrag diesen Thread startete und mich zwei Leute Hannes und Tobi auf den richtigen Weg leiteten . Nochmal DANKE!!!!! Und ehrlich gesagt bin ich recht froh über diesen Anfang! - Nun lerne ich Assembler - verstehe so überhaupt mal, was so ein mC wirklich macht - fange an logische Zusammenhänge zu verstehen - etc. Nun wieder zurück zum Projekt. Vielleicht ist es gar nicht so schlecht, dass es so ein Brennpunktthema in Bezug auf Verkehrssicherheit und EMV etc. ist So werden sich auch Gedanken gemacht, Fehlerquellen zu minimieren bzw. auszuschließen! z.B statt auftrennen --- > mithören und parallel schalten Für eine offizielle Zulassung sehe ich schwarz, da das ein relativ hoher Kostenfaktor ist. Aber vielleicht können wir Prüfungsbedingungen simulieren und Informationen über diese diversen EMV Vorschriften und Zulassungen etc. einholen und unsere Schaltung nach diesen Grenz und Richtwerten optimieren. Zwar ist es keine offizielle Zulassung, aber wir könnten mit gutem Gewissen sagen, dass wir ein Projekt von 0 bis 100% (theoretische Marktreife) durchgezogen haben! Warum ich das alles schreibe ??!! Hoffe das Hannes jetzt nicht mehr ein ganz so schlechtes Gewissen hat... :) Und das Ganze Projekt auch noch einen neuen Sinn @Hannes, Tobi und Dirk: Vielleicht können wir nach diesem Projekt aus diesem Multilog ein Tutorial zusammenstellen, das veröffentlicht werden kann Natürlich nur wenn Lust und Zeit besteht! Noch einmal besten Dank an Hannes und Tobi und alle andren für die bisherige tolle und kompetente Unterstützung! Viele Grüße, Stephan
Hi Stephan... Es steht dir frei, das, was du hier gelernt hast, zu einem Tutorial zusammenzufassen und im WIKI zu veröffentlichen. Jedoch habe ich Bedenken, dass das dann auf Anhieb auch von einem Neueinsteiger verstanden wird. Hier im Thread ist es ja gerade das (teils überspitzte) "Frage und Antwortspiel", was zum Verständnis beiträgt. In einem Tutorial hätten wir Vieles vergessen zu erwähnen... Übrigens: Die Art, wie wir die gestellte Aufgabe lösen, ist nur eine von vielen möglichen Lösungen und keinesfalls die optimale... Jeder Programmierer (falls wir uns so nennen dürfen) löst das Problem etwas anders, und das unabhängig von der verwendeten Programmiersprache. Sicher gibt es auch Leute, die dafür einen Mega16 und BASCOM bevorzugen... (böser Hannes...) Bit- & Bytebruch... ...HanneS...
Hallo alle zusammen...!!! So nun wollen wir mal etwas optimieren Punkt 1: Wir haben das Problem, dass wir während einer automatischen Blinkphase nicht durch antasten automatisch in die Gegenrichtung blinken können. Momentan müssten wir manuell in die Gegenrichtung blinken. Lösungsvorschlag: Siehe Kommentare ****NEU**** Punkt 2: Angenommen wir haben die Nachblinkzeit auf 6 Sekunden stehen (eigentlich ausgeschlossener Extremfall). Habe das ganze jetzt mal simuliert und festgestellt, dass wenn das Nachblinken abgelaufen ist (also sz = 0 ist), ja noch das wz einen relativ hohen Wert hat! Im schlechtesten Fall also auch 6 Sekunden, da ja der Reloadwert von der gleichen Quelle kommt . Sollten wir in diesen 6 Sekunden erneut in die gleiche Richtung blinken wollen, ist das automatische Nachblinken nicht möglich. Auch nach diesem manuellen Nachblinken wäre die Wiederholsperre auf 6 Sekunden... Kurze Zusammenfassung: Falls zweimal automatisch in die gleiche Richtung geblinkt werden soll, muss eine Pause von 6 Sekunden zwischen diesen beiden Blinkvorgängen liegen Lösungsvorschlag: Wir setzen die Wiederholsperre auf eine Konstante. Angenommen eine Blinkperiode dauert 1 Sekunde (müsste man genau messen). Also setzen wir die Wiederholsperre auf 1,2 Sekunden. Das wären dann 30 Timer0 Interrupts. Habe das noch nicht an dem Programm geändert, weil ich da eigentlich noch eine größere Idee habe. Durch den parallelen Programmiermodus hätten wir ja noch den RESET Pin über . Wie sieht es aus, wenn wir unserem Programm einen Initialisierungsmodus spendieren?! Wenn diese Tast (SMD-Taste) gedrückt wird und gleichzeitig geblinkt wird, die Zeit für die Wiederholsperre berechnet und als Konstante für das Hauptprogramm übernommen?! Was haltet ihr von der Idee? Stelle den Code geänderten Code jetzt mal zur Diskussion .! Es wurden nur Sachen hinzugefügt! Ich habe nichts weggenommen! Alles was von mir geändert wurde ist mit ****NEU**** gekennzeichnet! Gruß, Stephan
Hi... Das mit dem Merker kann man machen, ich habe es aber mangels Zeit nicht genau unter die Lupe genommen. Wiederholsperre als Konstante ist gut. Da sie bei jedem Timer-Int auf Start gesetzt wird, wenn eine Blinkseite an ist, muss sie nur die Aus-Phase überdauern. Setzt man sie auf etwa eine volle Periode (also Aus-Phase und Ein-Phase), bleibt genug Spielraum in beiden Richtungen. Sie "übersteht" also (auch bei leicht abweichenden Blinkfrequenzen) garantiert die Aus-Phase, gibt aber einen erneuten Zyklus schnell genug wieder frei. Vom Reset-Pin halte ich garnix! Nicht jeder hat ein STK500 und kann auf den Reset-Pin verzichten. Es ist auch nicht erforderlich. Hast du denn meine Vorlage und deine Änderung mal praktisch getestet? Dazu reicht ein Steckbrett mit dem Tiny15, LEDs (mit Widerständen) als Relais-Simulation, zwei Taster als Blinkschalter-Sim., mit denen auch der Blinkgeber simuliert wird. Die Taster müssen natürlich gegen Vcc (+5V) geschaltet werden, mit Pull-Down-Widerständen nach GND. Da dann alles mit 5V betrieben wird, wird die Schaltung recht einfach... Denn jetzt wird es wirklich Zeit, dass du das Programm (und vor allem die "Optimierungen"!) in Echtzeit im AVR testest... Gruß... ...HanneS... (der jetzt weiter mit der Dokumentation zum Servo-Projekt kämpft...)
Hallo... Die Teile werde ich mir noch bestellen müssen. Diese Woche wird es wohl nur für simulationen reichen. Habe das Programm noch etwas erweitert. Mit NEU gekennzeichnet. Statt den Reset Pin zu nehmen kommen noch zwei Taster an die beiden Eingänge! Eigentlich würde auch ein Taster, der mit beiden Eingängen verbunden ist reichen.... Wenn diese beiden Taster länger als 5s also 125 Interrupts gedrückt wurden springt das Programm in den Config modus. (gekennzeichnet mit dem label xxx) Was hälst du davon? Ist das so machbar, oder programmiert man das anders? Oder ist das zu Fehleranfällig? Wobei die Situation (log 1 auf beiden Eingängen über 5 Sekunden) im regulären Betrieb nicht vorkommen kann! (vielleicht hat unser "Blinksignal", doch noch Vorteile) Heute Abend werde ich mich dann um die Signalauswertung kümmern... Habe da auch schon ein paar Ansätze! Gruß, Stephan (der so langsam absoluter Assembler fan wird...)
Hallo... @Stephan: > Die Teile werde ich mir noch bestellen müssen. Diese Woche wird es > wohl nur für simulationen reichen. Dann lass uns mit Erweiterungen warten, bis du den Testaufbau (mit Tastern und LEDs) hast und die Änderungen prüfen kannst. Es schleichen sich sonst Fehler ein, nach denen wir uns dumm und dämlich suchen. Ich habe nämlich keine Zeit, jede Idee von dir theoretisch durchzutesten und auch keine Lust, eine Testplatine anzufertigen für ein Projekt, das ich selbst nicht realisieren möchte. Du willst das Projekt, du willst es optimieren, also brauchst du den Testaufbau... Ich bin sicher, dass noch einige Fragen zu klären sind, bis du das erste Programm in den AVR bekommst... Und das macht sich besser mit einem einfachen, (fast) fehlerfreien Programm. Ich habe mir deinen neuen Entwurf nicht angesehen und nehme daher auch keine Stellung dazu... @Axel: Warnblinker??? - Leiten wir auf Scheinwerfer um... ;-)) Neenee, Spaß beiseite... Bei der Urfassung des Programms passiert folgendes: - Erster Durchlauf: Blinken wird erkannt, Relais gesetzt, Wiederholsperre aktiviert - Zweiter Durchlauf: Gegenrichtung wird erkannt, Relais werden gelöscht - Weitere Durchläufe, bei denen die Blinker leuchten: Wiederholsperre wird bei jedem Blink auf Start gesetzt, wodurch die Anlage nicht wieder aktiviert werden kann. Dies hatte ich in der Urfassung berücksichtigt. Zugegeben, Stephans Erweiterung hatte ich nicht auf die Warnblinkerei überprüft. Dashalb ist es unbedingt notwendig, dass sich Stephan die Hardware zulegt und mit praktischen Tests beginnt. Gruß... ...HanneS...
@Hannes Ok, du hast recht! Da ich kein Steckbrett habe, werde ich das wohl auf eine Streifenrasterplatine realisieren! Werde mir ersteinmal ein paar Taster zulegen! LEDs (unter 20mA) mit den dazu passenden Vorwiderständen ein paar Tiny15 etc. Wenn ich die Bauteil alle zusammen habe, werde ich noch eine Bauteilliste ins Forum posten... Kannst ja mal einen Blick drauf werfen, wenn du Zeit hast. Eine Eagle Schaltplan wird natürlich auch direkt mit dran gehangen. Habe nämlich noch kein wirkliche "Grundsortiment" und dann wäre es doof, wenn es an einem fehlenden Bauteil scheitert... ;) Du hättest auch kein Interesse an einer fertigen Schaltung? Würde dir eine als "Andenken" an dieses Projekt schicken, wenn es soweit ist...! :) Gebe mich jetzt mal an den Schaltplan....! Gruß, Stephan
Hi... Mit Steckbrett hantiere ich auch selten. Streifenplatine ist gut, dazu ein paar billige IC-Fassungen "GS 8" und auch größere... ein paar Kontaktbuchsen "SPL 20" (lieber ein paar mehr) Poti "RT 10l47K" Low-Cost-LEDs "LED 3mm rot/grün/gelb" Widerstände 220 Ohm für LEDs "1/4W 220" Widerstände 3,3k bis 10k für Reset "1/4W 3,3k" Elkos "rad 10/35" für Betriebsspannung Keramik-Kondensatoren für Betriebsspannung "Kerko 100n" oder besser in SMD "X7R-G0805 100N" (gleich ein paar mehr, brauch man immer!) Tiny15 "ATtiny 15L DIP" Batteriehalter für 4 R6-Zellen und einen Satz R6-Akkus und Ladegerät oder ein Netzteil 5V oder einige Festspannungsregler "µA 78L05" und ein 12V-Netzteil "Taster 3301B" als Taster für Testaufbauten Ich bin sicher, dass noch was fehlt, aber das Genannte wirst du immer wieder brauchen. Mit den "SPL 20" und einer Streifenplatine hast du im Handumdrehen ein kleines Steckbrett (Testplatine) nach deinen eigenen Bedürfnissen aufgebaut (siehe meine Testplatinen). Zum Verdrahten eignet sich 0,5mm-Schaltdraht bzw Klingeldraht vom Baumarkt (0,6mm) Alle Bauteilbezeichnungen in "Anführungszeichen" sind Bestellbezeichnungen von Reichelt. Viel Erfolg... ...HanneS...
ich bevorzuge für so etwas ein steckbrett. geht schneller aufzubauen und man kann schnell mal austesten, was passiert wenn man etwas ändert. der liste von hannes hab ich im moment nichts hinzuzufügen - die hört sich schon mal gut an! zu meinen steckbrettern siehe auch hier: http://www.der-hammer.info/hvprog/bilder/prototyp.jpg
Hi... @Stephan: Habe noch etwas vergessen: --- Schnipp ..... Du hättest auch kein Interesse an einer fertigen Schaltung? Würde dir eine als "Andenken" an dieses Projekt schicken, wenn es soweit ist...! :) --- Schnapp ..... Ich werde zu gegebener Zeit entweder mein Steckbrett vorkramen oder eine allgemeine Tiny15-Testplatine fräsen, um das Programm (und auch andere) mal schnell testen zu können. Am finalen Gerät habe ich keinerlei Interesse. Das tu ich meinem Trabbi und seinem Fahrer nicht an. Ich schaffe es noch selbst, den Blinker ein- und auszuschalten, denn da bin ich im Training, denn ich muss ihn auch nach jeder Kurve selbst ausschalten (die mechanische Lenksäulenautomatik hat er nicht, ich vermisse sie aber auch nicht)... Brauchst also keins für mich mit zu bauen, es wäre schade um das Porto... @Tobi: Was in der Liste fehlt, merkt man erst, wenn das Zeugs geliefert wurde. Laut Murphy ist das immer so... Ich könnte jetzt Widerstände in Hunderterpacks in E6-Reihe empfehlen, aber das bringt nix, es weiß ja niemand, wie lange der Bastel/Entwickel-Trieb dauern wird. Ich habe mich recht kostengünstig bei Pollin eingedeckt, besonders hilfreich war das SMD-C-Sortiment. Da war ein Gurt Tantalelkos 3,3µF und ein Gurt Keramik-Vielschicht-Chipkondensator 470nF dabei. Die setze ich in der Stromversorgung der AVRs ein. 100nF würde reichen, 470nF schadet sicher nicht... Als vor einigen Jahren Conrad noch billige Bauteile als Restposten im Angebot hatte, habe ich mich auch mit diversen, immer wieder gebrauchten Teilen eingedeckt. Gruß... ...HanneS...
So, habe jetzt mal einen Schaltplan gezeichnet.... Schaut mal bitte drüber, ob das so realisierbar ist?! Zwei Taster simulieren Blinker Eingang links und Blinker Eingang rechts. Zwei LEDs simulieren die Ausgäge! Habe ja was mit EAGELE herum experimentiet und muss sagen, dass es immer besser klappt! Ich würde mir ganz gerne den Testaufbau, parallel zu meinem selbst gelöteten Aufbau auf Streifenraster, ätzen lassen. Einfach nur um damit mal Erfahrung zu sammeln... Habe dafür folgende Firma vorgesehen... www.gsel.com Nun zu der eigentlichen Frage! Solche Teile wie den Kurzhubtaster muss ich mir doch selber zeichnen, oder gibt es für alles Bibliotheken (glaube ich eigentlich nicht)? Das meißte und wichtigste ist ja in der rcl Bibliothek zu finden... Wie geht ihr mit EAGLE um? Richtet ihr euch nach den Bibliotheken und beschafft euch die Bauteile bei einem Händler? (eigentlich sehr kostspielig, denke ich!) Oder stellt ihr eure Schaltung mit von euch gewählten Bauteilen (z.B. alle von Reichelt) zusammen, und konstruiert die Fehlenden Bauteile in EAGLE? Gruß, Stephan
kurzhubtaster wie die von reichelt gibts glaub ich in der lib von omron ich geh danach was reichelts von den eagle libs hat meinst du wirklich das du dir den testaufbau schon ätzen lassen willst? für den preis bekommst du locker ein steckbrett
<Zitat> Habe dafür folgende Firma vorgesehen... www.gsel.com </Zitat> geht mich ja nichts an, aber die nennen keine Preise! http://www.gsel.com/platprof.html Durchkontaktiert und Lötstoplack sollte doch schon sein, oder? Im Thread http://www.mikrocontroller.net/forum/read-6-74726.html und auch in anderen in der Rubrik "Platinen" findest Du sicher was passenderes. ( http://www.q-pcb.de vielleicht? Ich habe sehr gute Erfahrungen gemacht!) Lass mal erst das Streifenraster. machen alle so. Schaltung scheint iO. Gruß Axel
>geht mich ja nichts an, aber die nennen keine Preise! Klar, sag ruhig was! Ich bin auf dem Gebiet absolut neu und bin über jede Info bzw. Hilfe dankbar! @Tobi und Axel Habe mich da wohl was im Preis verkalkuliert... Habe da eigentlich mit max. 10 EUR gerechnet... Und für den Preis hätte ich das einfach mal ausprobiert! Es wird aber doch teurer... Dafür bekomme ich wirklich schon eine Steckbrett, was ich persönlich für sinnvoller halten würde... Es gibt Diverse Programme z.B LochMaster mit dem ich Streifenrasterplatinen planen kann... Irgendwie macht das Programm einen recht "billigen" und "oberflächlichen" Eindruck! Kann mir das jemand bestätigen? Wie plant ihr eure Streifenrasterplatinen? Ich würde sie jetzt irgendwie nach dem EAGLE Schaltplan zusammenbasteln....?! Die Seite http://www.q-pcb.de macht einen verdammt guten Eindruck!!! Danke! Wenn die Schaltung so in Ordnung ist, werde ich mich mal dran geben... Und kleine Änderungen bei Streifneraster sind ja auch nicht die Welt...! Gruß, Stephan
Hi... Ich vermisse die Pull-Down-Widerstände an den Tastern bzw. AVR-Eingängen... Zuende geprüft habe ich aber nicht, die Grafik passt nicht auf den Schirm (zu viele DPI), wenn man immer nur einen kleinen Ausschnitt sieht, dann fehlt die Gesamtübersicht... Nicht vergessen, das ist nur ein Testaufbau, den hinterher niemand mehr braucht. Also bitte keinen unnötigen Aufwand treiben. Mach dir mal Gedanken, wie du ein Adapter realisierst, das du von oben auf den Tiny15/Tiny12 (in der Platine) aufstecken kannst, so dass die ISP-Leitungen kontaktiert werden. Dann ersparst du dir den ISP-Steckverbinder auf der Platine, der die Platine verkompliziert. Bei mir hat sich so ein Adapter gut bewährt. Es werden da nur die Pins 1, 4, 5, 6, 7 und 8 benötigt... Gruß... ...HanneS...
Hi! Wenn man das Blinken vorzeitig abbrechen will und tippt dazu die Gegenseite an, während die Lampen gerade aus sind, kann das nicht bemerkt werden, wie mir scheint?!?! Gruß Frank
Hallo an alle die diesen Thread vorangebracht haben, vorallem an Hannes, der uneingennützig Stephan geholfen hat, ist leider nicht selbstverständlich. Ich hab jetzt das gleiche Problem wie Stephan und komme da irgendwie nicht weiter, da das Problem ja immer noch ist, das der Wechsel zur anderen Seite bei Blinkerlampe aus, nicht erkannt wird. Gibet da vielleicht ne Hardwaremöglichkeit, ein "sauberes" Signal zu bekommen, oder hast du Stephan ne Möglichkeit gefunden, das Softwaremäßig hinzukriegen ? Danke für die Antworten. CU Bernd
Also mir fällt jetzt aus dem Hut nix ein, was ohne Änderung der Fahrzeuginstallation möglich wäre. Bei "offenem" Blinkgeber und einem eingeschalteten Relais haben nunmal alle Blinkschalter-Anschlüsse über die Glühlampen Massepotential. ...
Ich habe (vermutlich) eine Lösung gefunden... Hier geht's weiter: http://www.mikrocontroller.net/forum/read-1-271826.html#272633 ...
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.