Falsche Deklaration in pgmspace.h ?

[Hagen R. (hagen)]

Hi Leute

im Headerfile pgmspace.h ist folgendes deklariert

#ifndef __ATTR_CONST__
#define __ATTR_CONST__ __attribute__((__const__))
#endif

#ifndef __ATTR_PROGMEM__
#define __ATTR_PROGMEM__ __attribute__((__progmem__))
#endif

#ifndef __ATTR_PURE__
#define __ATTR_PURE__ __attribute__((__pure__))
#endif

#define PROGMEM __ATTR_PROGMEM__

typedef void prog_void PROGMEM;
typedef char prog_char PROGMEM;
typedef unsigned char prog_uchar PROGMEM;

typedef int8_t    prog_int8_t   PROGMEM;
typedef uint8_t   prog_uint8_t  PROGMEM;
typedef int16_t   prog_int16_t  PROGMEM;
typedef uint16_t  prog_uint16_t PROGMEM;
#if !defined(__USING_MINT8)
typedef int32_t   prog_int32_t  PROGMEM;
typedef uint32_t  prog_uint32_t PROGMEM;
#endif
typedef int64_t   prog_int64_t  PROGMEM;
typedef uint64_t  prog_uint64_t PROGMEM;

Wenn ich nun eine Konstante/Variable als

prog_uint_t c1[] = {1,2,3,4};

deklariere, erwarte ich eigentlich das diese Daten im FLASH abgelegt 
werden und ich später mit pgm_read_byte() darauf zugreifen kann.

Die Daten werden aber nicht in .section  .progmem.data,"a",@progbits 
abgelegt sondern in .data

Ein Zugriff mit pgm_read_byte() muß also schweitern.

Ich meine die Deklaration ist falsch denn benutzt man nachfolgendes 
klappt es

typedef uint8_t   prog_uint8_t  __attribute__ ((PROGMEM));

statt eben

typedef uint8_t   prog_uint8_t PROGMEM;

Liege ich mit meiner Annahme richtig, oder mach ICH was falsch ?

Gruß hagen

[Patrick D. (oldbug)]

Hallo Hagen!

Hm, Dein Problem kann ich nicht nachvollziehen.
Folgender Code:

#include <avr/io.h>
#include <avr/pgmspace.h>

prog_uint8_t    c1[] = {1,2,3,4};

int
main(void)
{
        return 0;
}

...ergibt folgendes .map-File:

 *(.progmem.gcc*)
 *(.progmem*)
 .progmem.data  0x0000008c        0x4 main.o
                0x0000008c                c1
                0x00000090                . = ALIGN (0x2)
 *(.init0)

Alles in Sahne, aus meiner Sicht...

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

Ich sehe das Gleiche.

Der vorgeschlagene Ersatz expandiert zu:

typedef uint8_t prog_uint8_t __attribute__ ((__attribute__((__progmem__))));

was der Compiler verständlicherweise nicht compilieren möchte.

Ich habe den Eindruck, Hagen hat hier irgendwas anderes als wir...

[Hagen R. (hagen)]

hm ich verstehe es auch nicht

#include <inttypes.h>
#include <avr/signal.h>
#include <avr/eeprom.h>
#include <avr/pgmspace.h>
#include <avr/delay.h>
#include <stdio.h>
#include "uart.h"

prog_uint8_t c1[] = {0x00, 0x00, 0x01,    // Oscillator on
                        0xFF};
uint8_t PROGMEM c2[] = {0x07, 0x00, 0x00,    // Display control           PT1-0=00, VLE1-0=00, SPT=0, GON=0, DTE=0, CL=0, REV=0, D1-0=00
                        0x02, 0x04, 0x00,    // LCD Drive AC control      FLD1-0=01, B/C=0, EOR=0, NE5-0=000000
                        0x04, 0x00, 0x00,    // Power control (2)         CAD=0
                        0x0C, 0x00, 0x01,    // Power control (3)         VC2-0=001
                        0x0D, 0x06, 0x06,    // Power control (4)         VRL3-0=0110, PON=0, VRH3-0=0110
                        0x0E, 0x00, 0x00,    // Power control (5)         VCOMG=0, VDV4-0=00000, VCM4-0=00000
                        0xFF};

und im MAP dann

 *(.progmem.gcc*)
 *(.progmem*)
 .progmem.data  0x0000008c       0x6d main.o
                0x000000a6                c4
                0x0000008c                c2
                0x000000aa                c5
                0x0000009f                c3
                0x000000fa                . = ALIGN (0x2)
 *fill*         0x000000f9        0x1 00
 *(.init0)

                0x000015da                _etext = .

.data           0x00800100      0x5b4 load address 0x000015da
                0x00800100                PROVIDE (__data_start, .)
 *(.data)
 .data          0x00800100      0x5ad main.o
                0x00800102                ascii_tab
                0x00800644                c1
                0x00800642                backcolor

wie man sieht c1 liegt eben nicht da wo c2 bis c4 liegen !

Ich habs jetzt eben so gemacht das ich mit

uint8_t PROGMEM c2[].....

arbeite, das geht und ich vergeude keine Zeit bei der Fehlersuche.

Gruß Hagen

PS: welchen f..k formatierungstag muß ich eingeben das der Source als 
Source angezeigt wird ?

 ...

 scheint ja nicht zu funktionieren ?

[Hagen R. (hagen)]

mein PS hat sich erledigt, habs selber rausbekommen.

Gruß Hagen

[Patrick D. (oldbug)]

C und /C für C-Code, VHDL und /VHDL für VHDL ;-)
pre und /pre verwende ich für Kommandozeilen oder sonstige files (z.b. 
der .map-File Auszug ist darin eingebettet)...

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

#include <avr/signal.h>
...
#include <avr/delay.h>

deutet darauf hin, dass du eine ziemlich alte Version der Bibliothek
nimmst.  <avr/signal.h> ist ersatzlos gestrichen und sein vormaliger
Inhalt in <avr/interrupt.h> aufgegangen (wo er von vornherein hin
gehört hätte), und <avr/delay.h> heißt jetzt <util/delay.h>.

Hmm, andererseits habe ich gerade im CVS nachgeguckt, da hat sich
nichts Wesentliches geändert seither.

[Hagen R. (hagen)]

"deutet darauf hin, dass du eine ziemlich alte Version der Bibliothek
nimmst. "

Das stimmt allerdings. Ich hatte zwar schon die neuste Version vom GCC + 
Lib installiert aber noch nicht die Zeit gefunden alles darauf 
umzustellen. Solltes es doch mal machen bevor ich rum"meckere" ;) Bin 
halt ziemlich konservativ wenn es um meine Werkzeuge geht.

@Patrick: danke für den Hinweis.

Gruß Hagen