Arduino Forum

Forum 2005-2010 (read only) => Hardware => Development => Topic started by: bigfun on Oct 22, 2006, 05:16 am

Title: Ok, on to Atmega32
Post by: bigfun on Oct 22, 2006, 05:16 am
Ok, I feel like I really know the Atmega168 now, so now I'm just pushing dev like the kind of project manager we have all hated at some point during our careers. Shoot me if this is going too far.  I have an Atmega32. This thing rocks, hardware-wise.  If Arduino can go  here, at least in the software world, there is no end to what it can do. I see that the Arduino Atmega168 bootloader supports it.  The question is:  what are we going to need to add to the Arduino IDE to support it?  I want an item in the dropdown.  I just tried burning the Atmega168-compatible software to an Atmega32 in an Olimex AVR-P40-USB board and, well, nothing much happened when I then tried to upload an Arduino sketch.  Perhaps someone can shine a light on the differences between an Atmega168 and an Atmega32 and how that applies to the dropdown in the Arduino IDE.  
Title: Re: Ok, on to Atmega32
Post by: mellis on Oct 22, 2006, 12:02 pm
To start experimenting, you can change the "build.mcu" setting in your preference file.  This is the setting that the Tools | Microcontroller (MCU) menu sets.   Changing it to "atmega32" will tell the Arduino environment to compile your sketch for the atmega32, which means your .hex file will have the right opcodes at least (since I think the ATmega32 and the ATmega8 have slightly different instructions).  You'll probably get a bunch of errors in the Arduino core, though, since the hardware - and thus the code - for the two chips are different.  Take a look at ARDUINO/lib/targets/arduino/wiring.c and pins_arduino.c.  Sadly, editing this file to work with the ATmega32 probably requires reading the ATmega32 datasheet (http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf), which is not the most fun way to spend a Sunday.  Supporting different chips and different boards is definitely a long-term goal of the Arduino project, though, so any headway you make would be greatly appreciated.
Title: Re: Ok, on to Atmega32
Post by: ritzdank on Nov 13, 2006, 11:17 pm
even easier for beginning; try it without Arduino IDE, with the command line way-of-life. http://www.arduino.cc/playground/Learning/CommandLine. just edit the mcu type in makefile and adjust both files pins_arduino.c and wiring.c. probably, other files? anyway, i would be very interested in getting different atmel chips to work. would expand arduino community enormously.
Title: Re: Ok, on to Atmega32
Post by: mellis on Nov 15, 2006, 08:45 am
Just to reiterate, since you were asking questions on another thread.  You don't need to worry about the IDE (at least, not at first).  You don't actually need a menu item for the chip you want to use, you can just edit your preferences file and set "build.mcu" to "atmega32".  What you do need to do is edit the wiring.c and pins_arduino.c files in the ARDUINO/lib/targets/arduino directory.  It shouldn't require too many changes, just changing some names of hardware registers and bits for doing particular hardware configuration things.  It will probably mean spending a lot of time reading the ATmega32 datasheet, though.  Once you get those files working, you can go in and add an ATmega32 menu item if you want.
Title: Re: Ok, on to Atmega32
Post by: leKuk on Nov 28, 2006, 04:50 pm
hi,

what's the main advantage of the atmega32 over the 168 ?

i found an avr overview here: http://www.sander-electronic.de/datasheet/AVR.pdf

am i right that the difference is something like from the atmega8 to the atmega168?
i mean double sized memory + a few more I/O ?

not that i could not find a use for both of it,
i just wonder if there was another killer feature or possibility i didn't find being ignorant, like for USB-connectivity or energy-saving or something.

//kuk
Title: Re: Ok, on to Atmega32
Post by: bigfun on Dec 04, 2006, 12:46 am
Actually, a lot more i/o.  and double the flash of the atmega168 and quadruple the atmega8.   Anything with half the storage of my old commodore 64 should be able to do a lot of fun stuff.  Still, at this point in Moore's Law I don't know why Atmel can't make a processor with a megabyte of storage that fits in the Atmega8 footprint.  Imagine what that could do!
Title: Re: Ok, on to Atmega32
Post by: leKuk on Dec 04, 2006, 01:15 am
i see,

but how many more i/o is that? digital or analog... the pdf i found is not clear to me.
Title: Re: Ok, on to Atmega32
Post by: karlcswanson on Dec 04, 2006, 03:58 am
according to AvrFreaks (http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=displayDev&objectid=69) there is 32 I/O pins, 4 are PWM and 8 are analog.
Title: Re: Ok, on to Atmega32
Post by: scubo on Sep 29, 2007, 12:06 am
I would like to use an Atmega16 with the Arduino software.  I have seen in the previous posts, there is a way to do this. But as the last post is from december 2006 I want to ask if maybe someone has already resolved this problem.
I want to switch from Bascom AVR (which is a programing language for Atmels in Basic) to an open source programme like Arduino or Wiring, but as far I see, there are only some types of Atmels supported at the moment.
Title: Re: Ok, on to Atmega32
Post by: qratman on Sep 29, 2007, 10:31 am
Hi, I have also a spare ATmega16 which I'd like to use for Arduino. Some suggestions? So now there are two requests  for ATmega16 support 8-)
Title: Re: Ok, on to Atmega32
Post by: Cheater on Sep 29, 2007, 12:25 pm
It would be nice if Arduino handled all AVR chips.

