Error: cannot open source input file "mbed.h"

[bco stm]

Hi,

 

I have this message while running the make.py on my target:

>>> BUILD PROJECT: BASIC (NUCLEO_F103RB, ARM)
Compile: main.cpp
C:/Keil/ARM/ARMCC\bin\armcc -c --cpu=Cortex-M3 --gnu -Ospace --split_sections --apcs=interwork --brief_diagnostics --restrict --md --no_depend_system_
headers -IC:/Program Files/ARM/armcc_4.1_791\include --cpp --no_rtti -DTARGET_NUCLEO_F103RB -DTARGET_M3 -DTARGET_STM -DTARGET_STM32F10X -DTARGET_STM32
F103RB -DTOOLCHAIN_ARM_STD -DTOOLCHAIN_ARM -D__CORTEX_M3 -DARM_MATH_CM3 -IC:\GitHub\mbed\libraries\tests\mbed\basic -IC:\GitHub\mbed\libraries\tests\m
bed\basic -IC:\GitHub\mbed\libraries\tests\mbed\env -o C:\GitHub\mbed\build\test\NUCLEO_F103RB\ARM\MBED_A1\.\main.o C:\GitHub\mbed\libraries\tests\mbe
d\basic\main.cpp

[Error] test_env.h@5:  #5: cannot open source input file "mbed.h": No such file or directory

[ERROR] "C:\GitHub\mbed\libraries\tests\mbed\env\test_env.h", line 5: Error:  #5: cannot open source input file "mbed.h": No such file or directory

C:\GitHub\mbed\libraries\tests\mbed\basic\main.cpp: 0 warnings, 1 error

The mbed.h file is inside the "mbed\libraries\mbed\api" folder. But it seems this path is not included. Do you know why ?

 

Thanks.

Bruno

[Bogdan Marinescu]

Hi,

Try to build the SDK first:

workspace_tools/build.py -t ARM -m ...

--
You received this message because you are subscribed to the Google Groups "mbed-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mbed-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[bcostm]

OK. I have tried the build and now I have another file not found:

 

[Error] stm32f10x.h@8297:  #5: cannot open source input file "stm32f10x_conf.h": No such file or directory

 

This file is inside the "mbed\libraries\mbed\targets\hal\TARGET_STM\DRIVERS\STM32F10X_standard_peripherals_driver" folder.

 

How can I add this folder path ?

[Bogdan Marinescu]

You need to have the proper labels, but your code shouldn't be directly under TARGET_STM, but rather under TARGET_STM/TARGET_STMF1xx (or something similar) to keep the code properly structured. Take a look at the STM32F4XX target, you should mirror that structure.

Best,

Bogdan

[bcostm]

 

I understand your point and all the standard mbed files (device.h, pin_names.h, etc...) are in the correct place. But concerning the "standard peripherals drivers" files we don't want to duplicate them into each target. There are too many files and it will be too difficult to maintain if we do this way. This is why we would like to place them inside a TARGET_STM/DRIVERS folder for example. Each target must "point" into it. Is it possible ?

 

On Wednesday, 13 November 2013 15:22:13 UTC+1, Bogdan Marinescu wrote:

You need to have the proper labels, but your code shouldn't be directly under TARGET_STM, but rather under TARGET_STM/TARGET_STMF1xx (or something similar) to keep the code properly structured. Take a look at the STM32F4XX target, you should mirror that structure.

Best,

Bogdan

On Wed, Nov 13, 2013 at 3:58 PM, bcostm <bco...@gmail.com> wrote:

OK. I have tried the build and now I have another file not found:

 

[Error] stm32...@8297:  #5: cannot open source input file "stm32f10x_conf.h": No such file or directory

[Bogdan Marinescu]

It's perfectly possible, yes, and it should already work with your current directory setup. Could you please let me know how your target is defined in targets.py?

[bcostm]

I have only did this:

 

