Interesse an individuellen led Treibern

Hallo chp,

über den Spannungsteiler wird die Schwelle für die low-battery Warnung eingestellt.


Ich habe übrigens gestern weitere Treiber dieses Typs von kaidoman bekommen, sie haben erneut ein anderes Platinenlayout und sind auch anders bestückt.

Übrigens gibt es einen Thread, da steht schon Einiges zu den Treibern drin.
http://www.messerforum.net/showthread.php?t=57416&highlight=trustfire+801




Heinz


Edit: Leider hat dieser Treiber wieder leichtes PWM Flimmeren auf low. Auf high flimmert nichts.
Den Blink zur Bestätigung, wenn Memory eingerastet ist, gibt es nicht mehr.
Weiterhin braucht man dagen den doppelten Tab, wenn Memory zugeschlagen hat, um den Modus zu wechseln.


Neuste Version mit fast* fehlerfreiem Layout *Der mittlere Pin von Q3 liegt über einer Leiterbahn...
7135new2psss.jpg


PWM sichtbar, 579Hz auf low
7135new2graphwrk8.jpg


Frequenzspektrum auf low
7135new2frequenzi517.jpg
 
Last edited:
@Heinz
Ich hoffe du schreibst hier noch was zu deinen neuen Treibern. Ich hab den grade auch bei Kaidomain geordert. Den weiß ich schon was da kommt.

Es scheint hier im Forum noch gar keinen Tread zu geben wo verschiedene Treiber vorgestellt werden.Also könnte man diesen Tread
nicht leicht abändern also:
Interesse/Vorstellung an/von inviduellen Led-Treibern.
Hallo Herr Moderator??
Gruß
Nebel-Jonny
 
Hallo chp,

über den Spannungsteiler wird die Schwelle für die low-battery Warnung eingestellt.

Gut sowas in der Richtung dachte ich mir schon. Kann ich für die erste Version also erstmal weglassen.



Das sind exakt die Treiber die ich auch habe.
Unterschied zwischen den Treibern:
Die früher gezeigten Treiber hatten ein Fehler im Layout und deshalb musste der C mit auf das GND-Pad des Attiny gelötet werden. Die Pads die eigentlich dafür vorgesehen waren, liegen auf VCC und PWM (statt GND), was keinen Sinn macht.
Die neue version ist nun korrekt.
 
Allerdings zusätzlich noch ein Spannungsteiler (R1 und R2 gehen an Pin2 des Attiny und VCC/GND), dessen Funktion mir noch unklar ist.
über den Spannungsteiler wird die Schwelle für die low-battery Warnung eingestellt
Jein, für die Erkennung ja aber die Schwelle glaub ich nicht,
ich vermute eher das der Tiny mit interner Referenz des ADC-Ports arbeitet (1,1V). Würde man jetzt die 4,2-2,7V der LIR-Zelle einfach auf den ADC-Port geben würde der Tiny schaden nehmen oder im besten Falle ständig den Maximalwert anzeigen. Durch den 3/13 Spannungsteiler liegen zwischen 0,97V und 0,62V an. Mit der aufbereiten Spannung kann der ADC arbeiten. Die low-battery Schwelle wird duch die Programmierung eingestellt.


Realisiert werden kann die "Erkennung der Auszeit" meiner Meinungs nach mit einem Puffer Kondensator und der Brownout Detection.
Klingt interessant , könntest du das ein bisschen genauer erklären?

Gruß
Matthias
 
Jein, für die Erkennung ja aber die Schwelle glaub ich nicht,
ich vermute eher das der Tiny mit interner Referenz des ADC-Ports arbeitet (1,1V). Würde man jetzt die 4,2-2,7V der LIR-Zelle einfach auf den ADC-Port geben würde der Tiny schaden nehmen oder im besten Falle ständig den Maximalwert anzeigen. Durch den 3/13 Spannungsteiler liegen zwischen 0,97V und 0,62V an. Mit der aufbereiten Spannung kann der ADC arbeiten. Die low-battery Schwelle wird duch die Programmierung eingestellt.