I'd figure out how to do it but I only have a 168.
Feel free to send me chips. ;)

If the Arduino supported multiple chips then we could pick the right chip for the job, write the code and just hit the upload button.
Hell it would automatically make programs work on different chips.
Title: Re: Ok, on to Atmega32
Post by: scubo on Sep 29, 2007, 12:42 pm
I have taken a look to the files that mellis mentioned in one of the previous posts. I think, it will be not too complicated to make some Atmega16 or 32 files. I like the Atmega16 because it is cheap and have more I/O pins. As a first step, we could try to create the necessary files for Atmega16 and 32. So more experienced users would be able to upload their .hex files with an ISP programmer and AVRDude on homemade Atmel/Arduino boards.
Title: Re: Ok, on to Atmega32
Post by: scubo on Sep 30, 2007, 12:46 pm
I modified now the pins_arduino.c file and changed the build command in the preferences.
The compiling works fine without error message. As I have problems with upload (I have a STK200 parallel programmer), I use the .hex file that will be generated in the applet folder and upload it separately with AVRDude. At the end, writing is successful, but no reaction on my atmel16....

What can be the problem?
I didn't touch so far the wiring.c file because  I hope that maybe the ATmega8 and 16 have the same parameters. No idea....

Although i get no error message with compiling I don't know, if the changes i made, are ok. Especially I don't know if #elseif is correct syntax at all.
I attach you the code of the file. I hope someone can help me to figure out what is wrong. Thanks!

#include <avr/io.h>
#include "wiring_private.h"
#include "pins_arduino.h"

#define PA 1
#define PB 2
#define PC 3
#define PD 4

// these arrays map port names (e.g. port B) to the
// appropriate addresses for various functions (e.g. reading
// and writing)
const uint8_t PROGMEM port_to_mode_PGM[] = {
     NOT_A_PORT,
#if defined(__AVR_ATmega16__)
       &DDRA,
#else
NOT_A_PORT,
#endif
     &DDRB,
     &DDRC,
     &DDRD,
};

const uint8_t PROGMEM port_to_output_PGM[] = {
     
     //NOT_A_PORT,
#if defined(__AVR_ATmega16__)
       &PORTA,

#else
NOT_A_PORT,
#endif
     &PORTB,
     &PORTC,
     &PORTD,
};

const uint8_t PROGMEM port_to_input_PGM[] = {
     
     //NOT_A_PORT,
#if defined(__AVR_ATmega16__)
       &PINA,
#else
NOT_A_PORT,
#endif
     &PINB,
     &PINC,
     &PIND,
};

const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
     PD, /* 0 */
     PD,
     PD,
     PD,
     PD,
     PD,
     PD,
     PD,
     PB, /* 8 */
     PB,
     PB,
     PB,
     PB,
     PB,
     PC, /* 14 */
     PC,
     PC,
     PC,
     PC,
     PC,
#if defined(__AVR_ATmega16__)
       PC,
     PC,
       PA,         /* 22*/
     PA,
     PA,
     PA,
     PA,
     PA,
     PA,
     PA,
#endif

};

const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] = {
     _BV(0), /* 0, port D */
     _BV(1),
     _BV(2),
     _BV(3),
     _BV(4),
     _BV(5),
     _BV(6),
     _BV(7),
     _BV(0), /* 8, port B */
     _BV(1),
     _BV(2),
     _BV(3),
     _BV(4),
     _BV(5),
     _BV(0), /* 14, port C */
     _BV(1),
     _BV(2),
     _BV(3),
     _BV(4),
     _BV(5),
#if defined(__AVR_ATmega16__)
       _BV(6),
     _BV(7),
     _BV(0), /* 22, port A */
     _BV(1),
     _BV(2),
     _BV(3),
     _BV(4),
     _BV(5),
       _BV(6),
     _BV(7),
#endif


};

