I have a project, which does not work using the Mbed os 5 offline compiler with GCC tools on Mac using a regular filesystem. When I use an externe case sensitive disk it works.
There is something wrong in the compiler setup, I have a file PinMap.h in my project, this gets mixed up with the pinmap.h within Mbed OS. The problem does not exits on mbed-os 2
Any help will be appreciated.
Regards Helmut
PS: I like to use my regular system disk for mbed os and I prefer to keep my PinMap.h file because I use this as well on Arduino and other platforms.
Am I right in thinking that when running the normal macOS files system (case insensitive) that this results in a name clash between PinMap.h and pinmap.h in the HAL?
If so, I’m afraid that this is a known issue in Mbed OS 5, we are working on fixing this in future versions of Mbed OS.
I realise this is not something you would like to do, but my only suggestion is that you rename the PinMap.h file.
Hi Graham thanks for the advise, yes I will rename it to xPinMap.h or so.
I just figured out yesterday, the same problem exists on Windows. (I work on Mac)
Do you have any idea in which area the problem in the mbed-os tools is?
I checked already the compiler response files, etc. no luck so far.
regards, Helmut
I renamed the PinMap.h to xPinMap.h, unfortunately no change.
On a case sensitive file system it works, with mbed-os 2 it worked, with mbed-os 5 it fails:
Compile [ 69.7%]: PeripheralPins.c
[Error] PeripheralPins.h@39,14: unknown type name ‘PinMap’
[Error] PeripheralPins.h@40,14: unknown type name ‘PinMap’
At present I have no idea where the problem is, I was expecting my local PinMap.h file, but it looks it is a different problem. I have no idea so far.
I would expect this to work now, it looks like the struct PinMap is not being defined. This is defined inside Mbed OS hal/pinmap.h. This file uses the header guards MBED_PINMAP_H so there is unlikely to be a conflict.
I’ve taken a look at your code. It’s bit complex, and some things are not clear:
most of your .h are missing header guards. It’s good practice to always use one for each .h. I don’t know if it will solves things here, but at least we’ll know it’s not that.
your Utils are importing main.h which is strange.
you are also importing code from examples in your libs, which feels also strange
it looks like a lot of crossed reference and imports might cause the issue
Was the code working at one point? What change did break it?
I’d start with a simplier example to make sure the issue is really with PinMap and not with something else that confuses the compiler and makes it look like PinMap is the issue.
When first compiling, the error the same as you:
Compile [ 52.6%]: PeripheralPins.c
[Error] PeripheralPins.h@39,14: unknown type name 'PinMap'
yes I will adding missing header guards, no questions
I include main.h in several libraries to make dprintf() and dump()
debug functions available
The print functions work/switch automatically over UART or
USBSerialBuffered communications.
Yes in the libs I don’t need main.h unless I use debug printing.
I imported the USB Code and renamed it with xUSBSerial etc.
This is temporary because mbed-os for my target STM32L4 does not
support USB, I did the
work to get USB working. I am planning to merge this into mbed-os 5
Another point is that I did a USBSerialBuffered class which allows
usb.printf() on interrupt
level (gets collected and async sent) to have an easier console via
USB only.
I will check the crossed references and will reduce it to isolate the
problem.
The code was working for mbed-os 2 for years, the code (RadioShuttle &
LoRa Libraries) is working
as well on Arduino ESP32 and Arduino D21
When migrating from mbed-os 2 to mbed-os 5 the compile problem occurred,
using a case sensitive file system it is working.
I have not switched to mbed-os 5 because it needed so much more flash
and sram. Now with the
mbed-os 5 bare-metal option the resources usage by mbed-os 5 is fine and
I am in a progress of switching to mbed-os 5.
FYI: I found a problem, even after renaming all active PinMap.h files to
xPinMap it still failed. mbed-os compile sets up the include search path
to every thing folder, even some Arduino examples in the same library
which still had a PinMap.h there.
I was searching the include path order and putting #error “xxx” lines
into the different .h files until I found it.
Somehow this is an mbed-os problem where a OS .h file uses an identical
.h filename in a user library or app folder.
PS: independent of this I cleanup up several .h files with include
guards and avoid to include main.h when not needed.
I found a workaround of the problem. Renaming all PinMap.h files to xPinMap.h is a workaround.
mbed-os compile searches its .h files in every single folder of the app and its libraries. A duplicate .h filename (e.g. pinmap.h and PinMap.h) breaks mbed-os 5 on case insensitive file systems (e.g. Windows and Mac).
