OR-ing an offset to a base address instead of adding it is dangerous
because it can only work if the base address is aligned enough for the
offset.
Moreover, if the base address or the offset has a value unknown at
compile time, then the assembly instructions dedicated to 'base +
offset' addressing on most CPUs can't be emitted by the compiler because
this would require the alignment of the base address against the offset
to be known in order to optimize 'base | offset' into 'base + offset'.
In that case, the compiler has to emit more instructions in order to
compute 'base | offset' on most CPUs, e.g. on ARM, which means larger
binary size and slower execution.
Hence, replace all occurrences of 'base | offset' with 'base + offset'.
This must become a coding rule.
Here are the results for the cc2538-demo example:
- Compilation of uart_init():
* before:
REG(regs->base | UART_CC) = 0;
200b78: f446 637c orr.w r3, r6, #4032 ; 0xfc0
200b7c: f043 0308 orr.w r3, r3, #8
200b80: 2200 movs r2, #0
200b82: 601a str r2, [r3, #0]
* now:
REG(regs->base + UART_CC) = 0;
200b7a: 2300 movs r3, #0
200b7c: f8c4 3fc8 str.w r3, [r4, #4040] ; 0xfc8
- Size of the .text section:
* before: 0x4c7c
* now: 0x4c28
* saved: 84 bytes
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Currently there is an linker error when compiling with debug information.
This is only the case for dwarf (the default). Everything is fine with
stabs, thus allowing to debug and use all the other nice tools like
"objdump -S".
Since avr-libc 1.8.0 MCUSR is marked as poison as it was replaced by the
correct name MCUCSR.
Thus code still using the old MCUSR name does not compile anymore.
This commit replaces usages of former MCUSR by its new name MCUCSR and
modifies the alias fallback accordingly.
The border-router tries to transmit and do other stuff after turning
the radio off, and the radio driver didn't handle that very well.
With this fix, it's no longer necessary to reset the border router
after starting tunslip6.
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."
The problem with the current version of the code was that the condition at the end of the do...while loop at Timer A1 interrupt:
while((TACCR1 - TAR) > INTERVAL);
evaluates to false whenever TACCR1 == TAR.
Not incrementing TACCR1 in this case leads to Timer A1 interrupt not being called for 2 seconds, until TAR counter reaches TACCR1 again after an overflow.
The patch avoids this problem by changing the condition of the loop, and using CLOCK_LT macro to compare between time values.
The patch also attempts to fix another problem: a read of TAR register while it is being updated may return a lower value than the actual contents. To avoid that, the "read twice and compare results" idiom should be used. As the TAR register is updated by the actual hardware, it is of no importance whether it is read with interrupts disabled or enabled; the problem can occur in both contexts.
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.