Danke für die Erläuterung! Das umzusetzen sollte auch kein Problem sein.

Klingt interessant , könntest du das ein bisschen genauer erklären?

ja werde ich, aber nicht jetzt.


Ansonsten gibt es Neuigkeiten.

Habe weitere Treiber bekommen und zwar die 5-Mode und die 16-Mode von DX.

Links 5-Mode, Rechts 16-Mode. Die Platine sieht etwas anders aus, aber das Layout ist exakt gleich. Der Unterschied liegt wohl nur im Programm.
2lx85ub.jpg


Ansonsten habe ich eben das vorhandene Programm vom aufgelöteten Chip runtergezogen und disassembled. Um aus dem Assemblercode Erkenntnisse zu gewinnen, bedarf es allerdings noch einiger Stunden.

Zumindest habe ich aber herausgefunden, dass die Attiny13V nicht getauscht werden müssen, sondern neu programmiert werden können.
Das ist doch schonmal eine gute Nachricht auf dem Weg zum Traum-UI.
 
ich habe mal den Versuch gestartet, den MC einer Treiberplatine neu zu
programmieren. Die Wahl fiel auf den Attiny13 von Atmel, der auch bei den Treibern
von DX un Kai zum Einsatz kommt. Primäres Ziel war aber, den Controller von der
Nitecore D10 (Attiny13V) neu zu programmieren, mit Unterspannungsabschaltung.
Das Vorhaben habe ich erstmal genervt zur Seite gelegt, kommt ev. später.
langjährige Hobbyprogrammierung für x86 CPU's in C und Assembler ist vorhanden.
Es mussten die neuen Befehle und die Eigenheiten des Attiny13 gelernt werden.
Neue Hardware in Form eines ISP Programmers (USB Anschluss) für den MC angeschafft.

Als Versuchstreiber habe ich einen Linearregler mit 3x7135 und PIC 12F629 ausgesucht.
Da der MC 12F629 von Microchip nicht pinkompatibel mit dem Attiny13 ist, musste etwas umgelötet werden.

Das Programm ist in Assembler geschrieben.

Attiny13 im 8 pol. DIP Gehäuse. 2,7 bis 5,5 Volt. Attiny13V ab 1,8 Volt
Taktfrequenz 1,2Mhz. PWM Frequenz ca. 1,5kHz. in meine Augen reicht das.
Kann erhöht werden, wenn der MC mit 4,8 oder 9,6 MHZ getaktet wird.

3 Modi mit Memory, welches nach ca. 2 Sek. durch 2 maliges kurzes Blinken signalisiert wird.
Low: PWM 1:255 Stromaufnahme 6mA
Middle: PWM 1:10 Stromaufnahme 130mA
High: keine PWM, sondern volle Betriebsspannung, Strom ca. 1000mA
jeweils bei ca. 4,1 Volt Akkuspannung gemessen.

Bei unterschreiten der Spannung von ca. 3,4 Volt wird in den nächst niedrigeren Modi runter geschaltet.

wenn die Spannung im LOW Modus dann nicht mehr über 3,4 Volt gehalten werden kann,
wird die Lampe ausgeschaltet und der MC geht in den sleep Modus.
Stromaufnahme im sleep Modus: ca. 0,1mA. Bedingt durch den Spannungsteiler für den AD Wandler.

Man kann also ungeschützte Zellen verwenden.

Versuchsaufbau
versuchsaufbau937y.jpg

Treiber
alt0z4f8.jpg

Treiber ohne Controller
alt178ut.jpg

mit Attiny13
fertig1z5hc.jpg


fertig2k463.jpg

Versuchslampe mit CREE P4, macht übrigens ganz gut Throw.
lampe212q.jpg

Betrieb mit LIR 18350 im ausgedrehten Batterierohr.
lampe1h75a.jpg
 
