Interesse an individuellen led Treibern

Hallo Palladin,

nur kurz zu einem Punkt (Rest später) :

ADC-Kondensator:
Deshalb wollte ich es so genau wissen, bei den 2,8A Exemplaren von Kai & Shiningbeam ist es nämlich der größere (1872) der zwischen Masse und Pin 7 hängt.

Ist das wirklich so oder könnte es sein, daß das Layout täuscht?
(Ich habe selbst keinen doppelseitig bestückten Treiber und finde außer diesem hier kaum Bilder auf denen man die Widerstände erkennt.)

Wundert mich nämlich aus folgendem Grund: Der Tiny13 kann am ADC nur mit 0 bis 1,1V etwas anfangen. Wenn nun der größere von 2 Widerständen vom ADC nach Masse geht, fällt dort auch die größere Spannung (>1,1V) ab.
 
Au weia, sorry den Satz von mir bitte streichen, der ist natürlich grober Unfug.

Soweit ist mir der Sinn des Spannungsteilers aus diesem Thread schon klar geworden, daß dies auch nicht funktionieren sollte.
Aber es ist manchmal Erstaunlich wie sich mancher Unsinn, hier noch ganz aus meinen allerersten Anfängen, im Gedächtnis festbrennt und nicht mehr auszutilgen ist.

Es ist natürlich der kleinere 4,7k der mit dem Kondensator beglückt werden sollte,
bei meinem "alten" Layout, in etwa SO aussieht (bei meinen Kai Exemplaren geht der Massering des Boards sogar direkt bis zum Widerstand) ist es daher fast trivial, den richtigen auszuwählen.
Der "falsche" Widerstand hat schließlich keinen Masseschluss sondern lediglich Kontakt zu Pin 7 und 8.

Daher auch nur Bockmist gelabert aber richtig gelötet, soll heißen, der Kondensator saß bei den Messungen schon auf dem richtigen Widerstand, die Tabelle oben ist soweit korrekt.

Das von Dir verlinkte Foto scheint das allerneueste Layout zu Zeigen, so kamen am Montag zumindest meine neuen Exemplare von Shiningbeam an.
Die Widerstände sind dort wieder zurück auf die Seite vom Tiny gewandert und der große wurde auf 19,1k "befördert".
Die Werte vom kleinen und der Schottky Diode blieben unverändert.

Maile mir mal Deine Adresse, ich schicke Dir was für Deine Sammlung :)


Ich muß auch noch :rolleyes: eine Frage anhängen:
Bislang hab ich zu Testzwecken nur Kai Exemplare verbraten und daher stellte sich das Problem noch nicht.
Bei sämtlichen mir bekannten 1,4 oder 2,8A Varianten von Shiningbeam (ab 2010) sind die Pins 3&4 des Tiny verlötet - warum auch immer.
Von potentiellen Kontaktproblemen am SOIC Clip mal abgesehen, stört das bei der Programmierung und/oder der Funktion?
Im Zweifel macht mal wieder ein Versuch kluch, auf den Versuch kommt es bei mir auch nicht mehr an :)
 
Last edited:
So, jetzt nochmal der Reihe nach...
Ich hab jetzt erst mal etliche Stunden und einige verbrutzelte Treiber gebraucht, um mit Sicherheit sagen zu können:
Wenn der ADC-Kondensator erst mal angelötet ist, dann ist Schluß mit programmieren. :glgl: Die Reihenfolge sollte man unbedingt beachten.
Stimmt, der ADC1 ist auch ein Pin für die Datenübertragung zum PC, hatte ich glaube in Erwartung von Problemen gar nicht erst versucht - dann aber dummerweise vergessen zu erwähnen, Sorry.

Was mir in dem Zusammenhang bislang noch auffiel:
Ich kam bislang immer auf 2,5 kHz oder 16,8 kHz (statt 2,3 bzw. 19).
Mangels Oszilloskop ist das jetzt nur primitiv mit meinem Spax-O-Meter (Fotozelle am DMM) gemessen, aber voll daneben lagen die Werte bislang eigentlich noch nie.
Theoretisch entsprechen die Hardware-PWM-Frequenzen dem Tiny-Takt von 4,8MHz geteilt durch 256 = 18,75hHz, sowie nochmal durch einen Vorteiler von 8 =2,343kHz.
Im Datenblatt ist die Toleranz des internen Taktgebers bei Werks-Kalibrierung mit +-10% angegeben, aber zusätzlich noch auf den Kalibrierungspunkt von 3V und 25°C bezogen.

Zu den von Dir anfangs beschriebenen Übertragungsfehlern ist mir folgendes aufgefallen:
Bei mir tritt der Fehler eigentlich nur beim überschreiben auf.
Wenn ich den Chip vorher lösche, dann klappt es auf Anhieb.
Guter Hinweis, ähnlich war es auch bei mir, ein paar Fehler kamen jedoch trotzdem noch. Aber da muss schon ein Zusammenhang bestehen, wenn dir nun genau das Gleiche auffällt.

Kleine Anmerkung/Frage:
In den Pausen glimmt die Lampe, warum auch immer, noch ein ganz klein wenig.
Das finde ich im Grunde genial, sieht man doch jederzeit, daß die Lampe im Betrieb ist.
Aber irgend etwas habe ich dann in den oberen Zeilen doch wohl vermasselt, oder?
Nee, das ist nicht außergewöhnlich, daß auch ein Tastgrad von 0 schwach leuchtet. Wie sich das technisch erklärt, ist mir nicht bekannt, es tritt auch nicht bei jeder LED/Treiber/Frequenz-Kombination auf. Wenn man es nicht mag, kann man an den entsprechenden Stellen (OCR0B = 0 ...) auch den PWM-Pin als Eingang: Ddrb.1 = 0 und nach dem "Wait.." wieder zurück als Ausgang: Ddrb.1 = 1 schalten.
(Soweit ich mich erinne, hatte ich den Tastgrad bevorzugt, weil in Low-Modi der reine Eingang->Ausgang-Wechsel zu einem kurzen und womöglich störenden "Blitz" führte. Evtl. bekommt man das wiederum in Kombination mit der Tastgrad-Schalterei weg.)

Ich muß auch noch :rolleyes: eine Frage anhängen:
Bislang hab ich zu Testzwecken nur Kai Exemplare verbraten und daher stellte sich das Problem noch nicht.
Bei sämtlichen mir bekannten 1,4 oder 2,8A Varianten von Shiningbeam (ab 2010) sind die Pins 3&4 des Tiny verlötet - warum auch immer.
Von potentiellen Kontaktproblemen am SOIC Clip mal abgesehen, stört das bei der Programmierung und/oder der Funktion?
Im Zweifel macht mal wieder ein Versuch kluch, auf den Versuch kommt es bei mir auch nicht mehr an :)
Wäre nur mit dem "Sternchen-Part" Problem - genau wie Widerstände (oder üblicherweise eher widerstandlose Brücken "000") abseits des Spannungsteilers. Ohne den Part ist es egal, womit auch immer diese per Programm als (Pull-Up) Eingänge konfigurierten Pins verbunden sind.

@ADC-Thema
Muss nochmal neu aufgerollt werden, was sich wohl noch ein wenig hinziehen wird, solange besser erstmal auf 2,3kHz beschränken. Auch an der Stelle nochmal vielen Dank für die zugesandten Testtreiber.
 
Guten Morgen,

ich hab mich heute auch nochmal dran gesetzt, nachdem ich vom Conrad nen frischen Attiny13 bekommen habe :super:

Folgendes Verhalten:

4gnt6uy7.jpg


Wenn ich jetzt hier auf Programmieren klicke, passiert folgendes:

r5aows56.jpg


Programmiere ich aber nicht EEPROM sondern Flash, klappts:

wfzrszw8.jpg


Sowohl mit eep als auch mit hex...

:confused:

Was will mir der Tiny sagen? :argw:

(edit) Das testweise Programmieren eines 2,8A Treibers ergab fürs Flashprogrammieren mit hex-Datei: Keine Funktion
......................................................................................................................eep-Datei: Keine Funktion

:lechz::lechz::mad::mad::lechz::lechz::jammer:
 
Last edited:
Ich habe die BLF-Software kürzlich mal probiert, mit dem Bascom "Sample Electronics Programmer" funktionierte folgende Methode:
Die BLF-VLD.hex vom Reiter Flash aus normal per Buffer -> load from File laden, die BLF-VLD.eep musste hingegen erst in eeprom.hex umbenannt werden, dann vom Reiter EEPROM aus ebenfalls als "Intel HEX" in den Buffer.

