I would say to go ahead and call it a 644p.
There are known errors in avr-libc for 644 (SIGNATURE_2 is wrong, for one); I suspect that they made the 644a the same as the original 644, which only had one UART.
(and: bad move on Atmel's part, to have the same signature for devices with that magnitude of HW difference! Grr.)
Yes, forgot to mention another file to edit as a workaround.
Edit the file under arduino-1.0.4\hardware\tools\avr\etc\avrdude.conf.
Look for this definition:
#------------------------------------------------------------
# ATmega644P
#------------------------------------------------------------
# similar to ATmega164p
part
id = "m644p";
desc = "ATMEGA644P";
has_jtag = yes;
stk500_devcode = 0x82; # no STK500v1 support, use the ATmega16 one
avr910_devcode = 0x74;
signature = 0x1e 0x96 0x0a;
change the signature to:
signature = 0x1e 0x96 0x09; #Temp fix for ATmega644A signature.
Of course remember to change it back if you ever plan to use an ATmega644P chip.
Thank you sir! Let me try that and report back to you.
...A couple of minutes later: It Works!!!. Finally after almost a week of frustration messing around with file settings and my breadboard setup, I can now receive AnalogInput data from a set of Xbee RF modules!!!
For Christ sake, Arduino should suport Sanguino, but since that's not happening any time soon. I wish I would have gotten an ATmega644P but sadly where I'm now availably and some times price is an issue.
Thank you so much for helping me out. Never thought people here would reply so promptly and lead me the right way. Thank you for your valuable and appreciated help in this regard.
I wish I could at least buy you a cup of nice Java.
For Christ sake, Arduino should suport Sanguino, but since that's not happening any time soon. I wish I would have gotten an ATmega644P but sadly where I'm now availably and some times price is an issue.
I'm a 644P and 1284P fan myself, but to expect the arduino company to support chips and boards that they don't develop, build, or sell would be a nightmare of added support for them with little payback. Also there are maybe hundreds of different variations of AVR chips and boards made by 3rd party manufactures and to expect the arduino folks to pick and choice which they might 'officially support' or not in their IDE is an impossible task for them to take on.
I think it's enough that the arduino IDE developers have included 'software hooks' into the IDE making it a relatively easy task for 3rd party board manufactures to develop the files needed to support their version of boards into the arduino IDE.