Now BusIn can also use PullUp, etc, instead of only BusInOut.
If the pin is NC, it does get to the init, but all write/mode functions
are disabled. This is how it used to be in the old gpio version. Quite
some libraries allow users to make pins NC, and they are all locking up
with the current mbed version. This is far from a perfect solution, but
more a temporary fix.
Made error(...) a weak function so that it can be overridden in
production projects. Also fixed several serial_api.c files that required
stdlib.h, but were getting it from error.h.
Removed SystemInit write to FWID.
Added DEVICE_ERROR_PATTERN for error signaling.
Exception for NRF added to board.c to keep irqs enabled since timer irq
is needed for the wait function.
Button pin names changed from BUTTON0 to BUTTON1 and from BUTTON1 to
BUTTON2.
Unused header files are removed from the cmsis dir.
Tab characters replaced by 4 spaces.
Brackets and parenthesis formatted.
Spi slave functions updated for faster response.
Currently implemented only for LPC1768. On this platform, when hardware
flow control is not directly supported, it will be emulated.
Also added "not_implemented.c" as a placeholder for various HAL functions
that might not be implemented on all platforms (in this particular case,
serial_set_flow_control). These are weak implementations that default to a
"not implemented" error message.
The new RawSerial class is a simple wrapper over the serial HAL that can
be safely used from an interrupt handler.
Interrupt chaining code was removed from InterruptIn, Serial and Ticker
because it caused lots of issues with the RTOS. Interrupt chaining is
still possible using the InterruptManager class.
A recent commit, 43acaa4166, to get _sbrk() to build successfully for
LPC2368 broke the Cortex-M implementation. __get_MSP() isn't ever
defined as a macro, it is an inline function. This means that the
code would always be compiled to use SP instead of MSP on Cortex-M
parts. I switched the code to instead use the TARGET_ARM7 define
to choose which stack pointer to utilize.
I tested this fix by making sure that the LPC2368 version of the mbed
SDK would still build successfully with the Python scripts and that the
NET1 test still built and ran successfully on my mbed-LPC1768 device.
If the FileBase::lookup operation in the constructor of FilePath returns
NULL, subsequent operations (such as isFile()/isFileSystem()) will call
methods on a NULL 'fb' pointer. This commit fixes this issue by adding
explicit NULL checks and a new method in FilePath (exists()).
I verified that the hang issue I was seeing when building and running
the mbed official networking tests with GCC_ARM was related to this
issue reported on the mbed forums:
http://mbed.org/forum/mbed/topic/3803/?page=1#comment-18934
If you are using the 4.7 2013q1 update of GCC_ARM or newer then it
will have a _sbrk() implementation which checks the new top of heap
pointer against the current thread SP, stack pointer.
See this GCC_ARM related thread for more information:
https://answers.launchpad.net/gcc-arm-embedded/+question/218972
When using RTX RTOS threads, the thread's stack pointer can easily
point to an address which is below the current top of heap so this
check will incorrectly fail the allocation.
I have added a _sbrk() implementation to the mbed SDK which checks the
heap pointer against the MSP instead of the current thread SP. I have
only enabled this for TOOLCHAIN_GCC_ARM as this is the only GCC based
toolchain that I am sure requires this.
These were done to silence GCC warnings and fix potential bugs where
they would never be equal when the enumeration wasn't a 32-bit type.
For example, common/pinmap_common.c used to contain this code:
if (pin == (uint32_t)NC)
I switched it to:
if (pin == (PinName)NC)
I wonder why this casting to uint32_t was done in the first place?
Maybe another supported compiler requires it?
- rename stdio.cpp to retarget.cpp, since it doesn't contain only stdio-related
code
- move __cxa_pure_virtual from exit.c to retarget.cpp where it belongs.
Now the I2C send/receive functions in the mbed HAL return the number of
bytes actually transferred or an error code (a negative value). The
public API remains unchanged.
Martin Kojtal
Bogdan Marinescu
Bogdan Marinescu
Rohit Grover
sg-
Sissors
neilt6
tkuyucu
mazgch
Emilio Monti
Joris Aerts
Adam Green
dinau
Matthew Else
Joe Turner