Blutzucker-Messgerät Hardware OLED Display

guck nochmal was du geschrieben hast und was auf dem bild ist, dann 
wirst du meine frage auch verstehen.


@Tom,

falsch, da steht was anderes drauf.

Da ich derzeit höher priorisierte Tasks abarbeite ;-) , komme ich nicht 
dazu die Aufräumarbeiten an dem GPS-Demoprog endgültig abzuschließen...

Vielleicht hat ja jemand Interesse mal drüber zu schauen und nach 
Optimierung bzw. Korrektur die Quellen eventuell auf die Artikelseite zu 
stellen?

Konstruktive Kritik eventuell gleich hier rein oder per PN - man lernt 
schließlich immer gern dazu... :-)

Gruß,
a.

Ich habe bei meinem 2ten Gerät alle Bauteile drauf gelassen.
Der Code von Adrian funktioniert einwandfrei nachdem ich die Fuses des 
168P korrigiert hatte, er war irgendwie zu langsam^^
So, nun habe ich die Wahl, mich in C einarbeiten, oder Adrians Code in 
Bascom umsetzen.....

Anselm

p.S.: Motoren usw. rausnehmen, dann hat man ne Menge Platz.

@Robert

das ist mir auch schon passiert. mir sind beim programmieren die 
sicherungen auf der rückseite durchgebrannt. Ich arbeite mit einem 
USBASP mit einem Quarzoszillator. dessen Taktausgang hab ich mit PB6 
(XTAL1) verbunden. voila Fuses neu gesetzt und das Teil lief wieder.

@Anselm

Stett in Adrians Demo Source drin, das CKDIV8 geändert gehört, da der 
atmega sonst mit 1 MHZ läuft

Ja, hab deinen Thread im bascom-forum gestern abend noch gefunden.
Wenn du ProfessorHase bist ^^

Gruß Anselm

100mA wären 1,2W - dass kann ich mir nicht vorstellen ;)
Ich werd mal am Montag messen, vielleicht kommt mir aber jemand zuvor.

Gruß Anselm

Hi!

An alle Streifengeplagten:
PB0 schaltet über Transistor T1 die Masse für das OLED! Wer da keinen 
dauerhaften High-Pegel anlegt bekommt Streifen!

Gruß
Robert

Mein Gerät hat im Originalzustand Streifen, ist das bei euch auch so?

Ich hatte noch keine Zeit das teil außeinanderzunehmen, kommt nach dem 
Urlaub und nach dem Umzug dran ;)

Das kann auftreten, wenn die Spannung zu stark abfällt, oder der DC-DC 
Wandler zu stark schwingt.

Hallo,

ich würde das Display gern als Eingabeeinheit nutzen und dazu eine 
Tochscreen-Folie aufbringen. Das Problem ist: wo finde ich eine kleine 
einigermaßen passende Folie?

Bei Dealsextreme gibt es diverse davon für'n Appel und 'n Ei - aber 
meines Erachtens alle zu groß. Hat jemand eine Idee wo es etwas 
passendes geben könnte?

Danke für zahlreiche Tipps ;-)

Einhart

Das wird m.E. zu aufwändig und das Flackern wird wegen der seriellen 
Ansteuerung des Displays zu langsam und damit sichtbar.

Die für ein Touchpanel notwendige Hardware ist minimal. Die Touchfolie 
für die NDS lite kostet z.B. um die 2€. Ich habe die bestellt - 
vielleicht bekommt man das mechanisch irgendwie hin.

AVR-DRagon sagte mir 3V SPI, aber ich habs nicht gemessen.
Gerät liegt auufer Arbeit, kann grad nicht..

Jetzt hab' ich auch nachgemessen: 3,2V bei 2,9V Batterie.

Dann hast du beim Abmontieren des ASIC irgend einen Kollateralschaden 
verursacht. Bei mir ist der auch weg.

Q9 schrieb:
> Wieder ne Frage:
> Ich versuche gerade, den USART im SPI Modus zu benutzen:
>
> Init:
>   UBRR0 = 0;
>   XCK_DDR |= (1<<XCK);
>   UCSR0C = (1<<UMSEL01)|(1<<UMSEL00)|(1<<UCPHA0)|(1<<UCPOL0);
>   UCSR0B = (1<<TXEN0);
>   UBRR0 = 2;
>
> Write:
>   while ( !( UCSR0A & (1<<UDRE0)) );
>   UDR0 = dat_or_cmd;
>
>
> Leider tut sich am Display nichts. Hat jemand von Euch damit schon
> Erfolg gehabt?

Hab gerade mal ins Datenblatt geschaut:
Der "initial value" für UDRE0 ist 0, evtl. bleibt Dein Programm dann in 
der while-Schleife hängen.
Probier mal, erst auf UDR0 zu schreiben und dann die while-Schleife.

Er schaltet die 12V über einen 100 Ohm Widerstand gegen Masse. Der Grund 
erschließt sich mir aber auch nicht auf Anhieb. Vieleicht eine Art PWM.

Das könnte zum Abschalten benutzt werden. Laut Datenblatt muss Vcc (12V) 
vor Vdd auf 0 sein. Wahrscheinlich kann das damit sichergestellt werden.

@Q9: zu PB0 habe ich mittlerweile auch die Vermutung wie Einhart...

„And now for something completely different“ ;-)

