Not clear at all! The Uno looks fine. Could the head Arduino guys fix?
Arduino schematics aren't the clearest in the world and that one is little better, but what exactly isn't clear, I haven't had a good look but it seems about normal?
Rob
All the connecting lines a very light and some don't connect. Just about unreadable. I'm using Mint-Debian with Firefox and other PDF text or schematics look good. OK. I just tried to see schematic on another machine using XP and IE. Just a blank screen. Tried Firefox, the same. On Linux box, at least I can see it, but it's unusable.
I think there is something strange with how the pdf was created.
I have attached what it looks like when I view the pdf in Chrome.
If I download and view it in Adobe Reader, it looks ok.
It looks OK on my PDF reader. I suspect this is an interim schematic as it doesn't have a title block or any notes.
Anyone know what the * on some pins means? And why are there two processors?
Rob
Try zooming in a step if you cannot see the lines.
The two processors are really two different footprints for the same one. If you open it in Eagle and look at the board, you can see an alternative, smaller wiring right below the main processor. That is probably in case they cannot re-stock the chip they use at the moment. It is the same chip, just packaged differently.
As for the stars... looks like independent PWM channels to me. Every pin marked with a star has an output compare unit on that µC pin (OC**), and the only output compare unit not marked with a star is merely the complementary output to another, so not independent.
You would think they would use the ~ symbol as with all other schematics, go figure.
Life's to shore to learn Eagle, is that a QFN package under the QFP?
Rob
Any ideas about the IO/Alt1/Alt2/Alt3 labels on the right?
Well no-one's ever accused Arduino of producing great schematics.
I would say that those labels indicate alternative functions for those pins.
I see that they still haven't allowed for a full 8-bit port to be available, instead we get two LEDs smack in the middle of PORTB and PORTD. C'mon guys, often having access to a full 8-bit port is important.
The second processor does in fact appear to be the QFN version, although if you Google "atmega32u4-xumu" there is no such thing, and yet a search for "ATmega32U4-MU" (the correct part number) works. So what's with the bogus part number?
Rob
They are both like that - XUMU, -XUAU.
I think I still like my pin assignments better.
Maybe I'll ask maniacbug to make me a pins_arduino.h variant for IDE 1.0.1.
Eagle doesn't export the greatest of files for sharing.
All my thumbs up for your variant, though after the R3 releases, it might have made sense to include the new SDA/SCL breakout. Kudos for putting SPI back on the edge connectors, as well as preserving signals like SS.
Well, I do provide jumpers to have SCL/SDA on the A4/A5 connector pins, and they are also on separate pins, if that's what you meant.
I was kinda referring to the new 1.0 pins that are desperately trying to become accepted a standard.
"trying to become accepted a(s) standard"
Maybe by some.
I don't appreciate that 5 pins are not brought out to female headers for general use: TXLED, RXLED, and MISO, MOSI, SCK (but are on male pins on ICSP header).
Here's a schematic of how I am designing an 32U4 into another board. Space is really tight, so pins were assigned for routability.
Are TXLED, RXLED, MISO, MOSI, SCK defined as D20-24 if someone wanted to use them as regular digital pins? Or incorporate the LEDs as indicators for software use?
I haven't studied the Leonardo files to find out yet.
I don't appreciate that 5 pins are not brought out to female headers for general use:
Many of the Arduino design decisions baffle me, on the Leo they dedicate two pins to Tx and Rx LEDs and in doing so they remove any chance of having a full 8-bit port.
WTF??
At least bring them out to the world so people have a choice.
Rob
CrossRoads:
"trying to become accepted a(s) standard"
Maybe by some.
I don't appreciate that 5 pins are not brought out to female headers for general use: TXLED, RXLED, and MISO, MOSI, SCK (but are on male pins on ICSP header).Here's a schematic of how I am designing an 32U4 into another board. Space is really tight, so pins were assigned for routability.
Are TXLED, RXLED, MISO, MOSI, SCK defined as D20-24 if someone wanted to use them as regular digital pins? Or incorporate the LEDs as indicators for software use?
I haven't studied the Leonardo files to find out yet.
I am talking about the two pins left of AREF on the R3 boards (and Leo), which have been put there precisely to give I²C a definite position instead of forcing users to rely on the jumper workarounds and such. But yeah, the unavailability of the LED pins and the limited availability of the SPI pins is a real shame.