const uint8_t PROGMEM digital_pin_to_timer_PGM[] = {
     NOT_ON_TIMER, /* 0 - port D */
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     // on the ATmega168, digital pin 3 has hardware pwm
#if defined(__AVR_ATmega168__)
     TIMER2B,
#else
     NOT_ON_TIMER,
#endif
     NOT_ON_TIMER,
     // on the ATmega168, digital pins 5 and 6 have hardware pwm
#if defined(__AVR_ATmega168__)
     TIMER0B,
     TIMER0A,
#elseif defined(__AVR_ATmega16__)
       TIMER1B,
       TIMER1A,
#else
     NOT_ON_TIMER,
     NOT_ON_TIMER,
#endif

#if defined(__AVR_ATmega16__)
       TIMER2,
#else

     NOT_ON_TIMER,
#endif
     NOT_ON_TIMER, /* 8 - port B */
#if defined(__AVR_ATmega16__)
       NOT_ON_TIMER,
     NOT_ON_TIMER,
#else
     TIMER1A,
     TIMER1B,
#endif

#if defined(__AVR_ATmega168__)
     TIMER2A,
#elseif defined(__AVR_ATmega16__)
       NOT_ON_TIMER,
#else  
     TIMER2,
     
#endif
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,/* 14 - port C */
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,
#if defined(__AVR_ATmega16__)
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER, /*22 port A */
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,
     NOT_ON_TIMER,
      NOT_ON_TIMER,
     NOT_ON_TIMER,
#endif

};
Title: Re: Ok, on to Atmega32
Post by: scubo on Sep 30, 2007, 08:24 pm
it works, it works!!! yupi....

There are still some problems with the ports addressing maybe and maybe we have to adjust the interupts for the timer and PWM... but in fact, I have some blinking LEDs here!

 ;D  Welcome Atmega16  ;D
Title: Re: Ok, on to Atmega32
Post by: jds on Oct 01, 2007, 12:37 pm
Congrats, well done!

Now, on to Atmega32?
Title: Re: Ok, on to Atmega32
Post by: scubo on Oct 01, 2007, 01:26 pm
I will check this week if it is really working properly. Until now it´s no more than playing around.
But if it will really work for Atmega16, why not for an Atmega32, too?
The problem is that I am doing no more than "try and error". Maybe someone can give me advice how to go on more sistematically.


Title: Re: Ok, on to Atmega32
Post by: jds on Oct 16, 2007, 01:39 pm
Any update on this?
Title: Re: Ok, on to Atmega32
Post by: scubo on Oct 16, 2007, 02:37 pm
I am still playing around with it.
I realized that there is a mistake in the code of my previous post. Unfortunately I dont find the "edit" option to change this post and update it.
"// NOT A PORT" has to be changed twice in "NOT A PORT". Don't ask me why
I uploaded a small programme to test input and output, and it works fine and with the right ports now.  But I still haven´t tested if all ports are really active and what happens with PWM,timer and so on.
I will take a look at it the next days.
Title: Re: Ok, on to Atmega32
Post by: jds on Oct 17, 2007, 11:46 am
You can edit your posts by clicking the 'modify' button at the top of the post (right side of screen).

Thanks for the update!
Title: Re: Ok, on to Atmega32
Post by: scubo on Oct 21, 2007, 01:26 pm
It seems that the editing of previous posts only is possible for some hours/days.... sorry.
To avoid that this happens again, I have put now all things on my webpage to be able to update it.

I have tried to make a documentation of the modifications I did and made a small sketch of a very basic Atmega16 board for around 5 Euros.

take a look at
http://www.subtours.com/ralph/theory/atmega16witharduino.html

As far as I have tested now, it seems that everything works fine (analog read and analog write (PWM) as well as serial).
Atmega32 should work as well because it has the same pin distribution.

At the end i took away all "if´s" for atmega8 and 168, because it was too confusing. So when you change the files, it only works for atmega16. Save the original files before testing!




Title: Re: Ok, on to Atmega32
Post by: mellis on Oct 21, 2007, 05:01 pm
This is very cool!  I've been hoping to include support for more chips in the Arduino software.

Are you (or anyone else) interested in officially supporting this?  That is, integrating it back into the standard core (ATmega8 and ATmega168) and testing and updating it as the core changes?  If so, we could certainly include with the standard distributions of the software.  We just need someone (not me) to commit to keeping it working.
Title: Re: Ok, on to Atmega32
Post by: Cheater on Oct 23, 2007, 03:12 pm
With my next shipment from Futurlec I'll grab a handful of assorted Atmel chips and see what I can do with them. :)
I may be interested in officially supporting them if I get everything working smoothly.

Btw scubo its probably best if you now got the original Arduino files and your modified files open together and put the defines in that way.
Makes it easier to see what needs editing.
Title: Re: Ok, on to Atmega32
Post by: scubo on Oct 23, 2007, 08:46 pm
hi cheater! you are right; its not very good this documentation....
I prepared now a pdf where you can clearly see, what I have edited.

http://www.subtours.com/ralph/downloads/texts/atmega16_arduino.pdf

But maybe some things are not really necessary. That´s the problem for me that I have no basic knowledge of what has to be done.

