Go Down

Topic: ATmega1284P: End to End using 1.0 IDE (Read 81305 times) previous topic - next topic

CrossRoads

It resets just fine. I have seen no signs of hanging with the multiple bootload downloads. Its the serial downloads I can't get working.

Hmm, the AVR ISP connects to Reset pin directly.
The FTDI Basic goes thru a cap.
Will try FTDI Basic without the cap.
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.

CrossRoads

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.

CrossRoads

#152
Feb 14, 2012, 04:05 am Last Edit: Feb 14, 2012, 04:08 am by CrossRoads Reason: 1
I am just sooooo frustrated.
I pulled the '328 from my Duemilanove, wired up +5/Gnd/Reset/Tx/Rx to my 1284.
Downloaded this sketch via "Upload Using programmer" & confirmed both Serial ports work.
Code: [Select]

byte pin1 = 4;
byte incomingByte1='a';
byte incomingByte2='b';

void setup(){
 pinMode (pin1, OUTPUT);
 Serial.begin(9600);
 Serial1.begin(9600);
}
void loop(){
 if (Serial.available()>0){
   incomingByte1 = Serial.read();
Serial.write(incomingByte1);
 }
 if (Serial1.available()>0){
   incomingByte2 = Serial1.read();
   Serial1.write(incomingByte2);
 }
digitalWrite(pin1, HIGH);
delay (100);
digitalWrite(pin1, LOW);
delay(100);
}[code]
confirmed both serial ports are working.
Reloaded a bootloader:
[code]
        Programmer Type : usbasp
        Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9705
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
        To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: auto set sck period (because given equals null)
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "C:\Arduino-1.0\hardware\mighty-1284p-slow\bootloaders\optiboot\optiboot_atmega1284p_slow.hex"
avrdude: writing flash (130554 bytes):

Writing | ################################################## | 100% 73.05s

avrdude: 130554 bytes of flash written
avrdude: verifying flash memory against C:\Arduino-1.0\hardware\mighty-1284p-slow\bootloaders\optiboot\optiboot_atmega1284p_slow.hex:
avrdude: load data flash data from input file C:\Arduino-1.0\hardware\mighty-1284p-slow\bootloaders\optiboot\optiboot_atmega1284p_slow.hex:
avrdude: input file C:\Arduino-1.0\hardware\mighty-1284p-slow\bootloaders\optiboot\optiboot_atmega1284p_slow.hex contains 130554 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 70.50s

avrdude: verifying ...
avrdude: 130554 bytes of flash verified
avrdude: reading input file "0x0F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.02s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0F:
avrdude: load data lock data from input file 0x0F:
avrdude: input file 0x0F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude done.  Thank you.

And yet I still can't download via the serial port!
Code: [Select]

####avrdude: Send: U [55] . [00] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [01] . [00] F [46] p [70] . [e0] . [0e] . [94] . [b5] . [03] . [08] . [95] . [1f] . [92] . [0f] . [92] . [0f] . [b6] . [0f] . [92] . [11] $ [24] / [2f] . [93] ? [3f] . [93] . [8f] . [93] . [9f] . [93] . [af] . [93] . [bf] . [93] . [80] . [91] . [18] . [01] . [90] . [91] . [19] . [01] . [a0] . [91] . [1a] . [01] . [b0] . [91] . [1b] . [01] 0 [30] . [91] . [1c] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] # [23] / [2f] - [2d] _ [5f] - [2d] 7 [37]   [20] . [f0] - [2d] W [57] . [01] . [96] . [a1] . [1d] . [b1] . [1d]   [20] . [93] . [1c] . [01] . [80] . [93] . [18] . [01] . [90] . [93] . [19] . [01] . [a0] . [93] . [1a] . [01] . [b0] . [93] . [1b] . [01] . [80] . [91] . [14] . [01] . [90] . [91] . [15] . [01] . [a0] . [91] . [16] . [01] . [b0] . [91] . [17] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [80] . [93] . [14] . [01] . [90] . [93] . [15] . [01] . [a0] . [93] . [16] . [01] . [b0] . [93] . [17] . [01] . [bf] . [91] . [af] . [91] . [9f] . [91] . [8f] . [91] ? [3f] . [91] / [2f] . [91] . [0f] . [90] . [0f] . [be] . [0f] . [90] . [1f] . [90] . [18] . [95] . [9b] . [01] . [ac] . [01] . [7f] . [b7] . [f8] . [94] . [80] . [91] . [14] . [01] . [90] . [91] . [15] . [01] . [a0] . [91] . [16] . [01] . [b0] . [91] . [17] . [01] f [66] . [b5] . [a8] . [9b] . [05] . [c0] o [6f] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [7f] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [86] . [0f] . [91] . [1d] . [a1] . [1d] . [b1] . [1d] b [62] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] j [6a] . [95] . [d1] . [f7] . [bc] . [01] - [2d] . [c0] . [ff] . [b7] . [f8] . [94] . [80] . [91] . [14] . [01] . [90] . [91] . [15] . [01] . [a0] . [91] . [16] . [01] . [b0] . [91] . [17] . [01] . [e6] . [b5] . [a8] . [9b] . [05] . [c0] . [ef] ? [3f]   [20]
avrdude: Recv:

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: Send: V [56] @ [40] . [00] . [00] . [0c]   [20]
avrdude: Recv:
avrdude: stk500_cmd(): programmer is out of sync
[/code][/code]
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.

