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
Das ist übelst aufwendig... ist doch einfacher gleich einen uC zu nehmen der das von Haus aus kann (Peter, dein Einsatz!).
Da wäre beispielsweise ein MCS-51 Controller angebracht. Der kann externen RAM für Code nutzen und ist sehr weit verbreitet.
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.
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.