vinciDuino and Leonardo Support

I see the Spanish thread on the vinciDuino, but unfortunately I cannot do Spanish. I have some questions about support for these and if they work the way I think.

  • is there a boot loader for the vinciDuino and Leonardo?
  • can sketches be loaded via the native USB interface?
  • does the USB support auto reset or is this strictly via the serial header?
  • how does one integrate the vinciDuino into the Arduino IDE?

Send a PM to fm, the main vinciDuino contact it seems.

adilinden:
I see the Spanish thread on the vinciDuino, but unfortunately I cannot do Spanish. I have some questions about support for these and if they work the way I think.

  • is there a boot loader for the vinciDuino and Leonardo?
  • can sketches be loaded via the native USB interface?
  • does the USB support auto reset or is this strictly via the serial header?
  • how does one integrate the vinciDuino into the Arduino IDE?

Hi, we have build a wiki for the vinciDuino which I hope can answer your questions. This is a direct link to the English version: https://bitbucket.org/fmalpartida/vinciduino/wiki/Home.

To answer your questions more specifically:

  • The sketches on the current release of the vinciDuino can be downloaded directly using the native USB interface, very handing too. There is no need to use a UART to USB interface.
  • The reset function works very nicely, on sketch upload, the board resets and runs the bootloader.
    We have also added an additional UART breakout to the board compatible with Sparkfun's FTDI cable and board, so you can have both at the same time:
  • Serial object which references the native USB UART and
  • Serial1 object which addresses the second UART of the chip.
    This second UART is also very handy if you want to add the capability to the board of connecting an Xbee for example.

The vinciDuino currently integrates directly into the Arduino IDE, simply select Leonardo as a board and that's it. You are up and running. We have been running some test of the board right now and all the IO, ADCs, Serial connections, I2C, SPI are working directly without having to do a single modification. We could say that the board is a pre-Leonardo clone. Its footprint is smaller though, while shield headers are compatible.

The current project status is that we have released a batch of Rev A boards to beta testers. There are some things that we will review on Rev B, but in general it is working very nicely. Taking on Crossroads suggestions another thing that we will revise is the linear regulator.

@CrossRoads, do you know how can I remove the thermal relieve from one component so that it is fully copper filled?

Hard way is to edit the symbol.
Easy way is to add a polygon over the area you want filled, name it the same as the area it is connecting so it doesn't get isolated.
You may end up with "overlap" errors that you can ignore.
Use viewplot.com software to review the gerbers that are created to make sure you end up with correct results.

I did the same to extend some pads on parts that I thought were a little small.

Hi CrossRoads, thanks for the tip, worked great.

Unfortunately I use a Mac and EE design packages are not widely available. Do you know of a gerber viewer for Mac, I currently use MCN viewer, not bad but sometimes is a pain. I've been looking around for gerbv but I haven't been able to find the .dmg for it.

"Unfortunately I use a Mac"
Sorry to hear that :grin:

Don't know how to help you out.
Don't macs do some kind of slow windows emulation thing so they can run what the rest of the world can run?

I do use a Mac but run a Gerber viewer in a VMware Windows instance.

Hi CrossRoads, didn't want to sound ... Any way, what I meant was that it is unfortunate to run OS X for EE Design packages. Most of them are only available on Windows. I do use MCN viewer, which is a native Mac gerber viewer but has its limitations.

I've been running on vmware some CAD software, but it is a real pain, slow, ...

Any way, I'll do a forum post to see if anyone has some idea as to the where a bouts of gerbv or a similar app for Mac.

Yeah, I saw that post elsewhere.

You could just view the individual layers in Eagle. Its all the same information.

Yeah, that is what I do too. Thanks for the tips CrossRoads.

I tried to tabulate the pin assignments of the vinciDuino. Did I get this right?

*uino ATmega32u4 Function
A0 36 - PF7 (ADC7)
A1 37 - PF6 (ADC6)
A2 38 - PF5 (ADC5)
A3 39 - PF4 (ADC4)
A4 41 - PF1 (ADC1)
A5 42 - PF0 (ADC0)

D0 20 - PD2 (RXD1/INT2) UART RX
D1 21 - PD3 (TXD1/INT3) UART TX
D2 19 - PD1 (SDA/INT1) SDA, IRQ2
D3 18 - PD0 (OC0B/SCL/INT0) PWM, SCL, IRQ3
D4 25 - PD4 (ICP1/ADC8)
D5 31 - PC6 (OC3A/OC4A) PWM
D6 27 - PD7 (T0/OC4D/ADC10) PWM
D7 1 - PE6 (INT6/AIN0)

D8 28 - PB4 (PCINT4/ADC11)
D9 29 - PB5 (PCINT5/OC1A/OC4B/ADC12) PWM
D10 30 - PB6 (PCINT6/OC1B/OC4B/ADC13) PWM
D11 12 - PB7 (PCINT7/OC0A/OC1C) PWM
D12 26 - PD6 (T1/OC4D/ADC9)
D13 32 - PC7 (ICP3/CLK/OC4A) LED

ICSP3 9 - PB1 (PCINT1/SCLK) SPI SCK
ICSP4 10 - PB2 (PCINT2/MOSI) SPI MOSI
ICSP1 11 - PB3 (PCINT3/MISO) SPI MISO

