bgreat

Arduino Pinout observations

Recommended Posts

One issue I ran into with the Papilio DUO is the ATmega32u4 to Arduino header wiring. I had expected it to be compatible with the Arduino Leonardo (and others) standard for the AVR signals. But, it is not. This will likely cause issues with shields and their supporting libraries -- particularly ones that use the on-chip peripheral functions -- I2C, SPI, etc. The only AVR signals that are routed as expected are PD2 (RXD1/AIN1/INT2) and PD3 (TXD1/INT3). The LED not being wired to the expected PC7 output caused me some initial grief when I was testing the board with the Arduino example sketches -- I should have referred to the schematic instead of assuming :) . As the Papilio DUO is implemented as a 4-layer PCB, it should not be overly difficult to route the board to use the default IO wiring.

 

Here is a table with the expected pin mapping vs. the Papilio DUO pin mapping:

Arduino                                   Papio DUODigital                           (PWM~)  Alternate               AVR DIO   AVR DIO======= ======================= =======   =======RX<=0   RXD1/AIN1/INT2          PD2       PD2TX=>1   TXD1/INT3               PD3       PD3    2   SDA/INT1                PD1       PB5   ~3   OC0B/SCL/INT0           PD0       PB4    4   ICP1/ADC8               PD4       PD7   ~5   OC3A/#OC4A              PC6       PD6   ~6   T0/OC4D                 PD7       PD4    7   INT6/AIN0               PE6       PD1    8   ADC11/PCINT4            PB4       PD0   ~9   PCINT5/OC1A/#OC4B/ADC12 PB5       PB7  ~10   PCINT6/OC1B/OC4B/ADC13  PB6       PB0  ~11   PCINT7/OCA0/OC1C/#RTS   PB7       PB2   12   T1/#OC4D/ADC9           PD6       PB3  ~13   ICP3/CLK0/OC4A          PC7       PB1  GND AREF

For the Arduino Analog header, the Papilio DUO analog order is in reverse of the Arduino normal order. This could be an issue for Arduino familiar users.

 

Wish List:

1. The current PCB brings the ICSP signals to the digital header, eliminating a need for a separate 6-pin header, but I would much prefer having the standard digital signals and an additional set of pads for installing a 6-pin ICSP header. There is room on the board. It could even be a set of pads on the board back side for a surface mount header. This would allow for simple pogo-pin programming during manufacturing without incurring the expense of installing a header -- and allow the user to install their own header if wanted. A set of surface mount pads for a standard 10-pin JTAG connection would also be convenient.

 

2. For the Arduino Power header, it would be nice to be able to use the Vin pin (currently NC on Papilio DUO) as an alternate power input. This would require a 5V regulator for full compatibility, so is an unlikely addition due to added cost. For now, 5Vdc can be supplied to the board via the header provided the USB power jumper is removed.

 

3. A set of jumpers to allow routing of the FT2232H ICSP pins directly to the ATmega32U4 to eliminate the current requirement of loading a bit file to the FPGA to route the signals.

 

4. A reset button for the Arduino would be convenient -- or a jumper header to allow sending the current reset button to the FPGA, Arduino, or both.

 

5. Label all components on the silk screen layer. Pin 1 and polarity marking would also be nice. These are not only useful for building, but also for board trouble shooting. During assembly, I would have appreciated some package outlines also.

 

 

All in all, I have found the Papilio DUO to be a pleasure to build and work with so far. I am looking forward to the final product and tools that have been demonstrated.

 

Enjoy!

Bill

 

Share this post


Link to post
Share on other sites

Hello Bill,

 

I'm back from China now and will start working on the Papilio DUO with a vengeance. :)

 

Even with four layers it was difficult to route the two different designs and I changed the way that the pins are connected to make routing possible... The plan is to create a new set of core files in the Arduino IDE that will make the changes transparent to end users. I think I have it done already, let me try to dig it up.

 

Jack.

Share this post


Link to post
Share on other sites

One issue I ran into with the Papilio DUO is the ATmega32u4 to Arduino header wiring. I had expected it to be compatible with the Arduino Leonardo (and others) standard for the AVR signals. But, it is not. This will likely cause issues with shields and their supporting libraries -- particularly ones that use the on-chip peripheral functions -- I2C, SPI, etc. The only AVR signals that are routed as expected are PD2 (RXD1/AIN1/INT2) and PD3 (TXD1/INT3). The LED not being wired to the expected PC7 output caused me some initial grief when I was testing the board with the Arduino example sketches -- I should have referred to the schematic instead of assuming :) . As the Papilio DUO is implemented as a 4-layer PCB, it should not be overly difficult to route the board to use the default IO wiring.

 