But I think that we would need different data files for each atmel instead of one with a lot of "if´s" for each atmel. I started with it, as you can see on the wrong code that i cant delete anymore :( , but at the end I decided to make the timer definitions only for atmega 16 because i was too confused.



Title: Re: Ok, on to Atmega32
Post by: Cheater on Oct 24, 2007, 02:01 am
Quote
But I think that we would need different data files for each atmel instead of one with a lot of "if´s" for each atmel. I started with it, as you can see on the wrong code that i cant delete anymore :( , but at the end I decided to make the timer definitions only for atmega 16 because i was too confused.

Well I half agree with you and half disagree.

Having something like #include <atmel168.h> at the top of the code would work but it would also duplicate a lot of code between chips.
On the other hand IFs are slightly messier but they mean everything is efficient.

Good commenting with the IFs is the best solution imho.

Oh btw you may want a tool like Kompare.
I'm not sure of any Windows alternative but it is a visual diff program.
Here is a screenshot:

(http://www.caffeinated.me.uk/kompare/screenshot.png)
Title: Re: Ok, on to Atmega32
Post by: Digger450 on Oct 24, 2007, 07:47 am
I use Beyond Compare for windows, great application.
Title: Re: Ok, on to Atmega32
Post by: englere on Oct 28, 2007, 07:31 pm
I just thought I'd point out that the ATMega328P should be a drop-in replacement for the Arduino MCU. Like the Mega32 it has twice the memory. But it has the same 28-pin form-factor. Should be available by Feb 2008.
Title: Re: Ok, on to Atmega32
Post by: neuromancer2701 on Oct 31, 2007, 08:23 pm
I have been looking into expanding the Arduino capabilities.  From what I have read the Atmega 164P/324P/644P would best choice.  The IO is same for all three but the flash size is different.  The board layout would be similar to the current one and you gain the flash size as well as more io.  The XX4P models have more features than the standard 32 as well.

Title: Re: Ok, on to Atmega32
Post by: englere on Oct 31, 2007, 09:42 pm
The Picopower chips are a good choice because they give you a lot of low-power options, and they're otherwise quite compatible.

Although I love lots of flash memory, any chips over 32K can't be JTAG debugged by a Dragon. I know the official Arduino IDE doesn't support JTAG debugging yet, but AVR Studio does.

For now I'm keeping compatibility with the Dragon but I hope to move beyond 32K someday. I'd either have to buy a JTAGICE mk II, or perhaps some new third party products that aren't even on the market yet. Most of the third-party JTAG devices don't support the newer chips but I know of two companies working on new JTAG devices that would be cheaper than the JTAGICE mk II, but still compatible with it.

If enough of us request JTAG style in-circuit debugging (single-step, breakpoints, watches) in the Arduino IDE maybe that can be added someday.

Eric
Title: Re: Ok, on to Atmega32
Post by: mazx on May 21, 2008, 01:59 pm
Gents,

I've been messing around with arduino-0011-core.zip in an effort to port it to ATMega32 and ATMega644 chips. I finally managed to get it to work and was able to successfully test it with ATMega32 by essentially running code written for ATMega168 with a minor tweak at the application level (PDE file) that does PWM register initialization. I think that tweak can be safely ignored for the purpose of code/chip interoperability since its application specific. ATMega644 support still requires more work and testing.

I have successfully validated following things myself on ATMega32:
I2C master mode (PC0,PC1)
8 and 16 bit PWM on (PB3,PD4,PD5,PD7)
Hardware Serial (PD0,PD1)
Software Serial (PB0)
Analog reads PA0-2

Clock speed used for tests is 8Mhz.

I would really appreciate if someone could review/try this code  for interoperability correctness as well as get creative with it and hopefully provide me with some feedback.

List of modded files:
pins_arduino.c
pins_arduino.h
wiring.c
wiring_analog.c
wiring_digital.c

To get things to work, I had to actually copy these five files into $ARDUINO_IDE_HOME/hardware/cores/arduino directory. But before you do it, make sure that you backup originals so you have something to roll-back to ;) in case things get messy.

This is were you can download the files http://www.robotcraft.ca/webshop/p7/Robot-Software-Downloads/pages.html
Modded version of arduino-0011-core.zip -> http://www.robotcraft.ca/webshop/download/zip/arduino-mega32-644-modded-public.zip
Modded files only -> http://www.robotcraft.ca/webshop/download/zip/arduino-mega32-644-mod.zip

Cheers...


Andre
Title: Re: Ok, on to Atmega32
Post by: Dalek on May 29, 2008, 06:08 am
Hey guys,

I tried to get these files incorporated, but I got a lot of "first instances"

Also how are you uploading your sketches to your Atmega 16s and 32s?

Does the arduino software create .hex files I can upload using my STK500?


OK to prevent "first instances" the #elseif had to be changed to #elif
Title: Re: Ok, on to Atmega32
Post by: mazx on May 30, 2008, 03:15 am
> I tried to get these files incorporated, but I got a lot of "first instances"

What files are giving those errors and for what micro 32 or 644?

> Also how are you uploading your sketches to your Atmega 16s and 32s?

I'm using plain $14 parallel port programmer for ATMega32 and ATmel AVRISPMK2 for 644. I was also using STK500 for both during initial testing.
I don't use bootleader for any of my purposes.

> Does the arduino software create .hex files I can upload using my STK500?  
Yep, Arduino IDE creates HEX files (AVR GCC actually  :))
You can if you plug m168 into STK500 board. I bet you could also do some Wodoo with cables and program Arduino board directly from STK. I've never done this myself though. :-/

> OK to prevent "first instances" the #elseif had to be changed to #elif
Great, what files did you have to fix?
I'm wondering why I haven't run into those issues myself. I had those earlier too and they essentially were caused by improper preprocessor if/else blocks.
Title: Re: Ok, on to Atmega32
Post by: mazx on Jun 04, 2008, 08:21 pm
Ok,

I've updated the zip http://www.robotcraft.ca/webshop/download/zip/arduino-mega32-644-mod.zip file.

The update includes support for ATMega644 (in addition to ATMega32) micros.

http://www.robotcraft.ca/webshop/download/zip/arduino-mega32-644-modded-public.zip is still available but doesn't include support for ATMega644.

You will also need to add the following configuration information to your $ARDUINO_HOME/hardware/boards.txt file, so you could select ATMega32 and ATMega644 as target microprocessors from your Arduino IDE.


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

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

You may need to adjust atmega32.build.f_cpu/atmega644.build.f_cpu lines and specify appropriate clock speed that micro is running at. Mine was running at 8MHz.

The IDE uploading functionality is not working since the bootloader wasn't ported yet. You will need to use ISP  hardware to load up your HEX files onto 32/644 megas.
Title: Re: Ok, on to Atmega32
Post by: wenger on Jun 09, 2008, 12:00 am
Hey Mazx,

this is pretty exciting.  I noticed on the robotcraft site that you also sell the pololu products - have you by any chance tried to get the arduino boot loader onto the two mcu's on the orangutan x2?  That would be an even more fantastic board if it would could run wiring code natively on the 168 and 644 on the x2.
Title: Re: Ok, on to Atmega32
Post by: mazx on Jun 09, 2008, 10:59 pm
I've been thinking about X2 a while ago myself. This particular controller board might require some additional research time.

I don't remember seeing ISP connector for ATMega168 on X2 board to start with plus even if you manage to replace firmware on atmega168 with a default arduino bootloader you will probably 'brick' your X2 altogether since mega168 serves as ISP programmer to mega644. :)

Now what remains to be seen is whether you can use bootloader on 644 while there is mega168 is sitting in front of it (provided we have a working bootloader for mega644). In theory, I don't see a problem with that but it needs to be verified.

I will post more information on this once I get some time to port a bootloader to mega644 and experiment with X2 board.

But yeah, I completely agree with you on using WIRING to program X2 would be a blast.  :)
Title: Re: Ok, on to Atmega32
Post by: Dalek on Jun 19, 2008, 12:18 am
The "first instance" problem happen in the pins_arduino.c (this is for a 32)

