mikrocontroller.net

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.
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

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


:
Autor: W.S. (Gast)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
6 lesenswert
nicht 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!

Autor: W.S. (Gast)
Datum:
Angehängte Dateien:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht 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
Autor: KI-Besitzer (Gast)
Datum:

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

Autor: W.S. (Gast)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: Joerg W. (joergwolfram)
Datum:

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

Autor: A. S. (achs)
Datum:

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

Autor: Johannes S. (jojos)
Datum:

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: Zuschauer (Gast)
Datum:

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

Autor: Jan L. (ranzcopter)
Datum:

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

Autor: Zuschauer (Gast)
Datum:

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

Autor: Roland F. (rhf)
Datum:

Bewertung
1 lesenswert
nicht 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.
Autor: Johannes S. (jojos)
Datum:

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

Autor: wendelsberg (Gast)
Datum:

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

Ich bin fuer gitlab.com

wendelsberg

Autor: Ma S. (turbotorsten)
Datum:

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

Autor: m.n. (Gast)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht 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
Autor: W.S. (Gast)
Datum:

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

Autor: Jan L. (ranzcopter)
Datum:

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

Autor: Ursus (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
> Was wäre dann das Gegenteil von "unixoid"?

Professionell.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht 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
Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht 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.
Autor: TrollJäger (Gast)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht 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
Autor: W.S. (Gast)
Datum:

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

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

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

Autor: Mehmet K. (mkmk)
Datum:

Bewertung
5 lesenswert
nicht 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)?!?!?

Autor: W.S. (Gast)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht 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
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht 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
Autor: TrollJäger (Gast)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

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

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

Autor: Erik D. (erikms5)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: Erik D. (erikms5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

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

Gruß Erik

Autor: Thomas S. (doschi_)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: Thomas S. (doschi_)
Datum:

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

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.