Tagchen,
Da ich im Moment hoffentlich den letzten Stress mit einer
selbstgebastelten Gerätschaft beseitigt habe und das Teil bis zu seiner
Bestimmung hoffentlich ohne weitere Probleme seinen Dienst verrichtet
und auf meinem Schreibtisch immer noch ein paar Teile rumliegen dürstet
es mich mal wieder nach einem neuen Projekt. Ein paar Taster habe ich
hier noch und ein 16x4 LCD, perfekt im Grunde für ein kleines Gerät,
dass noch keinen Sinn hat, aber trotzdem funktionieren soll. Ich dachte
da an eine Art PDA. Also einfache Eingaben über die Taster und Anzeige
über das LCD. Was das Ding dann für Zwecke erfüllt ist vorerst egal. Ich
dachte mir also, man könnte das mal ganz flexibel gestalten. Hier also
mein Vorhaben:
Das eigentliche Betriebssystem soll eigentlich nur eine Art BIOS sein.
Es soll einige Funktionen bereitstellen und nach der Initialisierung die
Kontrolle über den uC an ein anderes Programm weitergeben. Es soll auch
über die RS232-Schnittstelle diese Programme entgegennehmen und
speichern können, wahrscheinlich in einem externen Flash-Speicher oder
EPROM. Folgende Funktionen soll es bieten:
- vereinfachter Zugriff auf Tastenbefehle und LCD-Ausgabe (also dem
Programm den Lowlevel-kram wie Interrupts und IO-Pins abnehmen, eine Art
stdio)
- ebenso für die RS232-Schnittstelle. Allerdings bei einem bestimmten
Befehl soll auch Zugriff auf BIOS-Funktionen möglich sein (einspielen
von Programmen, evtl. Optionen)
- einen I2C-Bus
- evtl. einen weiteren selbsterdachten Bus für die Nutzung von weiteren
Modulen, (Treiberfunktionalität?)
Ist ja schonmal ganz nett durchdacht, nur habe ich sowas noch nie
gemacht. Ich habe bisher immer nur Programme geschrieben, die einfach
straight ihre Arbeit alleine verrichteten. Deshalb suche ich nun
Ansätze, wie sowas genau gemacht wird. Den Zugriff auf externen
Flash-Speicher z.B. kriege ich wohl anhand der Datenblätter hin, aber
dann von da ein Programm zu laden und auszuführen, da bin ich mit meinem
Latein am Ende (habe Französisch gehabt). Gibt es dazu entsprechende
Quellen? Habe so noch nichts gefunden aber vielleicht habt ihr ein paar
todsichere Google-Stichworte für mich oder direkt irgendwelche Links zu
dem Thema. Benutzt werden sollen AVR-Controller, da ich diese bereits
benutzt habe. Alles andere steht noch halbwegs in den Sternen. Aber
zunächst bräuchte ich ein paar Denkansätze bezüglich der Software.
Bis denn,
Luther
Stimmt grundsätzlich, aber es wäre durchaus denkbar, einen einfachen
Interpreter zu entwickeln, so wie es zum Beispiel in den Basic-Stamps
von Parallax gemacht wurde. Dort enthält der uC einen Basic-Interpreter.
Der Programmcode befindet sich in einem externen EEPROM und wird Befehl
für Befehl in den Controller geladen und interpretiert. Ist zwar nicht
beliebig schnell aber unheimlich flexibel.
Gruss
Christian
Also wäre da zum Beispiel hier der AT89S8252 von Atmel. Bei anderen
Herstellern habe ich mich noch nicht umgesehen aber im Datenblatt steht
einiges von External Program Memory. Also das, was ich suche. Allerdings
bestehen diese Angaben nur aus Zahlen, mit denen ich zunächst wenig
anzufangen habe. Werde also mal ein wenig nachsehen, was ich hier so in
der Linkliste finde. Da die Sache ja sowieso zu lernzwecken ist, kann es
nicht schaden, eine andere Controllerfamilie auszutesten.
Aber wie läuft das denn bei AVRs? Wird der Code direkt aus dem
Programm-Flash ausgeführt? Ich hatte gehofft, man hätte eine Art
Programmspeicher, in den das Programm geladen und dann ausgeführt wird.
So ist es ja üblicherweise bei PCs, aber gut, da ist es wahrscheinlich
sehr schwierig, den Code direkt von einer Festplatte auszuführen.
Also nochmal zurück zum MCS-51. Der externe RAM verfliegt ja dummerweise
beim ausschalten. Mein Controller muss also aus dem (externen)
Flash/EPROM/Whatever den Programmcode laden und in den RAM schieben und
dann die Programmausführung auf die Startadresse im RAM setzen. Bitte
bescheid sagen, falls das mal wieder um viel zu viele Ecken gedacht
ist... Inzwischen sehe ich mich ein wenig im Netz nach Infos um.
Obwohl ich noch wenig Ahnung hab: Nimm einen SRAM + Pufferbatterie!
Sollte beim PalmPilot ähnlich laufen. Der "vergisst" ja auch alle
gespeicherten Programme, wenn die Batterie leer ist :)
So ein externer Code-RAM hat schon einige Vorteile:
Er läßt sich schneller als ein Flash beschreiben und auch beliebig oft.
Für den Anschluß gibt es nen Haufen Schaltungen. Beim AT89S8252 sind die
unteren 8kB der interne Flash, da kommt dann das Bootprogramm rein.
Darüber wird automatisch der externe Speicher angesprochen.
Üblich ist z.B. einen 65C256 in die oberen 32kB ab Adresse 8000h zu
legen.
Um dann gleich beim Einschalten ein fertiges Programm in den RAM zu
laden und zu starten gibt es auch mehrere Möglichkeiten. Man legt z.B.
einen 29C512 Flash in den unteren Datenbereich ab 0000h, d.h. er läßt
sich nur als Datenspeicher lesen und schreiben und kein Code ausführen.
Eine andere Möglichkeit ist auch, statt des Flash einen AT24C256 zu
nehmen.
Von batteriegestützem RAM ist abzuraten, da ein ständig unter Spannung
stehendes Experimentierboard schnell zu Brutzeln anfangen kann, wenn man
mit Lötkolben, nackten Drähten oder anderem darin rumwerkelt.
Peter
P.S.: Ich gebs zu, ich mag die 8051 lieber.
Sie hatten eben den Vorteil, daß sie zuerst als Flash da waren, als noch
kein anderen µC-Hersteller wußte, wie man Flash schreibt.
Meine ersten AT89C51 von 1994 waren von Anfang an bugfrei, die ersten
AT90S1200 von 1997 dagegen nicht zu gebrauchen.
Und als ich dann den ATtiny22 ausprobierte bin ich wieder reingefallen.
Dessen Bugbeseitigung dadurch, daß er eingestellt wurde, hat mich auch
echt verblüfft.
Wenn ich das richtig sehe werden die Speicherbausteine parallel
angeschlossen und mir gehen dann schonmal 16 IO-Pins flöten. Find ich
irgendwie schade, obwohl ja am 8252 genug dran sind und ich über
I2C-Schnittstelle noch Expansions einbauen kann, wenn es nicht reichen
sollte.
Es gibt ja scheinbar auch serielle Varianten von EEPROMs und RAMs, z.B.
I2C-Bus. Aber dann funzt das doch mit der Adressierung nicht richtig und
ich werde wohl keinen Code daraus ausführen können.
Und noch was:
[QUOTE]Man legt z.B. einen 29C512 Flash in den unteren Datenbereich ab
0000h, d.h. er läßt sich nur als Datenspeicher lesen und schreiben und
kein Code ausführen.[/QUOTE]
Das klingt, als ob die Code-Ausführbarkeit von der Adressierung abhängt.
Kann man dann nicht einfach den Flash an 8000h setzen? So würde ich mir
das indenramladen sparen.
Gibt es noch irgendwo richtig umfangreiche, detaillierte Infos über
diese ganze Speicheradressierungsgeschichte und wie sie angeschlossen
werden? Bin bisher nicht sonderlich fündig geworden. Das Datenblatt vom
8252 macht mich nicht sehr schlau und ansonsten gab es nur nackte
Schaltpläne, die aber nicht näher erklärt wurden. Und was ich
softwaremäßig drehen muss weiß ich so auch noch nicht.
Für die Aufrufe von API-Routinen, die ich im BIOS ablegen würde, müsste
ich dann wahrscheinlich nur an entsprechende Subroutinen im OnChip-Flash
springen oder ein paar Software-Interrupts auslösen, richtig?
Du kannst auch den Flash direkt als Programmspeicher nehmen und den RAM
einsparen.
Du kannst auch den EA-Pin umschalten und dann auch schon ab 0000h
externen Code ausführen.
Usw.
Es führen viele Wege nach ROM.
Insgesamt sind 64kB Code und 64kB Daten adressierbar.
Aber das steht ja viel ausführlicher in den Datenblättern.
Das Philips Datenbuch IC20 ist da sehr zu empfehlen.
Peter
Hi
ich könnte ein Laderroutine in ASM bieten die ein Hexfile entgegennimmt
und ein Flash damit programmiert. Bräuchte sicher ein bischen
Umarbeitung da sowas doch sehr Hardwareabhängig ist. Mein Programm
braucht aber externes RAM da es erst das ganze Hexfile empfängt und
dekodiert. Ließe sich aber auch einfach auf Zeilenweises einlesen
umbauen. Bei Interesse -> Mail
Matthias
So ich schätze inzwischen steige ich ein wenig durch. Habe das IC20 nur
als Helpfile gefunden. Gibt's das auch als pdf zum drucken? Ansonsten
habe ich bei Intel noch ein ca. 330 Seiten starkes manual für die
MCS51-Architektur gefunden. Jetzt werde ich mich mal langsam da
durchschlagen und hoffen, dass ich das gebacken kriege.
Ich bin neu hier, meine erster Gedanke wäre, RAM (so viel wie möglich),
der direkt ausführbaren( vielleicht schon ausgeführten Code durchs
Booten) beinhaltet und dann wie beim Gameboy: Bankswitching! Einfach
verschiedene Segmente einblenden mit Addresscounter (oder sowas
ähnlichem). Dann könnte man zusätzliche Hardware addressieren.
Wenn Du Dich auf den MCS-51 einschießen willst, dann empfehle ich Dir
das "Mikrocontroller-Kochbuch" von Andreas Roth. Es ist meines Erachtens
sehr gut geschrieben, der Anfänger erfährt genau, wie ein MCS-51 ans RAM
angeschlossen werden muß (Schaltungsbeispiele) und auch der Experte
findet immer wieder kleine Tricks. Es ist meine "Bibel", was MCS-51
Programmierung betrifft.
