Hallo, meine Idee ist, Daten im hinteren Teil des Programmspeichers eines AVR-Controllers abzulegen. D.h., im vorderen Speicher befindet sich das kompilierte Bascom-Programm, welches auf die Daten im hinteren Speicherteil zugreift (nur Auslesen). Geht das und wenn ja, kann jemand ungefähr sagen, wie?
Wie kommen denn die Daten in den "hinteren" Speicherbereich? Ich Ram gingen sie beim Ausschalten verloren. Wenn das ok ist, kannst Du den Befehl "Data" verwenden. Wenn sie nicht verlorengehen sollen, speichere im Eprom (deklarieren "AS Eram")
eprom ist zu klein die daten sollen mit dem programm als hex-file übertragen werden
Data, Read, Restore... Nun schau doch emdlich mal in Deine Bascom-Hilfe nach den genannten Begriffen/Befehlen/Anweisungen... ...
Hallo Hannes, Danke für die Schlagworte! Sorry, bin noch nicht dazu gekommen, sie in der Bascomhilfe nachzuschlagen, habe sie aber schon notiert!!! Nachschlagen folgt...
Hallo, habe die Befehle unter Bascom nachgeschlagen und da kamen sie mir auch gleich aus C64er-Zeiten wieder bekannt vor ;) Habe dann auf die Schnelle auch gleich mal ausprobiert, wie viel Platz eine Zahl (in dem Fall Byte) im Speicher frisst; anscheinend nur so viel, wie sie auch gross ist. Blöd ist nur, dass ich ca. 50kb Daten habe, bis die als Data-Zeilen abgetippt sind, ist möglicherweise das Silizium-Zeitalter schon wieder vorbei... Davon ab müssen die Daten auch z.T. „mittendrin“ ausgelesen werden, weiß jetzt gar nicht, ob das mit Data-Zeilen möglich ist. Es gibt aber wohl noch eine Variante mit dem Inp(x)-Befehl, mit ihm kann man anscheinend Adressen bis &HFFFF auslesen. Mit Peek(x) geht’s wohl eher nicht, Tests aber bisher noch nicht vorgenommen. Hat jemand einen Tip für einen freeware-Hex-Editor, mit dem man die Daten an das kompilierte Bascom-Prog anhängen kann? Viele Grüsse!
Hi Mit etwas Assembler, Stichwort 'LPM/ELPM', ist das mit ein paar Zeilen erledigt. MfG Spess
Noch ein Vorschlag: Ich habe in einem ähnlichen Fall ein 24C512 als externen Speicher benutzt. Werner
> Hat jemand einen Tip für einen freeware-Hex-Editor, mit dem man die > Daten an das kompilierte Bascom-Prog anhängen kann? Wenn Du mit BASCOM werkelst, dann kannst Du ja BASIC. Was hindert Dich daran, ein QBASIC- oder Visual-BASIC-Programm zu schreiben, dass Dir die Data-Zeilen erstellt? Ich schreibe größere .db/.dw-Blöcke auch nicht von Hand, da muss auch VB oder QB dran glauben und mir aus den gewünschten Daten oder Funktionen eine fertige Include-Datei erstellen. ;-) ...
> Ich habe in einem ähnlichen Fall ein 24C512 als externen Speicher > benutzt. Das ist sicher nicht immer nötig. Wenn die Daten (Konstanten, z.B. Zeichensatz, Soundstream, Tabellen) ins Flash reinpassen, dann gibt es keinen Grund, ein externes EEPROM zu benutzen. So füllt z.B. eine Schrankensteuerung (2 verschiedene Blinker, 2 Servos als Antriebe, Soundausgabe der Glockenschläge) einen Mega8 den Flash zu knapp 45% (incl. Sounddaten), es würde also sogar im Mega48 Platz finden. Es ist allerdings in ASM, die Sounddaten werden in BASCOM aber auch nicht größer. ...
Hallo, Danke für die vielen Antworten! Über den externen Speicher hatte ich auch schon nachgedacht, es müsste aber eigentlich auch so gehen. ASM ins Basic einzubauen wäre zu überlegen, wenn es anders nicht geht. Bei den künstlichen Datazeilen wäre noch das Problem, dass die Daten nicht am Stück ausgelesen werden, sondern immer nur Segmente benötigt werden. Alleine von der Verwaltung her wären definierte Speicheradressen wesentlich besser geeignet. Der oben erwähnte INP(x)-Befehl (x= Adresse der auszulesenden Speicherzelle) müsste irgendwie für meine Zwecke anwendbar sein... mit ihm kann man auch externen Speicher auslesen. Allerdings ist mir nicht ganz klar, wie man ihn initialisieren muss, damit der interne Speicher ausgelesen werden kann. Meine Versuche in diese Richtung haben bis jetzt jedenfalls keine Früchte getragen. Die auf diese Weise ausgelesenen Speicherzellenwerte stimmen nicht mit den tatsächlichen überein und besitzen meistens den Wert &H00. Weiß jemand, wie man den Bascom-Befehl INP(x) auf den internen Programmspeicher (Flash ROM) anwendet?
> Bei den künstlichen Datazeilen wäre noch das Problem, dass die Daten > nicht am Stück ausgelesen werden, sondern immer nur Segmente benötigt > werden. Ja wo ist dann Dein Problem? Du kannst die DATA-Blöcke durch Labels trennen. Du kannst RESTORE mit Label verwenden. Somit hast Du die Möglichkeit, ohne Kenntnis der realen Adressen den Lesezeiger auf den Anfang eines jeden Data-Blocks zu setzen. ...
@JensNernst was Du suchst ist Data, Loadlabel und CPeek. Bin gespannt ob Du aus Deinem Crosspost im Bascom-Forum Antwort bekommst...
Schau Dir mal die Beispiele für die GraphLCD an! Dort werden die Bilder als Data in den Flash (nicht den EEPROM) compiliert. Habe ich selber schon etliche male gemacht! Ohne dem wäre der EEPROM zu klein!
> Der oben erwähnte INP(x)-Befehl (x= Adresse der auszulesenden > Speicherzelle) müsste irgendwie für meine Zwecke anwendbar sein... Nein, INP(x) entspricht dem LDS-Befehl, der kann nicht auf Flash zugreifen, nur auf RAM. Zu RAM gehört: 0-31: Register R0 bis R31 (gemappt) 32-95: I/O-Register 0-63 (gemappt) 96-Ramend: SRAM (erst intern, dan XMEM) oder stattdessen: 96-255: Extended I/O-Register (nicht alle AVRs) 256-Ramend: SRAM (erst intern, dan XMEM) Der Flash liegt in einem eigenen Adressraum und das EEPROM hat einen weiteren eigenen Adressraum. Vielleicht solltest Du Dich mal mit dem Unterschied zwischen v.Neumann- und Harvard-Architektur vertraut machen. Dein C64 hat(te) v.Neumann-, der AVR hat Harvard-Architektur. ...
Hallo Leute, mal wieder Danke für die vielen Antworten!!! Hier erst mal nur ganz kurz: CPEEK(x) bringt auf jeden Fall schon mal sinnvollere Ergebnisse. Allerdings stimmen die Adressen im Programmierfeld von Bascom nicht mit den x-Werten bei CPEEK(x) überein, weis jemand etwas darüber? (hatte leider noch keine Zeit, das näher zu beleuchten, anscheinend gibt es eine Parallelverschiebung in der Adressierung der Speicherbytes) Hat das möglicherweise mit der von Hannes erwähnten Harvard-Architektur des AVRs zu tun? Viele Grüsse und auch schon mal schönes Wochenende!
Alle Zugriffe auf Flash erfolgen über den Z-Pointer und LPM. Wie diese Zugriffe funktionieren, ist im Datenblatt bei der Speicherbeschreibung mit Text und Grafiken erklärt. Wie eine Hochsprache (wie BASCOM) den Befehl LPM nutzt, weiß ich nicht, ich bevorzuge die direkte Art, der AVR auch, er kann kei BASIC. Du wirst also die von BASCOM angebotenen Konzepte näher analysieren müssen. Um das besser geeignete Konzept auswählen zu können, müsste man erstmal wissen, wie Deine Flash-Zugriffe aussehen. Denn da gibt es ja auch unterschiedliche Ansprüche. Z.B. (nicht vollständig): - Es soll ein Soundstream im festen Zeitraster an einen Port ausgegeben werden (alle x µs das nächste Byte, Restore/Read) - Es soll aus einem Zeichensatz das dem ASCII-Wert zugehörige Bitmuster ermittelt werden (Zugriff über Index) - Es soll zu einem Funktionsargument ein Rückgabewert ermittelt werden (Lookup-Tabelle) Beim flüchigen Ansehen der BASCOM-Hilfe sind mir READ, CPEEK und LOOKUP mit entsprechenden Varianten (z.B. für Strings) aufgefallen. Genauer will ich da aber nicht einsteigen, ich bevorzuge die direkte, unmissverständliche Programmierung in ASM. Da muss ich nicht 27 mal um die Ecke denken. ...
@Hannes, würde Jens verstehen was Du sagst, würde er nicht über 3 Foren crossposten, in dem ihm wieder jeder das selbe sagt, das MCS Forum, das Bascom Forum und hier, nimm CPeek ! Das ist laut Bascom Hilfe dafür vorgesehen, hab's doch auch bereits geschrieben, Loadlabel und CPeek. Loadlabel liefert bei Übergabe des entsprechenden Datalabels eine Wordadresse, die man CPeek übergibt, welche einem dann das entsprechende Byte an dieser Adresse ausgibt. CPeek macht nichts anderes als daß es die Wordadresse in das Z-Register lädt und LPM aufruft. Aber Jens ist recht lern- und verständnisresistent.
> CPeek macht nichts anderes als daß es die Wordadresse in das Z-Register > lädt und LPM aufruft. Aha, dann kann man also zwischen LOADLABEL() und CPEEK() noch einen Index zur Basisadresse addieren um Lookup-Zugriffe zu erreichen. > das MCS Forum, das Bascom Forum und hier Aha, das wusste ich nicht, ich besuche die anderen genannten Foren nicht. Ääähhh, nein, ich bin kein BASIC-Muffel, Commodore Plus/4 (C16) und PC programmier(t)e ich in BASIC. Beim AVR empfinde ich ASM aber als einfacher. Das hat vermutlich damit zu tun, dass meine ersten AVRs kein SRAM hatten und ich von der Existenz von BASCOM damals auch nichts wusste. Aber das ist gut so, in ASM bin ich flexibler. ;-) ...
Ja, genau, man kann durch zuaddieren eines Index auf die Wordadresse einen freien Zugriff auf die Data Anweisungen aufbauen, und muss nicht die sequentielle Read Anweisung verwenden. Ist ja auch kein Problem, nicht jeder mag's, manche hassen es. Ich schätze Bascom um ein paar Sachen einfach zu programmieren. Man muss das ganze Config-Zeugs auch nicht mitmachen, sondern kann die AVR Register über die normalen Namen konfigurieren und ansprechen, was mir persönlich lieber ist. Kritische Sachen mach' ich in Assembler, das lässt sich hervorragend in den Basic Code integrieren. Es fehlen mir nur ab und zu die Pointer von C, das wär schon manchmal praktisch. Aber ich hatte mal einen Temperatursensor, glaube es war ein DS1820, in C implementiert, das war vielleicht ein Mist. Da ist Bascom wirklich bequem. Wenn mich interessiert, was Bascom so macht und wie sauber das Compilat ist, lad' ich das Obj File in's AVR Studio und ruf mir den Disassembler auf. Und wenn man nicht versteht, wie die Register des MC zu verwenden sind, hilft einem auch C nix...
> Und wenn man nicht versteht, wie die Register des MC zu verwenden sind, > hilft einem auch C nix... Das Verständnis der Architektur (Register, Maschinen-Befehlssatz, Adressbereiche, I/O-Features) ist in jeder Programmiersprache ein unschätzbarer Vorteil (bezogen auf kleine Mikrocontroller, nicht auf PC, wo die Ressourcen generell verschwendet werden). ...
Probier doch mal folgendes: Definiere eine Stringvariable der gewünschten Länge. Mit dem Bascombefehl LOADADR var , reg ermittelst du die Adresse und los geht es (in ASM).
LOADADR Var,Reg wirkt aber auf SRAM und nicht auf Flash, denn VARiablen liegen im SRAM. Hier geht es darum, Konstanten im Flash zu adressieren. ...
Hallo, nach einem turbulenten Wochenende und einem ebensolchen Wochenstart will ich noch mal kurz den Faden aufnehmen und mich für eure aktive Hilfe bedanken! Dieser Dank geht hier auch ganz besonders an Hannes! Der Befehl CPEEK(x) ist, wie sich nach eingehender Prüfung gezeigt hat, genau das, was ich gesucht habe! Ich denke mal, dass jetzt alles weitere gelingen müsste, ansonsten melde ich mich noch mal. Für die Zukunft würde ich gerne auch ein paar kleinere AVR-Projekte in ASM bewältigen. Wenn jemand hier an dieser Stelle mit ein paar Tipps weiterhelfen kann und möchte (Buchempfehlungen, links etc.), bin ich sehr verbunden! Werde hierzu aber auch noch im einzelnen die Forensuche frequentieren. Also viele Grüsse und viel Spass beim Arbeiten und Basteln weiterhin!
> Für die Zukunft würde ich gerne auch ein paar kleinere AVR-Projekte in > ASM bewältigen. Gute Idee... > Wenn jemand hier an dieser Stelle mit ein paar Tipps > weiterhelfen kann http://www.mikrocontroller.net/articles/AVR-Tutorial http://www.avr-asm-tutorial.net/ http://www.hanneslux.de/avr/index.html ...
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.