Ansi C; Syntax einer Funktion, die eine ROM-Adresse zurückgibt

[BL (Gast)]

Hallo,


ich brauch eine Funktion, die eine Adresse aus dem Flash zurückgibt. Nun 
komm ich aber nicht auf die richtige Syntax und die 
Compilerbeschreibung(CC8e) gibt nix her. Kann mir jemand auf die Sprünge 
helfen?

const char *Text (uns8 Zeiger) // Anzeige Text
{
   ...
}

Das nimmt der Compiler z.B. nicht. Muß man dann die Flash-Adresse als 
uns32-Zahl übergeben oder wo ist da der Schlauch geknickt?


Besten Dank für sachdienliche Antworten und verschwendet mit anderen 
bitte nicht Eure Zeit!


BL

[Jörg W. (dl8dtl) (Moderator)]

BL schrieb:
> Das nimmt der Compiler z.B. nicht.

Wie wäre es mit 'ner Fehlermeldung?

Btw., ANSI-C (oder auch seine deutlich jüngeren ISO-Pendants) haben
keine Idee von RAM, ROM oder sowas.

[Mark B. (markbrandis)]

Jörg W. schrieb:
> BL schrieb:
>> Das nimmt der Compiler z.B. nicht.
>
> Wie wäre es mit 'ner Fehlermeldung?
>
> Btw., ANSI-C (oder auch seine deutlich jüngeren ISO-Pendants) haben
> keine Idee von RAM, ROM oder sowas.

Ich würde sogar meinen, dass das auf die allermeisten 
Programmiersprachen ab der 3. Generation zutrifft.

[Jörg W. (dl8dtl) (Moderator)]

Das wollte ich jetzt aber nicht groß auswalzen.  Die Fehlermeldung
wäre schon von Interesse, dann kann sich vielleicht auch jemand einen
Reim drauf machen, der den fraglichen Compiler nicht zur Hand hat.

[Markus F. (mfro)]

CC8e ist offensichtlich ein Compiler für PIC18?

Nachdem meiner Erinnerung nach das Memory-Layout der PICs - sagen wir 
mal so - eher unkonventionell ist, kann es durchaus sein, daß Du da mit 
Banking fummeln mußt. Wie das geht, sollte eigentlich im Datenblatt 
stehen.

Ich würde mal raten(nachdem die PICs nach meiner Erinnerung - zumindest 
in einem für C einigermaßen brauchbaren Memory-Modell - mit 12 Bit 
Adressen arbeiten), daß der Zeiger 16 Bit haben muß.

[BL (Gast)]

Besten Dank, Problem schein erst mal gelöst.

Der Compiler -ja, für PIC18- frißt es erst mal. Im Controller hab ich's 
noch nicht ausprobiert.

Die korrekte Syntax lautet:

const size2 char *MenuText (uns8 Zeiger)

"size2" bezeichnet, dass der ganze Adressbereich, bzw. ein 16-Abschnitt 
angesprochen wird.

[Oliver S. (oliverso)]

An das "uns8 Zeiger" glaube ich aber immer noch nicht. Entweder ist das 
ein blöd gewählter Parametername, oder es ist falsch.

Oliver

[Markus F. (mfro)]

Ich denke, das muß

const size2 char *text(int index) { return txt[index]; }

(oder so ähnlich) heißen. size2 ist anscheinend ein "type modifier" der 
sagt, daß das ein 16-Bit langer Zeiger sein soll.

aber: das ist alles Mögliche, aber "ANSI C", wie in der Fred-Überschrift 
verlangt, ist das ganz bestimmt nicht ;).

[W.S. (Gast)]

Markus F. schrieb:
> Nachdem meiner Erinnerung nach das Memory-Layout der PICs - sagen wir
> mal so - eher unkonventionell ist,

