Hallo,
ich will folgendes programmieren:
Auf meinem Mikrocontrollersystem will ich eine Art Shell bauen. Also so
ähnlich wie die Konsole unter Windows oder Linux. Der Controller ist
über RS232 mit einem PC gekoppelt, auf dem ein Terminal läuft. Dort gibt
man Befehle ein, und die führt der Mikrocontroller dann aus.
Das ansich wäre ja noch nicht so schwierig.
Komplizierter wird es, wenn das ganze möglichst flexibel bzw. modular
sein soll. Also ich möchte möglichst einfach neue 'Befehle'
implementieren können, am besten wärs wenn das auch dynamisch (also zur
Laufzeit!) möglich wäre.
Mal ganz grundsätzlich: Wie könnte man sowas anpacken?
Ziel und Zweck der Sache ist eigentlich, dass man Grundlegende Dinge in
so einer Shell verpacken könnte. z.B. Programm runterladen, bestimmte
Speicherbereiche ändern und so weiter. Halt so debugging-Sachen. Und je
nach Anwendung könnte man dann noch weitere Befehle implementieren.
Habt ihr schon mal sowas gemacht?
Extrem nützlich wäre es auch, wenn man verschiedene 'Pakete'
programmieren könnte. Also jeweils kleine, unabhängige Programme, die
man nach belieben zusammensetzen könnte. Ziel davon wäre es, dass man
sich die Software für verschiedene Mikrocontroller schön modular
zusammenbauen könnte.
So als Beispiel: Man hat ein Paket für CAN, eines für USB und eines für
Ethernet. Auf einem kleinen 44pin-ARM, wo z.B. nur der CAN-Controller
verwendet wird, lädt man nur das CAN-Paket runter. Auf einem anderen
will man dafür USB und Ethernet verwenden, deshalb installiert man da
noch die beiden anderen Pakete. Der Zweck davon wäre, dass man nicht
immer wieder extra was neues schreiben muss, sondern nur noch fertige
'Bauklötzchen' zusammenschustern muss.
Hat dazu jemand ne Idee, wie das gehen kann?
So genau kenne ich mich damit nicht aus aber es gibt doch das µC linux
ist das nicht sowas?
Habe mal einen ATTiny inner Platine für ein CNC Fräse gesehen die konnte
man über das Terminalprogramm ansprechen und Einstellungen (
Konfigurieren )und nebenbei hat der µC noch 1 Achse der CNC Fräse
Gesteuert.
bei: http://www.peters-cnc-ecke.de
Das nennt sich UHU Servocontroller.
Da gibt es dann kleine befehle zum setzen von Parametern oder zum
anzeigen von eingestellten Parametern usw.
Hallo,
ich habe für meine Teleskopsteuerung so eine Shell programmiert.
Sie arbeitet mit Tabellen, die Schlüsselwörter (Befehle) mit
Sprungadressen für die entsprechenden Routinen enthalten.
Die jeweilige Routine holt dann weitere Parameter aus dem Eingabestring
ab. Diese können Zahlen (beginnend mit Ziffern, '0x' oder '0b') oder
wiederum Labels sein.
Hier ist der Quelltext zu finden:
http://www.martin-cibulski.de/atm/mount_controller_4/mc_4_asm_main/index_de.htm
Die Shell steht in monitor.asm.
Modular ist das Ganze auch, weil es mehrere Befehlstabellen gibt, die
nacheinander durchsucht werden. In monitor.asm gibt es dazu die
'mon_master_label_tab', die auf die Untertabellen verweist.
Gruß,
Martin
Wenn Du Dich mit UPN anfreunden kannst, dann wäre vielleicht ein FORTH
das richtige.
Forth gibt es überall für AVR's, ARM's und alle möglichen Prozessoren.
Gruss
Frank
Hallo,
ja eigentlich wäre ja uC Linux gut. Aber damit kenne ich mich nun
wirklich nicht aus, und so wie ich das einschätze, braucht das wohl auch
ziemlich viel RAM bzw. FLASH, was nicht in jedem Fall zur Verfügung
steht. Aber gut wäre es auf alle Fälle....
@Frank:
das mit UPN und FORTH interessiert mich.
Du meinst aber doch wohl nicht DAS UPN, das auch bei
hp-Taschenrechnern zum Einsatz kommt oder? ;)
Gast wrote:
> @Frank:> das mit UPN und FORTH interessiert mich.> Du meinst aber doch wohl nicht DAS UPN, das auch bei> hp-Taschenrechnern zum Einsatz kommt oder? ;)
Doch, genau das meine ich.
Wenn es Dich interessiert - schau Dir ruhig mal FORTH an.
1 1 + . <enter>
2
Bei den meissten Forth bekommst Du ein Terminal, kannst "online" das
Programm erweitern. Wird im Flash gespeichert. Ist halt UPN :-)
Ich kenne es zwar nur für AVR's und PC's, aber gibt es auch für ARM
Vielleicht kann ja jemand von den Kollegen hier ein's vorschlagen.
Gruss
Frank
Das nannte man früher Monitor
damit wurde der uC fernbedienbar,
http://forums.freescale.com/t5/8-Bit-Microcontrollers/Sorce-code-and-Doc-for-BUFFALO-or-other-Monitor-for-68HC11/td-p/2121
und die MS-DOS Kommandozeile (oder CP/M oder Bourne) verfolgt genau den
Ansatz, alles was noch nicht als eingebautes Kommando bekannt ist, als
Extension zu suchen und aufzurufen, dort hat auf Diskette/Platte und
nicht im Speicher, aber im Prinzip ist das nichts anderes.
Deine Idee ist also nichts Neues, sondern seit 50 Jahren gängige Praxis,
und die Leute sind zu dutzenden leicht unterschiedlichen Lösungen
gekommen,
bei denen du nun bewerten darfst, welcher Aufwand welchen Effekt wert
war und dann hältst du dich einfach an so eine Vorlage.
Die meisten sind inzwischen im Source verfügbar.
Gast schrieb:> Extrem nützlich wäre es auch, wenn man verschiedene 'Pakete'> programmieren könnte. Also jeweils kleine, unabhängige Programme, die> man nach belieben zusammensetzen könnte. Ziel davon wäre es, dass man> sich die Software für verschiedene Mikrocontroller schön modular> zusammenbauen könnte.
Genau das macht man doch. Wer zum Beispiel einen CAN-Treiber braucht,
der linkt ihn in seinem Programm mit - den schreibt man ja in der Regel
nicht selbst.
> So als Beispiel: Man hat ein Paket für CAN, eines für USB und eines für> Ethernet. Auf einem kleinen 44pin-ARM, wo z.B. nur der CAN-Controller> verwendet wird, lädt man nur das CAN-Paket runter. Auf einem anderen> will man dafür USB und Ethernet verwenden, deshalb installiert man da> noch die beiden anderen Pakete. Der Zweck davon wäre, dass man nicht> immer wieder extra was neues schreiben muss, sondern nur noch fertige> 'Bauklötzchen' zusammenschustern muss.
Und wie genau soll das zur Laufzeit gehen? Das CAN-Paket soll ja
vermutlich im Flash-Speicher landen. Oder nicht?
Ansonsten, um Treiber (eben für CAN oder für anderes) dynamisch zu laden
oder aus dem (Haupt-)Speicher wieder zu entfernen, braucht es eben ein
Betriebssystem.
Irgendwie sehe ich noch nicht so richtig, was Du machen willst, was aber
mit modularer Programmierung in C und Linken der entsprechenden
Bibliotheken die man braucht und Weglassen derer, die man halt nicht
braucht, nicht gehen soll... dass man die Treiber für verschiedene
Schnittstellen sehr oft ändert, erscheint mir jedenfalls als ein leicht
exotischer Anwendungsfall.