Wenn ich es richtig verstehe, fehlen dir im Prinzip nur noch die Daten im EEPROM. Probiere erstmal, ob vielleicht auch bei deinem Programmer bereits die Umbenennung in .hex funktioniert. Falls nicht, schaue mal nach einer Möglichkeit das EEPROM manuell zu editieren. Welche Werte die Zellen benötigen, kannst du dir dann mit der soeben beschriebenen Methode in Bascom anschauen.

Die vorkompilierten Versionen taugten mir persönlich wegen "Memory" und teils komplizierter Bedienung recht wenig.
Aber gut, dafür hat der Kollege ja einen äußerst umfangreich kommentierten "Baukasten" für programmier-erfahrene Anwender geschaffen, wogegen mein Bascom-Geschreibsel mit der Handvoll Kommentare eher eingeschränkt und chaotisch wirkt.
Eigentlich wollte mir nur mal anschauen, wie dort das "EEPROM Wear Leveling" aufgebaut ist, aber da gab es nix abzuschauen, wird auf gerade mal 3 Zellen verteilt...
 
Meine Sätze bestehen aber schon noch aus normalen Wörtern, anstatt Bits und Bytes, oder muss ich mir ernsthaft Sorgen machen?
Wenn der Hinweis (ob zielführend weiß ich nicht) wirklich so unverständlich sein sollte, könnte man zumindest zeigen, daß man sich Mühe gegeben hat und dementsprechend gezielter nachfragen. Dann versuche ich gern zu helfen, aber nicht bei so Einzeilern wie "Was möchtest du mir mitteilen"...
 
Nur mal ein kurzer Zwischenbericht von meiner Seite:

Zuerst:
6. Versuch:
Quasi ein Kontrollversuch bei 2,3kHz.
Dem stark erhöhten Wert bei 2,8A muß ich noch auf dem Grund gehen, der bereitet mir momentan aber kaum Kopfzerbrechen, ich befürchte, da war lediglich mein Versuchsaufbau den Strömen nicht gewachsen.
Dem ist tatsächlich so.
Ein Nachtest mit adäquat dimensionierten Litzen erbrachte 3,3V, das ist völlig in Ordnung.
Dennoch ist nicht zu übersehen, daß die Schwellenwerte beim max Mode (ohne PWM) immer gerne etwas nach oben abdriften, auch schon bei 2,3kHz.
Wie sich zeigen sollte, liegt bei max überhaupt ein Knackpunkt.

Seit dieser Woche arbeite ich jetzt mit 3 "festen" Versuchsaufbauten (1050,1400 und 2800mA) um das ständige hin- und herlöten etwas zu minimieren, das andauernde umprogrammieren reicht.

Ich habe die Woche jetzt mal mit einer "Kompromißfrequenz" von 4,7kHz getestet (Fusebit DCBA auf 0010 = 9,6MHz).

Ich erspare euch mal neue Tabellen :D

Erste Versuche mit dem 2,8A Testbed erbrachten nur grüne Werte bei den Schwellwerten, wie gehabt, mit einer leicht verfrühten Warnung auf Max.

Die Tests mit dem 1050er Treiber waren zuerst sogar noch besser, da war selbst Maximum im Gleichklang

Das sah eigentlich auf den ersten Blick gar nicht mal schlecht aus.

Auch die von rsfyfy mir gegenüber geäußerte Befürchtung, daß es bei der Tiny Taktung von 9,6MHz bei Spannungen unter 3V zu Problemen kommen könnte, haben sich bei mir zumindest bei meinen bescheidenen Tests nicht bewahrheitet
- aaaaaber...

dann kam der 1400mA Treiber an die Reihe.
Und da bewies sich, daß möglichst intensive Tests elementar sind.

Alle Schwellenwerte waren perfekt, aber es zeigte sich ein anderes Problem.
Im max Mode versagte der ADC in über 50% der Fälle komplett - keinerlei Warnung geschweige den Abschaltung.
Wenn er mal funktionierte, dann wurden die Schwellenwerte mustergültig eingehalten :rolleyes:

Nachtests erbrachten, daß dieses Phänomen auch vereinzelt bei dem 1050mA Pendant auftritt :staun:

Lediglich der 2,8A Treiber weigerte sich zumindest bislang bei rund 50 Versuchen standhaft zu versagen.

Mal schauen, ob ein anderer Weg nach Rom führt.
 
Falls der Verdacht aufgekommen sein sollte:
Nein, zumindest von meiner Seite aus ist das Thema gewiß nicht eingeschlafen.

Holt Euch erst mal einen Kaffee, das wird verdammt lang :D.

Ganz im Gegenteil, ich war mit den Treibern dermaßen beschäftigt, daß mir einfach die Zeit fehlte, hier Zwischenstände zu berichten.

Die letzten 6 Monate habe ich intensiv an der Programmierung der Treiber gefeilt.
In diesem Zusammenhang ein ganz herzliches Dankeschön an rsfyfy, der mit unendlicher Geduld mir in allen Belangen geholfen hat.

Ich glaube, das Endergebnis kann sich sehen lassen.

Kaum zu glauben, aber aus diesem robusten, zuverlässigen, aber eher doch rudimentären Treiber ist IMHO ein echtes Kleinod geworden!

Treiber auf Maß sind endlich Wirklichkeit.

Nochmals die Grunddaten:


  • Modes nach Wahl in beliebiger Reihenfolge.
    Anzahl möglichst 1-10, notfalls auch 20+
    Abstufung in 255 Stufen, daher fein einstellbar.

  • "Pseudo-"* Memory frei.
    Start immer auf 1. Stufe

  • Theoretisch freie PWM Wahl* bis 19,2 KHz.

  • Optional Burst auf Max.
    Nach X Minuten drosselt die Lampe die Leistung nach Wunsch - Dragster an der Leine.

  • Optional Nachtwander Modus
    Die Lampe wird in einer frei definierbaren Stufe in einem einzustellenden Intervall bis zu einem Schwellwert hin dunkler.

  • Wer's braucht: SOS oder Beacon als mögliche letzte Stufe sind möglich und implementiert,
    Strobe sollte auch gehen, aber letzteren weigere ich mich zu programmieren :D

  • Geniale 2 stufige Akkuwarnung - Warnung und Notabschaltung,
    Schwellenwerte frei wählbar.
    Geblinke und Zeitabstand lassen sich nach Geschmack einstellen.
    Kaum ein Treiber (incl. Serienlampen) kann diesem selbstprogrammierten hier das Wasser reichen!

    Die Notabschaltung erfolgt durch herunterdimmen beim Erreichen des 2.
    Schwellenwertes.

    *Siehe Kommentare bei meiner Treibervorstellung weiter unten.

Nach Hunderten von Teststunden sowohl im "Labor" wie auch in der Praxis, wage ich zu behaupten, daß nunmehr sämtliche Kinderkrankheiten bei der Augenblicklichen Version ausgemerzt sind und der Treiber absolut zuverlässig läuft.

Die Akkuwarnung ist genial und ermöglicht einem, gerade bei einzelligen Lampen hat das ja durchaus Bedeutung, die Energiezelle auszureizen, ohne Gefahr zu laufen, Akkus zu tief zu entladen oder spontan im Dunkeln zu stehen, weil die Schutzschaltung greift.


Ich möchte hier mal in Kürze "meine" Treiberversion vorstellen und in dem Zusammenhang noch dazu ein paar, wie ich meine, elementare Kommentare dazu abgeben.

Wer seine eigene Version entwickeln möchte sollte hier auch Anregungen finden, worauf dabei zu achten ist.