Du bist bloß nicht dran gewöhnt, daß es eben neben der 
v.Neumann-Architektur eben auch noch was Anderes gibt, z.B. Harvard. Da 
ist überhaupt nichts unkonventinelles dran, sondern Harvard ist für 
Controllersysteme eigentlich die viel bessere Architektur, weil sie 
Daten und Befehle in getrennten Adreßräumen führt, was wiederum zu 
beträchtlich einfacherer und damit stromsparender Konstruktion des Chips 
führt. Und auf dem Controller werkelt ja normalerweise eine feste 
Firmware und nicht tausend ladbare Programme wie im PC.

Kein Wunder, wenn es zu Holpereien kommt, wenn man als C-Programmierer 
partout NICHT sich mit den Gegebenheiten der zugrundeliegenden Hardware 
befassen will. Was, Assembler? Bäh. Was, Architektur? nochmals Bäh. Da 
kann nix gescheites draus werden.

W.S.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> Da ist überhaupt nichts unkonventinelles dran, sondern Harvard ist für
> Controllersysteme eigentlich die viel bessere Architektur, weil sie
> Daten und Befehle in getrennten Adreßräumen führt

Sieht man ja prima daran, dass sich ARMs, bei denen alles in einem
Adressraum liegt, partout nirgends durchsetzen konnten.

[Markus F. (mfro)]

W.S. schrieb:
> Du bist bloß nicht dran gewöhnt, daß es eben neben der
> v.Neumann-Architektur eben auch noch was Anderes gibt, z.B. Harvard. Da
> ist überhaupt nichts unkonventinelles dran, sondern Harvard ist für
> Controllersysteme eigentlich die viel bessere Architektur, weil sie
> Daten und Befehle in getrennten Adreßräumen führt, was wiederum zu
> beträchtlich einfacherer und damit stromsparender Konstruktion des Chips
> führt.

Jo, da hast Du völlig recht. Daran bin ich nicht gewöhnt.

Will mich aber auch nicht daran gewöhnen.

Muß ich auch - zum Glück - nicht ;).

[Peter D. (peda)]

BL schrieb:
> Der Compiler -ja, für PIC18- frißt es erst mal. Im Controller hab ich's
> noch nicht ausprobiert.

Zwischen "kein Syntaxfehler" und "funktioniert auch" liegen aber Welten.

Wenn Du nicht ins Assemblerlisting schauen willst, kannst Du einfach ein 
Minimalprogramm drumrum schreiben und es in den Simulator laden.

Wenn ich Funktionspointer oder Structs übergeben will, mache ich das 
vorzugsweise mit typedef.

[W.S. (Gast)]

Jörg W. schrieb:
> Sieht man ja prima daran, dass..

Anstatt mal wieder herumzupolemisieren, hättest du besser an die 
Milliarden 8051 denken können.


Und noch einer:
Markus F. schrieb:
> Will mich aber auch nicht daran gewöhnen.
> Muß ich auch - zum Glück - nicht

Ja, Gärtner oder Friseur ist auch ein grundanständiges Handwerk. Da 
brauchst du keinerlei Detail von irgendwelchen µC zu kennen.

W.S.

[Jörg W. (dl8dtl) (Moderator)]

W.S. schrieb:
> Anstatt mal wieder herumzupolemisieren,

Machst du doch auch.

> hättest du besser an die
> Milliarden 8051 denken können.

Ja, Totgesagte leben länger.  Eine moderne Architektur wird es aber
deshalb trotzdem nicht mehr.  Sie waren gut für ihre Zeit.  Die
getrennten Adressräume sind wohl dennoch das, was ein Programmierer
beim Übergang auf eine Architektur mit flachem Adressraum am wenigsten
vermissen wird.

[W.S. (Gast)]

Jörg W. schrieb:
> Machst du doch auch.

Und? quod licet jovi...

Und es ist egal, welche Architektur sich in den Zeitläuften wie 
verbreitet - wichtig hingegen ist, deren Spezifika zu kennen und 
sachgemäß heranzugehen. Da hapert es allerdings allenthalben, wie man an 
diesem Thread sehen kann. Wer eben zu blöd ist, den Unterschied zwischen 
Harvard und v.Neumann überhaupt zu kennen und dennoch unbedarft in C 
einfach drauflos zu programmieren, kriegt genau deshalb Probleme. 
Unfähigkeit eben.

W.S.