Update to Arduino 1.0.5 (and for OSX avr-gcc 4.8.1) #1
Conversation
Chnaged LOW to HIGH
This reverts commit 7e5ca62.
Fixes arduino#1160 Merge remote-tracking branch 'arduino/master-issue1160'
This alters the debounce example code to toggle the LED rather than just use the button state to set the LED state. Fixes arduino#293
gitignore was missing from master
Removing duplicate comment from top of KeyboardAndMouseControl example code.
removed redundant thisPin declaration in setup
Update build/shared/examples/05.Control/Arrays/Arrays.ino
This allows use of A0, A1, A2, A3 constants and for them to be mapped to the appropriate analog input channel. It should only be used if the macro is actually defined.
Update README.md
Esplora: added reading from Tinkerkit inputs
The comments explaining the if..else part were mistaken.
fix comments on spaceship example
Updated to reflect changes with how the IDE creates new blank sketches.
removed the variable “led” and added some additional descriptive text
Previously, when SoftwareSerial was initialized, it would always be set to an idle level of HIGH, even when inverted logic was enabled. Once a byte is transmitted, the idle level gets correctly set to LOW instead. This commit makes sure that the idle level is correct directly after initialization already. This fixes arduino#1361.
Bug in SoftwareSerial when using inverse logic
Match return value to type in available()
If the Start of Frame interrupt triggers just after the call to USB_SendSpace in USB_Send then we can get data loss. When the first bank is full and the second partially full, the SOF handler will release the second bank via USB_Flush. Data is then lost due to overflow as USB_Send continues writing data to the now-closed bank. Fix this by re-checking the FIFO status inside LockEP, immediately before doing the data write. Signed-off-by: Paul Brook <[email protected]>
Read CDC data from USB FIFO on demand instead of in ISR. Remove superfluous ring buffer. Signed-off-by: Paul Brook <[email protected]>
Stream::find(char *target) passes NULL as “terminator” to Stream::findUntil(char *target, char *terminator), which immediately dereferences it by passing it on to strlen():
bool Stream::find(char *target)
{
return findUntil(target, NULL);
}
// as find but search ends if the terminator string is found
bool Stream::findUntil(char *target, char *terminator)
{
return findUntil(target, strlen(target), terminator, strlen(terminator));
}
Stream::find(char *target) passes NULL as “terminator” to Stream::findUntil(char *target, char *terminator), which immediately dereferences it by passing it on to strlen() :
bool Stream::find(char *target)
{
return findUntil(target, NULL);
}
// as find but search ends if the terminator string is found
bool Stream::findUntil(char *target, char *terminator)
{
return findUntil(target, strlen(target), terminator, strlen(terminator));
}
Fix of a bug in Stream.cpp
Conflicts: .gitignore app/src/processing/app/debug/Compiler.java
* this bug got me super confused when i tested on windows
|
Release notes for Arduino 1.0.4 to 1.0.5 is here I actually am basing off SHA: arduino/Arduino@1918966 on the Arduino master branch, should be easy to stay in sync with updates on mainline. |
|
hughescr, This is interesting and a perhaps more integrated solution than what we use now. But I was wondering if you'd seen that in fact, we've been using the gcc 4.8.1 compiler because of the advantages in code size you mentioned. We simply couldn't get arducopter to fit on the APM1 and APM2 anymore without upgrading. I'll have a chat with some of the other devs (especially Tridge) to decide whether we should incorporate your changes. For Arducopter we're planning on dropping support for APM1 and APM2 after the next release (AC3.2). Re the ArduPirate-NG board, it's probably not worth it for the AVR based board but if they develop an ARM or Linux based board, perhaps the ArduPirate group would consider building an AP_HAL layer for their board like the VRBrain and Linux ports have. I think we'd be happy to have them join the dev team. I think it would be more efficient overall for us to all be working off the same code base. |
|
I hadn't seen that you're using 4.8.1 -- all the stuff I saw online was pointing to the old 1.0.3 based Arduino with some ancient gcc in it. The ardupilot-ide branch on github seems to be that version too. Is there somewhere else I should be looking? I'd be happy to rework anything if it makes sense to do so. I'm kind of working on this full-time for the next few months and have a very good amount of experience in software development, open source, etc. (almost none in planes/drones though before about a week ago).
I more than fully agree. I'm working on plane stuff while it seems most of the megapirate-ng stuff is focused on copters, and not much activity has happened at all on the project since ~ february. The latest plane version in megapirate-ng is 2.7.4 I think... I found https://github.com/smurfy/ardupilot-mpng which has a much closer-to-upstream version of 2.7.6/2.7.8 merged into megapirate-ng and have been digging into understanding that. It's clear that the way megapirate added its boards support was a divergent attempt to do things which is much better done with the HAL stuff you guys have been working on. Architecturally, it's a little fragmented too, with stuff in /libraries depending on header files in /Ardu* and things like that which make me feel a little icky inside. My next project after getting my build environment set up was to essentially take the work megapirate-ng has done for my board (The HK AIO board which is identical to the Crius AIO board), and then convert all their board-specific stuff into a HAL which could get back into mainline ardupilot; that all as a path to getting more recent than 2.7.6 for my plane. To do that, I'll work from a fork of your ardupilot repo so that merging back to you should be easy once I get the HAL done. Hacking drone software is too hard, too expensive, and requires too much knowledge about hardware. My project for the summer is to help fix the first 2 of those issues and put together good resources for a software-developer audience for the hardware issues which don't presuppose that you know wtf a stepper motor is (I had seen a stepper motor before last week, and knew how they worked in theory, but hadn't ever actually connected one to a PWM and a lever arm before) |
This re-applies (and fixes) the ardupilot patches to Arduino onto the current upstream 1.0.5-r2-gitlatest version from upstream. Also adds the MegaPilot-NG board definition.
For OSX only (so far) it also updates to use the avr-gcc 4.8.1 picked up from upstream Arduino's ide-1.5.x-avr-toolchain-gcc-4.8.1 branch
avr-gcc 4.8.1 compiles ardupilot to about 20% smaller size than the old compiler, and benchmarks on other codebases show a 1.5x-8x speedup at runtime (at the expense of slightly larger runtime RAM consumption). This is a significant improvement that should be carried into the Windows and Linux builds as well, I just haven't got around to that yet since I don't work on those platforms. It should be quite easy using the pre-built avr-gcc toolchains available from http://downloads.arduino.cc/avr-toolchain-${file_arch}-gcc-4.8.1.zip by modifying build/build.xml