ATmega1284P: End to End using 1.0 IDE

What happens when you connect to the correct chip?

Well, this will cause some laughs...

The UNO shares the ICSP pins with Pin13, 12, 11, so if one wants to program via ICSP, please: disconnect any I/O cables/sensor/etc. from pins 13, 12 and 11.

It that simple!
I was changing the boards, but connecting the exactly same cables to the same pins, so no way.
Hope it can help to anybody.

Yes, if external devices were driving those pins while you were programming, that would be a problem.

In short: is USBasp enough to correctly bootload the 1284 (P and non-P) ? I have the one based on an Atmega8A, which I have successfully used to bootload a countper Atmega328 (non-P, so I had to edit avrdude.conf).

svalls:
Ok, I have now more info:
The signature corresponds to the MEGA16U2, so I am connected to the wrong chip.

Any ideas?

The are 2 ICSP headers in the Rev. 3 boards. Make sure you connect to the one farthest from the USB connector.

I don't believe the USBASP based on Atmega8 will program the full address range of the '1284.

NickGammon has nice writeups on using an Arduino as ISP including '1284s.

I use an Atmel AVR ISP MKii myself.
Set up the 1284 core files here

I install a bootloader so the fuses are set right, then use File:Upload using Programmer to upload a sketch if I'm not uploading via the Serial port.

Just a question: is the Optiboot 4.5 available in the Mighty-1284 core able to write over the whole memory of the 1284P (due to the fact that it has 128 kB of Flash)? I think it is, just because the bootloader is written in the higher part of the Flash and it's running fine on my chip... :sweat_smile:

I don't know - I use
optiboot_atmega1284p.hex

The 1284 shouldn't have major size issues; it has 64kwords of flash, and most of the serious difficulties happen when you go beyond 64k (note that 64k words == 128kbytes.)

westfw:
The 1284 shouldn't have major size issues; it has 64kwords of flash, and most of the serious difficulties happen when you go beyond 64k (note that 64k words == 128kbytes.)

Yeah, 64 kW = 128 kB.
I supposed that it didn't have issues, thanks :wink:

CrossRoads:
I don't believe the USBASP based on Atmega8 will program the full address range of the '1284.

actually usbasp has no problem there. ive been using them last couple years for bootloader development with m128 and more recently m1284. its the worlds most popular choice now and my favorite. considering they are only 2 or 3 bucks on ebay i can buy a dozen with enough left over for a handful of avr chips all for less than the price of one mkII. imo dragon would be the next step up with its superior debug and 12v capabilities.

john1993:

CrossRoads:
I don't believe the USBASP based on Atmega8 will program the full address range of the '1284.

actually usbasp has no problem there. ive been using them last couple years for bootloader development with m128 and more recently m1284. its the worlds most popular choice now and my favorite. considering they are only 2 or 3 bucks on ebay i can buy a dozen with enough left over for a handful of avr chips all for less than the price of one mkII. imo dragon would be the next step up with its superior debug and 12v capabilities.

The dragon is nice, but there are a few issues with avrdude and the dragon.
Back to back avrdude commands will fail because avrdude resets the USB when it exits and the
dragon USB enumeration is not complete when the second avrdude command comes in which causes
avrdude to report that there is no dragon device on the USB.
Because of this issue, you can't use the Arduino IDE or the optiboot makefiles with
avrdude on a dragon to burn a bootloader.
I bugged it a few years ago. I've since patched my own avrdude to fix this.
(its like 4-5 lines of code)

--- bill

yes, and i want to thank you again for fixing my avrdude ff issues. it literally took 100x longer to upload that bootloader before. i agree about the windows/linux thing you brought up there too. unfotunately stuck in a wintel world.

not being a particularly fervent atmel studio fanboy i dont use the dragon that often. maybe couple times a year to revive some mis-fused basket cases. but since most avrdude operations can be done with multiple commands per line i dont see a problem there. why does arduino not do this? anyway i guess thats another argument in favor of usbasp.

Is this topic still alive?

In other words: are the 1284P boards still developed and compatible with the latest Arduino IDE's (1.05 and 1.5.x) ??

Hello.

I would like to ask Bob and Maniacbug about the pin-port relation.

I am using the UTFT library with a Bobuino board and from what i found up until now is that the UTFT library uses internal PORT instructions to send the data to the 8-bit data port (D0~D7) on UNO.

Arduino UNO uses PortD0~PortD7 directly with pins D0~D7, while bobuino uses PortD0~PortD3 for pins D0-D3 and PortB0-PortB3 for pins D4-D7.
I have managed to send the data output to these ports and have the LCD screen i'm using print everything correctly.

But PortB1-PortB5 are used with Digital pins 9-13 on Atmega328P and since i use some of these ports to send data to other pins, that seems to interfere internally with the output of the Digital Pins.

I found out that this is the problem by using correctly the SPI pins with a NRF24 module, but failing to use it correctly while running both RF24Network and UTFT. It actually does not work at all (no "network.available") or it works "just once", receiving a packet and sending one. And then nothing.

Having said all that, would it be smart to use Bobuino with the bootloader and settings for Mighty ATmega1284P "just to see what happens" or would it be easy to use internal port commands in order to "clear up" this mess?

@Bob, to ensure maximum compatibility with UNO you must use similar port-to-pin associations in pins_arduino.h
I believe it would not be obvious in general, but UTFT made it clear that that's a problem

@MarsWarrior,
Yes, for 1.0.5. Never tried with 1.5
http://www.crossroadsfencing.com/BobuinoRev17/


@fleshmachine,
I have no control over how a library, written for one device using hardware port specific callouts, vs using Digital pin names that are more general across devices, will work.

When I developed the Bobuino pinout 2+ years ago under -0023, I had never heard of UTFT. I wanted D0/D1 to match, I wanted D10-11-12-13 to match, I wanted SCL on A4/A5 to be able to match (my hardware designs allow the D18/D19 pins to be SCL/SDA, or D18/D19 with SCL/SDA on separate hardware pins). The rest I tried to connect logically, with the analog pin closest to the middle of the chip going straight to an adjacent header with A0 thus being closest to the power header.

I understand pins_arduino.h for 1.0.x better now, if you wanted to create your own pins_arduino.h it's not hard to do. In another thread we wer working the file for a '2561, which is like a slimmed down '2560 with 64 pins and I think 54 IO.
So:
328, 20 IO
1284, 32 IO
2561, 54 IO
2560, 84 IO (or however many the Mega brings out)

I wanted D0~7 to correspond to Port D pins 0~7. I tried repositioning pins as such:

D0-D7 ... PD0~7
D8 - PB0
D9 - PB1
D10 - PB4
D11 - PB5
D12 - PB6
D13 - PB7
...
(Port A and Port C are left untouched)
D30 - PB2
D31 - PB3

Here is my pins_arduino.h based on bobuino pins_arduino. I really have no idea how this file works so if you can take a look it will be really helpful.

pins_arduino.h (6.96 KB)

How is that different than the Mighty1284 variants that exist now?

You can't just change pins_arduino.h file to suit you needs. It has to match how the hardware pins are brought out to the headers. You are asking for a different hardware board to match the header functions.

hiduino:
You can't just change pins_arduino.h file to suit you needs. It has to match how the hardware pins are brought out to the headers. You are asking for a different hardware board to match the header functions.

True, found it out the hard way today..