Go Down

Topic: atmega328-mmh and arduino? (Read 770 times) previous topic - next topic

doov

I recently spun a board with an atmega328-mmh.  I'm trying to program it with the ISP.  I modified the avrdude.conf file so that the device signature would match that of atmega328-mmh (and not the default atmel part on the uno board).  The arduino IDE claims that everything programmed fine.

First thing I'm trying to do is just blink an LED -- it's not functioning (the code is fine/works on other arduino boards).  I'm wondering how the arduino ide handles different chip packages.  For example my led is on pin 11 of the 328-mmh, which corresponds to PB1.  PB1 on the 32 pin MLF part is pin 13.  Does the IDE/compiler translate the I/O (e.g. Arduino pin 9) to PB1 or does it need to know something about the physical pin assignments on the atmel part?  In other words can I even program the 328-mmh by faking an Uno board or are all the I/O assignments going to be botched?  Thanks!

D

doov

Sorry for the duplicate post -- slow internet + browser forward/back don't mix well.

CrossRoads

Pins_arduino.h is used for any '328 port to software naming.
The software does not care about the physical package - the die inside the part is the same.
So PB5 will map to what the software thinks is D13, no matter what actual physical pin it goes to - 19 on a 28-pin DIP, 17 on a 32-pin TQFP or MLF, 15 on a 28-pin MLF.

I'll delete the duplicate post.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

doov

Thanks a lot for the reply (and for deleting the duplicate post)!  Turns out that I apparently had a cold solder joint (that package is pretty small for hand soldering).  I now successfully blink an LED though I observe that delay(n) results in a delay that's actually 16n.  So delay(10) results in a delay that's 160 mS.  I'm using the same resonator that's found on the uno (murata CSTCE16M0V53-R0).  Some more debugging is probably needed, but it would seem that the arduino is operating at 1 MHz and not 16 MHz -- or at least that's an obvious theory.  Are there any particular reasons that this behavior would be exhibited?  I can't see how any timing registers would have changed.  Thanks!

D

fungus


Thanks a lot for the reply (and for deleting the duplicate post)!  Turns out that I apparently had a cold solder joint (that package is pretty small for hand soldering).  I now successfully blink an LED though I observe that delay(n) results in a delay that's actually 16n.  So delay(10) results in a delay that's 160 mS.  I'm using the same resonator that's found on the uno (murata CSTCE16M0V53-R0).  Some more debugging is probably needed, but it would seem that the arduino is operating at 1 MHz and not 16 MHz -- or at least that's an obvious theory.  Are there any particular reasons that this behavior would be exhibited?  I can't see how any timing registers would have changed.  Thanks!


What clock source did you select when you set the fuse bits?

Try doing a "burn bootloader".
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

CrossRoads

Yes, burn bootloader first to set fuses for Uno like operation.
Then re-upload.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

doov

Thanks so much for the fast replies!  I will try that later this weekend when I've got the HW in front of me.  Much appreciated guys!

D

doov

Burning the bootloader was the solution.  Thanks for the help.

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy