This change allows the compiler to handle callbacks resolution.
Callbacks now must be implemented on the class that extends
PUSBListNode and this is forced by compiler by means of pure
virtual methods.
Also the calls to HID.interface() and HID.endpoint() can now
be simplified to interface() and endpoint() respectively since
the methods are no more static.
The method
int8_t PluggableUSB::addFunction(PUSBListNode *, uint8_t *)
has been changed to
bool PluggableUSB::plug(PUSBListNode *node)
since both EP and Interfaces are now saved directly into node
In particular HIDDescriptorListNode.cb has been renamed to
HIDDescriptorListNode.descriptor because it contains decriptor data
and not callbacks.
Moreover the HID_Descriptor.descriptor field has been renamed
to HID_Descriptor.data so the structure has now two fields length
and data.
typedef struct __attribute__((packed)) {
uint16_t length;
const void* data;
} HID_Descriptor;
class HIDDescriptorListNode {
public:
HIDDescriptorListNode *next = NULL;
const HID_Descriptor *descriptor;
HIDDescriptorListNode(const HID_Descriptor *d) : descriptor(d) { }
};
This imply a change in the use of the node from:
node->cb->lenght
node->cd->descriptor
to
node->descriptor->length
node->descriptor->data
According to #3786 removed the reference to Leonardo only in while(!Serial) of the examples.
Changed in in "wait for serial port to connect. Needed for native USB port only"
with this PR you can add
\#include Keyboard.h
\#include Mouse.h
\#include HID.h
in the top of the sketch and you will expose a Mouse+Keyboard
From the library pow, simply add
static HID_Descriptor cb = {
.length = sizeof(_hidReportDescriptor),
.descriptor = _hidReportDescriptor,
};
static HIDDescriptorListNode node(&cb);
HID.AppendDescriptor(&node);
in the class' constructor and you are done!
This fixes the Wire examples that uses I2C reserved address (from 0 to 7) substituting them with 8 that is the first one available and that can be used.
I also modified the wire reference
http://www.arduino.cc/en/reference/wire
according to this fact.
To avoid having a .cpp just for an extern variable definition, `static`
has been chosen over `extern`.
As the `EEPROMClass` class simply wraps functionality located elsewhere,
it is completely compiled away. Even though each translation unit which
includes the header will get a copy with internal linkage, there is no
associated overhead.
More info
[here](http://stackoverflow.com/questions/29098518/extern-variable-only-in-header-unexpectedly-working-why)
Previously, the TX pin would be set to output first and then written
high (assuming non-inverted logic). When the pin was previously
configured for input without pullup (which is normal reset state), this
results in driving the pin low for a short when initializing. This could
accidenttally be seen as a stop bit by the receiving side.
By first writing HIGH and then setting the mode to OUTPUT, the pin will
have its pullup enabled for a short while, which is harmless.
Instead of using a lookup table with (wrong) timings, this calculates
the timings in SoftwareSerial::begin. This is probably a bit slower, but
since it typically happens once, this shouldn't be a problem.
Additionally, since the lookup tables can be removed, this is also a lot
smaller, as well as supporting arbitrary CPU speeds and baudrates,
instead of the limited set that was defined before.
Furthermore, this switches to use the _delay_loop_2 function from
avr-libc instead of a handcoded delay function. The avr-libc function
only takes two instructions, as opposed to four instructions for the old
one. The compiler also inlines the avr-libc function, which makes the
timings more reliable.
The calculated timings directly rely on the instructions generated by
the compiler, since a significant amount of time is spent processing
(compared to the delays, especially at higher speeds). This means that
if the code is changed, or a different compiler is used, the
calculations might need changing (though a few cycles more or less
shouldn't cause immediate breakage).
The timings in the code have been calculated from the assembly generated
by gcc 4.8.2 and gcc 4.3.2.
The RX baudrates supported by SoftwareSerial are still not unlimited. At
16Mhz, using gcc 4.8.2, everything up to 115200 works. At 8Mhz, it works
up to 57600. Using gcc 4.3.2, it also works up to 57600 at 16Mhz and up
to 38400 at 8Mhz. Note that at these highest speeds, communication
works, but is still quite sensitive to other interrupts (like the
millis() interrupts) when bytes are sent back-to-back, so there still
are corrupted bytes in RX.
TX works up to 115200 for all combinations of compiler and clock rates.
This fixes#2019