Inspiriert von Mockup's 7-Segment-Anzeige habe ich mal einen 
Kurzzeitwecker entworfen. Den auf dem Board vorhandenen Buzzer habe ich 
auf Masse und  - in Ermangelung eines greifbaren Widerstandes - direkt 
mit PB2 verbunden (gut zu erreichen an R17 neben dem 32kHz Quarz). Bei 
Interesse folgt demnächst der Quellcode...

Gruß,
a.

Q9 schrieb:
> 5 ms gehen auch.
> Die Row- und Colum-Address-Setzerei aus der Initialisierung kann man
> doch eigentlich weglassen, oder?

möglicherweise - habe ich noch nicht getestet, aber die Rechteckfunktion 
hatte ich schon mal im GPS-Demo drin ;-) - die 5ms werd ich auch mal 
ausprobieren.

@Thomas F. (adriano6)
Ich weiß ja nicht ob du auch meine Funktion nutzt, ich habe die aber 
noch einmal schmaler gemacht, damit gefällt mir das besser.

Ein weiteres Problem mit verschobenen Buchstaben gab es in der alten 
Version. Da stand statt "backslash" "\" in der Headerdatei. Der Compiler 
hat das als Zeilenumbruch interpretiert. Somit fehlte genau ein 
Buchstabe, und alle Großbuchstaben waren um eins verschoben. Nur zur 
Info.

Ich habe mal etwas mit dem 'Graphic Accelerator' rumgespielt:

http://vimeo.com/6609124

Der ATmega dreht zu 80% Däumchen, ein Großteil der 20% gehen für das 
softSPI drauf.

Leider ist die Qualität von dem Video nicht so prall, das Drehen der 
Bälle kommt nicht so richtig rüber.

Der Code ist schnell zusammengehackt, das müsste ich erst mal lesbar 
machen. Aber eigentlich ist es auch nicht kompliziert.

Die Linien im Hintergrund sind einfach Rechtecke mit Breite 1.
Für die Sprites habe ich die Copy-Funktion benutzt.
Der sichtbare Bereich des Displays beginnt erst bei Spalte 7. Die 
Spritedaten und Puffer für den Spritehintergrund liegen im unsichtbaren 
Bereich des Display-RAM und werden jeweils hin- und herkopiert. Dazu 
definiert man den Display-Ausschnitt über das gesamte RAM und schaltet 
wrap-around ein. Die (2 Pixel breiten) Spalten 0-6 liegen dann aus Sicht 
des Copy-Befehls auf 64-70, der gesamte unsichtbare Bereich geht von 
58-70.
Die Spritedaten werden zuerst als Block in den sichtbaren Bereich 
geschrieben und dann wegkopiert. Beim direkten Schreiben in den 
unsichtbaren Bereich hat es mir immer die Daten teilweise zerschossen. 
Per Copy klappt das aber problemlos.
Damit die horizontale Bewegung halbwegs fliessend aussieht, gibt es für 
jedes Sprite zwei um jeweils ein Pixel verschobene Versionen. Bei den 
Rechtecken passiert das gleiche über das Grayscale-Pattern.
Setzen und Löschen eines Sprite besteht also nur aus drei Copy-Befehlen:
Hintergrund in einen Puffer, gemäß der x-Koordinate das passende 
Spritepattern in den sichtbaren Bereich und zum Löschen den Puffer 
wieder zurück.

> Übrigens: Das Via kommt genau neben dem Pad vom Buzzer raus. Eine
> Zinnbrücke reicht..
@Q9: dass macht die Verbindung natürlich noch einfacher

> Ich weiß ja nicht ob du auch meine Funktion nutzt
@mockup: ja, deine Funktion hätte ich lieber nehmen sollen, um Zeit zu 
sparen (ich hatte mir unbedingt eine 1 Pixelspaltbreite eingebildet...)

> 1. Wo kommen die Daten für die Initialisierung...
@Q9: natürlich nur aus dem Datenblatt... ;-))

> Benutzt du eigentlich den Lastwiderstand zum Ein/Ausschalten?
@Peter: derzeit noch nicht - nutzt den jemand?

@christian-g: interessantes Video: etwas Code würde sicher Zeit sparen!

> Hier noch ein OLED-Projekt: http://www.gaudi.ch/CMS/index.php
> Für Timer-Funktionen sollte man wohl den Quarz noch an den AVR fummeln
> (PB6, PB7 - wo geh'n die Vias hin?), sonst ist kein Verlaß drauf..
@Q9: wenns genauer sein soll kommt man nicht umhin - den Link habe ich 
mit aufgenommen

zum Kurzzeitwecker:
ein paar Fehler (aber noch nicht alle :-)) habe ich in V0.3 gefixt...
Hardware-SPI muss ich auch mal testen...

Gruß,
a.

abo

@Q9
Die Reihenfolge beim Ausschalten müsste m.E. so sein:

void
SSD1325_PowerOff(void)
{
    SSD1325_WriteCmd(0xAE);         // display OFF
    SSD1325_VCC_OFF;                // 12 V OFF
    SSD1325_VCC_LOAD_ON;            // 100 Ohm to GND
    _delay_ms(200);                 // Wait until panel discharges 
completely
    SSD1325_VCC_LOAD_OFF;           // 100 Ohm to GND
}

Gruß
Einhart

Ist es eventuell nur Dein Messgerät, welches mit seiner Messung nicht 
tiefer kommt?

zwieblum schrieb:
> Nö, Messgerät ist Agilent 1242A, das kann uA.

naja, mein china no name kann es auch, sogar zimlich genau, daran wirds 
also nicht liegen.

