next topic »

[Reply #30 on:]

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

[Reply #31 on:]

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.

[Reply #32 on:]

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.

[Reply #33 on:]

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.  

[Reply #34 on:]

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'"

>


 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.

[Reply #35 on:]

Dalek,

What version of Arduino IDE are you using?

[Reply #36 on:]

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

[Reply #37 on:]

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

[Reply #38 on:]

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?

[Reply #39 on:]

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.

[Reply #40 on:]

Hmm... looks like MAC arduino-0011 distro has a different avr-gcc build.

Yeah, you may have to rebuild your GCC then.

[Reply #41 on:]

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!

[Reply #42 on:]

Good staff!  

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

Kewl!!!

[Reply #43 on:]

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:

[Reply #44 on:]

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