Mini-OS für Arduino Uno mit TFT-Touch-Shield: 4AOS

[martin k. (mknot9)]

Eventuell braucht ja jemand manchmal eine Möglichkeit, einen 
Mikrocontroller auf die Schnelle, ohne PC in der Nähe, (um-)zu 
programmieren.
Da jedoch beim UNO nur 2 kB RAM zu Verfügung stehen, sind viele 
Kompromisse nötig, um trotzdem etwas OS-ähnliches mit Code-Interpreter 
und Editieroption zu realisieren.
Einen möglichen Ansatz dazu habe ich auf arduino.cc dokumentiert:
http://playground.arduino.cc//Main/4aos

Da die Beschreibung auf Englisch ist, was nicht immer jedermanns Sache 
ist, beantworte ich auch hier gerne Rückfragen. Ein Video zum Stand des 
Projekts gibt's hier:
http://youtu.be/wgT-P-NlnEw

[Jens H. (tiger1602)]

AmForth !!! ?

[chris (Gast)]

schitzlmax schrieb:
>mein senf -> müll
mein senf dazu: Du bist ein fantasieloser Nörgler

>und dein englisch .. katastrophe!
Die Nützlichkeit deines Beitrags ... Katastrophe!

Hallo Martin,

ich finde Dein Projekt nicht schlecht. Vielleicht ist der Nutzen noch 
nicht so hoch, regt aber sicherlich einige Leute zu weiteren Ideen an.

Bester Gruß,
chris

[martin k. (mknot9)]

schitzlmax schrieb im Beitrag #3183249:
> was verstehst du bitte unter os?

Nun ein OS ist es sicher nur in dem allgemeinsten Sinne, dass mein 
sketch den Usern die Möglichkeit bietet, mit der Hardware (µc, tft, 
sd-card und den noch freien I/O-pins) zu kommunizieren bzw. sogar 
Programme zu editieren und ablaufen zu lassen, sowie mit anderen 
austauschen zu können. Bei 32 kB muss natürlich alles, was ein modernes 
OS ausmacht aussen vor bleiben, genauso wie Ansprüche ans Rechentempo.

> geschweige denn wie wenig sinn soetwas auf einen mini arduino board hat
> und wie langsam das alles geht..

Sinnfragen sind immer schon ein schwieriges Thema gewesen, da halt ich 
mich raus. Mein Ziel war, neumodisch gesagt, sowas wie 'nen µc-to-go zu 
basteln. Mit dem arduino-board scheint das mit wenig Aufwand möglich zu 
sein und wenn andere ähnliche Ideen haben, müssen sie nicht ganz bei 0 
anfangen.

Wie schön, das dies Forum 'Codesammlung' und nicht 'Sinnsammlung' heisst 
;-)

>
>...

[Michael F. (mifritscher)]