> Ich werd' mal morgen ein
> anderes Gerät zerlegen und dort messen, vielleicht hab' ich beim
> Ausbauen vom dem fetten Atmel irgendwas kaputt gemacht.

Oder vllt etwas nciht ausgebaut ? Da gibts doch schöne motor treiber ics 
usw.

Ist das Display noch am Gerät dran? Wie hoch ist der Strom, wenn du das 
Display abnimmst?
Was passiert wenn du im Power Reduction Register alle Peripherie einzeln 
abschaltest (PRR=255).

Hi,
wurde nun eigentlich der Temperatursensor schon ausfündig gemacht? Das 
Gerät soll einen ja warnen, wenn die Temperatur unter +6°C oder über 
+40°C liegt. Dazu benötigen das Gerät doch einen Temperatursensor...

Der mega328P hat nen Temperatursensor...

Zu schade aber auch...

Simon K. schrieb:
> Der mega328P hat nen Temperatursensor...
Welcher 328P? Gibt's auch Geräte mit 328P? Ich kenne bisher nur den 
168PV.

Gruß,
Bernd

Der Temp. Sensor befindet sich ganz am Ende des Anhängsels der Platine 
(da wo der Anschluss zum Sensor ist).

B. Heller schrieb:
> Der Temp. Sensor befindet sich ganz am Ende des Anhängsels der Platine
> (da wo der Anschluss zum Sensor ist).

Ist es R35 von hier?
http://www.mikrocontroller.net/wikifiles/7/77/AccuCheckL1.jpg

*Zustimm ;)

Ich habe die Info (R35 = Temperaturfühler) in die Wiki-Bauteileliste 
übernommen.

Ist genaueres bekannt? NTC/PTC/PT100/PT1000/... ?

> Ist genaueres bekannt? NTC/PTC/PT100/PT1000/... ?
Gemessen im eingelöteten Zustand:
Raumtemperatur 9,5 kOhm; fällt beim Anhauchen auf ~ 8 kOhm
-> Vermutung: NTC mit 10 kOhm bei 20°C

Das Signal geht weiter zu R23 (rechte Lötstelle) und liegt dann an IC1 
an.

So also den Temperaturfühler hätten wir entlarvt. Schade nur, dass man 
zum Benutzen einen AD-Wandler braucht.

Als nächtes lockt mich der IC8 von der Wiki-Seite. Der ist ja mit all 
den  Motoren verbunden. Ist das sowas wie eine PWM-Controller? Gibt es 
dazu schon näheres?

Bei mir steht folgendes drauf:
ZMD G1
C1319900
1216 0840
02720SG

ZMD ist wohl der Hersteller, zumindest gibt es einen 
Halbleiterhersteller mit dem Namen "ZMD"...

Wenn noch jemand die Beschriftung seines IC8 ablesen könnte, würden wir 
zumindest wissen weclher Bestandteil der Beschriftung nicht zur Serie 
gehört.

http://www.zmd.de

Bernd O. schrieb:
> Simon K. schrieb:
>> Der mega328P hat nen Temperatursensor...
> Welcher 328P? Gibt's auch Geräte mit 328P? Ich kenne bisher nur den
> 168PV.
Ups :-)

Für die, die es interessiert. Ich habe die Grafikdemo nochmal 
überarbeitet und den Code auch etwas lesbarer gemacht (s. ZIPfile). Ein 
paar Zeilen im Wiki-Artikel kommen dann auch noch.
Die Version mit dem softSPI konnte ich nach dem Umbau auf Hardware-SPI 
nicht mehr testen, sollte aber funktionieren. Nach ca. 30s schläft der 
ATmega ein, ein Druck auf die mittlere Taste läßt ihn wieder aufwachen.

resU schrieb:
> Der IC8 der grad vor mir liegt hat als Aufdruck
>
> ZMD G1
> C1376200
> 1216 0842
> U2720SG
Dito

Aber jetzt kommts:

BIG 01
A802MKK

Also mal eine komplett andere Beschriftung.

Moin,

den Piezo habe ich zwischen zwei Portpins gehängt. Ds bringt schon eine 
ganz gute Lautstärke.

Ich träume immer noch vom Touchscreen auf dem Board. Die billigen Panels 
für die NDS-Lite reichen aber für zwei Displays ;-( - sprich viel zu 
groß.

Gruß
Einhart

Könntest du den Schaltplan noch als PDF posten? Mein Eagle meckert, dass 
es zu alt sei, um das schematic zu öffnen...

@Q9:
>Die von adriano ermittelten Werte sind also nur experimentell bestimmt,
da hast du meine Smileys wohl übersehen!?

@christian-g: danke für die interessanten Sourcen des Grafikdemos!

Anbei die aktuellen Sourcen + Hexfile zum Kurzeitwecker (mit 
Einsparpotential, da noch einiges an Redundanz enthalten...
vielleicht sollte ich doch mockup´s 7-Segment-Routine nutzen...)

Ich habe versucht einige aktuelle Infos aus dem Thread einzuarbeiten 
(Hardware SPI, Power ON/OFF Sequence) und einige Fehler "optimiert"! 
;-))

Gruß,
a.

Fossy schrieb:
> Hat jemand schon einmal versucht das Display in der Weise zu betreiben,
> wie es vom Geräte-Hersteller verwendet wird, also um 90 Grad im
> Uhrzeigersinn gedreht?
>
> Ich habe mit den Set-Remap Einstellungen des Displays experimentiert,
> bin aber zu keinem akzeptablen Ergebnis gekommen.

Also ich wuerde einfach die Funktion PaintChar(...) anpassen.
(siehe Anhang!)

