Ok, on to Atmega32

Congrats, well done!

Now, on to Atmega32?

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.

Any update on this?

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.

You can edit your posts by clicking the 'modify' button at the top of the post (right side of screen).

Thanks for the update!

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!

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.

With my next shipment from Futurlec I'll grab a handful of assorted Atmel chips and see what I can do with them. :slight_smile:
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.

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 :frowning: , but at the end I decided to make the timer definitions only for atmega 16 because i was too confused.

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 :frowning: , 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:

I use Beyond Compare for windows, great application.

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.

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.

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

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

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

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.

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.

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.

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

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