CodeVision AVR Pointer auf fkt()

[Koopi (Gast)]

Hallo und Guten Morgen,

folgende Zeile stellt eine Definition und Zuweisung eines Pointers auf 
eine Funktion dar.

void (*Init_ptr)( void ) = Init; // void init( void );

Laut CodeVisionHelp ist das immer ein Pointer auf flash. Leider nimmt 
sich CodeVision 4 Words Code und 2 Byte SRAM.
Die 2 Byte SRAM pro Pointer machen bei meinem Menue leider gleich 752 
Byte SRAM. Wie läßt sich das verhindern?

Koopi

[winne der philosoph ;-) (Gast)]

mh?

Wahrscheinlich in dem man das Problem welches dich bewogen hat, diesen 
Weg zu gehen auf andere Weise löst. Lleider ist deine Anfrage vollkommen 
frei Evon Zusammenhängen. Das Einzige für mich erkennbare ist, dass du 
aus irgendeinem mir unbekannten Grund versuchst 376 Pointer im SRam 
anzuhäufen. Was sich sicher auch anders lösen läßt. Es sei denn  du 
versuchst sich selbst generierenden Code zu zu erzeugen. Das geht 
freilich nicht im flash und würde dank havard auch im ram nicht 
ausgeführt.   ;-)

[Koopi (Gast)]

Die Anfrage ist bewusst auf den Punkt gebracht.

Ich möchte nichts im SRAM aufhängen, sondern im flash. Ein Menue läßt 
sich mit einer StateMachine, die entsprechend ihres Zustandes auf 
verschiedene Funktionen zugreift, leicht und komfortabel realisieren. 
Dazu muss ich aber mit Zeigern auf die in Frage kommenden Funktionen 
zugreifen können. Das ganze funktioniert mit uVision übrigens sehr gut.

Koopi

[winne (Gast)]

so hier die lösung deines Rätsels eine eigen art von CVAR ist das du den 
speicherort von konstnten variablen und soit pointern definieren kannst

default ist sram alternativ flash und eeprom


siehe CVAVR help
stichwort: pointer

Due to the Harvard architecture of the AVR microcontroller, with separate address spaces for data (SRAM), program (FLASH) and EEPROM memory, the compiler implements three types of pointers.
The syntax for pointer declaration is:

[<type storage modifier>] type * [<pointer storage modifier>]
[* [<pointer storage modifier>] ...] pointer_name;

or

type [<type storage modifier>] * [<pointer storage modifier>]
[* [<pointer storage modifier>] ...] pointer_name;

where type can be any data type.

Variables placed in SRAM are accessed using normal pointers.
For accessing constants placed in FLASH memory, the flash type storage modifier is used.
For accessing variables placed in EEPROM, the eeprom type storage modifier is used.
Although the pointers may point to different memory areas, they are by default stored in SRAM.
Example:

/* Pointer to a char string placed in SRAM */
char *ptr_to_ram=”This string is placed in SRAM”;

/* Pointer to a char string placed in FLASH */
flash char *ptr_to_flash1=”This string is placed in FLASH”;
char flash *ptr_to_flash2=”This string is also placed in FLASH”;

/* Pointer to a char string placed in EEPROM */
eeprom char *ptr_to_eeprom1="This string is placed in EEPROM";
char eeprom *ptr_to_eeprom2="This string is also placed in EEPROM";

In order to store the pointer itself in other memory areas, like FLASH or EEPROM, the flash or eeprom pointer storage modifiers must be used as in the examples below:

/* Pointer stored in FLASH to a char string placed in SRAM */
char * flash flash_ptr_to_ram=”This string is placed in SRAM”;

/* Pointer stored in FLASH to a char string placed in FLASH */
flash char * flash flash_ptr_to_flash=”This string is placed in FLASH”;

/* Pointer stored in FLASH to a char string placed in EEPROM */
eeprom char * flash eeprom_ptr_to_eeprom="This string is placed in EEPROM";

/* Pointer stored in EEPROM to a char string placed in SRAM */
char * eeprom eeprom_ptr_to_ram=”This string is placed in SRAM”;

/* Pointer stored in EEPROM to a char string placed in FLASH */
flash char * eeprom eeprom_ptr_to_flash=”This string is placed in FLASH”;

/* Pointer stored in EEPROM to a char string placed in EEPROM */
eeprom char * eeprom eeprom_ptr_to_eeprom="This string is placed in EEPROM";

In order to improve the code efficiency several memory models are implemented.

The TINY memory model uses 8 bits for storing pointers to the variables placed in SRAM. In this memory model you can only have access to the first 256 bytes of SRAM.

The SMALL memory model uses 16 bits for storing pointers the variables placed in SRAM. In this memory model you can have access to 65536 bytes of SRAM.

In both TINY and SMALL memory models pointers to the FLASH memory area use 16 bits.

Because in these memory models pointers to the FLASH memory are 16 bits wide, the total size of the constant arrays and literal char strings is limited to 64K.
However the total size of the program can be the full amount of FLASH.

In order to remove the above mentioned limitation, there are available two additional memory models: MEDIUM and LARGE.
The MEDIUM memory model is similar to the SMALL memory model, except it uses pointers to constants in FLASH that are 32 bits wide. The pointers to functions are however 16 bit wide because they hold the word  address of the function, so 16 bits are enough to address a function located in all 128kbytes of FLASH.