Gruß,
a.

Ich habe mich gefragt, wie ich den Stromverbrauch des Gerätes senken 
kann, ich will damit eine Uhr bauen.
Wodurch entsteht denn eigentlich bei so einem OLED-Display der 
Stromverbrauch? Nimmt der Verbrauch ab, wenn man dunklere Farben, zur 
Darstellung, verwendet?

Ja so dachte ich mir das auch. Kann nur hier nicht so einfach den Strom 
messen, sonst hätte ich es schnell ausprobiert.

Danke!

Also das ist ja ein AS1329B und im Datasheet steht: "Delivers 160mA @ 
3.3V (from Single AA Cell)" und "Delivers 570mA @ 3.3V (from Two AA 
Cells)"

such mal auf deinem receiver, vielleicht findeste da noch ein stepdown, 
den du umgehen kannst.

Hat von euch mal jemand den Strom gemessen, den der Kurzzeitwecker 
verbraucht? Ich habe hier eine kleine Platine gemacht, für einen 
Kurzzeitwecker und wollte das nun auch als Uhr und Thermometer benutzen. 
Aber der Verbrauch ist zu hoch. Der Mikrocontroller alleine mit den 
Spannungswandlern benötigt bei mir 5mA. Sobald das Display zusätzlich 
dran ist, braucht die Schaltung 15mA. Für den Batteriebetrieb einer Uhr 
ist das etwas viel.

Ich frage mich nun ob ihr auch solche Werte habt, oder ob an meiner 
Schaltung etwas flasch ist und deshalb so viel Strom verbraucht wird?

Also ich habe im Befehlssatz, des Displays, Befehle gesehen um die 
Ansteuerung zu spiegeln. Beim kurzen Test hat das aber nicht so wirklich 
geklappt.

Das Drehen der Displayinhalte geht meines Wissens mit diesem Display 
nicht. Auch bei meinen Spiegelversuchen war es im Endeffekt sehr einfach 
das Bild direkt spiegelverkehrt in den Display-RAM zu schreiben. Ich 
denke mal das Drehen geht auch sehr leicht in Software.

Gibt es schon was nutzbares in BASCOM dazu? Hatte nur bei Adriano den 
Link gefunden, aber der führt ins nichts...?

Schau doch mal bitte unter www.bascom-forum.de
Da werden Sie geholfen ...Ein netter Mensch (der auch hier mitliest 
ist), hat ein Bascom Code veröffentlicht.

Gruß Anselm

Mal Link heraus gesucht habe:
http://bascom-forum.de/index.php/topic,2754.msg16848.html#msg16848

Genau diese Seite geht bei mir nicht...
Wird ewig geladen und kommt kein Inhalt... :(

Gerade was entdeckt... Accu-Chek Voicemate plus. Das Gerät kann in 
Verbindung mit dem hier beliebten Gerätchen die Messwerte für 
sehbehinderte oder blinde Personen vorlesen. Was für eine Schnittstelle 
hat also unser Gerät? IrDA oder was gescheites? g

IrDA

Definitiv IrDa, kann man ja auch mal mit einem PC mitlesen die Comm.

Daniel H. schrieb:
> Genau diese Seite geht bei mir nicht...
> Wird ewig geladen und kommt kein Inhalt... :(
So kennt man Basic ja ;-)

SCNR

Das hier wäre auch ein ziemlich interessantes Gerät, kostet aber wohl 
leider ca. 50€:
http://www.contourusb.de/

Einfach warten, wird schon billig ;)

Hab mir eins geshoppt, mal sehn wies ist :)

B. Heller schrieb:
> Hab mir eins geshoppt, mal sehn wies ist :)

Zu welchem Preis?

M. G. schrieb:
> B. Heller schrieb:
>> Hab mir eins geshoppt, mal sehn wies ist :)
>
> Zu welchem Preis?

Na was so auf der Seite steht ;)

Hallo,

auch ich experimentiere momentan mit dem Gerät und habe eine Frage zur 
Spannung (die hier schon in anderer Form gestellt wurde):

Wieviel messt Ihr zwischen VCC-GND am Atmega168? ich komme nur auf 2.8 V 
(bei ausgebauten asic). Bei einem neuen Gerät (mit Asic) messe ich 3.2V.
Gibt es Bauteile, die unbedingt zusätzlich zum Asic ´runter müssen?

so, jetzt mit 3.3V:

Das Rätsels Lösung liegt in PB7: damit wird der 3.3V Step-Up 
eingeschaltet. Wenn PB7 auf high liegt, messe ich 3.25V, bei PB7 auf low 
nur 2.8 V.
Beim Nachverfolgen von Pin4 des AS1329 (Shutdown) liegt dieser über R12 
an PB7.
Das Ärgerliche daran: einen Quarz zu nutzen wird schwieriger...

Die Info habe ich mal in die Pinbelegungstabelle des Artikels 
eingepflegt.

Wollte mich mal bedanken für die ganze Arbeit, die ihr hier reingesteckt 
habt.

Das ist ein super Einstieg in die avr Programmierung. Heute war das Ding 
in der Post (gebraucht für 1€ von ebay) ISP drangelötet wie im Artikel 
eingezeichnet und den Kurzzeitwecker draufgespielt.

15 Minuten und das erste Resultat war auf dem Screen zu sehen.
Klasse.

So, und jetzt wird selbst was geschrieben :-)

Das geht mit ADC6, den 3.2 Volt-Wandler dazu abschalten.

