SUPER - DANKE,
werd's die Tage gleich mal testen.
Wünsch euch allen ein schönes Wochenende !
Thorsten Erdmann schrieb:
>> gedenkst du uns an Deiner Library teilhaben zu lassen ?>> Wäre SEHR interessiert.>> Gedenke ich. Hier ist nun die erste Version mit kleinem Demoprogramm.>> http://www.trektech.de/OLEDLibrary/bin/OLED-Demo.zip>> Leider bin ich aber nun auf ein sehr häßliches Problem gestoßen. Mit> allen drei Fonts (klein, groß und riesige Ziffern (antialized)) passt> das ganze nun nicht mehr ins Flash. Was nun? Auf einen der Fonts> verzichten? Irgendwie eine Kompression der Fonts verwenden? Oder die> Fonts im externen EEPROM speichern, was vermutlich gähnend langsam wäre,> oder?>> Leider habe ich es immer noch nicht geschafft eine Doku zu machen, aber> ich denke der Code ist hinreichend kommentiert um damit klar zu kommen.> Übrigens ist irgendwie HARD-SPI kaputt gegangen. Wenn jemand sieht warum> das nicht mehr geht, wäre ich für Hinweise dankbar (dazu in oled.h> HW_SPI auf 1 setzen).>> Vielleicht hat ja jemand eine Idee. Feedback ist erwünscht.>> Gruß> Thorsten
Lupin schrieb:
> Nur den größten der fonts speichern und für andere schriftgrößen runter> skalieren (mit interpolation).
Ich denke mit Skalieren kriegt man keine ansprechenden Fonts hin. Dann
könnte ich ja gleich eine TTF Library nehmen, aber die wird wohl auch
den kleinen Prozessor sprengen.
Gruß
Thorsten
Hallo,
erstmal tausend Dank für Eure wundervolle Arbeit.Auch ich profitiere
davon.Ich habe eine Idee für eine schöne Verwendung der OLED Displays
zusammen mit dem atmega168 Prozessor.In Anlehnung an die allseits so
beliebten und leider auch sehr hoch gehandelten Nixie Uhren, wäre doch
eine Anwendung als ultimative Funkuhr denkbar.Dabei sollte man sich wie
auch bei den Nixie Uhren ncht auf eine Anzeige beschränken, sondern für
jede Stelle der Uhrzeit (eventuell natürlich auch fürŽs Datum) ein extra
Display benutzen.Das hat auch entscheidende Vorteile: jedes Display
braucht nur eine Zahl von 0 bis 9 anzuzeigen, dabei wären je nach noch
verfügbarer Speichergröße natürlich unteschiedliche Darstellungen, z.B.
animierte 7- oder 16- Segment Anzeigen oder auch Punktmatrix Anzeigen
(am besten mit bewegten Zahlen wie im Fahrstuhl) sehr schön.Der
Einfachheit halber sollte der Prozessor für jedes Display gleich
Programmiert werden, man müsste jedem Display dann nur einmal sagen, an
welcher Stelle es steht.Die Uhrzeit wird dann jeweils über den RXD
Eingang vom Prozessor mit dem DCF77 Signal Synchronisiert.Vielleicht
findet sich ja Jemand der das programmieren kann, ich kann das leider
nicht.
Grüße
Mirko
Hallo,
meine Idee soll kein Ersatz für eine Nixie Uhr sein.Eine Nixie Uhr war
nur die Grundlage meiner Idee.Natürlich gibt es günstige Nixie Röhren,
diese sind aber sehr klein.Nixie Röhren in der Größe des OLED Displays
sind neu wirklich nicht billig und bei dem Blutzucker Messgerät ist auch
noch die Ansteuerung mit dabei.Eine komplette 6- Stellige Nixie Uhr mit
neuen großen Röhren kostet locker 150,- bis 200,- Euro.Die komplette
Hardware inklusive Netzteil und DCF77 Antenne für eine 6- Stellige
Funkuhr mit den OLED Displays wird keine 50,- Euro kosten.Das ist doch
ein gutes Argument dafür oder?
Grüße
Mirko
> Das ist doch ein gutes Argument dafür oder?
Nee ist immernoch schwachsinn. Wer des Geldes wegen eine Nixie Uhr faken
will hat nicht verstanden weshalb man Nixie Uhren baut.
Außerdem ist die Displaygröße nen Witz im vergleich zu meinen Burroughs
B7971.
Hallo @all,
Hallo Thorsten,
> Das mit dem static rausnehmen war des Rätsels Lösung, zusammen mit nur> an einer Stelle das Font-File einbinden. In den anderen Dateien statt> dessen eine extern-Deklaration via Headerfile.> Danke für den Tip.> Gruß> Thorsten
Ja damit hab ich auch immer zu kämpfen, das Doubledefining von z.B. font
Daten, die im Header predefiniert sind. Lt. meinem Lehrbuch beschränken
sich Angaben im Header File auf ausschliesslich Deklarationen,
Prototypen und Defines jedoch KEINE Var.Defintionen wobei eine
Fontdefinition ja eigentlich auch eine Speicherreservierung darstellt.
Daher stand ich auch vor der Überlegung, wie kann ich Doubledefines bzw
Compilerfehler vermeiden obwohl ich die fonts mehrfach inkludiere. Des
Rätels Lösung ist in der Tat das einmalige Einbinden des "font.h" in
einem C-Source in dem Pointer Zuweisungen passieren, und das Deklarieren
einer externen Variable in einem anderen C-Header, z.B. in oled.h durch
die Zeile:
1
externconstchar*font;
und die Definition, Speicherallokierung in dem C-Source oled.c:
1
constchar*font;
So funktioniert es!
Thorsten Erdmann's OLED_Demo.zip ist gut dokumentiert, habe es auch
gleich in mein Projekt implementiert bzw. angepasst. Arbeite jedoch
nicht mit einem AVR sondern mit nem ARM7TDMI von NXP (LPC2103 mit
8kRAM/32kFlash). Der hat mit ca. 58MHz ordentlich Dampf umd das
Graphikgezeichne zeitnah hinzukriegen. SPI bediene ich hardwareseitig
mit ca. 2MHz Tclk.
Die Fonts "numbers.h" und "chrbig.h" sehen super aus.
Desweiteren hab ich Gefallen an der Formatierungsmethode gefunden:
Das Komma Null am Ende definiert mit die Screennummer (habe 2 OLEDs) am
Bus hängen. Mit dieser Funktion hat man so ziemlich alles was man[n]
braucht um ein Datenstring formatiert zu platzieren.
Per sprintf (ok, der ist ziemlich perfomant) kann man dem pText Pointer
nen Stringtext überheben und schwupps passiert die Anzeige.
Was mir jedoch noch fehlt sind alphanumerische Zeichen für den
numbers.font.
@Thorsten: Wie funktioniert das mit dem BMP Ausgangsfile? Welchen
(Arial??) Font hast Du für "number.h" verwendet? Könntest Du ein
Beispiel posten, das mittels FontCreator.exe von Dir in ein Sourcefile
konvertiert? Komme damit noch nicht ganz zurecht. Ne kleine Hilfe von
Dir wäre super!
Anbei schon mal die JPGs über die OLED Anzeige mit Thorsten's Font und
nach ARM7 angepasster OLED.lib.
Grüsse, Peter
Hallo,
ich weiß so genau gar nicht mehr welchen Font ich genommen hatte. Ich
glaube es war "Arial Narrow" mit 36pt. Ein bischen mühsam ist es ja
schon ein passendes BMP zu malen. Ich habe das mit Paint gemacht.
Erstmal ein schwarzes Bild gemalt und dann in gelb die gewünschten
Zeichen hintereinandergemalt. Dann habe ich die Zeichen jeweils um ein
Pixel auseinander gezogen um "leere" Pixel als Zwischenräume zu
bekommen. Wenn es nicht in eine Zeile passt kann man auch mehrere Zeilen
machen. Der FontCreator liest dann alle Zeichen von links nach rechts
und von oben nach unten ein, eben so wie man hierzulande liest.
Hat man das Bild fertig konvertiert man es in C-Code wie folgt:
fontcreator -c -min <asciicode> -bits 4 <bmpfile> <fontfile>
<asciicode> ist der kleinste im Font vorkommende ASCII-Code, bei
vollständigen Fonts also meist das Leerzeichen (32), was auch der
Defaultwert ist.
-bits 4 sagt dem Programm, daß man 4 Bit Graustufen haben will. Enthält
das Bild mehr Farben wird entsprechend reduziert. Will man einen reinen
Schwarzweiß-Font haben (wie die beiden kleinen Fonts) gibt man -bits 1
an.
Schöner wäre es natürlich wenn der FontCreator gleich Fontfiles lesen
könnte. Das war mir aber zu kompliziert zu programmieren, ich bin nicht
so gut in Windows-Programmierung.
Übrigens enthalten die kleinen Fonts alle 256 Zeichen. Unter 32 sind ein
paar Grafiksymbole und über 127 kommen alle möglichen Länderspezifika.
Hat man Speicherprobleme kann man einfach den Font Sourcecode um die
unnützen Zeichen reduzieren. Ich arbeite aber auch gerade daran die
Fonts noch etwas komapkter abzuspeichern, komme im Moment nur nicht so
oft dazu, da ich mit meinem AVR-gestütztem Dimmer kämpfe.
Bis denn
Thorsten
Werde es bezeiten Ausprobieren und mir einen Font "zurechtbasteln".
Die 4Bit Graustufen sehen auf dem OLED jedenfalls super bzw.
professioneller aus als ein reines b/w Schema.
Derzeit arbeite ich an der Takt/Eventgenerierung für die Statemachine
bzw. TaskScheduler. Baue den Keller auf bevor ich die GPS Applikation
draufsetze.
Vielen Dank für Deine Hilfe und fürs FontCreator Tool! Tolle Arbeit!
So macht dasjedenfalls viel Laune :-)
Hallo all,
Das Projekt GPS Telemeter nähert sich dem Ende, es fehlt noch eine s=v*t
Methode um auch Tageskilometer berechnen und anzeigen zu können.
Alles in allem wars schon ein ordentliches Stück Arbeit mit der
Adaptierung nach ARM7 bzw. der OLED_LIB.c, dennoch kann sich das
Ergebnis durchaus sehen lassen.
Vielen Dank an Thorsten für die excellente "Vorarbeit" bzw.
Fontgenerierung mit den Graustufen und den Samplecodes aus der
OLED_Demo.c.
Anbei ein paar Snapshots der GUI Applikationen anwählbar durch einen
Taster.
Viele Grüsse, ucPeter
Hallo zusammen,
anbei die Sourcecode Files (*.c und *.h Dateien) fürs Projekt "GPS
Telemeter", lauffähig auf nem ARM7/LPC2103 im Thumb Mode @Headerboard
LPC-H2103:
http://elmicro.com/de/lpchb.htmlhttp://elmicro.com/files/olimex/lpc-h2103.pdf
Den Tripcounter habe ich noch nicht implementiert. Bisher sind nur die
Applikationen "Höhe und Kompass" vorhanden. Aber falls jemand Laune ha,
sehr gerne!
P.S. wie wäre es mal mit nem neuen Thread? Dieser Blutzucker Thread
platzt mittlerweile aus allen Nähten....
Gruss, Peter
Hallo Leute,
ich platzt einfach mal so in euer Forum rein, ohne mich wirklich gut mit
der Materie auszukennen. Doch ich steh vor einem Problem, und ihr seid
eine meiner letzten Hoffnungen:
Ich muss ein Bauteil identifizieren und herausfinden wo man es erwerben
kann.
Ich sitzt hier vor einem auseinder gebauten Blutdruckmessgerät: Firma
"smartLAB" Model "global". Auf der Platine befindet sich eine Buchse mit
sechs Kontakten, in die die Teststreifen eingeführt werden. Unter was
für einem Begriff kann ich diese Buchse ( oder Steckleiste oder
wie-man-es-eben-nennt) finden. Sinn dieser
Stecker/Steckleisten-Vorrichtung ist, glaube ich, folgender: Auf dem
Teststreifen findet "Glucose-Oxidase" statt, wodurch ein Elektronenfluss
entsteht. Mit Hilfe der Vorrichtung wird der Elektronenfluss gemessen.
Ich glaube weniger, dass Du so eine custom-Buchse irgendwo her leicht
bekommst.
Die sind meist Herstellerspezifisch.
Mit freundlichen Gruessen
Bjoern Heller
tinman schrieb:
> M. G. schrieb:>> Das hier wäre auch ein ziemlich interessantes Gerät, kostet aber wohl>>>> leider ca. 50€:>>>> http://www.contourusb.de/>>> Gibt es gerade bei serviceapotheke24 für 19,95€ + Versandkosten.>> http://shop27.permanent.de/plist.asp?pzns=9002532>> schon gekauft und aufgemacht ?
Nein.
Hat jemand so ein Teil?
Würde mich mal interessieren, ob das Gehäuse nur zusammengeklipst oder
aber verklebt ist.
Hat jemand von euch vielleicht ne Ahnung, wo man uncodierte Teststreifen
her bekommt. Bzw. sind wirklich alle Teststreifen von jeglichen Firmen
codiert??
So,
nachdem mir wieder mal mein Drucksensor in die Hände gefallen ist, habe
ich dies gleich mal für eine lange überfällige I2C / IIC
Softwareumsetzung am BZM genutzt. Weitere Erklärungen finden sich im
Quelltext bzw. auf meiner HP.
Hat schon jemand neue Erkenntnisse zum "mobile" ?
Gruß,
a.
Thomas F. schrieb:
>> Hat schon jemand neue Erkenntnisse zum "mobile" ?>
Die motorsteuerung ist ein Silabs C8051F330, die ABG8U sind irgendwelche
mosfets.
Wenn ich den günstig finde gucke mir die sachen genauer an, z.zt. bin
mit dem Bayer Contour zugange.
Thomas R. schrieb:
> ... z.zt. bin mit dem Bayer Contour zugange.
Ich hab mir jetzt auch so ein Contour USB bestellt.
Leider wurde der Thread mit Deinen Infos
Beitrag "Übersicht über preisgünstige elektronische Geräte für reverse-engineering" geschlossen, vielleicht
sollten wir einen eigenen eröffnen? Gäbe ja noch einiges interessantes
herauszufinden:
Ansteuerung von OLED, iNAND, Firmwareupdate per USB...
M. G. schrieb:
> Thomas R. schrieb:>>> ... z.zt. bin mit dem Bayer Contour zugange.>> Ich hab mir jetzt auch so ein Contour USB bestellt.> Leider wurde der Thread mit Deinen Infos> Beitrag "Übersicht über preisgünstige elektronische Geräte für reverse-engineering" geschlossen, vielleicht> sollten wir einen eigenen eröffnen? Gäbe ja noch einiges interessantes> herauszufinden:> Ansteuerung von OLED, iNAND, Firmwareupdate per USB...
Eigentlich ist es auch eine "Blutzucker-Messgerät Hardware mit OLED
Display", und man hat hier schon über andere geräte gepostet.
Dieser thread ist schon eigentlich viel zu lang, ein neues könnte nicht
schaden. Benutze aber bitte nihc das böse wort "re***-en***", das zieht
die s p a m m e r magisch an.
Dann kann man weiter über die Accu Chek und ähnliche
Blutzucker-Messgeräte mit OLED displays berichten.
Ist ja ein echt gelungener und interessanter Beitrag!
Beim durchlesen dieses Threads ist mit allerdings das hohle Gemeckere
von Diabetiker Typ II aufgefallen.
Da fragt man sich was er denn für ein Problem mit der Verwertung von
Geräten hat, welche eh in gewaltigen Massen von der Industrie auf den
Markt geworfen wird und früher oder später eh im Müll landet.
-So auch Blutzucker- Messgeräte.
Aber Stess beiseite, eine andere interessante Quelle für OLED-Displays
sind auch noch ausgediente oder einwenig in die Jahre gekommene
MP3-Player.
Da gibt es oftmals Displays mit "Area-Color", d.h. ein Abschnitt (oder
auch mehrere Abschnitte) des Displays hat (haben)eine andere Farbe.
Ich habe u.a. eines durch Zufall ergattert, welches gleich vier
verschiedene Farbbereiche besitzt.
Interessant sind auch die Flash- Speicher, zu denen sich in fast jedem
Fall ein Datenblatt finden lässt und man somit in der Lage ist auch
diesen für einige interessante Anwendungen zu verwenden.
Man sollte hier aber wirklich mal alles zum Thema OLED- Display
übersichtlicher bündeln und somit besser handhabbar machen, denn dieser
Display-Typ ist durchaus interessant.
Stefan102 schrieb:> welche eh in gewaltigen Massen von der Industrie auf den>> Markt geworfen wird und früher oder später eh im Müll landet
... sollte natürlich korrekterweise lauten: ...welche in gewaltigen
Massen von der Industrie auf den Markt geworfen werden und früher oder
später im Müll landen...
War wohl doch ein wenig zuviel Müdigkeit. ;-)
Aber den Beitrag (Thread) auf jeden Fall weiterentwickeln.
MfG.
102
Hallo zusammen,
zuerst einmal vielen Dank für die bisher gesammelten Erkenntnisse! Durch
diesen Thread angespornt möchte ich dieses Display einmal an meinem
AtMega32 ans Laufen bringen, leider scheitere ich an einer Kleinigkeit:
Wie bekomme ich aus den 5V, die ich zur Verfügung habe die 12V OLED
Spannung? Ich habe einen max232 zur Verfügung, der mir 10V liefern
könnte. Reicht das für das Display?
Danke für die Hilfe und sorry, falls ich in der suche etwas übersehen
habe...
Nico
Wie bekomme ich aus den 5V, die ich zur Verfügung habe die 12V OLED
Spannung? Ich habe einen max232 zur Verfügung, der mir 10V liefern
könnte. Reicht das für das Display?
Ähm, der max232 ist ein Levelshifter für RS232 Pegel.
Die 12V Supply Voltage fürs Display treiben die OLED's.
Nimm einfach nen step-up Wandler wie er auf dem original PCB drauf ist.
Gruss
tec
Ok, schonmal vielen Dank für die Antworten! So einen StepUp Wandler
müsste ich mir dann bauen. Ich hab das Display leider standalone bei
eBay gekauft, hab also leider nicht den Rest vom Gerät.
So eine Ein-komponenten-Lösung wie nen 7805 von 12V -> 5V gibt es in der
anderen Richtung nicht, oder?
Nico
Moin,
ich versuche den ATMega168 zu programmieren.
STK500 (clone) - AVRStudio 4
Fuses und Lockbits und Chip-ID werden wie oben gelesen
Auslesen geht (alles FF wegen der Lockbits)
Beim Programmieren friert der Ablauf sofort ein und der STK500 ist nicht
mehr ansprechbar (bei mehreren Clockrates, ich nehme jetzt 57 kHz).
any ideas?
Der 168 wird mit nur 3,x V betrieben. Ich konnte mir behelfen, indem ich
bei meinem billigen seriellen Programmer über eine Diode und Pull-Up die
High-Pegel des 168 etwas angehoben habe.
Zuvor hatte ich ähnliche Probleme.
Ich vergass, ich habe einen 74LS07 dazwischengeklemmt.
Werd das aber nochmal durchmessen. Aber lesen geht ja.
Kann es sein, dass der Programmer im AVRStudio doch einen Verify
byteweise macht?
Accu-Chek Mobile
Gibt es denn jetzt irgendwo einen neuen Thread oder weitere
Informationen zum neuen Accu-Chek Mobile?
Ich habe zwei, eins davon zerlegt, und komme damit an einigen Stellen
nicht weiter, und das alte CompactPlus ist ja schlecht zu bekommen.
de8msh schrieb:> Geht aber nicht... QFP100 ist rausoperiert.
Die passende Antwort auf Deine detaillierte Fehlerbeschreibung lautet:
Dann stimmt etwas nicht.
Löse das Problem und es wird gehen ;-)
Falk
Hallo nochmal,
das Gerät hat Strom. Es zeigt sich bei Druck auf mittlerer Taste ein
Batteriesymbol. Ich habe o.g. Verbindung zu dem ATmega hergestellt. In
der AVRDude.conf habe ich das hier
Falk Willberg schrieb:> de8msh schrieb:>> Geht aber nicht... QFP100 ist rausoperiert.>> Die passende Antwort auf Deine detaillierte Fehlerbeschreibung lautet:>> Dann stimmt etwas nicht.>> Löse das Problem und es wird gehen ;-)>> Falk
Hi OM Falk,
nun ist es detaillierter :) Was nun weiter?
Marco De8msh schrieb:> nun ist es detaillierter :) Was nun weiter?
Die Fehlermeldung lesen, da siehst Du wo es hängt.
Und dann den Thread durchlesen, da steht die Lösung. Ja, da musste jeder
durch.
de8msh schrieb:> Hallo nochmal,>> das Gerät hat Strom. Es zeigt sich bei Druck auf mittlerer Taste ein> Batteriesymbol. Ich habe o.g. Verbindung zu dem ATmega hergestellt. In> der AVRDude.conf habe ich das hier>>
Da ich Deinen Programmer nicht kenne, kann ich zur Konfiguration nichts
sagen. Aber die erste Fehlermeldung bedeutet, daß gar keine
Kommunikation mit dem AVR möglich ist.
Ich habe sowas immer durch nicht vorhandene Stromversorgung, vertauschte
Leitungen oder invertierte Pegel gehabt.
Mit einem Scope ist das leicht herauszufinden.
Falk
Marco De8msh schrieb:> Also,>> ich habe etwas über 3 V an VCC, und GND mit GND von Spannungsquelle und> Seriellem ISP Adapter verbunden.>> Ich messe nun an PIN SCK ~>4V. ?
Kann schon sein, sagt aber nichts aus.
Da kommen schließlich +/-12V über 100k an. Begrenzt wird die Spannung
nur durch die Substratdioden des AVR.
Funktioniert der Programmieradapter mit anderen AVRs?
Hast Du ein Oszilloskop?
Falk
Hallo nochmal,
ich will ja nicht lockerlassen, da ich das Display einfach zu gut finde.
Habe ja auch das vom Nokia 3310. Aber das ist um Ecken besser. Daher
meine Frage: wenn ich
avrdude -p m168 -P com1 -c ponyser -U flash:w:oled.hex -F
gebe, auch wenn das mit dem angeschlossenen Bitbanger von der Config
nicht genau passt,
Ponyser hat das
und Enter drücke leuchtet ein paar Sekunden die Batterieleuchet auf.
Siehe http://www.youtube.com/watch?v=0vtawlgOeDE
Ist das nun schlecht oder gut? Bei der Einstellung "pong" passiert
nichts :(
Marco De8msh schrieb:> Mit der Elo Pong Platte, im Anhang, klappt der Bitbanger. Ich verstehe> nicht warum es am Blutzuckermesseisen nicht klappt...
Weil die Pegel des Blutzuckermessers zu niedrig für die serielle
Schnittstelle sind. Mit 5V reicht es noch, 3V sind zu wenig. Das Problem
war hier schon mehrmals angesprochen worden.
Du kannst über Pull-Ups und zusätzliche Dioden die Pegel etwas anheben.
Gruß,
Pom
Hmmm... Ich habe mir den Threat mehrmals durchgelesen. Habe auch etwas
zu Dioden gesehen - aber nicht in diesen Zusammenhang gebracht. Dann
scroll ich nochmal nach oben...
Pom schrieb:> Marco De8msh schrieb:>> Mit der Elo Pong Platte, im Anhang, klappt der Bitbanger. Ich verstehe>> nicht warum es am Blutzuckermesseisen nicht klappt...> Weil die Pegel des Blutzuckermessers zu niedrig für die serielle> Schnittstelle sind. Mit 5V reicht es noch, 3V sind zu wenig. Das Problem> war hier schon mehrmals angesprochen worden.>> Du kannst über Pull-Ups und zusätzliche Dioden die Pegel etwas anheben.>> Gruß,> Pom
Soll ich es so tun? Oder wie ist das gedacht?
DE8MSH schrieb:> Soll ich es so tun? Oder wie ist das gedacht?
Ist das Problem noch aktuell?
Egal, hier auf jeden Fall mal die Lösung:
Die Signale, die von RS232 an den Controller gehen sind groß genug und
werden wie schon geschrieben von den Clamp-Dioden begrenzt.
Das Problem ist, dass der Pegel am Ausgang des des Programmers, also
MISO zu klein ist, damit am PC eine Änderung über die serielle
Schnittstelle erkannt wird. Für den MISO-Pin müssen die Pegel etwas
erhöht werden um sicher aus dem Hysteresebereich der RS232 rauszukommen:
1
+5V
2
|
3
| |
4
| | R (Pull-Up)
5
|
6
|
7
PC --O (CTS und RXD)
8
|
9
_
10
V Si-Diode (1N4148 oder ähnlich)
11
-
12
|
13
|
14
MISO
Durch diese Beschaltung kommt der Pegel des Atmel von 0/3,x V am PC um
die Diodenflußspannung erhöht an der RS232 an. Bei mir hat eine Diode
ausgereicht. Den hohen Pegel (hier +5V) hatte ich mir über mehrere
Dioden von den Ausgängen der RS232 gezogen und über einen kleinen
Kondensator gestützt. Dadurch brauchte ich keine zweite Spannung und der
Adapter passte weiterhin in das Steckergehäuse. Pull-Up weiß ich nicht
mehr, irgendwas mit ein paar kOhm wird wohl passen.
Ohne diese Maßnahme hatte ich mir erst einen Atmega kaputtgeflasht. Ich
konnte die Fuses auslesen, aber beim Programmieren der Fuses blieb er
hängen und war danach tot. Die Fuses waren aber O.K. - mit der gleichen
Einstellung (avrdude commandline) und Pegelanhebung konnte ich nachher
zwei Geräte problemlos programmieren.
Gruß,
Bernd
Hallo Bernd,
ja es ist - oder war - noch aktuell. Habe mir einen anderen Banger
gebaut.
Den:
http://www.avrfreaks.net/wiki/index.php/Documentation:Simple_serial_programmer
Leider VOR dem Lesen Deiner Info. Daher habe ich keine Pullup drinnen...
Dann hatte ich auch erst einen kleinen Erfolg: nachdem mit dem
vorherigen Banger >nichts< passierte konnte ich mit dem Neuen wohl
flashen. Dies (o.Ä.) erschien:
Writing | ################################################## | 100%
Danach kam irgendwas mit
Reading | ################################################## | 100% oder
so ähnlich....
und peng - nichts geht mehr. Habe den Vorgang wiederholt. Nada. Scheint
zerflasht zu sein. Irgendwie sah ich noch was mit Fuses. Aber ich habe
zu schnell die Dosbox geschlossen. Daher habe ich über den Vorgang
nichts mehr an Aussagen. Das war's dann wohl erstmal mit dem Gerät. Und
Tschüss...
Marco De8msh schrieb:
...
> Reading | ################################################## | 100% oder> so ähnlich....
Das sieht ja gut aus. (Oder so ähnlich...)
> und peng - nichts geht mehr. Habe den Vorgang wiederholt. Nada.
Was geht nicht mehr? Das Flashen? Gint es eine Fehlermeldung?
> Scheint> zerflasht zu sein. Irgendwie sah ich noch was mit Fuses.
Hast Du die Fuses nun geändert oder nicht?
> Das war's dann wohl erstmal mit dem Gerät. Und> Tschüss...
Wenn Du nur die falsche Taktquelle eingestellt hast, ist noch nichts
verloren: Einen externen Oszillator an den Takteingang und es geht
wieder.
Dafür reichen 10kHz aus einem 555...
Falk
Hallo Falk,
aus dem Gedächtnis heraus sah die Meldung wie oben im "Bluescreen" aus.
Hatte auch dieses "... first mismatch byte at 0x000".
Nun passiert bei erneutem Flashversuch nichts mehr. Es wir auch kein
Batteriesymbol im Display mehr angezeigt.
Vlad Tepesch schrieb:> -F sollte man nur benutzen, wenn man wirklich sicher ist zu wissen, was> man tut.
Da avrdude aber die Signatur dieses Bausteins nicht kennt, kommt man
ohne -F nicht weit. Auf den ganzen Seiten, die sich mit dem Meßgerät
befassen taucht immer wieder -F auf.
Gruß,
Bernd
DE8MSH schrieb:> Hallo Falk,>> aus dem Gedächtnis heraus sah die Meldung wie oben im "Bluescreen" aus.
Kann das ranzige Windows kein Cut&Paste im Terminal? In Screendumps kann
man nicht suchen, nix herauskopieren...
> Hatte auch dieses "... first mismatch byte at 0x000".
Nochmal die Frage: Hattest Du die Fuses programmiert?
Mit "-F" sagst Du avrdude, daß alle Fehler ignoriert werden dürfen.
Damit verschweigt avrdude Dir wunschgemäß, daß es überhaupt nicht mit
dem Target kommunizieren kann.
> Nun passiert bei erneutem Flashversuch nichts mehr. Es wir auch kein> Batteriesymbol im Display mehr angezeigt.
Dann hat also irgendetwas funktioniert.
Falk
Falk Willberg schrieb:> Kann das ranzige Windows kein Cut&Paste im Terminal? In Screendumps kann> man nicht suchen, nix herauskopieren...
Doch, beherrscht es auch. Jedoch nicht per Strg+C / Strg+V, sonder nur
mit der Maus - finde ich auch sehr umständlich.
Mit Cygwin und einem ordentlichen Terminal geht es aber sehr wohl.
Hallo Falk,
der Screenshot ist sinngemäß, da ich, wie oben geschrieben, meine eigene
DOS box bei meinem Fehlversuch zu früh schloss. Und Abby Finreader ist
mir gerade zu teuer :)
Ich habe das etwas abgewandelte Kommando abgefeutert:
"avrdude -c ponyser -P com1 -b 115200 -p m168 -F -U Oled.hex"
Original ist:
"avrdude -c avr910 -P com1 -b 115200 -p m168 -x devcode=0x35 -F -U
Oled.hex"
Wo soll ich hier Fuses angefasst haben?
... und hier nochmal die Meldung, die ich jetzt immer bekommen:
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
Egal ob mit oder ohne -F.
Christian H. schrieb:> -F übergeht ja nur die ID-Prüfung und ggf Fehler bei der> Datenübertragung. Solang keine Verbindung besteht, wie hier, bringt -F> auch nichts.
Genau das ist ja mein Problem derzeit. Ich komme "nicht mehr rein".
Sollte ich mal -i testen?
DE8MSH schrieb:> Christian H. schrieb:>> -F übergeht ja nur die ID-Prüfung und ggf Fehler bei der>> Datenübertragung. Solang keine Verbindung besteht, wie hier, bringt -F>> auch nichts.>> Genau das ist ja mein Problem derzeit. Ich komme "nicht mehr rein".> Sollte ich mal -i testen?
Wird vermutlich nichts helfen.
Es besteht ja noch Hoffnung: Die Fuses wurden nicht verändert, also
sollte der ATmega nach wie vor per internem Oszillator laufen und das
ISP-Interface ansprechbar sein.
Mit der Original-Fiwmare startet der ATmega ja mit der Batteriespannung
und erhöht sich die Spannung dann selbst über den DC/DC-Wandler
(AS1329). Es wäre also denkbar, dass folgendes passiert ist:
Die ursprüngliche FW läuft und hat den DC/DC-Wandler aktiviert, der die
3,3 V zur Verfügung stellt. Das ISP-Interface funktioniert anfänglich
mit 3,3 V. Während des Löschens und Flashens werden die Ausgänge des
ATmega hochohmig und der DC/DC Wandler schaltet sich ab. Nun stehen nur
noch (bestenfalls) 3V zur Verfügung - das könnte für das ISP-Interface
zu wenig sein.
Ergebnis:
Das Flash wurde gelöscht, nach dem Reset ist keine FW mehr im ATmega,
weshalb weitere Flashversuche fehlschlagen und auch das Display bleibt
aus, da das Flash gelöscht ist.
Klingt für mich plausibel.
Vorschlag:
Modifizier' Deinen Programmer, so dass er auch mit 3V klar kommt oder
speise testweise die Hardware extern mit beispielsweise 3,3 V (oder
minimal mehr). Dabei sollte nichts kaputt gehen und Du weist, ob es sich
noch rentiert, hier weiterzumachen.
Gruß,
Bernd
Ok, das Teil ist zerflasht. Ich habe es mit
http://www.ak-modul-bus.de/stat/dds_generator.html an PIN PB6 und PB7
mit 4000kHz versucht. No way. Dinges bleibt tot. Display geht aber noch
- an anderem BZM.
Der Rest starb beim ersten Flashversuch.
schau mal, ob den ATMega überhaupt Strom bekommt bzw. kontrolliere die
beiden Sicherungen auf der Rückseite. Ist mir bei allen drei Meßgeräten
passiert, daß beim ersten flashen die Sicherung durchgebrannte ist.
Viel Glück
pcs
Hi Leute, ich habe mir nun auch so ein BZM besorgt doch habe ebenfalls
Probleme beim Aufspielen der Beispiel Sketch.
Ich erhalte:
sudo avrdude -c usbtiny -b 115200 -p m168 -F -U flash:w:Oled-Demo.hex
-D
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.01s
avrdude: Device signature = 0x1e940b
avrdude: Expected signature for ATMEGA168 is 1E 94 06
avrdude: reading input file "Oled-Demo.hex"
avrdude: input file Oled-Demo.hex auto detected as Intel Hex
avrdude: writing flash (13586 bytes):
Writing | ################################################## | 100%
7.97s
avrdude: 13586 bytes of flash written
avrdude: verifying flash memory against Oled-Demo.hex:
avrdude: load data flash data from input file Oled-Demo.hex:
avrdude: input file Oled-Demo.hex auto detected as Intel Hex
avrdude: input file Oled-Demo.hex contains 13586 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100%
7.11s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0xff
avrdude: verification error; content mismatch
avrdude: safemode: lfuse changed! Was 42, and is now ff
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was d6, and is now ff
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Es erscheint danach auch nichts auf dem Display.
Wenn ich die lfuse schreiben lasse [y] bleibt alles an der Stelle
stehen.
Ich nutzte einen USBtinyISP. Hat jemand eine Idee woran das liegen
könnte?
Beste Grüße
Jan schrieb:> [...]> sudo avrdude -c usbtiny -b 115200 -p m168 -F -U flash:w:Oled-Demo.hex> [snip]> Ich nutzte einen USBtinyISP. Hat jemand eine Idee woran das liegen> könnte?
Hallo Jan,
das Problem ist bekannt. Der ATmega arbeitet anfänglich mit 3,3V über
den internen DC/DC-Wandler. Während der Programmierung wird der Pin, der
den DC/DC-Wandler aktiviert hochohmig und der Wandler schaltet sich ab,
worauf der ATmega nur noch von der Batteriespannung (bestenfalls 3V)
versorgt wird.
Beide Spannungen sind für die Bit-Banging-Adapter an der RS232 und auch
für den USBASP eigentlich zu niedrig.
Da die meisten Versionen von AVRDUDE diese Variante des ATmega168 nicht
kennen muß mit dem Flag "-F" gearbeitet werden. Dieses Flag sagt dem
AVRDUDE nicht nur, die falsche ID zu ignorieren, sondern auch so
ziemlich alles andere was der Chip so von sich gibt. Ich konnte sogar
mal "flashen" während das Target ohne Batterien war.
=> Lösung:
System extern mit etwas höherer Spannung versorgen (3,4 V oder 3,6 V)
gehen vielleicht auch noch oder den Programmer für die niedrigen Pegel
des Zielsystems fit machen.
Da nur der Pegel der MISO-Leitung am Programmer gelesen wird reicht es
aus, den Pegel dieser Leitung anzuheben. Entweder über eine Diode wie
ein paar Beiträge weiter oben skizziert oder über einen simplen
NPN-Transistor, der mit der Basis über einen Vorwiderstand am MISO des
ATmega hängt, mit dem Emitter an GND und mit dem Kollektor über einen
1k-Widerstand am hohen Pegel der Host-Seite. Der Kollektor geht an den
MISO-Eingang des Programmers. Das geht bei den RS232-Bit-Bang-Adaptern
ganz einfach, da man die zusätzliche Invertierung einfach in die
Beschreibungsdatei des Interfaces aufnehmen kann. Für den USBASP ist
noch eine weitere Invertierung nötig, damit die Pegel wieder stimmen
(wenn man die USBASP-Firmware nicht umprogrammieren will.
Damit sollte alles funktionieren.
EDIT:
Ich habe den USBtinyISP mit dem USBASP verwechselt. Der USBtinyISP hat
ja einen 74AHC125 als Eingangsinterface.
Versuch: Klappt es denn, wenn der Jumper für OUTPWR entfernt wird?
Gruß,
Bernd
... Nachtrag:
Auch mit dem 74AHC125 könnte es eng werden, denn der Ausgang liefert bei
3 V VCC bestenfalls 3 V, eher etwas weniger.
Das Eingangsinterface vom ATmega braucht 0,6*VCC, bei 5V also mindestens
3V um High zu erkennen. Das ganze ist also extrem knapp und könnte mal
funktionieren und mal nicht. Wenn über USB 5,2 V reinkommen kann es
schon sein, dass es nicht mehr funktioniert.
Mit dem USBtinyISP würde ich statt der 3V über Batterien einfach mit
einem Labornetzteil mit 3,3V speisen, dann sollte sich alles
programmieren lassen. Alternativ kann man auch den DC/DC-Wandler
aktivieren, indem man den Widerstand zwischen ATmega und DC/DC-Wandler
auf den DC/DC-Wandlerseite während der Programmierung auf die 3V von der
Batterie legt, dann läuft der Wandler einfach weiter und macht sich so
die nötigen 3,3 V. Der Widerstand wird im Wiki beschrieben.
Gruß,
Bernd
den usbasp kan nman auch ganz einfach davon überzeugen, mitzumachen.
Ist zwar ein bisschen quich and dirty, aber es geht:
Einfach 2 Dioden in die Versorgung des Atmegas packen, am besten per
Jumper zuschaltbar.
an den Dioden fallen jeweils 0.7V, also ingesamt 1.4V ab.
Da der Mega jetzt mit 3.6V versorgt wird, erkennt er auch die 3.3V
Logikpegel zuverlässig.
man sollte dann nur darauf verzichten, externe Schaltungen mit dem
USBASP zu versorgen.
Hi, ich nochmal,
eine Frage hab ich doch noch:
Kann mir jemand erklären wie ich aus dem Beispiel C file das hex File
erzeugen kann?
Ich hab schon verschieden Makefiles im Internet angesehen, allerdings
komm ich damit leider nicht zu Ziel. Kann mir jemand ein solches
Makefile posten?
Vielen Dank und ja, ich hab noch nie zuvor einen Atmega geflasht.
Gruß Jan
Hallo Leute,
bevor ich jetzt ein zweites Gerät zerflashe... Ich habe einen anderen
ISP Programmer am Start. Nun sieht das ganz so aus:
C:\Temp\isp>avrdude.exe -c avr910 -P com3 -b 115200 -p m168 -x
devcode=0x35 -F -U oled.hex
Found programmer: Id = "AVR ISP"; type = S
Software Version = 3.9; Hardware Version = 1.2
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize = 64 bytes.
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.03s
avrdude.exe: Device signature = 0x1e940b
avrdude.exe: Expected signature for ATMEGA168 is 1E 94 06
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will
be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "oled.hex"
avrdude.exe: input file oled.hex auto detected as Intel Hex
avrdude.exe: writing flash (13586 bytes):
Writing | ################################################## | 100%
33.46s
avrdude.exe: 13586 bytes of flash written
avrdude.exe: verifying flash memory against oled.hex:
avrdude.exe: load data flash data from input file oled.hex:
avrdude.exe: input file oled.hex auto detected as Intel Hex
avrdude.exe: input file oled.hex contains 13586 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100%
7.06s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude.exe: verification error; content mismatch
avrdude.exe: safemode: lfuse changed! Was 42, and is now 0
Would you like this fuse to be changed back? [y/n]
Wenn ich nun y gebe blingt der Programmer als wenn er Code übertragen
würde.... Nichts weiter.... Ist Y oder N richtig?
Marco De8msh schrieb:> Hallo Leute,>> bevor ich jetzt ein zweites Gerät zerflashe... Ich habe einen anderen> ISP Programmer am Start. Nun sieht das ganz so aus:>> [...]>> avrdude.exe: verifying ...> avrdude.exe: verification error, first mismatch at byte 0x0000> 0x0c != 0x00> avrdude.exe: verification error; content mismatch>> avrdude.exe: safemode: lfuse changed! Was 42, and is now 0> Would you like this fuse to be changed back? [y/n]>>> Wenn ich nun y gebe blingt der Programmer als wenn er Code übertragen> würde.... Nichts weiter.... Ist Y oder N richtig?
N ist richtig. Auch dieser ISP funktioniert nicht.
Was passiert ist folgendes:
Der Programmer prüft die Fuses nach dem Programmieren und merkt, dass
die lfuse früher 0x42 war und jetzt als 0 gelesen wird. Der Grund ist
klar: Durch das Programmieren wird der DC/DC-Wandler abgeschaltet und
die Pegel werden zu klein.
Wenn Du nun "Y" drückst, dann versucht der Programmer, der schon die
FUSE nicht lesen konnte, diese auch noch zu schreiben. Bestenfalls
geht's komplett schief und es wird nichts geschrieben. Wenn Du Pech
hast, kommt irgendetwas an und der ATmega ist wieder "verfust".
Gruß,
Bernd
Hi Bernd,
aber was mache ich falsch? Ich habe Minuten vorher einen ATtiny85
geflasht. Alles ist ok damit. Nur das BZM zickt herum. Wie mache ich es
korrekt, damit ich sauber flashen kann? Also am Ende N geben? Oder
bringt das schon nichts mehr weil Dude schon
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude.exe: verification error; content mismatch
vermeldete?
Marco De8msh schrieb:> Hi Bernd,>> aber was mache ich falsch? Ich habe Minuten vorher einen ATtiny85> geflasht. Alles ist ok damit. Nur das BZM zickt herum. Wie mache ich es> korrekt, damit ich sauber flashen kann?
Das Problem ist nicht, dass der ISP "kaputt" ist - er ist ohne weitere
Maßnahmen einfach nicht für die niedrigen Pegel des BZM geeignet.
Versorge den ATtiny85 doch mal mit 2,x V und probiere, ob er sich immer
noch programmieren lässt.
Steht aber alles hier und in den Folgebeiträgen:
Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"
Gruß,
Bernd
Marco De8msh schrieb:> Also am Ende N geben? Oder> bringt das schon nichts mehr weil Dude schon>> avrdude.exe: verifying ...> avrdude.exe: verification error, first mismatch at byte 0x0000> 0x0c != 0x00> avrdude.exe: verification error; content mismatch>> vermeldete?
Bringt schon nichts mehr. Solange Du die Fuses nicht änderst und avrdude
nicht erlaubst, die Fuses zu "korrigieren" geht aber auch nichts kaputt.
Gruß,
Bernd
>> Ich habe den> http://www.my-irshop.de/catalog/product_info.php?cPath=28&products_id=158> und der müsste kompatibel sein - müsste...
Die erwähnten Programmer sind bezüglich der Pegel komplett
unterschiedlich. Deiner wird mit den 5V vom USB gespeist und erwartet
damit höhere Pegel als das BZM liefern kann. adriano6 verwendet einen
Programmer, der vom Target gespeist wird und damit perfekt zu den Pegeln
vom Target passt.
Das Problem ist nicht, dass Dein Programmer nicht kompatibel zu diesem
ATmega im BZM wäre - das ist er ganz bestimmt nicht, das Problem ist,
dass Dein Programmer nicht in der Lage ist, mit den niedrigen Pegeln des
batteriegespeisten BZM umzugehen.
Damit ein ATmega logisch "1" erkennt, muß die Spannung am Pin mindestens
ca. 60 % der Betriebsspannung sein. Wenn der ATmega in Deinem Programmer
mit den 5V vom USB gespeist wird, dann braucht er mindestens 0,6 * 5 V =
3V. Alles was kleiner als 3 V ist, wird vom Programmer als logische "0"
gewertet. Wenn das BZM nur mit zwei Batterien gespeist wird, die nur
nagelneu auf (knapp) über 3V kommen, dann kann das nicht funktionieren -
zumindest nicht zuverlässig.
Vlad Tepesch (vlad_tepesch) hat hier skizziert, wie man einen
USB-Programmer an die niedrigen Pegel anpassen kann:
Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"
Über die beiden Dioden fällt Spannung ab und der ATmega des Programmers
läuft (ungefähr) mit der Spannung, die auch das Target hat.
Alternativ eben wie gesagt:
Target mit 3,4 V versorgen sollte auch gehen.
Gruß,
Bernd
Ich habe es aufgegeben die Originalplatte zu flashen. jkw und ich haben
das ganze auf den Arduino herübergetragen und es rennt dort auf
ATmega328 und ATmega1280.
Hier auf ATmega328:
http://www.youtube.com/watch?v=qXA25QDRXJI
Danke an Alle, die mir geholfen haben auch wenn ich zu bräsig bin das
auf der Orgplatte zu flashen.
Q9 schrieb:> Sieht so aus, als wär der Schaltregler AS1329 (Nähe + Pad) für die 3.3 V> Versorgung der Schaltung zuständig. Mhh. Am ISP messe ich aber nur 2.2> V.
Liebe Gemeinde,
ich konnte glücklicherweise auch noch ein paar dieser tollen Fundgruben
erwerben...
Den Fehler von Q9 hatte ich auch. Wie sich herausstellte, war eine der
Sicherungen durchgebrannt (SI2, siehe Wiki zum BZM
http://www.mikrocontroller.net/wikifiles/5/54/AccuCheckL6.jpg)
Nun, da ich die 3,3V habe, muss ich feststellen, dass die immer
anliegen, auch wenn das Gerät im Ruhezustand ist. Ich habe festgestellt,
dass bei ausgelötetem "IC1" der Steuerausgang PD7 des ATmega im
Schlafzustand verständlicherweise floatet und damit der StepUp nicht
sauber abgeschaltet wird. Mit einem 200k Widerstand gegen Masse lässt
sich das beheben.
Hat jemand eine elegantere Methode gefunden?
Hier eine Frage von mir:
Leider liegen die 3,3V, oder wenigstens die Batteriespannung mit ca. 3V
permanent an. Hat jemand einen Punkt gefunden, an dem ich die
Betriebsspannung nur bei eingeschaltetem Gerät abnehmen kann? Sonst sind
die Batterien so schnell leer, durch meine zusätzlichen Schaltungen...
Grüße,
Pijey
Momentan für 9€ bei mycare.de
Wie funktioniert denn die USB Schnittstelle?
Der MSP430 hat laut Datenblatt kein USB, und ich kann auf den Fotos der
Platine keinen separaten USB controller sehen.
Hallo,
ich ich habe die Firmware von diesem Beitrag
Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"
aufgespielt. Leider empfängt das Display keine Zeichen, wenn man es mit
einem Mikrocontroller verbindet. Masse kann man ja einfach die
verwenden, die bei der ISP rausgeführt ist, oder?
Wo könnte denn da der Fehler sein? Was könnte man falsch gemacht haben?
So sieht das Display aus. Es ist auch kein klares Bild bzw Schwarz,
sondern es sind Linien erkennbar.
Wenn man jetzt etwas über die serielle Schnittstelle schickte, müsste
das dann ja hier auftauchen, oder?
Hallo,
mittlerweile läuft es, allerdings funktioniert das mit UART nicht. Wie
lässt sich denn das machen, damit der Controller richtig senden kann?
Funktioniert das ohne einen externen Quarz? Bzw adriano hat es ja
offenbar ohne geschafft.
Ich habe die Baudrate schon auf 300 gesetzt, aber es kommen nur
Hieroglyphen
Hallo,
Ich wollte gern der DCF 77 uhr bauen, aber Ich bin anfänger mit Atmega
programming.
Welche Software und Programmer soll Ich benütze für Program die Atmega
168 ?
Mit freundliche Grüben aus Schweden
Sven L.
Hallo !
Jetzt Ist die DCF77 projekte fertig ! Ich benützte AVR Studio 4 als
Software und STK 500 ISP programmer.
DCF 77 modul aus Pollin mit eine 4093 als wellenformung und eine
7400
als Invertien die Signale zu Atmega 168.
Haben irgendjemand eine Idee wie man kan die Piezo Buzzer stuere so es
klingt einmal sekunde bei DCF 77 empfang ?
Mit Freundliche Grüben
Sven L
PS: Entschuldigung für meinem kleine Deutsch DS
So, ich habe die Displays nach ... 10 Jahren mal herausgekramt, weil ich
eines davon gut gebrauchen könnte... aber die scheinen tot zu sein: mit
3V ist gerade so etwas auf dem Display zu erkennen.
Die Gummierung vom Gehäuse ist auch schon ergraut...
Läuft es bei euch noch?
Hallo Q9,
habe mehrere der Messgeräte vor ca. 9 Jahren gekauft. Eines der
Displays wurde in eine Anzeige eingebaut, welche jede Woche ca.
eine Stunde in Betrieb war. Nach fünf Jahren war das Display nicht
mehr lesbar und wurde durch ein neues ersetzt welches gleich alt war,
jedoch noch nicht benutzt wurde.
Die anderen scheinen auch noch zu funktionieren.
Gruß
Frank
Danke - vielleicht hat irgendwas aus der "Gummierung" des Gehäuses die
LEDs erledigt. Oder ich habe damals eine schlechtere Charge abbekommen
(5 Stück).
Ich habe sie zusammen in einem Karton bei Raumtemperatur aufbewahrt.
Schade.
beim Aufräumen/Ausmisten dieser Woche habe ich meine zwei Displays auch
wieder gefunden und gleich mal Angeschlossen. Beide OLED Anzeigen sind
auch sehr dunkel :-( obwohl kaum benutzt.
Hat da jemand eine Erklärung sind ja Organische Displays lieg es an dem.
Ist jetzt wohl nicht Schlimm aber nachhaltig ist es natürlich nicht ...
Hallo Andreas,
habe noch zwei Geräte eingelagert (unbeheizter Dachboden) beide 2009
gekauft. Das eine Display sieht noch gut aus. Das andere ist wesentlich
dunkler, obwohl es etwas neuer ist. Vermutlich gibt es
Produktionsschwankungen. Die OLED Technik war damals ja noch relativ
neu. Zehn Jahre sind für ein "wegwerf" Messgerät ein guter wert. Zur
Lebensdauer beim Lagern habe ich nichts gefunden.
Habe bisher ein Projekt seit 2009 mit dem Display am laufen, wenn das
letzte aufgebraucht ist, werd ich wohl auf Nokia LCD umrüsten ;-)
Frank
Andreas B. schrieb:> hat vielleicht noch jemand eins-zwei von denn Displays die noch> funktionieren im Tausch mit Nokia Displays. Ich wollte was testen.> Gruß Andreas
Ich habe noch einige 'rumliegen. Kann ich dir zuschicken. Testen musst
du aber selber.
Einhart P. schrieb:> Andreas B. schrieb:>> hat vielleicht noch jemand eins-zwei von denn Displays die noch>> funktionieren im Tausch mit Nokia Displays. Ich wollte was testen.>> Gruß Andreas>> Ich habe noch einige 'rumliegen. Kann ich dir zuschicken. Testen musst> du aber selber.
danke habe dir mal angeschrieben ...
Gruß Andreas
Einhart P. schrieb:> Andreas B. schrieb:>> hat vielleicht noch jemand eins-zwei von denn Displays die noch>> funktionieren im Tausch mit Nokia Displays. Ich wollte was testen.>> Gruß Andreas>> Ich habe noch einige 'rumliegen. Kann ich dir zuschicken. Testen musst> du aber selber.
Hallo Einhart,
erst mal vielen vielen Dank für dein Päckchen :-) hatte gestern alles
noch Zerlegt und die Displays getestet "die sind alle TOD :-(" und
werden jetzt Entsorgt. Sende dir die nächsten Tage auch was zu
vielleicht kannst du es gebrauchen ...
Noch ein gutes neues Jahr 2021 und danke nochmal
Gruß Andreas