GCC - Länge eines Const Array in ein anderes bringen

[Draco (Gast)]

Ich habe hier ein "Problem", welches eigentlich aus Faulheit aufgekommen 
ist. :-D

Ich habe ein Const Array (Ein HID Desc.) von welchem ich die Länge 
brauche:

  static const uint8_t PROGMEM rep_desc[] =
  {
    0x05, 0x01,                    
    0x09, 0x05,                    
    0xa1, 0x01,                    
    0x05, 0x09,                    
    0x19, 0x01,                    
    0x29, 0x06,                    
    0x15, 0x00,                    
    0x25, 0x01,                    
    0x95, 0x06,                   
    0x75, 0x01,                    
    0x81, 0x02,                    
    0x95, 0x01,                    
    0x75, 0x02,                  
    0x81, 0x03,                   
    0xc0
  };

Nun muss (möchte) ich die länge des Arrays in ein anderes, 
gleichartiges, Array bringen. Normalerweise mach ich das ja mit 
sizeof(). Jeoch meckert er dann rum, das sizeof() dann nicht 'const' ist 
- Logischerweise. Wie kann ich das umgehen? Momentan bleibt mir nichts 
weiter übrig und zähle die Werte per Hand und schreibe sie dann in das 
andere Array... aber wenn ich hier nun hundertmal rumteste, ist das 
wirklich nervig!

Danke für eure Hilfe.

p.s. So in etwa meine ich das, das geht ja nun nicht:

  static const uint8_t PROGMEM dev_desc[] =
  {
    0x09,0x21,        
    0x11,0x01,   
    0x00,0x01,        
    0x22,sizeof(rep_des)
  };

[Dr. Sommer (Gast)]

C++ nehmen, da geht das IIRC genau 1:1 so

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

In eine Variable schreiben und den Pointer auf diese in das Array?

Lustigerweise meckert der GCC bei mir bei was ähnlichem nicht rum:

struct dispwert {  
  char uschrift[50];
  unsigned short adress;
  //Floatingpointanzeigen Formatangaben (müssen auf 6 Zeichen passen!)
  unsigned after; //Ziffern nach dem Komma
  float divider; //zB um kWh statt Wh anzuzeigen
};

//Array aus structs was angezeigt werden soll
struct dispwert anzeigeelemente[] = {
  {"P L3 MAX kw", P_L3_MAX, 3, 1000.0},
  {"U L3N", U_L3N, 2, 1.0},
  {"P GES kw", P_GES, 3, 1000.0}
};

//Länge des dynamischen Array herausfinden
const unsigned elements_anzeigeelemente = sizeof(anzeigeelemente)/sizeof(struct dispwert);

[Nop (Gast)]

Könnte man nicht die Daten im ersten Array als Enums machen und dann 
immer als letztes Enum ein Größen-Enum anhängen?

[Frank M. (ukw) (Moderator)]

Draco schrieb:
> p.s. So in etwa meine ich das, das geht ja nun nicht:
>
>   static const uint8_t PROGMEM dev_desc[] =
>   {
>     0x09,0x21,
>     0x11,0x01,
>     0x00,0x01,
>     0x22,sizeof(rep_des)
>   };

Doch, geht - wenn man vom fehlenden "c" beim Ausdruck "sizeof(rep_des)" 
absieht:

$ cat s.c

#include <stdint.h>
#define PROGMEM

  static const uint8_t PROGMEM rep_desc[] =
  {
    0x05, 0x01,
    0x09, 0x05,
    0xa1, 0x01,
    0x05, 0x09,
    0x19, 0x01,
    0x29, 0x06,
    0x15, 0x00,
    0x25, 0x01,
    0x95, 0x06,
    0x75, 0x01,
    0x81, 0x02,
    0x95, 0x01,
    0x75, 0x02,
    0x81, 0x03,
    0xc0
  };


  static const uint8_t PROGMEM dev_desc[] =
  {
    0x09,0x21,
    0x11,0x01,
    0x00,0x01,
    0x22,sizeof(rep_desc)
  };

