In einem Thread ging es darum, welcher Controller für die (beliebten?) 0,96" OLED Display mit 128x64 Pixeln. Aus der Diskussion heraus wurden naaaatürlich wieder alle möglichen Controller, Szenarien etc. genannt (und ich hab mich - eigentlich wollte ich ja gar nicht - auch beteiligt und den ATtiny44 genannt). Normalerweise würde ich sagen, dass die Tiny-Serie aufgrund vieler Einschränkungen nicht so wirklich Einsteigerfreundlich sind, aber ich habe mich mal hingesetzt und einiges von meinen Sachen für den Tiny44 extrahiert. Ich bin noch lange nicht fertig, aber das was ich habe mag ich hier mal zur Verfügung stellen. Es ist ein Archiv, das einige Demoprogramme beinhaltet. Jedes ist ein "Makefile-Projekt" sodaß ein "make" die Hex-Datei erzeugt. Jedes dieser Makefiles inkludiert eine Datei namens "makefile.mk", die die eigentliche Arbeit übernimmt. Im jeweiligen Makefile des Projekts können Anpassungen (vor allen Dingen bzgl. des Flashprogrammers) vorgenommen werden. Die Namen dort dürften selbst erklärend sein. Umgesetzt für den ATtiny44 sind bis jetzt: - ein "abgespecktes" printf (ohne Float) Unterstützung aber dafür mit neuem Festkommaformater %k - Software für OLED-Display mit SSD1306 Controller, jeweils für I2C und SPI Interface - Software für N5110 Display 84x48 mit SPI-Interface - Softwarerealisiertes I2C - SPI ist in den Displayheadern zwischen Softwarebasieren oder Hardware umschaltbar (USI) - ADC - PWM - serielle Schnittstelle mit 19200 Baud (bei 8 MHz intern) USI basierend - einfacher Tönegenerator mit Timerinterrupt realisiert und einfachem Notenparser (Demodatei spielt den Schneewalzer ab) - 4-stellige 7-Segmentanzeige (mit Software für den TM1637 Treiberchip = China Anzeigemodul) - einfacher I2C Busscaner (der die belegten I2C Adressen auf der seriellen Schnittstelle ausgibt)
Angehängte Dateien:
-
tiny44_with_oled.jpg
130 KB -
anzeigen.jpg
59 KB
Ich halte dein Projekt für etwas weniger sinnvoll. Bei einem µC mit 2 oder 4 K an Flash und 128 oder 256 Byte an RAM würde ich eher Abstand nehmen vom Anschluß grafischer Displays und allenfalls ein normales Alpha-Display vorsehen. Es ist ja nicht Sinn der Übung, es irgendwie hinzubekommen, daß man auf einem 128x64 Display etwas in 8x8 oder 16x16 Char's hinschreiben kann, sondern es muß daneben auch noch genug Platz für eine eigentliche Anwendung sein, die sowas dann sinnvoll nutzen kann. Nächstes: einen Ersatz für printf in so einem kleinen µC machen zu wollen, ist ebenfalls weniger sinnvoll. Das frißt dir nur den Flash auf. Mach es deshalb besser einzeln: - Char-Ausgabe - Stringausgabe - byte zu Hex Ausgabe - int zu Hex Ausgabe - int zu Dezimalausgabe Wenn du die dafür nötigen Funktionen schön separat hältst, ohne daß alles durch ein printf immer belegt ist (der Compiler kann ja nicht ahnen, was du später in die Formatstrings schreiben willst), dann kann der Linker ggf. unbenutzte Funktionen weglassen, was dir den Platz für die eigentliche Anwendung besser frei hält. W.S.
Ralph S. (jjflash) >Normalerweise würde ich sagen, dass die Tiny-Serie aufgrund vieler >Einschränkungen nicht so wirklich Einsteigerfreundlich sind, aber ich >habe mich mal hingesetzt und einiges von meinen Sachen für den Tiny44 >extrahiert. Ich mag kleine Mikrocontroller und finde es gut, wenn jemand versucht, etwas minimllistisch umzusetzten. Insofern: Daumen hoch für Dein Projekt.
@W.S prinzipiell geb ich dir recht (mit printf)... das ganze belegt 698 Bytes im Flash... allerdings sind die Funktionen due printf benötigt alle für sich aufrufbar, die Software für die Displays haben nur ein putchar und ein gotoxy... Ausgaben kann man sich machen wie man mag... und mag man nur eine Integerausgabe haben kann man sich das aus printf kopieren. Ich sehe das hier nicht mal als Projekt, es ging darum, dass jemand danach gefragt hat das Display daran anzuschließen. Grundsätzlich macht so ein Display dann Sinn, wenn das Gerät sehr klein werden soll, auch wenn nur Text ausgegeben werden soll. Im übrigen ist das so abgespeckt, dass auslesen des ADC, umrechnen in Spannungswert und anzeige auf Display jetzt 2900 Byte belegt (da ist dann auch I2C implementiert). Auf dem N5510 ist es aufgrund des kleineren Fonts noch weniger. Das hier ist für diejenigen gedacht, die sich ihre Programme eben zusammen kopieren und sich auf ihr eigentliches Problem konzentrieren und sich (irgendwie nicht richtig) nicht so sehr mit der Peripherie auseinander setzen wollen. Nächste Woche werde ich das wohl um I2C Devices für Portexpander, Temperatursensor (LM75) und RTC erweitern. Serielles Schieberegister 74LS595, den Ultraschall Abstandssensor und eine grundsätzliche Auswertung für NTC. Smile, Charlieplexing mit 20 LEDs funktioniert hier auch schon. Es dreht sich also nicht darum das hier am Stück zu verwenden, sondern darum, eventuell das benötigte heraus zu kopieren.
Ich habs mir mal angeschaut und versucht auf meinen Attiny85 zu portieren aber irgendwie bin ich hier zu blöd für...und ich bin bei meiner Lib hängen geblieben und hab da die putc-funktion umgeschrieben. Ich lass mich einfach zu leicht ablenken, dennoch danke an Ralph. Ich finde das schon sehr interessant.
Ralph S. schrieb: > t44_framework.zip Das ist sie wieder, diese Unart Variablen/Datensätze in Header-Dateien zu packen. Bitte jetzt keine Begründung weil es ein Tiny ist muss man das so machen. SCNR
Code Betrachter schrieb: > Das ist sie wieder, diese Unart Variablen/Datensätze in > Header-Dateien zu packen. Wieso "Unart"? Ist was ist denn daran verwerflich den Font ins Headerfile zu schmeißen?
M. K. schrieb: > Wieso "Unart"? Ist was ist denn daran verwerflich den Font ins > Headerfile zu schmeißen? So kann man den Font 2mal (in2 versch. C-Files) includen, und dem Linker den Magen verderben. Wenn du schon den Font in eine separate Datei auslagerst, solltest du die nicht .h, sondern z.B. .fnt nennen.
Harry L. schrieb: > M. K. schrieb: >> Wieso "Unart"? Ist was ist denn daran verwerflich den Font ins >> Headerfile zu schmeißen? > > So kann man den Font 2mal (in2 versch. C-Files) includen, und dem Linker > den Magen verderben. > Wenn du schon den Font in eine separate Datei auslagerst, solltest du > die nicht .h, sondern z.B. .fnt nennen. beispiel.c -> #define BEISPIEL_C beispiel.h -> #ifndef BEISPIEL_H #define BEISPIEL_H ... #ifdef BEISPIEL_C #define GLOBAL #else #define GLOBAL extern #endif ... //global vars #undef GLOBAL ... #endif
:
Bearbeitet durch User
Marcus H. schrieb: > font.h -> > > #ifndef FONT_H > #define FONT_H > ... > #ifdef FONT_C > #define GLOBAL > #else > #define GLOBAL extern > #endif > ... //global vars > #undef GLOBAL > ... > #endif Ja und? Ich kann das trotzdem in file1.c UND in file2.c includen, und schon meckert der Linker.
Marcus H. schrieb: > Harry L. schrieb: >> M. K. schrieb: >>> Wieso "Unart"? Ist was ist denn daran verwerflich den Font ins >>> Headerfile zu schmeißen? >> >> So kann man den Font 2mal (in2 versch. C-Files) includen, und dem Linker >> den Magen verderben. >> Wenn du schon den Font in eine separate Datei auslagerst, solltest du >> die nicht .h, sondern z.B. .fnt nennen. > Mir ist ein copy-paste-Fehler passiert. So war das gemeint: main.c -> #define MAIN_C beispiel.h -> #ifndef BEISPIEL_H #define BEISPIEL_H ... #ifdef MAIN_C #define GLOBAL #else #define GLOBAL extern #endif ... //global vars #undef GLOBAL ... #endif
:
Bearbeitet durch User
Marcus H. schrieb: > Mir ist ein copy-paste-Fehler passiert. So war das gemeint: > > #ifndef BEISPIEL_H > #define BEISPIEL_H > ... > #ifdef MAIN_C > #define GLOBAL > #else > #define GLOBAL extern > #endif > ... //global vars > #undef GLOBAL > ... > #endif Und was soll das bringen? Sorry, aber sowas ist einfach nur Pfusch.
:
Bearbeitet durch User
Hier kannst du dir anschauen, wie man sowas machen kann: https://github.com/HarryLipphaus/OledLib/tree/master/Src
M. K. schrieb: > Wieso "Unart"? Ist was ist denn daran verwerflich den Font ins > Headerfile zu schmeißen? Weil auch ein Font in der Firmware aus KONSTANTEN Daten besteht und folglich ein Teil des Hex- oder Binfiles wird, genau so wie eben auch die konstanten Daten, aus denen der Maschinencode besteht. Also gehört er in eine .c Datei und wird separat übersetzt und zur Objektdatei gemacht. Alternativ kann man ihn als .inc in eine C-Datei inkludieren, womit er ja auch in die .c kommt. In einer Headerdatei haben solche Dinge rein GARNICHTS verloren. Dort muß nur das hinein, was man aus der zugehörigen .c Datei zu exportieren wünscht. Also die Typdeklarationen von structs oder die Prototypen von Funktionen oder Konstanten, die per #define gemacht werden und dergleichen. Ich geb hie rmal ein Beispiel: zuerst die "Helvetica_Bold_12.c"
1 | /* Grafik-Font "Helvetica Bold" 12 Pixels */
|
2 | const char Helvetica_Bold_12[] = { |
3 | /* HCap Height Ascent Descnt Min Max */
|
4 | 8, 12, 10, 2, 31, 127, |
5 | /* OffHi OffLo DeltaX DeltaY */
|
6 | 1, 138, 6, 12, /* CH_1F "nix" cnt= 9 ab 394*/ |
7 | 1, 147, 3, 12, /* CH_20 "space" cnt= 5 ab 403*/ |
8 | 1, 152, 4, 12, /* CH_21 "exclam" cnt= 6 ab 408*/ |
9 | 1, 158, 5, 12, /* CH_22 "quotedbl" cnt= 8 ab 414*/ |
10 | 1, 166, 6, 12, /* CH_23 "numbersign" cnt= 9 ab 422*/ |
11 | 1, 175, 6, 12, /* CH_24 "dollar" cnt= 9 ab 431*/ |
12 | ... und so weiter. |
und hier die "Helvetica_Bold_12.h"
1 | #ifndef HELV12BINCLUDED
|
2 | #define HELV12BINCLUDED
|
3 | extern const char Helvetica_Bold_12[]; |
4 | #endif
|
Ralph S. schrieb: > allerdings sind die Funktionen due printf benötigt alle für > sich aufrufbar Du hast meinen Einwurf nicht verstanden. Also: Wenn du ein printf schreibst, was auf diverse Sub-Funktionen wie CharOut(),StringOut(),HexOutByte(),IntOutByte(),HexOutInt(), und so weiter zurückgreift, dann sind ALLE DIESE Funktionen für den Compiler in Benutzung, sobald du auch nur ein einziges Mal in deiner ganzen Firmware printf benutzt - egal ob du von all diesen Subfunktionen auch nur eine davon tatsächlich benutzt oder nicht. Folglich kann der Compiler all die in einem konkreten Projekt unbenutzten Subfunktionen eben NICHT weglassen und daher lungern sie in der Firmware als toter Code herum. Wenn du Flash bis zum abwinken hättest, wäre das egal, aber hier ist das eben nicht egal. Ralph S. schrieb: > Das hier ist für diejenigen gedacht, die sich ihre Programme eben > zusammen kopieren und sich auf ihr eigentliches Problem konzentrieren > und sich (irgendwie nicht richtig) nicht so sehr mit der Peripherie > auseinander setzen wollen. Das ist typisch: Gut gemeint ist eben fast immer das Gegenteil von gut gemacht. Ich habe in deinem Paket kein System sehen können. Du hast ne Menge Demos, aber kein wirkliches Gerüst für jemanden, der das tun will, was du angesprochen hast. Such hier mal nach einem Anhang "STM32F103C8T6.ZIP". Das ist von mir und es ist ein lauffähiges Minimal-Projekt, was mir und anderen tatsächlich ermöglicht, sich auf ein eigentliches Problem zu konzentrieren. Und warum? Weil dieses Minimalsystem bereits eine funktionable Infrastruktur bietet: Lowlevel-Treiber für diverse Kanäle einschließlich USB-VCP und Hilevel-Teile für Uhrzeit, Events, E/A-Konvertierungen, ein leicht erweiterbares Kommandoprogramm und ein weitgehend optimiertes Konfigurationsprogramm für die Basis-Peripherie, also Pins, Power und Takt. Nochwas: Normalerweise sollte man gerade bei grafischen Displays gut trennen zwischen der logischen Ebene, wo man Funktionen hat wie Pixel setzen, Linien zeichnen, Flächen füllen, Text in diversen Fonts zeichnen und so weiter - und der physischen Ebene, wo dafür gesorgt wird, daß das Display richtig aufgesetzt wird und der Bildinhalt nach Änderungen ins Display gelangt. Das fehlt bei dir - aber den Grund sehe ich durchaus: Du hast in so einem kleinen µC keine Chance, dir einen ausreichend großen Bildspeicher-RAM zu reservieren. Ich kenne das, ich hatte vor langem aus Übermut auch mal ein ALPS-LSU (96x32) mittels eines PIC16F871 angesteuert - eigentlich nur, um zu sehen, ob das überhaupt geht. Aber für's Praktische ist das alles Mumpitz. Man sollte so kleine µC wirklich nicht mit grafischen Displays belästigen. W.S.
Gut gesprochen, W.S. Meinen ausdrücklichen Dank dafür. Ich bin zu faul mir die Finger für so etwas wund zu schreiben. M. K. schrieb: > Wieso "Unart"? Ist was ist denn daran verwerflich den Font ins > Headerfile zu schmeißen? Allein die Fragestellung lässt Bände sprechen über das Chaos das manche Programmierer in sich tragen. W.S. schrieb: > Normalerweise sollte man gerade bei grafischen Displays gut > trennen zwischen der logischen Ebene, wo man Funktionen hat wie Pixel > setzen, Linien zeichnen, Flächen füllen, Text in diversen Fonts zeichnen > und so weiter - und der physischen Ebene, wo dafür gesorgt wird, daß das > Display richtig aufgesetzt wird und der Bildinhalt nach Änderungen ins > Display gelangt. Auch dafür meine ausdrückliche Zustimmung. Wärend man bei C++ und Objekt-/Klassenprogrammierung praktisch dazu gezwungen wird sollte man sich eine ähnliche Hierarchie-Struktur auch ausserhalb von OOP zu eigen machen.
... hm, jetzt hab ich alles zig mal gelesen... und bin hin und her gerissen. Was Sinn macht, was nicht... und unterm Strich wurde nix falsches geschrieben... auch wenn ich manche wenige Dinge anderst sehe... Hm... Displays und ATtiny... ob man das wirklich lassen muss...
Die Arbeit finde ich schon gut, wenn man dann etwas braucht und dann schnell aus seinem Pool von Funktionen zusammenstoppeln kann erfüllt es ja seinen Zweck. Ich habe mich nur frühzeitig auf die Cortex-M umorientiert (als hier noch ständig lamentiert wurde, braucht man nicht, geht auch mit AVR). Da ist ein kleiner M0 mechanisch auch nicht viel größer wenn ich TSSOP20 nehme. Bekomme ich auf selbstgeätzte Platinen oder DIP Adapter fürs Steckbrett und ist damit basteltauglich. Dafür habe ich beim LPC824 zB 32 kB Flash und 8 kB RAM und viel brauchbare Peripherie. Da sind die Limits schon deutlich höher und kleine Displays können auch besser genutzt werden. Und nach oben hin haben die M3/M4 Familien viel mehr Luft mit den gleichen Tools.
Harry L. schrieb: > So kann man den Font 2mal (in2 versch. C-Files) includen, und dem Linker > den Magen verderben. Öhm, ist doch prima wenn der Linker meckert. Wäre schon irgendwie doof wenn er es hinnehmen würde. Code Betrachter schrieb: > Allein die Fragestellung lässt Bände sprechen über das Chaos das > manche Programmierer in sich tragen. Und wie sollen wir Unwissenden es besser machen wenn die Wissenden der Meinung sind Code Betrachter schrieb: > Ich bin zu faul mir die Finger für so etwas wund zu schreiben. ? So eine Einstellung sorgt doch nur dafür, dass wir Unwissenden es weiterhin falsch machen werden während die Wissenden sich weiterhin darüber aufregen. So wird sich an der Situation nichts ändern.
Na ja... W.S hat ja schon recht: Code gehört schon in die .c Datei... Nur ist war mir die Länge des Fonts zu lang so dass mir der Code nicht leserlich war. Normalerweise geh ich her und hab den tatsächlich in einer Datei namens .fnt und den mittels #include in .c eingebunden... Das hat aber auch schon mecker gegeben. Hm, außerdem sollte es ja nicht nur um Displays gehen... @johannes: normalerweise nehm ich, wenn es klein werden soll einen STM32F030... Ist Strom sparen angesagt einen L053 und für Dinge mit Rechenleistung einen F411... Bei Displays, wie es W.S. beschreibt, bin ich nicht gsnz seiner Meinung, weil ein getrenntes Aufsetzen des Displays zu Userfunktionen (so wie er es beschteibt) immer einen Framrbuffer benötigt. Würde ich das bei graphischen Farbdisplays so machen (480x320) braucht das für Controllerverhältnisse Unmengen an RAM
Ralph S. schrieb: > Na ja... W.S hat ja schon recht: Dagegen hab ich auch nix, seine Erklärung fand ich auch super und habs bei mir auch gleich entsprechend umgesetzt. Ich finde es nur nicht so schön wenn erst groß gemeckert wird und auf nachfragen dann teilweise solche Antworten wie hier kommen.
Ralph S. schrieb: > Bei Displays, wie es W.S. beschreibt, bin ich nicht gsnz seiner Meinung, > weil ein getrenntes Aufsetzen des Displays zu Userfunktionen (so wie er > es beschteibt) immer einen Framrbuffer benötigt. Ich denke, er meinte hier so Displays wie eben diese kleinen OLED-Displays wie hier beschrieben und da macht das auch meiner Meinung nach Sinn...sofern man den Speicher dazu auch hat. In der Tat machen das viel Libraries für SSD1306/SH1106 Displays, dass sie einen Buffer benutzten. Ich hab für diese Displays ja auch nur einen Lib geschrieben (vor über 1 1/2 Jahren) weil ich so ein Display (lediglich Text) an einem Atmega48 benutzen wollte und da hat man halt nicht genügend Speicher.
Ralph S. schrieb: > Hm... Displays und ATtiny... ob man das wirklich lassen muss... Drück dich präziser aus! Also: Alpha-Displays im 4 Bit Modus und kleine µC geht völlig in Ordnung. Hab selber schon kleine Digitalthermometer und Frequenzzähler mit sowas wie PIC16F716 und den mittlerweile ausverkauften 2x8 Char Dispays von Pollin gebaut und die funktionieren prächtig. Allerdings hab ich die in Assembler programmiert. Das was nicht in Ordnung geht, sind grafische Displays an kleinen µC, weil man dort an den zu kleinen Ressourcen schwer leidet - und wenn man es mit Krampf dennoch irgendwie hinbekommt, dann ist für die eigentliche Anwendung kein Platz mehr. M. K. schrieb: > Und wie sollen wir Unwissenden es besser machen wenn die Wissenden der > Meinung sind.. ..daß sie für längliche Erklärungen nicht geschätzt, sondern oftmals nur angemotzt werden? Ich sag dir die Lösung: selber nachdenken. JAJAJA.. ich weiß, daß das logische Schlußfolgern beim Erlernen von C fast nie hilfreich ist, weil die Sprache an sich quasi diktatorisch aufgebaut ist ("das ist hier eben so, basta!") und man mit Logik nicht wirklich weiter kommt. Trotzdem, selber denken tut wohl immer not. Also denkt an die Trennung von Zeugs, was wirklich hardwareabhängig ist und anderem Zeugs, was eben nicht wirklich hardwareabhängig ist und teilt eure Firmware entsprechend auf. Das hilft am meisten. W.S.
W.S. schrieb: > M. K. schrieb: >> Und wie sollen wir Unwissenden es besser machen wenn die Wissenden der >> Meinung sind.. > > ..daß sie für längliche Erklärungen nicht geschätzt, sondern oftmals nur > angemotzt werden? Längliche Erklärungen werden eigentlich immer geschätzt. Dass die Wissenden angemotz werden kommt idR immer nur daher, dass sie keine ausreichende Erklärungen geben, häufig sagen sie nur "das kann man viel besser machen" verraten aber nicht wie bzw. wenn man nachfragt als Unwissender kommt dann meist nur ein W.S. schrieb: > Ich sag dir die Lösung: selber nachdenken. Und genau so etwas ist schlicht überhaupt nicht hilfreich, ganz besonders für den, der nachgefragt hat. So etwas wird eher das Gegenteil bewirken und der Unwissende wird vom Wissenden nur denken "Was ist denn das für ein Quatschkopp?" Bevor der Wissende also so etwas schreibt empfehle ich dem Wissenden besser nichts zu schreiben, das ist für alle Seiten, Unwissenden, Wissenden und Mitleser, die beste Lösung.
M. K. schrieb: > Und genau so etwas ist schlicht überhaupt nicht hilfreich, ganz > besonders für den, der nachgefragt hat. So etwas wird eher das Gegenteil > bewirken.. Nein, es wird nur - wie man so schön sagt - die Spreu vom Weizen trennen. Was meinst du, wo wir alle steckengeblieben wären, wenn die Leute angesichts eines nichgewußten Sachverhaltes die Flinte ins Korn geworfen hätten und nicht angefangen hätten, selber nachzudenken? Es ist schlichtweg unmöglich, für alles, was man nicht selber weiß, irgend jemanden fragen zu wollen. Wen hätte Einstein denn fragen sollen auf der Suche nach der richtigen Relativität-Theorie? Etwa den lieben Gott? Nee, auf den Hintern setzen und die grauen Zellen warmlaufen lassen. So geht das. W.S.
W.S. schrieb: > Es ist schlichtweg unmöglich, für alles, was man nicht selber weiß, > irgend jemanden fragen zu wollen. Darum gehts ja nicht, es geht ja um so Aussagen wie Code Betrachter schrieb: > Das ist sie wieder, diese Unart Variablen/Datensätze in > Header-Dateien zu packen. Und da fragt man dann mal nach warum und bekommt als Antwort Code Betrachter schrieb: > Allein die Fragestellung lässt Bände sprechen über das Chaos das > manche Programmierer in sich tragen. Und das ist einfach unschön, das sorgt nur für Frust auf allen Seiten. Du hast dir ja die Mühe gemacht es ausführlich zu erklären und dafür nochmal ausdrücklich danke. So ein Verhalten hilft allen ;)
Angehängte Dateien:
-
t44_with_txlcd_kl.jpg
170 KB -
t44_with_tft_kl.jpg
260 KB
Hätte ich gewußt, dass das hier ein Faß aufmacht, ich hätte das wohl
nicht eingestellt, aber ich hab jetzt angefangen und jetzt muß ich da
durch.
@sylaina:
Du bist doch lange genug hier und weißt dass der Ton bisweilen "rüder"
wird, und?
Auch muß man nicht zwingend immer einer Meinung mit jemandem sein der
ausgewiesenerweise gut (und vllt. besser als man selbst ist)?
Diskussion und debattieren ist wichtig um sich selbst auch wieder mal zu
hinterfragen.
Zuuuuuum Beispiel:
Ich WEISS dass Code definitiv nicht in den Header soll (mache das für
mich aber dennoch, wenn ich genau weiß, das wird nur einmal aufgerufen.
Das ist wie Rauchen, das sollte man auch nicht tun ... macht es aber).
W.S. hat mich zum Nachdenken gebracht und von daher hätte ich jetzt
glatt etwas um ihn zu necken (was zumindest von meiner Seite nicht böse
gemeint ist).
Erstens:
Die Fontdateien sind tatsächlich in eine eigene Sourcedatei gewandert
die separat zur Objektdatei kompiliert werden kann / muß und
hinzugelinkt werden.
Ich stimme ihm aber nicht zu, dass ein "grafisches" Display zu heftig
für den Tiny ist, weil:
Das Display als reines Textdisplay, im Falle des OLED's mit 16x8 Zeichen
fungiert. Warum? Weil das Ding klein ist und weil das (zumindest aus
China) preiswerter als ein Textdisplay ist. Das gleiche gilt für ein
N5110 Display mit 84x48 Pixeln.
Ich habe mir sehr lange Gedanken darüber gemacht, ob es beim Tiny
sinnvoll ist, 3 Ebenen (Kommunikationsschnittstelle, physische
Schnittstelle (die eben nur eine Schnittstelle hat, die die Daten der
hardwareunabhängigen Funktionen anzeigt) und eben eine die der Benutzer
verwendet (putchar, putpixel etc.)
Im Falle eines Textdisplays gebe es jetzt die Möglichkeit einen, sagen
wir Textframebuffer anzulegen und diesen der pyhsischen Schicht zu
geben. Wäre im Falle des Tiny kontraproduktiv, weil es selbst bei dem
kleinen OLED 128 Byte RAM von den vorhandenen 256 Bytes bedürfte.
Möglich wäre auch, die eine Schnittstelle zur Verfügung zu stellen, die
das Displayram adressiert und einen Stream dazu.
Weil aber hier nur sehr sehr wenige Funktionen vorhanden wären, ist mir
der Overhead, eine weitere Datei hinzuzulinken irgendwie zu
unübersichtlich. So besteht beim I2C Display eben nur die I2C
Schnittstelle und die Software für das Display.
Beim SPI-Interface bin ich noch "böser" und habe das SPI-Interface mit
zum Display hinzugefügt.
Ich weiß dass das der reinen Lehre widerspricht und auf großen Systemen
würde man das so nicht tun.
W.S. ist halt anderer Ansicht / Meinung wie auch immer. Genauso, wie er
eben darauf beharrt, dass am Tiny ein graphisches Display nichts zu
suchen hat. Hat es auch nicht !!! Ich betrachte das als ein Textdisplay
mit User definierbarem Zeichensatz.
Jetzt kommt das Necken:
Ich habs auch noch prompt für ein farbiges TFT-Display gemacht (und
sogar bis zur Auflösung von 320x240 Pixeln gezogen, was dann selbst als
Textdisplay Quatsch ist).
Dann zum Begriff "Framework": Der stimmt wohl nicht so recht, es hätte
wohl besser heißen müssen: "Codesammlung für ATtiny44 (was auch nicht
mehr stimmt, ich habe heute ATtiny84 ausprobiert, es ging alles ohne
Codeänderungen, was auch zu erwarten war).
Also, was hab ich dieser Codesammlung gemacht:
- alle Konstanten aus den Headern entfernt und entweder in die Sourcen
gepackt oder im Falle von Fonts eigene Sourcedateien daraus erstellt.
- Source für 4 stelliges 7-Segmentmodul (China) mit SN74HC595 ...
welches ich nicht sehr mag, weil das eben trotz Schieberegister
gemultiplext werden muß. Hier kann man sehen, wie ein Timerintervall
aufgesetzt wird (Timer0)
- daraus (Abfallprodukt) ein eigenes Demo, welches per 1 mS Intervall
die ISR aufruft, nur um eine 32-Bit Variable hoch zu zählen
- TFT-Farbdisplayanbindung für Displays mit ILI9163 9340 9225,
ST7735R und SD02A1 Controllerchip (das war das necken von W.S.)
- Textdisplays mit HD44780 kompatiblen Controller im 4-Bit Transfer
Dann habe ich mir Gedanken über das printf gemacht... Woher die ewige
Abneigung dagegen stammt weiß ich wirklich nicht. Sie wird von vielen
entweder gehasst oder geliebt.
Mein sehr abgespecktes printf habe ich jetzt satt unter die Lupe
genommen:
Ein Programm, dass den ADC ausließt und diesen Wert in eine Spannung
umrechnet und über den UART ausgibt (nur diesen Wert, keinen Text)
benötigt insgesamt:
mit my_printf : 1324 Byte
mit putint : 988 Byte
Differenz : 336 Byte
Gehe ich davon aus, dass ich zumindest noch "Spannung" oder "Temperatur"
oder was weiß ich ausgeben mag (worauf auch immer), dann wird die
Belastung durch den Formaterscanner des printf noch geringer, sie
beträgt dann noch 189 Byte.
Diese Bytes opfere ich gerne, wird jemandem der Speicher zu knapp, kann
das printf immer noch hinausbefördert werden, nur der Speichergewinn ist
nicht wirklich hoch.
Dafür kann das my_printf auch nicht sooooo richtig viel:
%c: einzelnes Zeichen,
%s: String
%x: NUR 16-Bit hexadezimale Ausgabe
%d: NUR 16-Bit signed int Ausgabe
Einen Längenformater im Stile %.3x gibt es nicht !
Inkompatibel:
%k
==> gibt einen signed Integer aus und eine globale Variable (ich glaube
hier fliegen wieder Steiner) gibt an, an welcher Stelle ein Komma
eingefügt wird. Das hat den Sinn, mit bspw. 100-fach größeren Ganzzahlen
zu rechnen und bei der Ausgabe eben ein Komma (Punkt) zu setzen:
printfkomma= 2;
b= 4312;
printf("Zahl: %k", b); // Ausgabe ist 43.12
Und ich gebe W.S. Recht: vieles ist da schon armamputiert. Mein Chef
meinte aber auch mal bei bestimmten Dingen: Wenn es billiger wird und
trotzdem geht ist alles gut.
Also, werter W.S (und das "werter" meine ich im Sinne von ehrenwert):
Nicht so komplett zuhauen, das ganze Teil ist für copy & paste
gedacht... dafür, ein Verzeichnis zu kapern und um die Demo sein eigenes
Programm drumherum zu stricken...
An die Moderatoren: Sorry wenn ich soviel geschrieben habe.
Morgen füge ich dem ganzen ein Charlieplexing für 20 LED's hinzu und je
nachdem wie die Zeit ist, ein Auswerten von NTC's über Stütztabellen.
.. vor lauter Schreiben hab ich doch prompt die Software nicht mitangefügt. Ist hier im Anhang.
Ralph S. schrieb: > Das Display als reines Textdisplay, im Falle des OLED's mit 16x8 Zeichen > fungiert. Warum? Weil das Ding klein ist und weil das (zumindest aus > China) preiswerter als ein Textdisplay ist. Einen, meiner Meinung nach, ziemlich entscheidenen Punkt hast du noch vergessen: Diese kleinen I2C-Displays brauchen grade mal 2 IOs des µCs, so ein alphanumerisches Display mit HD44780-Kontroller oder ähnliches braucht minimum 7 IOs, das kann an einem Attiny schon eng werden. ;)
M. K. schrieb: > Diese kleinen I2C-Displays brauchen grade mal 2 IOs des µCs, > so ein alphanumerisches Display mit HD44780-Kontroller oder ähnliches > braucht minimum 7 IOs Komm schon, n bisschen Spielerei ist das schon. Ich denke die Displays waren / sind für billige Smartwatches und MP3 Player gewesen die der Chinamann auf ein PCB gehauen hat. Außer für eine Kontrolle innerhalb eines Gerätes um einen Initialisierungsvorgang bei der Inbetriebname zu visualisieren hab ich so ein Teil noch nicht sinnvoll genutzt. Ein alphanumerisches das über einen PCF8574 Extender angspesprochen wurde in einem Gerät hingegen schon (ein alphanumerisches Display braucht im 4 Bit Modus, wenn die CS Leitung permanent aktiv ist 6 I/O Leitungen). Smile, vllt. sollte man mal fragen, welche Projekte unabhängig vom Controller mit den OLEDs bisher realisiert wurden. Fällt mir gerade ein: einer Bluetoothbox mit UKW-Radio hab ich auch so ein Ding spendiert (war privat halt). Freu dich doch einfach daran, dass an deiner "Lib" immer weiter dran werkelst und sie für dich immer besser wird. Aus Erfahrung weiß ich: fertig wird es nie, es fällt einem immer etwas neues ein. Für mich hab ich mir vorgenommen, ein Breakoutspiel auf dem OLED und dem Tiny zum Laufen zu bringen: Gibts schon, gibts in gut, sogar in richtig gut... aber wurstegal ist ob das Sinn macht oder nicht: Es ist eine Spielwiese (so wie andere Computer zocken... zocken "wir" halt mit den Bauteilen).
Ralph S. schrieb: > Komm schon, n bisschen Spielerei ist das schon. Natürlich ist sowas Spielerei. Wenn man sowas im ernsthaften Einsatz braucht greift man höchstwahrscheinlich zu bewährten Systemen. In der Tat hab ich diese Art von Displays bisher auch nur intern in Anlagen verwendet (Anzeige von Initialisierungen oder Zustände, einmal zur Resolver-Anzeige).
Angehängte Dateien:
-
tiny44_ntc_kl.jpg
250 KB -
tiny44_charlie20_kl.jpg
130 KB -
charlieplex20.gif
12 KB
... ich habe die Codesammlung erweitert und im "Paket" ist nun enthalten: - Blinken mit Timer0 Interrupt - Charlieplexing mit 20 LED's (benötigt 5 I/O Leitungen) - Auswertung NTC-Widerstand (mit Lookup Tabellengenerator)
Angehängte Dateien:
-
tiny44_dotmatrix_kl.jpg
130 KB -
tiny44_ir_receiver.jpg
200 KB
... das Framework Codesammlung Demo (oder wie auch immer man das jetzt nennen kann) hat Zuwachs bekommen. Integriert wurde das Ansteuern eines MAX7219 Multiplexchip mit angeschlossener 8x8 LED Dot-Matrix und Software für das Auswerten eines HX1838 IR-Empfängers. By the way: Wie nennt man eigentlich eine .c / .h Kombination korrekt? Für mich nenne ich das immer Softwaremodul, weil ich den Begriff lib oder library nicht nehmen mag, weil das bereits kompilierte Codes aus einer oder mehreren .c / .h Dateien ist, die einem Linker mit -lmysoftware mitgegeben wird (und die Datei dann eben mysoftware.a heißt)
Ich nenn das immer User-Library denn IMO ist es das auch.
Angehängte Dateien:
-
attiny44_rda5807.gif
12 KB -
attiny44_rda5807_kl.jpg
170 KB
... eine weitere "Erweiterung" für den Tiny44 (wollte ich früher und
noch ein paar andere Dinge tun, aber Urlaub und dann keine Zeit):
ATtiny44 und RDA5807 UKW-Modul
Auf EBAY gibt es seit geraumer Zeit extrem Preiswerte "Arduino-Module"
mit RDA5807 und diesen Chip hatte schon einmal an einen STM8 angebunden
gehabt, jetzt also an einem ATtiny44.
An sich, wenn ich evtl. eine Platine entwickle, dann, einfach weil es
schöner ausschaut, mit einem RDA5807 im SOP16 Gehäuse (und ohne Modul)
Im Ordner "rda5807_ukw" gibt es nun 2 .c Dateien. Eine davon ist zum
absoluten Experimentieren mit dem Chip gedacht und kann mit PC über UART
kommunzizieren, die zweite Datei enthält das "Radio" mit Display und
Tastensteuerung wie oben im Foto.
Damit das auf dem Steckbrett "geschickter" ausschaut, wurde ein weiteres
Softwaremodul für I2C OLED Display hinzugefügt, dass die Ausgabe auf dem
Display auf dem Kopf stehend ausgibt: oled1306rot_i2c.c (rot für
rotated).
Im Ordner "fremdproject" sind die Dateien, um aus einem Tiny44 einen
USBtiny AVR-Programmer zu machen (wie der Name sagt: nicht von mir).
Video vom Radio kann man sich hier ansehen:
https://www.youtube.com/watch?v=a72RcWbq9HQ
Erstaunlich, was aus der Kombination von RDA5807 mit minimalistischem
Brückenverstärker HXJ8002 herauskommt...
Wie gesagt, es wird wohl eine Platine gemacht werden als Lötübungen für
Auszubildende.
Wer es nachbauen will, oder mit den Funktionen zum RDA5807
experimentieren mag (vllt. in Kombination mit LED oder
7-Segmentanzeige): Viel Spaß damit
Angehängte Dateien:
-
attiny44_ultraschall.jpg
230 KB
Um nicht jedesmal alles neu in einer ZIP-Datei hier mit hochzuladen, dieses mal "nur" den Quellcode und das Makefile. Einen neuen Ordner im Verzeichnis in dem die ATTiny44 Ordner liegen, anlegen und die beiden Dateien einfügen. ------------------------------------------------ Dieses mal hier: ATTtiny wertet den HC-SR04 Ultraschallentfernungssensor aus. Weil dieser Sensor so wirklich einfach zu handhaben ist, gibt es hierfür keine Paarung aus .c und .h Dateien sondern nur die "Demo". Es benötigt von den anderen Dateien: i2c_sw.c oled1306_i2c.c font8x8h.c toene.c Das Prinzip ist einfach: Ein Startsignal sendet einen Ultraschallton aus und am Ultraschallmikrophone wird solange gewartet, bis dieser Ton wieder ankommt. Je größer die verstrichene Zeit ist, desto weiter ist ein Gegenstand vom Sensor entfernt. Zum Zeitzählen wird hier Timer1 (16-Bit) verwendet. Youtubevideo gibts hier: https://www.youtube.com/watch?v=ouwT-32E3kI
Erst mal großes Lob an Ralf S. für seine Code Bibliothek, die zu eigenen Experimenten anregt. Da ich noch ein paar RDA5807 Module herumliegen hatte, habe ich mal das UKW Radio aufgebaut. Allerdings in einer minimalistischen ATtiny85 Variante. Probleme hatte ich anfangs mit der Tastensteuerung, die nur sporadisch auf Eingaben reagierte. Mit einer Tastenabfrage- und Entprellung per Timer Interrupt funktioniert es nun bestens.
Hey Danke fürs Lob... Die Sache mit den Tasten schau ich mir nochmal an. Hm, hast du den Tiny komplett mit 3,3V laufen (weil ich keinen Spannungsregler sehe)? Mit dem 2_farbigen Display siehts besser aus (hatte ich bisher keines, hab mir aber glatt gleich enes bestellt)
Doch, links unten auf der Platine ist ein 3,3V Regler im TO92 Gehäuse. Anbei mein main Programm mit der modifizierten Tastensteuerung. Ich hatte das Projekt mit AVRStudio 4.17 bearbeitet.
Angehängte Dateien:
-
i2c_to_hd44780_kl.jpg
120 KB -
i2c_to_hd44780_picture.jpg
43 KB
... auf Anfrage einer einzelnen Person: Anbindung von HD44780 komaptiblen Displays mittels I2c. In Ermangelung eines (Arduino)-Moduls wie oben im Bild habe ich dieses diskret aufgebaut, mit der Pinbelegung, die wohl dem käuflichen Modul entspricht (lt. einigen Schaltplaenen im Netz). Sollte jemand ein solches Modul im Betrieb haben (und mit ATtiny44 hantieren) wäre eine Rückmeldung bzgl. funktionieren / Nicht funktionieren ganz nett. ------------------------------------------------------- Dieses "Softwaremodul" hat mich wirklich "geärgert" weil sich dumme Fehler eingeschlichen hatten, aaaaaaber jetzt sollte es funktionieren. Im Anhang befindet sich der Code für das Demoprogramm, den Header und den Sourcecode (zum Ansehen). In der ZIP-Datei sind alle benoetigten Dateien enthalten (inklusive der I2C und my_printf Software). Viel Spaß
Angehängte Dateien:
-
lcd_7segment_b.gif
24 KB -
lcd_7seg_kl.jpg
190 KB -
servo_motor_kl.jpg
130 KB
neu hinzugekommen sind: - DHT11 (Luftfeuchtigkeit und Temperatursensor ... nicht so wirklich gut) - Minispiel "Simon sagt" (aus Nachbarthread) - Ansteuerung zweistelliges 7-Segment LCD (reines LCD ohne Controller) über Schieberegister SN74HC595 - Ansteuerung Servomotor --------------------------------------------------- LC-Displays dürfen im Gegensatz zu LED-Anzeigen NICHT statisch betrieben werden, jedes einzelne LC-Segment benötigt zum Anzeigen eine Wechselspannung! Das ist nicht sooooo ganz so einfach. Das LCD-Softwaremodul bindet über 2 (kaskadierte) Schieberegister ein LCD an. Dieses geschieht mittels Timerinterrupt, der im Wechsel Anzeigesegmente und die Backplane (BP) des Displays negiert: Ist die BP logisch 1, ist das anzuzeigende Segment logisch 0. Ist die BP logisch 0, ist das anzuzeigende Segment logisch 1. Hierdurch entsteht (ähnlich wie bei Brückenschaltungen) eine Wechselspannung am Segment! --------------------------------------------------- Dateien sind in den entsprechenden Ordnern im Archiv zu finden
Angehängte Dateien:
-
tiny44_ds3231_kl.jpg
180 KB -
samsung_20t201_kl.jpg
100 KB
... die Codesammlung / das "Framework" wurde ein (kleines) bisschen erweitert. Hinzugekommen ist: --------------------------------- Software für die billigen 433 MHz Sender / Empfänger: rf433_rx / rf433_tx Bestehen im wesentlichen aus einer per Bitbanging realisierten seriellen Kommunikation im RS232-Protokoll, der beim Versand eines Bytes // Integers // Strings ein Prüfbyte mit angehängt wird --------------------------------- Ansteuerung einzelner Schieberegister: shiftreg Ansteuern der Schieberegister HEF4094 / SN74595. Beschreibung der Anschlüsse sind im Quelltext enthalten ---------------------------------- Auslesen der Realtime-Chips DS1307 / DS3231 rtc_i2c Funktionen zum Lesen und Schreiben der RTC Bausteine DS1307 / DS3231. Beide Chips sind softwarekompatibel und funktionieren mit derselben Software. Von der Verwendung des DS1307 sehe ich mittlerweile jedoch ab, weil er im Vergleich zum DS3231 relativ ungenau geht. ---------------------------------- Ansteuerung des VF-Displays Samsung 20T201DA2 vfd_samsung Oben genanntes Display wird mittels (Bitbanging) SPI angesteuert. Eine Funktion zum Upload eigener Benutzerzeichen (max. 8 sind möglich) ist vorhanden.
Willst du deine Codesammlung nicht mal auf ein git-Repo (github, bitbucket, oä) packen?
... denke ich gerade im Moment drüber nach (weil ich den Code für tm1637 so modifizieren möchte, dass er zum einen auch Funktionen zum Tastenlesen beinhaltet und zum anderen für die Chips tm1651 und tm1687 auch noch funktionieren soll). Hmm, eigentlich dachte ich, dass im Großen und Ganzen nix mehr dazukommt oder geändert wird, dem scheint aber nicht so zu sein.
Ralph S. schrieb: > Hmm, eigentlich dachte ich, dass im Großen und Ganzen nix mehr dazukommt > oder geändert wird, dem scheint aber nicht so zu sein. Das Problem kenn ich ;)
Beitrag #6647373 wurde vom Autor gelöscht.
Angehängte Dateien:
-
attiny_oled64x32_b.jpg
92 KB
Ach herjeh: 3 Jahre ist das her als ich das hier gemacht habe! Für ein kleines Projekt - ich möchte ein Spannungsmessermodul machen, das ich einfach auf ein Steckbrett stecken kann - habe ich mir den ATtiny x4 ausgesucht um das zu bewerkstelligen. Damit das so klein wie möglich wird habe ich ein OLED Display, SSD1306 Controller mit nur 64 x 32 Pixeln ausgesucht. Schwups: meine Routinen für die üblichen OLED Displays mit 128 x 64 Pixeln funktionieren nicht. Das kleine Display benötigt eine andere Initialisierung und eine andere Adressierung im Displayram. Habe ich jezt gelöst und das Ergebnis passt zu "meinem" ATtiny44 Framework. Da ich jetzt aber nicht das gesamte Framework wieder hochladen möchte gibt es den Projektordner mit allen zum Übersetzen benötigten Sourcen. Wer tatsächlich dieses Framework nutzt muß aus dem Zip-File lediglich die Dateien oled_64x32_i2c.c / .h in die entsprechenden Ordner src und include kopieren. Wer es brauchen kann: Viel Spaß damit ! (alle anderen dürfen Spaß beim Lästern haben). Gruß jjflash
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.