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