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"
Print::write(const uint8_t *buffer, size_t size) and Print::print(const
__FlashStringHelper *ifsh) would continue calling write(char) after a
failed write(char) this behavior would render returned count unuseable
see arduino/Arduino issue #3614
This makes the CDC "Serial" object on the Leonardo and similar boards
support this recently introduced method as well. The CDC code in the sam
core is not changed.
end() already waited for the buffer to be empty, but then there could
still be two bytes in the hardware registers that still need to be
transmitted (which were dropped or kept in the buffer, depending on the
exact timing).
This changes the wait loop to a call to the flush() function, which
already takes care of really waiting for all bytes to be transmitted,
meaning it is safe to turn off the transmitter.
This allows detecting when the USB host sends a break request and what
the value of the request was. See the comments in USBAPI.h for details.
This just modifies the avr core, not the sam core.
This allows a sketch to find out the settings chosen by the USB host
(computer) and act accordingly.
Other than reading the DTR flag and checking if the baudrate is 1200,
the regular CDC code doesn't actually use any of these settings.
By exposing these settings to the sketch, it can for example copy them
to the hardware UART, turning the Leonardo into a proper USB-to-serial
device. This can be useful to let the computer directly talk to whatever
device is connected to the hardware serial port (like an XBee module).
The Teensy core already supported these methods. This code was
independently developed, but the method names were chosen to match the
Teensy code, for compatibility (except that `dtr()` and `rtr()` return
`bool`, while the Teensy version return a `uint8_t`).
This change is applied to both the avr and sam cores, which have a very
similar CDC implementation.
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!
and restore it in case of aborted reboot
use RAMEND-1 as suggested by @yyyc514 in PR #2474
of course it's not a real solution but we cannot force everyone to update the bootloader using an external programmer
This uses the gnu11 standard, which is C11 with GNU extensions.
Previously, gnu89 was being used, which is pretty ancient by now. C99
brings some important improvements, some of which were already available
and used even without this option. C11 is more recent and brings more
minor improvements. Most notable feature is the static_assert statement,
allowing checking invariants at compiletime using the full C
expressions.
Gcc 4.8 defines __cplusplus as 201103L, so we can check for that now. It
still also defines __GXX_EXPERIMENTAL_CXX0X__, but this could help on
other compilers, or if gcc ever decides to stop defining the
experimental macro.
This uses the gnu++11 standard, which is C++11 with GNU extensions.
C++11 should be full compatible with the previously used C++98
standards, so all pre-existing sketches should continue to work.
to avoid the bug #2198 simply reconfigure the pin -> no additional overhead if pinMode configuration is performed at the beginning of the sketch, 4 to 25% overhead on all analogRead() due to the additional check
When a pin is designated as an output on the Arduino Due, the pin is set
to a HIGH logic level. Changing the default pin state to LOW makes the
behaviour correspond with AVR.
1Mhz is a default clock speed on Atmega328, many users run it on the
internal 1Mhz clock to save battery power. Up until now
delayMicroseconds() function wasn't taking this frequencies into an
account.
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.
* Moving Upload options from "File" menu to "Sketch" menu as those
are sketch actions more than file actions.
Signed-off-by: Arnav Gupta <championswimmer@gmail.com>
Rebased the bugfix from the original Google Code issue #292 to work with Arduino 1.6.x
Description of original fix provided by Pete62:
The later 8 bit AVR's use two registers (TCCRxA, TCCRxB) whereas the ATmega8 only uses a single register (TCCR2) to house the control bits for Timer 2. Bits were inadvertently being cleared.
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
Before, the interrupt would remain enabled during reception, which would
re-set the PCINT flag because of the level changes inside the received
byte. Because interrupts are globally disabled, this would not
immediately trigger an interrupt, but the flag would be remembered to
trigger another PCINT interrupt immediately after the first one is
processed.
Typically this was not a problem, because the second interrupt would see
the stop bit, or an idle line, and decide that the interrupt triggered
for someone else. However, at high baud rates, this could cause the
next interrupt for the real start bit to be delayed so much that the
byte got corrupted.
By clearing the interrupt mask bit for just the RX pin (as opposed to
the PCINT mask bit for the entire port), any PCINT events on other bits
can still set the PCINT flag and be processed as normal. In this case,
it's likely that there will be corruption, but that's inevitable when
(other) interrupts happen during SoftwareSerial reception.
This precalculates the mask register and value, making setRxIntMask
considerably less complicated. Right now, this is not a big deal, but
simplifying it allows using it inside the ISR next.
Since those functions are only called once now, it makes sense to inline
them. This saves a few bytes of program space, but also saves a few
cycles in the critical RX path.
Previously, up to four separate but identical ISR routines were defined,
for PCINT0, PCINT1, PCINT2 and PCINT3. Each of these would generate
their own function, with a lot of push-popping because another function
was called.
Now, the ISR_ALIASOF macro from avr-libc is used to declare just the
PCINT0 version and make all other ISRs point to that one, saving a lot
of program space, as well as some speed because of improved inlining.
On an Arduino Uno with gcc 4.3, this saves 168 bytes. With gcc 4.8, this
saves 150 bytes.
Similar to SoftwareSerial::write, this rewrites the loop to only touch
the MSB and then shift those bits up, allowing the compiler to generate
more efficient code. Unlike the write function however, it is not needed
to put all instance variables used into local variables, for some reason
the compiler already does this (and doing it manually even makes the
code bigger).
On the Arduino Uno using gcc 4.3 this saves 26 bytes. Using gcc 4.8 this
saves 30 bytes.
Note that this removes the else clause in the code, making the C code
unbalanced, which looks like it breaks timing balance. However, looking
at the code generated by the compiler, it turns out that the old code
was actually unbalanced, while the new code is properly balanced.
This change restructures the loop, to help the compiler generate shorter
code (because now only the LSB of the data byte is checked and
subsequent bytes are shifted down one by one, it can use th "skip if bit
set" instruction).
Furthermore, it puts most attributes in local variables, which causes
the compiler to put them into registers. This makes the timing-critical
part of the code smaller, making it easier to provide accurate timings.
On an Arduino uno using gcc 4.3, this saves 58 bytes. On gcc 4.8, this
saves 14 bytes.
Somehow gcc 4.8 doesn't inline this function, even though it is always
called with constant arguments and can be reduced to just a few
instructions when inlined. Adding the always_inline attribute makes gcc
inline it, saving 46 bytes on the Arduino uno.
gcc 4.3 already inlined this function, so there are no space
savings there.
Before, there was nearly identical code for the inverted and regular
cases. However, simply inverting the byte in the inverted case allows
using the regular code twice, reducing the generated code size by 100
bytes (on an Arduino Uno and gcc 4.3, on gcc 4.8 the reduction is 50
bytes).
stopListening also disabled the interrupt, if needed, so calling that
function makes more sense. Since stopListening only disables the
interrupt when the current SoftwareSerial is the active object, and that
can only be the case when _rx_delay_stopbit is non-zero, there is no
need to separately check _rx_delay_stopbit anymore.
If an interrupt causing overflow would occur between reading
_buffer_overflow and clearing it, this overflow condition would be
immediately cleared and never be returned by overflow().
By only clearing the overflow flag if an overflow actually occurred,
this problem goes away (worst case overflow() returns false even though
an overflow _just_ occurred, but then the next call to overflow() will
return true).
This prevents interrupts from triggering when the SoftwareSerial
instance is not even listening.
Additionally, this removes the need to disable interrupts in
SoftwareSerial::listen, since no interrupts are active while it touches
the variables.
The current check is still always false when the old check was, but
additionally it will not disable the interrupts when they were never
enabled (which shouldn't matter much, but this is more consistent).
In this case, SoftwareSerial::begin will not have enabled the
interrupts, so better not allow the SoftwareSerial instance to enter the
listening state either.
Before enabling interupts, begin would see if the given receive pin
actually has an associated PCINT register. If not, the interrupts would
not be enabled.
Now, the same check is done, but when no register is available, the rx
parameters are not loaded at all (which in turn prevents the interrupt
from being enabled). This allows all code to use the same "is rx
enabled" (which will be added next).
Previously, it could happen that SPI::beginTransaction was
interrupted by an ISR, while it is changing the SPI_AVR_EIMSK
register or interruptSave variable (it seems that there is
a small window after changing SPI_AVR_EIMSK where an interrupt
might still occur). If this happens, interruptSave is overwritten
with an invalid value, permanently disabling the pin interrupts.
To prevent this, disable interrupts globally while changing
these values.
From https://github.com/arduino/Arduino/pull/2376#issuecomment-59671152
Quoting Andrew Kroll:
[..this commit..] introduces a small delay that can prevent the wait
loop form iterating when running at the maximum speed. This gives
you a little more speed, even if it seems counter-intuitive. At
lower speeds, it is unnoticed. Watch the output on an oscilloscope
when running full SPI speed, and you should see closer back-to-back
writes.
Quoting Paul Stoffregen:
I did quite a bit of experimenting with the NOP addition. The one
that's in my copy gives about a 10% speedup on AVR.
Previously, when verbose uploads were enabled, avrdude was run with four
-v options, causing it to dump all raw bytes exchanged with the
bootloader. This floods the console so much that meaningful output
mostly disappears.
Most users probably want to enable verbose mode just to see what avrdude
command is ran. Furthermore, users that benefit from the raw bytes
dumped are perfectly capable of either running avrdude manually, or
modifying platform.txt. Given that, running avrdude with just one -v
should be plenty.
This fixes#891.