I also had problems with WProgram.h the line
"unsigned long pulseIn(uint8_t pin, uint8_t state,unsigned long timeout = 1000000L);"

I got these errors

WProgram.h:13: error: default argument given for parameter 3 of 'long unsigned int pulseIn(uint8_t, uint8_t, long unsigned int)'

WProgram.h:13: error: after previous specification in 'long unsigned int pulseIn(uint8_t, uint8_t, long unsigned int)'

I was able to upload sketches using the STK500, you just need to mod the avrispmkii to be serial instead of usb, and mod the preferences.txt

I also get tons of errors from stdio.h, When I was using WinAVR to compile C I never had any problems

They start at line 263 with things like "stdio.h:263: error: expected unqualified-id before 'int'"

Quote
>


I tried to get these files incorporated, but I got a lot of "first instances"

What files are giving those errors and for what micro 32 or 644?

> Also how are you uploading your sketches to your Atmega 16s and 32s?

I'm using plain $14 parallel port programmer for ATMega32 and ATmel AVRISPMK2 for 644. I was also using STK500 for both during initial testing.
I don't use bootleader for any of my purposes.

> Does the arduino software create .hex files I can upload using my STK500?  
Yep, Arduino IDE creates HEX files (AVR GCC actually  :))
You can if you plug m168 into STK500 board. I bet you could also do some Wodoo with cables and program Arduino board directly from STK. I've never done this myself though. :-/

> OK to prevent "first instances" the #elseif had to be changed to #elif
Great, what files did you have to fix?
I'm wondering why I haven't run into those issues myself. I had those earlier too and they essentially were caused by improper preprocessor if/else blocks.

Title: Re: Ok, on to Atmega32
Post by: mazx on Jun 19, 2008, 06:14 pm
Dalek,