Taktfrequenz 1,2Mhz. PWM Frequenz ca. 1,5kHz. in meine Augen reicht das.
Kann erhöht werden, wenn der MC mit 4,8 oder 9,6 MHZ getaktet wird.
Der Attiny kann intern nur 128 kHz, 4,8 und 9,6 MHz erzeugen, du meinst 128 kHz statt 1,2 MHz oder? Reicht für die Anwendung aber auch locker aus!

3 Modi mit Memory, welches nach ca. 2 Sek. durch 2 maliges kurzes Blinken signalisiert wird.
Low: PWM 1:255 Stromaufnahme 6mA
Middle: PWM 1:10 Stromaufnahme 130mA
High: keine PWM, sondern volle Betriebsspannung, Strom ca. 1000mA
jeweils bei ca. 4,1 Volt Akkuspannung gemessen.

Interessant! Kannst du prinzipiell erläutern wie du die "Erkennung der Schalterdrückens" realisiert hast?

Hast du den Memory Modus mit dem EEPROM realisiert?


Ich hoffe das ich in ein paar tagen auch mal weitermachen kann, aber bisher blockiert noch ein anderes Projekt meinen Tisch..
 
Alle Taktfrequenzen 128KHz, 4,8MHz und 9,2MHz können noch mal durch 8 geteilt (Fuse Bits) werden. Aber Vorsicht bei 128kHz.
Das wären dann 16kHz. Mein Programmer z.B. kann dann nicht mehr über die ISP Schnittstelle mit dem MC kommunizieren.
Das geht dann nur mit Tricks wieder rückgängig zu machen.
Interessant! Kannst du prinzipiell erläutern wie du die "Erkennung der Schalterdrückens" realisiert hast?
Die Lampe wird eingeschaltet und damit der MC neu gestartet.

Hast du den Memory Modus mit dem EEPROM realisiert?
Im ausgeschalteten Zustand gehen ohne Betriebsspannung alle Daten verloren. Deshalb EEPROM. Geht nicht anders.
 
Ich grabe den Thread mal wieder aus.