Habe die Info hier eingepflegt:
http://www.mikrocontroller.net/articles/Compact_Plus_Blutzuckermessger%C3%A4t-Hardware#Pinbelegung_Mega168

Frank.

B. Heller schrieb:
> Hab mir eins geshoppt, mal sehn wies ist :)

Hast Du es schon bekommen und mal das Innenleben angeschaut?

Bisher noch nicht...

Für eine ComPort-Ausgabe vom Rechner habe ich schnell mal ein 3.3V 
Display gebraucht und deshalb das OLED-Modul seriell (9600-8-N-1) 
ansteuerbar gemacht. Damit bin ich bekanntlich nicht der erste, aber ich 
teile eben auch gern! ;-)

krishna schrieb:
...
> Aber'n Terminal ist ja keine Kunst.

Stimmt, man braucht nur etwas Zeit. ;-)
(obwohl es kein echtes Terminal ist!)

Quelltext gibts vielleicht nach Überarbeitung demnächst...
...falls man auch mal etwas über andere Projekte mit Verwendung dieses 
OLEDs erfährt!? ;-)

Gruß,
a.

Hallo Tobi,

warum willst du die eh schon vorhandenen Bauteile wegwerfen und neue 
einsetzen? Das QFN-Package kann man doch von Hand löten. Wenn ich die 
Zeit finden würde, hätte ich eine Platine mit den Originalbauteilen 
gebaut.

Danke Tobi,

was mir fehlen würde:

ein normaler SMD Quarz mit 2 Cs als Alternative
RxD und TxD 'rausführen z.B. für externe Ansteuerung
ein ISP-Header wäre auch schön

Platz dafür wäre in den Platinenmaßen da.

Gruß
Einhart

Sehr interessant Deine Platine. Ich habe aber zwei Änderungsvorschläge.
Mach sie doch exakt so groß wie das Display, als 45x36mm und mach 
stattdessen Kerben und Löcher für die Plastiknasen rein, so daß man sie 
von hinten auf das Display klipsen kann. Dann noch den Displaystecker 
etwas in die Mitte rücken, so daß das Flachbandkabel nicht so weit nach 
aussen ragt.

Problem beim direkten aufklipsen ist allerdings, das dann die Bauteile 
auf der einen Seite vom Display weg zeigend und der Folienstecker zum 
Display hin zeigen muß.

Aber auch wenn es so bleibt wie es ist, planst Du davon ein paar mehr zu 
fertigen?

Gruß
Thorsten

Hallo

ich bastel hier grad eine kleine Library für schöne Proportionalschrift 
für das Display. Dabei ist mir aufgefallen, daß der Rechteckbefehl 0x24 
sich etwas seltsam verhält. Erstens kann er anscheinend nur byteweise 
malen, also sind die senkrechten Linien immer zwei Pixel breit und man 
kann auch nicht auf ungerade Pixel positionieren. auch die Breite ist 
immer doppelt so breit.

Ein Rechteck x,y,x+2,y+2 ist also 4x4 Pixel groß. Soll das so sein? Ich 
befürchte ja, wenn ich mir den geringen Wertebereich von x und y im 
Datenblatt anschaue.

Des weiteren fängt der Bildschirm anscheinend nicht bei 0,0 an sondern 
bei 7,7. Wie kommt das denn?

Viele Grüße
Thorsten

Japp ist so.

Die Parameter geben nicht die Koordinaten sondern die Speicheradressen 
an.
Zudem inklusive beider Enden. für einen 2x1 Punkt müssen Start und 
Endadresse die Gleiche sein.

Abfeilen ? Ehm, es reich den folienstecker aus der gehäuse (schwarz) 
rausziehen damit die lang genug wird .. und den dazugehörigen stecker 
unter dem display verstecken anstatt unter den displayrahmen.

hammer was ihr alles rausbekommt ;)

Hallo

So ähnlich wie Olafs Platine dachte ich mir das. Wenn man den 
Folienstecker noch weiter nach innen verlegt, so daß er nicht mehr unter 
den Displayrahmen ist muß man nicht feilen. Allerdings ist dann der eine 
Kunststoffdorn im Weg. Den muß man dann abknipsen, was aber einfach geht 
und keine Folgen hat wenn die Platine exakt die Masse der anderen Nasen 
einhält.

Aufpassen muß man aber auch mit Bauteilen die unter dem Displayrahmen 
liegen. Erstens ist hier nur 1mm Platz und das auch nicht überall. Muß 
man also recht genau arbeiten.

Gruß
Thorsten

PS.: Hat schonmal jemand was mit dem Accu-Chek Mobile gemacht?

Hallo

meine Proportionalschrift Library nimmt Formen an. Siehe Foto. Das 
schwierigste war erstmal ein Programm für den PC welches den Font 
generiert.

Die Library kann proportionale Fonts beliebiger Größe in schwarzweiß 
(siehe kleiner Text) oder mit 16 Graustufen (siehe große Zahlen) 
darstellen.

So ganz optimal funktioniert es aber noch nicht, wie man an den "e"s im 
Text sehen kann. Der Grund ist, daß man ja bei diesem Display nicht 
pixelgenau positionieren kann. Ich müßte die Textzeile also wohl erst im 
Speicher zusammenbauen. Dazu ist das RAM des Controllers aber arg knapp.

Nun versuche ich meine Routine so umzubauen, daß sie nicht zeichenweise 
sondern zeilenweise rendert, was aber furchtbar viel Bitschiebereien mit 
sich bringt. Mal sehen ob ich es hinbekomme.

Bis denn
Thorsten

