Go Down

Topic: vinciDuino and Leonardo Support (Read 7060 times) previous topic - next topic


For the RX and TX I would maintain the pin assignment that we've used. This is used by the core and bootloader to blink the LEDs when sending and receiving information from the USB virtual serial interface.


The Leonardo uses ATmega pins 8 and 22 for the RX and TX LEDs. On the CrossRoads suggested pinout these become D10 (also SPI SS) and D3. This would then make them unavailable for pretty much any digital IO that requires the USB serial functionality while a sketch runs (i.e. serial monitor). So in my mind it would make a lot more sense to remap the RX and TX LEDs to ATmega pins 1, 31, or 32. This would then require the appropriate changes in  the bootloader.

Are there any other places where the pin mapping for RX and TX LEDs is relevant, other then the "hardware/arduino/variants/leonardo" and "hardware/arduino/bootloaders/diskloader/src" locations?

Quote

I've changed the bootloader and it compiles just fine, no problems foreseen there.


How do you build the bootloader? I found the files in "hardware/arduino/bootloaders/diskloader/src". It look like the definitions for the TX and RX pin are in Platform.h.

Yet another thing I am not sure about is the function of the HWB pin. I found the explanation in the datasheet. But in the Leonardo (and vinciDuino) is the HWBE fuse enabled or disable? Is this pin reserved or useable as digital IO?

"When the HWBE fuse is enable the ALE/HWB pin is configured as input during reset and sam-
pled during reset rising edge. When ALE/HWB pin is '0' during reset rising edge, the reset vector will be set as the Boot Loader Reset address and the Boot Loader will be executed"


westfw

Quote
Do you know of a gerber viewer for Mac,

"gerbv" is open source linux SW that will compile for Mac.  Recently, it installs fine using Fink/Fink-commander
(you'd need to start by installing the Mac developer tools and X windows system...)

CrossRoads

Rx/Tx LED:

"On the CrossRoads suggested pinout these become D10 (also SPI SS) and D3. This would then make them unavailable for pretty much any digital IO that requires the USB serial functionality while a sketch runs (i.e. serial monitor). "

How so? Rx/Tx during download of a sketch is different than using the USB as Serial during a sketch; in one case, the bootloader code makes the LEDs do something (blink to show activity) and in the second your code controls those pins, and you treat them as IO, same as if you were using D13 and its LED on an Uno, and the USB port hardware does its own thing, just like the UART does on an Uno.

So you could have the bootloader flash the LED on D13 as Tx, and the one I show on D25 as the Rx.
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.


How so? Rx/Tx during download of a sketch is different than using the USB as Serial during a sketch; in one case, the bootloader code makes the LEDs do something (blink to show activity) and in the second your code controls those pins, and you treat them as IO, same as if you were using D13 and its LED on an Uno, and the USB port hardware does its own thing, just like the UART does on an Uno.


Elsewhere I read this:


I tried running the example serial sketch and the RX and TX LEDs flash as expected.

I changed the fuses to activate the HWB pin and running without the bootloader disables the serial and the RX/TX LEDs( but TX pin is held low so LED is always turned on)


This leads me to believe that using the USB serial port will cause the RX and TX LED to be controlled by the USB code. I imagine not unlike the UNO, where the RX and TX pins are connected to the FTDI chip. If I use the serial monitor on UNO I do not have D0 and D1 available as they are the serial port. Likewise, I seem to get the idea that the RX and TX LED port pins are taken over on the Leonardo when the USB serial functions are used.

Since the 32U4 has a few extra IO ports it only makes sense to use an otherwise unused pin pair to drive the RX and TX LED. If I am right, then this is pretty significant, if I am wrong then no harm done. Well, except for having to build a custom bootloader in addition to changing "hardware/arduino/variants/leonardo/pins_arduino.h". But then, "hardware/arduino/variants/leonardo/pins_arduino.h" needs to be modified anyways to support the changed port scheme.

#19
Dec 21, 2011, 12:01 am Last Edit: Dec 21, 2011, 12:06 am by adilinden Reason: 1
I created a schematic for what I have in mind...

I did not bring the extra port pins to a header. Instead I wired them to the various LED. In addition to RX and TX I wired up an extra LED. Also, I provided a jumper for the D13 LED so it may be driven by another port pin.


fm

Hi, I've downloaded kicad which seams to have as a package gerberv. But it is so slow and a bit buggy.
   

#22
Dec 21, 2011, 08:56 am Last Edit: Dec 21, 2011, 08:58 am by adilinden Reason: 1
I think having to make too many changes to the Arduino environment is somewhat of a scary thought. At least for a a very first try of making a Arduino shield and bootloader capable gizmo. So I gave the pinout some more thought and came up with a compromise. I put SDA/SCL and the SPI pins where they will work (for my purposes) and shuffled some of the other pins to fill that gaps created. At the same time I left the Leonardo specified RX LED and TX LED pins untouched. So the bootloader should work without any changes.

These are the results. I am not sure about the whole lot of D2 through D7. I just realized now that I mixed them up pretty good. Might have to give that some more thoughts. But with this arrangement I think all that would need changes is "hardware/arduino/variants/leonardo/pins_arduino.h". Unless I can figure out how to create a whole new board within the environment.

Code: [Select]

*uino ATmega32u4 Function
A0 36 - PF7 (ADC7)
A1 37 - PF6 (ADC6)
A2 38 - PF5 (ADC5)
A3 39 - PF4 (ADC4)
A4 40 - PF1 (ADC1) *jumper select 19 - PD1 (SDA/INT1) SDA
A5 41 - PF0 (ADC0) *jumper select 18 - PD0 (OC0B/SCL/INT0) SCL

D0 20 - PD2 (RXD1/INT2) UART RX
D1 21 - PD3 (TXD1/INT3) UART TX
D2# 25 - PD4 (ICP1/ADC8)
D3# 26 - PD6 (T1/OC4D/ADC9)
D4# 27 - PD7 (T0/OC4D/ADC10) PWM
D5# 12 - PB7 (PCINT7/OC0A/OC1C) PWM
D6# 31 - PC6 (OC3A/OC4A) PWM
D7# 32 - PC7 (ICP3/CLK/OC4A) PWM

D8 28 - PB4 (PCINT4/ADC11)
D9 29 - PB5 (PCINT5/OC1A/OC4B/ADC12) PWM
D10 30 - PB6 (PCINT6/OC1B/OC4B/ADC13) PWM
D11# 10 - PB2 (PCINT2/MOSI) SPI MOSI
D12# 11 - PB3 (PCINT3/MISO) SPI MISO
D13# 9  - PB1 (PCINT1/SCLK) SPI SCK, LED (*jumper select)

D14 8  - PB0 (PCINT0/SS) RX LED
D15# 22 - PD5 TX LED
D16# 1  - PE6 (INT6/AIN0) L1 LED (*jumper select)
D17# 33 - PE2 (HWB) L2 LED

# means deviate from Leonardo

After yet another revision of the pinout I've settled on just changing the MOSI, MISO, SCK, SDA, SCL pins to have the "traditional" Arduino position. Now I just need to come up with a name for it :-)

Graynomad

Could you not run SDA/SCL out to the new locations as well? No harm done and may be useful for new shields.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

fm

I like it, it looks very cool. I agree with Rob, breaking out the SCL and SDA should be a nice feature for this board.
I like the crystal you are using what is its part number?
I woul also add the PWM serigraphy to the board. Being a non standard layout would help developers locate those pins easily.
Have you considered filtering the supply line with a PI filter? You have enough space on board and would get help reduce over all noise on analog readings too.
I would surround the AREF with ground all the way to the pin.
   

Both are very valid points.

I also discovered that I made the vias specific to the tolerances of a particular board house. I went to BatchPCB to see about costs. It turns out I need a larger drill size and a larger ring, in turn raising clearance errors at all vias routing signals. I will see about fixing that and running the I2C to the additional 2 pins as well.

I must say, the AREF pin is in a pretty awkward place. Would it not make a lot more sense to have an AGND.and AREF grouped with the analog pins? Not something that cam be changed without breaking shield compatibility. Just a thought though.

Also, I did not seperate analog VCC and GND from digital. Having them filtered and routed separately would greatly help any noise issues.

On one hand I am anxious of having a board in my hands sooner rather then later. So unless I discover some really major errors I'll be sending this to be made. Then do another sample with all of these enhancements addressed.

Thank you for looking at this and making suggestions. Very much appreciated.


I like the crystal you are using what is its part number?


Here is the parts list for all but the headers from DigiKey. The crystal is a NX5032 series. A bit smaller then a surface mount HC49 type. I understand that technically a ceramic resonator is not acceptable for USB. Although, I have used ceramic resonators with USB on PIC in the past.

Code: [Select]
Digi-Key Part Number Manufacturer Manufacturer Part No Customer Reference Qty Description
ATMEGA32U4-AU-ND ATMEL ATMEGA32U4-AU U1 1 MCU AVR 32K FLASH 16MHZ 44-TQFP
311-1140-1-ND YAGEO (VA) CC0805KRX7R9BB104 "C1,2,3,4,5,6,7,11" 6 CAP CER 0.1UF 50V 10% X7R 0805
478-1655-1-ND AVX CORPORATION (VA) TAJA106K016RNJ C10 1 CAP TANT 10UF 16V 10% 1206
709-1172-1-ND JOHANSON DIELECTRICS INC (VA) 500R15N220JV4T "C8,9" 2 CAP CER 22PF 50V 5% NP0 0805
311-10KARCT-ND YAGEO (VA) RC0805JR-0710KL R1 1 RES 10K OHM 1/8W 5% 0805 SMD
311-1.0KARCT-ND YAGEO (VA) RC0805JR-071KL "R2,3,4,5,6" 5 RES 1.0K OHM 1/8W 5% 0805 SMD
311-22ARCT-ND YAGEO (VA) RC0805JR-0722RL "R7,8" 2 RES 22 OHM 1/8W 5% 0805 SMD
754-1133-1-ND KINGBRIGHT CORP (VA) APT2012SURCK "L1,2" 2 LED 2X1.2MM 630NM RD WTR CLR SMD
754-1127-1-ND KINGBRIGHT CORP (VA) APT2012CGCK PWR 1 LED 2X1.2MM 570NM GN WTR CLR SMD
754-1125-1-ND KINGBRIGHT CORP (VA) APT1608YC "RX, TX" 2 LED 1.6X0.8MM 588NM YLW CLR SMD
644-1037-1-ND NDK (VA) NX5032GA-16.000000MHZ-LN-CD-1 X1 1 CRYSTAL 16.000000 MHZ 8PF SMD
ED2992CT-ND ON SHORE TECHNOLOGY INC (VA) USB-M26FTR USB 1 CONN USB MINI B R/A SMD


Quote

Have you considered filtering the supply line with a PI filter? You have enough space on board and would get help reduce over all noise on analog readings too.


Here are some old old notes on USB connectivity I have. I believe the first diagram with the ferrite is the PI filter you suggest?

Code: [Select]
USB Connection
--------------
Some hints on USB connections and power decoupling. The PIC includes ESD
protection (maybe?) and driver output impedance to match USB specs.

                       Ferrite
     5V   1 o-----------+---[===]---+--------+------o Vusb
                        |           |        |
     D-   2 o-------+   | 10nF      | 100nF  | 10uF
                    |  ===         ===      ===
     D+   3 o----+  |   |           |        |
                 |  |   |           |        |
     GND  4 o----|--|---+---[===]---+--------+------o GND
                 |  |  Ferrite
                 |  |         0R
                 |  +-------[===]-------------------o D+
                 |            0R
                 +----------[===]-------------------o D-
Parts:
  10nf      DigiKey C0805C103K5RACTU
  100nF     DigiKey GRM219F51H104ZA01D
  10uF      DigiKey GRM21BF51C106ZE15L
  Ferrite   DigiKey MI0805K400R-10

USB Connection (alternate per Atmel)
------------------------------------
The Atmel chip requires ESD protection and matching resistors. The USBLC6-2SC6
is a suitable TVS device specifically for HS USB 2.0 operation.


     5V   1 o--------+-------+----------------------o Vusb
                     |       |
                  +-----+    |         22R
     D-   2 o-----|     |----|--------[===]---------o D+
                  |     |    | 100nF
                  | TVS |   ===
                  |     |    |         22R
     D+   3 o-----|     |----|--------[===]---------o D-
                  +-----+    |
                     |       |
     GND  4 o--------+-------+----------------------o GND

Parts:
  100nf
  22R
  USBLC6-2SC6

fm

#28
Dec 23, 2011, 10:55 pm Last Edit: Dec 23, 2011, 11:03 pm by fm Reason: 1
Rev B of the vinciDuino has been ordered. We have currently ordered 10 to try them with what we think is going to be the final version.
Rev A has been fully tested with:

  • Windows - XP SP3 and 7

  • Mac OSX Lion

  • Linux Ubuntu


Everything is working great out of the box without any changes to the Arduino 1.0 IDE.

There aren't that may differences between Rev A and Rev B:

  • RX/TX LEDs are compliant to the core - off when not in use.

  • Improved board thermal dissipation

  • Separated ground planes for analog and digital

  • Added additional filtering to power supply

  • Added a new row of headers to cater for standard prototyping boards with standard 0.1" pin spacing

  • Added an additional Vin connector

  • Improved artwork and board routing



As always all the project information can be found here: https://bitbucket.org/fmalpartida/vinciduino/wiki/Home

Hope you like it.
   

fm

@adilinden - thanks for the information. Yes that looks very much like a pi filter.
   

Go Up