Help with compiler errors

[Brother Theo]

I am trying to compile a portion of code from a project I found on github. I made a new project with MXCube and am compiling with the Ac6/Eclipse environment. I am getting the following compiler error:

In file included from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Inc/main.h:49:0,

                from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Inc/stm32f4xx_hal_conf.h:43,

                from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal.h:48,

                from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f4xx.h:245,

                from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Inc/usbh_conf.h:55,

                from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Middlewares/ST/STM32_USB_Host_Library/Core/Inc/usbh_core.h:37,

                from C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Inc/MIDI_application.h:14,

                from ../Src/MIDI_application.c:12:

C:/CircuitAbbey/Development/Synth/Eurorack Modules/UsbMidi/UsbMidi Code/UsbMidiP1/Inc/usbh_MIDI.h:58:8: error: unknown type name 'USBH_ClassTypeDef'

 extern USBH_ClassTypeDef MIDI_Class;

       ^~~~~~~~~~~~~~~~~

What I don't get is the file usbh_MIDI.h does not appear in that long include chain. Also the file usbh_MIDI.h has the correct include to get to the definition of USBH_ClassTypeDef. How should on ebe reading that error message?

[Tesla DeLorean]

Do a find-in-files on "USBH_ClassTypeDef" determine where it is defined.

Make sure the include file involved is pulled in, and the include paths are specified in the project.

Check your project's stm32f4xx_hal_conf.h and make sure USB modules have been enabled.

[waclawek.jan]

It says, "I was about to translate line 8 of usbh_MIDI.h, which mentions USBH_ClassTypeDef, but I didn't stumble upon definition of USBH_ClassTypeDef before this line so I don't know how to handle that. And, I was translating usbh_MIDI.h because I was translating main.h and stumbled upon #include "usbh_MIDI.h" at line 49. And I was translating main.h, because I was translating stm32f4xx_hal_conf.h and stumbled upon #include main.h on line 43. Etc...

In other words, the definition of said USBH_ClassTypeDef is supposed to occur (directly, or indirectly through inclusion of file containing that definition) anywhere in any of those files mentioned at a line before those mentioned.

Best practice is, that all file is "self-resolving", i.e. that all symbols mentioned in a file are defined (again directly or indirectly) in that very same file, i.e. that all files are compilable in itself, or, in other words, that the definition of a symbol in a file does not rely on that file being included in other file (which already contains that definition); however, Cube is not exactly known for rigorously following best practices.

JW

[Brother Theo]

I looked up the build log which it turns out gives a clearer picture of the compile process. It is trying to compile a file called Midi_Application.c, whose .h file includes the .h chain that leads tot he definition It is sez it cannot find. I am confused.

[Brother Theo]

Drilled down some more. usbh_def.h includes usbh_conf.h which has the definition for USBH_MAX_NUM_ENDPOINTS. Further down in usbh_def.h it does this line:

#define USBH_CONFIGURATION_DESCRIPTOR_SIZE (USB_CONFIGURATION_DESC_SIZE \

                                          + USB_INTERFACE_DESC_SIZE\

                                          + (USBH_MAX_NUM_ENDPOINTS * USB_ENDPOINT_DESC_SIZE))

Using USBH_MAX_NUM_ENDPOINTS no problem. But further down it tries the line:

typedef struct _InterfaceDescriptor

{

 uint8_t bLength;

 uint8_t bDescriptorType;

 uint8_t bInterfaceNumber;

 uint8_t bAlternateSetting;   /* Value used to select alternative setting */

 uint8_t bNumEndpoints;       /* Number of Endpoints used for this interface */

 uint8_t bInterfaceClass;     /* Class Code (Assigned by USB Org) */

 uint8_t bInterfaceSubClass;  /* Subclass Code (Assigned by USB Org) */

 uint8_t bInterfaceProtocol;  /* Protocol Code */

 uint8_t iInterface;          /* Index of String Descriptor Describing this interface */

 USBH_EpDescTypeDef              Ep_Desc[USBH_MAX_NUM_ENDPOINTS];  

}

USBH_InterfaceDescTypeDef;

And errors out on USBH_MAX_NUM_ENDPOINTS, claiming it is undeclared.

Thoughts ?

[Brother Theo]

I think I see what is going on. It is a path issue. The build is trying to include a header file from the middleware STM32_USB_Host_Library and cannot find it. I suspect my "makefile" if you will, is broken.

[waclawek.jan]

> usbh_def.h includes usbh_conf.h which has the definition for USBH_MAX_NUM_ENDPOINTS

> [...]

> But further down it tries the line:

> typedef struct _InterfaceDescriptor

> [...]

> USBH_EpDescTypeDef              Ep_Desc[USBH_MAX_NUM_ENDPOINTS]; 

> }

> USBH_InterfaceDescTypeDef;

> [...]

> And errors out on USBH_MAX_NUM_ENDPOINTS, claiming it is undeclared.

>

> Thoughts ?

1. Try to concentrate on one issue. It's hard to shoot a moving target.
2. You are lying in one of the statements above; if the compiler claims USBH_MAX_NUM_ENDPOINTS is undeclared then it means there was no such symbol encountered so far, so it's either not mentioned in said usbh_conf.h, or usbh_conf.h is not #included before the offending typedef. That #define USBH_CONFIGURATION_DESCRIPTOR_SIZE does not throw any error is normal - the preprocessor directives are not parsed for C statements; they are simply stored and resolved only at the place where they are used.
3. If the preprocessor would not find a #included header, it would say so.

You can run the compiler with switches modifying its behaviour so it runs only the preprocessor. For gcc, https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html - -E outputs the complete preprocessed source; using one of the -dxxx options outputs various information intended for easier debugging. Often, this helps less than a sheet of paper onto which one writes down the translation tree (which includes portions of files *before* the offending statement/#include, and #includes therein) and tries to locate the offending symbols "manually".

I can't and don't want to comment on particularities related to Cube/CubeMX nor the eclipsoids.

[Brother Theo]

Thanks for the idea! Pre-processor output might be useful.

I am using Eclipse/AC6 platform. How do I give it the -E option?