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.
Hehe, erwischt :) muss lauten AT5"8"A63M-02, aber dennoch kein Datenblatt. :( Grüße
Neuigkeiten: Die tollen Jungs von Segor in Berlin haben ab nächste Woche den kleinen 15Pin Connector fürs OLED im Sortiment! Wer Segor nicht kennt, schaut hier: http://www.segor.de und schämt sich ;) Gruß tec
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.
Hallo! Habe gestern warscheinlich aufgrund eines ISP-Fehlers die Fuses falsch programmiert und kann nun mit dem 168er auf dem Serienboard nicht mehr kommunizieren. Hat jemand schon mal versucht mit einem externen Taktgeber zu arbeiten? Wie und womit sind die XTAL-Pins (PB6 und PB7) verschaltet? Gruß Robert
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
@Anselm ich arbeite bereits an einer Umsetzung nach BASCOM - Mach Dir nicht die Mühe. Bis auf die Darstellung von Graustufen Bildern habe ich alles fertig und werde den Code hier veröffentlichen.
Ja, hab deinen Thread im bascom-forum gestern abend noch gefunden. Wenn du ProfessorHase bist ^^ Gruß Anselm
Hat mittlerweile jemand den maximalen Strombedarf, also bei allen Pixeln auf höchster Helligkeit, gemessen? Wie klein darf die 12 V Spannungsquelle dimensioniert werden? Reicht es einen Boostconverter für 100 mA einzuplanen? Grüße
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
Ja stimmt. Das würde bei 1,2 W wohl etwas warm :). Nur denke ich dass schon eine gewisse Reserve da sein sollte. Im AccuCheck Gerät sieht man z.B. ab und zu bei größeren blinken Elementen dass diejenigen, die dauernd leuchten etwas blasser werden wenn der Stromverbrauch steigt. Grüße
Jetzt auch in BASCOM ... Im von Anselm genannten Forum habe ich den Code veröffentlicht. Support gebe ich am besten auch dort.
Compact Plus: Man kann die Innereien mit einem Messer an den Schweißpunkten trennen und so das Batteriefach weiterbenutzen (ist dann aber nur noch mit einer Schraube am Gehäuse fest). Das ist auch der einzige Weg, die Mechanik auszubauen. Es bleibt viel Platz - z.B. für GPS und SD-Karte, wie weiter oben angedacht. Wird die Schaltung über einen Step-Up versorgt, oder direkt aus den Batterien? Mein GPS-Modul braucht nämlich 3.3 V..
man kann außerdem noch den "wurmfortsatz" an der Originalplatine plan abschneiden, dann hat man noch ein bischen mehr platz.
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.
Gibt es ein Datenblatt zum Display selbst? Ich würde gerne wissen was so die Lebenserwartung ist. Danke übrigens an Adriano für den Demo Code und die Infoseite. Jemand hatte geschrieben, dass er Daten seriell empfängt - würdest Du den Code hier reinstellen? Das würde mir etwas Zeit sparen. Ich brauche nämlich noch irgendeine Art UI für mein NSLU-2 Webradio..nur werde ich für die Tasten wohl nicht um ein TX in Software herumkommen.
Zu dem Display habe ich selbst noch kein Datenblatt gefunden. Wenn du bei Google aber mal nach Osram Pictiva suchst, findest du vergleichbare Displays etwa mit 128x86 Pixeln. Die Lebenserwartung liegt soweit ich mich erinnere bei um die 40000 h. P.S.: http://catalog.osram-os.com/catalogue/catalogue.do?favOid=000000000000054400010023&act=showBookmark
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
Darüber habe ich auch schon nachgedacht, mit folgendem, nicht weiter verfolgten Gedanken: "sprite" hat auf Basis einer LED-Matrix und eines Photosensors eine Art Touchpanel aufgebaut: http://spritesmods.com/?art=novemini&page=2 Evtl. funktioniert das Prinzip auch mit OLED und man könnte drauf synchronisieren? Im schlechtesten Fall könnte man selbst die Tastenfelder nacheinander zeichnen und das Streulicht detektieren. Flackert dann aber..
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.
Notiz zur CompactPlus Hardware und Adrianos Beispielcode: Es wird Software-SPI eingesetzt write_byte() Es gibt die Möglichkeit "20. USART in SPI Mode".. Und ich möchte meine Frage nochmal stellen: > Wird die Schaltung über einen Step-Up versorgt, oder direkt aus den > Batterien? Mein GPS-Modul braucht nämlich 3.3 V..
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.
D.h. ein Betrieb an 5 V ist vermutlich nicht möglich!?
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.
Bei einem neuen Gerät (mit dem großen IC) komme ich auch auf 3.2 V..
Dann hast du beim Abmontieren des ASIC irgend einen Kollateralschaden verursacht. Bei mir ist der auch weg.
Angehängte Dateien:
-
oled_ghosting.jpg
30 KB
Guten Sonntag, ich habe nochmal eine Frage zur Compact Plus Elektronik. Und zwar habe ich den 3.3 V Schaltregler ausgelötet, und den Ausgangspin direkt auf Batterie + gelegt (Der Schaltregler für die OLED Vesorgung lebt auch direkt aus der Batterie). Weiterhin versorge ich die Schaltung durch externe 3.3 V die ich über die AVR ISP Pins angelegt habe. OLED Spannung ist 13.2 V aus 3.3 V. Das Problem: es gibt vertikale Schmier-Streifen auf dem OLED.
Des Rätsels Lösung: V_COMH voltage war zu niedrig. Mit dem weiter oben erwähnten Wert 0x11 (Wert nach Reset) geht es gut. Ich hatte das Display eine zeitlang so mit statischem Bild im Betrieb, jetzt ist es bereits leicht eingebrannt.. also Vorsicht!
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?
@Q9: an CS, DC, SCLK und die Fuse-Bits hast du gedacht?
Sonst ist der Code identisch zum funktionierenden Beispiel von adriano. D.h. Pins sind dieselben, Register identisch. Fusebits für SPI/UART? Wüsste nicht welche.. Allerdings bin ich mir über den SPI mode nicht ganz im Klaren und ob das Timing hinhaut.
Also ich komme nicht dahinter. Leider kann ich auch nicht messen. Hier aus dem Datenblatt des SSD1325: > SDIN is shifted into an 8-bit shift register on every rising edge of SCLK > in the order of D7, D6, ... D0. > D/C# is sampled on every eighth clock and the data byte in the shift > register is written to the Graphic Display Data RAM (GDDRAM) or command > register in the same clock. Also MSB first, rising edge, clock_cycle > 250 ns (also < 4 MHz) SPI Mode müsste 3 nach Atmel sein. AVR317 sagt nicht wirklich mehr als das Datenblatt.
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.
Danke für den Hinweis, das hatte ich auch schonmal ausprobiert. Zwischen den Bytes muss noch eine Pause eingelegt werden, damit SCLK und SDIN auf high bleiben, dann geht es. Mit 40 µs klappt es auf jeden Fall, ich werde mich jetzt an einen brauchbaren Wert rantasten. Vielleicht kann jemand mit LA das optimieren.
Mit UBRR0=0 (4 MHz) und 2 µs Pause nach dem Schreiben funktioniert es endlich. Hat jemand schon einen Soft-UART eingebaut?
Ich bin gerade dabei die Initialisierung des OLED nachzuvollziehen. Es gibt hier/Wiki/adrianos Seite unterschiedliche Aussagen bzgl. PB0 Es ist ein Testpad neben dem AVR (http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html) - Ladepumpe erzeugt 12 V (wohl falsch, da dafür der Stepup zuständig ist). - geht an Transistor T1 (http://www.mikrocontroller.net/articles/Compact_Plus_Blutzuckermessger%C3%A4t-Hardware#Pinbelegung_Mega168) - schaltet Masse für OLED (Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display") Die Masseverbindungen am Displayconnector scheinen aber direkt auf Masse zu gehen. Adrianos Code funktioniert ja wunderbar und lässt den Pin tristate. Wenn ich PB0 setze flackert das Display wie verrückt. Könnte mir das (was macht PB0/der Transistor) bitte jemand erklären?
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.
Vielleicht eine Grundlast zum Starten? > Because of the minimum duty cycle of each power switching cycle of > TPS61080/1, the device can lose regulation at the very light load.
Das könnte zum Abschalten benutzt werden. Laut Datenblatt muss Vcc (12V) vor Vdd auf 0 sein. Wahrscheinlich kann das damit sichergestellt werden.
Angehängte Dateien:
-
OLED-Kurzzeitwecker.jpg
260 KB
@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.
Sehr großes Interesse! Ich habe derweil noch einen Tip für den Befehl "Draw Rectangle (24h)" Es kann nur eine gerade Anzahl von Spalten angegeben werden. Der Befehl braucht Ausführungszeit und wird durch ungeduldig folgende Kommandos abgebrochen. Hier mal ein schneller Ersatz für die Clearscreen Funktion:
1 | SSD1325_WriteCmd(0x24); |
2 | SSD1325_WriteCmd(7); |
3 | SSD1325_WriteCmd(0); |
4 | SSD1325_WriteCmd(57); |
5 | SSD1325_WriteCmd(79); |
6 | SSD1325_WriteCmd(0); |
7 | _delay_ms(1000); |
Ich weiß nicht, wie lange man warten muss. Ich probier's jetzt mal mit 10 ms.
Hi >Mit UBRR0=0 (4 MHz) und 2 µs Pause nach dem Schreiben funktioniert es >endlich. kannst du dir wahrscheinlich sparen, wenn du auf TXC0 und nicht auf UDR0 prüft. Dann ist das Byte wirklich gesendet. MfG Spess
5 ms gehen auch. Die Row- und Colum-Address-Setzerei aus der Initialisierung kann man doch eigentlich weglassen, oder?
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.
> die Rechteckfunktion hatte ich schon mal im GPS-Demo drin
Stimmt, habe ich noch nicht gesehen.
Kurzzeitwecker:
Sehr schön!
Der Alarm geht nur beim ersten Mal bzw. verliert seine Einstellung und
ich habe horizontale Streifen (leere Zeilen sind leicht heller als
Zeilen mit Pixeln).
Übrigens: Das Via kommt genau neben dem Pad vom Buzzer raus. Eine Zinnbrücke reicht..
Heute habe ich mein Display mal an einen ATmega32 angeschlossen und das angepasste C Grundgerüst aufgespielt. Verwunderung: Alle kleinen Buchstaben sind um ein Zeichen verschoben. Anstelle eines a also b usw. Ich habe es so gelöst dass ich noch ein Zeichen zwischen den großen und kleinen Buchstaben eingefügt habe aber... woran bitte liegt das und warum hat das noch niemand hier erwähnt? :) Grüße
@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.
Dank spess53 das Schreiben mit USART-SPI jetzt ohne fixe Warteschleife:
1 | UDR0 = dat_or_cmd; |
2 | while ( !( UCSR0A & (1<<TXC0)) ); |
3 | UCSR0A |= (1<<TXC0); // clear TXC0 |
Noch zwei Fragen, dann ist Feierabend: 1. Wo kommen die Daten für die Initialisierung eigentlich her, gesnifft per LA? 2. Was nützt das "Horizontal Scrolling" wenn keine Synchronisation möglich ist (man weiss ja nicht, wann man angekommen ist)?
Was ist der schnellste Weg zu einem funktionierenden UART (RX, TX)? TX ist belegt mit (Soft-/UART-) SPI - Die (TXD, XCLK) könnte man an den echten SPI (MOSI, SCLK) hängen, dann wäre der echte UART frei. - Man bleibt bei Soft-SPI und benutzt den UART für RX, Soft-TX über einen Timer. - Man könnte PB0 verlegen um den ICP1 für Soft-UART freizubekommen. Alternativ den Komparator für ICP nutzen. Alles umzulöten macht viel Arbeit, Software muss man nur flashen - das Problem: ich bin kein Softwareguru.. Gute Nacht.
> 14.09.2009 22:17 Alle kleinen Buchstaben sind um ein Zeichen verschoben.
Vermutlich werden die falschen Daten aus dem Font gelesen. Entweder hat
sich irgendein Offset verändert, oder ein Datensatz (eine Zeile) fehlt.
ASCII Tabelle hilft.
Hatte deine Problemlösung überlesen. D.h. hier hast du noch eine Zeile eingebaut?
1 | 0x61, 0x51, 0x49, 0x45, 0x43, // Z 0x5A |
2 | |
3 | 0x00, 0x7F, 0x41, 0x41, 0x00, // [ - 0x5B |
4 | |
5 | 0x55, 0x2A, 0x55, 0x2A, 0x55, // backslash 0x5C |
6 | |
7 | 0x00, 0x41, 0x41, 0x7F, 0x00, // ] 0x5D |
8 | |
9 | 0x04, 0x02, 0x01, 0x02, 0x04, // ^ 0x5E |
10 | |
11 | 0x40, 0x40, 0x40, 0x40, 0x40, // _ 0x5F |
12 | |
13 | 0x00, 0x01, 0x02, 0x04, 0x00, // ' 0x60 |
14 | |
15 | 0x20, 0x54, 0x54, 0x54, 0x78, // a 0x61 |
Richtig. Ich habe einfach das Zeichen 0x60 kopiert und damit jetzt zwei gleichen Zeichen unter 0x60 und 0x61, aber so klappt es. Mit dem Zeichensatz aus dem Muichiz Thread läuft es auch ohne diesen "Trick". Da scheint also wirklich eine Zeile zu fehlen.
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.
Das mit der Eieruhr hat mich auf Ideen gebracht: Herdwarner: Ich vergesse ständig Sachen auf dem Herd / im Backofen. Eine Fotodiode im Sichtfenster auf der Rückseite prüft (ggf. nach Tastendruck) alle 30 Sekunden ob dort Licht reinscheint. Wenn, dann "Piep". Mikrowellen-Energiezähler: Zählt anhand der eingestellten Leistung die zugeführte Energie und schätzt die Erwärmung von Presets (Masse bzw. Volumen und Dichte, Ausgangstemp, Wärmekapazität).. und ETA. :-) Ich bin auch für ein Board mit dem Wichtigsten: AVR, Step-Up Regler, OLED an SPI, UART herausgeführt, geschalteter Entladewiderstand, ISP Header, Buzzer (+ Transistor), evtl. Taster... macht mal bitte :-)
Kurzzeitwecker 0.2 - Pause funktioniert noch nicht - Da die Zeit aus dem EEPROM kommt, bei Aufruf eines Programms Focus gleich auf "Start" - Zahnputztimer Startzeit "00:0/" (oder Müll aus meinem EEPROM?) Wär natürlich auch nett: -die Timer als Liste im EEPROM anlegen, dann brauchen sie eigentlich auch keinen Namen mehr. - die verstrichene Zeit anzeigen - statt Sternchen den Text invertieren - nicht immer den ganzen Bildschirm neu schreiben - zwischendurch zum Stromsparen nur die Zeit in 5x7 anzeigen und z.B. alle 10 s in groß.. - Helligkeit einstellbar .. Aber Ideen hast du selber ja genug, nehme ich an! :-) Benutzt du eigentlich den Lastwiderstand zum Ein/Ausschalten?
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.
Sieht gut aus! Veröffentlichst Du den Quellcode? Hardware SPI läuft übrigens wunderbar zwischen ATmega und Display. Selbst bei 8 MHz gibt es keine Probleme.
Oder kannst du kurz erläutern, welche Funktionen du benutzt? @Adriano 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..
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.
> ein paar Fehler (aber noch nicht alle :-)) habe ich in V0.3 gefixt... Sogleich geflasht..macht Spaß! :-) - der blinkende Doppelpunkt ist beim Start nicht zu sehen (bitte Menüeintrag zum Abschalten des Blinkens) - Idee: die passiven Segmente mit Helligkeit 1 betreiben ? > Hardware-SPI muss ich auch mal testen... Weiter oben hatte ich den Code zur Initialisierung (aus dem ATMEL Datenblatt übernommen) und später die Schreibroutine gepostet. Dauert 1 min zu übernehmen.. Hier meine Funktionen zum Ein- und Ausschalten mit Lastwiderstand. Die Einschaltzeit (12 V Schaltregler) habe ich gemessen, ist evtl. etwas länger. Wie lange das OLED zum Entladen braucht weiß ich nicht. Vielleicht ist jemand nochmal so gut und hält sein Oszi dran?
1 | void
|
2 | SSD1325_PowerOn(void) |
3 | {
|
4 | OLED_RES_LO; // Reset |
5 | _delay_us(10); |
6 | OLED_RES_HI; |
7 | SSD1325_VCC_LOAD_ON; // 100 Ohm to GND |
8 | SSD1325_VCC_ON; // 12 V ON |
9 | _delay_ms(40); // wait until VCC stable |
10 | SSD1325_VCC_LOAD_OFF; // 100 Ohm to GND |
11 | SSD1325_WriteCmd(0xAF); // display ON |
12 | }
|
13 | |
14 | |
15 | void
|
16 | SSD1325_PowerOff(void) |
17 | {
|
18 | SSD1325_WriteCmd(0xAE); // display OFF |
19 | SSD1325_VCC_LOAD_ON; // 100 Ohm to GND |
20 | _delay_ms(200); // Wait until panel discharges completely |
21 | SSD1325_VCC_OFF; // 12 V OFF |
22 | SSD1325_VCC_LOAD_OFF; // 100 Ohm to GND |
23 | _delay_ms(100); // wait for T_off |
24 | }
|
Die ersten Befehle aus adrianos Initialisierung können anscheinend schadlos weg, es folgen ja keine Daten. Die von adriano ermittelten Werte sind also nur experimentell bestimmt, wenn ich das richtig verstanden habe. Deshalb wär' es gut zu wissen, ob in den Informationen zu OSRAM Pictiva OLEDs irgendetwas über die zulässigen Spannungen/Ströme für die Pixel steht. Alternativ, wenn jemand einen Logikanalysator hat, müsste man bei der Initialisierung vom Accu-Chek mal mithören. Wahrscheinlich wird da 4 MHz SPI eingesetzt. Ich habe mir nämlich schon einen Text leicht eingebrannt, und der war nicht länger als 2 h aktiv. > Ich bin auch für ein Board mit dem Wichtigsten: AVR, Step-Up Regler, > OLED an SPI, UART herausgeführt, geschalteter Entladewiderstand, ISP > Header, Buzzer (+ Transistor), evtl. Taster... macht mal bitte :-) Das halte ich für eine gute Idee, leider kann ich das nicht "mal eben so" umsetzen. Mit dem Adapter von oben ist
Schlürf.. Bugreport (v0.3): Absturz nach Ablauf der Zeit (countdown). Konnte nicht "abbrechen". Watchdog einsetzen, die Kondensatoren halten die Versorgungsspannung anscheinend ziemlich lange ohne Batterien (OLED Raminhalt derselbe nach Einlegen.) Beim Anlegen der Versorgungsspannung werden 2 Bildschirme gezeichnet, irgendwas stimmt mit der Starteinstellung wohl nicht. Idee: Es wär praktisch wenn der Zähler nach Ablauf weiterläuft (Zeitüberschreitung). Dann weiß ich genau, wenn der Tee bitter schmeckt, dass er 15 Sekunden zu lange gezogen hat.. :-)
@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
Sagt mal, wie hoch ist denn der Stromverbrauch bei euren Geräten? Ich komme auf diese Werte: ~ 55 mA helles Display ~ 14 mA schwarzes Display ~ 10 mA schwarzes Display, 12V ausgeschaltet ~ 3 mA schwarzes Display, 12V ausgeschaltet, AVR im Poweroff Mode kann ich da irgendwie noch was ausschalten, damit der Verbrauch weiter sinkt?
Also ich hatte mit dem Kurzzeitwecker-Demo und ausgebautem 100Pin Atmel-IC so unter 100µA gesehen (nach Auto-Abschaltung nach ca. 30sec) - kann daß jemand bestätigen?
Hm. Viellecht kann mir da jemand weiterhelfen. Ich mache diese Sequenz (Quellcode vom OLED-Demo):
1 | |
2 | ClearDisplay(); |
3 | OLED_12V_LO; |
4 | write_cmd(0xAE); |
5 | sei(); |
6 | EICRA=0b0100; |
7 | EIMSK=0b10; |
8 | set_sleep_mode(SLEEP_MODE_PWR_DOWN); |
9 | sleep_mode(); |
Das Display ist jetzt dunkel, AVR im Poweroff-Mode (der fette Atmel ist ausgelötet). Das Ding zieht aber noch immer 2mA. Was hab' ich vergessen abzuschalten? Stromverbrauch im Sleepmode vom Kurzzeitwecker-Demo ist übrigens auch 2mA. Mit den 2 mA lebt das Ding mit einem Satz Batterien grad' mal 20 Tage, das ist ein bischen dürftig.
0.3 eiertimer setup 05:00 - 18 mA danach power down - 9 µA
Ist es eventuell nur Dein Messgerät, welches mit seiner Messung nicht tiefer kommt?
Nö, Messgerät ist Agilent 1242A, das kann uA. Ich werd' mal morgen ein anderes Gerät zerlegen und dort messen, vielleicht hab' ich beim Ausbauen vom dem fetten Atmel irgendwas kaputt gemacht.
Datenblätter: SSD1325 - 5 µA ATmega168P PWRDWN ohne WDT - 2 µA
Vergessen: Stepup 12 V - less than 2 μA Stepup 3.3 - powersave 30 µA
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 alles leer, ausgeweidet, das gute Teil. 2. Gerätchen hab' ich grad' ausgeschlachtet (ist ja schon morgen :-). Zieht mit Originalsoftware 11uA. Also entweder ist was faul beim 1. Gerät oder es fehlt etwas essentielles beim Schlafmodus, was ich eher vermute. Kann bitte jemand ein funktionierendes Codefragment für den Schlafmodus posten, das alles abschaltet, was es so gibt?
Hoppala, schau schau: Originalsoftware auf 2. Gerät: 11uA mit meinem Codefragment von oben: 28uA Eieruhr: 28uA Beim Gerät habe ich vor dem Messen den fetten Atmel entfernt. Die Fuses wurden nicht geändert. 2 Geräte, eines zieht um 2 mA mehr als das andere. Na ja ... Bleibt noch die Preisfrage, warum die Originalsoftware 60% weniger Strom frisst. Was ist es fehlt? Ist es jenes Ding, das abgeschaltet wird, ident mit jenem Ding im 1. Gerät, das 2mA frisst? Irgendeine Idee?
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).
Ich vergaß, PRR=255 ist natürlich im Code drinnen. Ohne Display sind's noch immer 1.977 mA. mit Display sind's 1.984mA, Differenz 7uA.
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...
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
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.
Der IC8 der grad vor mir liegt hat als Aufdruck ZMD G1 C1376200 1216 0842 U2720SG
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.
Der Schaltplan der Adapterplatine aus Beitrag "Re: Blutzucker-Messgerät Hardware OLED Display" erweitert um den 3.3 V Schaltregler AS1329 (Schaltungsbeispiel aus Datenblatt), den Entladewiderstand, ATmega168, ISP Header. Meine Phantasie: + OLED an SPI + UART herausgeführt. + Quarz + Drehencoder + Piezo so laut wie möglich (H-Brücke erforderlich?) + Eingangsspannungsüberwachung (Akkus nicht tiefentladen) + 3.3 V Teil durch Lötjumper überbrückbar (wenn nicht bestückt) + ungenutzte Pins an Stiften im 2.54 mm Raster nach rausführen (Huckepack) Dann könnte man's in mehreren Projekten als 'human interface' benutzen (Temperaturregler für Laminator, Timer, Wecker, RS232 interface für Webradio, ..) Der Haken am Phantasieren: Leider ist es für mich nicht mal eben in einer Stunde layoutet. Vielleicht hat jemand Lust, an der Stelle einzusteigen..
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...
Dann nützt dir das nix, ich habe im Prinzip nur die Bauteile in die Schematic reingepackt. Richtig verdrahtet is da noch nix.
@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.
@adriano6: V0.4 funktioniert bei mir gut, allerdings habe ich die inaktiven Segmente dunkler (Stufe 1) eingestellt, da sie mich sonst beim Ablesen zu sehr stören... Gibt es eigentlich schon eine Mega168 Pin-Pad-Zuordnung, damit man mögliche Anschlußdrähte auf Goldpads anlöten kann? @tec: Hast du zur neuen Mobile-Version schon neue Erkenntnisse bezüglich der Nutzung von Display, Controller und RFID-Einheit?? Gruß OLED-Fan
Hallo zusammen, ich hätte da mal eine Frage an die Spezialisten: 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. Vielleicht hat jemand das schon umgesetzt und kann Hinweise geben. Ganz unsinnig ist das Anliegen ja nicht, will man Display und Platine im Original-Gehäuse betreiben. Gruss Fossy
Angehängte Dateien:
-
OLED_102x80_Hochformat.jpg
190 KB
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?
Star Keeper schrieb: >Wodurch entsteht denn eigentlich bei so einem OLED-Display der >Stromverbrauch? Wenn du Stromaufnahme oder Umwandlung meinst, dann doch zum größten Teil durch die Emittierung von Licht - wie bei LEDs auch! >Nimmt der Verbrauch ab, wenn man dunklere Farben, zur >Darstellung, verwendet? klar, also entweder nach einer kurzen Anzeigedauer auf kleine Zeichen ausweichen bzw. dunkle Graustufen verwenden (siehe Segment.c von OLED-Fan), oder das Display ganz abschalten.
Ja so dachte ich mir das auch. Kann nur hier nicht so einfach den Strom messen, sonst hätte ich es schnell ausprobiert. Danke!
kann mir irgendwer sagen wieviele mA der StepUp für 3,3 V liefern kann? meint ihr das reicht für die versorgung von sd ung gps mit? an welche pins würdet ihr eine sd karte klemmen? grüße
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)"
sollte ja reichen ..... dummerweise will mein gps wohl erst ab 5 v aber danke dir
such mal auf deinem receiver, vielleicht findeste da noch ein stepdown, den du umgehen kannst.
hab ich schon ... Navi S-1 ... hab grade den spannungsregler ausgelötet.... leider bricht die spannung vom Blutzuckermessgerät von 3,3 auf 3,0 ein sobald ich die gps maus anschließe und das scheint der maus nicht zu reichen
irgendwer noch nen tipp wie ich dagegen wirken könnte? ich fürchte nur das der einfach zu viel braucht...
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?
Schreibt oben einer: " ~ 55 mA helles Display ~ 14 mA schwarzes Display ~ 10 mA schwarzes Display, 12V ausgeschaltet " " 0.3 eiertimer setup 05:00 - 18 mA danach power down - 9 µA "
hat schon irgendwer ne SD Karte in der kiste laufen ? Portb würde sich denke ich anbieten ..... und dann über soft spi ?
Moin, sehr cooles Projekt, klinke mich hier auch mal ein. Gibt es eigendlich einen Befehl, um das Display im Hochformat zu Beschreiben? Grüße Marco
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.
Hmm... adriaNo6 hat auf seiner Website: http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html die DCF77-Uhr im Hochformat, nur leider ohne Code. Im Datenblatt kann ich leider auch nix brauchbares finden.
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
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 ;)
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.
hmmm vielleicht sollte ich dann nochmal versuchen den gps ans laufen zu bringen
kann mir einer sagen wofür d1 da ist? diese weid warm?! oder obs der transistor danebeb is?!
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 :-)
Ja, ein ganz dickes Danke auch von mir ! Das Originalgerät hat eine "Low Batt" Anzeige, gibt es eine Chance, einen der ADC-Eingänge dazu zu benutzen, wenn so eine Funktion implementieren will ? Oder macht das auch der große Atmel ?
Es muss einen Grund geben, warum die 32-Pin Variante des Mega169 eingebaut ist. Diese unterscheidet sich durch die kleinere 28-Pin Variante durch zwei zusätzliche ADC-Eingänge. Wofür werden diese gebraucht ? AREF liegt nicht nur einfach an VCC, sondern da sind noch Kondensatoren verbaut, das deutet wohl darauf hin, daß der ADC wirklich benutzt wird. Wofür ? An ADC6 ist eine konstante Spannung von 0.7 Volt (100Pinner ausgebaut) zu messen. Vielleicht gibt es irgendeinen Trick, wie man an die Batteriespannung kommt ? Evtl mit eingeschalteten 3.2 Volt ?
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.
D.h. der Schaltregler schaltet im deaktivierten Zustand die Batteriespannung durch? Gab's nicht auch die Möglichkeit, den ADC Mux auf VCC und interne Bandgap zu schalten? - damit lässt sich VCC auch messen (mit ein bisschen Rechnen). adriano hat wieder was neues (aber wieder nicht zum Download ;-): Displaymodul über die serielle Schnittstelle ansteuern http://home.arcor.de/wehrsdorf/Oled-Display-Recycling.html#terminal (Fehlt noch das <.. id="terminal"> auf der Seite ;-)
B. Heller schrieb:
> Hab mir eins geshoppt, mal sehn wies ist :)
Hast Du es schon bekommen und mal das Innenleben angeschaut?
>adriano hat wieder was neues (aber wieder nicht zum Download ;-):
Ich seh da nix.
Aber'n Terminal ist ja keine Kunst.
Was hängt denn an XTAL1 - kann man dort einen externen Quazoszillator anhängen, oder ist der Pin (auch nach dem Ausbau von IC1) anderweitig belegt ?
Wenn ihr so weiter macht habt ihr bald ein OpenSource Zucker Meßgerät. \o/
Angehängte Dateien:
-
Oled-Modul_seriell.jpg
230 KB
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.
Ich sitze grade an einer intelligenten FB für DSLRs. Der interne Oszillator des AVR ist allerdings, wie bekannt, ein "wenig" ungenau, das gilt besonders bei Batteriebetrieb. Ich versuche das durch Messen der Betriebsspannung und Temperatur zumindest ein wenig zu kompensieren, also rein durch Software. Leider komme zu selten dazu, wirlich konkret was dran zu machen. ...macht aber trotzdem viel Spaß. Nebenbei ist übrigens (noch) eine neue 7-Seg Routine angefallen, die werde ich demnächst hier mal reinstellen.
Hi, Baue gerade an einer Interfaceplatine mit ATMega168p, Li-Ion-Charger, 3.3V LDO und einem Step-Up Wandler auf 12V. Da mir das Package des TPS61080 nicht gefällt will ich diesen ersetzen. Mit welchen Strömen muss hier gerechnet werden?
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.
hier mal eine Version. Platine ist kleiner als das Display. Will das Ganze mobil einsetzen. Die meisten Widerstände und Kondensatoren sind 0603 oder größer. Sollte also möglich sein die 0402 vom Gerät zu verwenden. Nei sind auf jeden Fall der Li-Ion Charger und der LDO. Den 32kHz Quarz werde ich vielleicht noch gegen den vom Gerät tauschen. Muss erst schauen ob ich da eine alternative Quelle finde.
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
Hi, Kondensatoren zum Quarz sind jetzt drinnen. Miso, Mosi & Co sind auf SMD Pads am Print, habe diese in dieser Version vergrößert. Ebenfalls habe ich RX und TX rausgeführt. Außerdem hat der 12V DC/DC noch seinen eigen 1uF Kondensator am Eingang bekommen. lg
Hi, für mein kleines Radioprojekt habe ich zusätzlich zu einem normalen LCD gleich mal adrianos serielle Ansteuerung getestet. Beitrag "Re: OLED RDS Radio mit SI4735 + AVR" Klappt prima, damit brauche ich nur noch einen Pin am Controller, statt 7 beim LCD! Im Debugscreen gibt es allerdings noch einen kleinen Bug bei der Anzeige der empfangenen Zeichen im oberen Bereich. ;-) Gruß, OLED-Fan
Hi Tobi, ich würd versuchen es mit 0-Ohm Rs auf ein einseitiges Layout zu bekommen .. und bislang ungenutzte Pins auf Lötpads legen, dass man mit dem Modul auch weiterbasteln kann..
Also ein einseitiges Layout ist für mich nicht intressant, weitere Lötpads habe ich eingefügt. Noch irgendwelche Wünsche?
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.
> 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. Ich habe mir so eine Platine mal gemacht. Das Problem ist bloss das man etwas am Display abfeilen muss wenn der Stecker unter dem Oled ist weil er einen Millimeter zu dick ist wenn man die Platine aufklippsen will. Weil uebrigens soviel Platz auf der Platine ist habe ich gleich 3.3V Versorgung, Pegelkonverter LCV125 und 12V Boost mit draufgemacht. Erlaubt den direkten Anschluss an einen M16C der mit 5V laeuft. Wenn man einen ordentlichen Busabschluss macht dann kann man das Display auch schoen schnell ansprechen. Ich takte da meine Daten fehlerfrei mit 3.3Mhz rein. Hier kann man das ganze mal sehen: http://www.criseis.ruhr.de/oled.jpg http://www.criseis.ruhr.de/oled2.jpg http://www.criseis.ruhr.de/oled3.jpg Wie man sieht ist es mein erstes Muster, also wies noch 1-2 kleine Fehler auf. :-) Olaf
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.
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?
> Allerdings ist dann der eine Kunststoffdorn im Weg. Richtig. Wie man sieht ist bei mir der Platz zum Stecker auch schon knapp. Ich wollte den aber nicht abknipsen weil das einer der beiden Zentrierungen ist welcher fuer die korrekte Position sorgt. > Aufpassen muß man aber auch mit Bauteilen die unter dem Displayrahmen > liegen. Erstens ist hier nur 1mm Platz und das auch nicht überall. Da hatte ich keine Probleme. Ich hab nur bei den Tantal aufpassen muessen. Man muesste den Stecker fuer das Flachbandkabel in einer Version haben welche die Kontakte auf der anderen Seite hat, dann koennte man den Stecker einfach auf die andere Platinenseite verlegen und alles waere kein Problem mehr. Aber ich will ja keine Serienproduktion aufziehen. Fuer meine vier Oleds ist das okay wenn ich da ein kleines bisschen dran rumschnitzen muss. Olaf
Angehängte Dateien:
-
oled_txt.jpg
160 KB
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
Da LEDs ein etwas breiteres Spektrum abstrahlen als z.B. Laser sollte durch eine rote Folie schon noch etwas zu sehen sein... wenn auch wenig. 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 ;).
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 ;-)
Angehängte Dateien:
-
IMG_0742.JPG
43 KB
@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
Angehängte Dateien:
-
OLED_GPS_Anwendung1.jpg
110 KB
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
Hat schonmal jemand das Accucheck mobile ohne brutale Gewalt aufbekommen?
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 */
|
11 | static const unsigned char chrsmall[] PROGMEM = { |
12 | 0x01, // Bits per pixel : 1, Orientation: horizontal, not mirrored |
13 | 0x00, // lowest ASCII code : 0 |
14 | 0x7f, // highest ASCII code: 127 |
15 | 0x0a, // character height : 10 |
16 | |
17 | /* Character width table */
|
18 | 0x06,0xa0,0x02, // ASCII: 32, width: 6, offset: 672 |
19 | // viele viele Bytes...
|
20 | 0x00 // row 9 |
21 | };
|
22 | /*** END OF FONT DATA ***/
|
23 | #endif
|
In den diversen C Files binde ich diese nun via include ein und weise sie je nach Bedarf einer Pointervariable zu:
1 | #include "oled.h" |
2 | #include "numbers.h" |
3 | #include "chrbig.h" |
4 | #include "chrsmall.h" |
5 | #include "gui.h" |
6 | |
7 | const uint8 *font; |
8 | |
9 | void tolle_funktion(void) |
10 | {
|
11 | font=chrsmall; |
12 | }
|
Solange ich diese Zuweisungen nur in einem C-File mache ist alles gut, auch wenn ich die Zuweisung zigmal drin habe. Wenn ich das aber in mehreren C-Files tue, wird je C-File einmal der Font eingebunden. Wieso dies? Die globale font-Variable ist übrigens nur in einem File definiert und in allen anderen via extern referenziert. Ein Versuch war nun die Fonts nicht als Includefile einzubinden sondern als eigenständiges C-File. Dann optimiert der AVRgcc sie aber ganz weg (ich habe sie dann natürlich ins Makefile mit aufgenommen) und meckert bei jeder Referenz, daß diese nicht erfüllbar ist. Was nun? Bis denn Thorsten
1 | #ifndef CHRSMALL_H
|
2 | #define CHRSMALL_H
|
Solche eine Header-Falle bringt nichts bei mehreren C-Dateien. Die werden immer getrennt voneinander in Objektfiles übersetzt. Jedes Objektfile enthält also die Fonts. Das o.g. ifndef bringt nur etwas, wenn die Fonts über mehrere Header-Files eingebunden werden können. In diesem Fall verhindert dies die Mehrfacheinbindung in einem Objektfile.
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
@ Thorsten: gedenkst du uns an Deiner Library teilhaben zu lassen ? Wäre SEHR interessiert. Gruß: Andi
> 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
M. G. schrieb: > 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... Dir ist bewußt, daß beim 2561 die ISP pins nicht mit den SPI pins identisch sind? SPI liegt auf PB1-PB3, für die serielle Programmierung werden aber PB1, PE0 und PE1 verwendet. (Siehe Tabelle 30-15 im Datenblatt).
Hi, sieht jemand eine Möglichkeit die IRDA-Schnittstelle nutzbar zu machen? Ich stelle mir einen Trick wie den beim Buzzer vor. Ich habe schon versucht einfach mal durchzumessen ob ein Via irgendwo in der beim Mega168 mit den IRDA-Leitungen wieder auftaucht. Das ist aber zu klein für mich.
Karl Kloss schrieb: > M. G. schrieb: >> 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... > > Dir ist bewußt, daß beim 2561 die ISP pins nicht mit den SPI pins > identisch sind? > SPI liegt auf PB1-PB3, für die serielle Programmierung werden aber > PB1, PE0 und PE1 verwendet. (Siehe Tabelle 30-15 im Datenblatt). Ja, ist mir bewusst, dass man RxD und TxD nehmen muss statt MOSI und MISO. Leider hatte ich trotzdem keinen Erfolg.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.