$ gcc -c s.c
$ (keine Meldung)

Dein Problem muss woanders stecken - jedenfalls nicht in dem hier 
beschriebenen Text.

[Dr. Sommer (Gast)]

Frank M. schrieb:
> Dein Problem muss woanders stecken - jedenfalls nicht in dem hier
> beschriebenen Text.

Kannst du das mal mit dem AVR GCC probieren? vermutlich muss der für 
PROGMEM alle Daten zur Kompile Zeit wissen...

[Clemens L. (c_l)]

Nimm den Präprozessor zur Hilfe:

#define REP_DESC { 0x05, 0x01, ..., 0xc0 }

static const uint8_t PROGMEM rep_desc[] = REP_DESC;

static const uint8_t PROGMEM dev_desc[] =
  {
    0x09,0x21,
    0x11,0x01,
    0x00,0x01,
    0x22, sizeof((const uint8_t[]) REP_DESC)
  };

[Draco (Gast)]

Danke für eure Mühe, es lag am Rückgabewert von sizeof... er gibt uint16 
zurück. So gehts dann nun:

#include <stdint.h>
#define PROGMEM

#define low(x)   ((x) & 0xFF)
#define high(x)  (((x)>>8) & 0xFF)

  static const uint8_t PROGMEM rep_desc[] =
  {
    0x05, 0x01,
    0x09, 0x05,
    0xa1, 0x01,
    0x05, 0x09,
    0x19, 0x01,
    0x29, 0x06,
    0x15, 0x00,
    0x25, 0x01,
    0x95, 0x06,
    0x75, 0x01,
    0x81, 0x02,
    0x95, 0x01,
    0x75, 0x02,
    0x81, 0x03,
    0xc0
  };


  static const uint8_t PROGMEM dev_desc[] =
  {
    0x09,0x21,
    0x11,0x01,
    0x00,0x01,
    0x22,
    high(sizeof(rep_desc)),low(sizeof(rep_desc))
  };

Warum auch immer er mir da nen "non const" error rausgeworfen hat, keine 
Ahnung.

Aber geht nun... vielen Dank euch :-D

[Frank M. (ukw) (Moderator)]

Dr. Sommer schrieb:
> Kannst du das mal mit dem AVR GCC probieren? vermutlich muss der für
> PROGMEM alle Daten zur Kompile Zeit wissen...

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

static const uint8_t PROGMEM rep_desc[] =
{
    0x05, 0x01,
    0x09, 0x05,
    0xa1, 0x01,
    0x05, 0x09,
    0x19, 0x01,
    0x29, 0x06,
    0x15, 0x00,
    0x25, 0x01,
    0x95, 0x06,
    0x75, 0x01,
    0x81, 0x02,
    0x95, 0x01,
    0x75, 0x02,
    0x81, 0x03,
    0xc0
};


static const uint8_t PROGMEM dev_desc[] =
{
    0x09,0x21,
    0x11,0x01,
    0x00,0x01,
    0x22,sizeof(rep_desc)
};

int
main ()
{
}

avr-gcc  -mmcu=atmega328p -Wall -gdwarf-2 -std=gnu99 -da -flto         -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d  -c  ../test.c
avr-gcc -mmcu=atmega328p -flto  -Os -Wl,-Map=test.map test.o     -o test.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  test.elf test.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex test.elf test.eep || exit 0
avr-objdump -h -S test.elf > test.lss

AVR Memory Usage
----------------
Device: atmega328p

Program:     138 bytes (0.4% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)

Geht also auch beim avr-gcc einwandfrei durch.

[Frank M. (ukw) (Moderator)]

Draco schrieb:
> high(sizeof(rep_desc)),low(sizeof(rep_desc))
>   };
>
> Warum auch immer er mir da nen "non const" error rausgeworfen hat, keine
> Ahnung.

