Motherboard v1.2: atmega644 vs atmega644P [solved]

Hi folks,

i am having some challenges getting the firmware installed on my rmb-1.2.

After quite a while of troubleshooting on my own, I realized that when I assembled my rmb-1.2, I soldered in an atmega644 (device signature = 0x1e9609) instead of an atmega644p (device signature = 0x1e960a). Not on purpose of course - Digi-Key sent the wrong chip, the invoice did not match the package contents, and i didn't realize this until now.

Now given that these chips appear to be almost identical, i somewhat hope that i am not as screwed as i first thought (at least with some help) :-)

The challenge I believe I already solved:

• modifying boards.txt to point to "ATmegaBOOT_644.hex" for the sanguino.bootloader.file, and changing sanguino.build.core remove the "p".
• burning the bootloader with this modification (using USBtinyISP and Arduino 0017)

However, I can't seem to be able to compile and upload the Sanguino Master Firmware because of the sanity check in SanguinoMaster.pde:

#ifndef __AVR_ATmega644P__
#error Oops!  Make sure you have 'Sanguino' selected from the 'Tools -> Boards' menu.
#endif

If I change this to __AVR_ATMega644__, verification starts but then fails with "error: 'Serial1' was not declared in this scope":

C:\Users\reprap\AppData\Local\Temp\build6219.tmp\/RS485.h: In function 'void rs485_tx(byte)':

C:\Users\reprap\AppData\Local\Temp\build6219.tmp\/RS485.h:16: error: 'Serial1' was not declared in this scope

 In function 'void init_serial()':
error: 'Serial1' was not declared in this scope In function 'bool read_tool_response(int)':

Does anyone have hints as to how I might get around hot air rework and putting the atmega644p onto my board instead?

TIA,
-volty

Edited 3 time(s). Last edit at 11/21/2009 01:48AM by volty.

May Help

Migrating from Atmega644 to Atmega644p

For removing the chip there is a special Desoldering solder "Chip Quick".

[www.curiousinventor.com]

Another approach is simply use a dremel tool (very, very carefully) to cut the leads off of the current chip and then remove the left behind pins with flux and solder wick before soldering on the new chip.

For home made hot air rework tools check the following links:

[www.engadget.com]

[www.gideontech.com]

[www.dansworkshop.com]

Note the second link talks up front about removing a complex part.

Edited 1 time(s). Last edit at 11/12/2009 11:36AM by freds.

I am a bit confused.

I do have access to a hot air rework station and I know how I can de-solder the 644 and put the 644p in. It's just that I don't wanna do it unless the lack of the 2nd USART in the 644 poses an insuperable hardware limitation -- and I couldn't really find anyone who could confirm that it is.

Here's one of the reasons why I haven't given up yet - quote from [sanguino.cc]: "[...]the atmega644P [...] is identical in nearly every aspect to the atmega644, except it contains an additional serial USART. Unfortunately you will not have access to this."

Does this mean that we can't use the 2nd USART on the atmega644p? (if yes, this would mean that i do not have a hardware limitation and should be able to run my motherboard with the atmega644)

Or just that I can't use the 2nd USART on the atmega644 because it is not present there (stating the obvious)? (in which case I still don't know whether I actually need it)

I am still learning, and would appreciate any assistance in better understanding how we use these UARTS / serial ports

Thx,
-volty

Hi Volty

I spent a couple of hours on this (sucked me into the vortext) and it appears that you have to have a new core compile for the different processors under Arduino IDE.

It appears that Zach when he designed the Sanguino used RobotCraft's code for the 644 processor as a base when transitioning to the 644P.

RobotCraft's code for their "Arduino IDE ATMega 48/324/32/644 Patch" can be downloaded at:

[www.robotcraft.ca]

[www.robotcraft.ca]


This might give you a starting point to be able to compile. I am not sure if there are any other differences like clock speed, which could result in the serial port operating at the wrong baud rate.

If you can work out the rest of the details then the DIP version of the 644 is much more available then 644P for people who wish to breadboard a controller.

Edited 1 time(s). Last edit at 11/14/2009 05:25PM by freds.

if the only difference is the 2nd uart, you should be able to replace all occurrences of USART0 with USART in the firmware, then recompile and run. If you find an occurence of USART1, you may need the 2nd uart after all.

avr-libc calls them USART0, USART1, etc when there's many, but just USART if there's only one. You could potentially even redefine USART0* USART* and compile successfully, and you would get errors about USART1 if it's used anywhere

Thanks all. Yeah, it seems I am not going to be able to avoid having to put a 644P in.

While USART is not the object used in the firmware (serial is), I see both serial and serial1 being used.

From SanguinoMaster:

//start our hardware serial drivers
void init_serial()
{
  pinMode(RX_ENABLE_PIN, OUTPUT);
  pinMode(TX_ENABLE_PIN, OUTPUT);
  digitalWrite(RX_ENABLE_PIN, LOW); //always listen.

  Serial.begin(HOST_SERIAL_SPEED);
  Serial1.begin(SLAVE_SERIAL_SPEED);
}

One of them seems to talk to the host (my machine) and the other seems to talk to the slaves (extruder drivers).

Oh well. Anyway, thanks all for the good info, links and motivation
-volty