Superinteressants Thema hier! Habe gleich mal eine Frage zum OLED 
Display. Ich würde für meine Anwendung eine rote Anzeige benötigen. Ist 
es möglich vor das Display eine rote Folie zu legen und so die Farbe zu 
ändern? Oder kommt da nichts mehr durch? Bei einer normalen gelben LED 
funktioniert es. Das Leuchten wird zwar dunkler, da nur ein kleiner Teil 
des Spektrums genutz wird, das würde aber in meinem Fall nicht so 
stören, da es eh Nachts benutzt werden soll.

Viele Grüße,
Steffen

Steffen N. schrieb:
> Ich würde für meine Anwendung eine rote Anzeige benötigen. Ist
> es möglich vor das Display eine rote Folie zu legen und so die Farbe zu
> ändern? Oder kommt da nichts mehr durch? Bei einer normalen gelben LED
> funktioniert es. Das Leuchten wird zwar dunkler, da nur ein kleiner Teil
> des Spektrums genutz wird, das würde aber in meinem Fall nicht so
> stören, da es eh Nachts benutzt werden soll.

Ich denke, das sollte funktionieren.

Deine Beschreibung der Einsatzumgebung erinnert mich an meine 
Ausbildung. Du denkst aber dran, dass Hilfsmittel meist nicht zugelassen 
sind? Rot ist zwar am wenigsten verräterisch im Gelände, aber ich 
fürchte aus Erfahrung, dass man dich auf freiem Feld damit immer noch 
kilometerweit sehen kann.
Hmm, da hab ich auch gleich mal wieder Lust mich zu einer Übung zu 
melden.

> Besser wäre ein orange-rot oder gleich ein Display in der passenden
> Farbe oder ein kleines TFT (z.B. das vom Siemens S65) mit frei wählbarer
> Schriftfarbe ;).

Da werde ich mir im neuen Jahr mal so ein Blutzuckermessgerät holen und 
Tests machen, oder hat jemand eine Quelle für günstige rote OLED 
Displays.

Das Problem an TFT's bzw. LCD Anzeigen ist vor allem die Trägheit bei 
Kälte. Da das Gerät auch bei -30°C noch was anzeigen soll, wäre so ein 
OLED Display schon eine feine Sache.

> Deine Beschreibung der Einsatzumgebung erinnert mich an meine
> Ausbildung. Du denkst aber dran, dass Hilfsmittel meist nicht zugelassen
> sind? Rot ist zwar am wenigsten verräterisch im Gelände, aber ich
> fürchte aus Erfahrung, dass man dich auf freiem Feld damit immer noch
> kilometerweit sehen kann.
> Hmm, da hab ich auch gleich mal wieder Lust mich zu einer Übung zu
> melden.

Hallo Tim,
ich hätte nicht gedacht das Du in deiner Ausbildung Astronom warst ;-))) 
Das Display soll nämlich Teil einer Teleskopsteuerung werden, dort sind 
rote Anzeigen ein unbedingtes Muß um das dunkeladaptierte Auge nicht zu 
beeinflussen. Wie ich auch oben schon schrieb kann es Nachts sehr kalt 
werden und da versagen LCD-Anzeigen durch ihre Trägheit leider total.

Viele Grüße und frohe Weihnachten,
Steffen

Mit dem Hintergrund, dass du ohnehin eine möglichst geringe Störung 
durch das Licht haben willst, solltest du es einfach mal mit einer Folie 
ausprobieren.
Das Display ist in der hellsten Helligkeitsstufe schon ziemlich hell.

@Thorsten:
Gibt es denn bereits nähere Infos zu der Proportionalschrift bzw. eine
Applikation ähnlich dem GLCD zu Generierung des Fonts->*.h File.?
Gruss, Peter

Thomas F. schrieb:
> Da es mehrere Anfragen während meines Urlaubs gab, hier mal der
> Quelltext des Quick & Dirty GCC-Oled-Demos (im Gerät mit dem
> ATmega168PV).

Übrigens, die Definition von WriteString sollte wie folgt lauten:

void WriteString(BYTE xPos, BYTE yPos, char *Str)

(char statt BYTE für das Ergebnis des Pointers),
dann sind auch die ganzen Warnungen des Compilers weg.

Gruß
Karl

@Peter:
Ja, es gibt was neues zur Proportionalschrift. Erstens habe ich ein 
kleines Tool gebaut welches aus einer Bitmapgrafik eine Font-Datei 
erstellt. Ist zwar nicht perfekt, funktioniert aber.

Ausserdem sind die Positionierfehler der Zeichen nun weg, da ich immer 
die ganze Zeile in einem Rutsch ausgebe und nicht zeichenweise. Auch 
gibt es schon eine Funktion zur formatierten Ausgabe. Das heißt man gibt 
ein Rechteck an in dem der Text erscheinen soll. Dabei kann man angeben 
ob er rechts, links, oben, unten oder zentriert ausgeben werden soll. 
Ausserdem kann man Vorder- und Hintergrundfarbe einstellen.

Da ich in Urlaub war habe ich aber noch nicht die Zeit gefunden mal ein 
schönes Archiv mit Beschreibung zusammenzustellen. Ich will auch noch 
Routinen für Rechtecke (gefüllt oder leer) und horizontale und vertikale 
Linien einbauen. Vielleicht sogar eine Routine um ein Menü darzustellen 
und zu steuern (mit den Tasten).