Zeig mal die vollständige Fehlermeldung.

> Aber geht nun...

Geht bei mir auch mit avr-gcc ohne den high/low-Trick.

Außer Du hast tatsächlich mehr als 255 Elemente im Array, was Du uns 
dann aber verschwiegen hast :)

[Draco (Gast)]

Frank M. schrieb:
> Außer Du hast tatsächlich mehr als 255 Elemente im Array, was Du uns
> dann aber verschwiegen hast :)

Ja das hab ich, leider :-D

Ich dachte das wäre nicht von belangen, aber wie sagt man so schön "Man 
soll ja nicht denken"!

[Frank M. (ukw) (Moderator)]

Draco schrieb:
> Ja das hab ich, leider :-D
>
> Ich dachte das wäre nicht von belangen, aber wie sagt man so schön "Man
> soll ja nicht denken"!

Dann hat die Fehlermeldung aber garantiert nicht so gelautet, wie Du es 
beschrieben hast, sondern:

warning: large integer implicitly truncated to unsigned type [-Woverflow]

Das kommt nämlich bei mir, wenn ich mehr als 255 Elemente einfüge. Auch 
ist es kein Error, sondern lediglich eine (ernstzunehmende) Warnung.

[Draco (Gast)]

Das schmeißt er mir dabei raus:

c:\users\draconix\Documents\Atmel Studio\7.0\ThinJoyStick\ThinJoyStick\DracoUSB\DracoUSB.c(174,44): info: each undeclared identifier is reported only once for each function it appears in
c:\users\draconix\Documents\Atmel Studio\7.0\ThinJoyStick\ThinJoyStick\DracoUSB\DracoUSB.c(248,2): error: initializer element is not constant
      sizeof(rep_desc),
      ^
c:\users\draconix\Documents\Atmel Studio\7.0\ThinJoyStick\ThinJoyStick\DracoUSB\DracoUSB.c(248,2): error: (near initialization for 'conf_des[25]')
    make: *** [DracoUSB/DracoUSB.o] Error 1
    "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU=16000000 -DMCU=atmega32u4  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.106\include"  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=atmega32u4 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.0.106\gcc\dev\atmega32u4" -c -std=gnu99 -MD -MP -MF "DracoUSB/DracoUSB.d" -MT"DracoUSB/DracoUSB.d" -MT"DracoUSB/DracoUSB.o"   -o "DracoUSB/DracoUSB.o" "../DracoUSB/DracoUSB.c" 
c:\users\draconix\Documents\Atmel Studio\7.0\ThinJoyStick\ThinJoyStick\Debug\Makefile(87,1): error: recipe for target 'DracoUSB/DracoUSB.o' failed
    make: *** Waiting for unfinished jobs....

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

> 'conf_des[25]'

Wie hier schon geschrieben wurde, haste dich wohl vertippt.
Fehlermeldungen sind nicht zum überfliegen da, sondern zum analysieren!

[Frank M. (ukw) (Moderator)]

Hm, eine Erklärung habe ich dafür jedenfalls nicht.

Vielleicht nur bei Ansicht des tatsächlichen Sources... - aber egal. :-)

[Draco (Gast)]

Mw E. schrieb:
>> 'conf_des[25]'
>
> Wie hier schon geschrieben wurde, haste dich wohl vertippt.
> Fehlermeldungen sind nicht zum überfliegen da, sondern zum analysieren!

Nein halt, der Fehler war hier beim Aptippen. Im Sourcecode sind einige 
Variabel Namen ohne das "c" geschrieben. Die Konstante in dem diese 
Funktion aufgerufen wird, heißt tatsächlich bloß conf_des.