class NUCLEO_F103RB(Target):
    def __init__(self):
        Target.__init__(self)
       
        self.core = "Cortex-M3"
       
        self.extra_labels = ['STM', 'STM32F10X', 'STM32F103RB']
       
        self.supported_toolchains = ["ARM", "GCC_ARM"]

[Martin Kojtal]

Each target's HAL contains separate implementations, not dependent on any drivers. This leads to a question I wanted to ask : can be peripheral drivers included in the HAL and reused their implementations in the target's HAL? There's not yet any target which pulls peripheral drivers, I marvel why.

Regards,
0xc0170

[Bogdan Marinescu]

That happens because one file in cmsis (mbed/targets/cmsis/TARGET_STM/TARGET_STM32F10X/stm32f10x.h) include a file from the peripheral drivers (mbed/targets/hal/TARGET_STM/TARGET_STM32F10X). That's currently not supported, because of the logical separation between cmsis and hal. In your particular case, it seems that the best solution would be to comment out these lines in stm32f10x.h:

//#ifdef USE_STDPERIPH_DRIVER

//  #include "stm32f10x_conf.h"

//#endif

Best,

Bogdan

[Bogdan Marinescu]

HI Martin,

On Wed, Nov 13, 2013 at 5:13 PM, Martin Kojtal <koj...@gmail.com> wrote:

Each target's HAL contains separate implementations, not dependent on any drivers. This leads to a question I wanted to ask : can be peripheral drivers included in the HAL and reused their implementations in the target's HAL? There's not yet any target which pulls peripheral drivers, I marvel why.

Generally, mbed's peripheral drivers are written especially for mbed, which makes them smaller than the generic peripheral driver provided by the manufacturer. That said, it is possible to share code between two targets, check for example here:

https://github.com/mbedmicro/mbed/tree/master/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC81X

You could also use peripheral drivers if you want, provided the license is compatible with mbed.

Best,

Bogdan

Regards,
0xc0170

[bcostm]

 

I have found a temporary solution: I have put all the "standard peripherals driver" files in the folder "mbed\targets\cmsis\TARGET_STM\TARGET_NUCLEO_F103RB".

 

The build terminated with success with this.

 

Bruno

[Martin Kojtal]

Generally, mbed's peripheral drivers are written especially for mbed, which makes them smaller than the generic peripheral driver provided by the manufacturer. That said, it is possible to share code between two targets, check for example here:

https://github.com/mbedmicro/mbed/tree/master/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC81X

You could also use peripheral drivers if you want, provided the license is compatible with mbed.

Best,

Bogdan

 
My question was targeted at peripheral drivers made by manufacturers. Will you/we allow to bring those libraries to mbed HAL ? Complete package or just a subset needed for HAL implementation?

I am inclined to keep HAL implementation pure and simple, those drivers should be accessible as libraries online on mbed for users to use complete set of target's features.
If anybody got any comments, we can discuss this in the separate topic.

Regards,
0xc0170

[Bogdan Marinescu]

On Wed, Nov 13, 2013 at 7:38 PM, Martin Kojtal <koj...@gmail.com> wrote:

Generally, mbed's peripheral drivers are written especially for mbed, which makes them smaller than the generic peripheral driver provided by the manufacturer. That said, it is possible to share code between two targets, check for example here:

https://github.com/mbedmicro/mbed/tree/master/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC81X

You could also use peripheral drivers if you want, provided the license is compatible with mbed.

Best,

Bogdan

 
My question was targeted at peripheral drivers made by manufacturers. Will you/we allow to bring those libraries to mbed HAL ? Complete package or just a subset needed for HAL implementation?

But that's what I said, perharps not too clear: sure you can use that code for the mbed HAL implementation, as long as it it compatible with the mbed license.

Best,

Bogdan

I am inclined to keep HAL implementation pure and simple, those drivers should be accessible as libraries online on mbed for users to use complete set of target's features.
If anybody got any comments, we can discuss this in the separate topic.

Regards,
0xc0170

--