Derzeit ist MINOS auf dem STM32F407VET6 Black Board lauffähig, welches für einen einstelligen Euro-Betrag zu haben ist. Die Portierung auf andere STM32F4xx-Boards ist geplant.
MINOS unterstützt dabei ein Dateisystem auf einer eingesetzten SD-Karte und verwendet eine UNIX/Linux ähnliche Mini-Shell mit Command Line Editing und Dateinamen-Expansion. Desweiteren ist sowohl der NIC-Compiler und der dazugehörende Objekt-Interpreter als auch ein kleiner Editor zum Erfassen von Shell-/Boot- und NIC-Scripts vorhanden.
Derzeit wird folgende auf dem Black Board integrierte Hardware unterstützt:
SD-Karte mit FAT32-Dateisystem
GPIO für jeden freien PIN
Board-LEDs
Buttons als Taster
UART1 zum Betrieb als VT100-kompatible Console - vorzugsweise PuTTY als Terminal-Emulation
Batteriegestützte Echtzeituhr des STM32F407
SPI Flash mit 2 MB
Als externe Hardware wird zur Zeit unterstützt:
UART2 zum Anschluss von externer Peripherie über serielle Schnittstelle
WS2812 LED Stripes
FSMC-Schnittstelle zum Anschluss von SSD1963-TFT-Displays, zum Beispiel 7" 800 x 480.
SPI - zum Beispiel Touch auf einem angeschlossenen SSD1963-Display
I2C - zum Beispiel externe RTC DS3231
Die Unterstützung weiterer Peripherie bzw. die Portierung auf andere STM32-Boards wird folgen. Da bin ich auf die Vorschläge von Euch angewiesen.
Nähere Infos zum unterstützten TFT-Display werde ich kurzfristig in den Artikel einarbeiten, insbesondere was Bezugsquellen und Anschlussbelegung betrifft.
Die oben abgebildeten Uhren sind nicht Bestandteil von MINOS, sondern in der Sprache NIC geschrieben. Der NIC-Source-Code dazu ist im MINOS-Artikel als Listing aufgeführt:
Warum schaffen es die unixoiden Programmierer eigentlich nicht, eine
Struktur in ihre Firmware zu kriegen? Lowlevel-Timer-Initialisierungen
in main, Uhrzeit- und Kalender-Funktionen in base.c, kein wirklicher
Tasten-Handler in buttons.c sondern nur sowas:
if (GPIO_ReadInputDataBit(BUTTON_PORT, BUTTON_PIN) == BUTTON_PRESSED)
und so weiter..
W.S.
Wow... der weltberühmte Entwickler der noch berühmteren
Lernbetty-Software begibt sich von den Höhen der Programmierung in die
niederern Gefilde der unixoiden Welt und studiert meine Software, und
zwar in alphabetischer Reihenfolge!
Ich bin echt zu Tränen gerührt.
Bei "A" gibt es nichts, also stoßen wir zu "B":
base.c:
Zur Zeit fristen die Handvoll (noch unbenutzten und deshalb dort
geparkten) Kalenderfunktionen ihr trostloses Dasein in der schnöden
base.c. Ich werde sie wohl in die Datei mit dem hochtrabenden Namen
"calendar.c" verschieben müssen, um mehr Struktur in die Software zu
bekommen.
Eine super Anregung: Damit werde ich endlich eine "richtige" Struktur
der Software erhalten, indem ich die Anzahl der bisherigen 29 C-Module
auf die sagenhafte Zahl von 30 bringe! Werde ich umsetzen, danke!
button.c:
Ich muss leider zugeben, dass diese Button-Geschichte noch ziemlich
rudimentär ist. Hier ist Dir leider nicht aufgefallen, dass etwas noch
viel wichtigeres fehlt, nämlich eine ordentliche Software-Entprellung!
Die habe ich aber schon eingeplant und gebe dieser eine wesentlkich
höhere Priorität als einem wie auch immer gearteten "Handler". Da kommt
also auf jeden Fall noch was!
Vielen Dank für Deine konstuktive Kritik! Thumbs up!
Frank M. schrieb:> Vielen Dank für Deine konstuktive Kritik!
Danke für die Blumen.
Ja, auch du hättest besser daran getan, die Lernbetty näher anzusehen
und die grundlegenden Strukturen zu verstehen. dann hättest du nicht so
ein Spaghetti-Projekt gestartet.
Mein Rat:
Schaffe Programm-Ebenen mit sauberen Interfaces.
Also erstens:
Schreibe Lowlevel-Treiber für das, was du tatsächlich für deinen OS-Kern
benötigst. Und nicht die ganze Breitseite an irgendwelchen Demo-Codes
für alle möglichen und unmöglichen Peripherie-Cores, die die diversen
Chips haben bzw. haben können. Also weg mit dem ganzen SPL Verzeichnis.
Obendrein sollen die Lowlevel-Treiber ein hardwareunabhängiges Interface
zu den höheren Schichten haben. Das führt dann dazu, daß du all die
unsäglichen
#if defined (STM32FwelcheVersion)
einfach WEGLASSEN kannst und solltest!
Hardwareabhängige Dinge haben schon direkt oberhalb der Lowlevel-Treiber
GARNICHTS mehr zu suchen. Ab da hat es gefälligst hardwareunabhängig
zu sein.
Eine Ausnahme mag allenfalls sein, daß man bei manchen Chips nicht mit
"toUART5" arbeiten kann, weil es diesen UART auf dem konkreten Chip
garnicht gibt.
Zweitens:
Führe das Schichtenmodell auch auf höheren Schichten weiter. Der
eigentliche OS-Kern hat sich um das Kanalisieren der I/O-Ströme zu
kümmern, so etwas wie ein Kommandoprogramm zu bieten, das Kommandozeilen
von diversen I/O-Streams ermöglichen soll- aber nicht deren Auswertung!
Und er soll Events an eventuelle Interessenten verteilen, sowie für
grafische Zwecke ein Grafikinterface nebst Schriften bieten. Ebenso ist
es Sache des OS-Kerns, Vorgänge wie das Einsetzen oder Herausnehmen
einer SD-Karte oder das An- oder Ab-Stöpseln des USB zu behandeln und
der Shell-Schicht entsprechende Events zu deen Kenntnisnahme zu senden.
Übles Beispiel deinerseits: dein Unit button.c, der nicht die geringste
Treiber-Qualität besitzt. Es mag ja OK sein, auch eine Abfrage des
momentanen Zustandes einer Taste zu haben, aber das Wesentliche wäre,
ein Tastaturereignis a la "idButton1" beim Übergang der Taste von
ungedrückt zu gedrückt zu generieren und anschließende Maßnahmen zu
ergreifen, um diese Taste zu entprellen.
Drittens:
Die Auswertung von Benutzer-Aktionen (Mausereignisse, Tastenereignisse)
und Benutzekommunikation (hereingekommene und lowlevel-editierte
Kommandozeilen) ist hingegen Sache einer Shell, die sich ihrerseits auf
gar keinen Fall mit Hardwareangelegenheiten befassen soll.
Ein Sonderfall bei µC ist die niedere Hardware-Konfiguration. So etwas
ist IMMER projektabhängig, also braucht es einen separaten Modul zum
Konfigurieren der projektabhängigen Portpin-Verwendung. Das ist eine
andere Sache als die Portierung auf verschiedene Chips.
Und da man eben dieses für jedes Projekt anders machen muß, ist an
dieser Stelle sowohl etwas Komfort als auch Lesbarkeit erforderlich. Was
du da in
src\system_stm32f4xx.c
abgeliefert hast, ist ... beschämend.
Ich hänge dir mal einen Konfigurationsmodul für einen anderen Chip dran,
nicht zum Copy&Paste, sondern damit du das Prinzip verstehen kannst.
So.
In einem ordentlich konstruierten Mini-OS gibt es also:
- lowlevel-Treiber, die chipabhängig sind und also beim Wechsel auf eine
andere Plattform durch die dafür passenden Treiber zu ersetzen sind.
Aber da all diese Treiber eine einheitliche Schnittstelle nach oben
haben (ein einheitliches .h für alle Chips), betreffen die Änderungen
zum Portieren eben nur diese Treiber.
- den OS-Kern, der hardwareunabhängig ist. Das Wenige, was eventuell
hier noch vonnöten ist betrifft:
- die Bildschirm-Auflösung (x,y,Farbtiefe usw) für die
Grafikschnittstelle (GDI)
- die Überwachungsfunktionen für die Peripherien, die das brauchen:
SD-Karte, ggf. USB.
- die Shell-Schicht und die Anwendungen, zu denen auch ein Mini-Compiler
gehören.
Also durchforste mal dein Projekt nach all den unzähligen #ifdef's oder
if defined (STM32Fxyz) und schmeiß all diese #ifdef's raus. Wenn du dein
Projekt sauber strukturiert hast, dann sollten diese nämlich ganz von
selber obsolet sein.
Und wenn du schon eine SD-Karte im System vorsiehst, dann mußt du eben
auch ein API für deinen OS-Kern vorsehen, der von ladbaren Anwendungen
auf nicht umständliche Weise benutzbar ist und der bei Änderungen im
OS-Kern kein Neu-Übersetzen der Anwendungen erfordert. Der SVC ist dabei
eine ganz gute Wahl.
Siehe Lernbetty.
Die hatte das nämlich alles bereits implementiert.
Was bei ihr systembedingt fehlte, ist das Laden von Anwendungen aus
einem Massenspeicher UND Threads nebst Relokation der Anwendungen, um
selbige auf gerade freie RAM-Adressen zu laden und parallel laufen zu
lassen.
W.S.
W.S. schrieb:> Übles Beispiel deinerseits: dein Unit button.c, der nicht die geringste> Treiber-Qualität besitzt.
Das soll momentan auch kein Treiber sein. Minos soll auch kein OS sein.
Vielleicht wird es das mal irgendwann, vielleicht auch nicht. Offenbar
gehst Du da mit den falschen Erwartungen dran.
Du hängst Dich auch viel zu sehr an dem simplen button.c auf, ohne Dir
den Rest angeschaut zu haben. Daher reden wir hier auch aneinander
vorbei. Deshalb halte ich eine weitere Diskussion mit Dir nicht
zielführend.
Und nein, ich schaue mir bestimmt nicht die Lernbetty an, die Du immer
wieder wie sauer Brot anbietest, so dass man den Eindruck bekommt, Du
hättest in Deinem Leben nichts anderes fertiggestellt bzw. gemacht.
Dieser Eindruck ist gewiss falsch, aber merkwürdigerweise spricht hier
auf mikrocontroller.net immer nur einer davon. Deshalb ist das Dein Ding
und nicht meins.
Außerdem will ich gewiss nicht irgendetwas ausgerechnet nach Deinem
Geschmack programmieren. Da unterscheiden sich unsere Vorstellungen von
Software zu sehr, wie sich schon des öfteren in diversen anderen Threads
herausgestellt hat. Daher verzichte ich auf Deine altväterlich
anmutenden Ratschläge dankend, auch wenn sie hier und da für die
Programmierung eines OS richtig sein können.
Wo Minos noch hinführt, weiß ich noch gar nicht. Ich betrachte es
momentan lediglich als Werkzeugkasten, um mit der Programmiersprache NIC
mit wenigen Zeilen ein lauffähiges Programm zu realisieren. Ich kenne
jedenfalls kein Programm, wo man mit weniger als 270 Programmzeilen, die
dabei auch noch extrem kurz sind, eine komplette WordClock hinbekommt.
Als letztes noch eine Info für Dich:
button.c ist eine exakte Kopie aus meinem Projekt "WordClock mit
WS2812", welches auf dem STM32F103-Mini-Dev-Board, auf den Nucleo-Boards
STM32F401 und STM32F411 und neuerdings auch auf dem STM32F407 Black
Board läuft. Daher ist die Unterscheidung per #define auch äußerst
sinnvoll. Und ich werde den Teufel tun und mich im Nachhinein wieder
einschränken auf nur ein Board, nur damit es Dir gefällt. Nach Deiner
Vorstellung müsste ich button.c (Taster mit/ohne Pullup, manchmal
low-aktiv, mal high-aktiv je nach Board) nämlich N-mal implementieren -
für jedes Board extra. Das entspricht nicht meiner Vorstellung.
Oder nimm IRMP, welches auch aus meiner Feder stammt. Das läuft auf
diversen ATtinys, ATmegas, ATXmegas, PICs, STM8, STM32F1xx, STM32F4xx,
ESP8266, LPC1347, LPC4088 und diversen anderen ARM Cortexes. Nach Deiner
Philosophie hätte ich irmp.c X-fach neu implementieren müssen - für
jeden Prozessor extra. Nee, nicht mein Ding.
Und da Du desöfteren hier solche Formulierungen wie "übel", "beschämend"
usw. - überflüssigerweise - angebracht hast, bist Du auch kein adäquater
Diskussionspartner für mich. Ich muss mich hier nicht blöd anmachen
lassen. Ich bitte Dich daher, Dich zukünftig aus diesem Thread
herauszuhalten und für Deine Lernbetty woanders Werbung zu machen.
Die Lernbetty als "sauer Brot" zu bezeichnen empfinde ich als frech. Sie
ist ein (kleines) Brötchen.
Ausserdem muss ich W.S. vollkommenrecht geben, das man das ganze "#if
defined" einfach weglassen kann, wenn man wie er, sich nur auf eine
CPU-Variante festnageln lässt.
;)
Weiter machen! :D
Frank M. schrieb:> Und nein, ich schaue mir bestimmt nicht die Lernbetty an
Das ist dein Problem. Du hättest daraus lernen können. Aber du hast ja
nicht mal meinen obigen Beitrag gelesen, geschweige denn verstanden.
Nun, Ratschläge zu geben ist das eine, selbige anzunehmen oder
wenigstens darüber nachzudenken, ist was ganz anderes. Was erwartest du
eigentlich, wenn du hier so ein Projekt vorstellst?
W.S.
W.S. schrieb:> Was erwartest du eigentlich, wenn du hier so ein Projekt vorstellst?
Ich erwarte jedenfalls nicht, dass sich hier irgendwelche
geltungsbedürftige Typen melden, welche mit ihrem persönlichen Programm
(hier: Lernbetty) den Thread kapern wollen.
Mach also für Deine Lernbetty einen eigenen Thread auf und versuche
nicht, immer die Welt verbessern zu wollen.
> Warum schaffen es die unixoiden Programmierer eigentlich nicht, eine> Struktur in ihre Firmware zu kriegen?
Was ist eigentlich ein unixoider Programmierer? Sicherlich jemand, der
das heilige Windows nicht verehrt. Denn nur wer das heilige Windows
verehrt, dem wird die Gabe der Softwarestruktur gegeben werden. Enter.
Frank M. schrieb:> Mach also für Deine Lernbetty einen eigenen Thread auf und versuche> nicht, immer die Welt verbessern zu wollen.
Egal ob W.S.s Kritik gerechtfertigt ist oder nicht: Lernbetty hast Du
ins Spiel gebracht.
Und beim ersten reinschauen habe ich den Eindruck, dass dessen Schöpfer
zumindest die notwendige Erfahrung hat für konstruktive Kritik. Und
nachdem Du darauf verweist, ist es doch gut, wenn W.S. seine Ansichten
anhand eines konkreten Entwurfs verdeutlicht anstatt per kontextlosem
Pseudocode.
Achim S. schrieb:> Egal ob W.S.s Kritik gerechtfertigt ist oder nicht: Lernbetty hast Du> ins Spiel gebracht.
Nö, die hat "W.S." erstmalig erwähnt, im vierten (seinem zweiten)
Beitrag in diesem Thread.
Johannes S. schrieb:> warum wird der Code für so umfangreiches Projekt in einer altmodischen> Zip Datei angeboten?
Das ist nur für den Übergang, steht auch so im Artikel.
mikrocontroller.net bietet ebenso ein eigenes SVN an. Da muss man sein
Projekt nur von Andreas freischalten lassen. Das werde ich noch machen.
Das nächste Update kann man sich dann auch per SVN ziehen.
Wenn Dir SVN auch noch zu altmodisch ist, sag Bescheid. Meinetwegen
kanns dann auch bei github & Co gehalten werden. Das ist mir persönlich
egal.
Spätestens nach den Beiträgen zum Projekt vergeht einem die komplette
Lust und da hat Achim S. schon recht, Lernbetty hast du ins Spiel
gebracht!
Du hast W S. erster, zugegebener bissigerer aber nicht ganz
ungerechtfertigter, Beitrag, direkt mit Verweis auf Lernbetty ins
lächerliche gezogen.
Bin auch überrascht das ein Moderator so einen Ton an den Tag legen darf
hier.
Die Kritik an der button.c hast du ja bestätigt das diese unfertig ist
und das die Uhrzeit- und Kalender-Funktionen in base.c aktuell "sinnlos"
da sind auch. Bleib übrig "low-level Timer Initialisierung in der main"
okay das kann, muss aber nicht schlimm sein. Und zu guter letzt das
"unixoiden Programmierer", ob das ein Schimpfwort ist, ich glaube
nicht...
Von daher ging hier die harte Gangart in dem Thread von einem Moderator
aus, wenn Moderatoren so einen Ton an den Tag legen dürfen, warum soll W
S. das nicht dürfen.
Zuschauer schrieb:> Du hast W S. erster, zugegebener bissigerer aber nicht ganz> ungerechtfertigter, Beitrag
Problem imo halt: Der Ton macht die Musik, und die war schon "leicht
dissonant"...
Jan L. schrieb:> Problem imo halt: Der Ton macht die Musik, und die war schon "leicht> dissonant"...
W S. hat etwas rau angefangen und ukw dann richtig zugeschlagen das es
kracht, von einem Moderator würde man halt erwarten das er eher
moderiert und deeskaliert anstatt noch mehr zu eskalieren.
W.S. schrieb:> Warum schaffen es die unixoiden Programmierer eigentlich nicht, eine> Struktur in ihre Firmware zu kriegen?
Das war das einzig bissige, der Rest war gerechtfertigt und wurde auch
sachlich erklärt von ukw (z.B. noch in Entwicklung etc.).
Frank M. schrieb:> Wow... der weltberühmte Entwickler der noch berühmteren> Lernbetty-Software begibt sich von den Höhen der Programmierung in die> niederern Gefilde der unixoiden Welt und studiert meine Software, und> zwar in alphabetischer Reihenfolge!
Aber dann mit sowas zu antworten... also bitte... und damit kam die
Lernbetty Software ins Spiel, wenn W.S. auf sowas reduziert wird von
einem Moderator kann er sich ja wohl darauf berufen was daran "besser"
ist als an MINOS
Frank M. schrieb:> Oder nimm IRMP, welches auch aus meiner Feder stammt. Das läuft auf> diversen ATtinys, ATmegas, ATXmegas, PICs, STM8, STM32F1xx, STM32F4xx,> ESP8266, LPC1347, LPC4088 und diversen anderen ARM Cortexes. Nach Deiner> Philosophie hätte ich irmp.c X-fach neu implementieren müssen - für> jeden Prozessor extra. Nee, nicht mein Ding.
Eben nicht komplett neu implementieren, sonder im Grunde nur ein paar
Zeilen pro Plattform... du hast das Prinzip zwischen High- und Low-Level
Code nicht ganz verstanden. Im Grunde wurde der Treiber nur "Pin High"
und "Pin Low" zur Verfügung stellen, evtl. noch Timer/Wait und das war
es schon, alles andere kann bleiben. Du hast deinen "Treiber" quasi
durch ifdef etc. gebaut. Das Problem ist will man das Projekt porten
muss man alle Stellen suchen wo man was anpassen muss, die wären sonst
in einem Treiber gebündelt. Bin IRMP aber auch nur schnell überflogen,
kann sein das die #ifdef schon gebündelt sind.
Hallo,
Rufus Τ. F. schrieb:> Nö, die hat "W.S." erstmalig erwähnt, im vierten (seinem zweiten)> Beitrag in diesem Thread.
Nein, das war Frank im 3. Beitrag.
rhf
Frank M. schrieb:> Wenn Dir SVN auch noch zu altmodisch ist, sag Bescheid. Meinetwegen> kanns dann auch bei github & Co gehalten werden.
Wenn man die Kindergartenkacke hier wieder liest ist es doch nur noch
verschwendete Zeit hier so ausführliche Artikel zu schreiben. Auf Github
kann man so Projekte besser entwickeln und wenn jemand einen ernsten
Vorschlag hat kann er sich per Issue oder PR beteiligen.
Zuschauer schrieb:> W S. hat etwas rau angefangen und ukw dann richtig zugeschlagen das es> kracht, von einem Moderator würde man halt erwarten das er eher> moderiert und deeskaliert anstatt noch mehr zu eskalieren.
Das ist ein Phänomen was man komischerweise immer wieder in der SW/HW
Entwicklung entdeckt,(Siehe LKML) da gehts noch bedeutend heißer her und
der "Ober Moderator" teilt am aller heftigsten aus. Trotzdem
funktionierts irgendwie...
Nichts desto trotz,dass ist ein sehr spannendes Projekt mit viel
Potenzial. Gibt es denn eine Art "road-map", bzw. eine Art Plan wo das
ganze mal landen soll? Abgesehen von der Portierung auf weitere Boards.
Um wieder zum Thema zu kommen: ich habe mal ein wenig in der
Beschreibung von MINOS und NIC geblättert.
Sowie ich es verstehe und auch gut finde, hat man mit MINOS ein
Werkzeug, mit dem man im Zielsystem seine Programme anpassen kann.
Was ich jedoch vermisse, ist die Möglichkeit, Interrupts zu verarbeiten.
Habe ich etwas übersehen?
Mit den Datentypen 8-Bit und 32-Bit Integer gekommt man auf der einen
Seite kurze Laufzeiten. Auf der anderen Seite sehe ich aber float oder
besser double als unbedingt notwendigen Datentyp an, sobald es etwas
mehr sein soll, als LEDs oder Licherketten leuchten zu lassen.
Daher meine ketzerische Frage: "Sind float/double in realistischer
Planung?"
Ich möchte nun alle Beteiligten bitten, wieder zum Thema zurückzukommen.
Ja, vielleicht habe ich auf W.S.' ersten Beitrag etwas zu überzogen
reagiert. Und ja, wie ich oben schon geschrieben habe, hat er mit
einigen seiner Äußerungen zu der Entwicklung eines "richtigen" OS
durchaus recht. Die dafür notwendigen Programmiertechniken sind mir
durchaus bekannt. So weit ist MINOS aber noch lange nicht - schon gar
nicht in der ersten hier vorgestellten Version. First make it work, then
make it fine. Und es ging mir erstmal darum, etwas lauffähiges
vorzustellen, auf dessen Basis man dann das Projekt weiter entwickeln
kann. Dafür muss dann in der ersten Version auch nicht alles perfekt
sein.
Zum Thema:
Ma S. schrieb:> Gibt es denn eine Art "road-map", bzw. eine Art Plan wo das ganze mal> landen soll? Abgesehen von der Portierung auf weitere Boards.
Auf meinem Plan stehen schon einige Punkte, die ich aber noch nicht ganz
ausformuliert habe. Einiges davon habe ich hier auch schon prototypisch
laufen oder funktioniert bereits in anderen Projekten.
1. EEPROM-Simulation
---------------------
Auf dem STM32F407 BlackBoard gibt es einen 2 MB großen Flash. Für diesen
habe ich eine Simulation geschrieben, dass er sich genauso wie ein
externes EEPROM verhält. Dies habe ich auch für das Projekt
WordClock mit WS2812 bereits so umgesetzt und wird in der dortigen
nächsten Version 3.0 mit erscheinen, so dass man für dieses Projekt
zumindest für das BlackBoard kein externes EEPROM mehr benötigt, um
seine Konfigurationsdaten zu speichern. Im nächsten Schritt wollte ich
den "Treiber" dafür auch in MINOS integrieren. Allerdings sind die 2MB
Flash-Kapazität für eine simple EEPROM-Emulation ziemlich fett und die
Anwendung für ein paar KB an Konfigurationsdaten verschwenderisch. Da
ließe sich auch (zum Teil jedenfalls) mehr draus machen, z.B. auch noch
ein internes Filesystem. Wer da noch andere Gedankenanstöße hat, kann
sich gerne melden.
2. Netzwerk
------------
Ich möchte den ESP8266 (evtl. später auch ESP32) an den STM32 anbinden,
um so eine Netzwerkverbindung herzustellen. Dabei soll die
UART-Verbindung zwischen STM32 und ESP8266 gemultiplext werden, um so
mehrere Kommunikationskanäle gleichzeitig in beiden Richtungen
transparent zur Verfügung zu stellen. Dann kann man auch per telnet eine
Console auf dem STM32 öffnen und der STM32 kann so auch andere
Netzwerkdienste bereitstellen. Ebenso kann er auch zu anderen Hosts eine
Verbindung aufnehmen, um so Daten auszuliefern oder abzuholen.
Hierfür werde ich eine spezielle Firmware für den ESP8266 bereitstellen,
der dies dann erledigt. Genau so etwas habe ich auch bereits in
WordClock mit WS2812 umgesetzt. Hier dient der ESP8266 ebenso als
Netzwerk-Controller für den STM32.
3. Programmierung NIC
---------------------
Ein NIC-Programm kann zum einen selbst auf dem STM32F4xx compiliert
werden. Das Editieren und die nötige Compilation kann auch komfortabler
unter Linux oder Windows erfolgen, so dass man dann die resultierende
Objekt-Datei nur noch auf den STM32 schieben muss. Der Compiler läuft
bei mir bereits unter Linux und Windows. Diesen werde ich demnächst auch
hier vorstellen.
So kann man dann den Compiler auf einem kleineren STM32F103 weglassen
und es muss nur noch das NIC-Runtime-System unter MINOS auf dem STM32 im
Flash vorhanden sein, um seine Anwendung auszuführen.
Für das "Schieben" auf den STM32 bietet sich dann auch ein virtueller
UART-Kanal via ESP8266 an. Somit benötigt man auf seinem PC lediglich
eine WLAN-Verbindung, um direkt ausführbare NIC-Programme auf das
MINOS-System zu schieben.
4. Updates für den MINOS-Host
------------------------------
Beim WordClock mit WS2812 Projekt besteht die Möglichkeit, dass der
ESP8266 sich von einer beliebigen Webseite ein STM32-Firmware-Update
holt oder er eines von einem lokalen PC per Webinterface übertragen
bekommt. Per STM32-Bootloader flasht der der ESP8266 dann den STM32.
Auch dieses Feature möchte ich für MINOS übernehmen.
Es gibt da noch weitere Punkte, die hier aber zu weit führen würden. Ich
werde da in den nächsten Tagen eine Roadmap im Artikel aufstellen.
m.n. schrieb:> Was ich jedoch vermisse, ist die Möglichkeit, Interrupts zu verarbeiten.
Bisher gibt es die Möglichkeit, Timer-Alarms in NIC zu nutzen. Ein
Beispiel ist hier zu finden: MINOS: Lauflicht mit WS2812. Zunächst
wird das Lauflicht per Delay realisiert, in der zweiten Variante ein
Timer-Wert abgefagt. In der verbesserten 3. Ausführung wird dann ein
Alarm-Signal gepollt und in der letzten und 4. Variante wird beim
Ablaufen des Timer-Alarms selbsttätig eine NIC-Unterfunktion analog zu
einer ISR aufgerufen.
Dieses Vorgehen könnte man natürlich vom Timer-Interrupt auch auf andere
Interrupt-Quellen übertragen.
> Daher meine ketzerische Frage: "Sind float/double in realistischer> Planung?"
Ja, sind sie. Bevor ich aber noch weitere Datentypen als die bestehenden
einführe, möchte ich vorher die Entscheidung im NIC-Interpreter, mit
welchem Datentyp innerhalb von arithmetischen Ausdrücken nun
"weitergerechnet" werden muss, noch in den NIC-Compiler verlagern. Das
spart nicht nur ein wenig Verarbeitungszeit, sondern vereinfacht auch
die Datentyp-Behandlung im Code des Interpreters erheblich.
Frank M. schrieb:> First make it work, then> make it fine.
Siehst du, genau DAS ist der zentrale Punkt. Das ist das von mir
angesprochene unixoide Herangehen an's Programmieren.
Und das ist nach meiner Erfahrung grundfalsch. Wenn du zuerst drauflos
programmierst und dann versuchst Grund rein zu kriegen, dann hast du im
besten Falle sinnlos einen Teil deiner Programmierarbeit vergeigt,
nämlich den, den du dann wegreißen und ersetzen mußt.
Im schlimmeren Falle bleibt der Kruscht im Projekt drin und du wirst
dich damit selber einengen und in unnötige selber aufgestellte
Fettnäpfchen treten und eigentlich unnötige Workarounds dir ausdenken
müssen. Von der Portierbarkeit mal ganz abgesehen.
Ich predige hier nicht umsonst den Leuten immer wieder, daß sie vor dem
Schreiben der ersten Zeile nachdenken und sich einen Plan machen sollen.
Also nicht zuerst in die Tasten hauen und dann nachträglich in Ordnung
bringen wollen. Sowas muß doch irgendwann mal begriffen werden. Man
kommt sich nach einiger Zeit ja so vor, als ob die eigene Zunge ein
Fransenteppich geworden wäre.
W.S.
W.S. schrieb:> as ist das von mir> angesprochene unixoide Herangehen an's Programmieren.>> Und das ist nach meiner Erfahrung grundfalsch.
was hat das denn mit "unixoid" zu tun? Oder behauptest du tatsächlich,
alles was im Umfeld eines Unix-ähnlichen Systems programmiert wird, ist
per se sch*ce?
Was wäre dann das Gegenteil von "unixoid"? "microphil"?
W.S. schrieb:> Siehst du, genau DAS ist der zentrale Punkt.
Ich schreibe in meiner Freizeit freie Programme, weil ich die Freiheit
habe, diese Programme so zu schreiben wie ich es möchte und zwar so,
dass ich Spaß daran haben kann.
Akzeptiere das bitte.
Das Kopieren und das Einbinden von button.c aus dem Parallelprojekt
kostete mich keine 2 Minuten. Wenn ich den Dreizeiler später umbaue, so
dass er den Kriterien für ein OS genügt, habe ich genau 2 Minuten meines
Lebens verschwendet. Aber ich hatte schon Wochen vorher ein lauffähiges
Programm, mit dem ich etwas anfangen konnte. Das ist es mir wert.
W.S. schrieb:> Ich predige hier nicht umsonst den Leuten immer wieder, daß sie vor dem> Schreiben der ersten Zeile nachdenken und sich einen Plan machen sollen.
Das ist doch im groben und ganzen passiert, siehe erster Beitrag und
Wiki-Artikel. Vor dem Schreiben der ersten Zeile Code wurden sich
Gedanken gemacht, welche Schichten dem Nutzer präsentiert werden soll,
wie diese Aussehen, wie sie sich verhalten und grob welche "Toolchain"
es gibt.
Am wichtigsten ist doch für den "Benutzer" das die "oberste Schicht"
gleich bleibt, sprich das seine NIC-Programme auch mit späteren
Versionen laufen. Was darunter passiert kann (und soll) ihm egal sein.
Damit ist schon die halbe Miete gewonnen. Wenn ukw nun "unnötig"
programmieren muss ist das ja nicht "dem Benutzer" sein Problem, der nur
seine NIC Programme ausführt. Solang die oberste Schicht gleich bleibt,
kann sich darunter ändern was will. Programme für Single-Core Rechner
laufen meist auch auf Multi-Core Rechnern. Programme die für
Linux-Kernel 2.6 geschrieben wurden compilieren auch noch unter dem
4.0er Kernel (ausnahmen bestätigen die Regel), obwohl sich "unter der
Haupe" extrem viel getan hat. Aber solang die "oberste Schicht" gleich
bleibt stört das den Benutzer nicht. (und ja ich weiß, "oberste Schicht"
ist etwas salopp formuliert)
Klar Treiber für MINOS oder gar das Projekt auf andere Plattformen
portieren ist im aktuellen Zustand nicht möglich, aber vielleicht wird
das ja noch kommen.
Ich muss W.S. schon Recht geben, professionelle hardwarenahe
Programmierung hat NICHTS mit "First make it work, then make it fine" zu
tun. Das machen in diesem Bereich nur Leute, die mehr von ihren
Fähigkeiten halten als tatsächlich vorhanden. Im PC-Bereich kommt man
mit dieser Einstellung vielleicht weiter, aber keiner kann mir erzählen,
dass soetwas bare-metal programmiert einen vernüntig geplanten
Programmstruktur- und Ablauf schlagen kann.
Mit einer sauberen Struktur und definierten Schnittstellen wären die
oben von W.S. aufgeführten Fehler allesamt vermeidbar gewesen...
TrollJäger schrieb:> Ich muss W.S. schon Recht geben, professionelle hardwarenahe> Programmierung hat NICHTS mit "First make it work, then make it fine" zu> tun.
MINOS ist ein Freizeitprojekt und kein professionelles. Oder hast Du
irgendwo gelesen, dass ich dafür Geld nehmen möchte?
Außerdem spricht für Dich, dass Du jemandem Recht gibst, nur weil er
selbstverständlich gültige Gemeinplätze getarnt als altväterliche
Ratschläge gibt und sonst von C-Programmierung recht wenig Ahnung hat.
Das fängt schon mit dem mangelnden Verständnis von "const" in einem
Funktionsargument an.
> Das machen in diesem Bereich nur Leute, die mehr von ihren> Fähigkeiten halten als tatsächlich vorhanden.
Ich weiß, was ich von meinen Fähigkeiten halte. Du hast weder den
MINOS- noch den NIC-Artikel gelesen noch kennst Du irgendeines
meiner anderen Projekte, die allesamt aus meiner eigenen Feder stammen:
Ein paar findest Du hier:
https://www.mikrocontroller.net/articles/Benutzer:Ukw
Wohlgemerkt: Ich habe mich dort nicht als Anwender an den dort
aufgeführten Projekten beteiligt, sondern sie stammen alle von mir. Lies
mal die Artikel, dann hast Du erstmal ein paar Wochen zu tun. Natürlich
können mehrere zehntausend Zeilen allein an Dokumentation das eine oder
andere leichte Gemüt durchaus überfordern. Wer damit aber arbeiten
möchte, tut dies auch gern.
> Im PC-Bereich kommt man> mit dieser Einstellung vielleicht weiter, aber keiner kann mir erzählen,> dass soetwas bare-metal programmiert einen vernüntig geplanten> Programmstruktur- und Ablauf schlagen kann.
Dann lies mal den Source oder den Artikel statt einfach etwas
nachzuplappern. Der ist durchaus strukturiert und baut auch
schichtenweise aufeinander auf. Außerdem steckt da eine Menge Arbeit
drin. W.S. hat sich lediglich eine Stelle rausgepickt, die zwar
diskussionwürdig ist, aber dem Großen und Ganzen nicht gerecht wird.
> Mit einer sauberen Struktur und definierten Schnittstellen wären die> oben von W.S. aufgeführten Fehler allesamt vermeidbar gewesen...
Die Struktur ist sauber, die Schnittstellen sind alle wohldefiniert, die
sogenannten "Fehler" sind keine Fehler. Sonst hätte ich wohl kaum
NIC als strukturierte Programmiersprache auf dieser Basis nebst
NIC-Compiler implementieren können.
Apropos "allesamt": Mir ist nur die eine Stelle bekannt, die von W.S.
kritisiert wurde. Er zitierte hier eine Programmzeile aus insgesamt mehr
als 60.000 Zeilen Code. Das ist weit weniger als 0,001% des ganzen
Source-Codes. Die gesamte Codequalität aufgrund einer Zeile hier groß
und breit runtermachen zu wollen, grenzt an Unverschämtheit.
Mir ist auch die Zeit zu schade, mich hier weiter rumzustreiten. Ich
werde nur noch auf fundierte Kritik antworten, nämlich dann, wenn der
Betreffende
- den Artikel MINOS gelesen hat,
- den Artikel NIC gelesen hat,
- die Software im Großen und Ganzen überblickt oder ein Anwender ist
Sollte es jedoch mehr von denjenigen geben, die aufgrund von schlechter
Laune oder gar aus Missgunst ein Geschenk meinerseits runtermachen
wollen, stelle ich die ganze Sache einfach kommentarlos ein. Das tut mir
nicht weh. Es gibt genügend andere spannende Projekte.
Frank M. schrieb:> Sollte es jedoch mehr von denjenigen geben, die aufgrund von schlechter> Laune oder gar aus Missgunst ein Geschenk meinerseits runtermachen> wollen, stelle ich die ganze Sache einfach kommentarlos ein.
Mach das oder auch nicht, ganz nach deinem Gusto. Frei nach Einstein:
"dem Universum ist das alles schnurz".
Also: Wärest du nicht so hochnäsig auf der einen Seite und so
unverschämt und anmaßend in deinen Stellungnahmen auf der anderen Seite
wärest, sondern sachlich und ruhig und gewillt, auch durchaus
wohlmeinende Kritik als Anlaß zu nehmen, Struktur in dein Projekt zu
bringen, dann wären sowohl dir selbst als auch etwaigen hier mitlesenden
Interessenten damit gedient.
Aber wenn du nicht anders kannst als beleidigte Leberwurst zu sein, dann
kann auch unsereiner dir nicht helfen. Du vermutest, daß Kritik an
deinem Projekt aus Mißlaune oder gar Mißgunst entstünde? Nee, das ist
falsch. Die Kritik entsteht aus deinem Projekt selbst.
Mache es einfach besser und sauberer. Und zu dem Zweck stelle dir vor,
daß andere Forenteilnehmer es auf PIC32, LPC17xx, Fujitsu FR30 und Sharp
BlueStreak zu portieren gedenken und dabei auch die jeweiligen ganz
anderen Compiler verwenden würden. Ein Chip davon ist übrigens
bigendian, also das wäre auch zu beachten. Und nachdem du dir das
vorgestellt hast, überdenke die Struktur deines Projektes noch einmal
ganz gründlich.
Frank M. schrieb:> Die Unterstützung weiterer Peripherie bzw. die Portierung auf andere> STM32-Boards wird folgen. Da bin ich auf die Vorschläge von Euch> angewiesen.
Das ist der falsche Weg, den auch Mikroe gegangen ist: Anpassung des
Projektes nur durch den Autor, da dies für Andere zu kompliziert würde.
Mit sowas verbaut man sich nur alles. Besser ist es tatsächlich,
Anpassungen an andere Plattformen den Anderen so leicht zu machen, daß
jeder das selber kann. Aber dazu ist dein Spaghetticode mit all den
#define's nicht geeignet, da hast du ganz einfach zu wenig vorgedacht.
Und genau darüber ging die ganze Diskussion.
W.S.
W.S. schrieb:> Aber wenn du nicht anders kannst als beleidigte Leberwurst zu sein
Da bist Du bei Kritik an Deiner "Lernbetty" aber auch nicht wirklich
anders.
W.S. schrieb:> Wärest du nicht so hochnäsig auf der einen Seite und so> unverschämt und anmaßend in deinen Stellungnahmen
Dies aus Deinem Munde (bzw. von Deiner Feder)?!?!?
Rufus Τ. F. schrieb:> Da bist Du bei Kritik an Deiner "Lernbetty" aber auch nicht wirklich> anders.
Hat in den letzten 6 Jahren denn irgendwer mal die Lernbetty kritisiert?
Nö.
Jedenfalls nicht sachlich kritisiert.
Herum-Pöbler gab's schon immer und wird es auch in Zukunft geben. Aber
die disqualifizieren sich selbst indem sie unsachlich werden und mit
persönlichen Beleidigungen werfen.
Es gab allerdings jemanden, der den SVC nicht verstanden hat. Sonst
gab's eigentlich gar keine Kritik an der Lernbetty. Schade nur, daß
damals seit Bekanntwerden der Lernbetty die zugrundeliegende
Fernbedienung bei Pollin ratzfatz ausverkauft war. Hatte ja auch etwas:
ein komplettes kleines Entwicklungssystemchen mit Gehäuse,
Grafikdisplay, Tasten, Mini-Betriebssystem, Soundausgabe und so weiter -
und das alles für 4 Euro.
Ich habe in den letzten 6 Jahren immer mal wieder den diversen Leuten,
die ein Problem hier vorgetragen hatten, gezeigt, daß eben dieses
Problem bereits seit damals in besagter Lernbetty gelöst und vorgeturnt
worden ist.
Eben so, daß man daraus hätte etwas lernen können.
Das ist der Punkt.
Auch heute noch kann man daraus lernen, trotz Übergang vom Arm7TDMI zu
den Cortexen. Prinzipien, Strategien, Herangehensweisen, Problemlösungen
sind fast immer hardwareunabhängig. Man muß halt nur drauf achten, daß
man saubere Schnittstellen zwischen unten und oben in der Firmware sich
einrichtet.
Und wer partout daraus nix lernen will, der mag das nach seinem Gusto
halt bleiben lassen. Schade nur um die viele Schreibarbeit.
W.S.
W.S. schrieb:> Wärest du nicht so hochnäsig auf der einen Seite und so unverschämt und> anmaßend in deinen Stellungnahmen auf der anderen Seite wärest, sondern> sachlich und ruhig und gewillt, auch durchaus wohlmeinende Kritik als> Anlaß zu nehmen
Entschuldigung, Deine angeblich so "wohlmeinende Kritik" als 1. Posting
nach meinem Eröffnungsbeitrag lautete:
"Warum schaffen es die unixoiden Programmierer eigentlich nicht, eine
Struktur in ihre Firmware zu kriegen?"
Das klingt ganz und gar nicht wohlmeinend, das war einfach unverschämt.
Wenn Du keine Struktur siehst, dann ist das Dein Problem und nicht
meins.
> Und zu dem Zweck stelle dir vor, daß andere Forenteilnehmer es auf> PIC32, LPC17xx, Fujitsu FR30 und Sharp BlueStreak zu portieren> gedenken und dabei auch die jeweiligen ganz anderen Compiler> verwenden würden.
Schau mal in den Artikel IRMP, dann wird klar, dass Du hier schon
wieder nur schwafelst. Der von mir entwickelte IRMP läuft auf mehr
Mikrocontroller-Familien, als Du Dir jemals erträumen wirst! Ja, die
Portierung haben teilweise auch ganz normale Forumsuser geschafft! Ich
achte immer auf Portabilität, sonst würden die zum MINOS-Projekt
gehörenden Objekt-Interpreter NIC und der Compiler NICC nicht auch auf
Windows und Linux laufen. Dein altväterliches Geschwafel von "Endianess"
kannst Du Dir an den Hut schmieren, ich schreibe durchweg Programme, die
von der Endianess einer CPU unabhängig sind.
Und noch etwas: ich nehme von Dir grundsätzlich keinen Ratschlag an,
weil Du schon desöfteren gezeigt hast, dass Du von C NULL bis WENIG
Ahnung hast. Du weißt noch nichtmals, was "const" in einem
Funktionsparameter bedeutet. Das sind Basics! Deine Ausführungen, wie
man "richtig" programmiert, sind lediglich Geschwafel, weil altbekannte
Gemeinplätze.
Der Unterschied zwischen uns beiden:
Ich gehe nicht mit Deiner Unwissenheit hausieren!
Du wolltest diesen Thread von vornherein kaputtmachen. Das ist Dir auch
gelungen. Gratulation!
So, der Source-Code ist hier nicht mehr verfügbar, ich habe den
Download-Link aus dem Wiki entfernt.
Ein anderer Moderator mag den Thread nun schließen, weil nun mangels
Source-Code der eigentliche Zweck des Unterforums "Projekte und Code",
Source-Code vorzustellen, hier nicht mehr gegeben ist. Ich schreibe hier
nur als User, nicht als Moderator.
Frank, bei allem Respekt: komm bitte etwas runter. Als Moderator
sowieso, aber auch als "normaler" Mensch.
Die eigenen Projekte sind wie eigene Kinder, das ist bei mir genauso. Da
ist Kritik schwer zu ertragen - auch wenn es berechtigt ist.
Mit W.S. hast du anscheinend ein Problem. Ist OK, aber trotzdem sachlich
zu bleiben wäre wünschenswert. Klärt das untereinander, geht einen Bier
trinken, kloppt euch, was auch immer.
Deinen Source von MINOS habe ich mir gestern schon und heute erneut zu
einem großen Teil reingezogen. Was soll ich sagen: ist gut und
funktional aber strukturell weder einheitlich (z.Bsp. Interface von UART
und I2C) noch gut wartbar / anpassbar (defines echt überall, zwar viele
einzelne Dateien aber ohne durchgehende Struktur - IM SINNE VON
ANWENDUNGSSSCHICHTEN. Muss ja nicht OSI sein, aber die Grundidee
dahinter sollte man schon anwenden. Auch als Hobbyist...
Man sieht, dass du viel Programmiererfahrung hast, keine Frage. Aber das
heisst noch lange nicht, dass man es nicht deutlich besser machen kann.
Ich persönlich programmiere beruflich Hardware auch seit 23 Jahren, und
habe trotzdem nie aufgehört meine Arbeitsweise, Codestruktur und
Methodik zu verbessern. Bis heute! Natürlich könnte ich mich auch
aufblasen, und auf die recht nette Anzahl und offensichtliche Qualität
meiner in den letzten zwei Jahrzehnten fertiggestellten Projekte
verweisen. Ist aber nicht Sinn der Sache. Als Programmierer Eitel zu
sein steht einem definitiv mehr im Weg als es - wenn überhaupt - hilft.
Just my 2 cents...
TrollJäger schrieb:> Mit W.S. hast du anscheinend ein Problem.
Mit oberlehrerhaftem Gehabe habe ich ein Problem, ja. Der Typ hat
überhaupt kein Recht, anderen immer seine Meinung aufzuzwingen. Tut er
aber in vielen Threads in diesem Forum. Ich habe ihn wohl in der
Vergangenheit wohl zu oft in anderen Threads korrigiert, so dass er nun
meint, er müsste hier mal zurückschlagen.
Und wenn er meint, ich müsste mein Programm so schreiben, wie er es
will, dann soll er mich bezahlen oder einfach die Klappe halten. Aber
nein, ich würde mich von ihm nicht bezahlen lassen. So bleibt nur noch
die letzte Alternative übrig. Aber daran hält er sich nicht, sondern
wiederholt hier immer wieder aufs Neue sein Geschwafel. Warum wohl?
Deshalb schrieb ich weiter oben:
"Ich schreibe in meiner Freizeit freie Programme, weil ich die Freiheit
habe, diese Programme so zu schreiben wie ich es möchte und zwar so,
dass ich Spaß daran haben kann."
Diese Freiheit kann und darf ein Oberlehrer wie W.S. mir nicht
nehmen.
Er ignoriert das aber und lamentiert trotzdem wieder dasselbe Zeug.
> Man sieht, dass du viel Programmiererfahrung hast, keine Frage. Aber das> heisst noch lange nicht, dass man es nicht deutlich besser machen kann.
Natürlich kann man es besser machen, das steht außer Frage. Projekte,
die ich beginne, laufen über viele Jahre, werden laufend verbessert und
erweitert - und auch auf andere µCs portiert. Das WordClock-Projekt
begann 2009 und heute noch wird die Software geflegt und immer wieder
nach User-Wünschen erweitert. Dabei ist das Interesse daran hier im
Forum bis heute ungebrochen. Jedoch entstehen neue Strukturen erst bei
neuen Anforderungen. Solange diese nicht gegeben sind, sehe ich es auch
nicht notwendig an, diese Strukturen von vornherein vorzusehen,
jedenfalls nicht in einem Hobby-Projekt. In dem Code steckt jede Menge
Arbeit. Und vielleicht findet überhaupt niemand Interesse, dann wäre das
vorsorgliche Einziehen einer Abstraktionsschicht verlorene Arbeit. Daher
gehe ich da in meiner Freizeit pragmatisch vor.
Im Moment läuft MINOS nur auf einem STM32F407VE. Sollte dies mal anders
sein, wird man eine Zwischenschicht einziehen müssen, klar. Aber ich
mache das nicht unbedingt direkt von vornherein, das erählt hier nur
W.S., dass man das so machen müsse, obwohl er seine Lernbetty nie auf
etwas anderes portiert hat als eine schnöde Fernbedienung und auch nie
auf etwas anderes portieren wird. Und es spricht auch niemand darüber,
nur er packt seine Lernbetty immer und immer wieder in diversen Threads
aus und preist sie wie von Gott gegeben. Da kann einem nur schlecht
werden.
> Ich persönlich programmiere beruflich Hardware auch seit 23 Jahren, und> habe trotzdem nie aufgehört meine Arbeitsweise, Codestruktur und> Methodik zu verbessern.
Da geht es mir natürlich nicht anders.
> Bis heute! Natürlich könnte ich mich auch> aufblasen, und auf die recht nette Anzahl und offensichtliche Qualität> meiner in den letzten zwei Jahrzehnten fertiggestellten Projekte> verweisen. Ist aber nicht Sinn der Sache. Als Programmierer Eitel zu> sein steht einem definitiv mehr im Weg als es - wenn überhaupt - hilft.
Ich bin noch nie mit meinen Projekten hausieren gegangen, bis auf diesen
Thread, nämlich weil ein Gast namens "Trolljäger", von dem ich hier noch
nie etwas gelesen habe, augenscheinlich ohne jegliche Argumentation ...
nur so zum Zeitvertreib ... erstmal in dasselbe Horn bläst wie W.S. Und
weil er den ganzen Sermon nochmals wiederholt, wurde ich ein wenig
sauer. Nichts gegen Dich persönlich, aber das war mein gestriger
Eindruck nach Deinem erstmaligen Auftreten hier.
Hallo,
MINOS würde mich auch interessieren, aber ich bekomme es einfach nicht
ans laufen. Ist das HEX-File auf dieser Seite noch aktuell? Ich habe
Minos-STM32F407VET.hex mit dem STM32Cube-Programmer auf das
STM32F407VET6 Black Board geflasht (alle 3 Schnittstellen USB, UART und
ST-Link) es gab auch jedes Mal das OK beim Verify. Wie komme ich nun auf
die Konsole? Versucht habe ich über Putty, minicom und Screen. An
Betriebssystemen habe ich WinXP, Win7, Raspbian Stretch und (K)ubuntu
18.04 zur Verfügung. Das Board scheint iO (MicroPython läuft problemlos
mit screen und minicom auf /dev/ttyACM0).
Danke
Erik
Erik D. schrieb:> Ist das HEX-File auf dieser Seite noch aktuell?
Ja.
> Wie komme ich nun auf die Konsole?
Die Console läuft auf UART2 vom STM32 - mit 115200 Bd.
Frank M. schrieb:> Erik D. schrieb:>> Ist das HEX-File auf dieser Seite noch aktuell?>> Ja.>
Mal eine (vermutlich ganz dumme) Frage:
Wo finde ich diese HEX-Datei (Minos-STM32F407VET.hex)?
Auch im Artikel kann ich diese nicht entdecken.
Danke!
Thomas
Erik D. schrieb:> vielen Dank, funktioniert, wäre ich von selber aber nie drauf gekommen.
Stimmt, vor lauter Dokumentation habe ich dieses kleine aber wichtige
Detail vergessen ;-)
Hole ich im Artikel nach.
Thomas S. schrieb:> Wo finde ich diese HEX-Datei (Minos-STM32F407VET.hex)?> Auch im Artikel kann ich diese nicht entdecken.
Diese ist jetzt wieder im Artikel MINOS unter Download zu finden.
Frank M. schrieb:> Thomas S. schrieb:>> Wo finde ich diese HEX-Datei (Minos-STM32F407VET.hex)?>> Auch im Artikel kann ich diese nicht entdecken.>> Diese ist jetzt wieder im Artikel MINOS unter Download zu finden.
Danke!
Hallo! Leider scheint mir dieser Beitrag vor ca 2,5 Jahren spurlos an
mir vorbei gegangen zu sein. Allerdings scheint MINOS das zu sein, was
ich mir selbst schon mal gewünscht hatte, ein kleines, *ix ähnliches
Betriebsystem (zumindest eine Shell) welches auf Cortex-M4 oder höher
läuft. Auch eine "eigene" Programmiersprache finde ich ganz toll. Gab es
denn hier eine Weiterentwicklung? Unter welcher Lizenz steht den der
Quelltext und kann man (noch) auf diesen zugreifen?
Und bitte: Mir geht es jetzt wirklich nicht darum, ob das ganze Projekt
industrietauglich ist oder nicht! Ich finde die Idee einfach gut!
Bitte nicht wieder die vermeintliche Code-Qualität diskutieren!
Ich hätte noch STM32F4 und STM32F7 Discovery Boards hier (mit Display,
SDCard, SDRAM und externen Flash). Evtl. würde MINOS (mit etwas Aufwand)
darauf laufen...
Klaus R. schrieb:> Unter welcher Lizenz steht den der Quelltext und kann man (noch) auf> diesen zugreifen?
Ursprünglich war die Lizenz GPL. Mittlerweile habe ich einige Teile -
unter anderem den TFT-Treiber - von MINOS für STECCY, den
ZX-Spectrum-Emulatur für STM32, wieder verwendet und dort unter MIT
Lizenz gestellt.
Wenn ich einen Relaunch von MINOS mache, dann wohl unter MIT-Lizenz.
Damals wurde mir die Lust und Laune, daran weiterzuarbeiten, durch W.S.
gänzlich vergällt.
> Und bitte: Mir geht es jetzt wirklich nicht darum, ob das ganze Projekt> industrietauglich ist oder nicht! Ich finde die Idee einfach gut!
Industrietauglich ist es sicher nicht. Dafür war es auch nicht gedacht.
Eher was zum Experimentieren, Spielen und Erweitern.
> Ich hätte noch STM32F4 und STM32F7 Discovery Boards hier (mit Display,> SDCard, SDRAM und externen Flash). Evtl. würde MINOS (mit etwas Aufwand)> darauf laufen...
Ja, man könnte wohl die MINOS-Version, die ich ursprünglich für das sehr
preisgünstige STM32F407-Blackboard erstellt habe, auf die teureren
Discovery-Boards portieren. Am Blackboard hängt dasselbe 7" TFT-Display,
welches ich auf für STECCY verwende. Dafür habe ich mittlerweile
auch eine simple Adapterplatine gemacht, so dass man das BlackBoard
einfach auf das SSD1963-TFT aufstecken kann - egal, ob in der 5 oder
7-Zoll-Variante.
Ich werde MINOS in den nächsten Tagen auf github bereitstellen. Wenn
Du Lust und Laune hast, können wir uns auch gemeinsam an den Port aufs
Discovery-Board machen.
Eine Bereitstellung von MINOS auf github wäre super. Ich schaue zzt. ob
die Blackboards lieferbar wären, wahrscheinlich dauert das im Moment ein
paar Wochen mit der Lieferung (aus China). Europäische Händler, die
liefern können, sind zzt. rar (habe auf EBay nichts brauchbares
gefunden).
Klaus R. schrieb:> Ich schaue> zzt. ob die Blackboards lieferbar wären, wahrscheinlich dauert das im> Moment ein paar Wochen mit der Lieferung (aus China). Europäische> Händler, die liefern können, sind zzt. rar (habe auf EBay nichts> brauchbares gefunden).
Ich habe hier einige Blackboards rumliegen und könnte Dir eines
schicken, wenn Du möchtest.
Vielleicht eine kleine Anregung aus Sicht eines Programmierers. Ich kann
schon in gewisser Weise nachvollziehen, das für so ein Projekt eine
eigene Programmiersprache wie NIC entworfen wird.
Allerdings wäre es meiner Meinung nach sinnvoller auf bekannte
Programmiersprachen wie z.B. MicroPython oder Lua zu setzen, auch wenn
diese nicht immer optimal sind.
Einerseits weil diese Sprachen von einer großen Community verwendet und
weiter entwickelt werden und damit auch Bugs zeitnah gefixt werden und
andererseits weil Programmierer dann nicht die x. Programmiersprache neu
lernen müssen.
Außerdem gibt es für Lua und Python sehr gute Entwicklungsumgebungen
kostenlos wie z.B. Visual Studio Code mit Syntax highlighting und
Refactoring etc.
T. B. schrieb:> Allerdings wäre es meiner Meinung nach sinnvoller auf bekannte> Programmiersprachen wie z.B. MicroPython oder Lua zu setzen, auch wenn> diese nicht immer optimal sind.
Als ich 2017 damit begann, NIC zu entwickeln, war MicroPython noch gar
kein Thema, jedenfalls hier. Ich wollte damals einfach mal selbst einen
Compiler für eine einfache, Basic-ähnliche Sprache schreiben, mehr
nicht. Mittlerweile ist die ganze Sache zeitlich überholt worden, u.a.
durch die Entwicklung von MicroPython oder auch Weiterentwicklung von
LUA.
Diese Tatsache erhöht nicht gerade meine Motivation, hier irgendetwas
weiterzutreiben. Ich möchte auch nicht, das NIC & MINOS in eine Ecke
geschoben werden wie z.B. das bo8-Projekt von Josef - durch Kommentare
wie zum Beispiel:
Wozu braucht man das?
Von daher liegt das ganze Projekt seit der Veröffentlichung Ende 2018 in
der Schublade. Und vielleicht ist es besser, dass es darin bleibt.
Damals wurde das auch nicht als fertiges Projekt vorgestellt, sondern
als erster Prototyp, der weiterentwickelt werden sollte - nach den
Anfordernissen der User. Als Entwickler hat man ja - wie viele wissen -
manchmal auch ein Brett vor dem Kopf, was die Praxis anbelangt.
Mittlerweile sind zweieinhalb Jahre vergangen, ohne dass es weiterging -
einfach, weil ich keinen weiteren (teils gerechtfertigten, teils
ungerechtfertigten) Kritiken von zum Beispiel W.S. ausgesetzt werden
wollte. Da habe ich dann einfach etwas anderes gemacht - wie zum
Beispiel STECCY entwickelt, wobei einige Module aus MINOS für
STECCY weiterverwendet werden konnten. Diese für MINOS verlorene Zeit
ist jetzt wohl nicht mehr einholbar.
> Einerseits weil diese Sprachen von einer großen Community verwendet und> weiter entwickelt werden und damit auch Bugs zeitnah gefixt werden und> andererseits weil Programmierer dann nicht die x. Programmiersprache neu> lernen müssen.
Ich frage mich nur, was MicroPython mit MINOS am Hut hat. Wenn ich das
richtig verstanden habe, läuft MicroPython mehr oder weniger auf Bare
Metal. Das mit der x-ten Programmiersprache sehe ich auch ein, außerdem
ist die Manpower dort wesentlich höher.
Damals dachte ich noch, mit der Vorstellung an dieser Stelle ein paar
Leute zu begeistern und eventuell auch ein Entwickler-Team zu gewinnen -
so wie ich es schon einmal mit dem fli4l-Projekt (bzw. später eisfair)
als Gründer geschafft habe. Das ist leider durch die vorzeitige,
vollkommen überzogene und oberflächliche Kritik verhindert worden.
[Reihenfolge verändert]
Frank M. schrieb:> Damals dachte ich noch, mit der Vorstellung an dieser> Stelle ein paar Leute zu begeistern und eventuell auch> ein Entwickler-Team zu gewinnen -
Ich denke, diese Chance besteht immer noch. Hängt natürlich
auch etwas von DEINER Bereitschaft ab... :)
> Das ist leider durch die vorzeitige, vollkommen> überzogene und oberflächliche Kritik verhindert worden.
Ich kann Deine damalige Reaktion SEHR gut verstehen;
unsachliche Kritik kann sehr kränkend sein.
Andererseits: Du musst Dir nicht jede Jacke anziehen,
mit der Dir irgendjemand vor der Nase herumwedelt.
(Zumal die "Kritik" damals m.E. inhaltlich fehlging:
Am Reissbrett planen kann man nur die Implementierung
BEKANNTER Lösungsprinzipien für BEKANNTE Probleme. Je
höher der Innovationsgrad, desto unmöglicher die Planung.
Wer es dennoch versucht, wird mit Wasserfallmodell nicht
unter 20 Jahren bestraft. Aber das nur nebenbei.)
> T. B. schrieb:>> Allerdings wäre es meiner Meinung nach sinnvoller auf>> bekannte Programmiersprachen wie z.B. MicroPython oder>> Lua zu setzen, auch wenn diese nicht immer optimal sind.>> Als ich 2017 damit begann, NIC zu entwickeln, war> MicroPython noch gar kein Thema, jedenfalls hier. [...]> Mittlerweile ist die ganze Sache zeitlich überholt> worden, u.a. durch die Entwicklung von MicroPython> oder auch Weiterentwicklung von LUA.
Also... ich weiss nicht.
Ich schicke voraus, dass ich mich mit Micropython und
LUA nicht auskenne.
Ich sehe da ein grundsätzliches Problem. Übliche Sprachen
gehen von einer sequenziellen Maschine mit einem "Aus-
führungspfad" aus: Das Programm schreibt vor, welche
Aktionen wie oft in welcher Reihenfolge ausgeführt werden,
und allfällige Ein- und Ausgaben machen den Bediener zum
Sklaven der CPU: Sie haben dann zu erfolgen, wenn sie für
den Programmablauf notwendig sind. Wann das ist, schreibt
das Programm vor. (Ich weiss, dass das stark vereinfacht
ist.)
Für Steuerungsanwendungen ist diese Sichtweise aber
überhaupt nicht adäquat. Dort gibt es in der Regel viele
Baugruppen außerhalb des Mikrorechners, die ihre eigenen
Verhaltensgesetze, ihre eigenen Abläufe und ihre eigenen
realen Zustände haben. Hier muss eine Umkehrung statt-
finden: Die CPU muss zum Sklaven der äußeren Prozesse
werden. Sie muss die äußeren Zustände abfragen, die für
die vorliegende Kombination von Umständen passende
Verhaltensregel ermitteln und die notwendigen Folge-
aktionen auslösen.
Da es hier TATSÄCHLICH eine Vielzahl von Komponenten
gibt, die TATSÄCHLICH viele Dinge parallel machen, KANN
es keinen "Ausführungspfad" geben. Deshalb sind m.E.
die klassischen Programmiersprachen in dieser Anwendung
immer irgendwie Krampf.
Nun gibt es durchaus Sprachen, die diese Idee umsetzen.
Eine ist VHDL. Ohne mich damit in der Tiefe auszukennen
hege ich jedoch gewisse Zweifel, ob man eine µC-Steuerung
ausgerechnet mittels VHDL programmieren möchte :)
Eine andere solche Sprache ist AWL, verwendet in SPS. Mein
Kontakt damit beschränkt sich auf ein paar Wochen in der
Ausbildung; an Erkenntnissen habe ich daraus mitgenommen:
1. Viele Grundideen sind m.E. sehr gut und verdienen
Beachtung.
2. Die Syntax ist vorsintflutlich.
Außerdem gibt es noch Scratch. Nach dem, was ich so
aufgeschnappt habe, sind viele Konzepte interessant, aber
die starke Orientierung auf Graphik statt auf textuelle
Beschreibung steht dem ernsthaften Einsatz auf sehr kleinen
Maschinen im Wege.
Ich sehe hier also durchaus Handlungsbedarf...
Ach so: Objektorientierung ist m.E. -- wenn überhaupt -- nur
ein Teilschritt zur Lösung.
Och Leute! Jetzt fangt halt nicht wieder an, das Projekt zu zerreden! Es
ist manchmal wirklich nett, bei einem Projekt "einzusteigen", wenn es
noch nicht so komplex ist. Ja, evtl. ist es eine Spielerei, ja evtl.
wäre ein µLinux mit einem Lua Interpreter schon praxistauglicher... aber
warum muss man immer nach dem Nutzen fragen? Hätte das Adam Dunkels mit
seinem BASIC auch gemacht, hätte er es vielleicht nie veröffentlicht.
Irgend jemand hat das Projekt dann aufgegriffen und weiterentwickelt.
Oder Fabrice Bellard mit dem tcc? Charles Moore hatte mit Forth eine
nette Idee und diese hat auch im MSR Bereich etliche Anhänger gefunden.
Sein GA144 Chip war dann doch recht "eigenwillig". Aber wenn er das Geld
und die Zeit hat, kann er doch so viele "eigenwillige" Chips designen
wie er will. Ich muss ihn ja nicht programmieren. Man muss nicht immer
nach der "sinnvollen Anwendung" eines Projektes fragen. Auch Erwachsene
dürfen "spielen". Es kann auch sein, dass ich mir MINOS ansehe und dann
merke, ist doch nichts für mich! Aber ich kann doch nicht den Sinn des
ursprünglichen Autors in Frage stellen! Jeder kann für sich entscheiden,
ob ihm ein Projekt liegt/motiviert/weiterbringt. Aber dann gleich für
alle in Abrede zu stellen, dass es nichts bringt?
Lange Rede, kurzer Sinn: Ich würde mir wirklich gerne MINOS ansehen bzw.
ausprobieren.
Klaus R. schrieb:> Jetzt fangt halt nicht wieder an, das Projekt zu zerreden!
Hat Egon nicht, das musst Du falsch verstanden haben. Hast Du meine
Antwort-Mail bekommen?
Also ich finde das Projekt auch interessant, und würde mir das auch gern
mal anschauen.
Und W.S. einfach ignorieren!
Meine Projekte hat er auch versucht kaputt zu reden.
Frank M. schrieb:> Hat Egon nicht, das musst Du falsch verstanden haben. Hast Du meine> Antwort-Mail bekommen?
Ich habe dabei gar nicht Egon gemeint! Eher die Aussagen von T.B. und
deine Reaktion darauf mit dem Satz
Frank M. schrieb:> Und vielleicht ist es besser, dass es darin bleibt.
Frank M. schrieb:> wobei einige Module aus MINOS für> STECCY weiterverwendet werden konnten. Diese für MINOS verlorene Zeit> ist jetzt wohl nicht mehr einholbar.
Wenn ich so bedenke, welche Spiele auf diesen kleinen Kisten bereits
liefen, z.B. montezumas-revenge, um einmal eines zu nennen. Andere Leute
verprasssen viel Zeit beim Spielen, in der Spielhölle, oder sonstiges.
Als verlorene Zeit würde ich das daher nicht sehen, weil die dabei
gewonnenen Erfahrungen, Lernerfolge und Fehlschläge, kamen Dir bei
Steccy sicherlich wieder zugute.
Nach zweieinhalb Jahre "MINOS-Abstinenz" gibt es nun ein erstes Release
0.9.0 auf github:
https://github.com/ukw100/MINOS
Release 0.9.0 incl. fertige HEX-Files:
https://github.com/ukw100/MINOS/releases/tag/0.9.0
Änderungen/Erweiterungen:
- ILI9341 TFT-Support zusätzlich zum SSD1963 TFT-Support
- Vereinheitlichung I2C- und UART-Schnittstellen
- I2C-Libs für RTC, EEPROM und Text-Display hinzugekommen
- Kleinere Bug-Fixes
MINOS läuft auch ohne TFT Display. Daher gibt es nun 3 HEX-Files:
- MINOS mit ILI9341
- MINOS mit SSD1963
- MINOS ohne TFT display
Den Artikel MINOS habe ich soweit aktualisiert. Allerdings sind die
TFT-Funktionen noch unvollständig dokumentiert. Das werde ich im Zuge
der Übersetzung der Doku auf GitHub dann nachholen.
Viel Spaß!
Und schon gibt es ein Update. Durch einen blöden Tippfehler beim Bauen
des Releases wurde der ILI9341-Treiber deaktiviert.
Ist jetzt korrigiert in 0.9.1:
https://github.com/ukw100/MINOS/releases/tag/0.9.1
Schön, dass es weitergeht!
Wenn du komplett langeweile hast, kannste das ja mal für den MIPS TTL
Rechner "Spaceage 2" portieren ;)
Wobei ich mir sicherlich deine Programme wie den Editor und die Shell
ansehen werde.
Das soll eh noch implementiert werden, aber man muss ja nich alles
komplett von vorne neuschreiben.
Es soll allerdings ein echtes Multitasking OS mit Prozessen später auf
dem Gerät laufen.
Was nur etwas nervt ist, dass ein echtes VT100/101 keine Zeichen löschen
kann mit Zeichennachrückung in der Zeile, bzw insert.
Was bei meinem Eigenbau CMDline Mailprogramm schon ein echter
showstopper is :/
Den Fußpilz werde ich beim Einbau deines Editors sicher auch nochmal
bekommen.
(Komplette Zeile und alles danach neuschreiben is bei 9600Baud
laaangsaaam)
Mw E. schrieb:> Was nur etwas nervt ist, dass ein echtes VT100/101 keine Zeichen löschen> kann mit Zeichennachrückung in der Zeile, bzw insert.
Geh mal davon aus, dass die heutigen Terminal-Emulationen alle VT200/220
beherrschen, auch wenn sie sich "VT100-Emulation" schimpfen. Da
funktioniert das mit Löschen und Einfügen eines Zeichens innerhalb einer
Zeile auch.
Insert-Modus ein:
1
\033[4h
Insert-Modus aus:
1
\033[4l
Also Zeichenkette XYZ einfügen:
1
\033[4hXYZ\033[4l
Wenn man das ganz geschickt macht, schaltet man erst wieder auf den
Replace-Mode zurück, wenn wirklich Zeichen wieder überschrieben werden
müssen. Spart 4 Bytes ;-)
Zeichen auf Cursor-Position löschen:
1
\033[P
Alles rechts vom Cursor wandert auch automatisch nach links.
Der Mini-Editor im MINOS benutzt zur Terminalsteuerung MCURSES,
das verwendet die obengenannten Sequenzen - mit der oben genannten
Optimierung für Insert/Replace. Funktioniert bisher überall, womit ich
das getestet habe. Ebenso geht das mit Zeilen löschen/einfügen - unter
Nutzung der Scrolling-Regions.
Hier eine kleine MCURSES-Demo:
http://www.mikrocontroller.net/wikifiles/e/ed/Mcurses.avi
Frank M. schrieb:> Geh mal davon aus, dass die heutigen Terminal-Emulationen alle VT200/220> beherrschen, auch wenn sie sich "VT100-Emulation" schimpfen. Da> funktioniert das mit Löschen und Einfügen eines Zeichens innerhalb einer> Zeile auch.
Weis ich, die Codes kenn ich auch alle.
Du hast nur eben ein Problem wenn du "VT100 kompatibel" programmierst
und ein echtes VT100 das einfach nicht macht.
Laut Anleitung kanns das auch nicht, erst das VT200.
Is mir ja so passiert beim Mailprog auf dem MIPS TTL.
Ist denn im MINOS auch Netzwerk geplant?
Dann ließe sich ja das Mailprogramm mal portieren auf MINOS.
Vorher muss ich da aber noch aufräumen und auch mal auf m/ncurses
aufbauen.
Das sieht an vielen Stellen noch experimentell und gruselig aus.
Das basiert auf der lowlevel Event API vom lwip.
Mw E. schrieb:> Ist denn im MINOS auch Netzwerk geplant?
Ich überlege, einen ESP8266 optional als Kommunikationscontroller
anzuflanschen, so wie ich das bei WordClock mit WS2812 gemacht habe.
Dann kann man:
- per Telnet auf die MINOS-Console zugreifen
- über OTA ("over the air") den STM32 flashen/updaten
- Ein Web-Interface vorschalten
- den STM32 Netzwerkverbindungen z.B. NTP aufnehmen lassen
- das aktuelle Wetter über openweathermap.org abholen und anzeigen
Diese Punkte sind in WordClock mit WS2812 bereits umgesetzt, man
kann sogar mit seinem Handy auf der WordClock Snake oder Tetris spielen
;-)
WordClock-Updates kann man ebenso direkt übers Internet vom Webserver
auf dem STM32 einspielen.
Auch für SMTP sehe ich da kein Problem, um ein paar kleine Mails
rauszuschicken.
Ok, ich konnte MINOS unter Linux kompilieren. Allerdings musste ich die
Dateien unter SPL/src und SPL/inc nach src/spl kopieren, damit mein
Makefile durch lief. Zum flashen habe ich st-link/st-flash (ursprünglich
von texane) benutzt: https://github.com/stlink-org/stlink, dazu ein
ST-Link von einem STM32L476 Nucleo.
Klaus R. schrieb:> Ok, ich konnte MINOS unter Linux kompilieren.
Gratuliere! :-)
> Allerdings musste ich die> Dateien unter SPL/src und SPL/inc nach src/spl kopieren, damit mein> Makefile durch lief.
Das könnte man wahrscheinlich auch durch einen entsprechenden
Include-Pfad hinbekommen. Aber danke schonmal für das Makefile, ich
schaue in den nächsten Tagen, wie man das anpassen kann, dass es auch
mit separatem SPL-Pfad kompiliert.
Frank M. schrieb:> Gratuliere! :-)
;-)
Wie lange hast du eigentlich für MINOS gebraucht? wc zählt in src rund
70k LOC, auch wenn vermutlich nicht alles von dir ist. Das ist schon
eine reife Leistung, ich würde wohl Jahre brauchen. Lob!
Im Anhang noch ein neues Makefile, dass den Quelltext ohne Änderungen
kompiliert. Ich habe (X)Ubuntu 20.04 verwendet und gnu make sowie
arm-none-eabi-gcc muss installiert sein. Das Makefile liegt direkt im
MINOS Verzeichnis. Trotz -Os -ffunction-sections -fdata-sections und
--gc-sections ist "mein" binary deutlich größer: minos.bin 148k und
minos.hex 416k. Da wird wohl etwas mehr hinzugelinkt.
Was das Makefile (noch) nicht macht, ist die TFT-Varianten von MINOS zu
bauen. Auch schmeißt der arm-gcc (7.2.1 ist bei XUbuntu 20.04 im Repro)
ein paar Warnings bei -Wall:
Dieser ist relativ einfach zu beheben:
Klaus R. schrieb:> Wie lange hast du eigentlich für MINOS gebraucht?
Och, das ging über einige Monate - aber nicht kontinierlich, sondern
nur, wenn ich mal wieder Luste hatte.
> wc zählt in src rund 70k LOC, auch wenn vermutlich nicht alles> von dir ist.
fatfs ist von Elm Chan, der Rest von mir.
Klaus R. schrieb:> Im Anhang noch ein neues Makefile, dass den Quelltext ohne Änderungen> kompiliert.
Sehr gut. :-)
> Trotz -Os -ffunction-sections -fdata-sections und> --gc-sections ist "mein" binary deutlich größer: minos.bin 148k und> minos.hex 416k. Da wird wohl etwas mehr hinzugelinkt.
Kann sein, dass ich mit LTO linke, muss ich nachsehen.
> Man könnte nun einfach> unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];>> schreiben, aber evtl. irrt hier der gcc.
Nein, der gcc irrt nicht. Korrekt wäre:
Begründung:
Durch das Format "%s.%s" benötigt der String varname insgesamt Platz für
- 1x Funktionsname
- 1x Punkt
- 1x Variablenname
- 1x Terminierung mit \0
Ích werde das korrigieren und mit ins nächste Release nehmen.
> Welchen Version des gccs verwedest du?
Noch den relativ alten gcc 5.4.1, der mit EmBitz 1.11 ausgeliefert wird.
Ich werde mal die aktuelle Toolchain unter Linux installieren und das
mit Deinem Makefile übersetzen.
Danke für die Hinweise :-)
Ich habe eben arm-none-eabi-gcc 7.3.1 unter Linux installiert und das
Makefile direkt ausprobiert. Läuft nach den Korrekturen in nicc.c und
system_stm32f4xx.c (überflüssiges Semikolon entfernt) ohne Murren durch.
Die Änderungen inklusive Makefile sind bei github eingescheckt, ein
neues Release habe ich auf github aber noch nicht erstellt. Mache ich im
Laufe des Abends.
Das Makefile hatte noch Probleme, wenn es um die Abhängigkeiten geht.
Änderungen in den Header Dateien wurden nicht erkannt. Das konnte
mittels kompilieren mit -MMD behoben werden.
Hallo Frank,
Dein MINOS scheint genau die Milch-gebende-Eier-Sau zu sein, die mir
schon lange vorschwebte.
Da ich kein begnadeter Programmierer bin (Hardware liegt mir mehr),
würde ich das vergefertigte HEX-File verwenden wollen.
Jetzt bin ich mir nicht 100% sicher, ob ich das richtige Board erwischt
habe.
Ist ja schon einige Zeit her, seitdem Du daran gearbeitet hast und
vielleicht hat sich in der Zwischenzeit ja auch etwas an der Hardware
der jetzt käuflichen Boards geändert.
Ist das, im Anhang angehangene Board, "Dein" Board?
Den Schaltplan dafür habe ich gefunden und kann damit mein, seit x
Monden unbenutztes, F4(07VGT6)-Discovery verwenden.
OK, das Discovery hat mehr RAM, aber das sollte keine Rolle spielen.
Großer Dank für dieses Projekt!
Gruss ...IG
Hallo Frank,
Danke für die schnelle Antwort. :-D
Jetzt juckt es mir schon richtig in den Fingern!
(Leider C*r*na schon vorbei und auch noch warm draußen.)
Gruss ...IG
ich habe mir das Projekt auch noch mal angesehen, ich finde den Umfang
der eingebauten Kommandos sehr gut. So eine Shell einfach als Komponente
in ein Projekt zu übernehmen wäre schon cool, dafür ist MINOS aber noch
etwas zu monotlithisch gebaut. Also z.b. das im cmd eine lange Kette von
strcmp() das Kommand sucht, was alles im Code im passiert, aber damit
auch sofort viele Abhängigkeiten hat. Da würde ich mit einer
Modularisierung ansetzen, dann kann man z.B. über ein Modul Filesystem
Kommandos, Systemkommandos, HW oder sonstiges hinzufügen.
Frank M. schrieb:> Ich überlege, einen ESP8266 optional als Kommunikationscontroller> anzuflanschen, so wie ich das bei WordClock mit WS2812 gemacht habe.
So kann man das auch machen.
Wobei ich es schöner fände wenn ein "OS" direkt Sockets anbietet.
Das durch den ESP durchzuleiten wird doch etwas anstrengender als direkt
MAC/PHY anzuschließen?
(oder eben eine Evente API wie beim threadless lwip)
Johannes S. schrieb:> Also z.b. das im cmd eine lange Kette von> strcmp() das Kommand sucht, was alles im Code im passiert, aber damit> auch sofort viele Abhängigkeiten hat. Da würde ich mit einer> Modularisierung ansetzen, dann kann man z.B. über ein Modul Filesystem> Kommandos, Systemkommandos, HW oder sonstiges hinzufügen.
Wär auch garnicht so schwer, da könnt man etwas in die Richtung POSIX
gehen.
Der cmd Parser kennt nur callbacks (int main(int argc, const char*
argv[])) sowie nen kurzen String mit dem Namen.
Somit muss die cmd nurnoch die Tokens erkennen und in das altbekannte
Format packen.
Dann den passenden Callback aufrufen und die Argumente übergeben.
Die einzelnen "Programme" klamüsern sich dann die Argumente per getopt
in ihre interne Funktionalität.
Johannes S. schrieb:> Also z.b. das im cmd eine lange Kette von strcmp() das Kommand sucht,> was alles im Code im passiert, aber damit auch sofort viele> Abhängigkeiten hat. Da würde ich mit einer Modularisierung ansetzen,> dann kann man z.B. über ein Modul Filesystem Kommandos, Systemkommandos,> HW oder sonstiges hinzufügen.
Da hast Du vollkommen recht, das kann man allgemeiner gestalten. Ich
setze das auf die TODO-Liste.
Mw E. schrieb:> Frank M. schrieb:>>> Ich überlege, einen ESP8266 optional als Kommunikationscontroller>> anzuflanschen, so wie ich das bei WordClock mit WS2812 gemacht habe.>> So kann man das auch machen.> Wobei ich es schöner fände wenn ein "OS" direkt Sockets anbietet.
Stimmt schon, das wäre natürlich optimal. Ich denke darüber nach.
> Das durch den ESP durchzuleiten wird doch etwas anstrengender als direkt> MAC/PHY anzuschließen?
Nun, die dafür nötige SW habe ich bereits vor Jahren für die
WordClock mit WS2812 erstellt.
Der angeflanschte ESP8266
- kann auf Webservern nach eigenen und STM32-Updates suchen
- kann sich selbst aktualisieren
- kann den STM32 per STM32-Bootloader aktualisieren
- hat eine Web-Oberfläche für diverse Einstellungen
- kann über die Web-Oberfläche Updates auch lokal einspielen
- kann Webservices (z.b. OpenWeatherMap) nutzen und weiterleiten
- dient mit seinem SPIFFS als Massenspeicher für den STM32
(letzteres ist natürlich unnötig, da hier eine SD-Karte eingesetzt wird)
Ein richtiger IP-Stack hat natürlich auch seine Vorzüge.
> Der cmd Parser kennt nur callbacks (int main(int argc, const char*> argv[])) sowie nen kurzen String mit dem Namen.
Gute Idee, klingt einfach und gut :-)
Ja, das hatteste ja schon geschrieben was der ausgelagerte
Kommunikationscontroller kann.
Dann kommt dann also noch eine Socket API dazu.
Was man hat soll man auch nutzen.
Es würde ja reichen die Ethernetframes des lwip zum ESP zu tunneln.
Insofern der ESP RAW sockets kann, das weis ich jetzt nicht.
Ein Vorzug des kleinen POSIX Umbaus beim Programme aufrufen wäre ja
auch, dass somit Programme mit dem Script aufrufbar wären.
Bisher scheints ja noch nicht zu gehen, jedenfalls sehe ich das nichti
nd er Doku und nicht in den Beispielen.
zum cmd Tokenizer und Editor kann ich dir leider kein Code geben, weil
ich das auf Arbeit geschrieben habe.
Da wirds für Testsoftwares genutzt.
Allerdings muss ichs eh nochmal reimplementieren für den MIPS TTL
Rechner.
Dabei sollen auch Pipes möglich sein, aber das hab ich noch kein Konzept
zu.
Mw E. schrieb:> Ein Vorzug des kleinen POSIX Umbaus beim Programme aufrufen wäre ja> auch, dass somit Programme mit dem Script aufrufbar wären.
Es sind bereits jetzt schon "externe" Programme aufrufbar, Du kannst
beliebige NIC-Programme aus dem Kommando-Interpreter von SD starten.
Beachte dazu den else-Zweig der strcmp-Kette.
Sonst wäre das ja witzlos. Du kannst auch eine BOOT-Datei auf der SD
ablegen. Das wird wie ein Script abgeabeitet beim Booten. Dort kann man
dann sowohl interne Kommandos als auch eigene NIC-Programme beim Powerup
oder Reset starten.
Lediglich die internen UNIX-like Kommandos wie ls, cp, mv, df usw.
werden über die strcmp-Kette gestartet - war für mich erstmal das
einfachste. Da eine Tabellen-Struktur drüberzulegen, ist wirklich nicht
schwer. ;-)
EDIT: Gerade umgeschrieben:
// Hier werden externe Programme von SD gestartet.
29
}
P.S.
Die obige Suche ist linear, bisher war die obige Schleife einfach
"ausgerollt". Da ich die internen Kommandos in der oben angedeuteten
Kommando-Tabelle in alphabetischer Reihenfolge abgelegt habe, könnte man
da auch eine Baum-Suche drüberlaufen lassen, die dann noch etwas
schneller ist. Werde ich dann so im nächsten Release veröffentlichen.
Aber das ganze ändert nichts an der Funktionalität, nach der Suche nach
internen Kommandos wird dann - wenn nicht erfolgreich - das Kommando
extern von der SD ausgeführt. Zur Zeit ist hier nur die Ausführung von
externen "Binaries" möglich, die mit dem NIC-Compiler erstellt wurden -
also keine externen C-Programme. Dafür wäre einiges mehr an Aufwand zu
treiben. Dafür müsstest Du relozierbare Binaries erzeugen, die an
beliebiger Stelle im RAM ausführbar wären. Das geht momentan nur für
NIC-Programme.
Frank M. schrieb:> könnte man> da auch eine Baum-Suche drüberlaufen lassen,
macht nur Sinn wenn man schneller tippen kann als der µC die Kommandos
findet.
Mach dir keinen Stress, das ist schon alles so programmiert das man
erkennen kann was es tun soll.
Meine Idee war C++ und als Unterbau Mbed-OS reinzubringen, da habe ich
Ethernet, USB, Storage uvm. Auch als Test ob git da noch was
zusammenhängendes erkennt wenn in einem Branch sehr vieles umgebaut
wird. Ist auch nur eine Spielerei, aber wenn ich mit wenigen Zeilen ein
Programm um eine Mini Shell erweitern kann, dann ist es vielleicht doch
ganz praktisch.
Hallo Ihr's,
nachdem heute aus dem AMAZONas 2 STM21F407VET-Boards (wie Foto weiter
oben) bei mir eintrafen, habe ich das vorgefertigte MINOS.hex geflasht &
etwas experimentiert.
Halelulia - es funktioniert !
Sehr fein!
GPIO-Tests = 158kHz - nicht schlecht!
Hatte erst einen kleinen Piezo-Summer dran und mich gewundert, warum ich
da nix höre, doch dann habe ich mich an die "Hz"-Funktion des
Multimeters erinnert. :-)
In der Zwischenzeit (also seit Entdeckung bis Board-Lieferung) habe ich
mir die Dokumentation zum Minos und NICC etwas näher betrachtet.
Shell check
Editor check
File check
GPIO check
UART check
i2c check
RTC check
spi ?
pwm ?
1wire ?
Interrupts ? (Pin bzw. z.B. UART-Event)
Adc/dac könnte man, wenn man es denn tatsächlich braucht, per i2c
realisieren.
Bitte nicht falsch verstehen, ich bin in keinster Weise ein M.ister
W.ichtig, sondern nur ein kleiner Hardware-Schmied, der nach schnellen
Lösungen für einzelne, kurzzeitige Probleme sucht.
(Minos + F407-Board = schweizer Taschenmesser)
Ich habe keine Ahnung wie aufwändig die Implementierung ist/wäre.
Das was ich bisher gesehen habe lässt mich bereits mit offenem Mund vorm
Monitor sitzen. Allein die Dokumentation der Befehle - Hut ab.
Eine kurze Info bezüglich der "?" würde mich trotzdem sehr
interessieren.
Gruss... IG
Ingolf G. schrieb:> spi ?> pwm ?> 1wire ?> Interrupts ? (Pin bzw. z.B. UART-Event)
SPI, PWM, 1Wire: Da habe ich schon etwas in der Mache. Kommt demnächst.
ADC: Steht bereits auf der TODO-Liste, kommt also auch - vermutlich nach
SPI, PWM, 1Wire.
Interrupts: Die Möglichkeiten sind hier vielfältig, momentan sind nur
Timer-Events realisiert. Die UART-Routinen arbeiten jetzt schon
Interrupt-gesteuert, es gäbe natürlich auch hier die Möglichkeit, in NIC
einen Event auszulösen, wenn neue Zeichen vorhanden sind. Denke ich mal
drüber nach.
Was ich auf jeden Fall für sinnvoll erachte, sind PinChange-Events.
Schreibe ich auf die TODO-Liste.
Hallo Frank,
Frank M. schrieb:
spi demnächst
pwm demnächst
1wire demnächst
adc über-demnächst
Interrupts über-demnächst
> Interrupts: Die Möglichkeiten sind hier vielfältig, momentan sind nur> Timer-Events realisiert. Die UART-Routinen arbeiten jetzt schon> Interrupt-gesteuert, es gäbe natürlich auch hier die Möglichkeit, in NIC> einen Event auszulösen, wenn neue Zeichen vorhanden sind. Denke ich mal> drüber nach.>> Was ich auf jeden Fall für sinnvoll erachte, sind PinChange-Events.> Schreibe ich auf die TODO-Liste.
Das klingt doch sehr gut!
Ich würde Dich ja gerne dabei unterstützen, das Einzigste-te, was mir
einfällt, wäre eine Bier-Spende. ;-)
Gruss... IG
Interessantes Projekt! Allerdings ist mir nicht klar, warum Du eine neue
Programmiersprache "NIC" dafür entworfen hast. Eine "eigene Sprache" ist
natürlich ein netter Partygag und guter Ego-Tripp (und ich denke auch,
jeder Entwickler, der was auf sich hält, sollte einmal eine Sprache plus
Compiler entworfen und implementiert haben!), erhöht aber die Motivation
nicht, sich mit MINOS auseinanderzusetzen. Properitäre Sprache lernen =
verlorene Zeit, da kein übertragbares Wissen, kein return of investment.
Warum nicht wenigstens sowas wie Great Cow BASIC das zumindest entfernte
Verwandschaft mit "etwas Bekanntem" hat? Dann hätten sich das vielleicht
mehr Leute angesehen. Na ja, kann ja noch werden!
Frank M. schrieb:> Es sind bereits jetzt schon "externe" Programme aufrufbar, Du kannst> beliebige NIC-Programme aus dem Kommando-Interpreter von SD starten.> Beachte dazu den else-Zweig der strcmp-Kette.
Entweder ich bin blind oder das steht nicht in der verlinkten Doku?
Frank M. schrieb:> Zur Zeit ist hier nur die Ausführung von> externen "Binaries" möglich, die mit dem NIC-Compiler erstellt wurden -> also keine externen C-Programme. Dafür wäre einiges mehr an Aufwand zu> treiben. Dafür müsstest Du relozierbare Binaries erzeugen, die an> beliebiger Stelle im RAM ausführbar wären. Das geht momentan nur für> NIC-Programme.
Ja leider haben Cortex-M keine MMU, damit würde so einiges gehen.
@Michael W.:
Kannst ja nan LUA Interpreter einbauen ;)
Ist garnicht mal so schwer, hab ich mal für ein anderes Projekt gemacht.
Thread beobachten
Seitenaufteilung abschalten