Forum: Projekte & Code MINOS - Minos Is No Operating System


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

MINOS - Minos Is No Operating System

MINOS ist eine sehr einfache, trotzdem aber auch komfortable Firmware, welche auf einem STM32F4xx läuft.

Artikel zu diesem Projekt: MINOS

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.

Artikel zur Sprache NIC: NIC

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:

MINOS#TFT-Analoguhr
MINOS#TFT-WordClock

Den C-Source-Code von MINOS selbst sowohl die dazugehörenden HEX-Files findet ihr im Artikel unter MINOS#Download.

Viel Spaß,

Frank


:
von W.S. (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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!

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von KI-Besitzer (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Joerg W. (joergwolfram)


Lesenswert?

> 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.

von A. S. (achs)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

warum wird der Code für so umfangreiches Projekt in einer altmodischen 
Zip Datei angeboten? Github & Co. sind wesentlich besser geeignet für 
sowas.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Zuschauer (Gast)


Lesenswert?

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.

von Jan L. (ranzcopter)


Lesenswert?

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"...

von Zuschauer (Gast)


Lesenswert?

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.

von Roland F. (rhf)


Lesenswert?

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

Beitrag #5627055 wurde von einem Moderator gelöscht.
von Johannes S. (jojos)


Lesenswert?

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.

von wendelsberg (Gast)


Lesenswert?

Frank M. schrieb:
> kanns dann auch bei github & Co gehalten werden. Das ist mir persönlich
> egal.

Ich bin fuer gitlab.com

wendelsberg

von Ma S. (turbotorsten)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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?"

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von W.S. (Gast)


Lesenswert?

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.

von Jan L. (ranzcopter)


Lesenswert?

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"?

von Ursus (Gast)


Lesenswert?

> Was wäre dann das Gegenteil von "unixoid"?

Professionell.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Julian W. (julian-w) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch User
Beitrag #5653531 wurde von einem Moderator gelöscht.
Beitrag #5653562 wurde von einem Moderator gelöscht.
von TrollJäger (Gast)


Lesenswert?

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...

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von W.S. (Gast)


Lesenswert?

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.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

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.

von Mehmet K. (mkmk)


Lesenswert?

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)?!?!?

von W.S. (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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!

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von TrollJäger (Gast)


Lesenswert?

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...

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Ein anderer Moderator mag den Thread nun schließen,

Ich hab' ihn jetzt erstmal hierher, ins OT verschoben.

von Erik D. (erikms5)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Erik D. (erikms5)


Lesenswert?

Hallo Frank,

vielen Dank, funktioniert, wäre ich von selber aber nie drauf gekommen.

Gruß Erik

von Thomas S. (doschi_)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Thomas S. (doschi_)


Lesenswert?

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!

von Klaus R. (klausro)


Lesenswert?

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...

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Johannes S. (jojos)


Lesenswert?

für die Discos gibt es BSP von ST, da ist die Ansteuerung der genannten 
Komponenten drin. Damit sollte die Portierung nicht schwierig sein.

von Klaus R. (klausro)


Lesenswert?

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).

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von T. B. (bri)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Egon D. (egon_d)


Lesenswert?

[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.

: Bearbeitet durch User
von Klaus R. (klausro)


Lesenswert?

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.

von Egon D. (egon_d)


Lesenswert?

Klaus R. schrieb:

> Och Leute! Jetzt fangt halt nicht wieder an, das
> Projekt zu zerreden!

???

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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?

von Harry L. (mysth)


Lesenswert?

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.

von Klaus R. (klausro)


Lesenswert?

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.

von Klaus R. (klausro)


Lesenswert?

Frank M. schrieb:
> Hast Du meine Antwort-Mail bekommen?

Ja, ich habe auch am Freitag zurückgeschrieben! Danke!

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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ß!

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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)

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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

: Bearbeitet durch Moderator
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Klaus R. (klausro)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Klaus R. (klausro)


Angehängte Dateien:

Lesenswert?

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:
1
src/system_stm32f4xx.c: In function 'SetSysClock':
2
src/system_stm32f4xx.c:552:9: warning: this 'while' clause does not guard... [-Wmisleading-indentation]
3
         while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS ) != RCC_CFGR_SWS_PLL);
