Ok, on to Atmega32

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.

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

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

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.

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?

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.

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?

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.

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

Best wishes,
Edwin

Can I run this one one of these?

http://cgi.ebay.com/Atmel-ATMega32-Controller-and-Board-Kit-Robotics_W0QQitemZ180115533675QQcmdZViewItem?_trksid=p3286.m20.l1116

I just happen to have one.

Can I run this one one of these?

http://cgi.ebay.com/Atmel-ATMega32-Controller-and-Board-Kit-Robotics_W0QQitemZ180115533675QQcmdZViewItem?_trksid=p3286.m20.l1116

I just happen to have one.

As far as I can see, you can. Point is however that the board you mention does not have a serial port or USB port. You will have to add either a serialport-adapter (a circuit with a MAX232 or equivalent) or a USB port (with an FTDI-serial-to-USB converter) in order to make the bootloader work. Also no crystal is available, so you either have to recompile the sources to run at 8MHz (internal RC oscillator) or add a 16MHz crystal. To get the bootloader 'in' first, you'll be needing an ISP type programmer.

Can I run this one one of these?

http://cgi.ebay.com/Atmel-ATMega32-Controller-and-Board-Kit-Robotics_W0QQitemZ180115533675QQcmdZViewItem?_trksid=p3286.m20.l1116

I just happen to have one.

I've been using this board to port Arduino core to ATMega32, 324 and 644. We also sell them here -> http://www.robotcraft.ca/webshop/Controllers/c22/p280/AVR-ATMega32-Robot-Controller-Board/product_info.html

It's should work just fine but you will need USB-FTDI converter like no13 already said.

Andre
robotcraft.ca

wow, i totally spaced it, but the Sanguino was launched a few weeks (a month?) ago, and things are going well. i made it a website with all sorts of info, board designs, etc. You can see it here: http://www.sanguino.cc

I've just been using the ideas found here to make arduino stuff work with the ATMega32 on the Penguino AVR

so far it's working well, can probably expect a patch released for arduino software for the penguino soonish

Hi

I tried the method where 7 files (downloaded from robotcraft.ca) will be replaced and board.txt modified with the following lines:

################################
atmega324.name=ATmega324
atmega324.upload.protocol=stk500
atmega324.upload.maximum_size=14336
atmega324.upload.speed=19200
atmega324.bootloader.low_fuses=0xff
atmega324.bootloader.high_fuses=0xdd
atmega324.bootloader.extended_fuses=0x00
atmega324.bootloader.path=atmega8
atmega324.bootloader.file=ATmegaBOOT.hex
atmega324.bootloader.unlock_bits=0x3F
atmega324.bootloader.lock_bits=0x0F
atmega324.build.mcu=atmega324p
atmega324.build.f_cpu=8000000L
atmega324.build.core=arduino

#################################
babyo48.name=Pololu Baby Orangutang - ATMega48
babyo48.upload.protocol=stk500
babyo48.upload.maximum_size=14336
babyo48.upload.speed=19200
babyo48.bootloader.low_fuses=0xff
babyo48.bootloader.high_fuses=0xdd
babyo48.bootloader.extended_fuses=0x00
babyo48.bootloader.path=atmega168
babyo48.bootloader.file=ATmegaBOOT_168_ng.hex
babyo48.bootloader.unlock_bits=0x3F
babyo48.bootloader.lock_bits=0x0F
babyo48.build.mcu=atmega48
babyo48.build.f_cpu=20000000L
babyo48.build.core=arduino

Still I get compiling error about USART

I have ordered one of the boards. I have the core files fully compiling. I sent them to the people that sell this board. They will be posting them in a week or so when I have a chance to test them.

If anyone wants to try my libraries before that, send me a PM

Mark