What version of Arduino IDE are you using?
Title: Re: Ok, on to Atmega32
Post by: Dalek on Jun 20, 2008, 12:27 am
The IDE I use is 0011,

I did find a solution to the problems with stdio.h, it is apparently not uncommon.

before calling stdio.h

add #undef int()
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jun 25, 2008, 08:32 pm
Hey Guys,

I'm very interested in getting Arduino working for the atmega644, and I've read through this thread a couple times already.  I got the updated files, and I added the 644 to my boards.txt file.

As soon as I switch to the atmega644 'board', i get this error:

"unknown MCU `atmega644' specified"  as well as a list of all the supported MCUs.

My rather uneducated guess is that the avr-gcc included with arduino-0011 does not have built-in support for the atmega644.  a cursory google search shows that it is supported, so my guess its a simple matter of rebuilding the included avr-gcc to enable atmega644 support.

Is this the right way?  Does anyone have any pointers and/or links I should check out to help me?  I'd really appreciate it.

~Zach
Title: Re: Ok, on to Atmega32
Post by: mazx on Jun 25, 2008, 09:09 pm
Arduino-0011 comes with avr-gcc that already supports atmega644. :-?

You can validate it by running

%ARDUINO_HOME%\hardware\tools\avr\bin\avr-gcc --target-help

Look for "Known MCU names:" section. It contains every AVR module this compiler build supports.

Here is mine produced by stock arduino-0011 avr-gcc.

Known MCU names:
 avr1 avr2 avr3 avr4 avr5 avr6 at90s1200 attiny10 attiny11 attiny12
 attiny15 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22
 attiny26 at90s4433 at90s4414 at90s4434 at90s8515 at90s8535 at90c8534
 at86rf401 attiny13 attiny2313 attiny261 attiny461 attiny861 attiny24
 attiny44 attiny84 attiny25 attiny45 attiny85 atmega603 atmega103
 at43usb320 at43usb355 at76c711 atmega48 atmega8 atmega83 atmega85
 atmega88 atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2 at90pwm3
 atmega16 atmega161 atmega162 atmega163 atmega164p atmega165 atmega165p
 atmega168 atmega169 atmega169p atmega32 atmega323 atmega324p atmega325
 atmega325p atmega329 atmega329p atmega3250 atmega3250p atmega3290
 atmega3290p atmega406 atmega64 atmega640 atmega644 atmega644p atmega128
 atmega1280 atmega1281 atmega645 atmega649 atmega6450 atmega6490
 atmega16hva at90can32 at90can64 at90can128 at90usb82 at90usb162
 at90usb646 at90usb647 at90usb1286 at90usb1287 at94k atmega2560
 atmega2561

Do you have any other avr-gcc installed (though I doubt it will cause a problem)? It's been a while since I looked at arduino IDE source but if I remeber correctly it keeps looking for avr-gcc within it's own %ARDUINO_HOME% directory structure.

Could this be a problem with line endings in your boards.txt file after copy/paste? This is just a guess. :-/
Can you post atmega644 portion of your boards.txt file?
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jun 25, 2008, 09:27 pm
uh oh.  maybe this is a mac-specific problem.  here is what i get when i run that:

Iowa:/Applications/arduino-0011-644 iowa$ hardware/tools/avr/bin/avr-gcc --target-help

Target specific options:
 -msize                    Output instruction sizes to the asm file
 -mshort-calls             Use rjmp/rcall (limited range) on >8K devices
 -mno-tablejump            Do not generate tablejump insns
 -mtiny-stack              Change only the low 8 bits of the stack pointer
 -mcall-prologues          Use subroutines for function prologue/epilogue
 -mno-interrupts           Change the stack pointer without disabling interrupts
 -mint8                    Assume int to be 8 bit integer
 -mmcu=                    Specify the MCU name
 -minit-stack=             Specify the initial stack address

There are undocumented target specific options as well.
AVR options:
 -mmcu=[avr-name] select microcontroller variant
                  [avr-name] can be:
                  avr1 - AT90S1200, ATtiny1x, ATtiny28
                  avr2 - AT90S2xxx, AT90S4xxx, AT90S8xxx, ATtiny22
                  avr3 - ATmega103, ATmega603
                  avr4 - ATmega83, ATmega85
                  avr5 - ATmega161, ATmega163, ATmega32, AT94K
                  or immediate microcontroller name.
 -mall-opcodes    accept all AVR opcodes, even if not supported by MCU
 -mno-skip-bug    disable warnings for skipping two-word instructions
                  (default for avr4, avr5)
 -mno-wrap        reject rjmp/rcall instructions with 8K wrap-around
                  (default for avr3, avr5)