Nur bin ich nun auf ein kleines Problem gestoßen. Meine Stringausgabe 
erwartet die Strings im RAM, also als normale char-Variablen. Will ich 
nun die Strings im Flash ablegen gehts nicht so einfach. Da ich ja immer 
die ganze Zeile am Stück bearbeite müßte ich nun die ganze 
Ausgaberoutine doppelt vorhalten, einmal mit progmem-Strings und einmal 
mit normalen. Oder aber ich kopiere bei Aufruf der progmem Ausgabe 
erstmal die Zeile ins RAM und rufe dann die RAM-Ausgaberoutine auf. Was 
meint ihr, was am sinnvolsten ist?

Wollt Ihr schonmal das noch nicht hübsch gemachte Beispielprogramm haben 
oder soll ich es lieber erstmal aufräumen und dokumentieren? Vermutlich 
habe ich morgen Zeit dazu, sonst am Wochenende.

Bis denn
Thorsten

Habe wieder eine nette Idee, was ich aus einem Gerät machen werde.

Es soll ein WLAN-Spectrum-Analyzer werden.

Nur 2,4GHz, da ich keinen anderen Empfänger da habe.

Ausgabe des Spektrums als Balkengrafik mit Maximumanzeige. Per Cursor 
kann man sich einzelne Frequenzen anwählen und dort noch einen 
numerischen Wert anzeigen lassen.

Das ganz wird auch per RS232/USB abfragbar sein, damit man die Daten 
auch mit dem Notebook verarbeiten kann.

Bei 80 Frequenzen pro Scan und ca 10 Scans pro Sekunde sollte 115200 
Baud ausreichen.

Auf dem Notebook kann man dann auch noch eine 3D-Grafik (eine Art 
Geländeprofil) ausgeben lassen und die Daten über längere Zeit 
aufzeichnen.

Das ganze sind vorerst nur Ideen. Verwirklichung später ;-)

@Thorsten:

Das mit dem Fontgenerierungs-Tool hört sich soweit super an.
Mein Ziel wäre eine simple Implementierung von ädequaten und großen 
Fonts (à la 40-50 y_pixel) um damit in meiner Anwendung GPS Speed, Höhe 
über NN und Heading verteilt auf 2 OLED-Displays anzuzeigen. Das Teil 
wird mit einem Navlock "Open"-GPS Empfänger gekoppelt und anschliessend 
im Auto verbaut. Daher auch der große Font zwecks guter (Ab)Lesbarkeit. 
Der Treiber für einen Big Font (ähnlich dem TTF Windows-Font ARIAL48) 
arbeitet schon zufriedenstellend (siehe Bild im Anhang).
Jedoch fehlen mir z.B. noch Schatten um den Font etwas "aufzupeppen". 
Ausserdem dauert es furchtbar lang bis ein Font fürs Flash ausgesucht, 
konvertiert und angepasst ist. Daher wäre so ein Tooling nicht schlecht.

> Nur bin ich nun auf ein kleines Problem gestoßen. Meine Stringausgabe
> erwartet die Strings im RAM, also als normale char-Variablen. Will ich
> nun die Strings im Flash ablegen gehts nicht so einfach. Da ich ja immer
> die ganze Zeile am Stück bearbeite müßte ich nun die ganze
> Ausgaberoutine doppelt vorhalten, einmal mit progmem-Strings und einmal
> mit normalen. Oder aber ich kopiere bei Aufruf der progmem Ausgabe
> erstmal die Zeile ins RAM und rufe dann die RAM-Ausgaberoutine auf. Was
> meint ihr, was am sinnvolsten ist?

Um Dir ein Feedback zu geben: Könntest Du das anhand eines Beispiels 
erklären, ich hab noch nicht ganz den Durchblick was Du genau meinst. 
Definiere progmem-Strings und "normale" Strings. Was für eine 
RAM-Ausgaberoutine? etc. pp. :-)

Grüsse, Peter

@Peter: Spassig, Du hast dann fast das selbe vor wie ich, nur will ich 
keine GPS Daten anzeigen sondern die Uhrzeit als D'ni-Zeichen (siehe 
Computerspiel Myst). Und das dann verteilt auf drei Einzeldisplays.

Zum Progmem Problem. Normalerweise (wenn man keine AVR Prozessoren 
verwendet) definiert und verwendet man in C Strings ja so:

1

const char s[]="Hallo";

2

3

void printstr(char *s)

4

{

5

  // gib den Text aus

6

}

7

8

[...]

9

10

printstr(s);

Solch "normale" Strings landen beim Atmel im RAM, genauso wenn man 
einfach schreibt:

1

printstr("Hallo");

Hat man nun viele Strings müllt man sich damit das knappe RAM voll. 
Deshalb kann man bei den AVRs Daten und damit Strings auch im 
Programmspeicher (Flash) ablegen. Dann müssen die Strings aber anders 
definiert werden, nämlich so:

1

const char s[] PROGMEM="Hallo"; // man beachte das PROGMEM

2

3

void printstr_P(PGM_P s)

4

{

5

  // gib den Text aus

6

}

7

8

printstr_P(s);

9

printstr_P(PSTR("Hallo"));

Man muß also die Parameterübergabe an die print-Funktionen anders machen 
und in den Funktionen auch anders auf die Strings zugreifen. Da ja bei 
den kleinen Display nicht soviele Zeichen in eine Zeile passen wäre es 
wohl am einfachsten eine printstr_P Funktion zu bauen, die den String 
ins RAM kopiert und dann printstr aufruft. Dann braucht man zwar auch 
ein paar Bytes RAM, aber immer nur für eine fürs ganze Programm und 
nicht für jeden einzelnen String.

