Der ATmega2560 entfacht Träume

Wegen der Corona Krise und meines aktuellen Exils am Land komme ich aktuell leider so gut wie gar nicht mehr dazu, mit meinen MCUs zu spielen.

Zwar hätte ich meinen PI-Top dabei, doch wenn keine ordentliche Lötstation in der Nähe ist, was soll man da schon was Interessantes anstellen?

Aber man kann planen … da fiel mir wieder ein, dass ich die Lösung gegen Pin-Mangel schon lange in der Tasche habe, sie aber noch nie eingesetzt habe: den ATmega2560

Der Traum vom eigenen OS

Für PCs ein OS zu schreiben ist zwar nicht unmöglich, aber zumindest unnötig geworden. Man kann nicht mehr so wie in den 90ern sich in Assembler ein “besseres” DOS schreiben, das auch wirklich etwas bringt.

Aber bei den Mikrocontrollern, da wäre es schon super, eine stabile Binär-API zu haben, oder dass man Skripts auf sie hochlädt und nicht ganze Sketches.

Doch das Problem beim Arduino UNO: Zu wenig RAM und zu wenig Anwendungsmöglichkeiten.

Wenn man ohnehin nur 1 oder 2 SPI oder I2C Module anstecken kann, wozu dann ein “Treiber Framework” aufbauen. Und mit 2 KB RAM und 1 KB EEPROM Speicher kommt man auch nicht sonderlich weit.

Doch der ATmega2560, der große Bruder vom Arduino UNO ATmega328, der könnte eher für so etwas geeignet sein.

Der ATmega2560

• 8 KB RAM, also 4 mal soviel wie der ATmega328, da lassen sich schon einige Datenstrukturen ablegen.
• 4 KB EEPROM, da könnte man tatsächlich schon Scripts ablegen … ist zwar immer noch kein “Datenträger”, aber immerhin ebenso 4 mal größer als beim UNO
• 256 KB Programmspeicher: Die ersten DOS Versionen waren wesentlich kleiner ;)
• 100 Pins, da kann man also schon so einiges anstecken
• 1 x I2C: OK gleich stark wie der UNO
• 2 x 8-bit und 4 x 16-bit Timer: Für Interrupts ist also auch gut vorgesorgt.
• 4 x UART und 5 x SPI: genau hier fängt der OS Gedanke an Sinn zu machen …

In dem Moment, wo man zwischen mehr als 2 Geräten und 2 Kommunikationskanälen wechseln kann, beginnt es Sinn zu machen, einen “Verwalter”, also ein Betriebssystem zwischen den Endpunkten zu etablieren.

Für kleinere Aufgaben (wie ein Gerät und eine UART) verdrahtet man die Logik besser fest, doch wenn man die Möglichkeit hat, mehrere Geräte dynamisch ein und auszuschalten, und wenn man z.B. einen Steuer- und einen Datenkanal separat bedienen kann … ja, da macht das schon mehr Sinn …