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.
