Update Nucleo F303RE and STM32F4Discovery uavcan configurations

*  This driver supports the 'I2C lcd backpack' design that is based on the PCF8574 io expander.  There's a myriad of different vendors of such, but they are principally the same, save wiring and minor features like jumpers for I2C addresses.  This driver supports known and unknown variants.
*  The interface board supports HD44780-based LCD modules up to 4x32, and this driver accommodates all those formats.

This fix removes the disabling of the whole USB peripheral on suspend
interrupt. Its enough to freeze the clock instead.

When disabling the whole peripheral, the next wakeup-interrupt comes
up with an disabled clocking. The unfreeze clock has no effect, because
the master clock is disabled. This makes all registers, including the
IDR unwriteable and the IRQ falls in an endless loop blocking the whole
system.

Furthermore the disabling of the peripheral clock prevents hotplugging
or reconnecting the USB.

sam_systemreset.c edited online with Bitbucket

Add the up_systemreset interface to the samv7 arch.  The approach is slightly different in that: 1) It enables ARCH_HAVE_RESET and allows the user to set if, and for how long, to drive External nRST signal. It also does not contain a default board_reset, as that really should be done in the config's src if CONFIG_BOARDCTL_RESET is defined.

sam_i2cbus_initialize
sam_i2cbus_uninitialize
sam_i2cbus_initialize

Or twi_reset is called.

I found this a while back in the stm32 family, so there may be more arch-es with this sort of bug. I suppose any driver that has the notion of "do not set the freq if it is already set" could be suspect.

Tiva boards:  Fix a naming collision, rename board-specific function from tiva_timer_initialize() to tiva_timer_configure() to remove conflict

Reorder some logic:  (1) set initial CPU IDLE task regsters AFTER allocating stack, (2) invalidate cache in CPU start-up BEFORE handling first interrupt.

Fix for a minor typo that I introduced somewhere along the way during my testing.  This makes the bridge code actually compile…

Add basic configuration for stm32f411e-disco board with STM32F411VE chip

-------
   This patch enhances networking support for the simulation under Linux.
   Includes updated support for Linux TUN/TAP, and the addition of support for
   Linux bridge devices.

CHANGES
-------
   o Check to see if the d_txavail callback is present before calling it in
     the arp send code.  This prevents a segfault when simulating the telnetd
     daemon with arp send enabled.

   o Adjust the simulation's netdriver_loop() so it will detect and respond to
     ARP requests.

   o Do not attempt to take the tap device's hardware address for use by the
     simulation.  That hardware address belongs to the host end of the link,
     not the simulation end.  Generate a randomized MAC address instead.

   o Do not assign an IP address to the interface on the host side of the TAP
     link.

   + Provide two modes: "host route" and "bridge".

   + In host route mode, maintain a host route that points any traffic for the
     simulation's IP address to the tap device.  In this mode, so long as the
     simulation's IP is a free address in the same subnet as the host, no
     additional configuration will be required to talk to it from the host.
     Note that address changes are handled automatically if they follow the
     rule of if-down/set-address/if-up, which everything seems to.

   + In bridge mode, add the tap device to the specified bridge instance.  See
     configs/sim/NETWORK-LINUX.txt for information and usage examples.  This
     enables much more flexible configurations (with fewer headaches), such as
     running multiple simulations on a single host, all of which can access
     the network the host is connected to.

   o Refresh configurations in configs/sim where CONFIG_NET=y.  They default
     to "host route" mode.

   o Add configs/sim/NETWORK-LINUX.txt

CAVEATS
-------
   - The MAC address generation code is extremely simplistic, and does not
     check for potential conflicts on the network.  Probably not an issue, but
     something to be aware of.

   - I was careful to leave it in a state where Cygwin/pcap should still work,
     but I don't have a Windows environment to test in.  This should be
     checked.

   - I don't know if this was ever intended to work with OS X.  I didn't even
     try to test it there.

NOTES
-----
   - Was able to get telnetd working and simulate nsh over telnet, but only so
     long as listen backlogs were disabled.

     There appears to be a bug in the backlog code where sockets are being
     returned in SYN_RCVD state instead of waiting until they're ESTABLISHED;
     if you perform an immediate send after accepting the connection, it will
     confuse the stack and the send will hang; additionally, the connection
     will never reach ESTABLISHED state.

     Can be worked around by adding a sleep(1) after the accept in telnetd.  I
     don't have the necessary knowledge of the IP stack to know what the
     correct fix is.

Adds support for the 3 user LEDs on the Nucleo-144 board family