The MEDIUM memory model can be used only for chips with 128kbytes of FLASH.

The LARGE memory model is similar to the SMALL memory model, except it uses pointers to the FLASH memory area that are 32 bits wide.
The LARGE memory model can be used for chips with 256kbytes or more of FLASH.

In all memory models pointers to the EEPROM memory area are 16 bit wide.

Pointers can be grouped in arrays, which can have up to 8 dimensions.
Example:


/* Declare and initialize a global array of pointers to strings  

   placed in SRAM */

char *strings[3]={"One","Two","Three"};

/* Declare and initialize a global array of pointers to strings  

   placed in FLASH

   The pointer array itself is also stored in FLASH */

flash char * flash messages[3]={"Message 1","Message 2","Message 3"};

/* Declare some strings in EEPROM */

eeprom char m1[]="aaaa";

eeprom char m2[]="bbbb";

void main(void) {

/* Declare a local array of pointers to the strings placed in EEPROM

   You must note that although the strings are located in EEPROM,

   the pointer array itself is located in SRAM */

char eeprom *pp[2];

/* and initialize the array */

pp[0]=m1;

pp[1]=m2;

}

Pointers to functions always access the FLASH memory area. There is no need to use the flash keyword for these types of pointers.

Example:

/* Declare a function */

int sum(int a, int b) {

return a+b;

}

/* Declare and initialize a global pointer to the function sum */

int (*sum_ptr) (int a, int b)=sum;

void main(void) {

int i;

/* Call the function sum using the pointer */

i=(*sum_ptr) (1,2);

}

[winne (Gast)]

man kann auch nach storage modifier suchen ;-)

wenn deine funktionen fix sind sollte das mit flash als modifier gehen 
:-)

[winne (Gast)]

etwa so

void (flash *Init_ptr)( void ) = Init; // void init( void );

oder so

void (eeprom *Init_ptr)( void ) = Init; // void init( void );

[winne (Gast)]

Berichtigung der modifier muss hinter den * wen der pointer ins flash 
soll.

void (*flash Init_ptr)( void ) = Init; // void init( void );

Achtung wenn funktionen auf diesen pointer zugreifen sollen uss diesen 
auch mitgeteilt werden wo sie den pointer finden.

[winne (Gast)]

das sieht dan etwa so aus

void LCD_Write_Strf (flash char str [] )
{   
    while ( *str )
        {
        LCD_Write_Data_to_RAM(*str++);
        }
   
}  
//------------------------------------------------- 
void LCD_Write_Stre (eeprom char str [] )
{   
    while ( *str )
        {
        LCD_Write_Data_to_RAM(*str++);
        }
   
}

[Koopi (Gast)]

@winnie,

danke die 10:21 Antwort ist der Treffer.

Ich habe alle Varianten ( auch die 10:12 ) versucht, aber nicht *flash.

Kannst Du mir sagen warum es flash und nicht flash sein muss? Es ist 
zwar richtig, für mich aber nicht plausibel! ( Horizonterweiterungsfrage 
)

ein weiteres danke, dass Du nicht erst eine andere Lösung in den Raum 
geworfen hast. Davon gibt es hier leider reichlich.

[Koopi (Gast)]

Berichtigung:
Das fette soll heißen: "(Stern)flash und nicht flash(Stern)"

Koopi

[winne (Gast)]

>Kannst Du mir sagen warum es flash und nicht flash sein muss?

Das ist eine Syntaxfrage. Die Reihenfolge bei CVAVR lautet nunmal so.
Der storage modifier wird dem identifier vorangestellt, und dem Ganzen 
der Pointerstern wenn man sich auf den Pointer und nicht auf das 
funktionsergebnis bezieht.

Ich arbeite schon seit drei Jahren mit CVAVR und inzwischen 
überglücklich. Aber anfänglich bin ich fast verrückt geworden damit. 
Insbesondere damit, dass man für verschiedenen Speicherorte auch 
verschiedene Funktionen braucht. Ich komme von der 6502 mit einem 
itegriertem Adressraum. Die Umstellung auf Havard birgt Tücken, diese 
förden den Lernprozess, und deshalb habe ich sofort daran gedacht als 
ich dein Dilemma erkannte.

Leider scheinen viele das Geld und die Mühen des CVAVR zu scheuen. So 
bin ich bemüht diesem hier im forum zu einem Stand zu verhelfen, der 
diesem mächtigen Compiler nebst Helferlein (speziel sei der Codewizzard 
erwähnt) gerecht wird.

[Koopi (Gast)]

ich arbeite auch schon einige Jahre mit diesem Compiler. Da ich aber 
sehr viel mit uVision und IAR mache, fallen mir doch immer wieder einige 
Unzulänglichkeiten auf. Wie Du schon bemerkt hast, sind die 
Funktionsaufrufe mit verschiedenen Speichertypen ein Problem. Das selbe 
Problem gibt es bei den structs und typedefs.
Der Editor hätte auch einige Erweiterungen nötig. Da wären insbesondere 
ein "Go to Definition" und fehlende Reiter für die gerade offenen 
Funktionen zu erwähnen.

Wenn ich aber den äußerst gut kalkulierten Preis dagegen halte ist es 
wieder in Ordnung ( uVision z.B. kostet 3000 Euro ).

Koopi