retrolefty

Got to be something in the bootloader code or timing problems working with AVRDUDE?

Lefty

CrossRoads

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.


Swapped Rx & Tx just in case:
Code: [Select]


         Programmer Type : Arduino
         Description     : Arduino
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: Send: V [56] @ [40] . [00] . [00] . [0c]   [20]
avrdude: Recv:
avrdude: stk500_cmd(): programmer is out of sync



Hang on...  This is progress!  In previous tries, there was NO communication.  This tells us that the rx/tx were backward previously.  Now we can try to figure out why it's hanging here.  Did you try the 28800 bootloader with THIS rx/tx configuration?

CrossRoads

Yes, those are the 28800 results.  I thought I had copied more of it.
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.

Does it always stop uploading in the same place?  That is, if you did it 10 times and captured the verbose output each time, would that output be all different, all the same, or some same/some different?

CrossRoads

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.

cowasaki

I think I might be suffering the pins not being nailed down issue with trying to get the GLCD library to work.

I have a board sat here and running Arduino v1.0 using ManiacBug's instructions. 

I have started a thread on the issue in the LCD section (http://arduino.cc/forum/index.php/topic,91961.msg690725.html) but I think it might be down to pins not being where they should be.

Has anyone got GLCD working on ManiacBug 1284p chips ?

Really hoping for official support for this chip...

bperrybap


I think I might be suffering the pins not being nailed down issue with trying to get the GLCD library to work.

I have a board sat here and running Arduino v1.0 using ManiacBug's instructions. 

I have started a thread on the issue in the LCD section (http://arduino.cc/forum/index.php/topic,91961.msg690725.html) but I think it might be down to pins not being where they should be.

Has anyone got GLCD working on ManiacBug 1284p chips ?

Really hoping for official support for this chip...


I touched on this briefly in the GLCD thread above, but in my opinion,
one of the big problems/difficulties with getting new processors and boards
supported is the way the Arduino team has
implemented the development environment with the IDE.

i.e. The IDE has certain knowledge about the target that it does not share

A big problem is that the core and now this new variant information in 1.0
is unknown by anything but the IDE.
There are times when the code being compiled could take advantage of this information
or in some cases actually need to know which core and which variant of that core is being compiled.

Without this kind of information you can get forced into having to duplicate code or entire
directories of code just to be able to build the code slightly differently because of something as trivial
as pin mapping differences between variants of the same core because the core code can't
tell which variant the code is being compiled for.

In the case of the glcd library it needs to be able to know this information to be able to properly
map Arduino pins to direct port i/o pins. As it is today, the glcd library does not have access to anything
but the processor type, which simply is not good enough when there are multiple variations of that core
that have different pin mappings.
glcd needs this because it not only maps Arduino pins to direct port i/o but by being able to look
at the individual Port and bit numbers of each Arduino pin it can tell which of the 8 data lines are adjacent
to each other and in which order and use that information to convert to using nibble and bytes
with direct port writes as well when the chosen pins allow it.
And since this is all this is done at compile time, the glcd code must know the exact pin mapping information
which can only be known if you know the core and variant.
(processor type really isn't needed if you know the core and variant)

Teensy helps solve some of this by defining a few core defines so that it is possible to tell the difference between
Teensy and Leonardo, but if Teensy headers didn't create these core defines, there would be no way to tell them apart.
Since the Arduino to port/bit mappings are different between Teensy and Leonardo, it can be critical
in some cases to know which one you are using.

The solution to all of this is along the lines of what Paul asked for some years ago and that is to
communicate the core (and now the variant) information to the code being compiled.

There needs to be defines for both of these pieces of information that are available to the
modules being compiled so that if needed they can uniquely identify the target.

mpide has some additional/better capabilities than the Arduino IDE that can help in this area.
mpide allows setting per board compiler defines in the board.txt file

There are several different ways that this could be handled.
The exact method of doing it isn't that important, what is more important
is the information itself.

Ideally the cpu/board/core/variant values could each be defined using either
well known names or each assigned to well known define names.

This should be an easy issue to solve and it does not have to involve
waiting for the Arduino team to do anything.
(Core and Variant defines could be added to the variant header files)

If we could get consensus on the information which is only 2-3 define values
(CPU is already defined) and how they should be defined, then all the 3rd party cores
could start to use it in their variant files without having to wait on any support
from the official Arduino code.

--- bill






This is all true.  Yet, you can be sneaky and discover the pin mappings, just by inspecting the arrays that pins_arduino defines.  As you say, "it needs to be able to know this information to be able to properly map Arduino pins to direct port i/o pins."  Well that is exactly available in the pins_arduino arrays.

bperrybap


This is all true.  Yet, you can be sneaky and discover the pin mappings, just by inspecting the arrays that pins_arduino defines.  As you say, "it needs to be able to know this information to be able to properly map Arduino pins to direct port i/o pins."  Well that is exactly available in the pins_arduino arrays.



I don't think that works for my use.

Yes I can look at it any given variant header file with my human eyes and easily figure it out the mapping,
and create my needed conversions, which I already have done for all the processors the glcd library supports.
but that doesn't help my glcd code during compile time figure out which specific variant
is being used to know which conversions to use when there are different mappings for the same
processor.

i.e. there are multiple variants with the same processor type that have different pin mappings.

The problem is the code being compiled currently does not know the board, core, or variant.
It only knows the processor type.

I also have to be able to detect if multiple Arduino pins are sharing a port and if they
are in a certain order within that port.

For example, if I have an arduino pin number lets say 24,
I need to know the memory address of the AVR port and the bit number assigned to that AVR pin
at compile time to be able to detect if it is in the proper bit location along with other 7 Arduino pins
to do nibble or byte accesses.

Some 1284 variants map Arduino pin 24 to bit 0 of PORT A and some map it to bit 7 of PORT A.
In order to get the best glcd performance (byte port accesses), the glcd data bits have to perfectly align
with the PORT bits because the glcd library is not working at the pin level, it is optimizing
across all 8 pins used for the data.
glcd can even do nibbles or 2 nibble across different ports.

I have 1000+ lines of some pretty complex macros and inline functions
that can collapse everything down to the minimal AVR instructions to update 8 pins
which can be as little as a single AVR instruction.
All this is done at compile time if all the conditions are met based on knowing the port memory addresses and
bit numbers of the 8 Arduino pins used used in the glcd library for the data lines.

Having core and variant information would allow the glcd code to select the proper pin mappings
from its internal mappings to ensure all the information is known at compile time
when there are cases of different pin mappings for the same processor type.

Do you know of a way to do this using the existing the progmem data arrays?
If you do, I'm all ears.
I don't know how to get at the data in the progmem array at compile time.

--- bill



Do you know of a way to do this using the existing the progmem data arrays?
If you do, I'm all ears.
I don't know how to get at the data in the progmem array at compile time.


Just have a look at the source for wiring_digital.c, shows you how to do it right there.

Code: [Select]

        uint8_t bit = digitalPinToBitMask(pin);
        uint8_t port = digitalPinToPort(pin);

bperrybap



Do you know of a way to do this using the existing the progmem data arrays?
If you do, I'm all ears.
I don't know how to get at the data in the progmem array at compile time.


Just have a look at the source for wiring_digital.c, shows you how to do it right there.

Code: [Select]

        uint8_t bit = digitalPinToBitMask(pin);
        uint8_t port = digitalPinToPort(pin);



That won't work.
You didn't dig deep enough.
Have a look at Arduino.h
Those "functions" are macros that are defined as follows:
Code: [Select]
#define digitalPinToPort(P) ( pgm_read_byte( digital_pin_to_port_PGM + (P) ) )
#define digitalPinToBitMask(P) ( pgm_read_byte( digital_pin_to_bit_mask_PGM + (P) ) )


They use pgm_read_byte() to access/lookup the data from progmem.
While that works at run time, you cannot do this to get the information at compile time.

I need the information at compile time.

--- bill


Go Up