Im Anschluß hab ich mir ein kurzes "Treiber programmieren für Dummies" :steirer: vorgenommen, um manch einem den Einstieg zu erleichtern. Die Resonanz ist ja momentan noch eher mau :(.
 
Last edited:
Mein Treiber:

Vorerst habe ich mich auf die 2,8A Version konzentriert, noch ist es ja lange dunkel.

Basis ist das 501C Board mit 4,7 bzw. 19,1kOhm Widerständen, der ehemalige Kai „V1“ Treiber, welcher aber bei zahlreichen Onlinehändlern noch zu haben ist.

Von der Shiningbeam Variante würde ich eher abraten, die zusätzliche Verbindung zwischen Pin 3&4 des Tinys muss erst entlötet werden, damit der Clip greift. Wenn das nicht absolut perfekt durchgeführt wird, gibt das Kontaktschwierigkeiten.

Bevor jemand fragt: Der KAI V2 geht gar nicht, dort ist ein anderer Controller verbaut, der mit Bascom nicht programmiert werden kann.

Im Frühjahr oder Sommer habe ich vor, mich den kleineren (1-1,4A) Versionen zu widmen.

Die aktuelle Version läuft absolut stabil und scheint, soweit man dies nach „nur“ ein paar hundert Stunden Testzeit und rund einem Dutzend Treibern bislang beurteilen kann, inzwischen komplett bugfrei zu sein.

Ich hab mich für 5 Stufen entschlossen, sehr maßgeschneidert.
Das halte ich schon für vergleichsweise viel, i.d.R. sollte man mit maximal 4 Modes auskommen.
Da meine regelmäßigen Spaziergänge relativ lang sind, wollte ich die Möglichkeit haben, bei geplanter "Laufzeit" das Maximum aus der Lampe herausholen zu können ohne die Zellen wechseln zu müssen.

Mein Treiber startet auf Max, das ist eine Frage der Philosophie.
Wenn ich schnell Licht brauche, dann brauche ich es hell.
Wenn ich lediglich ein Gefunzel benötige, habe ich in der Regel vergleichsweise alle Zeit der Welt.

Die von mir gewählten Stufen sind ca. 2800/2100/1400/500/60mA
Wie gesagt Geschmacksache, am besten orientiert man sich bei der Auswahl an vorhandenen Lieblingslampen.

Bei nicht allzu massiven Hosts hat die 2,8A Max Stufe ein Burst Mode.
Nach bei mir 6 Minuten schaltet die Lampe herunter auf 2,4A.
Das ist moderat, kaum wahrnehmbar, entspannt die thermische Situation etwas und spart Strom :)


Mode Reset Intervall:
Etwas knifflig dort den idealen Wert zu finden.
Der Tiny kann in der Konfiguration keine Ausschaltzeiten messen, sondern nur die Einschaltzeit.
Modewechsel und ausschalten ist für ihn das gleiche.
Daher die Krücke mit der Einschaltzeit.
Wenn die Lampe X ms eingeschaltet war, ist die nächste Stufe wieder die 1.
Ein langes Intervall ermöglicht es einem "in Ruhe" zu evaluieren ob die Stufe passt.
Andererseits muß die Lampe aber dann auch mindestens so lange eingeschaltet bleiben, damit beim nächsten Start die Lampe auch wieder bei der 1. Stufe beginnt.

Schwierig ist die Entscheidung insbesondere in Verbindung mit einem Forward Clicky, der einen allzu gerne verleitet, auch mal nur ganz kurz aufzuleuchten, bzw. der evtl. auch mal versehentlich nur kurz angetippt wird.

Persönlich habe ich mich mit der Zeit vom Intervall her immer weiter heruntergearbeitet.
Da es ja eh Modi nach Maß sind, kennt man mit der Zeit seine Modes so gut, daß man im Vornherein eigentlich schon immer weiß, z.B. "Hier brauche ich die 2. Stufe".
Persönlich würde ich sagen: Je geringer die Anzahl der Modes desto geringer die Qual der Wahl.
Folglich würde ich dann eher zu einer kürzeren Intervallzeit neigen.
Für meine 5 Modes bin ich momentan bei 750ms, Tendenz eher nach unten.
500ms würde ich z.B. für eine 3 Mode Variante vorschlagen, das ist auch rsfyfys Standardwert.


Von der Frequenz her habe ich mich für eine Variante mit rund 4,6kHz entschieden.
(Für Cracks: Bei voller Tiny Taktung von 9,6mHz, ADC Frequenz 75mHz)
Dies erwies sich bei mir in zahllosen Tests mit Abstand als bester Kompromiß zwischen hoher PWM Frequenz und recht zuverlässigen ADC Werten für die Akkuwarnung.
Die PWM Frequenz ist jenseits der Wahrnehmungsgrenze und die Genauigkeit der ermittelten Spannungswerte der Zelle sind funktional.

Akkuwarnung:
Ganz klar das absolute Highlight des Treibers.
Im höchsten Maße ist der Treiber hiermit idiotensicher und sorgt dafür, daß bei Bedarf die volle Kapazität des Akkus guten Gewissens ausgeschöpft werden kann, ohne daß man sich Sorgen um die Zelle machen müßte.

Eine rechtzeitige Vorwarnung sorgt dafür, daß man nicht spontan im Dunkeln steht, etwas, was man in manchen Situationen ganz und gar nicht gebrauchen kann.
Die Notabschaltung garantiert, daß der Treiber auch in einem unbeaufsichtigtem Moment dem Leuchten rechtzeitig ein Ende setzt bzw. gibt dem Anwender ein letztes Signal, daß es höchste Zeit ist, die Energiequelle oder Lampe zu wechseln.
Auch hier wird es nicht schlagartig dunkel, sondern die Lampe dimmt gemächlich jeweils eine Stufe herunter bis 0 (und der Treiber schaltet sich ab).

Kaum irgendeine Serienlampe hat überhaupt eine Akkuwarnung, wer die folgenden Zeilen durchhält, weiß auch warum :)

Der Spaß ist wahnsinnig diffizil.

Hauptproblem ist (das kann man auch in der vorhergehenden Posts lesen), daß die Spannungswerte, die der Tiny im PWM Modus errechtet, teilweise erheblich vom tatsächlichen Wert abweichen. Volle Pulle, ohne PWM kommt der Chip jedoch auf die korrekten Werte.

Daher lag mein erstes Augenmerk darauf, eine Konfiguration zu finden, bei der die Abweichungen nicht sonderlich ins Gewicht fallen.
Pauschal kann man sagen: Je höher die PWM Frequenz, desto mehr driften die Werte auseinander.
Ebenso gilt: Je höher die Ströme (Restspannung der Zelle, Vf des Emitters) desto größer die Abweichung.

Dieses Phänomen ist von Treiber zu Treiber sehr unterschiedlich.
Einerseits scheinen die Abweichungen in Abhängigkeit mit der tatsächlichen Tiny Frequenz zu stehen. Die +/- 5% sind dann schon erheblich.
Zum anderen scheint auch die Qualität der Boards (oder der Verlötungen?) eine erhebliche Rolle zu spielen. Rsfyfy hatte mir gegenüber mal erwähnt, daß das Board quasi als Antenne für die Störsignale fungiert.
Ich habe gerade einen neuen Riegel Treiber angebrochen, bei diesem Scheinen die Abweichungen deutlich geringer auszufallen, wie bei allen bisherigen Exemplaren

Fazit:
Eine XR-E mit ihrer hohen Vf und max. 1000mA macht kaum Probleme, da sollten auch 19kHz noch recht problemlos gehen.
Beim anderen Extrem, einer XM-L und 2,8A sieht die Sache ganz anders aus.

Dort haben sich die oben bereits erwähnten Werte bewährt.
Die 4,6mHz packt der Tiny noch ohne große ADC Ausreißer solange man ihn auf voller Taktung laufen läßt. Die relativ träg eingestellte ADC Frequenz verhindert zudem noch etwas übernervöse Ausrutscher.

Soweit erst mal zu den Grundeinstellungen.

Kommen wir nun zu den Schwellwerten:

Das ist natürlich Geschmacksache oder vielleicht sogar eine Philosophiefrage.
Es ist der ewige Spagat zwischen voller Ausnutzung der Kapazität und Zellschonung.
Zudem muß man immer noch die Eigenart des Treibers im Hinterkopf behalten, daß bei zu hoher Restspannung die ADC Werte weiter auseinanderdriften.

Des weiteren muß man sich entscheiden, wie groß die Zeitspanne zwischen Warnung und Notabschaltung sein sollte.
Das macht die Sache erst recht nicht einfacher...
Hier kommen dann noch ein Haufen anderer Variablen ins Spiel.

Wichtigster ist die Zelle: Wer sich mit der Materie vertraut gemacht hat und sich die Kurven einiger Tests zu Gemüte führt, wird feststellen, daß die Spannungskurven sehr unterschiedlich ausfallen.
Hochkapazitätszellen (2900mAh aufwärts) haben eine weitaus flachere Spannungskurve.
Die Zeitspanne zwischen Warnung und Abschaltung kann daher erheblich variieren, die Warnung erfolgt signifikant früher oder später.

Auf weitere Faktoren wie Höhe der Leistung, Emitter Vf, Teil- vs. Vollgeladene Zelle entleeren, Temperatur, Zellenalter, etc. gehe ich jetzt nicht ein, sie beeinflussen das Ergebnis aber durchaus und wurden bei meinen Tests natürlich soweit machbar berücksichtigt.