Ist daraus nix geworden? Das wäre jammerschade. :(

Ich für meinen Teil wäre fürs Erste schon unbeschreiblich dankbar, wenn eine Gute Seele es schaffen könnte, den 2- bzw. 3-Modi Kai Linearreglern die Memoryfunktion abzugewöhnen.

Dann hätte ich im Grunde zumindest im Akkubereich alles was ich bräuchte :cool:.
 
...Ich für meinen Teil wäre fürs Erste schon unbeschreiblich dankbar, wenn eine Gute Seele es schaffen könnte, den 2- bzw. 3-Modi Kai Linearreglern die Memoryfunktion abzugewöhnen.

Dann hätte ich im Grunde zumindest im Akkubereich alles was ich bräuchte :cool:.


Das möchte ich unterstreichen!

Die Treiber mit 7135er Linear Reglern der letzen Inkarnation arbeiten mit 4,5kHz PWM und flimmern nicht mehr.

Einzig das Memory nervt...




Heinz
 
Ich hätte das HEX File und das Reassemble File wenn jemand damit was anfangen kann.
Für das entwirren bzw. selbst schreiben hat mir bis jetzt die Zeit gefehlt.

Mit Pech ist der Memory Fluch und Segen zugleich, denn warscheinlich ist ohne den EEPROM kein Modwechsel möglich.
Wenn jemand von euch ein LCR-Meter zu Hand, könnte er mal den Kondensator durchmessen, von Kapazität könnt man auf Überbrückungszeit schließen.

Gruß
Matthias
 
Hallo,

um dieses Thema mal wiederzubeleben, hier eine Anleitung wie man (m)eine alternative Software auf die Attiny13V-Lineartreiber bügelt.
Es wird keine Erfahrung in Sachen Microcontroller vorausgesetzt, ein paar Grundkenntnisse für Elektronik-Bastelei (und PC) schaden natürlich nicht...
Ansonsten braucht man kaum mehr als:

- PC mit paralleler Schnittstelle
- ein altes, paralleles Druckerkabel
- etwas Geschick für feine Lötarbeiten, hält sich aber wirklich in Grenzen
- die kostenfreie Demo-Version von Bascom-AVR

Erst noch kurz und knapp zum Sinn der Sache, offenbar bin ich ja nicht der Einzige, der diese Treiber teils "überfunktioniert" findet, neben Geblinke auch im Memory eher Ärgernis als Nutzen sieht. Außerdem stören mich recht geringe PWM-Frequenzen.

Mein Programm bietet daher folgende Funktionen:

- 2,3 / 19 kHz PWM
- memoryfreie (1) 2 oder 3 Modi *
- Dimmstufen fein einstellbar, extrem niedriges "Low" möglich *
- 2stufiges Unterspannungsverhalten
- gute Ausnutzung der EEPROM-Lebensdauer (wurde hier ja schon thematisiert) >6Mio Wechsel
- * kann später ohne PC mittels "Sternchen" an der Unterseite noch verändert werden.


Wie bereits angedeutet, ist der Programmieradapter im einfachsten Fall lediglich ein profanes Druckerkabel, von dem ein Stecker aufgeschraubt, 5 Leitungen ausgelötet und zum Treiber verlegt werden. Sicherheitshalber empfiehlt sich jedoch zusätzlich ein paar Widerstände (so zwischen 100 bis 500 Ohm) einzusetzen, die machen sich m.E. am besten im Stecker der Gegenseite.

Hier der Schaltplan
(die Buchsenleiste können wir weglassen und direkt an den Treiber gehen)

Die Bezeichnungen findet man auf Seite 2 des Attiny13-Datenblatt, oder auch in Bascom (View -> Pin Layout).
Dann durchleuchtet man den Treiber von unten (Leiterbahnverlauf) und notiert sich dankbar alle Möglichkeiten nicht direkt an den Pins löten zu müssen. Eine Ausnahme macht da - zumindest beim Layout meiner Version - nur der "Reset", erfreulicherweise der wohl bestzugängliche Pin.

Neben den Datenleitungen braucht der Tiny außerdem noch eine Stromversorgung.
Es gäbe zwar die Möglichkeit den Parallelport auch dafür zu nutzen, würde aber den Aufwand auch nicht gerade vereinfachen. Außerdem braucht man, wenn man später das Ergebnis testen möchte, eh eine andere Spannungsquelle (Akku / Netzteil).
Über den normalen Eingang des Treibers ist eine Spannung zwischen 3 und 6V genehm, notfalls wäre auch denkbar diese z.B. vom Batteriefach einer Fernbedienung mit zwei frischen Alkaline abzugreifen.

Wenn alle Leitungen verlegt sind, sollte es ungefähr so aussehen:



Übrigens, anfangs hätte ich wegen der Peripherie an Board - vor allem dem Spannungsteiler am SCK - evtl. Probleme erwartet, was sich jedoch nicht bestätigt hat.


So, die Hardware-Vorbereitungen soweit abgeschlossen, gehen wir zum Software-Part über.
Nachdem Bascom installiert und gestartet ist, wird ein unbeflecktes Fenster mit meinem Programm becopypastet:
(wenn man vorher auf meinen Beitrag "zitieren" geht und aus dem Fenster dann kopiert, sieht das ein bisschen geordneter aus, hier sind irgendwie die "Space-Zeichen" verloren gegangen)


$regfile = "attiny13.DAT"
$crystal = 4800000
$hwstack = 32
$swstack = 8
$framesize = 16


Portb = &B00111001

Tccr0a = &B00100011
Tccr0b.1 = 1 '<- 2,3kHz, für 19kHz ersetzen durch: TCCR0B.0 = 1

Admux = &B01000001 'ADC
Adcsra = &B11000110 '/ADC


Dim U1adc As Word
Dim U2adc As Word
Dim Index As Byte
Dim Count As Byte
Dim Modul As Word

'*********************

If Mcusr.0 = 0 Then
Powerdown
Else
Mcusr.0 = 0
End If

Waitms 100

Readeeprom Index , 63
Modul = Index.7
Reset Index.7

If 62 < Index Then
Index = Modul
Goto Init
End If

Readeeprom Count , Index
Incr Count

If Count = 0 Then
Init:
Incr Index
Count = Modul
Writeeeprom Count , Index
Index.7 = Modul
Writeeeprom Index , 63
Else
Writeeeprom Count , Index
End If

'****************************

Modul = Modul + 2

Index = Count Mod Modul

Count = 255

If Index = 0 Then
Readeeprom Count , 0
End If
If Modul = 3 Then
If Index = 1 Then
Readeeprom Count , 1
End If
End If

'************************

U1adc = 1000

Ddrb.1 = 1

Ocr0b = Count


Do

If Pinb.3 = 0 Then
Count = Count - 1
Gosub Flash
Writeeeprom Count , Index
End If

If Pinb.4 = 0 Then
Count = Count + 16
Gosub Flash
Writeeeprom Count , Index
End If

If Pinb.0 = 0 Then
Readeeprom Count , 63
Toggle Count.7
Gosub Flash
Bitwait Pinb.0 , Set
Writeeeprom Count , 63
Wait 1
End If


Waitms 50 'ADC
U2adc = U1adc
Shift U1adc , Left , 5
U1adc = U1adc - U2adc
U1adc = U1adc + Getadc(1)
Shift U1adc , Right , 5

If U1adc < 470 Then '<- 2,8V (470 / 1024 * 1,1 / 3 * 13 + 0,6)
Gosub Flash
Decr Count
If Count = 0 Then
Ddrb.1 = 0
Powerdown
End If
Elseif U1adc < 550 Then '<- 3,2V (550 / ...)
If Modul < 4 Then
Gosub Flash
Gosub Flash
Gosub Flash
End If
Modul = Modul + 64 '<- 51s Blink-Abstand (65536 / [<-Teiler] * 0,05)
End If '/ADC

Loop

'*********************

Flash:

Ocr0b = 0
Waitms 30
Ocr0b = Count
Waitms 400
Return

End

'******************************************************



Die Voreinstellungen bei Bascom habe ich nicht mehr 100%ig im Kopf, meine jedoch kaum etwas verstellt zu haben, was hier von besonderer Bedeutung wäre.
Mal unter Options->Programmer schauen, ob der "Sample Electronics Programmer" gewählt ist. Dort ein Häkchen bei Auto Verify und Erase Warning, der Rest ohne.
Die Parallelport-Einstellungen (378, Delay 0) blieben bei mir unverändert.

Per "Compile"-Button wird das Programm in eine Chip-gerechte Sprache übersetzt.
Das Treiber-Kabel-Gewirr angeschlossen (optimalerweise bereits vorm Rechner-Start) und stromversorgt, sollte ein Klick auf "Program Chip" den "Sample Electronics Programmer" ohne Fehlermeldungen starten und dieser automatisch einen "Attiny13" erkennen.

Im Programmer werden Aktionen i.d.R. ohne Nachfrage durchgeführt, dementsprechend vorsichtig muss man agieren. Das gilt besonders für den Reiter den wir uns gleich als Erstes anschauen, die "Lock and Fuse Bits".
Nun ist da ja noch ein Programm auf dem Chip, welches man sich vielleicht gern sichern würde, aber solange das Lockbit 21 nicht auf "11:No memory lock..." steht, kann man sich das laut Programmer trotzdem mögliche Lesen des "ROM" - und damit eine Datei voller Datenmüll - gleich sparen.
Der Chip kann nun gelöscht werden: "Erase chip(flash ROM and EEPROM)"

Wieder zurück zum Reiter Fuse Bits, mit der besonderen Vorsicht ist gemeint, daß man sich dort mit falschen Einstellungen (z.B. Ändern von "High 3") vom Chip aussperrt, also mit dem Parallel-Programmer keinen Zugriff mehr bekommt. Die Bits sind entsprechend der folgenden Abgebildung ggf. zu ändern und werden erst übertragen sobald man die "Write FS(H)" Buttons anklickt.



Anschließend wird der Chip mit dem Programm beschrieben, welches der Reiter "FlashROM" bereit hält und mittels "Write buffer to flash ROM" überträgt. Bei mir gab es da hin und wieder Übertragungsfehler ala "Difference at ..." (möglicherweise funkt die Peripherie ja doch ein wenig dazwischen), aber spätestens nach ein paar Anläufen war es dann immer fehlerfrei drin.

Als vorerst letzten Schritt, verpassen wir dem (Reiter) EEPROM, wo lauter "FF" stehen sollten (ansonsten: "Clear buffer"), halbwegs sinnvolle Werte für die beiden Dimmstufen. Dazu kommt ins 1. Feld (00,00) der Wert 09 und ins 2. (00,01) der Wert 32, anklicken->tippen->Enter, gefolgt vom "Write buffer to EEPROM"-Button.

Im Prinzip wäre die Sache nun soweit fertig, bevor man den Treiber wieder von der Verkabelung befreit, wäre aber ratsam mit einen kleinen Testaufbau zumindest ein paar Grundfunktionen zu prüfen. Zum Praxis-Test mit LED muss das Kabel vom PC getrennt sein. Der Parallelport ist eigentlich nicht zum An- und Abstecken bei laufenden Rechner gedacht, dessen Missachtung gelang mir zwar bislang ungestraft, eine Empfehlung möchte ich jedoch nicht daraus machen.

Der Treiber sollte nun mit der gewohnten Stromunterbrechungs-Prozedur drei deutlich unterschiedliche Modi nacheinander durchschalten.

Die mit PB3, PB4 und PB0 bezeichneten Pins führen jeweils zu offenen Lötbrücken, sowie Durchkontaktierungen an die Unterseite, teilweise als Sterne ausgeführt. Durch temporären Masseschluss dieser Pins ändert man die Helligkeit des jeweiligen Modus (ausgenommen High). PB4 durchläuft in 16 gröberen Schritten vorwärts die 256 Werte, PB3 macht die Feinabstimmung rückwärts.
Mit PB0 schaltet man (ebenso mittels "Antippen" einer Brücke, nicht zum dauerhaften Masseschluss gedacht!) den Treiber zwischen 2 und 3 Modi um. Die Helligkeit ändert sich bei wiederholten Schluss in zwei Stufen, welche keinerlei weitere Bedeutung haben, als den aktuellen Stand anzuzeigen: dunkler = 2, heller = 3.
Die Werte werden immer sofort gespeichert, die Modi können zum Vergleich durchgeschaltet werden.
Das Sternchen-Gefummel ist natürlich mehr Notbehelf als "UI", damit man später nicht nochmal an den PC muss. Vielleicht bekommt man es ja mit etwas chirurgischen Geschick auch ohne Zerlegen der Lampe hin.

Falls man über eine stufenlos regelbare Spannungsquelle verfügt, kann man gleich noch die Funktion bei Unterspannung testen.
Mit dem 10k-3k Spannungsteiler, der - soweit ich bei den häufig ändernden Layouts noch Überblick habe - immer mit diesen Werten verbaut ist (Aufdruck 103 und 302), sollte sich die Funktion wie folgt darstellen:
Stufe1: <3,2V LED blinkt in (umfangreich wählbaren) Abständen dreimal kurz.
Stufe2: <2,8V LED blinkt dauerhaft und wird dabei pro halbsekündlichen Blinker um je eine der max. 255 Stufen dunkler, demzufolge nach spätestens 2 Minuten = aus, Tiny geht schlafen.

Wo man recht einfach selbst Anpassungen im Programm vornehmen kann, ist an den entsprechenden Stellen mit Rechenformel kommentiert.

Zum ADC (Spannungssensor mit Umrechnung in digitale Werte) ist noch zu erwähnen, daß es mir zumindest auf Software-Ebene nicht gelungen ist, eine akzeptable Genauigkeit zu erreichen, sobald das PWM Richtung zweistellige kHz geht. Ich meine so ziemlich alles was das Datenblatt hergab probiert zu haben, die Schwellen drifteten je nach Tastgrad bis 0,3V drunter oder drüber...
Daher ist zwischen folgenden Möglichkeiten zu entscheiden:

- (Standardeinstellung) Beschränkung auf 2,3kHz, da sind keine nennenswerten Abweichungen feststellbar und das PWM ist auch bereits recht harmonisch, man muss den Blick schon extrem schnell bewegen, um noch ansatzweise "Punkt-Linien" der Lichtquelle wahrzunehmen.
- [EDIT] Kondensator-Methode war leider ein Fehlschluss, funktioniert in keinster Weise
- die gekennzeichneten ADC-Parts im Programm entfernen und sich auf den Helligkeitseindruck verlassen, eine Not-Abschaltung bei 2,4V hat man trotzdem noch - für Li-Ion allerdings schon recht ungesund, man sollte es im Normalfall früher wahrnehmen und reagieren.

So, ich hoffe nichts Wichtiges vergessen zu haben und daß jemand damit was anfangen kann, Fragen oder sonstiges Feedback sind natürlich jederzeit willkommen.
 
Last edited:
Hallo,

hier meine Treibervorstellung.

meine Programmierung:
genauere ADC Wandlung: Betrieb des ADC im 8 Bit Interrupt Modus. nur ADCH Register.
ADC starten, IRQ abwarten, ADCH auslesen. Das 8 x mal alle 0,5 Sec.
Die ausgelesen Werte 16 bittig addieren und wieder durch 8 teilen. ergibt guten Mittelwert.
Software PWM zwischen 2,5 und 4kHz. kein Flackern sichtbar. deine 2,3kHz sollten reichen.
Falls du ein Oszilloskop zur Hand hast, erleichert die Programmierung;).
Programm ist in Assembler geschrieben.

