Pages: [1] 
|
 |
|
|
Author
|
Topic: grafischer Bootscreen beim mcHF (Read 3016 times)
|
|
HB9ocq
Neuling
 Offline
Posts: 46
OSS: free bugs'n'fixes!
 
|
 |
grafischer Bootscreen beim mcHF
« on: 13. December 2016, 09:17:46 »
|
|
Hallo Stephan,
kannst Du bitte noch was zu make docs sagen.
|
|
hallo Markus,
die Antwort auf diese Frage ist leider nicht so kurz dass sie Forumstauglich waere.
Ich will Dich nicht auf die Schippe nehmen, muss Dich jedoch mit folgendem Vergleich auf die eigentliche Doku von Doxygen verweisen:
Laut Makefile wird ja "nur" gcc aufgerufen,
aber das Know-How steckt wohl in den "*.c" Dateien,
was bedeutet, das die Anzahl der nützlichen
Informationen von dessen Güte abhängt.
Wie erstellt man diese? Gibt es dafür Templates
je nach Programmiersprache oder ist das alles
Handarbeit?
|
|
Ausserdem habe nicht ich den Grundstein fuer "make docs" in mcHF gelegt. Ich habe nur einmalig im Makefile etwas aufgeraeumt und das Logo erstellt.
<https://raw.githubusercontent.com/df8oe/mchf-github/active-devel/mchf-eclipse/mcHF-logo.png>
Am ausbleiben von Reklamationen deute ich dass es gefaellt :->
An die Code-Ritter hier: wuerde dieses Bild sich nicht als Splash-Screen und/oder Hintergrund fuer "about" eignen?
In welchem Format muesste ich es aufbereiten, damit es ins FW-Binary kann?
(ja, ich weiss: Leute mit bloss 0.5MB FLASH wollen nichts davon fuer "Non-Functional-Items" abgeben...)
|
|
 Logged