Man kann sich jetzt entweder seinen Treiber auf eine Lieblingszelle maßschneidern, das wäre aber zu einfach ;) oder aber man versucht die Quadratur des Kreises, ich denke dies ist mir recht gut gelungen :D

Vorgaben meinerseits waren:
-Fokus auf Akkus mit einer hohen Spannungskurve, schlicht und ergreifend, weil dies die idealen Zellen mit Linearreglern sind, da der Output bedeutend länger Konstant bleibt.
Die üblichen Markenzellen bis 2600mAh fallen in diesen Bereich.
Dennoch auch ein möglichst sinnvolles Intervall auch bei Verwendung aller erdenklichen anderen Akkus, von Lithium-Mangan (IMR) Zellen bis hin zu den 3100er Langläufern.

-Gute 5 Minuten Intervall (ohne herunterfahren) habe ich dabei angepeilt. Das sollte in der Regel reichen, um in eine Situation zu kommen in der man in Ruhe den Akku wechseln kann.
Eine deutlich frühere Warnung wollte ich vermeiden. Das schafft nur zur Unzeit Unruhe oder aber man gewöhnt sich dermaßen an die Warnung, daß man den Wechsel verpennen würde, täte nicht die Notabschaltung greifen.

Meine Werte sehen momentan so aus:
Warnung bei gut 3Volt, Notabschaltung bei gut 2,9Volt.
(Auf Max - ohne PWM - erfolgt die Warnung etwas früher)
Bei einer hohen Spannungskurve einer Zelle entspricht dies einem Intervall von rund 7 Minuten.
Bei extremen "flachen" Langläufern verlängert sich das Intervall auf für mich noch vertretbare ca. 12-15 Minuten.

Die Warnung bei 3V liegt im sattgrünen Bereich.
In der Regel, wenn man den Treiber nicht gerade testet, wird man dann ja auch recht zeitgleich die Energieversorgung wechseln.
Auch bei gut 2,9V ist noch reichlich Luft, man sollte jedoch bedenken, daß der Herunterdimm-Vorgang auch noch etwas an der Kapazität nagt.
Was ich sagen will: Wer auf das regelmäßige auskosten der Herunterdimm-Show verzichten kann, tut auf Dauer seinen Akkus auch noch ein ganz klein wenig was gutes.

Eigentlich unnötig zu erwähnen, aber geschützte Akkus mit einer Schutzschaltung die bereits bei ca. 3V greift, sind mit diesen Werten kaum sinnvoll zu gebrauchen.

Meine Werte wurden durch unzählige (und unendliche) Tests in Theorie und Praxis mit einer großen Variation bei der Hardware überprüft.
(Disclaimer: Irgendeine Haftung meinerseits läßt sich aber daraus selbstredend nicht ableiten)
Auf allen Stufen von Mid bis Max führen sie zum gewünschten Erfolg.

Vorsorglich möchte ich hier nochmals explizit darauf hinweisen:
Auf Low Stufen (ich sag mal aus dem Bauch heraus, spätestens 2-stellige mA Werte und drunter) funktioniert keinerlei Akkuwarnung !!! – und auch keine Schutzschaltung in der Zelle.
Bei derart geringen Strömen nähert sich die Spannung unter Last gefährlich der Leerlaufspannung und dann ist jeder Schwellwert noch zu viiiiiiel hoch.
Dies nur vorsorglich.
Es gibt immer noch Experten die meinen, Laufzeitweltrekorde ohne nachzuladen mit einer Zelle aufstellen zu müssen und sich dann über ach so miese Zellen ärgern.
Im Zweifel nachladen! Der beste Akkuschutz ist immer noch Brain 1.0
Keine einzige Zelle hat bei mir wegen zu häufigem laden den Geist aufgegeben.
Fatal sind für Zellen überladen und zu tiefes entladen. Folgen durch „zu häufiges“ laden sind vernachlässigbar.


In diesem Zusammenhang ist auch noch zu erwähnen:
Die Toleranzen der Treiber sind leider recht erheblich, die Obigen Werte stellen in etwa den Durchschnitt dar. Mit leichten Toleranzen nach oben und unten muß man rechnen, diese sind aber in der Praxis vernachlässigbar und eher akademischer Natur.
Wer es ganz perfekt haben möchte kann selbstverständlich jeden Treiber einzeln ausmessen und die Werte feintunen :)
In sehr seltenen Fällen gibt es aber Ausrutscher, bei denen sich die einzelnen Toleranzen nicht gegenseitig nivellieren, sondern addieren. Wie gesagt, dies ist ausgesprochen selten, mir ist erst ein problematischer Treiber untergekommen.
In dem Fall muß man die Abweichung dann halt ggf. für beide Werte parallel korrigieren.

Was mir da noch aufgefallen ist:
Beim Feintuning der ADC Werte passiert offenbar bei der Änderung um einen Zähler manchmal gar nichts, dann wieder Mal macht das Ergebnis einen kleinen Sprung.
Keine Ahnung woran das liegt. PWM Mittelung? Irgendein interner Multiplikator?
Es spielt auch keine wesentliche Rolle, die Werte lassen sich noch ausreichend genau einstellen, daher nur zur Info.

Noch Fragen? :steirer:
Sonst fange ich mal mit dem Tutorial an.

Die Aktuelle Version des Treibers findet sich im Anhang.
So wie sie ist, läßt sie sich in jedem beliebigen Editor öffnen.
Wer sie direkt in Bascom laden möchte, entfernt einfach die 2. .TXT Endung.
 

Attachments

  • ATtiny13_V1-70_Palladin.bas.TXT
    3.6 KB · Views: 148
Last edited:
Treiber Programmieren für Dummies ;)

Okay, jetzt habe ich mit meinem Vorspann allen Angst gemacht :rolleyes:

Im Grunde ist es aber gar nicht schwer, sämtliche Fallstricke versuche ich Euch zu ersparen.
Deshalb gestatte ich mir, rsfyfys Erläuterungen und meine Erfahrungen zu einem möglichst simplen Tutorial zusammenzufassen.

Neben reichlich Treibern,
braucht es nur Software, einen Rechner mit LPT Druckerschnittstelle, Kabel und Klammer.

Ein regelbares Netzteil bis min. 5V/3A ist sicherlich für Testzwecke hilfreich aber nicht zwingend erforderlich.

Lötkolben nebst Zubehör und ein DMM unterstelle ich mal sind vorhanden, wenn jemand Treiber programmieren will ;)

Ach ja drei simple Drahtwiderstände so zwischen 100 und 500 Ohm sind auch nicht verkehrt.

Software, herunterzuladen hier
http://www.mcselec.com/index.php?option=com_docman&task=cat_view&gid=99&Itemid=54
die kostenlose Demo, zuunterst auf der Seite reicht vollauf für unsere Zwecke.

Klammer:
Notfalls geht es bei den ersten Versuchen auch ohne, es ist aber extrem mühselig, daher rate ich dringend zum Clip ab den ersten Gehversuchen.
Wie bereits weiter oben erwähnt, ist der vermeintlich preisgünstigere Somona Clip herausgeschmissenes Geld.
Der modifizierte 3M Clip von c-u-s.co.uk
ist eine Lohnenswerte Investition die einfach drin sein muß.
Dieser hat sich wirklich bewährt.

Kabel:
Ich rate dringend vom Druckerkabel-Recycling ab, das vervielfacht die Fehlerquellen.
Viel zu viele Strippen vergrößern die Verwechslungsgefahr, zu viel herumgelöte kann den Kunststoff um die Stifte schmelzen lassen und läßt letztere wandern, das Kabel ist viel zu starr und schwer für die filigrane Clip Prozedur.... etc....

Das ist auch gar nicht nötig.
Einen funkelnagelneuen 25-poligen Sub-D Lötkelch (Stecker) gibt es schon für einen Appel und nen Dotter zu erwerben. Wer sein Vermögen raushauen will, der spendiert ihm noch eine Haube :D, evtl. eine metallisierte zur Abschirmung.
In der Regel sind die Kontakte an der Stiftleiste numeriert, das erleichtert die Arbeit ungemein.
Vorsorglich sollte man vor dem Kauf aber nachfragen, ob dem wirklich so ist und daß die Numerierung sich auch auf der Lötseite befindet :rolleyes:.