Ach übrigens, versprich dir nicht zu viel von meinem Fontkonverter. Er 
erwartet ein Bild in dem alle Zeichen eines Fonts in der richtigen 
Reihenfolge, jeweils umrahmt von einem andersfarbigen Rahmen enthalten 
sind und baut daraus dann den C-Code für den Font. Aber das macht man ja 
nicht so oft. 2 1/2 Fonts habe ich ja auch schon fertig. Einen kleinen, 
einen mittleren und einen riesigen, der aber nur Ziffern und den 
Doppelpunkt enthält.

Gruß
Thorsten

Ich brüte nachwievor über die Sinnhaftigkeit der Funktion "printstr" in 
Bezug auf die Fontgenerierung. Den Zugriff auf die Strings im Flash 
mache ich über eine Pointeroperation und einer linearen Berechnung; im 
übrigen arbeite ich mit einem LPC2103 ARM7, dort entfällt die Option 
PROGMEM. Klar, ohne den Zusatz pointet der Compiler knallhart aufs RAM, 
daher ist das unumgänglich. Aber soweit ich das verstanden habe macht 
der kleine Umweg übers RAM schon Sinn sofern der printstr Verwendung 
findet. Steht das somit in direkten Bezug mit dem FontTool?
Du klar also wegen dem Komfort, kein Thema..ich benötige lediglich einen 
Weg um den Turnaround zw. Font sehen und nutzen zu beschleunigen. 
Desweiteren gefällt mir die Schattenfunktion, wobei das natürlich mehr 
Flash kostet sofern man ein paar Graustufen hinzufügt.
Möchte auch zwei Fonts einsetzen, zum einen die "nackten" Daten und zum 
anderen die Metrik, z.B. "km/h" oder "m" oder oder....
Rahmenerstellung hört sich auch interessant an.
Bin ja gespannt auf das Tool. Ne lass Dir Zeit und stabilisiere es bevor 
Du's postest.
Gruss, Peter

Hallösche! Nachdem ich mir mal den Output des GLCD.exe angeschaut hatte 
gabs weitere Änderungen im Treiber. Die Fontproperties sind dort ja 
unten alle generisch hinterlegt, man muss nur noch ein paar Zeiger bauen 
und schon kann man den Font einbinden; bin also weg von der Methodik mit 
dem statischen Font und dem gefitzel bis das mal passte. Aussehen tuts 
net schlecht. Diesmal wars ein ARIAL16 Kursiv Font. Und das JPG zeigt 
wie die Anwendung nachher aussehen könnte.

Beim Accu-Chek Mobile mit ATMega2561V Controller sind RxD0/TxD0 sowie 
der Portpin PG0 auf den Testpads herausgeführt, die unter dem Aufkleber 
auf der Gehäuserückseite verborgen sind. Wenn man PG0 über 1k auf GND 
legt und dann das Gerät einschaltet, dann sendet das Gerät zyklisch 
folgende Bytefolge mit 38400 Bd:
C0 29 BB 4C C1
(5 Hexwerte)

Das könnte evtl. ein Bootloader sein, der versucht, sich mit einem 
Updatetool zu verbinden.
Kommt jemand die Bytefolge bekannt bevor, könnte das irgendein 
"Standard-Bootloader" sein?

Was hat denn der Accuchek Mobile für ein Display?
Das gleiche wie der Compact Plus?

Zum Bootloader: Hast Du mal probiert, ob man mit FLIP rankommt?

Bzgl. Display:
OLED mit SSD1325
siehe auch Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display" und
http://www.flickr.com/photos/hellercom/sets/72157622084668976/

Bzgl. FLIP:
laut dieser Seite wird der ATmega2561 nicht unterstützt:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3886

Bluescreen2001 schrieb:
> Hat schonmal jemand das Accucheck mobile ohne brutale Gewalt
> aufbekommen?

Nein, leider nichts zu machen.

Wenn man über TxD / RxD eine neue Firmware flashen könnte, wäre das 
genial, da man dann nur den Aufkleber auf der Rückseite wegmachen und 
die Pins kontaktieren müsste. Ist die Frage, ob eine Art 
"Standard-Bootloader" verwendet wurde oder irgendwas proprietäres.
siehe auch 
Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display"

ISP und JTAG habe ich auch mal ausprobiert, aber ich bekomme leider 
keine Verbindung. Evtl. wurde beides durch die Fusebits deaktiviert?
Der PP/HV-Modus ist leider etwas aufwändig...

Hallo,

nun habe ich meine Library für das Gerät soweit fertig. Alle Drawing 
Primitives funktionieren (Proportionalschrift mit Ausrichtung, Rechtecke 
mit oder ohne Rahmen, horizontale und vertikale Linien). Das alles 
pixelgenau positionierbar.

Aber ich habe ein kleines Problem mit dem WinAVR. Wenn ich das Ganze in 
mehrere Dateien aufteilen will und von allen Teilen die Fonts einbinden 
möchte, bindet der WinAVR sie tatsächlich doppelt ein, was dann das 
Flash sprengt. Was mache ich da falsch?

Die Fonts sind in Headerfiles enthalten die wie folgt aussehen:

1

/* chrsmall.h

2

 * Font file created by FontCreator written by thorsten.erdmann@gmx.de

3

 * input file : 'chrsmall.bmp'

4

 */

5

#ifndef CHRSMALL_H

6

#define CHRSMALL_H

7

8

#include <avr/pgmspace.h>

9

10

/* Font header */