Forum: Mikrocontroller und Digitale Elektronik ATTiny10/11/12

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.

@Tobi:
Warum soll ein Print einen AVR mit UART brauchen?

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

unter ic's / mikrocontroller und dann unten auf seite 2

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.

Ganz vergessen...


Gruß,

Stephan

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

zählt doch hoch, nur Geduld: vorteiler steht ja auf 1024...

<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...

ja nee, zählt ja! Ich hatte auf autostep gestellt, da dauerts natürlich

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?)

Hi...

Da iss was dran... ;-))

...HanneS...

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...)

Hi,
wie verhält sich der Warnblinker?

Gruß
AxelR.

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

So wird es sein... (Ein Grund mehr, sowas nicht zu nutzen...)

... also zieht man die Anschlüsse am Schalter über 10K gegen 12V?

k.A.
war nur ne Idee, schade
AR.

seit wann waren die ersten Schriften im Gebrauch ?