Known MCU names:
 avr1 avr2 avr3 avr4 avr5 at90s1200 attiny10 attiny11 attiny12 attiny15
 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22 attiny26
 at90s4433 at90s4414 at90s4434 at90s8515 at90s8535 at90c8534 at86rf401
 attiny13 attiny2313 atmega603 atmega103 at43usb320 at43usb355 at76c711
 atmega48 atmega8 atmega83 atmega85 atmega88 atmega8515 atmega8535
 atmega16 atmega161 atmega162 atmega163 atmega165 atmega168 atmega169
 atmega32 atmega323 atmega325 atmega3250 atmega64 atmega128 atmega645
 atmega6450 at90can128 at94k
 no emulation specific options.
Title: Re: Ok, on to Atmega32
Post by: mazx on Jun 25, 2008, 09:40 pm
Hmm... looks like MAC arduino-0011 distro has a different avr-gcc build.

Yeah, you may have to rebuild your GCC then.
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jun 25, 2008, 09:53 pm
update:  i may have gotten it working!!!

i downloaded and installed the awesome AVR MacPack from here: http://www.obdev.at/products/avrmacpack/index.html

it installs into a directory like: /usr/local/AVRMacPack

i nuked the arduino-0011/hardware/tools/avr folder and copied over the /usr/local/AVRMacPack (renaming it avr, so that it matches the old path setup)

that combined with the updated 'arduino core' files allowed me to successfully compile a blank sketch.  i dont have my prototype board here with me to fully test stuff, but it successfully complied.

yay!
Title: Re: Ok, on to Atmega32
Post by: mazx on Jun 25, 2008, 09:57 pm
Good staff!  :)

I'm glad you got it working and paved the way for other Mac users.  ;)

Kewl!!!
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jun 26, 2008, 04:47 pm
i managed to get it working!  i wrote a sketch in arduino, uploaded it via a usbtiny programmer, and it works =)  well, sort of.  there are still some things that need doing, and i need to figure out how to burn the fuses to set up the chip properly.  its not using the external oscillator and jtag is enabled (which i think is why the 4 jtag pins arent working)

check the video:

http://vimeo.com/1237093
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jun 29, 2008, 01:48 am
Yo.

Just spent all day hacking on the atmega644 code.  here is the status:

* got fuses configured correctly, and got all digital i/o pins working correctly with arduino libraries (digitalRead/Write, pinmode, etc.)
* got pwm stuff 100% working
* got serial stuff working
* updated attachinterrupt, needs testing
* updated analogRead, needs testing

we then moved onto the bootloader.  we got it to recompile and uploaded it to the atmega644.  things went okay, until we tried to upload via serial port.  at first, we got this error:

