Blutzucker-Messgerät Hardware OLED Display

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

Sowas?

http://www.chumby.com/guide/widget/NIXIE%20Tube%20Clock%20-%20Tubes%20Only

http://www.chumby.com/guide/widget/Another%20Nixie%20Clock


Für das Geld, das ein Compact Pro kostet, bekommt man auch eine Nixie
Röhre auf ebay.
Soo teuer sind die auch wieder nicht.
Auch alte Meßgeräte mit Nixies werden immer wieder billig angeboten.

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

Na toll, jetzt hab ich doch glatt vergessen mich einzuloggen... Naja, 
letzter Beitrag wurde nun als "Gast" gepostet.
Gruss, 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

Das Einstellen folgt sobald ich den Code über alles bereinigt habe.
Gruss, Peter

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.html
http://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

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

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.

na jut, dann bestele ich eins und berichte im 
[Beitrag "Übersicht über preisgünstige elektronische Geräte für reverse-engineering"]

Thomas R. schrieb:
> na jut, dann bestele ich eins und berichte im
> [Beitrag "Übersicht über preisgünstige elektronische Geräte für reverse-engineering"]

gesagt getan,da es nciht 100% hier rein passt siehe

[Beitrag "Re: Übersicht über preisgünstige elektronische Geräte für reverse-engineering"]

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.

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

Nicolas Inden schrieb:
>
> Danke für die Hilfe und sorry, falls ich in der suche etwas übersehen
> habe...
>


guck hier, da haben welche eigene pcb gemacht die den originalen 
steup-up benutzt:

Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"

Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"


oder wie ich auf die faule art einfach alle was nciht benötigt wird 
abgelötet und nur stepup gelassen :

Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"

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

Hier z.b.

http://www.reichelt.de/?ACTION=3;ARTICLE=35025;PROVID=2402

oder

http://www.reichelt.de/?ACTION=3;ARTICLE=35040;PROVID=2402

Moin,

kann ich den ATmega eigentlich so programmieren: Batterien einlegen und 
per ISP Adapter, siehe

http://www.elo-web.de/elo/mikrocontroller-und-programmierung/ping-pong/mega8-isp-programmer

programmieren?

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

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?

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

1

C:\WinAVR-20100110\bin>avrdude -p atmega168 -P com1 -c pong  -U

2

> flash:w:Oled-Dem

3

> o.hex -F -D

4

> 

5

> avrdude: AVR device not responding

6

> avrdude: initialization failed, rc=-1

7

>

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

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

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

Mit der Elo Pong Platte, im Anhang, klappt der Bitbanger. Ich verstehe 
nicht warum es am Blutzuckermesseisen nicht klappt...

> Hast Du ein Oszilloskop?

Leider Nein. Was sollte ich damit messen? Welche Pin?

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

1

programmer

2

  id    = "ponyser";

3

  desc  = "design ponyprog serial, reset=!txd sck=rts mosi=dtr miso=cts";

4

  type  = serbb;

5

  reset = ~3;

6

  sck   = 7;

7

  mosi  = 4;

8

  miso  = 8;

9

;

und er Pong Progger hat das

1

programmer

2

  id    = "pong";

3

  desc  = "design pong serial, reset=!rts sck=txd mosi=dtr miso=cts";

4

  type  = serbb;

5

  reset = ~7;

6

  sck   = 3;

7

  mosi  = 4;

8

  miso  = 8;

9

;

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 :(

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

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

-F sollte man nur benutzen, wenn man wirklich sicher ist zu wissen, was 
man tut.

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.

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

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

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.

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

Wobei ich es langsam nicht mehr blicke. adriano6 schrieb mir mal als ich 
ihn fragte wie er den Programmer anschloss:

1

ja direkt mit den Pads auf der BZM-Leiterplatte verbunden

2

(und zwar mit allen drei baugleichen Programmern, die ich an unterschiedlichen Arbeitsorten einsetze!)

3

--> http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html

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

Vieleicht gebe ich es auf und verkaufe die Displays...

Marco De8msh schrieb:
> Wobei ich es langsam nicht mehr blicke. adriano6 schrieb mir mal als ich
> ihn fragte wie er den Programmer anschloss:
>
>
>

1

> ja direkt mit den Pads auf der BZM-Leiterplatte verbunden

2

> (und zwar mit allen drei baugleichen Programmern, die ich an

3

> unterschiedlichen Arbeitsorten einsetze!)

4

> -->

5

> http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html

6

>

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

Hi,

ich möchte eure Aufmerksamkeit mal auf ein weiteres Projekt lenken(wenn 
das hier so okay ist): 
Beitrag "Re: Zerlegt: Wellion Calla Premium (mit OLED)"

Grüsse aus Berlin
tec

Hallo,

das Gerät hat nur die Serielle des MSP über eine miniUSB Buchse 
rausgeführt.

https://github.com/techniker/OpenWeCalla/blob/master/README.md

Grüsse
tec

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?

hat keiner sonst das Programm ausprobiert?

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

@ B. Heller (tec)

Melde dich bitte mal per PN bei mir, du kannst dir bestimmt denken 
warum.
Auf meine PNs reagierst du ja leider nicht.

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

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

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

hat vielleicht noch jemand eins-zwei von denn Displays die noch 
funktionieren im Tausch mit Nokia Displays. Ich wollte was testen.
Gruß Andreas

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

Moin Andreas,
schade dann sind da offenbar miese Displays verbaut worden. Die Lagerung 
war eigentlich optimal. Dir auch alles Gute für's neue Jahr!