Ok, on to Atmega32

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.

Anyway, here is the 'latest' developments, aka how to follow along at home:

all files are stored in NYC Resistor subversion at: http://svn.nycresistor.com/projects/sanguino/

  • eagle board design files for soon to be released board based on atmega644 (i'm playing with prototype right now, will order production ASAP
  • atmega644 compatible bootloader (located in code/bootloader)
  • atmega644 compatible arduino 'core' (located in code/cores/sanguino)
  • a boards.txt file that is ready to go with the required changes.

so, what do you need to do to get arduino running on your atmega644?

  1. copy the 'sanguino' core file to arduino/hardware/cores
  2. copy the 'bootloader' directory to arduino/hardware/bootloader/atmega644 (rename the folder)
  3. replace boards.txt in arduino/hardware with the one in sanguino/code/boards.txt (or just copy the relevant section in)
  4. make sure your avr-gcc has support for atmega644 (the macs dont have it built in, others may... will be fixed in arduino 0012)
  5. breadboard the circuit based on the eagle schematic
  6. upload the bootloader via the arduino 'upload bootloader' menu option. i prefer usbtinyisp, but use whatever programmer you like
  7. upload your sketches via serial connection.
  8. yay!

cool! Several of the guys around here like the 644.

Will this be merged into the Arduino distribution?

-j

Great [smiley=tekst-toppie.gif]

cool! Several of the guys around here like the 644.

Will this be merged into the Arduino distribution?

-j

sort of.

i had a nice, long face-to-face conversation with a couple of the core arduino guys. they were very supportive and are receptive and welcoming of projects like this.
understandably, they care deeply about providing software that is simple and reliable out of the box. additionally, they are all quite busy and are unwilling to take on maintenance of others code. therefore, they declined to include it in the default arduino distribution. from the perspective of the guy who wants it included, i think they made the right decision.

however, they do want to make it possible. two important things were discussed and are in the works:

  • arduino 0012 which is due out here in the next month will include avr-gcc for more chips out of the box, including the atmega644/atmega644p.
  • a future version of arduino, hopefully arduino 0013, will include support for a 'new board' option in the 'boards' menu which will prompt you for a .zip file that contains the relevant files for your board of choice. this will be provided by the designer of the board in question. (eg: you download arduino, then you download my sanguino-0012.zip file and install it into your arduino software.)

in the meantime, with built-in support for the atmega644 chip it becomes a trivial process to add support to the arduino software. there are 3 things required:

  1. copy the 'sanguino' core to the 'cores' folder
  2. copy the 'atmega644' bootloader to the 'bootloaders' folder
  3. add a new board entry to the boards.txt file

it then becomes a 5 minute task. yay!

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

Hotcarrier,

the bootloader comes pre-compiled already for specific AVR chip and clock speed.

It's not the same as Arduino library or sketch files.

Andre

OK, I thought so, but the posted bootloader here:
http://macjordomo.fuortes.net/atmega644/

is an uncompiled c file. Does someone have the atmega644 (not 644p) bootloader compiled? With that
I am ready to go and try this.

My mistake, this file
http://svn.nycresistor.com/projects/sanguino/code/bootloaders/atmega644/

is uncompiled, the other location I showed in the previous post has a compiled version,but appears to be for the 644p. At least that is what my environment with all the IDE updates and a breadboard atmega644 with the AVRisp II reports.

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? :slight_smile: ) 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.

My mistake, this file
http://svn.nycresistor.com/projects/sanguino/code/bootloaders/atmega644/

is uncompiled, the other location I showed in the previous post has a compiled version,but appears to be for the 644p. At least that is what my environment with all the IDE updates and a breadboard atmega644 with the AVRisp II reports.

What clock speed your 644 is running at?

My atmega644 clock is 16mhz,crystal controlled.

My atmega644 clock is 16mhz,crystal controlled.

Here you go
http://www.robotcraft.ca/webshop/download/zip/bootloader_atmega644_16MHz.zip

Here is the compiler output:

C:\platform\arduino-0011\hardware\tools\avr\bin\avr-gcc -g -Wall -O2 -mmcu=atmeg
a644 -DF_CPU=16000000L  '-DMAX_TIME_COUNT=8000000L>>1' '-DNUM_LED_FLASHES=3' -Wl
,--section-start=.text=0xF800 -c -g -O2 -Wall -mmcu=atmega644 ATmegaBOOT.c -o AT
megaBOOT_644.o
avr-gcc: --section-start=.text=0xF800: linker input file unused because linking
not done
C:\platform\arduino-0011\hardware\tools\avr\bin\avr-gcc -g -Wall -O2 -mmcu=atmeg
a644 -DF_CPU=16000000L  '-DMAX_TIME_COUNT=8000000L>>1' '-DNUM_LED_FLASHES=3' -Wl
,--section-start=.text=0xF800 -o ATmegaBOOT_644.elf ATmegaBOOT_644.o
C:\platform\arduino-0011\hardware\tools\avr\bin\avr-objcopy -j .text -j .data -O
 ihex ATmegaBOOT_644.elf ATmegaBOOT_644.hex

The zip contains source by nyresistor guys and binaries produced for atmega644@16MHz. I've changed makefile slightly so now you can recompile the bootloader to your heart's content by simply specifying path to your ARDUINO_HOME\hardware\tools\avr\bin.

ARDUINO_AVR_BIN_DIR=C:\platform\arduino-0011\hardware\tools\avr\bin

Hmm... you will need to have Make installed on your system. Otherwise, use compiler output as posted above as your guideline to compile bootloader manually.

Andre
robotcraft.ca

Thanks Mazx!

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

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? :slight_smile: ) 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.

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 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. :slight_smile: 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? :slight_smile:

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 :wink: 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. :slight_smile: We just need to figure out a way of channeling our effort for a maximum return on the development cycles.

Andre
robotcraft.ca

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.

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. :slight_smile: 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.

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? :slight_smile:

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 :wink:

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

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.