Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to Arduino 1.0.5 (and for OSX avr-gcc 4.8.1) #1

Open
wants to merge 268 commits into
base: ardupilot-ide
Choose a base branch
from

Conversation

hughescr
Copy link

@hughescr hughescr commented Jun 7, 2014

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

shfitz and others added 30 commits December 23, 2012 11:55
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.
cmaglie and others added 27 commits March 25, 2014 18:01
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));
}
Conflicts:
	.gitignore
	app/src/processing/app/debug/Compiler.java
* this bug got me super confused when i tested on windows
@hughescr
Copy link
Author

hughescr commented Jun 7, 2014

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.

@rmackay9
Copy link
Member

rmackay9 commented Jun 7, 2014

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).
http://dev.ardupilot.com/wiki/building-ardupilot-with-arduino-windows/

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.

@hughescr
Copy link
Author

hughescr commented Jun 7, 2014

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).

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 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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.