Tja, ein BASIC für den Arduino... Bei dem Link oben sehe ich leider zwei
Probleme:
a) Der Arbeitsspeicher für das Anwenderprogramm ist mit 1 kByte RAM arg
limitiert. Ich würde heutzutage das Limit eher bei 16 oder sogar 32kByte
RAM sehen. Bzw. ginge das auch, das Anwenderprogramm in ein entsprechend
großes serielles EEPROM oder FRAM zu speichern. Das könnte man durchaus
zum editieren zeilenweise in das SRAM des Controllers laden.
b) Die Tastatur mit PS-2 Schnittstelle. Habe ich schon seit 15 Jahren
keine mehr gesehen. Ich denke, da bedarf es einer Lösung für USB oder
Bluetooth.
c) Zusammengefasst, eine Art "BASIC-Shield", mit ordentlich RAM und
Kommunikationsmöglichkeit mit einer modernen Tastatur.
Der müde Joe (Gast)
>a) Der Arbeitsspeicher für das Anwenderprogramm ist mit 1 kByte RAM arg>limitiert. Ich würde heutzutage das Limit eher bei 16 oder sogar 32kByte>RAM sehen. Bzw. ginge das auch, das Anwenderprogramm in ein entsprechend>großes serielles EEPROM oder FRAM zu speichern. Das könnte man durchaus>zum editieren zeilenweise in das SRAM des Controllers laden.
Dazu würden mir folgende Lösungen einfallen
1. MCU mit genügend Arbeitsspeicher verwenden
z.B. ESP32
https://github.com/espressif/arduino-esp32
oder STM32https://github.com/stm32duino/Arduino_Core_STM32
Oder nach alter Basic-Stamp Manier: Eine SD-Karte anschließen und das
Basic Programm von der SD-Karte ausführen. Zur Not könnte man noch einen
Cache zwischen der SD-Karte und dem Basic-Interpreter implementieren.
Für den ESP8266 gibt es auch eine Lua-Scripting Engine:
https://github.com/fdu/ESP8266-Arduino-Lua
Wobei man dort den Bytecode vermutlich auf dem PC compilieren müsste.
Ein echter Artuinohirnfurz.
Menschen mit Realitätssinn, nehmen einen PIC32 mit 128 kB RAM.
Der braucht dafür auch kein Artuinogedöhns.
Guggelsuchwort: Micromite
> dass ich einen Kassettenrecorder anschliessen kann,> um die Basic-Programme zu speichern/laden.
Dieses Problem wurde nun schon zu Z80-Zeiten allumfassend gelöst.
Guggelsuchwort: Conditioned Diphase/Manchester
lach:
>> dass ich einen Kassettenrecorder anschliessen kann,>> um die Basic-Programme zu speichern/laden.>Dieses Problem wurde nun schon zu Z80-Zeiten allumfassend gelöst.>Guggelsuchwort: Conditioned Diphase/Manchester
Wobei das beim ZX81 anders gelöst war:
Each byte consists of 8 bits (MSB first) without any start and stop
bits, directly followed by the next byte. A "0" bit consists of four
high pulses, a "1" bit of nine pulses, either one followed by a silence
period.
0: /\/\/\/\________
1: /\/\/\/\/\/\/\/\/\________
> Wobei das beim ZX81 anders gelöst war
Gut das ich den nicht hatte.
Das muss ja quälend langsam sein.
Ein einigermassen guter Recorder schaffte schon mindestens 5 kbit/s.
Mit dem "richtigen" Verfahren.
Und die Software gestaltete sich auch wesentlich einfacher.
lach schrieb:>> Wobei das beim ZX81 anders gelöst war> Gut das ich den nicht hatte.> Das muss ja quälend langsam sein.>> Ein einigermassen guter Recorder schaffte schon mindestens 5 kbit/s.> Mit dem "richtigen" Verfahren.> Und die Software gestaltete sich auch wesentlich einfacher.
War vor 40 Jahren mein erster Computer. Ja, quälend langsam, ca 300
Baud. Aber wer Retro-Feeling möchte, der muss leiden.
Wer wirklich damit arbeiten mußte, der möchte das nicht wieder haben.
lach schrieb:> Ein einigermassen guter Recorder schaffte schon mindestens 5 kbit/s.> Mit dem "richtigen" Verfahren.> Und die Software gestaltete sich auch wesentlich einfacher.
Mein 4 MHz Z80-System (Nascom2) schaffte 19200 bit/s. Das lief auf einer
fernsteuerbaren TEAC (Open-Reel) Bandmaschine, incl.
Bandpositionsbestimmung per Interrupt (Gabellichtschranke am Bandteller)
und Softsektorierung des Bandes. Die nächste Idee war dann die
Aufzeichnung von zwei Bit pro Schritt (Stereo!), das wurde allerdings
vor der Realisierung durch eine 8"-Floppy abgelöst, die dann den Weg zu
CP/M ebnete.
Udo schrieb:> Also mir ist vollkommen unklar, wie man auf die Idee kommen kann,> für einen kleinen uC ein Betriebssystem haben zu wollen.
Erinnert mich mit Gruseln an einen Bewerber auf eine
Hardware-Entwickler-Stelle. Frischer Master mit "guten analogen
Kenntnissen" sowie diverse Controller incl. gängige Betriebssysteme...
Eingeladen und festgestellt, Operationsverstärker waren nicht seine
Stärke...Frage nach Betriebssystemen wurde mit dem Hinweis auf die
Masterarbeit und die Ausgabe eines ASCII-Texts von einem AVR-Controller
zum PC beantwortet. Frage: kennen Sie Windows? Antwort, ja, das ist
Microsoft...
Frage: was sagt Ihnen Linux/Unix? Antwort: Nichts!
Wenn ich nicht dabeigewesen wäre, ich würd's nicht glauben :-)
Gruß Rainer
Mein erster Z80 (Eigenbau) hatte 3 kByte mit 24 1103.
Da reichte 5 kbit/s allemal :-).
Die Routinen enstanden auf Papier, wurden dann zuerst per
Tabelle, später per Kopf, in Hexcodes übersetzt, und mit
dem ebenfalls selbst gebauten Brenner in einen 2708 gebrannt.
Anders als heute bei manchen Softwerkern üblich, war bereits
die Version V 1.0 fehlerfrei und final.
Der verwendete Recorder hatte urspruenglich sogar nur eine
Gleichstromvormagnetisierung. Da musste man realisitisch bleiben.
Prüfsummen waren Luxus und fehlten entsprechend.
Wie die Praxis gezeigt hat, waren sie auch nicht nötig.
Ein zweiter Eigenbau hatte nur noch einen Tapeurlader im EPROM
und 16 kByte aus 4116 + 1 kByte für das Display.
Das Verfahren war immer noch das selbe...
Einen EPROM-Emulator für max. 8 kByte habe ich dann per
Hardware ebenfalls das Modulationsverfahren nahegebracht.
Den konnte man dann am C64, C128, CP/M-Rechnern oder auch
nur an einem Rekorder benutzen.
Gruss
Der müde Joe schrieb:> b) Die Tastatur mit PS-2 Schnittstelle. Habe ich schon seit 15 Jahren> keine mehr gesehen. Ich denke, da bedarf es einer Lösung für USB oder> Bluetooth.
Die Adapter von USB zu PS/2 einer Tastatur
gibt's es noch reichlich. Das kann man dann auch auf Bluetooth
erweitern.
Ein Schönes Wochenende wünsche ich Euch.
Dirk St
Der müde Joe schrieb:> a) Der Arbeitsspeicher für das Anwenderprogramm ist mit 1 kByte RAM arg> limitiert. Ich würde heutzutage das Limit eher bei 16 oder sogar 32kByte> RAM sehen.
Früher (tm), auf einem 6502, lief Basic auf 8kB ROM und 4kB RAM.
Arduino gibt es mit 96kB RAM (64k+32k) und 512kB Flash.
Merkst du was?
my2ct schrieb:> Merkst du was?
Mit der Müdigkeit vom Joe lässt sich praktisch jeder Mist er-
klären bzw. entschuldigen. Da kann man alles rauslassen was
einem gerade so einfällt.
Das BASCOM geht auch in die Richtung und hat einige Elementzüge eines
Betriebssystems unter der Haube, allerdings nur den Anteil des
Interpreters für dieses spezielle Basic.
Angesichts der Größe und Fähigkeiten von AVR Mikrocontrollern kann nur
so etwas ähnliches wie MS-DOS bei heraus kommen. Ich sehe da aber keinen
Vorteil gegenüber einem Framework wie Arduino. Das hat auch
Standard-Bibliotheken für Standard Hardware.
Man wird auf Mikrocontrollern wohl kaum ein Desktop OS brauchen, wo man
nach Lust und Laune unterschiedliche Programme startet. Da kann man dank
Flash auch bequem per Programmieradapter lösen oder man packt eine
gewisse Auswahl an Programmen in den Flash und wählt beim Start per Menü
aus, welches man ausführen will.
Letztendlich haben Benutzer ihr DOS lediglich als Programmstarter
wahrgenommen.
Ein OS, dass darüber hinaus geht müsste für mich aktives Multitasking
unterstützen. Und da haben wir bereits FreeRTOS. Was will man mehr?
Stefan ⛄ F. schrieb:> Ein OS, dass darüber hinaus geht müsste für mich aktives Multitasking> unterstützen. Und da haben wir bereits FreeRTOS. Was will man mehr?
kann FreeRTOS Schnittstellen ansteuern, Speicherkarten per Dateisystem
nutzen, Grafiken darstellen? FreeRTOS ist ein Kernel, ein kleiner Teil
eines OS. Wenn man mehr haben wollte, dann war es vorbei mit 'Free', das
gab es als Kaufoption.
my2ct schrieb:> Früher (tm), auf einem 6502, lief Basic auf 8kB ROM und 4kB RAM.
Mit Farbdisplay, Handflächengroß? Mit welchem Speicher? Datasette?
Tasten für Hex Eingabe und teures Display aus ein paar 7-Segment
Anzeigen. Supi.
Dieses 'Früher' kenne ich auch, es reicht mir aber das als Erinnerung zu
haben.
ZX81 für spottbillige 398 DM, 2 Monatslöhne eines Lehrlings. Wieviel
Bier man damals noch dafür bekam...
Mark S. schrieb:> Jaja, unsere Digital-Heimkehrer erzählen mal wieder Geschichten aus dem> Kriege
Naja, wenn man auf dem 8085 MFA Lehrsystem gearbeitet hat und mit dem
Basic Interpreter auf dem 8051, dann ist die Arduino OS Idee eben nur
ein sehr später Abklatsch einer ganz alten Idee.
Es ist vor allem sehr, sehr langsam.
Kann man machen, wenn man Freude daran hat und man lernt bestimmt auch
viel.
Danach verstaubt das Ding im Schrank weil es für reale Anwendungen
zuviele Recourcen in sein eigenes OS verschwendet.
Die 8051 erstetzten die 8085 und halten sich bis heute ganz wacker.
Die AVRs überholten die 8051, sind aber auch schon sackalt.
Wenns ein Hobby ist in man daran Freude hat, einfach machen und nicht
die Sinnfrage stellen.
Johannes S. schrieb:> kann FreeRTOS Schnittstellen ansteuern, Speicherkarten per Dateisystem> nutzen, Grafiken darstellen?
Kann es nicht, braucht es auch nicht, denn wir brauchen auf
Mikrocontrollern keine interaktive Eingabeaufforderung außerhalb der
Programme. Für den Restlichen Bedarf haben wir Bibliotheken und Flash.
Wir arbeiten interaktiv auf unserem PC. Dort wählen wir das gewünschte
Programm aus und übertragen es in den Mikrocontroller um es auszuführen.
Das sind nur wenige komfortable Klicks.
Der ESP8266 ist meiner Meinung nach der billigste Mikrocontroller, auf
dem ein OS mit interaktiver Eingabeaufforderung halbwegs sinnvoll
umsetzbar ist. Und es wurde gemacht - sogar kostenlos:
https://github.com/nodemcu/nodemcu-firmware . Als Bildschirm/Tastatur
verwendet man dort ein Terminalprogramm am seriellen Port. Du hast
interaktiv nicht nur Zugriff auf das Dateisystem, sondern auf sämtliche
Biblbiotheks-Funktionen der enthaltenen Scriptsprache LUA. Im
Custom-Build Service kannst du dir selbst zusammen stellen, welche das
sein sollen.
Damit bist du ganz nahe an dem, was MS-DOS früher auf PC konnte.
Mark S. schrieb:
> Jaja, unsere Digital-Heimkehrer erzählen mal wieder Geschichten aus dem> Kriege
mkn (Gast)
>Naja, wenn man auf dem 8085 MFA Lehrsystem gearbeitet hat und mit dem>Basic Interpreter auf dem 8051, dann ist die Arduino OS Idee eben nur>ein sehr später Abklatsch einer ganz alten Idee.
Aus der laufenden Diskussion scheint mir hier ein Missverständnis
vorzuliegen: Es geht hier nicht um AVR-Prozessoren, auch wenn viele
Leute Arduino damit verbinden. Das System umfasst mittlerweile
wesentlich leistungsfähigere Prozessoren wie die ESP-Reihe oder die
STM-ARMs bis zum H7. Die Leistungsfähigkeit dieser Prozessoren hätte
früher gereicht, das erste Linux laufen zu lassen (in wenigen Fällen
heute auch). Der Punkt ist aber, dass der Linux Kernel selbst schon ein
paar MB groß ist und damit "bloated".
Mit Arduino Libraries könnte man ein interaktives System schaffen,
welches im Vergleich zu Linux noch relativ schlank ist. Das System
bewegt ist dann vielleicht für Prozessoren um 100MHz und 64k Ram
geeignet.
Er Vorteil: man könnte ein interaktives Echtzeitsystem entwerfen, wie es
andere Implementierungen nicht bieten. Die Arduino-Libraries sind ja
genormt und dann auch einfach einzubinden.
Wenn's um die Frage geht, was ein interaktives System bringen soll:
Versuche dazu gibt es immer wieder wie z.B. das von Klaus
Beitrag "microCore, ein Echtzeitprozessor in VHDL für FPGAs"
oder das von Frank:
Beitrag "MINOS - Minos Is No Operating System"
Der große Nachteil dieser Herangehensweise: Sie sind zu keinem anderen
System kompatibel.
Das ist bei der Verwendung des Arduino-Frameworks natürlich völlig
anders. Dort sind sofort x1000 Libraries zur Verfügung.
Markus schrieb:> Aus der laufenden Diskussion scheint mir hier ein Missverständnis> vorzuliegen: Es geht hier nicht um AVR-Prozessoren, auch wenn viele> Leute Arduino damit verbinden. Das System umfasst mittlerweile> wesentlich leistungsfähigere Prozessoren wie die ESP-Reihe oder die> STM-ARMs bis zum H7. Die Leistungsfähigkeit dieser Prozessoren hätte> früher gereicht, das erste Linux laufen zu lassen (in wenigen Fällen> heute auch). Der Punkt ist aber, dass der Linux Kernel selbst schon ein> paar MB groß ist und damit "bloated".
Ja, aber braucht man das wirklich? Früher gab es auch mal Minix, lief
auf eine 68000 mit 1MB Ram. Entspricht heute einem STM H7. Ein
Mini-Linux wäre möglich.
Aber wozu. Da lege ich 10 Euro mehr auf den Tisch, habe eine Raspi mit
virtuellem Speicher, der alles kann.
Für die 10 Euro weniger (STM H7) habe ich keinen virtuellen Speicher,
und muss mit diversen Einschränkungen leben. Ausserdem muss ich hunderte
Stunden reinstecken, damit es auch nur ein bißchen läuft.
Früher hat man das gemacht, weil es nicht anderes gab. Heute macht man
es nur, wenn man viele Schmerzen erleben möchte.
Da warte ich lieber noch 8 Wochen, dann machen die Studios wieder auf.
PittyJ (Gast)
>Ja, aber braucht man das wirklich? Früher gab es auch mal Minix, lief>auf eine 68000 mit 1MB Ram. Entspricht heute einem STM H7. Ein>Mini-Linux wäre möglich.
Lustigerweise läuft Minix heutzutage auch noch auf allen Intel PCs:
1
Nov.2017:
2
Sicherheitsforscher haben vor wenigen Monaten Lücken in Intels Management Engine (ME) gefunden und darauf verwiesen, dass aktuelle ME-Versionen das Betriebssystem Minix verwenden.
aus
https://www.golem.de/news/betriebssystem-tanenbaum-bedankt-sich-fuer-minix-in-intel-me-1711-131009.html>Aber wozu. Da lege ich 10 Euro mehr auf den Tisch, habe eine Raspi mit>virtuellem Speicher, der alles kann.
Der RasPi hat aber z.B. nicht besonders viel Peripherie Schnittstellen.
Der Nachteil von Linux ist auch: es ist kein Echtzeibetriebssystem.
> Ausserdem muss ich hunderte> Stunden reinstecken, damit es auch nur ein bischen läuft.
Da hast du Recht. Es wäre aber anders, wenn es das
Arduino-Betriebssystem schon gäbe.
Markus schrieb:>>Aber wozu. Da lege ich 10 Euro mehr auf den Tisch, habe eine Raspi mit>>virtuellem Speicher, der alles kann.> Der RasPi hat aber z.B. nicht besonders viel Peripherie Schnittstellen.> Der Nachteil von Linux ist auch: es ist kein Echtzeibetriebssystem.
Wenn ich Echtzeit auf einem Raspi brauche, dann hänge ich dafür einfach
noch einen Arduino dran. Einfach per USB. Der Arduino kann die
zeitkritischen Sachen erledigen. Der Raspi hat Filesystem und GUI. Ist
doch eine super Kombination.
Statt eines Arduinos habe ich schon mit einem FPGA herumgespielt.
Einfach Boards sind doch auch schon für 30 Euro erhältlich. Ran an den
Raspi und fertig.
https://www.heise.de/make/meldung/iCEstick-Preiswerter-FPGA-1981927.html
Markus schrieb:> Der Vorteil: man könnte ein interaktives Echtzeitsystem entwerfen, wie es> andere Implementierungen nicht bieten.
Der Nachteil: Niemand braucht es, niemand will es, außer du - für dich
gibt es NodeMCU. Wozu dann der Aufwand?
Ok, man könnte ein Kunstprojekt daraus machen. Just for fun, weil man es
kann. Das finde ich persönlich aber noch langweiliger, als eine neue Uhr
zu erfinden oder eine schöne Modelleisenbahn aufzubauen.
> Mit Arduino Libraries könnte man ein interaktives System schaffen,> welches im Vergleich zu Linux noch relativ schlank ist.
Seit es IT gibt argumentiert jeder so, der ein bereits bestehendes
System neu erfindet.
Dann kommen die Anforderungen der echten Anwender dazu, und schwupss:
wird es groß und lahm. Am Ende steckt man ungeheuer viel Zeit hinein, um
die Performance wieder in Ordnung zu bringen und das Projekt pflegbar zu
machen. Dann erzählt man der Wert, dass diese Version 2.0 von Grund auf
neu sei, viel schneller und jetzt endlich die Welt retten wird. Während
andere gähnen und sagen "schon wieder so eins".
Schau dir NodeMCU an, das ist die Antwort auf deine Frage. Du musst
das Rad nicht neu erfinden! Wenn dir NodeMCU zu wenig verbreitet ist,
dann frage dich, woran das liegen könnte. Was haben die Macher von
NodeMCU falsch gemacht, was du besser machen würdest. Wahrscheinlich
nichts, es ist einfach nur so, dass das fast niemand braucht.
Markus schrieb:> Der Nachteil von Linux ist auch: es ist kein Echtzeibetriebssystem.
Der Hinweis hat jetzt aber wirklich gefehlt! Wann hätte man denn mal von
Echtzeitsystemen geträumt? Beim Herumstümpern mit Basic oder beim
Basteln mit CP/M oder wann?? Oder etwa beim Kaffee auf Atari? Sorry,
"Echtzeit" ist echt am Thema vorbei...
Gruß Rainer
Für einen Basic Interpreter?
Naja, Echzeit ist auch wenn der Großrechner meine Kohle rechtzeitig zum
Monatsanfang auf mein Konto überweist.
So ganz schlüssig ist das Konzept noch nicht.
Markus schrieb:> Nein. Echtzeit ist genau das Thema für Mikrocontroller.
Wie erfüllt denn dein gedachtes Betriebssystem die üblichen
Anforderungen an "Echtzeit", während es auf einen Datenträger zugreift
oder Ausgaben auf einem langsamen Display macht?
Arduino hat dafür ganz sicher nicht die passenden Bibliotheken. Die
meisten blockieren nämlich während der Übertragung.
Markus schrieb:> Nein. Echtzeit ist genau das Thema für Mikrocontroller.
Nee, Echtzeit-Betriebssysteme sind höchstens eine Untermenge von
Betriebssystemen. Und auch wenn das LED-Blinkprogramm die LED mit exakt
1s Takt an- und ausschaltet, liegt dahinter (meist) kein Echtzeitsystem.
Ich will mich jetzt aber nicht wegen Peanuts streiten...
Gruß Rainer
Johannes S. (jojos)
>Für einen Basic Interpreter?>Naja, Echzeit ist auch wenn der Großrechner meine Kohle rechtzeitig zum>Monatsanfang auf mein Konto überweist.
Man könnte das Basic mit Zeitfunktionen ausstatten:
millis,
wait_ms,
wait_until_last_multiple
Das letztere gibt's in LabView und sorgt für exakte Zeitschleifen, indem
es bei jedem Aufruf wartet, bis die relative Zeit zum letzten Aufruf
abgelaufen ist.
Ich schätze, dass ein Basic einfache Regelschleifen im Bereich von
100ms-10ms erlauben würde, was z.B. für viele mechanische Regelungen
oder Temperaturregelungen ausreicht.
>So ganz schlüssig ist das Konzept noch nicht.
Sollte es das sein?
Stefan ⛄ F. (stefanus)
>Arduino hat dafür ganz sicher nicht die passenden Bibliotheken. Die>meisten blockieren nämlich während der Übertragung.
Der Vorteil der Arduino-Libraries ist ja, dass sie im Quellcode
vorliegen und man sie entsprechend anpassen könnte.
Schnelle Echtzeit ließe sich eventuell auch über eine Interruptroutine
(z.B. 100kHz auf einem 100MHz ARM) realisieren, in die man die
gewünschte, eigene Funktion packt.
Nimmt man Betriebssystem wie Windows oder Linux wird dort ja Echtzeit
bei Video und Sound auf diese weise zusammen mit Buffers und Queues zur
Kommunikation mit dem langsamen Teil des System realisiert. Der Vorteil
hier des Arduino-Betriebssystems: man kann eine Intteruptroutine noch
mit überschaubarem Aufwand selbst realisieren.
Will man TFT-Grafiktreiber z.B. von Adafruit verwenden, bieten diese ja
üblicherweise das Anflanschen von Bitbanging-SPI Treibern an. Diese
währen zwar langsam, würden den FAST IRQ zumindest nicht blockieren.
Markus schrieb:> Der Vorteil der Arduino-Libraries ist ja, dass sie im Quellcode> vorliegen und man sie entsprechend anpassen könnte.
Was bleibt denn dann noch vom Arduino System übrig?
Damit kannst du in diesem Jahrhundert niemanden hinterm Zaun hervor
locken.
Markus schrieb:> Der Vorteil der Arduino-Libraries ist ja, dass sie im Quellcode> vorliegen und man sie entsprechend anpassen könnte.
was allerdings kein exklusives Arduino Feature ist.
Und einen Basic Dialekt mit µC I/O zu verknüpfen ist jetzt auch keine
neue Idee, Bascom und Co. gibt es glaube ich schon.
Was Basic den Einsteigern beigebracht hatte, war der berühmte
Spaghetticode. Ich bin ja liberal, aber Basic sollte in den Retro Kisten
bleiben :)
Da du dir ja schon Gedanken machst, würde ich auch eher microPython
empfehlen wenn es denn überhaut eine Scriptsprache sein muss. Aber man
kann auch mit/für Arduino brauchbaren Code schreiben, es ist ja
schliesslich C++. Wenn man nicht alles in eine meterlange loop() packt
und sich mit OOP vertraut macht.
Markus schrieb:> plus die Kompatibilität zu x-verschiedenen Prozessorarchitekturen
Da jede Architektur andere I/O Hardware hat, kann mit dem bisschen
Kompatibilität nicht viel anfangen. Es sei denn, man bietet für jede
Architektur eine eigene Implementierung der sehr stark vereinfachten API
an - wie Arduino das halt tut.
Nur sind so halt keine Echtzeit-Anforderungen (im Bereicht um 10ms) mehr
umsetzbar. Wie gesagt blockiert schon eine simple Textausgabe auf einem
Display oder ein Dateizugriff auf eine SD Karte das ganze System.
Markus schrieb:> Ungefähr x1000 Libraries, die man nicht anpassen muss und zig Millionen> Codezeilen.
Ich bezweifle stark, dass du 1000 Libraries für Arduino kennst, die
keine blockierenden I/O Zugriffe machen. Die will ich sehen, zeige mir
mal 20 für AVR oder 20 für STM32F3 (oder irgendeine andere single-core
Architektur deiner Wahl), dann bin ich schon zufrieden.
Für nicht blockierende I/O muss man Interrupts, DMA oder Hardware-Puffer
verwenden. Das ist dann immer hardwarespezifisch.
Für wie viele Mikrocontroller willst du (Markus) dein OS denn schreiben,
damit es für andere interessant wird?
Da dich das Thema interessiert, empfehle ich dir ernsthaft, dich am
NodeMCU Projekt zu beteiligen. Das Projekt könnte frischen Wind in Form
motivierter Entwickler wirklich gut gebrauchen, ebenso Portierungen auf
weitere Architekturen. Für dich wäre das eine richtig gute Basis, auf
der man aufbauen kann.
Johannes S. (jojos)
>Da jede Architektur andere I/O Hardware hat, kann mit dem bisschen>Kompatibilität nicht viel anfangen.
Das unterschätzt man ein wenig. Eins meiner Systeme mit ein paar 10.000
Zeilen Code setzt auf der Arduino IDE auf.
Es läuft bis jetzt auf
- den größeren Atmegas, (beim UNO muss ich ein paar Features
wegkommentiern)
- allen STM32 Derivaten, die von STM32Duino unterstützt werden
- ESP8266 und ESP32
- PiPico
Klar, ich muss für die verschiedenen Prozessoren per #ifdef die
Peripherie an- oder abschalten. Das geschieht aber automatisch beim
kompilieren weil der Compileraufruf den entsprechenden Prozessortyp
mitteilt.
Die ganze Diskussion erinnert mich an eine, die ich hier schon mal vor
über 10 Jahren hatte. Da gings darum, ob man mit Atemgas einen
polyphonen Synthesizer bauen kann. Es war damals die übliche
Mikrocontroller-Net Nörgelei: geht nicht, gibt's nicht, wenn's ginge
hätten wir's schon gemacht.
Da mir das zu doof war, habe ich das Projekt einfach mit dem Ergebnis
umgesetzt, dass es 100 fach gebaut wurde und X-fache Folgeprojekte
entstanden sind. Das MC-Netz ist für etwas ausgefallenere Ideen ein
wenig, wie wenn man Fleischfachverkäufern die Vorzüge eines
vegetarischen Schnitzels beibringen will: falsches Publikum.
Markus schrieb:> Johannes S. (jojos)>>Da jede Architektur andere I/O Hardware hat, kann mit dem bisschen>>Kompatibilität nicht viel anfangen.
na na, falsch zitiert.
Wenn man Basic so mag dann funktioniert das mit deinen rausgesuchten
Links mit Sicherheit. Nur ist Arduino doch schon relativ einfach, ich
sehe nicht das Basic daran noch etwas verbessert.
Die Verlagerung von Betriebssystem auf Echtzeitbetriebssystem spiegelt
wohl, dass es nicht mehr viel zu sagen gibt. Und ein Controller, der
garantiert innerhalb einer bestimmten Zeit auf einen Input reagiert,
arbeitet wohl nach Definition in Echtzeit, hat aber alles, nur kein
Betriebssystem auf dem Buckel! Alle Betriebssysteme, die nicht "Echzeit"
sind, geben deshalb auch nur eine bestimmte, garantierte kürzeste
Reaktionszeit an, z.B. "Sleep 1000ms" heißt eben, dass die Routine
mindestens 1000ms schläft...kann aber auch 1500ms sein ect...
Gruß Rainer
Rainer V.
>Die Verlagerung von Betriebssystem auf Echtzeitbetriebssystem spiegelt>wohl, dass es nicht mehr viel zu sagen gibt. Und ein Controller, der>garantiert innerhalb einer bestimmten Zeit auf einen Input reagiert,>arbeitet wohl nach Definition in Echtzeit, hat aber alles, nur kein>Betriebssystem auf dem Buckel!https://de.wikipedia.org/wiki/QNXhttps://en.wikipedia.org/wiki/VxWorks
Ich realisiere gerade einen Prozessor im TTL Logic, Betriebsystem, was ?
nö braucht man nicht.
@Markus: ich glaube daß das A- Feamework nicht mehr so beliebt ist wie
es irgendwann war und irgendwie mit niedrige Kentnisse verbundet wird...
so klingt es mir.
Die Idee finde ich gut, aber ich denke daß es nicht dort der Punkt ist
sonder ein bisschen mehr in Richtug Anwendung, wofür wird das benutzt ?
Sollen Kinder damit lernen ? oder soll es das Herz meinem einfachen
Roboter?