Here is a table with the expected pin mapping vs. the Papilio DUO pin mapping:

Arduino                                   Papio DUODigital                           (PWM~)  Alternate               AVR DIO   AVR DIO======= ======================= =======   =======RX<=0   RXD1/AIN1/INT2          PD2       PD2TX=>1   TXD1/INT3               PD3       PD3    2   SDA/INT1                PD1       PB5   ~3   OC0B/SCL/INT0           PD0       PB4    4   ICP1/ADC8               PD4       PD7   ~5   OC3A/#OC4A              PC6       PD6   ~6   T0/OC4D                 PD7       PD4    7   INT6/AIN0               PE6       PD1    8   ADC11/PCINT4            PB4       PD0   ~9   PCINT5/OC1A/#OC4B/ADC12 PB5       PB7  ~10   PCINT6/OC1B/OC4B/ADC13  PB6       PB0  ~11   PCINT7/OCA0/OC1C/#RTS   PB7       PB2   12   T1/#OC4D/ADC9           PD6       PB3  ~13   ICP3/CLK0/OC4A          PC7       PB1  GND AREF

For the Arduino Analog header, the Papilio DUO analog order is in reverse of the Arduino normal order. This could be an issue for Arduino familiar users.

 

Wish List:

1. The current PCB brings the ICSP signals to the digital header, eliminating a need for a separate 6-pin header, but I would much prefer having the standard digital signals and an additional set of pads for installing a 6-pin ICSP header. There is room on the board. It could even be a set of pads on the board back side for a surface mount header. This would allow for simple pogo-pin programming during manufacturing without incurring the expense of installing a header -- and allow the user to install their own header if wanted. A set of surface mount pads for a standard 10-pin JTAG connection would also be convenient.

 

2. For the Arduino Power header, it would be nice to be able to use the Vin pin (currently NC on Papilio DUO) as an alternate power input. This would require a 5V regulator for full compatibility, so is an unlikely addition due to added cost. For now, 5Vdc can be supplied to the board via the header provided the USB power jumper is removed.

 

3. A set of jumpers to allow routing of the FT2232H ICSP pins directly to the ATmega32U4 to eliminate the current requirement of loading a bit file to the FPGA to route the signals.

 

4. A reset button for the Arduino would be convenient -- or a jumper header to allow sending the current reset button to the FPGA, Arduino, or both.

 

5. Label all components on the silk screen layer. Pin 1 and polarity marking would also be nice. These are not only useful for building, but also for board trouble shooting. During assembly, I would have appreciated some package outlines also.

 

 

All in all, I have found the Papilio DUO to be a pleasure to build and work with so far. I am looking forward to the final product and tools that have been demonstrated.

 

Enjoy!

Bill

 

1) I will be publishing easy to use projects in the Designlab software that will make it easy to connect the ICSP pins to wing pins. I figured it was better to do this with a bit file... I intend to make this one of the steps in the test plan - to program the arduino bootloader to the DUO.

 

2) Yep, the additional 5V regulator is why I did not connect this pin.

 

3) I know its not the same, but I will provide a DesignLab example to do this.

 

4) We will be able to use the user switch for this purpose if so desired... The atmega reset pin is under control of the FPGA.

 

5) Yeah, I'm not sure I like my decision to leave the package marking from the silkscreen. I always have in the past but when I was looking at several recent designs I noticed the trend to leave it off. It makes the final PCB look cleaner and the important information easier to find... But it does really suck during this part of the design process to not have it, ultimately the pick and place machines will not need those markings so it was safe to leave them off. I'm still up in the air whether it was the right way to go, not sure if I will do it again in the future. The good news is that it is easy to enable that layer before generating the gerber files... Maybe I should have included it for prototypes and remove it for production.

Share this post


Link to post
Share on other sites

Welcome back!

 

If you like, I can take a look at the routing. I have done some initial routing and it was a simple matter to correct the A0-A5 lines.

 

I think I can route the PWM lines to the expected pins at a minimum.

 

Enjoy!

Bill

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now