Als Kabel selber eher etwas filigranes und flexibles, sonst zerrt eine Menge Gewicht an dem Clip und reißt diesen vom Tiny.

Grundsätzlich ideal ist ein Flachbandkabel, wäre da nicht die Fehlende Abschirmung.
5-Polig gibt es kaum eines, daß 10-polige von 3M läßt sich aber der Länge nach problemlos in der Mitte durchreißen, dann hat man gleich zwei :)
Das einzige Problem ist wie gesagt die fehlende Abschirmung, diese führt zu den von rsfyfy berichteten Schreibfehlern, die dann vermehrt auftreten.
Wer den Rechner nicht tief unter dem Schreibtisch vergraben hat, sollte ein Flachbandkabel ruhig wagen, vorrausgesetzt die Kabellänge übersteigt keinesfalls 1m.

Wer ein längeres Kabel benötigt, dem sei folgende abgeschirmte Datenleitung
Unitronic Liycy 5x0,14
ans Herz gelegt. Nicht allzu schwer und noch recht flexibel ist sie ein guter Kompromiß.

Das war’s schon für den Einkauf :)
 
Kabel konfektionieren:

Mach ich hier als separaten Post zum ausdrucken als Lötanleitung.
Im Grunde ganz simpel:

Für die Pinbelegung am 25-poligen Stecker verläßt man sich auf die Markierungen am Lötkelch.

Pinbelegung Attiny 13:
(Pin 1 ist in echt wie üblich der mit der Bohrung drüber.)

Tiny13pins.png


Da der Soic Clip von sich aus symmetrisch ist, kommt man nicht umhin, die gewählte Seite mit Pin 1 eindeutig zu markieren, z.B. in dem man die Pin 1 Ecke etwas abfeilt.
Ich habe der Einfachheit halber diese Ecke großzügig mit einen silbernen Edding markiert.

Die LPT Pins 18-25 werden mit einem dünnen draht verbunden.


Die 3 Widerstände werden beidseitig deutlich gekürzt, so daß die Enden, wenn man sie in den Lötkelch-Kontakten versenkt noch rund 5-8 mm herausschauen.
Die Widerstände können dann an den Kontakten 2, 4 und 5 des LPT Steckers verlötet werden.


Ansonsten wird verkabelt wie folgt.

  • LPT Pin 2 _____________ an Tiny Pin 5


    [*]LPT Pin 4 _____________ an Tiny Pin 1


    [*]LPT Pin 5 _____________ an Tiny Pin 7


    [*]LPT Pin 11 ____________ an Tiny Pin 6


    [*]LPT PIN 25 ____________ an Tiny Pin 4

Wer diesen Post jetzt wirklich ausgedruckt hat, schreibt bevor es losgeht noch zwischen jede der 5 Verbindungen eine der 5 Farben der Adern des von ihm gewählten Kabels, dann ist es idiotensicher.

Die 5 Verbindungen kriegt wohl jeder hin.
Beim Clip muß man nur darauf achten, daß man durch die versetzten Kontakte nicht durcheinander kommt.

Am schwierigsten ist noch, die Disziplin aufzubringen, die Verkabelung mindestens drei Mal zu überprüfen! Wer hier Mist baut, ist beim ersten Kabel bei der Fehlersuche ansonsten später aufgeschmissen, weil zu viele Fehlermöglichkeiten noch in Betracht kommen.

So in etwa sollte ein fertig konfektioniertes Kabel ausschauen:

Clip2.jpg


Fertig? Super! :)
Das Kabel ist schon die halbe Miete.

Wenn wir schon beim löten sind, können wir am ersten Treiber auf der Federseite bereits die Litzen für die Stromversorgung anlöten und uns individuelle Gedanken zur Stromversorgung machen.

Zum programmieren reichen wenige mA, zum testen braucht es dann der Treiberleistung entsprechend halt mehr.
 
Ran an die Software:

Vielleicht hätte ich es ganz an den Anfang schreiben sollen, als aller erstes sollte man überprüfen, daß der PC überhaupt noch eine LPT Schnittstelle hat. :glgl:

USB Adapter werden hier vermutlich nicht funktionieren, da die Software auf die E/A Bereiche auf Hardwarebasis zugreift, die ein Adapterkabel kaum zu simulieren vermag.

Adapterkarten sollten in der Regel gehen, sofern Platz und ein entsprechender Slot im Rechner vorhanden ist.

Ein kurzer Blick ins Bios sollte sicherstellen, daß die Schnittstelle überhaupt aktiviert ist.
Ansonsten reicht Standardeinstellung incl. Speicheradresse 378.
(Wer eine andere Speicheradresse wählen muss, z.B. weil an LPT1 bereits ein Drucker hängt, muss die Speicheradresse dann in Bascom ändern.)

Rechner ausschalten, Kabel anschließen, PC wieder hochfahren.

Unter Windows hilft noch ein Blick in den Gerätemanager, um auch hier sicherzustellen, daß die Schnittstelle von Windows fehlerfrei erkannt und konfiguriert wurde.

Dann kann es mit der Softwareinstallation losgehen.
Die heruntergeladene Datei entpacken und anschließend ausführen.
Das Handbuch kann man sich getrost als Einsteiger sparen, die Grundfunktionen die wir nur benötigen hat man auch so im nu raus :)

Der erste Programmstart, ist auch bei mir schon ein Weilchen her und der Alzheimer macht sich langsam breit ;)

Wichtig bei den Einstellungen ist nur, daß der Sample Electronics Programer verwendet wird, ansonsten erkennt Bascom nicht unser Kabel!

Options > Programer
Einstellungen wie folgt:

Settings.png


Dann kann es endlich losgehen :)

Das Hauptfenster:

Main.png


Die 6 rot markierten Buttons sind eigentlich alles was wir hier brauchen.
Auf der Linken Seite:
- Neue Datei,
- Datei öffnen,
- Speichern,
- Speichern unter,

ist eigentlich trivial.

Der schwarze rechte Chip in der Mitte steht für „Compile“,

Der grüne Quader rechts daneben steht für „Program Chip“,
falls noch Fehler im Code sind, färbt sich der Button übrigens rot.

Das war’s, den Rest können wir ignorieren.

Wenn man die ersten Programmzeilen in das Editor Feld schreibt oder ein Programm lädt, stellt man fest, daß die Editor Funktion ganz brauchbar ist.
Durch die mehrfarbige Hervorhebung sind die Zeilen sehr gut lesbar.
Ein kleines Ärgernis ist:
Die Kommentierungen schmeißt Bascom ungefragt immer extrem nach rechts.
Man kann die Abstände zwar wieder durch löschen verkleinern, beim nächsten Programmstart ärgert einen Bascom aber erneut :rolleyes:
Lernt damit zu leben.


Testen wir erst mal das Kabel mit einem ersten Versuch:

Der Treiber wird mit Strom versorgt und der Clip wird richtig herum vorsichtig aufgesetzt.


Hinweis:
Sowohl Clip wie auch der Tiny sind aus einem recht empfindlichen Kunststoff, die Ecken nudeln mit der Zeit ab, irgendwann findet der Clip keinen Halt mehr.
Daher den Clip vorsichtig positionsgenau aufsetzen und ebenso vorsichtig wieder entfernen.
Ein abreißen ist unbedingt zu vermeiden. Daher auch meine Warnung vor einem zu schweren Kabel.
Der Clip ist dennoch ein Verschleißobjekt, damit muß man leben.
Wenn er gar nicht mehr greift, kann man ganz vorsichtig versuchen, auf einer Glasplatte mit feinem Schleifpapier die Spitzen etwas zu schleifen, so daß man eine neue scharfe Kante bekommt. Dazu etwas zwischen die Klammern so spannen, so daß beide Enden eine Plane Fläche ergeben.
Wunder sollte man keine erwarten, aber ein paar weitere Programmierungen sollten bei guter Arbeit dann noch drin sein.

Die Tinys sollte man nach Möglichkeit auch nicht allzu häufig quälen.
Je runder die Kanten, desto leichter rutscht der Clip wieder ab...
Testtreiber sollte man daher nach Möglichkeit nach etwa einem halben Dutzend Versuchen verbauen und einen neuen Treiber zum Testexemplar designieren.



Weiter:
Meine Treiberversion, 2 Posts vorher angehängt, umbenennen, d.h. die „.TXT“ Endung entfernen und laden.

Anschließend klicken wir auf den „Compile“ Button, die Zeilen werden aufbereitet.
Ein weiterer Klick auf „Program Chip“ öffnet das Programmierfenster.

