Go Down

Topic: Ok, on to Atmega32 (Read 26179 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

mazx

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


I would suggest breaking out shared files between multiple cores into separate directory while keeping core specif ones in their appropriate directories. This will reduce maintenance and testing effort while encourage code re-use by maintainers.


Hoeken

Quote

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.


One problem with a multi-avr core is that you assume that developers submitting patches will never introduce bugs. if you overwrite the arduino 'core' with an arduino + sanguino core, and i made a mistake, then the functionality is broken for both, and it will probably just lead to headaches.

Quote

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 few things here:

1. its not exactly per-chip specific, but rather per-board.  the 'arduino' core is the logical place to put atmega88, atmega168, and atmega328 support, since that is the sub family set of chips to use.  the 'sanguino' core will support atmega644 and atmega644p

2. the arduino developers are not going to support all of these different chips.  they are focused on supporting the arduino and the variations they choose to do.  i am going to be providing support for the atmega644 via sanguino.  i imagine that in the future, others will be in charge of supporting their own core if they create a board variant on another chip.

3. i'm not doing it for free.  i currently sell arduino's and i plan on selling sanguino kits.  sure, the code is 100% free and open, but that doesnt mean there isnt any financial incentive ;)

4. it took about a days worth of work to port the code to the atmega644.  most of that was wrapping my head around the whole system.  i'm comfortable with updating the library as the arduino folks release new versions.

i like your idea of a multi-core approach, and i'm willing to help out and do what i can to make it happen.  i'm definitely more of a pragmatist and this was the way forward that seemed to cause the least problems with the current arduino state-of-the-art (0011).

Hoeken

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


I would suggest breaking out shared files between multiple cores into separate directory while keeping core specif ones in their appropriate directories. This will reduce maintenance and testing effort while encourage code re-use by maintainers.



i like this.  looking at the sanguino 'core' folder, there are quite a few redundant files:

binary.h
HardwareSerial.cpp *
HardwareSerial.h *
main.cxx
pins_arduino.h *
WConstants.h
wiring.h
wiring_pulse.c
wiring_shift.c
WMath.cpp
WProgram.h

* except for minor hardware-specific parts

moving all of those standard Arduino framework files and definitions in to some sort of 'framework' folder that contains nothing hardware specific, and then having individual 'core' directories that implement the predefined functions in a hardware-specific way would be ideal.  like i said before, i'm all for it.  unfortunately i dont have a *ton* of experience in designing C/C++ programs, so I'd be hesitant to architect such a system, but i'm more than willing to help with the porting and work needed to make it all work once a plan is laid out.

michelef

Quote
Quote from mazx on Yesterday at 21:16:33:

Quote
Quote from mellis on Yesterday at 19:44:18:
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.

I would suggest breaking out shared files between multiple cores into separate directory while keeping core specif ones in their appropriate directories. This will reduce maintenance and testing effort while encourage code re-use by maintainers.


Can the IDE be modified so that it looks in more than one folder for the cores? Currently boards.txt has:

diecimila.build.core=arduino or sanguino.build.core=sanguino.

If it could be made to follow something like:

sanguino.build.board=sanguino
sanguino.build.core=arduino

and use the files from the arduino folder unless there is one with the same name in the sanguino folder, then the core files would be shared by all boards and updated by the arduino team, and only the board specific files (like pins_arduino.c) would need to be provided by the specific board developer(s). This would make maintaing a common core easier (IMHO).





mellis

There are certainly ways to factor out the common (non-hardware-specific) files, but I'm not sure how much it helps, since I don't think there are very many.  It's probably possible to refactor the code so that the hardware specific parts are in fewer places, but that's a major task that I'd probably look to the community to take the lead on.  As I said, though, if someone can find a good solution, I'm definitely open to including it.

hotcarrier

OK, I was able to upload and burn the atmega644p, but not the atmega644 with the bootloader. The clock is running at 16mhz and the led on PB2 flashes appropriately. I can compile a sketch, but when I try to upload it, I get an avrdude error saying expected signature for atmega644p is blah blah. I have a 644p in the breadboard. When I tried to burn the bootloader into a atmega644 I received the same error. Can someone suggest how I might approach this?

michelef

Quote
Posted by: hotcarrier.  Yesterday at 23:13:26
OK, I was able to upload and burn the atmega644p, but not the atmega644 with the bootloader. The clock is running at 16mhz and the led on PB2 flashes appropriately. I can compile a sketch, but when I try to upload it, I get an avrdude error saying expected signature for atmega644p is blah blah. I have a 644p in the breadboard. When I tried to burn the bootloader into a atmega644 I received the same error. Can someone suggest how I might approach this?


did you replace you avrdude.conf file? It's in the Arduino/hardware/tools/avr/etc. Put back the one that came with the Arduino dist which has the ATmega644 and ATmega644p definitions.

hotcarrier

michelef,
Thanks, I tried the 0010 and 0011 avrdude.conf which appear to be the same and both appear to have the 644 in them. Any other ideas?

michelef

Quote
Posted by: hotcarrier      Posted on: Yesterday at 17:13:59,
I tried the 0010 and 0011 avrdude.conf which appear to be the same and both appear to have the 644 in them. Any other ideas?


Sorry, you have to have also the avrdude itself from the 0011 is you are using the AVRMacPack.

no13

#74
Aug 26, 2008, 02:03 pm Last Edit: Aug 26, 2008, 02:08 pm by no13 Reason: 1
I have used the arduino bootloader sources to recompile a bootloader for my own mega32 board running at 16MHz.. I had to modify the implementation of the getch() and putch() functions and UART initialisation. I also included the startup-hack by Limor. I used the pin-mappings as posted by Andre from robocraft.ca. Simple examples (blinky, analog to serialport) compile, and can be uploaded from standard arduino environment. I posted my modified sources on my blog at http://retrointerfacing.com.

(so thanx to all on this forum, since reading all this posts provided me with enough info to make my project a couple of steps closer to completion :)

Best wishes,
Edwin

Go Up