My previous commit, c6d2c81, broke Keil builds and maybe even IAR.
I need to learn how to read C code :) I thought I was masking off the
O_BINARY bit only for GCC builds but it turns out that my update was
in the fall-through case for all toolchains. This commit now places
the O_BINARY masking operation into a GCC specific #ifdef clause.
Testing:
I tested the same fopen("/local/out.txt","rb") code as before but this
time I built it with the online compiler and GCC_ARM. I tested the
resulting binaries on mbed-LPC11U24 and mbed-LPC1768 boards.
Thanks to @neilt6 for catching & reporting this!
Adding additional 'defined' statements to line 62 of parse_pins.cpp should in theory enable the rpc libraries for all other Nucleo boards, since all stm32 parts use the same pin labeling scheme i.e. P(port)_pinNumber e.g. PA_3,
PC_15 e.t.c.
Fixes issue #1562 reported by @justbuchanan.
When building code with GCC-ARM / newlib, attempting to use the
b (binary) mode in a fopen() call would fail. newlib would parse
this option and pass it down to the LocalFileSystem open call which
didn't like the unexpected O_BINARY flag in openmode.
The openmode_to_posix() function in retarget.cpp would never set the
O_BINARY flag for the other toolchains but for GCC it would just pass
down whatever newlib placed there. This commit masks out the O_BINARY
bit so that it never gets passed down to the file system drivers, just
as occurs for the other supported toolchains.
Test case:
FILE *fp = fopen("/local/out.txt", "rb");
I tested that code on mbed LPC1768 and LPC11U24 boards while using
GCC_ARM as the toolchain. It failed on both platforms previous to
this change and succeeded there after.
mbed scripts copy files, therefore file paths are not valid at the moment of ahe project generation.
Therefore checks like os.path.isdir or isfile fail. If include is set to TARGET/FOLDER, this would be
treated as a file, and added to the project workspace. This commit fixes it, it adds dirs only to
include_paths, as it should.
When two or more analogue inputs are initialized on more than one ADC HW block the initialisation fails with:
Cannot initialize ADC
The reason is the reusage of just one ADC_HandleTypeDef for all initializations (in mbed\targets\hal\TARGET_STM\TARGET_STM32F3\analogin_api.c). After the first (successful) ADC initialisation AdcHandle.State is set to HAL_ADC_STATE_READY).
But for another ADC block initialisation the AdcHandle.State has to be reset so that the HAL initialize it (in mbed\targets\cmsis\TARGET_STM\TARGET_STM32F3\stm32f3xx_hal_adc_ex.c line 424). When this state is not reset the HAL returns with an initialization error. And this error induces the above mbed error message.
The error message can be reproduced just with AnalogIn in1(xx); AnalogIn in2(yy); where xx and yy belongs to two different ADC blocks.
Martin Kojtal
dbestm
Adam Green
Brian Daniels
bcostm
tomoyuki yamanaka
neilt6
adustm
Toyomasa Watarai
Peter Conheeney
ohagendorf