ATmega128-working on a new board for myself, questions about ICSP header

Using Arduino Microcontrollers
1

OK, I'm working on a new ATmega128 board for myself. The hardware is pretty application specific but generally it's a radio controller.

I'm using the TQFP-64 package, and am laying out the board in EAGLE. Things were going well, until I realized I'd routed myself into a corner by trying to keep port assignments similar to the UNO R3. I have partial code already working on the R3, though it would be easier. It's not, so I gave up on that and am now using the ports more sensibly. I'll just have to reassign the LCD data and control lines instead of using the default stuff. The new layout actually is cleaner, AND I can fit all the bare-bones essentials onto a single-sided PCB. (basically leaving off the radio hardware, and putting it on a second board)

I am using MCUDude's (Hansibull?) MegaCore and bootloader, as found here: GitHub - MCUdude/MegaCore: Arduino hardware package for ATmega64, ATmega128, ATmega165, ATmega169, ATmega325, ATmega329, ATmega640, ATmega645, ATmega649, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega3250, ATmega3290, ATmega6450, ATmega6490, AT90CAN32, AT90CAN64 and AT90CAN128

Here's the issue-I'm laying out the ICSP header, and realize that his "minimal setup", shown below, doesn't seem to match up to the ICSP header labels...hmmm.

1100×922 13.8 KB

In the above diagram, it shows the ICSP header tied in to UART0, along with the FTDI interface. Is this correct? Should it not be tied to the SPI interface, like the ICSP header is labeled?

I'll have an FT232RL on board as well as the ICSP interface. I plan to use the UNO R3 I have here as the ICSP programmer to load the bootloader into the board initially-and then use the FT232RL from then on.

2

ISP should be connected to appropriate pins on ATmega, of course. Different types of ATmegas have different pin assignment. You have definitely use MOSI, MISO, pins!

EDIT: See the post #4 below, from westfw!

3

Xnke:
I gave up on that and am now using the ports more sensibly. I'll just have to reassign the LCD data and control lines instead of using the default stuff. The new layout actually is cleaner, AND I can fit all the bare-bones essentials onto a single-sided PCB. (basically leaving off the radio hardware, and putting it on a second board)

I am using MCUDude's (Hansibull?) MegaCore and bootloader, as found here: GitHub - MCUdude/MegaCore: Arduino hardware package for ATmega64, ATmega128, ATmega165, ATmega169, ATmega325, ATmega329, ATmega640, ATmega645, ATmega649, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega3250, ATmega3290, ATmega6450, ATmega6490, AT90CAN32, AT90CAN64 and AT90CAN128

Since you're using MegaCore wouldn't it make the most sense to use the MegaCore pin mapping on your board?

From https://github.com/MCUdude/MegaCore/blob/master/avr/variants/standard/pins_arduino.h:

//      ARD.     AVR
//      PINS     PINS
//      |>        |                     A0   A1   A2   A3   A4   A5   A6   A7 
//      |>        |                     D45  D46  D47  D48  D49  D50  D51  D52            D44  D43  D42
//      |         | >    AVC  GND  ARE  PF0  PF1  PF2  PF3  PF4  PF5  PF6  PF7  GND  VCC  PA0  PA1  PA2
//      V         V       -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -
//               PEN    |                                                                              | PA3    D41
//      D0       PE0    |                                                                              | PA4    D40
//      D1       PE1    |                                                                              | PA5    D39
//      D2       PE2    |                                                                              | PA6    D38
//      D3       PE3    |                                                                              | PA7    D37
//      D4       PE4    |                                                                              | PG2    D36
//      D5       PE5    |                                                                              | PC7    D35
//      D6       PE6    |                                                                              | PC6    D34
//      D7       PE7    |                                                                              | PC5    D33
//      D8       PB0    |                                                                              | PC4    D32
//      D9       PB1    |                                                                              | PC3    D31
//      D10      PB2    |                                                                              | PC2    D30
//      D11      PB3    |                                                                              | PC1    D29
//      D12      PB4    |                                                                              | PC0    D28
//      D13      PB5    |                                                                              | PG1    D27 
//      D14      PB6    |                                                                              | PG0    D26 
//                        -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -
//                       PB7  PG3  PG4  RST  VCC  GND  XT2  XT1  PD0  PD1  PD2  PD3  PD4  PD5  PD6  PD7
//                       D15  D16  D17                           D18  D19  D20  D21  D22  D23  D24  D25
4

