The shortcut has some issues:

- sometimes it fails when sending an odd number of bytes (may be
  due to memory alignment?)
- the data pointer should point to "stable" data (and this is not
  guaranteed by caller, it may be some sort of temporary buffer)
- the SRAM is not guaranteed to start at 0x20000000

All the above problems must be properly fixed before reenabling
this part

* fix in_endpoint buffer size (was too big)
* use the same EP for CDC_ENDPOINT_OUT and CDC_ENDPOINT_IN (different buffers)
* fix CDC_ENDPOINT_IN ep type

This way all the 64 bytes available can be filled up

Fixes #30

See #30

calling digitalWrite with any value different from 0 will end
in performing digitalWrite(HIGH)

In the wire library there are several functions where
an unnecessarily complex coding has been used:

  - endTransmission: the availability of data is already
    checked in while(...), therefore need not be checked
    again in the loop.
  - requestFrom: the for-loop has a predefined and fixed
    number of loops. Therefore a check whether the last
    element has been reached is unnecessary and does not
    add any benefit.

Fixes #20

Fix for deadlock conditions after i2c bus errors

The first occurs when starting a read transaction from a slave that doesn't respond. The code would wait until the SB (slave on bus) bit is set in the INTFLAGS register, but when a nack occurs that never happens so we're stuck in an infinite loop. The fix is to also look for the MB flag to be set. If it is, issue a stop condition and return.

The second happens when a bus error (ie, an illegal stop condition) occurs while sending data as a master. In that case we are waiting for the MB (master on bus) flag to be set. When a bus error occurs that never happens, so again we end up in an infinite loop. The fix here is to also look for the BUSERR flag to be set. If it is, return an error condition.

the function returned 1 millisecond after the required time