|
73 de Stephan HB9ocq
|
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #2 on: 13. December 2016, 12:26:22 »
|
|
Hallo,
auch wenn es off-topic ist:
https://de.wikipedia.org/wiki/X_PixMap
ist relativ simpel, wenn man bunte Bildchen direkt in C-Code einbinden möchte und keine libs für PNG/JPG und Co. einbinden will, denn das Bildformat ist als gültige C-Datenstruktur abgebildet.
Wenn Du den Decoder schreibst oder findest und wir ihn und das Bildchen rauswerfen dürfen, wenn es eng wird, why not.
73
Danilo
|
|
Logged
|
|
|
|
|
|
HB9ocq
Neuling
Offline
Posts: 46
OSS: free bugs'n'fixes!
|
|
Re:arm-none-eabi-gcc Code Optimierung mittels Compiler
« Reply #4 on: 13. December 2016, 15:55:44 »
|
|
Wir haben noch 29K frei, bis wir die 512er Marke überschreiten...
Andreas
|
|
ich gucke mir das gerne mal an, so als Denksportaufgabe - lasst euch soweit nicht von der Entwicklung fuer HAM-Funktionen ablenken.
Ich mach dann einen neuen Thread auf, ist ja nicht eigentliche "...-gcc Code Optimierung..."
73 de Stephan
[EDIT:] danke Andreas fuer den separaten Thread, dies ist ein "Nebengleis" unter allen Betrachtungswinkeln :-)
|
| « Last Edit: 13. December 2016, 16:48:36 by HB9ocq » |
Logged
|
73 de Stephan HB9ocq
|
|
|
HB9ocq
Neuling
Offline
Posts: 46
OSS: free bugs'n'fixes!
|
|
Re:grafischer Bootscreen beim mcHF
« Reply #5 on: 13. December 2016, 20:49:21 »
|
|
Naiver erster Versuch - tl;dr: unbrauchbar
$
$ convert mcHF-logo.png mcHF-logo.xpm
$ cp mcHF-logo.xpm mcHF-logo.xpm.c
$
$ gcc -c -o mcHF-logo.xpm.o mcHF-logo.xpm.c # Linux on C2D
$ ls -ld mcHF-logo.xpm.o
-rw-rw-r-- 1 stephans stephans 51776 Dec 13 20:06 mcHF-logo.xpm.o
$
$ arm-none-eabi-gcc -c -o mcHF-logo.o mcHF-logo.xpm.c # just a random ARM-arch...
$ ls -ld mcHF-logo.xpm.o
-rw-rw-r-- 1 stephans stephans 45808 Dec 13 20:08 mcHF-logo.xpm.o
$
|
|
Die Eckdaten des Originalbild sind wie folgt:
$
$ pngcheck mcHF-logo.png
OK: mcHF-logo.png (160x120, 32-bit RGB+alpha, non-interlaced, 84.4%).
$
|
|
Die "Groesse" ist immerhin bereits nur die Haelfte des mcHF-LCDs... :-o
In diesem "default" XPM-Format, werden fuer jedes Pixel 2 chars im C-String eingesetzt
$ grep -A1 pixels mcHF-logo.xpm
/* pixels */
"_ _ [ p.*._ _ _ _ _ _ _ _ _ _ _ <.C.@._ _ _ _ _ _ _ _ _ _ } s.:._ _ _ _ _ _ _ _ "
"_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ .M."
"h.g.h.g.h.h.g.h.h.g.h.h.g.h.g.h.g.h.g.h.h.g.h.h.g.h.h.g.h.h.g.h.h.g.h.h.g.h.g.h."
"g.h.g.h.h.g.h.h.g.h.g.h.g.h.g.h.h.h.M. ._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ",
$
|
|
D.h. dass der C-String um diese 160x120=19200 Pixels * 2 char = 38400 Bytes im FLASH-ROM belegt.
==>> Das geht so nicht, resp. das ist echt Platzverschwendung.
Ich versuche was an den Parameter zur Konversion nach XPM zu schrauben moeglich ist...
Sonst muss ein anderes Format als XPM her.
Nebenschauplatz: wieviele Farben sind im Bild definiert?
$
$ head mcHF-logo.xpm
/* XPM */
static char *mcHF_logo[] = {
/* columns rows colors chars-per-pixel */
"160 120 164 2 ",
" c #000000",
". c #010908",
"X c #150000",
"o c #000016",
"O c #070D15",
"+ c #080B15",
$
$
$ grep -cP '"[^ ]* {1,3}c ' mcHF-logo.xpm
163
$
|
|
Also 163 Farben sind zuviel des Guten, m.M.n. sollten ein paar Handvoll ausreichen
--> cleveres Suchen+Ersetzen oder andere Farbreduktion.
(warum sind in dieser einfachen Grafik so viele Farben? Antialiasing an den Farbuebergaenge/Kanten)
|
|
Logged
|
73 de Stephan HB9ocq
|
|
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:grafischer Bootscreen beim mcHF
« Reply #8 on: 14. December 2016, 07:56:19 »
|
|
Hallo Andreas,
zum Einschalt-Logo.
Kann man nicht eventuell im Display selbst
(im Controller) ein default Startbild hinterlegen?
Weiß nicht ob der verwendete Type so was kann.
Manche Displays haben für so was einen Buffer,
wo ein Inhalt auf Dauer ablegbar ist.
War nur so ein Gedanke von mir.
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:grafischer Bootscreen beim mcHF
« Reply #9 on: 14. December 2016, 08:51:22 »
|
|
Hallo,
tatsächlich ist das Laden der Daten des Bootscreens vom I2C unpraktisch. Wollte erwähnen, das der Bootscreen künstlich in SW verlängert wird, damit er ausreichend lange auf dem Bildschirm ist um die relevanten Infos zu lesen.
Für die Logo-Fans: Warum nicht einfach ein Binary an eine andere Adresse flashen, die außerhalb der 512k Zone liegt.
Dazu muss man dem Bootloader von Andreas beibringen, ein Binary bestimmten Namens an eine andere Adresse zu flashen, sofern der Speicher verfügbar ist. Die Erkennung von Flashgröße ist ja schon im mcHF selbst implementiert. Ich denke, Andreas hat dazu keine Lust (oder schätze ich das falsch ein, Andreas?  ) aber dank Open Soure und Open Mind kein Problem solche Änderung zu integrieren.
Dann würden die 512er kein Logo sehen, die mit mehr und dem richtigen Bootloader eben ein Logo 
73
Danilo
|
| « Last Edit: 14. December 2016, 08:52:01 by DB4PLE » |
Logged
|
|
|
|
|
|
HB9ocq
Neuling
Offline
Posts: 46
OSS: free bugs'n'fixes!
|
|
Re:grafischer Bootscreen beim mcHF
« Reply #11 on: 14. December 2016, 09:31:23 »
|
|
Aber mal angenommene 38KB sollten doch in wenigen Sekunden erledigt sein.
|
|
Jetzt seid doch bitte etwas geduldig: es werden NICHT 38kB sein, das waere Verhaeltnisbloedsinn weil bald 10% des gesamt FLASH-ROMs.
Mein Bauchgefuehl zieht mich in Wunschrichtung 5kB (mit "Elkotolleranz", also +/-30%).
Kann man nicht eventuell im Display selbst (im Controller) ein default Startbild hinterlegen?
|
|
Lieber nicht: es sind bereits 2 Displaytypen und 2 (oder 3) Anbindungsvarianten(*). Es ist verlockend, aber wenn auf solche Peripheriespezifizitaeten eingegangen wird, geht Flexibilitaet fuer kuenftige Evolution der FW verloren.
(*)Wenn in jedem Geraet NUR genau jene Routinen fuer genau die verloetete HW waere, kaeme auch wieder etwas freier FLASH-ROM Platz zustande.
Ein Profiling ueber welchen Code tatsaechlich abgearbeitet wird waere aufschlussreich.
(haette/taete/wollte - 3 Brueder die Bankrott gingen... ;-)
In SW gelten jedoch IMMER folgende 2 Regeln:
1. don't optimise. (fuer alle: Einsteiger wie Profis)
2. don't optimize yet. (aber auch NUR fuer absolute Experten :-)
Warum? In SW muss die Korrektheit des Codes erste Priotitaet haben - das lehrt uns die (SW-)Geschichte; kleine u. grosse Beispiele aus den Medien und dem eigenen Alltag kann jeder selber nennen.
Für die Logo-Fans: Warum nicht einfach ein Binary an eine andere Adresse flashen, die außerhalb der 512k Zone liegt.
Dann würden die 512er kein Logo sehen, die mit mehr und dem richtigen Bootloader eben ein Logo :)
Danilo
|
|
Das erfordert "bald sowas wie ein ROM-Dateisystem" genauer eine Partitionierung. Dies bedeutet zusaetzliche Routinen im Bootloader UND in der Anwendung.
Bei allem Enthusiasmus/Elan/Willen: das mcHF-Projekt hat (noch) nicht die noetigen Kapazitaeten um DIES auch noch einzubauen. Dies laeuft auf eine heftigstes Refactoring hinaus.
Tut mir leid hier die grosse Spur markieren zu muessen, aber ueber 15J Erfahrung mit Brotarbeit im Embedded-SW Bereich mit genau diesen Aufgabenstellungen in mit ueber 12MA starken Teams bringen mich zu solchen Aussagen.
Wenn dann mal der uC fuer STM32F7 hoffentlich mit maximal moeglichem FLASH-ROM Platz(*) festgenagelt ist, dann ist der richtige Moment um die Architektur fuer FLASH-ROM Partitionierung festzulegen (weil sowieso anderen Maschinencode rauskommen muss, also auch andere Portieraufwaende anstehen).
Alternativ waere eine uSD-Karte auf dem UI-PCB, oder ein weterer geraeteinterner USB-Port fuer ein (optional) Dauerhaft verbauter Massenspeicher. Und wieder Dateisystemcode (wohl FATxy) im FW-Binary...
(* Andreas hat "schon immer" fuer die 1 oder 2MB Typen der STM32F4 Reihe geweibelt: bloss die wenigsten haben sein Tipp ernst genommen...)
- - -
In meinem o.g. Analyseposting gehen klar die allerersten Nachteile hervor:
1. es ist ABSOLUT unsinnig pro Pixel 2 Bytes Platz zu verschwenden; ueberhaupt und schon gar nicht fuer eine nebensaechliche Dekoration
2. es sind nur ganz wenige Farben fuer das Bild ueberhaupt noetig (es geht nicht um TrueColor Portraitfotos der Entwickler/Besitzer - mcHF ist kein Fotoapparat). XPM erlaubt genau so wenige -beliebige- Farben einzusetzen wie benoetigt.
Ich versuche in den naechsten Tagen 2 Sachen:
a) die Farben des Bildes zu redizieren
b) ein Codierschema auszutuefteln, um die Strings fuer die XPM Datenstruktur IM FLASH platzsparender vorzuhalten, dann on-the-fly zu decodieren damit die XPM (voruebergehend, im RAM) Datenstruktur "fuer Danilo" daherkommt.
zu a):
- ich bin kein Bilbearbeitungsprofi
- ich will dies Algorithmisch in den Buildvorgang (ins Makefile) integrieren
- je nach meinem "Ungeschick" kann es in etwas Fleissarbeit (=benoetigt meine Zeit) ausarten
zu b):
- stichwort zum Prinzip: "Packed ASCII String", aber moeglichst auf 4bit/px = 16Farben angepasst
- eine Decodierrroutine fuer in die mcHF-FW
- ein Hilfsprogramm (script) fuer den Buildvorgang
Bitte diese Vorstudie abwarten - den sonst vorhandenen Dampf lieber in HAM-Funktionen einsetzen.
|
| « Last Edit: 14. December 2016, 09:35:02 by HB9ocq » |
Logged
|
73 de Stephan HB9ocq
|
|
|
|
|
HB9ocq
Neuling
Offline
Posts: 46
OSS: free bugs'n'fixes!
|
|
Re:grafischer Bootscreen beim mcHF
« Reply #13 on: 14. December 2016, 10:08:52 »
|
|
optimieren != Refactoring
Refactoring heisst meisst: untauglichen/falschen/schlechten Code richtigstellen, verbessern, gescheiter organisieren (da meist Funktionsaequivalent, minus die korrigierten Fehler).
optimieren heisst meisst: Kompromisse eingehen, indem Annahmen getroffen werden oder zu spezifische Umstaende ausgenuetzt werden, welche zu starke Plattformbindung ergeben.
In anderen Worten:
Refactoring == "gutes Optimieren" | optimieren == "schlechtes Optimieren" :-)
Somit ist auch gezeigt dass die Grenzen selbsverstaendlich fliessend sind und ihr das richtige gemacht habt: macht euren Heldenstatus nicht kaputt !-)
SO: FERTIG PHILOSOPHIE - AN DIE ARBEIT! (gilt haupsaechlich fuer mich)
Eine Schoenen Morgen noch
|
|
Logged
|
73 de Stephan HB9ocq
|
|
|
Pages: [1] 
|
|
|
|
|
|
|
...