In the above diagram, it shows the ICSP header tied in to UART0, along with the FTDI interface. Is this correct? Should it not be tied to the SPI interface, like the ICSP header is labeled?

The schematic above is correct. The ATmega64/128 are different than other AVRs, and uses PDI/PDO instead of MISO/MOSI. Have a look at google if you don't believe it :wink:

5

From the datasheet:

Serial Programming Pin Mapping
Even though the SPI Programming interface re-uses the SPI I/O module, there is one important difference: The MOSI/MISO pins that are mapped to PB2 and PB3 in the SPI I/O module are not used in the Programming interface. Instead, PE0 and PE1 are used for data in SPI Programming mode as shown in the following table.

6

@westfw
Oops, you revoked it to me. Now I remember that I already read it a time ago. K+

7

Thanks guys. I saw so much data to the contrary I figured I better ask for clarification

8

I'm still working on this-I am trying to retain the Uno Shield pin headers, as I have a nice LCD that would plug in, with some buttons below it-if I can get them on the same board, it's all the better. Same with having a right-angle header to come over to a second board, etc...

I've been through several revisions in EAGLE to get to where I am now...which is not yet where I want it to be.

I haven't used the Megacore pinout, because it's actually not that easy to work with when you get down to it-you would want to be able to route universal IO pins wherever they're easiest to route to, and then adjust in the software, rather than try to map pins on the board in such a way to make sense in software. The latter just results in a very noise-prone layout, needing lots of vias and multiple board layers.

Hopefully by february I'll have some better layouts ready to actually etch some boards.

9

Xnke:
I'm still working on this-I am trying to retain the Uno Shield pin headers, as I have a nice LCD that would plug in, with some buttons below it-if I can get them on the same board, it's all the better. Same with having a right-angle header to come over to a second board, etc...

I've been through several revisions in EAGLE to get to where I am now...which is not yet where I want it to be.

I haven't used the Megacore pinout, because it's actually not that easy to work with when you get down to it-you would want to be able to route universal IO pins wherever they're easiest to route to, and then adjust in the software, rather than try to map pins on the board in such a way to make sense in software. The latter just results in a very noise-prone layout, needing lots of vias and multiple board layers.

Hopefully by february I'll have some better layouts ready to actually etch some boards.

Depending on how exact you want the pinout, The Arduino environment allow for redirection between the logical PIN and the physical port/pin. There is an abstraction layer that is unique for each hardware board. pins_arduino.h (on Win7: Arduino\hardware\arduino\avr\variants\standard) for the UNO.

Now, dedicated hardware pins, like SPI, UARTS, I2C, Analog, Interrupts need be be accurately substituted.

I have built custom 328P's, and Mega2560's boards that include all of the hardware port/pins. I just 'added' the extra pins. So on my 328P I have A6, A7.

Chuck.

10

Xnke:
I haven't used the Megacore pinout, because it's actually not that easy to work with when you get down to it-you would want to be able to route universal IO pins wherever they're easiest to route to, and then adjust in the software, rather than try to map pins on the board in such a way to make sense in software. The latter just results in a very noise-prone layout, needing lots of vias and multiple board layers.

How about the Wiring V1.0 pinout:
http://wiring.uniandes.edu.co/source/trunk/wiring/firmware/hardware/Wiring/Wiring1/BoardInfo.txt?revision=1143
I made a pins_arduino.h for it:

The reason I always try to convince people to use existing pinouts is because variations tend to proliferate over time, making it difficult to write certain libraries/bootloaders/hardware packages so they are compatible with all pinouts. I know of 12 different ATmega1284P pinouts. On the other hand, you will probably only find one pinout for ATmega328P/168 because people follow the arduino:standard pinout.