Wenn jetzt keine Fehlermeldung erscheint und oben im Fenster der korrekte Chip angezeigt wird, Gratulation!
Ihr dürft Euch eine Woche wie Elvis fühlen ;)


Falls eine Fehlermeldung auftaucht wie
"Could not identify chip with ID: was auch immer“
hilft nur die Systematische Fehlersuche, die Codes geben keinen Anhalt.

Sitzt der Clip korrekt? Und richtig herum?
Gerade am Anfang kann es passieren, daß der Clip doch nicht gleich auf Anhieb 100%ig sitzt.
Daher mal versuchen, die Position der Klammer zu optimieren und nochmals testen.
Dazu muß man den Programmierer nicht jedes Mal schließen, ein klick auf das türkise „I“ rechts von der Chip Auswahl reicht.
Wenn der Tiny korrekt erkannt wurde, unterbleibt die Fehlermeldung und der korrekte Chip wird im Fenster angezeigt.

Weitere Fehlerursachen:
- Stromversorgung okay? Ggf. mit DMM prüfen und/oder Emitter anklemmen.
(Eine LED darf übrigens nicht während der Programmierung angeschlossen sein)

- LPT Stecker korrekt an den Rechner angeschlossen? Kontaktschwierigkeiten sind hier häufig und die beiden Schrauben haben daher durchaus ihre Berechtigung.

- Nochmals einen Blick in den Gerätemanager: Keine Frage- oder Ausrufungszeichen?
Unter Details die Einstellungen mit denen in Bascom vergleichen.

- Ansonsten das Kabel erneut überprüfen, am besten per Durchgangsprüfer mit feinen Prüfspitzen jeweils von Kontakt zu Kontakt.
Vor allem aber auch überprüfen, daß man wirklich die richtigen Pins gewählt hat!




Weiter mit dem programmieren:

Das Programmfenster enthält 3 Tabs, die wir nacheinander „abarbeiten“ werden, keine Sorge, halb so wild.

Man sollte sich aber angewöhnen, zuallererst den Treiber zu löschen.
Vergißt man dies, wundert man sich ansonsten nur allzu gerne, daß die Schreibversuche nicht fruchten.

Ein Klick auf den Button mit dem roten „C“ und der Treiber ist clean :)

Dann widmen wir uns zuerst dem rechten Reiter „Lock and Fuse Bits“.

LockAndFuse.png


Eine kurze Info zu den essentiellen Tasten:

Der Button mit dem roten Pfeil dient jeweils zum beschreiben des Chips im FlashRom und EEPROM Reiter.

Das rote C haben wir ja bereits kennengelernt.

Das türkisene I hatte ich bereits bei der Fehlersuche angesprochen. Ein Klick darauf läßt den Programer erneut nach dem Chip suchen.

Die Lock and Fuse Bits sind in 3 Bereiche unterteilt:

  • Lockbits, die werden bei uns nur durch das löschen aufgehoben, nix weiteres zu tun.

  • Fusebits: Wer bei meiner Frequenz bleibt, sollte nach dem Löschen lediglich den Fusebit G auf
    “0: Preserve EEPROM“ umstellen, und die Änderung per „Write FS“ auf den Tiny speichern.

  • Fusebits High: Bei meiner Version ist da nach dem löschen des Chips normalerweise nichts mehr zu tun, ansonsten Werte gemäß Screenshot abändern und analog per „Write FSH“ abspeichern.

Sehr praktisch sind übrigens die Prüfsummen, die sich jeweils neben der Überschrift befinden.
Bei meiner Treibervariante reicht es z.B., wenn man die Sollwerte FF / 32 / FD überprüft.
Stimmt jeweils die Prüfsumme, muß man die Werte nicht einzeln abgleichen.


Der nächste Tab den wir uns vornehmen ist der ganz linke, FlashROM:

Flash.png


Dort hat Bascom bereits den gecompilerten Code abgelegt, alles was wir tun müssen, ist per Klick auf den Button mit dem roten Pfeil die Daten zu übertragen.

Schreibfehler:
Wie rsfyfy bereits erwähnt hat, ist hier gelegentlich mit Schreibfehlern zu rechnen.
Art und Menge sind hier offenbar von verschiedenen Faktoren abhängig.
Eine gute Abschirmung des Kabels reduziert die Fehler deutlich.
Auch eine schlechte Verbindung zwischen Clip und Tiny kann die Häufigkeit erhöhen.
Zu einem gewissen Prozentsatz muß man die Fehler einfach hinnehmen und den Schreibvorgang halt wiederholen.
Im ganz hartnäckigen Fällen empfehle ich, die Reihenfolge umzukehren und direkt nach dem (erneuten) Löschen erst das FlashROM zu übertragen und dann die anderen beiden Reiter abzuarbeiten.
Keine Ahnung wieso, aber dies reduziert offenbar die Fehlerquote..


Gleich haben wir es geschafft, letzter Tab – EEPROM:
Eeprom.png


Hier werden die Helligkeitsstufen eingetragen.

Kleine Besonderheit: die letzte Stufe ist die 00;00 ansonsten ist die Reihenfolge Trivial,
01;00 ist die erste Stufe, 02;00 folglich die zweite, usw...

Der Tiny bietet 255 Helligkeitsstufen.
255 ist Max (ohne PWM)
1 ist die niedrigste Helligkeitsstufe, wobei anzumerken ist, daß einige Emitter erst bei etwas höheren Werten (4-8) anspringen.

Eingetragen werden die Werte hexadezimal, Umrechner finden sich zuhauf im Netz, eine Umrechnungsfunktion verfügt aber auch die angehängte Excel Tabelle, ein praktischer kleiner Spickzettel, den man parallel zu Bascom öffnen kann und mit der man alle wichtigen Werte zur Hand hat :)

Wenn wir jetzt bei meiner Treiberversion bleiben, lauten die korrekten Modewerte
FF C3 84 2F 08
Da der letzte Mode wie erwähnt am Anfang eingetragen werden muß, lautet im Programer die korrekte Reihenfolge
08 FF C3 84 2F
wie auch auf dem Screenshot ersichtlich.

Von einem Feld zum nächsten wechselt man übrigens mit einem „Enter“ zur Bestätigung und anschließend dem entsprechenden Pfeil an der Tastatur.

Ein weiteres mal betätigen wir am Ende den Übertragungsbutton mit dem roten Pfeil und ....

Das war’s ! :super:

Treiber abklemmen, testen, staunen :D

Das klingt jetzt alles so furchtbar kompliziert, ist aber nach ein paar Versuchen wirklich kein großer Akt mehr, ihr werdet sehen.

Viel Spaß damit! :)
 

Attachments

  • Palladins Atmel Tools_1-15.xls
    123 KB · Views: 109
Hallo,


wow das ist ja wirklich großartig! Tausend Dank an Euch! :)
Ich weiß, Beiträge die "nur" zum Bedanken gut sind soll man ja eigentlich lassen, aber ich finde so einen riesen Aufwand für das Forum kann man durchaus mal würdigen.
Die Methode mit ohne Memory ist grandios umgesetzt und eigentlich noch besser wie ganz ohne Memory, da man so immer sofortigen Zugriff auf den ersten Modus hat :super:

Auch die Akkuwarnung ist genial verwirklicht.

Ich werde deine Anleitung auf jeden Fall mal ausprobieren und im Selbstversuch testen ob sie tatsächlich idiotensicher ist :p

Zudem werde ich mal versuchen Strobe im letzten Modus zu verwirklichen :rolleyes:


MfG


Edit:

Nach einiger Zeit meine ich nun das Programm halbwegs durchblickt zu haben.

Hier wird ja zu XX gesprungen, wenn man in der letzten Stufe ist:

If Modul = 0 Then
Goto Main ' Main / SOS / BEACON (letzter Modus) ersetzen durch: Goto XX
End If

Ist dann auch folgendes beispielsweise möglich?

If Modul = 5 Then
Goto BEACON ' Main / SOS / BEACON (Modus fuenf) ersetzen durch: Goto XX
End If

Zudem hab ich mal versucht Strobe umzusetzen.
Nachdem die Modi sowieso immer wieder von vorn anfangen, hab ich mir gedacht, kann ich ja am Ende etwas nutzloses Geblinker unterbringen, man weiss nie wozu man es mal brauchen kann :D
Könnte das so hinhauen?

'******* STROBE
STROBE:

Do
Gosub STROBEAn
Gosub STROBEAus
Loop

STROBEAn:
Ocr0b = Pulse
Waitms 50
Return

