The mbed time build stamp is with decimal point, which is causing ASM to fail,
with strange command error. As a workaround, we truncate the number when exporting
to uvision.
targets.py : add IAR for NUCLEO_F746ZG and DISCO_F746NG
iar.py: in case of Cortex-M7F, change it into Cortex-M7 and add --fpu
VFPv5_sp
I have been confirmed that for Cortex-M4F we don't need to add the --fpu
VFPv4_sp
UART_IT_TC was enabled instead of UART_IT_TXE
This was causing an issue because UART_IT_TXE (and not UART_IT_TC) was disabled by same function.
Consequently if a transfer was ongoing when serial_irq_set() was called to disable IRQ, UART_IT_TC would still trigger (once).
Side effect is maybe speed: I guess using UART_IT_TC prevented implementation of continuous transfer.
This commit is focused on solving an issue observed with TARGET_STM32F4. It doesn't presume it should or shouldn't be done for other targets.
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.