bei Fragen fragen.

Gruß
Rainers
 
bei Fragen fragen.

Hallo Rainers,

ich habs mir in dem anderen Thread verkniffen, damit das dort nicht zu technisch wird, aber dann frag ich halt jetzt mal hier:

Was ich bei deiner Beschreibung besonders interessant finde, es klingt als würdest du beim Moduswechsel nicht das EEPROM nutzen, sondern den Tiny die "Auszeit" erkennen lassen, ähnlich wie es hier schon diskutiert wurde.
Allerdings ist der Kondensator - zumindest auf deinem Bild - wohl der Originale bzw. nicht deutlich größer, welcher sich normalerweise in deutlich weniger als 250ms entladen müsste.
Wäre schön wenn du dazu ein paar Worte schreibst. :)

p.s. Wäre natürlich noch schöner, wenn du dein Programm hier zur Verfügung stellst, falls das für dich ok ist.

EDIT: Ich habe deine Beschreibung nochmal gelesen und vermutlich vorher falsch verstanden.
Die Funktion ist im Prinzip ein normales "Memory", nur mit 250ms in einem kürzeren Zeitrahmen, richtig?
 
Last edited:
Hallo rsfyfy,

beim Programmstart EEPROM auslesen, sofort die nächste Stufe ins EEPROM,
nach 250ms Stufe 1 ins EEPROM. Alles ohne Kondensator. so einfach ist das :D.

