Teile des Programmspeichers unter Bascom auslesen

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")

Data, Read, Restore...

...

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...

> 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

...