* Implements CellularInterface
* Reference design for CellularInterface implementations
* Uses an external mbed-os IP stack and talks to modem over PPP.
This provides a HAL layer for Modem bearing devices.
Provides a standard interface to upper layer drivers.
Platform providers will be implementing this API under their
specific targets.
As a reference, two implementations are provided under TARGET_C027 (UBLOX)
and TARGET_MTS_DRAGONFLY_F411RE (MultiTech).
targets.json now contains a tag "MODEM" which tells that this target
has a modem and the modem_api is protected by a flag DEVICE_MODEM
(following the DEVICE_SERIAL fashion ).
* Lays down ground for mbed modem_api
* Standardizes pin names relating to modem device for UBLOX C027 and MTS_DRAGONFLY_F411RE
devices
* Ublox modem api is changed to use a standard, platform independent name so that same
api could be used with multiple ubloc modems.
* DCD Polarity macro is added to assist the driver in knowing correct polarity
GCC have not been capable enough to catch some linker errors which arose when
ethernet support for LWIP was disabled. Checks have been added to make sure that
unrefrenced code is not linked in.
nsapi_ppp glue layer is made more transparent to public cellular API. Storage of IP
addresses is removed. PPP layer already stores the addresses, so we pass the pointer back
to the upper layers.
If PPP is not used, we provide dummy functions.
* state machine corrections
* adding various standard API methods
* Addition/revision/enhancement of the nsapi_ppp glue layer
* Turning off debug by default
Mainly reutilizing code from ublox C027 support lib.
As we are using external PDP context, i.e., an external IP stack,
we will pass username and password to underlying stack running PPP.
We only support CHAP as the authentication protocol.
POSIX poll() provides a mechanism to attach a POLL_HUP event
if the modem or device hangs up on you. POLL_HUP and POLL_OUT are
mutually exclusive. We poll in the PPP_input() routine if the modem
hung up. If it did we stop the data consumption, close PPP and go back
to the driver for reserruction of AT parser and subsequent retries or
application specific actions.
This is achieved by attaching an interrupt to the DCD line of the modem.
When DCD line goes high (off), we have lost the carrier. So we record an
POLLHUP event using _poll_change().
In case of carrier lost, we would like to inform PPP data pump.
That involved setting up link status flag down semaphores.
mbed_lwip_bringup() and mbed_lwip_bringdown() had been Ethernet specific only.
We extend these routines to support PPP as well. Currently we support only one interface
at a time. However, future enhancement to multi interface support should be trivial.
mbed_ppp_init() is extended to take a function ptr.
ppp_lwip will call this callback upon a change in ppp link status.
in the beginning, the Ublox driver waits until the PPP link is established properly.
We introduce here mbed_trace to ppp_lwip shim layer.
If for some reason, FEATURE_COMMON_PAL is not included in the build,
dummies for trace functions are provided.
Add configuration to control Ethernet, PPP and TCP support.
Replaces LWIP_TRANSPORT_ETHERNET/PPP defines formerly used by targets.
Ethernet and PPP can be enabled simultaneously.
DHCPv4 is now only enabled if IPv4 and Ethernet are both enabled - we
assume PPP uses IPCP for configuration.
PPP configuration adjusted to cope with LWIP 2.0 changes, and
optimised for RAM a little.
This is a glue layer between LWIP PPP implementation and a device type FileHandle
stream. This enables an external interface which has a FileHandle, utilize LWIP network
stack via PPP, e.g., Cellular device, WiFi chips etc.
Its totally transparent to external device. Only thing this layer is interested in, is a
FileHandle. Similar is true for for the external device, it just hands over its stream to this
PPP layer and rest of the magic is done by this layer.
ATParser had been using std <vector> which had been pulling along a lot
of standard C++ stuff. We have an alternative implementation whcih achieves
a similar effect but without using <vector>. this saves a bunch of valuable
RAM resource.
We have also simplified the overall system by introducing proper CR and LF
rather than \r\n type of delimiters. This newline simplification is borrowed
from retarget.cpp.
Existing ATParser is extended to use FileHandle. This essentially detaches
ATParser from previous tight binding with various implementations of serial
interfaces with buffering.
Now the ATParser uses only abstract FileHandle and doesn't really care about
the underlying implementation. Underneath, it could be a USB device type FileHandle
or a Serial device type FileHandle etc.
Some simplification steps were taken as the code provided opportunities to simplify
and optimize.
BufferedSerial is a FileHandle and using SerialBase.
It keeps the SerialBase private however lets the user extend FileHandle
by keeping it public.
It is using CircularBuffer class for having circular buffers.
There are some minor amendments in CircularBuffer too.
Adding an entry for tx/rx buffer sizes in platform/mbed_lib.json.
Default size is 256 bytes.
For RTOS read(), write() calls yield for other threads to carry on with their stuff.
For non-RTOS blovking read or write would mean a loop where 100 percent resources are
consumed by this loop. Need to get a better implementation in. Currently no mechanism to
wake the mcu up after WFE.
mbed::fdopen() is provided in mbed_retarget.cpp which will attach a stream to the
given FileHandle. Removing mbed_set_unbuffered_stream() from stream class as it
is defined in mbed_retarget.cpp. Stream class should not decide whether it wants
to detach buffers from c library or not. mbed::fdopen() will do that based upon
isatty() call. So if a FileHandle is not a tty, i.e., is not a device type, c library
buffering will not be turned off. For device type FileHandles, c library buffering
is turned off.
This has been an attempt to extend existing FileHandle to behave like POSIX
file descriptor for input/output resources/devices too.
This will now provide an abstract indicator/handle any arbitrary file or device
type resource. May be in future, sockets too.
In order to correctly detect availability of read/write a FileHandle, we needed
a select or poll mechanisms. We opted for poll as POSIX defines in
http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html Currently,
mbed::poll() just spins and scans filehandles looking for any events we are
interested in. In future, his spinning behaviour will be replaced with
condition variables.
In retarget.cpp we have introduced an mbed::fdopen() function which is
equivalent to C fdopen(). It attaches a std stream to our FileHandle stream.
newlib-nano somehow does not seem to call isatty() so retarget doesn't work for
device type file handles. We handle this by checking ourselves in
mbed::fdopen() if we wish to attach our stream to std stream. We also turn off
buffering by C library as our stuff will be buffered already.
sigio() is also provided, matching the API of the Socket class, with a view to
future unification. As well as unblocking poll(), _poll_change calls the user
sigio callback if an event happens, i.e., when FileHandle becomes
readable/writable.
* Don't set errno when calls are successful (will slightly alleviate the problem
of errno not being thread-safe yet).
* Transfer errors returned from size() and seek() into errno.
* Fix isatty() - could never return 1 from a FileHandle.
* Use more appropriate errors than EBADF in some places (eg ENOENT for non-existant path).
There is an easy default implementation of spi_master_block_write that
just calls spi_master_write in a loop, so the default implementation
of spi_master_block_write has been added to all targets.
Use a newer version of uVisor that doesn't change the box main thread
function type. Previously, we required all box main thread definitions
to change from taking a `const void *` to a `void *` when moving to
RTX5. We now are backwards compatibile.
OsEventObserver objects expect a context to be maintained per thread on
their behalf. Add this context to the thread control block and extend
the thread creation functions with the ability to supply a context.
Add the OsEventObserver mechanism. A client interested in receiving
notifications on certain OS events can register to receive notifications
with osRegisterForOsEvents. This is useful for clients like the secure
memory allocator, which observes thread switching events in order to
swap in and out different memory allocator objects.
Hasnain Virk
Kevin Bracey
Martin Kojtal
Sam Grove
Jimmy Brisson
Bartosz Szatkowski
Yuguo Zou
Bartek Szatkowski
andreas.larsson
Jaeden Amero