einen Haken gibt es aber noch. Wenn die Lampe kürzer wie 250ms eingeschaltet war,
und man die Lampe dann einschaltet, ist man in der nächsten Stufe.

Aber wer leuchtet schon weniger als 250ms. Normalerweise tritt das Problem nicht auf.

Gruß
Rainer
 
Last edited:
Wow, super und tausend Dank für die Mühe!

Als blutiger Laie auf dem Gebiet raucht mir zwar gerade der Kopf, aber das ganze sieht machbar aus.

Ausgesprochen erfreulich ist, daß die Programmierung auch noch "on Board" erfolgen kann.
Da stellt sich natürlich die Frage, trotz der winzigen Abmessungen, ob man nicht vielleicht sogar noch einen temporären Anschluss von oben ohne löten realisieren könnte. Das würde den Aufwand bei mehr wie 1-2 Exemplaren ja deutlich beschleunigen.
Im Augenblick schwebt mir ein Silikon Abguss vom Atmel vor, mit winzigen herausragenden Nadeln als Kontakte.
Extrem filigran, aber so ließen sich recht mühelos auch Kleinserien realisieren.

Eine Frage noch auf die schnelle: Mir ist irgendwann mal eingebläut worden, man solle bloß keinen Treiber ohne Verbraucher anschließen.
Das bereitet hier keine Probleme während des programmierens?

