next topic »

[on:]

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?

[Reply #1 on:]

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

[Reply #2 on:]

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?

[Reply #3 on:]

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.

[Reply #4 on:]

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.

[Reply #5 on:]

"Unfortunately I use a Mac"
Sorry to hear that 

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?

[Reply #6 on:]

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

[Reply #7 on:]

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.

[Reply #8 on:]

Yeah, I saw that post elsewhere.

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

[Reply #9 on:]

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

[Reply #10 on:]

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

[Reply #11 on:]

And this is what CrossRoads suggested in another discussion thread

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

[Reply #12 on:]

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.

[Reply #13 on:]

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.

[Reply #14 on:]

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.