Hmm, schade, dass wir wohl beide nebenbei entwickelt haben, ohne was 
voneinander zu wissen :-( Ich habe ähnliches vor, bzw. steht der 
Interpreter und das Dateisystem schon. Kommandozeile gibt es in der 
Version 0.1, wo ein einfachster Editor mit enthalten sein wird. 
Zusätzlich wird es noch ein Editor geben, der an das LCD-Display 
(128x64, 4 Tasten) angepasst sein wird.

Links:
Beitrag "AVR: Interpreter für Assemblerartige Sprache" - der Interpreter
Beitrag "AVR: Kleines Dateisystem für SRAM, EEPROM, i2c/spi Speicher etc." - ein kleines Dateisystem

Zur Geschwindigkeit: Zumindest mein Interpreter schafft bei 20 MHz Takt 
ca. 100 kHz Befehlstakt, deiner dürfte jetzt auch nicht soooo viel 
langsamer sein (max. Faktor 10, so vom reinen Überfliegen her). Aber 
selbst wenn es nur 1 kHz sind reicht das für viele Sachen dicke aus.

[martin k. (mknot9)]

Hi Michael,
sorry, dass ich erst jetzt antworte, habe nur am WE Zeit für meine 
Bastelprojekte...

Michael F. schrieb:
> Hmm, schade, dass wir wohl beide nebenbei entwickelt haben, ohne was
> voneinander zu wissen :-( Ich habe ähnliches vor, bzw. steht der
> Interpreter und das Dateisystem schon. Kommandozeile gibt es in der
> Version 0.1, wo ein einfachster Editor mit enthalten sein wird.
> Zusätzlich wird es noch ein Editor geben, der an das LCD-Display
> (128x64, 4 Tasten) angepasst sein wird.

nun ja, evtl. hätten wir uns auch in die Haare gekriegt, welche 
'Design-Entscheidung' es denn nun sein soll. Wenn ich es richtig sehe, 
zielst Du ja eher auf 'größere AVRs'...
Meine Idee war, es mal mit 32k/2k zu probieren und einen skalierbaren 
Zeichensatz für kleinere Ein-/Ausgabe-Zwecke zu nutzen. Die Einbindung 
der offiziellen 'SD-lib' ist für mich auch nur eine 'Notlösung' in dem 
Sinne, dass das Projekt für Neueinsteiger leichter nachzuvollziehen ist, 
die ein Arduino mit LCD-Shield haben (sketch kopieren und los - für rund 
40€ .-)

Byte-Puristen muss mein Ansatz ein Graus sein, da ich in jede (SD-)Datei 
im Mittel nur 8 Byte reinschreibe, aber ich hatte sonst immer wieder 
Probleme, dass die 2k Ram nicht reichten, wenn ich mehr Bytes nutzte und 
im Interpreter handeln wollte...

>
> Links:
> Beitrag "AVR: Interpreter für Assemblerartige Sprache" - der Interpreter
> Beitrag "AVR: Kleines Dateisystem für SRAM, EEPROM, i2c/spi Speicher etc." - ein kleines Dateisystem
>
> Zur Geschwindigkeit: Zumindest mein Interpreter schafft bei 20 MHz Takt
> ca. 100 kHz Befehlstakt, deiner dürfte jetzt auch nicht soooo viel
> langsamer sein (max. Faktor 10, so vom reinen Überfliegen her). Aber
> selbst wenn es nur 1 kHz sind reicht das für viele Sachen dicke aus.

Der 'Haken' bei meinem Ansatz ist, dass wegen der vielen nötigen Dateien 
(s.o.) der Zugriff auf sie immer etwas langsamer wird, je mehr da sind. 
Bei einfachen kleinen Anwendungen ist das nicht weiter schlimm und ich 
habe das etwas mit meiner 'proprietären' jump-Interpretation etwas 
abgemildert, aber zeitkritische Sachen fallen (noch) komplett raus.

Im Moment schaue ich, wo ich noch ein paar Bytes im Code einsparen 
könnte, da ich eine Funktion implementieren will, mit der man zur 
Laufzeit kürzere/zeitkritische Codeteile einfach ins noch ungenutzte 
1k-EPROM kopiert um sie dort 'schnell' abrufen und ablaufen lassen zu 
können.

Evtl. komme ich mal auf Deine Idee zurück, nur Zahlen als Dateinamen zu 
nutzen, einen sehr vereinfachten SD-Treiber zu basteln und die SD-lib 
komplett aussen vor zu lassen, da ich so auch etwas mehr RAM zur 
Verfügung hätte...

[Michael F. (mifritscher)]

Hallo Martin,

nunja, mein erstes Ziel war ein Atmega16, was ich dann aufgegeben habe, 
weil die Kompromisse zu groß geworden wären. Ein Atmega32 wäre wohl 
problemlos gegangen, und sollte es eigentlich auch jetzt noch. Joar, 8 
Byte Dateien sind außergewöhnlich ;) Liest der Treiber nicht eh immer 
512 Byte am Stück ein? Zum auslagern könnte auch ein i2c-eeprom oder 
-ram nützlich sein.

[martin k. (mknot9)]

Michael F. schrieb:
> Hallo Martin,
> ...
> 8 Byte Dateien sind außergewöhnlich ;) Liest der Treiber nicht eh immer
> 512 Byte am Stück ein? Zum auslagern könnte auch ein i2c-eeprom oder
> -ram nützlich sein.

Hi Michael,

zumindest reserviert die sd-lib mindestens 512 bytes aus dem RAM für den 
buffer und weitere unvermeidbare Variablen reduzieren das verfügbare RAM 
auf deutlich weniger als 1,5k. Danach kommt ja erst mein eigentliches 
Mini-OS ins Spiel.
Zur Eingrenzung des Problems hatte ich recht früh die "Free 
RAM"-function von arduino.cc in mein "GUI" intergriert (s. Foto, letzter 
Eintrag in der 'status bar': dort sind noch 551 bytes 'frei'). Und zur 
Laufzeit sind es wegen diverser Funktionsaufruf noch weniger...

Die Nutzung eines zusätzlichen RAM/EEPROM-shields hatte ich auch schon 
mal angedacht, aber das würde den Einstieg für neugierige Nachahmer 
nochmals erschweren. Ich habs aber weiter auf der 
'coming-features'-Liste.

Gruss, Martin

[chris (Gast)]

Mit "Assemblerartigen Sprachen" habe ich auch schon vor einer ganzen 
Weile experimentiert:
http://hobby-roboter.de/forum/viewtopic.php?f=4&t=24

Mein Ziel war es, den Code möglichst schnell auf neue Mikroprozessoren 
portieren zu können. Eigentlich bietet Java so was, ist aber für sehr 
kleine Mikroprozessoren ungeeignet.

Hier auch einen Simulator für einen Parallax Propeller:
http://hobby-roboter.de/forum/viewtopic.php?f=4&t=77

Das Ziel war, mehrere Prozessorkerne parallel auf einem Atmega32 zu 
emulieren. Das habe ich dann später gemacht und zwei Propeller-Cores auf 
dem Atmega32 laufen lassen.