Go Down

Topic: Ok, on to Atmega32 (Read 24 times) previous topic - next topic

hotcarrier


Hoeken

Quote
Hoeken,
Can you tell me does the IDE compile the bootloader for the atmega644? Under which conditions?


no, the ide doesnt compile the bootloader, it expects it to be precompiled. its very easy to compile it, just type 'make' in the appropriate bootloader folder.

if you want to take the easier route, i added the bootloader for both atmega644 and atmega644P to the svn.nycresistor.com library.  the reason i wasnt before was because the code was still in flux and didnt want it to get out of date.  its pretty much solid now.

cheers,
Zach

Hoeken

Quote
Quote
Yo!

Sorry about the posting delay, but we managed to fix the problem.  We now have a fully functioning Arduino environment running on an atmega644.  This is very exciting, and we'll be posting a big announcement in a few weeks once we have it all nicely packaged up for the blogosphere.
...
* atmega644 compatible arduino 'core' (located in code/cores/sanguino)
...

Hoeken,

What changes have you made to robotcraft.ca patch to get sanguino core to work with your board?

I'd like to integrate those changes back into the patch.


Andre

PS: I've also added Mega48 (Pololu Orangutang, anyone? :) ) and Mega324P ;). You can get the patch here.
http://www.robotcraft.ca/webshop/p7/Robot-Software-Downloads/pages.html
The code is not fully tested yet, but if anyone is willing to poke around, you are welcome to.


That might be a bit tricky.  We decided it would be simpler to install, and much easier to understand if the sanguino/atmega644 stuff was completely separate from the arduino/atmega168 stuff.  i basically ripped out all the defined(__ATMEGA168__) stuff, made a separate 'cores/sanguino' folder that contains all the same functions / libraries as the standard arduino core, but written for the atmega644.

I know this makes it a PITA to put back into your patch, but it makes it much easier for me to maintain, and much easier for those who wish to install the sanguino software because:

1. no patching, its simply copy a folder to the /cores folder and edit boards.txt
2. it is a separate core, so there is little to no chance of breaking the regular arduino support
3. its much easier for someone to get in and understand how it all works without tons of #defines making things murky

anyway, its obviously open source so you're more than welcome to dig through and take what you'd like for your patch.

mellis

I should add that I'd be open to a setup that made it easier to add support for new microcontrollers without having to either sprinkle #ifdefs everywhere or reimplement everything in a separate core.  This seems like a tricky problem, but maybe someone has some ideas.  

mazx

Quote


I know this makes it a PITA to put back into your patch, but it makes it much easier for me to maintain, and much easier for those who wish to install the sanguino software because:

1. no patching, its simply copy a folder to the /cores folder and edit boards.txt
2. it is a separate core, so there is little to no chance of breaking the regular arduino support
3. its much easier for someone to get in and understand how it all works without tons of #defines making things murky


Here is a few thoughts that I have on this topic.

I agree with #2 and #3 that's why doing experimental work on default arduino core is better done in a separate core directory. This way you don't run a risk of breaking Arduino IDE if your experiments are not successful. I had my share of Arduino IDE reinstalls myself ;-).

As to #1, it's about the same amount of work in both cases since you overwrite original files in arduino directory by UNZIPing so called 'patch' file. :)  So whether you unzipping one or another file it still the same operation.

However, one CON that makes me a bit weary of going the route of keeping one core directory per MCU is that a separate core directory per MCU makes it a lot harder to stay in sync with original Arduino core. :-? Every time there is a change in the default core you need to propagate it into multiple other cores, plus re-test it. So instead of maintaining a single patch that allows everyone to compile arduino core for atmega 32,644,324P,48 and ...., other AVR MCUs, maintainer would required to create and maintain two or more different cores. Maintenance efforts will progressively  turn into a full-time job and a nightmare later as more MCUs will be added to the IDE supported list. Anyone, is looking to do it for free? :-)

A compromise solution which will address #1 and #2 points on you list as well as require moderate maintenance requirements is having pluggable 'multiAVR' core. This solution will require maintaining a separate copy of arduino core directory but keeping #defines in there so this core could be re-used for multiple MCUs. This way  you keep default arduino core intact, a 'multiAVR' core in-sync with the base arduino core and maintenance/porting effort at reasonable levels. People who look for Arduino IDE support for other AVR MCUs could download separate 'Arduino-on-steroids' MOD and plug it into 'cores' directory. Simple and easy!

Anyway, if anything I hope that other people will contribute to a discussion on what's a better way of turning Arduino IDE into milti-AVR coding platform ;-) I've heard number of positive comments from fellow roboteers about Arduino IDE and how easy it's for them to get their bots rolling around doing staff in a matter of hours when using Arduino IDE with AVR MCUs but not all of them are happy with being tied to single Mega168 AVR. So there is a definite need for multi core support in Arduino IDE - Sanguino is a proof of that. :-) We just need to figure out a way of channeling our effort for a maximum return on the development cycles.


Andre
robotcraft.ca

Go Up