[libopencm3-devel] strange compilation error for cdcacm.c with using C++

[kristoff]

Hi,


I use libopencm3 on STM32F103 maple-mini clones.


Some time ago, I tried the usb_cdcacm examples (see link (1) below) for
serial-over-USB on these devices, which compiles and works nicely.
All very fine.



Now, I would like to use this and combine it with an application that
reads and dumps the data on a a mifare rfid-tag using a nfrc522
rfid-reader. This is a port of the arduino mfrc522 C++ library to
opencm3. (see link 2 below)
The current version of my application uses the serial UART-port on the
STM32F103 which works great, but I like to use the serial-over-USB
interface.



As my mnf522-application is writen in C++, I need to compile the
"serial-over-usb" code in cdcacm.c (see link 3 below) using C++ instead
of gcc.

But I get this error:
--- cut here --- cut here --- cut here --- cut here ---
USBserial.h:142:2: error: elements of array 'const usb_interface ifaces
[]' have incomplete type
}};
^
USBserial.h:142:2: error: storage size of 'ifaces' isn't known
--- cut here --- cut here --- cut here --- cut here ---




This relates to this piece of code:

static const struct usb_interface ifaces[] = {{
.num_altsetting = 1,
.altsetting = comm_iface,
}, {
.num_altsetting = 1,
.altsetting = data_iface,
}};


(see lines 145 of
https://github.com/libopencm3/libopencm3-examples/blob/master/examples/stm32/f1/stm32-h103/usb_cdcacm/cdcacm.c
and above).


These structures are defined in "libopencm3/usb/usbstd.h" here:
/* USB Standard Configuration Descriptor - Table 9-10 */
struct usb_config_descriptor {
uint8_t bLength;
(...)
/* Descriptor ends here. The following are used internally: */
const struct usb_interface {
uint8_t *cur_altsetting;
uint8_t num_altsetting;
const struct usb_iface_assoc_descriptor *iface_assoc;
const struct usb_interface_descriptor *altsetting;
} *interface;
(...)



Development is done on an ubuntu 16.04 LTS. gcc is arm-none-eabi-gcc /
gcc version 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision
218278] (GNU Tools for ARM Embedded Processors)

The source of this version of gcc is "gcc4mbed"

So, my impression is that there are some differences in how gcc compiles
this as C then as C++.




Did anybody have simular issues?
What version of arm-none-eabi-gcc are you all now using (on ubuntu)?




Cheerio! Kr. Bonne.





(1)
https://github.com/libopencm3/libopencm3-examples/tree/master/examples/stm32/f1/stm32-h103/usb_cdcacm

(2) https://github.com/miguelbalboa/rfid

(3)
https://github.com/libopencm3/libopencm3-examples/blob/master/examples/stm32/f1/stm32-h103/usb_cdcacm/cdcacm.c

[Matthew Lai]

Hi Kristoff,

That syntax is called designated initializers, and is only legal in C.
It's one of the few things that are legal in C (C99) and not C++.

I would recommend compiling the file as C, and the rest of your
application as C++. Though you'd want to make sure that the header has
conditional compilation for C++ that adds 'extern "C" {...}' to avoid
name mangling.

Matthew