4
         ^~~~~
5
src/system_stm32f4xx.c:553:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'while'
6
         {
1
552c552
2
<         while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS ) != RCC_CFGR_SWS_PLL)
3
---
4
>         while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS ) != RCC_CFGR_SWS_PLL);

In nicc.c gefallen gcc einige "sprintf" nicht: gcc nimmt an, dass 
sprintf 34 bytes in den 33 bytes großen buffer schreibt. Man könnte nun 
einfach
1
unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];
 schreiben, aber evtl. irrt  hier der gcc. Welchen Version des gccs 
verwedest du?
1
src/nic/nicc.c: In function 'nicc':
2
src/nic/nicc.c:7012:52: warning: 'sprintf' may write a terminating nul past the end of the destination [-Wformat-overflow=]
3
                         sprintf ((char *) varname, "%s.%s", functions[current_function_idx].name, kw);src/nic/nicc.c:7012:25: note: 'sprintf' output 2 or more bytes (assuming 34) into a destination of size 33
4
                         sprintf ((char *) varname, "%s.%s", functions[current_function_idx].name, kw);

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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:
1
char varname[MAX_FUNCTION_NAME_LEN + MAX_VARIABLE_NAME_LEN + 2];
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 :-)

von Klaus R. (klausro)


Lesenswert?

Frank M. schrieb:
> Nein, der gcc irrt nicht. Korrekt wäre:char
> varname[MAX_FUNCTION_NAME_LEN + MAX_VARIABLE_NAME_LEN + 2];

Ok, hier wäre das diff:
1
6998c6998
2
<                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];
3
---
4
>                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 1];
5
7039c7039
6
<                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];
7
---
8
>                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 1];
9
7151c7151
10
<                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];
11
---
12
>                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 1];
13
7244c7244
14
<                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];
15
---
16
>                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 1];
17
7337c7337
18
<                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 2];
19
---
20
>                         unsigned char varname[MAX_VARIABLE_NAME_LEN + 1];

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Klaus R. schrieb:
> Ok, hier wäre das diff:

Nicht so vorschnell :-)

Ich schrieb:
1
char varname[MAX_FUNCTION_NAME_LEN + MAX_VARIABLE_NAME_LEN + 2];
Das "MAX_FUNCTION_NAME_LEN" fehlt bei Dir komplett.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Klaus R. (klausro)


Angehängte Dateien:

Lesenswert?

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.

von Ingolf G. (2v_xileh)


Angehängte Dateien:

Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Ingolf,

Ingolf G. schrieb:
> Ist das, im Anhang angehangene Board, "Dein" Board?

Das Board ist das richtige. Viel Spaß damit!

von Ingolf G. (2v_xileh)


Lesenswert?

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

von Johannes S. (jojos)


Lesenswert?

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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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 :-)

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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:
1
typedef struct
2
{
3
    char *  cmd;
4
    int     (*func) (int, const char **);
5
} INTERN_CMD_TABLE;
6
7
static INTERN_CMD_TABLE     intern_cmd_table[] =
8
{
9
    { "cat",        cmd_cat     },
10
    { "cd",         cmd_cd      },
11
...
12
    { "umount",     cmd_umount  },
13
};
14
...
15
    uint_fast8_t n_cmds = sizeof (intern_cmd_table) / sizeof (INTERN_CMD_TABLE);
16
17
    for (idx = 0; idx < n_cmds; idx++)
18
    {
19
        if (! strcmp (command, intern_cmd_table[idx].cmd))
20
        {
21
            rtc = (* intern_cmd_table[idx].func) (argc, argv);
22
            break;
23
        }
24
    }
25
26
    if (idx == n_cmds)
27
    {
28
        // 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.

: Bearbeitet durch Moderator
von Johannes S. (jojos)


Lesenswert?

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.

von Ingolf G. (2v_xileh)


Lesenswert?

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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Ingolf G. (2v_xileh)


Lesenswert?

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

von Michael W. (michael_w738)


Lesenswert?

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!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Mw E. schrieb:
> Entweder ich bin blind oder das steht nicht in der verlinkten Doku?

MINOS: Interpreter NIC

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.