Pointer auf Flash im dsPIC

[Horst (Gast)]

Hallo,
im Program Memory meines dsPIC33EP habe ich eine Liste an Daten, auf die 
ich zugreifen möchte. Am elegantesten ließe sich das in meinem Fall wohl 
über einen Pointer machen. Nur zeigt ein Pointer normalerweise ja auf 
den RAM und nicht den Flash. Im Users Guide des XC16 Compilers auf Seite 
147 habe ich aber folgendes gefunden:

__prog__ char * myPROGpointer;

"The pointer in this example does not use the space attribute as it is 
located in data memory, but the qualifier indicates how the pointer 
targets are to be accessed."
Hier das Dokument:
http://ww1.microchip.com/downloads/en/DeviceDoc/50002071F.pdf

Das klingt wunderbar einfach und genau danach, was ich suche. Ich 
fürchte aber, dass ich da noch etwas falsch verstanden habe. Erstens 
wundert mich, dass der Pointer als char deklariert wird.
Außerdem hätte ich im Disassembly irgendeinen Table Read Befehl 
erwartet. Stattdessen wird mein Pointer wie eine normale Variable 
behandelt:

x = *TablePtr;
MOV [W4], W6
MOV W6, x

x und TablePtr habe ich so deklariert:

uint16_t x;
__prog__ uint16_t *TablePtr;

Was mache ich falsch?

[W.S. (Gast)]

Horst schrieb:
> Was mache ich falsch?

Du programmierst PIC's in C und vertraust obendrein auch noch deinem 
Selbstgefühl, so nach dem Motto: "Wenn ich mir nen Pointer mache, dann 
hat der ja gefälligst dorthin zu zeigen, wo ich es haben will"

Mit den dsPIC's hab ich keine eigene Programmiererfahrung, aber dafür 
reichlich mit den kleineren PIC's - und die programmiere ich 
grundsätzlich in Assembler. Alles Andere kommt mir eher krampfig vor.

W.S.

[(prx) A. K. (prx)]

Horst schrieb:
> Hallo,
> im Program Memory meines dsPIC33EP habe ich eine Liste an Daten, auf die
> ich zugreifen möchte. Am elegantesten ließe sich das in meinem Fall wohl
> über einen Pointer machen.

Um wieviele Megabytes geht es?

Die 16-Bit PICs können mit einem normalen Pointer in den Datenbereich 
auch auf das Flash zugreifen, weil mit der zweiten 32KB Hälfte des 
Datenbereichs nicht RAM, sondern Flash adressiert wird. Infolgedessen 
wird der Compiler im default const-in-code memory model - anders als bei 
anderen µCs mit Adressraumtrennung - "const" Daten direkt ins Flash 
legen und sie dennoch wie Daten im RAM adressieren.

Der einfachste Weg, Daten im Flash zu verarbeiten, besteht also darin, 
die entsprechenden Daten als "const ..." zu deklarieren und mit "const 
... *" zu adressieren.

Grenzen findet dieses Verfahren, wenn man auch das dritte Byte der 
24-Bit Codeworte als Daten verwenden will. Denn das beschriebene 
Verfahren kann nur 2 der 3 Bytes nutzen.

[Frank K. (fchk)]

W.S. schrieb:

> Mit den dsPIC's hab ich keine eigene Programmiererfahrung, aber dafür
> reichlich mit den kleineren PIC's - und die programmiere ich
> grundsätzlich in Assembler. Alles Andere kommt mir eher krampfig vor.

Du schreibst wie ein Blinder über Farben. dsPIC/PIC24 hat eine völlig 
andere CPU-Systemarchitektur als PIC10/12/16/18 - AVRs (vor allem die 
ganz neuen) sind näher dran, was die CPU angeht.

Und PIC32 ist wieder völlig anders.

Was ähnlich ist, ist die Peripherie.

fchk

[Toxic (Gast)]

W.S. schrieb:
> Mit den dsPIC's hab ich keine eigene Programmiererfahrung, aber dafür
> reichlich mit den kleineren PIC's - und die programmiere ich
> grundsätzlich in Assembler. Alles Andere kommt mir eher krampfig vor.

Warum krampfig? Habe erst vor kurzem einen PIC12F1840 (Nachfolger vom 
PIC12F683) mit XC8 und C-Code maltraetiert.Ich find's super,obwohl ich 
bisher die kleinen Pics auch nur in Assembler programmiert habe.
Ich bin offen fuer beide Varianten und werde mir garantiert keinen 
Forumnamen wie zB. "C-Hater" oder "Assembler-Hater" zulegen....?

[W.S. (Gast)]

Toxic schrieb:
> Ich bin offen fuer beide Varianten und werde mir garantiert

OK, lassen wir mal die Kalauer, denn "Toxic" ist m.E. auch einschlägig.

Und warum krampfig? Weil man heutzutage nicht auf Biegen oder Brechen 
nen PIC benutzen muß. Die kleinen PIC's programmiere ich immer noch in 
Assembler und wenn das, was ich vorhabe, mir eher nach C riecht, dann 
greife ich lieber zu einer anderen Architektur, es sei denn, noch 
wichtigere Argumente würden einen PIC diktieren. Ah ja, mir fällt da 
wieder was ein, minimalistischer Frequenzzähler. Der profitiert vom 
asynchronen Prescaler bei den PIC's, da gibt es m.W. keine anderen 
Chips, die eine für diesen Zweck so gut geeignete Peripherie drin haben.

W.S.

[(prx) A. K. (prx)]

W.S. schrieb:
> greife ich lieber zu einer anderen Architektur,

Die 8-Bit PICs und die hier betrachteten 16-Bit PICs sind sich in ihrer 
Architektur weniger ähnlich als AVR und AVR32. Keilereien um C- vs 
Asm-Programmierung bei 8-Bit PICs sind hier also völlig fehl am Platz 
und Erfahrungen mit 8-Bit PICs helfen auch nicht weiter.

Familienähnlichkeit gibts bei 8/16/32-Bit PICs nur bei der Periphierie. 
Da sind Module, Begriffe und Konzepte familienübergreifend.