Post by kristoff
Hi,
I use libopencm3 on STM32F103 maple-mini clones.
Some time ago, I tried the usb_cdcacm examples (see link (1) below) for
serial-over-USB on these devices, which compiles and works nicely.
All very fine.
Now, I would like to use this and combine it with an application that
reads and dumps the data on a a mifare rfid-tag using a nfrc522
rfid-reader. This is a port of the arduino mfrc522 C++ library to
opencm3. (see link 2 below)
The current version of my application uses the serial UART-port on the
STM32F103 which works great, but I like to use the serial-over-USB
interface.
As my mnf522-application is writen in C++, I need to compile the
"serial-over-usb" code in cdcacm.c (see link 3 below) using C++ instead
of gcc.
--- cut here --- cut here --- cut here --- cut here ---
USBserial.h:142:2: error: elements of array 'const usb_interface ifaces
[]' have incomplete type
}};
^
USBserial.h:142:2: error: storage size of 'ifaces' isn't known
--- cut here --- cut here --- cut here --- cut here ---
static const struct usb_interface ifaces[] = {{
.num_altsetting = 1,
.altsetting = comm_iface,
}, {
.num_altsetting = 1,
.altsetting = data_iface,
}};
(see lines 145 of
https://github.com/libopencm3/libopencm3-examples/blob/master/examples/stm32/f1/stm32-h103/usb_cdcacm/cdcacm.c
and above).
/* USB Standard Configuration Descriptor - Table 9-10 */
struct usb_config_descriptor {
uint8_t bLength;
(...)
/* Descriptor ends here. The following are used internally: */
const struct usb_interface {
uint8_t *cur_altsetting;
uint8_t num_altsetting;
const struct usb_iface_assoc_descriptor *iface_assoc;
const struct usb_interface_descriptor *altsetting;
} *interface;
(...)
Development is done on an ubuntu 16.04 LTS. gcc is arm-none-eabi-gcc /
gcc version 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision
218278] (GNU Tools for ARM Embedded Processors)
The source of this version of gcc is "gcc4mbed"
So, my impression is that there are some differences in how gcc compiles
this as C then as C++.
Did anybody have simular issues?
What version of arm-none-eabi-gcc are you all now using (on ubuntu)?
Cheerio! Kr. Bonne.
(1)
https://github.com/libopencm3/libopencm3-examples/tree/master/examples/stm32/f1/stm32-h103/usb_cdcacm
(2) https://github.com/miguelbalboa/rfid
(3)
https://github.com/libopencm3/libopencm3-examples/blob/master/examples/stm32/f1/stm32-h103/usb_cdcacm/cdcacm.c
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
libopencm3-devel mailing list
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel

[kristoff]

Hi Matthew,

Post by Matthew Lai
Hi Kristoff,
That syntax is called designated initializers, and is only legal in C.
It's one of the few things that are legal in C (C99) and not C++.
I would recommend compiling the file as C, and the rest of your
application as C++. Though you'd want to make sure that the header has
conditional compilation for C++ that adds 'extern "C" {...}' to avoid
name mangling.

After a good night sleep, I also came to the same conclussion.

Thanks! :-)


I never had to mix C and C++ before so I'm still strugling a bit but I'm
getting there.



Now, on a more general note, I do would like to make the case to make
sure libopencm3 is (re)writen in a C++ compatible format.

After all, concidering the popularity of the arduino platform, there is
a lot of code for arduino for all kinds of devices. As said, the mfrc32
library I use is a port of a arduino C++ class to libopencm3.

it is not that difficult to simply "translate" the gpio, SPI or UART
calls from wiring into their libopencm3 equivalents, but if you need to
start writing "wrapper"-code to go from C++ to C -as for cdcacm- it does
make things (unnecessairy) complex.


After all, we are all to gain from having an as-smooth-as-possible path
to translate the (much larger) collection of arduino driver so we can
use them on libopencm3.

Post by Matthew Lai
Matthew

Cheerio! Kr. Bonne.

[Karl Palsson]

Post by kristoff
Hi Matthew,

Post by Matthew Lai
Hi Kristoff,
That syntax is called designated initializers, and is only legal in C.
It's one of the few things that are legal in C (C99) and not C++.
I would recommend compiling the file as C, and the rest of your
application as C++. Though you'd want to make sure that the header has
conditional compilation for C++ that adds 'extern "C" {...}' to avoid
name mangling.

After a good night sleep, I also came to the same conclussion.
Thanks! :-)
I never had to mix C and C++ before so I'm still strugling a
bit but I'm getting there.
Now, on a more general note, I do would like to make the case
to make sure libopencm3 is (re)writen in a C++ compatible
format.

In general I'm all for it, but designated initializers are bloody
awesome and C++ is lame for not having them. You'll run into it
in all the rcc clocks as well I'm afraid.

[kristoff]

Hi Karl,

Post by Karl Palsson

Post by kristoff
Now, on a more general note, I do would like to make the case
to make sure libopencm3 is (re)writen in a C++ compatible
format.

In general I'm all for it, but designated initializers are bloody
awesome and C++ is lame for not having them. You'll run into it
in all the rcc clocks as well I'm afraid.

I don't know designated initializers but I must say I agree with you.
They look very usefull.

The problem is that gcc does not have our "geeky" mind and simply says
"it's not in the standard, so ... bzzzz!".

Sayly enough, when you are trying to port an arduino library and some
example-code of a device you actually want to use, that's the only thing
that counts. :-(



Cheerio! Kr. Bonne.