ATmega1284P: End to End using 1.0 IDE

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..

CrossRoads:
@MarsWarrior,
Yes, for 1.0.5. Never tried with 1.5
Cross Roads Electronics


Thanx for the info. The first one is about 5x5cm I understand, but how big is the second one?

MarsWarrior:
Thanx for the info. The first one is about 5x5cm I understand, but how big is the second one?

UNO sized, maybe 1cm larger on the longer side

Little wider than Uno, I made room for names along the outside of the headers vs the inside.

USB/Serial adapter can be offboard for standalone projects, or MIKROE483 can be mounted onboard for USB connected projects.

example:

I'm not sure if this is the correct thread to post to, but I'm just trying to assess the impact of the structural changes to IDE1.6.2 which have moved the AVR compilor to a different location'

So unless the dev team for the Mega1280P have already updated their packages.txt file, its not going to work with 1.6.2

Moderator. Please move this if there is a more active 1280P thread,

The impact is minor. A few changes to platform.txt was all that was needed. A diff between the platform.txt that comes with the IDE and the platform.txt to be updated identifies the needed changes. The developer added much needed tag(s) that point to the correct new location(s). If you want a hand let me know.

@Coding Badly

yes. I've already worked out what to change in platform.txt, its the path to the compiler that's been moved.

Still a bit of a pit that this change means that the old platform.txt file before 1.6.2 is no longer compatible

So as soon as the master copy of the packages.txt is updated, anyone who wants to get an updated copy for whatever reason, is forced to update to 1.6.2 etc

Its actually more serious with some other boards I'm using, as the ARM compiler is nolonger installed by default.

So I have to install the Due in the boards manager, and also change platforms.txt to match the new ARM compiler location