www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bootloader basteln...


Autor: Hugoderwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MdeWendt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was für Atmel Controller

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die AVRs können keinen Programmcode aus externem Speicher ausführen. 
Stichwort: "Konsolenbau" ;-)

Autor: Christian Schifferle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist übelst aufwendig... ist doch einfacher gleich einen uC zu nehmen 
der das von Haus aus kann (Peter, dein Einsatz!).

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da wäre beispielsweise ein MCS-51 Controller angebracht. Der kann 
externen RAM für Code nutzen und ist sehr weit verbreitet.

Autor: Hugoderwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Vogt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hugoderwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hugoderwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: vogt31337 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.