(Bei HID Descriptor unten steht die Zeile)

  static const uint8_t PROGMEM conf_des[] =  
  {
    0x09,        //bLength = 0x09, Groesse Deskriptor in Byte
    0x02,        //bDescriptorType = 0x02, Konstante Configuration = 2
    high(wTotalLength),low(wTotalLength),  //wTotalLength,
    0x01,        //bNumInterfaces = 1
    0x01,        //bConfigurationValue = 1
    0x00,        //iConfiguration = 0, Index fuer Str.-Deskr.(0=kein Txt)
    0x80,        //bmAttributes = 0x80, kein remote wakeup Bit 7=1
    250,         //MaxPower = 250(dezimal), in 2mA Schritten! (500mA)
    
    /*** Interface Descriptor ***/
    0x09,        //bLength = 0x09, Groesse Deskriptor in Byte
    0x04,        //bDescriptorType = 0x04, Konstante Interface = 4
    0x00,        //bInterfaceNumber = 0;
    0x00,        //bAlternateSetting = 0;
    Nr_eps,      //bNumEndpoints = USB_Endpoints;
    0x03,        //bInterfaceClass = 0x03 HID, Klassencode:
    0x00,        //bInterfaceSubClass = 0x00, Unterklassencode
    0x00,        //bInterfaceProtocol = 0x00, Protokollcode
    0x00,        //iInterface = 0, Index fuer String-Deskr. Interf.
    
    /*** HID Descriptor ***/
    0x09,        //bLength = 0x09, Groesse Deskriptor in Byte
    0x21,        //bDescriptorType = 0x21 (HID-Klasse)
    0x11,0x01,   //bcdHID = 0x0110, HID_Spec 1.1
    0x00,        //bCountryCode = 0 (wird hier nicht unterstuetzt)
    0x01,        //bNumDescriptors = 1
    0x22,        //bDescriptorType = 0x22,
    //sizeof(rep_desc),   
    low(sizeof(rep_desc)),high(sizeof(rep_desc)),
    
  /*** EP1 Descriptor ***/
    0x07,    //bLength = 0x07, Groesse Deskriptor in Byte
    0x05,    //bDescriptorType = 0x05, Konstante Endpoint = 5
    0x81,    //bEndpointAddress = 0x81, Bit 7 = 1 (IN) Bit 0-3 EP-Nummer
    0x03,    //bmAttributes = Interrupt
    Ep1_fs_l,Ep1_fs_h,    //wMaxPacketSize = EP1_FIFO_Size;
    0xFF,    //bInterval = 1 bei Interrupt: Latenzzeit in Millisekunden
    
  /*** EP2 Descriptor ***/
    0x07,    //bLength = 0x07, Groesse Deskriptor in Byte
    0x05,    //bDescriptorType = 0x05, Konstante Endpoint = 5
    0x02,    //bEndpointAddress = 0x82, Bit 7 = 1 (IN) Bit 0-3 EP-Nummer
    0x03,    //bmAttributes = Interrupt
    Ep2_fs_l,Ep2_fs_h,    //wMaxPacketSize = EP2_FIFO_Size;
    0xFF     //bInterval = 1 bei Interrupt: Latenzzeit in Millisekunden
  };

[Falk B. (falk)]

@  Draco (Gast)

>Nein halt, der Fehler war hier beim Aptippen.

FAIL! Das tut man nicht! NIEMALS!

https://www.mikrocontroller.net/articles/Netiquette#.C3.84u.C3.9Fere_Form

"Quelltext nie abtippen, sonder immer das direkt kopierte Original 
posten, anderenfalls schleichen sich neue Fehler ein oder die 
existierenden werden nicht abgeschrieben."

[Huh (Gast)]

Draco schrieb:
> Nein halt, der Fehler war hier beim Aptippen.

Genau aus diesem Grunde wurde schon unzählige Male gesagt: Code nicht 
abtippen, sondern reinkopieren! Du bist der beste Beweis dafür, daß 
diese Mahnung völlig berechtigt ist! :-)