STROBEAus:
Ocr0b = 0
Waitms 50
Return
'******** /STROBE
 
Last edited:
... kann ich ja am Ende etwas nutzloses Geblinker unterbringen, man weiss nie wozu man es mal brauchen kann :D
Könnte das so hinhauen?

So wie der Treiber von rsfyfy konzipiert wurde, liegt der Blinkmodus bereits auf der letzten Stufe, unabhängig von der Gesamtzahl der Modes.

Die Adresse 00;00 im EEPROM (letzter Mode) bekommt dann auch ein FF - es sei denn, Du willst Strobe oder SOS flüstern :glgl:.

Wenn ich das richtig sehe - ich bin ja wirklich kein Strobe Experte :D - besteht ja Strobe ja nur aus einer kurzfrequentigen Abfolge von an und aus.


'******* STROBE
Strobe:

Do
Gosub Blitz1
Loop

Blitz1:
Ocr0b = Pulse
Waitms 5
Ocr0b = 0
Waitms 10
Return

'******** /STROBE

Jetza programmier ich den Scheiß ja doch :rolleyes:

Pulse schaltet ein, die "Waitms" danach sind die Einschaltdauer.
Ocr0b = 0 ist (quasi) aus, die folgende Zeile ist die Auszeit.

Ich hab keinen Schimmer über sinnvolle Intervalle, das musst Du ausprobieren oder aber nach einem passendem Oszilloskop Screenshot im Netz suchen.

Wenn die Werte mal stimmen, kannst Du ja noch einen "Blitz2" und weitere dahinterhängen (soweit halt der Speicher noch reicht) mit alternativen Abständen.

Falls der Tiny Random Befehle schluckt, könnte man über einen Zufallsstrobe nachdenken.

Okay, das war jetzt aber genug Kollaboration ;)
 
Hallo,


danke für deine Antwort! :)

So wie der Treiber von rsfyfy konzipiert wurde, liegt der Blinkmodus bereits auf der letzten Stufe, unabhängig von der Gesamtzahl der Modes.

Die Adresse 00;00 im EEPROM (letzter Mode) bekommt dann auch ein FF - es sei denn, Du willst Strobe oder SOS flüstern :glgl:.

Ja, deswegen war ja meine Frage, ob ich die anderen Modi auch so ansprechen kann.
Also ich sage beispielsweise ich will 6 Modi.
Dann leg ich auf den letzten Beacon, will aber noch einen zweiten Blinkmodus auf den vorletzten Platz haben.
Diesen wollte ich nun mit dem folgenden Befehl ansprechen:

If Modul = 5 Then
Goto SOS 'Main / SOS / BEACON (Modus 5) ersetzen durch: Goto XX
End If

Für Strobe wäre dann natürlich FF sinnvoll, aber Beacon fände ich mit ca. 40, also ca. 25%, besser.


Wenn ich das richtig sehe - ich bin ja wirklich kein Strobe Experte :D - besteht ja Strobe ja nur aus einer kurzfrequentigen Abfolge von an und aus.


'******* STROBE
Strobe:

Do
Gosub Blitz1
Loop

Blitz1:
Ocr0b = Pulse
Waitms 5
Ocr0b = 0
Waitms 10
Return

'******** /STROBE

Jetza programmier ich den Scheiß ja doch :rolleyes:

Pulse schaltet ein, die "Waitms" danach sind die Einschaltdauer.
Ocr0b = 0 ist (quasi) aus, die folgende Zeile ist die Auszeit.

Ich hab keinen Schimmer über sinnvolle Intervalle, das musst Du ausprobieren oder aber nach einem passendem Oszilloskop Screenshot im Netz suchen.

So in der Art hab ich das auch gemacht, nur eben Strobean und Strobeaus seperat...
Deine Variante ist natürlich Speicher sparender.

Übliche Frequenzen sind ca. 10 Hz, nachdem alle Hersteller meinen die Laufzeit verdoppelt sich bei Strobe, habe ich für beide Werte mal 50ms gesetzt. Das entsprich exakt 10 Hz.


Falls der Tiny Random Befehle schluckt, könnte man über einen Zufallsstrobe nachdenken.

Das ist ne ziemlich coole Idee, aber soweit ich das richtig heraus bekommen habe, gibt es keine direkte Funktion.
Zudem ist es ja nicht so wichtig erstmal.



Habt ihr eigentlich einfach am Anfang die Werte für $hwstack, $swstack, $framesize einfach gesetzt und dann nicht mehr verändert oder sind das die Werte, die sich am besten bewährt haben?

Der Speicher ist ja auch sehr knapp, beim compilieren sagt er mir, dass deine Version 94 % des Flash Speichers braucht :argw:

Wenn ich den Nachtwandermodus zusätzlich zu dem Burst aktiviere ist auch bereits der Speicher voll...

Zudem wollte ich eine weitere Variable als Byte definieren, jedoch ist dazu nicht mehr genügend Platz:

Error: 22 Line : 34 Out of SRAM space ,in File....

Nunja, 64 Byte SRAM ist ja wirklich nicht viel -.-

Deswegen auch meine Frage oben, da ich nun die folgenden Einstellungen habe:

$hwstack = 8
$swstack = 8
$framesize = 8

Und ebenfalls unter den Optionen den Stack etwas verkleinert habe.
So compiliert das Programm wenigstens mit der neu definierten Variable