Yikes!  device signature error (and the received signature was #000000)

we managed to fix this by copying the old avrdude and avrdude.conf from the standard arduino-0011-mac.  however, then we started failing with this message:

avrdude: verification error, first mismatch at byte 0x0000
        0x0c != 0xff
avrdude: verification error; content mismatch

when we run the command that generates this in full verbose mode, it appears all the data is coming back as 0xFF.  this leads me to believe that our read and/or write portion of the bootloader is broken.  unfortunately i dont really understand assembler, and i am obviously lost when it comes to debugging that portion.

you can find all of our latest progress here: http://svn.nycresistor.com/projects/megarduino/code/

it contains our boards.txt with our fuses (could that possibly be wrong?)
it also contains the megarduino core as well as the latest version of our bootloader.

if anyone has any suggestions or is capable of checking/porting the bootloader to the atmega644, we would love your help.  if you send us code, we'll try it out and post back the results.

cheers,
Zach
Title: Re: Ok, on to Atmega32
Post by: potaton0 on Jun 29, 2008, 02:35 am
Here's the verbose output of avrdude if that helps.  I have to link it since I can only go to 5500 chars here.

http://www2.justinday.com/avrdude.txt

             
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 07, 2008, 06:56 pm
Zack,

I just checked the link and got HTTP 404 error.  :o

Can you please update the link?

It's nice to hear that you got things going. Kewl staff.


Andre
Title: Re: Ok, on to Atmega32
Post by: michelef on Jul 08, 2008, 05:13 am
Andre,

I'm not sure what happened to Zach server, so I put up my version of the files here:

http://macjordomo.fuortes.net/atmega644/

if you copy the two atmega644 folders in cores and bootloaders in the hardware folder and append_to_board.txt to board.txt file you should get a new board menu called atmega644 in the Arduino IDE.

A few notes:

This is working on a DevBoard-32 with a Atmega644 and a 16 MHz resonator. It connects to my Mac with a Arduino Mini USB Adapter with the DTR connected to the reset pin by a 100 nano-farad capacitor and a 10K pull-up resistor (as per the Diecimila). It's working well and i can upload the sketches straight from the Arduino IDE after having uploaded the bootloader once (the Devboard-32 came with a different one) with a USBTiny connector.

Most of the code in the "core" folder is the Arduino original as changed by robotcraft.ca (without all the conditinals). Zach made most changes and I made some in the pinouts (due to my choice of board).
The bootloader was modified and made working by Zach  (I made extremely little changes). The boot loader hex file is currently compiled for a 16 Mhz external clock and a 3 seconds delay after reset before starting the sketch. The delay is plenty with the setup as above in which the reset is started by the Arduino IDE.  If you need to change these two things (e.g.manual reset, different clock) you can change two variables in the Make file of the bootlader. Change the AVR_FREQ to your clock frequency and the -DMAX_TIME_COUNT to a higher value (with 1/4 of AVR_FREQ is about 3 secs) to increase the delay. Also change the atmega644.build.f_cpu=16000000L value in the boards.txt


Also the current baud rate is 57600, it seems to work well if you have problems you can decrease it to 19200 by changing the 57600 both in the boards.txt and the bootloader .c file.

Make sure you look at pins_arduino.c because currently the "logical" pin in Arduino do not correspond to physical pin in the ATmega644 and that's where the correspondence is dictated. I'm currently working on a new board with a ATMega644 which would keep the same physical and logical pinouts of the Diecimila so you could just pop in shields and sketches and have it working. (Current code name is Quarantamila)

Finally if your clock is not external you might also need to change the fuses setup in boards.txt. I got them wrong at the beginning and my  

digitalWrite(ledPin, HIGH);    // sets the LED on
delay(1000);                       // waits for a second
digitalWrite(ledPin, LOW);    // sets the LED off

was taking about 16 seconds to turn off!!

(I apologize if most of these instructions were already clear to you, but ........ just in case  ;)

Michele


Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jul 08, 2008, 04:58 pm
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!
Title: Re: Ok, on to Atmega32
Post by: kg4wsv on Jul 08, 2008, 05:11 pm
cool!  Several of the guys around here like the 644.

Will this be merged into the Arduino distribution?

-j

Title: Re: Ok, on to Atmega32
Post by: JAy1st on Jul 08, 2008, 08:41 pm
Great  [smiley=tekst-toppie.gif]
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jul 11, 2008, 09:32 pm
Quote
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!
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 13, 2008, 12:30 am
Hoeken,
Can you tell me does the IDE compile the bootloader for the atmega644? Under which conditions?
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 14, 2008, 05:33 pm
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
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 14, 2008, 05:44 pm
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.
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 14, 2008, 05:48 pm
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.
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 14, 2008, 05:48 pm
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.
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 14, 2008, 06:01 pm
Quote
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?
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 14, 2008, 06:06 pm
My atmega644 clock is 16mhz,crystal controlled.
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 14, 2008, 06:37 pm
Quote
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:
Code: [Select]

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.
Code: [Select]

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
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 14, 2008, 06:42 pm
Thanks Mazx!
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jul 15, 2008, 06:00 pm
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
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jul 15, 2008, 06:08 pm
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.
Title: Re: Ok, on to Atmega32
Post by: mellis on Jul 15, 2008, 07:44 pm
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.  
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 15, 2008, 09:14 pm
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
Title: Re: Ok, on to Atmega32
Post by: mazx on Jul 15, 2008, 09:16 pm
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.

Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jul 15, 2008, 11:07 pm
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).
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Jul 15, 2008, 11:12 pm
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.
Title: Re: Ok, on to Atmega32
Post by: michelef on Jul 16, 2008, 10:33 am
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).




Title: Re: Ok, on to Atmega32
Post by: mellis on Jul 16, 2008, 05:02 pm
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.
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 16, 2008, 11:13 pm
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?
Title: Re: Ok, on to Atmega32
Post by: michelef on Jul 17, 2008, 07:05 am
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.
Title: Re: Ok, on to Atmega32
Post by: hotcarrier on Jul 18, 2008, 05:13 pm
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?
Title: Re: Ok, on to Atmega32
Post by: michelef on Jul 19, 2008, 03:30 am
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.
Title: Re: Ok, on to Atmega32
Post by: no13 on Aug 26, 2008, 02:03 pm
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
Title: Re: Ok, on to Atmega32
Post by: aballen on Aug 26, 2008, 11:18 pm
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.
Title: Re: Ok, on to Atmega32
Post by: no13 on Aug 27, 2008, 11:59 am
Quote
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.  
Title: Re: Ok, on to Atmega32
Post by: mazx on Aug 27, 2008, 04:08 pm
Quote
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
Title: Re: Ok, on to Atmega32
Post by: Hoeken on Sep 03, 2008, 07:30 pm
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
Title: Re: Ok, on to Atmega32
Post by: penguinman on Aug 14, 2010, 05:04 am
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
Title: Re: Ok, on to Atmega32
Post by: speeedy on Aug 17, 2010, 01:24 pm
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
Title: Re: Ok, on to Atmega32
Post by: msproul on Aug 17, 2010, 11:59 pm
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