mikrocontroller.net

Forum: Projekte & Code (sehr) kleines "FrameWork" für ATtiny44


Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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)

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
@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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Code Betrachter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier kannst du dir anschauen, wie man sowas machen kann:

https://github.com/HarryLipphaus/OledLib/tree/master/Src

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"
/* Grafik-Font "Helvetica Bold" 12 Pixels */
const char Helvetica_Bold_12[] = {
/* HCap Height Ascent Descnt Min  Max */
      8,   12,   10,    2,   31,  127, 
/* OffHi OffLo DeltaX DeltaY */
      1,  138,    6,   12,   /* CH_1F         "nix"  cnt= 9 ab   394*/
      1,  147,    3,   12,   /* CH_20       "space"  cnt= 5 ab   403*/
      1,  152,    4,   12,   /* CH_21      "exclam"  cnt= 6 ab   408*/
      1,  158,    5,   12,   /* CH_22    "quotedbl"  cnt= 8 ab   414*/
      1,  166,    6,   12,   /* CH_23  "numbersign"  cnt= 9 ab   422*/
      1,  175,    6,   12,   /* CH_24      "dollar"  cnt= 9 ab   431*/
... und so weiter.

und hier die "Helvetica_Bold_12.h"
#ifndef HELV12BINCLUDED
#define HELV12BINCLUDED
extern const char Helvetica_Bold_12[];
#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.

Autor: Code Betrachter (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
... 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...

Autor: Johannes S. (jojos)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
.. vor lauter Schreiben hab ich doch prompt die Software nicht 
mitangefügt. Ist hier im Anhang.

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;)

Autor: Ralph S. (jjflash)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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).

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
... 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)

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
... 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)

Autor: M. K. (sylaina)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nenn das immer User-Library denn IMO ist es das auch.

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
... 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:

Youtube-Video "RDA5807_ATtiny44"

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

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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:

Youtube-Video "ATtiny44 mit HC-SR04 Ultraschallentfernungssensor"

Autor: Thomas N. (tonevi)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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)

Autor: Thomas N. (tonevi)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
... 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ß

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... vergessen die ZIP-Datei anzuhängen :-(

Autor: Ralph S. (jjflash)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.