USBTX 22 - PD5 TX LED
USBRX 8 - PB0 (PCINT0/SS) RX LED

And for reference, this is what I got for the UNO:

*uino ATmega328 Function
A0 23 - PC0 (ADC0/PCINT8)
A1 24 - PC1 (ADC1/PCINT9)
A2 25 - PC2 (ADC2/PCINT10)
A3 26 - PC3 (ADC3/PCINT11)
A4 27 - PC4 (ADC4/SDA/PCINT12) SDA
A5 28 - PC5 (ADC5/SCL/PCINT13) SCL

D0 2 - PD0 (PCINT16/RXD) UART RX
D1 3 - PD1 (PCINT17/TXD) UART TX
D2 4 - PD2 (PCINT18/INT0) IRQ2
D3 5 - PD3 (PCINT19/OC2B/INT1) PWM, IRQ3
D4 6 - PD4 (PCINT20/XCK/T0)
D5 11 - PD5 (PCINT21/OC0B/T1) PWM
D6 12 - PD6 (PCINT22/OC0A/AIN0) PWM
D7 13 - PD7 (PCINT23/AIN1)

D8 14 - PB0 (PCINT0/CLKO/ICP1)
D9 15 - PB1 (PCINT1/OC1A) PWM
D10 16 - PB2 (PCINT2/OC1B/SS) PWM, SPI SS
D11 17 - PB3 (PCINT3/OC2A/MOSI) PWM, SPI MOSI
D12 18 - PB4 (PCINT4/MISO) SPI MISO
D13 16 - PB5 (PCINT5/SCK) SPI SCK, LED

And this is what CrossRoads suggested in another discussion thread

CrossRoads:
ATMega32U4 with USB only power, like this then.

*uino ATmega32u4 Function
A0 42 - PF0 (ADC0)
A1 41 - PF1 (ADC1)
A2 40 - PF4 (ADC4)
A3 39 - PF5 (ADC5)
A4 38 - PF6 (ADC6) *jumper select 19 - PD1 (SDA/INT1) SDA
A5 37 - PF7 (ADC7) *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 22 - PD5
D4 26 - PD6 (T1/OC4D/ADC9)
D5 27 - PD7 (T0/OC4D/ADC10)
D6 12 - PB7 (PCINT7/OC0A/OC1C)
D7 30 - PB6 (PCINT6/OC1B/OC4B/ADC13)

D8 29 - PB5 (PCINT5/OC1A/OC4B/ADC12)
D9 28 - PB4 (PCINT4/ADC11)
D10 8 - PB0 (PCINT0/SS) SPI SS
D11 10 - PB2 (PCINT2/MOSI) SPI MOSI
D12 11 - PB3 (PCINT3/MISO) SPI MISO
D13 9 - PB1 (PCINT1/SCLK) SPI SCK, LED

D20 18 - PD0 (OC0B/SCL/INT0) SCL
D21 19 - PD1 (SDA/INT1) SDA
D22 31 - PC6 (OC3A/OC4A)
D23 32 - PC7 (ICP3/CLK/OC4A)
D24 33 - PE2 (HWR)
D25 1 - PE6 (INT6/AIN0) RX LED

I think that is right, I haven't reviewed it thoroughly but seams good. The pin/port mapping is based on Leonardo's core files, that way the board will behave like Leonardo.

By the way, I like crossroads mapping better as it would maintain compatibility with shields already available.

fm:
By the way, I like crossroads mapping better as it would maintain compatibility with shields already available.

That is what I was thinking too. The SPI and I2C port placement is more important to me then PWM or pin change interrupts. I noticed there is no TX LED for the USB interface. Also, I would imagine the bootloader would have to be adjusted to support different pin assignments for TX and RX activity LED's. I think it would be trivial to utilize any of the D22 through D25 ports to light up some LED's.

I will have to learn how to tell the Arduino environment how the hardware is configured. I've had some very brief glimpses into the Arduino core files, just need to learn and understand them. How to build the bootloader is another thing to look at to properly support a different hardware configuration.

adilinden:
That is what I was thinking too. The SPI and I2C port placement is more important to me then PWM or pin change interrupts. I noticed there is no TX LED for the USB interface. Also, I would imagine the bootloader would have to be adjusted to support different pin assignments for TX and RX activity LED's. I think it would be trivial to utilize any of the D22 through D25 ports to light up some LED's.

This was my comment to the Arduino team, but it seams that they though other way. It is strange though, considering that it is very easy to do a compatible logical mapping, i.e. hardware pins to what the SW knows them by. I wouldn't be surprised if they do it for their commercial release though (a bit of misdirection there to avoid having any clones out there before their official release?).

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.

I will have to learn how to tell the Arduino environment how the hardware is configured. I've had some very brief glimpses into the Arduino core files, just need to learn and understand them. How to build the bootloader is another thing to look at to properly support a different hardware configuration.

This is all in "hardware/arduino/variants/leonardo", very easy to change (not very elegant nor efficient but it works, though). Whatever you do there has to be done in the bootloader "pin mapping" file too (well you can get away with minor changes there.
I've changed the bootloader and it compiles just fine, no problems foreseen there.

fm:
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?

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"

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

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.

CrossRoads:
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:

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

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.