ATMEGA1284P timing issue (delay function)

This is a brand new ATMEGA1284P-PU chip with a 16MHz external oscillator (crystal).

Much to my surprise :wink: it took the very first upload attempt of the blink sketch. My ponyser programmer happens to have a buffered LED on MOSI - PB5 pin, which maps to Arduino pin 13, so the 1284 started blinking.
But ever so slowly.... I timed 16 seconds for a delay(1000).

I didn't touch the fuses, they are all default, and I suspect this is my problem.

Apparently, the factory set fuse is for the "internal oscillator at 8MHz and fuse CKDIV8 set, resulting in a 1 MHz system clock".
Since Arduino runs at 16MHz and I seem to have a 1/16 ratio, my slower response seem to indicate that it does indeed run at 1MHz.

Would someone please confirm my evaluation?
Also, the 16MHz crystal and the two 22p caps are connected to pins 12 and 13, so it appears that it isn't being used and it doesn't cause any problems either, being connected and all.

Thank you for any info on this.

Your assessment is correct.

You need to do "burn bootloader" with an ISP programmer (I guess ponyser is ISP? ) in order to set the fuses to tell it to use the external crystal. Or set the fuses using AVRDude from the command line, or use a USBAsp with eXtremeBurner AVR)

I agree; you need to burn the bootloader, which will set the fuses.
Or, just set the fuses.

I'd recommend settings, but I don't seem to have a boards.txt here with a 1284P section I can look them up in.

Thank you very much gentlemen.

Bob, I know you created the Bobuino, which is 1284 based and I must say that you are the one that swayed me in favour of the 1284 as opposed to the 2560. The 328 is ... meh ... too small :slight_smile:

I have no immediate intention to burn a bootloader on it, for two reasons, it won't be programmed that often, so I will stick to the ponyser ISP and I will enjoy having most of the128K available.

I might just try hooking up a Prolific 2302 (or whatever it is) USB to serial to the RX TX pins and try programming it that way, apparently the 1284 does that?

So I will probably just stick to setting the fuses with the ponyser.

Thanks again DrAzzy and CrossRoads.

Burning the bootloader via ISP sets the fuses. You can then use ISP again to load your sketch, the fuses will not change.
"I might just try hooking up a Prolific 2302 (or whatever it is) USB to serial to the RX TX pins and try programming it that way, apparently the 1284 does that?"
You need a bootloader installed to do that, no matter which make of USB/Serial adapter you use.

CrossRoads:
"I might just try hooking up a Prolific 2302 (or whatever it is) USB to serial to the RX TX pins and try programming it that way, apparently the 1284 does that?"
You need a bootloader installed to do that, no matter which make of USB/Serial adapter you use.

Yes, thank you.

Update: I burned the fuses and it is now running happily at 16MHz with the crystal.

I was also able to upload a sketch that was over 26k, as I read that there could be issues if the boards aren't right. So far so good.

One more thing, I have seen several pins_arduino.h for this chip. I seem to favour the one for Bobuino, as it seems the closest to Arduino (Uno) as far as the pin mapping.
Any other opinions out there?

Thank you.

I favor the Bobuino too. Two votes, sounds unanimous so far 8)

That's 3 8)

Thanks gentlemen.

CrossRoads:
I favor the Bobuino too. Two votes, sounds unanimous so far 8)

You're not biased at all, eh? :wink:

One thing that puzzles me after mapping out the Uno/Nano pins with the Bobuino pins.h file though:
Why don't the ports match? 0 to 3 map the same way to PD0 to 3.
But 4 to 7 map to PB0 to PB3 on Bobuino and to PD4 to PD7 on Uno.
And the analog ones are PA7 to PA2 on Bobuino vs PC0 to PC5 on Uno.

For the best compatibility of sketches, wouldn't it be better to map all Uno ports the same on the 1284 and the new ones to whatever's left?

Thanks again.

I think he was trying to get the special functions of the pins to line up - since more people use the wrappers around the hardware functionality (for PWM, analogRead(), etc) than use direct port manipulation.

And the analog ones are PA7 to PA2 on Bobuino vs PC0 to PC5 on Uno.

You'll have to take that up with Atmel. The analog pins on the '328p are on PC0~5 plus two portless pins for A6/7 (SMD versions only), while on the '1284p, they're on PA0~7.

DrAzzy:
I think he was trying to get the special functions of the pins to line up - since more people use the wrappers around the hardware functionality (for PWM, analogRead(), etc) than use direct port manipulation.
You'll have to take that up with Atmel. The analog pins on the '328p are on PC0~5 plus two portless pins for A6/7 (SMD versions only), while on the '1284p, they're on PA0~7.

Thanks Doc. That makes sense, it's easier to map out pins while maintaining core functionality from libraries.

In case you do need bootloader, enable full-swing driver for your crystals. Otherwise the TX RX lines interferes with the oscillator enough to make the upload fail.

Yeah, I vote for bobduino pin mapping. I have an open source data logger design using this pin mapping.

@CrossRoads are you the author of the bobuino pins_arduino.h file or did maniacbug write that? The reason I ask is that the only variant with license information in the Mighty 1284P core is avr_developers which prevents me from adding bobuino pinout support for 2 different cores I'm working on without requiring the user to also install Mighty 1284P.

liudr:
In case you do need bootloader, enable full-swing driver for your crystals. Otherwise the TX RX lines interferes with the oscillator enough to make the upload fail.

Yeah, I vote for bobduino pin mapping. I have an open source data logger design using this pin mapping.

Thank you. No bootloader, this will become a permanent fixture once I am done with it, so I will just upload using the programmer.