Ich würde alles wirklich gerne ausprobieren, nur habe ich im Moment keinen PC mit der richtigen Schnittstelle zur Hand :(
Aber bald :D


Grüße
Fritz

Edit:
Mit Strobe eingefügt sind es schon 97% verbrauchter Speicher.
 
Last edited:
Hallo Fritz,

Ist dann auch folgendes beispielsweise möglich?

If Modul = 5 Then
Goto BEACON ' Main / SOS / BEACON (Modus fuenf) ersetzen durch: Goto XX
End If

Jain, das würde den Mode-Reset für die jeweilige Stufe aushebeln.
Das Programm ist nicht für die Nutzung von mehr als einem Blinkmodus an anderer als letzter Stelle optimiert.
Zur Not könnte man direkt nach dem "Main:" in irgendein Strobe-Unterprogramm schicken, muss dann aber das als Backup missbrauchte "U1adc" anstatt "Modul" abfragen.

Jeder Modus hat seine eigene EEPROM-Zelle, deren Wert per Variable "Pulse" genutzt, oder auch per "OCR0B = xxx" übergangen werden kann.


@ $hwstack, $swstack, $framesize

Anfangs, bzw. eine ganze Weile war ich bei diesen Werten unsicher, habe dann einfach großzügig den gesamten restlichen SRAM verteilt.
Mittlerweile bin ich recht sicher, daß wir nicht mehr als eine Handvoll (6 oder 8) Bytes $hwstack für die verschachtelte Gosub-Springerei brauchen, $swstack und $framesize könnte man auch auf 0 reduzieren.


@ Flash Speicherplatz

So bekommt man ca. 40 Bytes frei:

Adcsra = &B11000111
ändern in:
Adcsra = &B11100111

U1adc = U1adc + Getadc(1)
ändern in:
U1adc = U1adc + ADC

(Technische Erklärung: der HighLevel-Befehl "Getadc" war hier überflüssig, wenn man eh schon die ADC-Register manuell vorbereitet.)

Außerdem empfehle ich bei der aktuellen Bascom-Demo (2.0.7.1) den Befehl "Powerdown" zu ersetzen durch:

Adcsra = 0 'ADC aus, -140µA @ Powerdown (ca. soviel wie der Spannungsteiler), in vorigen Versionen vergessen
Mcucr = Bits(se , Sm1)
Sleep

Weniger weil es noch ein paar Bytes spart, sondern mehr weil diese Version einen Bug hat, der den Tiny nur in den Idle schickt. (Auch wenn in unserem Fall eh der Spannungsteiler ständig 0,1x mA zieht, muss das ja nicht sein)
 
Last edited:
Hallo,


danke nochmals für die Antwort!

Sind diese Treiber hier geeignet, Kosten nur ca. 2 Euro pro Stück:
http://www.intl-outdoor.com/amc71353-5mode-circuit-board-nanjg-ak47a-p-304.html

Also wenn man noch 5 7135er huckepack lötet. Denn ich finde es wesentlich schöner, wenn die Treiber auf der Rückseite keine Bauteile mehr haben.
Schaut fast so aus, wie wenn tiny 13A drauf steht, könnte aber auch V sein.


Dann hätte ich noch eine Frage bezüglich des ersten Bits des MCU Status Registers.
So ganz habe ich das aus dem Datenblatt noch nicht verstanden:
• Bit 0 – PORF: Power-on Reset Flag
This bit is set if a Power-on Reset occurs. The bit is reset only by writing a logic zero to the flag.
To make use of the Reset Flags to identify a reset condition, the user should read and then reset
the MCUSR as early as possible in the program. If the register is cleared before another reset
occurs, the source of the reset can be found by examining the Reset Flags.
Das heißt ja so, wie ich das aufgefasst habe, falls ein POR stattfindet wird dieses Bit auf 1 gesetzt.
Deswegen verstehe ich gleich mal den erste if Vergleich nicht :argw:

If Mcusr.0 = 0 Then
Ocr0b = 255
Goto Main
Else
Mcusr.0 = 0
End If

Also was er macht weiß ich, wenn Mcusr.0 = 0 setzte Helligkeit = 255 und springe zu Main.
Dass du dann, falls Mcusr.0 = 1 das Bit resetest ist auch klar, aber ist das Bit dann nicht einem Reset immer auf 1?
Die einzige Möglichkeit wäre ja, dass ein Reset durch den Watchdog durchgeführt wurde.
Also angenommen der Watchdog führt ein reset durch, wieso wird dann einfach Ocr0b = 255 gesetzt und zu Main gesprungen?
Ein Brown Out oder ein External Reset sollte ja nicht vorkommen.

Bitte entschuldigt meine Unwissenheit und die blöden Fragen, ich habe erst ein Semester cpp und ein ganz klein wenig Assembler hinter mir.


MfG
 
Hallo,

13V oder 13A ist egal, Hauptsache man bekommt auch das was abgebildet ist, und keinen PIC...

@ Reset-Abfrage-Part
Erstmal: Das sind sicher keine dummen Fragen. Zumal dieser Part mittlerweile tatsächlich etwas fraglich ist, folgender Hintergrund dazu:

Als mögliche Auslöser kommen Brown-Out und Reset-Pin in Frage, den Wachhund braucht's nicht.
Reaktion auf BOR (in Form von "Powerdown") schien mir anfangs als letzter Rettungsanker bei Tiefentladung nützlich. Eher für den Tiny selbst, damit dieser keinen Unsinn mit dem EEPROM anstellt, falls es mal irgendwie zu einer Art "Reset-Schleife" kommen sollte.

Ein mehr als rein hypothetisches Problem war aber auch:
Bei den Versionen mit "Sternchen-Anpassung" kam es am Programmier-Kabel immer zu unerwünschten EEPROM-Änderungen, da PB0 = MOSI.

Daher die Abfrage des PORF, welches der Tiny direkt nach dem allerersten Erwachen bei ca. 1,2V setzt (übrigens daraufhin gleich auch noch BORF). Nach einem Reset - egal welcher Ursache - wird dann das zurückgesetzte PORF erkannt und man kann den weiteren Ablauf "umleiten".

Jedoch hat das später wohl mehr Probleme als Nutzen gebracht:
Zumindest für meine Anwendung hat sich "Powerdown" als ungünstig bis gefährlich erwiesen, siehe #116, daher geändert zu "Vollgas und Ende".
Bei Palladin kam dann wiederum ein prellender oder sonstwie problematischer Schalter hinzu, der BOR zum Regel- anstatt Ausnahmefall machte und für jede Menge Verwirrung sorgte.
Nachdem ich die Abfrage hinter die 100ms EEPROM-Schreibverzögerung verfrachtet habe, scheint es da keine Probleme mehr zu geben. Auch wenn es in der "Sternchen-befreiten" Version vermutlich recht nutzlos ist, würde ich das im Zweifelsfall jetzt einfach so lassen.
 
Sind diese Treiber hier geeignet, Kosten nur ca. 2 Euro pro Stück:
http://www.intl-outdoor.com/amc71353-5mode-circuit-board-nanjg-ak47a-p-304.html

Sieht ja fast aus wie der Kai Treiber.
Ich unterstelle Mal, das AK74A Board bei Intl-outdoor ist die Weiterentwicklung.

Mit Hinweis auf FGA#58 spricht eigentlich grundsätzlich nichts gegen eine Programmierung.
Vermutlich liegt es nur an den zusammengerückten Komponenten, aber das Board wirkt auf mich größer wie 17mm.

Eng könnte es an der ebenfalls nähergerückten Diode werden, und da muß ja auch noch eine Litze dran, der Clip stülpt sich ja rundherum etwas um den Tiny.

Die für die ADC Werte verantwortlichen Widerstände sowie die Vf der Diode sind reine Glücksache, sollten aber nicht wirklich ein Problem darstellen.

Für den Preis kann man sicherlich mal ein paar Stück bestellen und testen.
Gib aber mal Bescheid ob sie was taugen.

Also wenn man noch 5 7135er huckepack lötet.
Was den Preisvorteil relativiert, es sei denn Du hast haufenweise Linearregler zuhause herum liegen.

Dir ist schon klar, das wären zwei "Trippledecker"?
Hast Du schon mal einen Linerarregler zwischen den Fingern gehalten bei frischer Bestromung?
Das Teil wird selbst mit nur einer Ebene flott richtig heiß.

In Notsituationen, bei extrem kurzen (oder langen, i.V.m. einer ordentlichen Feder) Bodies gebe ich Doppeldeckern meine Absolution, soll heißen, ich würde einen Shiningbeam 1,4A Treiber komplett verhuckepacken.
Bei Trippeldeckern hätte ich ein ganz, ganz schlechtes Gefühl.

Solange keine Not am Mann ist, würde ich unbedingt bei dem bewährten zweiseitigen Treiber bleiben. Das macht schon Sinn, daß die Heizkörper gut verteilt sind :D.

Dann hätte ich noch eine Frage bezüglich des ersten Bits des MCU Status Registers.

Ganz ehrlich, ich habe nicht den blassesten Schimmer :).

rsfyfy hat es bereits angedeutet.
In ganz vereinzelten Fällen kam es bei meinen Tests zu kleineren Aussetzern.
Manchmal hing die Notabschaltung, dann wiederum klemmte der Burst wenn direkt eingeschaltet, die ADC Warnung fiel aus, etc.
Das war extrem knifflig weil dies alles i.d.R. nur in 1 von hundert Fällen auftrat, das hat den Testumfang extrem potenziert...

Wie auch immer, ich wollte einen Treiber, der unter allen Umständen 110% funktioniert.
Es ist noch immer ein Albtraum der mich verfolgt, daher wollte ich definitiv vermeiden, zu einem späteren Zeitpunkt noch irgendeinen Bug zu finden, der mich zum nachbessern sämtlicher bislang gebauten Lampen zwingt ... Wer meine Wärmeleitpasten Bettungen kennt: Eine einzige Lampe ist schon der Horror.

Absolute Zuverlässigkeit auch unter den widrigsten Umständen war hier meine Philosophie, ich glaube, das ist man auch gerade diesem Treiber gegenüber schuldig.

Mit der Zeit sammelten sich bei mir während der Tests schwächelnde Bauteile wie besagter Clicky oder auch ein extrem niedrig taktender Tiny.
Bei Funktionstests habe ich diese Teile dann ganz bewußt schwerpunktmäßig eingesetzt um den Treiber so weit wie es geht zu fordern, um wirklich jede Eventualität so weit es irgend geht zu berücksichtigen.
Herausgekommen ist ein Treiber der funktioniert. Punkt.
Immer! Punkt. :steirer:

Vielleicht ein Schönheitsfehler ist es, daß der Treiber im Falle eines Brownouts auf Max geht.
Das ist in Hinblick auf die Zuverlässigkeit IMO immer noch die beste Lösung.
Zudem signalisiert es einem zumindest auf den niedrigeren Stufen, daß irgend etwas mit der Lampe im Argen liegt, dem man vielleicht auf den Grund gehen sollte.

Das war ein Heiden Stück Arbeit, den Treiber so weit zu bekommen.
Daher auch von meiner Seite die Empfehlung: Lass es so, falls es keinen triftigen Grund dagegen gibt.

Generell würde ich allen raten:
Auch wenn Euch das eine oder andere mißfällt, baut das Teil möglichst erst mal 1 zu 1 nach.
Bei Erfolg kann man im 2. Schritt dann Änderungen an Hard- und/oder Software Schritt für Schritt vornehmen.
Ansonsten kann es sein, daß man bei der Fehlersuche sehr schnell auf verlorenem Posten steht.
 
Back