The previous chip detection was inspired by the old IP65 driver code. For some reason it didn't work as expected. The new code is simpler and based on this statement in the chip datasheet: "The upper byte always reads as 33h and can be used to help determine the I/O location of the LAN91C96."
Made Ethernet drivers easier to consume by assembly programs.
* Replaced function pointers with JMP instructions.
* Provide return values additionally via Carry flag.
Reset Ethernet chips on initialization.
Both for the CS8900A and the W5100 the data sheets just say that
the RESET bit is automatically cleared after the RESET. This may
be interpreted in two ways:
1) There's no need to be afraid of reading the RESET bit as 1 and
unintentionally trigger a RESET by writing it back after ORing in
some other bit.
2) The RESET process isn't complete before the RESET bit hasn't
become 0 again.
It's impossible for me to empirically falsify the latter option
as the drivers are supposed to work on faster machines than the
ones I have access to. And if the RESET process includes things
like oscillators then the time to complete the RESET could differ
even between multiple exemplars of the same chip. Therefore I
opted to presume the latter option.
However that means a non-exsistent chip may cause an infinite
loop while waiting for the RESET bit to be cleared so I finally
added code to detect the presence of the Ethernet chips. There's
a risk of a chip being locked up in a way that makes the detection
fail - and therefore the RESET not being performed. This catch-22
needs to be solved by the user doing a hard RESET.
Instead of requiring all calls to `watchdog_start` to be
wrapped inside `#if WATCHDOG_CONF_ENABLE` guards, we control
things from within the WDT driver itself.
This commit also includes some minor documentation and
indentation cleanups
* Decouple 64-bit address from LINKADDR_SIZE
* get and set object from/to the start/end of the src/dest buffer
* We expect size == 8 (rather than size < 8) for both get_ and set_object. Error otherwise
* The RF no longer sets parameters by itself. We let the platform do this, using the extended API.
This avoids the limitation of having a single UART available at runtime, without
duplicating code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Because the CC2538 has a multi-byte SPI RX FIFO, flushing the buffer
requires more than just a single read. This adds a loop that empties the
entire RX buffer on a FLUSH().
Different SPI chips needs different SPI settings. This commit adds a
function that allows chip drivers to configure the SPI peripheral before
using it.
The frame pin the driver was using as a chip select does not work as
most devices expect it to. It toggles after every byte, and most chips
interpret that as end of message. To make drivers more reliable, each
chip driver should setup a GPIO and assert it as needed.
Contiki sometimes fails to boot correctly and locks up in
random_init()
This problem only manifests itself for specific versions
of the arm-gcc toolchain and then again only for specific
levels of optimisation (-Os vs -O2, depending on the
value of the SMALL make variable)
The lockup is caused when we write an RFCORE XREG before
the RF clock ungating has taken effect, which in turn
only occurs depending on the assembly generated for those
two instructions:
REG(SYS_CTRL_RCGCRFC) = 1;
REG(RFCORE_XREG_FRMCTRL0) = 0x00000008;
This commit makes the RNG wait for the ungating to take
effect before attempting to write the register