Ach ja, LPT Schnittstellen mögen tatsächlich manchmal das umstöpseln im laufenden Betrieb nicht - Versuch macht kluch :steirer:
Wenn der Anschluss anderweitig noch gebraucht wird, würde ich Vorsicht walten lassen, oder zumindest nachschauen ob auf dem MB notfalls noch ein Slot für Ersatz frei ist :glgl:
 
Eine Frage noch auf die schnelle: Mir ist irgendwann mal eingebläut worden, man solle bloß keinen Treiber ohne Verbraucher anschließen.
Das bereitet hier keine Probleme während des programmierens?

Hallo Palladin,

beim AMC7135 ist das kein Problem, Zitat Features/Datenblatt: "Output short / open circuit protection"

Das Parallelport-Umstecken würde ich wie gesagt auch nicht unbedingt weiterempfehlen, in der Entwicklungsphase des Programmes, mit einer Anzahl von (Trial&Error-)Programmiervorgängen im dreistelligen Bereich, wäre das allerdings sonst etwas zeitaufwändig gewesen... ;)
 
Also mich würde ein individueller Treiber interessieren der mit einem AA Akku eine P7 Led auf voller Leistung befeuert auch wenn der Akku dann in 10 Minuten leer ist.

Ist so was technisch möglich?

