Hier hat Frank ein kleines Betriebssystem für Mikrocontroller geschrieben: Beitrag "MINOS - Minos Is No Operating System" In diesem Thread möchte ich ein wenig diskutieren, ob man nicht auf Arduino-Basis einen einfachen kleinen Retrocomputer aus Arduino-Libraries zusammenfügen könnte. Hier gibt es schon einmal eine Linux-artige Shell: https://github.com/wastel7/microBox die hier zu einer Scriptsprache ausgebaut wurde: https://github.com/AntonEvmenenko/microBox Es könnte aber vom Syntax her einfacher sein, einen Basic-Interpreter an das System zu hängen: https://github.com/robinhedwards/ArduinoBASIC Vielleicht sollte man dem ganzen noch FreeRtos unterlagern https://create.arduino.cc/projecthub/feilipu/using-freertos-multi-tasking-in-arduino-ebc3cc um die Kommandozeile parallel zum Programmablauf bedienen zu können. Einen zweiten Arduino könnte man als VGA-Grafikkarte vewenden: https://create.arduino.cc/projecthub/ingo-lohs/arduino-output-a-vga-signal-50420b?ref=user&ref_id=161171&offset=0
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.
Also mir ist vollkommen unklar, wie man auf die Idee kommen kann, für einen kleinen uC ein Betriebssystem haben zu wollen. Was ist der Vorteil?
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 STM32 https://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
Was fehlt wäre noch, dass ich einen Kassettenrecorder anschliessen kann, um die Basic-Programme zu speichern/laden.
> 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.
Jaja, unsere Digital-Heimkehrer erzählen mal wieder Geschichten aus dem Kriege
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
>Sorry,"Echtzeit" ist echt am Thema vorbei...
Nein. Echtzeit ist genau das Thema für Mikrocontroller.
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.
>Was bleibt denn dann noch vom Arduino System übrig?
Ungefähr x1000 Libraries, die man nicht anpassen muss und zig Millionen
Codezeilen.
>Was bleibt denn dann noch vom Arduino System übrig?
plus die Kompatibilität zu x-verschiedenen Prozessorarchitekturen
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.
dann erfindet man eben noch Qs, Threads, Semaphore, Mutexe usw. in Basic...
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.
Apple ][ auf Arduino UNO: https://web.archive.org/web/20160825140500/http://dpeckett.com:80/turning-the-arduino-uno-into-an-apple https://github.com/dpeckett/arduino-appleii/
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/QNX https://en.wikipedia.org/wiki/VxWorks
Ist ja interessant, deine Links, gehen aber für meinen Geschmack ein ganz klein wenig an Arduino vorbei! Nichts für ungut... Gruß Rainer
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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.