Gruß Manuel
 
Mal schnell gerechnet:
Die P7 hat 3,6V x 2,8A = 10,08W,
den Treiberwirkungsgrad nehmen wir mal optimistisch mit 85% an.
Das macht 10,08W / 0,85 = 11,86W Leistungsaufnahme.
Bei einer Akkuspannung von 1,2V macht das einen Strom von 11,86W / 1,2V = 9,88A.

9,88A wird der Akku (wenn überhaupt) wohl nicht wirklich lange liefern können
(auch wenn man jetzt rechnen könnte 2Ah / 9,88A = 0,2h = 12min. hält der Akku)
 
beim AMC7135 ist das kein Problem, Zitat Features/Datenblatt: "Output short / open circuit protection"

Vielen Dank. Ich hatte mir so etwas auch gedacht.
Bislang haben die Biester bei mir auch jeder Misshandlung erfolgreich standgehalten :)


Das Parallelport-Umstecken würde ich wie gesagt auch nicht unbedingt weiterempfehlen, in der Entwicklungsphase des Programmes, mit einer Anzahl von (Trial&Error-)Programmiervorgängen im dreistelligen Bereich, wäre das allerdings sonst etwas zeitaufwändig gewesen... ;)

Ich kann mir gut vorstellen, was das für ein riesen Akt war....

Solange der LPT Port auch nicht aktiv ist, ist das Risiko auch gering.
Allerdings steckt man halt nie drin, welche blöde Software (AV, Explorer) bzw. welcher Treiber gerade mal meint, just in dem Moment den Port mal abzufragen...
Auf Nummer sicher, oder wer z.B. gar keinen Parallelport mehr hat, wäre man mit einem USB-LPT Adapter, mittlerweile für ganz kleines Geld erhältlich.


Ach ja, und dann wollte ich noch fragen ob es einen Treiber gibt, mit dem ich einen SST-90 Emitter mit einer Knopfzelle betreiben kann.
Zehn Sekunden reichen :steirer:
 
Back