DigiX Pinout documentation

[Mark]

Nice work.
Cheers

mark

[gogol]

Hello,

as some people have already downloaded my first draft, I will summarize the questions I am working on.


Which pins are connected to WiFi?
Which ones could be dis/connected by opening/closing a soldering bridge?

Which pins are connected to the NFC header?
Which ones could be dis/connected by opening/closing a soldering bridge?

The SD card seems only to be connected via SPI not via HSMCI.
Which SPI channel is used, which PIN is the corresponding CHIP-select?
Looks like PA29 is the CHIP-select and PA25-PA27 are the SPI lines.

The Due has an 4 port debug connector and an small 2x5 port JTAG.
The digix seems to have only the 2x5 JTAG, but labeled DEBUG. What are the differences?

Looks like, that the 2x5 DEBUG port of the digiX is fully redundant,
as all JTAG related pins are available on the additional digiX row.


I appreciate any help, links and additional information!


regards

  gogol

[gogol]

enclosed version 0.2. Still many questions open.
I really would appreciate feedback, critics, additions, ...

[gogol]

@digistump:

Is there any better documentation available than:
http://digispark.s3.amazonaws.com/DigiX-V1-Final-Production.pdf
which is linked from the wiki.

• In this PDF there are to many strings overlapped e.g. wifi pin 42 leads to SJ-7 and further to ??
• Jumper U$5 pin 3-8 are leading to nowhere.
• contradictionary/wrong information:  Wifi Pins 39/42 are documented to RXD2/TXD2 while they are connected to RX/TX

If anyone else have more information/documentation: Please share!

__
Edit: Enclosed version 0.3

[MichaelMeissner]

In looking at photos of the Due, Mega, Leonardo, and DigiX, it answers a question I've had in looking at various library code.  I've seen various library code that does I²C that uses the 2nd I²C port instead of the first i²C port.  It looks like yet another case of the Arduino team changing their mind as new boards come up.

In the Uno R2, they used A4/A5 as the I²C pins.  Then when the Uno R3 they come out with the new shield layout, and add 2 pins next to AREF for the I²C pins, and wire A4/A5 to use it.

Then the Mega comes out, and it has SDA/SCL relocated to pins 20/21, but I believe it still uses the 'common' I²C pins next to AREF.

Then the Leonardo, it uses pins 2/3, but it uses the pins next to AREF as well.

So any R1 shield wanting to use I²C, uses the 2 pins next to AREF.

Now we get to the Due.  Great, they have 2 I²C buses.  That can be useful.  However, they choose to put the 2nd I²C in the standard location next to the AREF pin.  I would have thought for maximum capability, they should have made the main I²C bus to use the standard location as well as the Mega location, and then put the 2nd I²C bus in some of the new pins.  Sigh.  Of course the DigiX has to follow this layout to be mostly Due compatible.

So now, 3rd party library code is littered with:

Code: [Select]

#if defined(__AVR__)
 #define WIRE Wire
#else // Arduino Due
 #define WIRE Wire1
#endif


[digistump]

@Michael - I agree - they should have made the ones by AREF Wire and the other Wire1 - it is just a code change to do it and the only reason I didn't is because it would be confusing if DigiX did it differently than the Due.

@gogol - - I've been following closely and just haven't had a chance to sit down and answer the questions here - so this will be a start hopefully:

The JTAG port is the same JTAG port as on the Due - but it is also duplicated to the header for use as general i/o (110-113 - jtag pin name is labeled on back of board) because of this 110,112,113 are pulled high with 10k resistors (111 is not)

WiFi module TX connects to RX2 Pin 19 on the headers, WiFi RX to TX2 Pin 18 - in the IDE (on Due and DigiX) this is Serial1

WiFi reset is unconnected as it ships but the PIN 106 MASTER-RST jumper on the back allows you to connect it to the Reset button by closing the solder jumper on the right (MASTER-RST) or Pin 106 (labeled WIFI RST on back of board) by closing jumper on left (with PIN 106 over it).

The WiFi RTS and CTS jumpers are connected when shipped and can be cut to free up pins 104 and 105 - which are labeled WIFI RTS and CTS on the back. If left connected hardware flow control can be turned on via the web interface and then by doing wifi.begin(baudrate,true); where baud rate is the baud the wifi module is set to - by doing this you can use any of the wifi module's baud rates without issue.

The AREF jumper on the back can be used to connect the AREF to the AREF pin but cutting the trace between the left side pads and bridging the right. THe default connects it to 3.3v - same as due.

The nRF IRQ jumper can be used to connect the IRQ pin on the nRF24L01+ module to 51 - off by default as most libraries don't need the IRQ pin

the nRF module (when plugged into the low profile header that is for it) is connected as follows:
CSN - 52
CE - 51
MOSI, MISO, SCK - to the SPI pins
VCC to 3.3, GND to Gnd

WiFi enable jumper on top of board (with shunt) connect power to wifi, remove to completely shut off wifi - useful for ocmputers that can't put out enough current over USB to power board and wifi - or for resetting with the reset jumper disconnected

108 and 109 are the TXL and RXL LEDs on a Due - also can be accessed at pin 73(TXL) for 108 and 72(RXL) for 109 - they will pulse when sending over USB - this can be turned off in the core if desired.


SPI is on PA25-27

SD Card select is on pin 4 - sd card is on spi, with spi header (ICSP header) and nrf module.

Pins 90-100 are labeled on the back with their functions when used with an ethernet phy - no documentation on this now

All I have a chance for now - let me know more questions (in a list if possible) and I'll keep clarifying

[gogol]

Thanks for your answers, I think, they helped a lot.

As for JTAG I already came to the same conclusion: The JTAG from the DUE is called DEBUG in the digiX. The 4pin debugWire from the DUE is missing on the digiX, but that is no problem, as that is also only a subset of JTAG.
The JTAG-pins are obsolete as well, as the corresponding pins are much better available on the new second row.

As for WiFi, thanks for making it clear, that it connects to Serial1. I was under the wrong assumption (and I don't know, how I came to that) that it connects to Serial0 instead of the 16u2.
I changed that in the documentation V0.4.

As for AREF
The function is just the same:  The AREF PIN is unconnected by default and the MCU AVREF pin is connected to 3V3.
That can be changed with an jumper, connecting AVREF to the AREF-pin. If that is the case, the user has to deliver a reference voltage to that pin, otherwise Analog-In is unreliable.
The DUE has the bridge on the front realized with an smd zero Ohm resistor. You will find it close to the 16u2 JTAG, direction AREF-pin.
The digiX pin is for sure better to handle!

However: The DUE has just one capacitor more:  C34 (in the DUE schematics). 
What was the reason to omit that capacitor?

(see enclosed pictures)

As for nRF

Can you provide me here with the information, which pins on U$5 are connecting to where, as I need that for the completion and the schematics don't contain that information.
Furthermore: I believe, that CS for NRF should be changeable to an alternate pin (e.g. PB23) in a next revision, as PB21 (pin 52) can act as well as forth serial port or A12.

(see enclosed picture)

With all that info I believe, that the documentation will be beta very soon.

Regards

  gogol

EDIT:
Enclosed Version 0.5 of pinout documentation
as well the corresponding snippets from the DUE and digiX schematics regards AREF
as well the U$5 plug for nRF

[scm6079]

Does anyone know the current available on each of the I/O pins?   The Due has some pins with 15ma, others lower. 

Thanks to everyone who has worked to pull this thread + wiki page together - invaluable data!!

-Scott

[gogol]

Does anyone know the current available on each of the I/O pins?

Have a look at the PDF with the documentation!  All yellow pins are high-current pins, as you can read in the legend!

[digistump]

AREF - Capacitor was omitted I believe after reading the datasheet and deciding it wasn't needed - testing confirmed that.

nRF - diagram of pins attached

[gogol]

The nRF IRQ jumper can be used to connect the IRQ pin on the nRF24L01+ module to 51 - off by default as most libraries don't need the IRQ pin
...
the nRF module (when plugged into the low profile header that is for it) is connected as follows:
CSN - 52
CE - 51
MOSI, MISO, SCK - to the SPI pins
VCC to 3.3, GND to Gnd

does that mean, that PIN 8 of the nRF plug (IRQ) gets cross-connected to PIN 3 (CE), which is than connected to Pin 51 ?

[gogol]

Ok, looks like I found the correct pinmapping:

Pin51 via SJ5 to nRF-IRQ
Pin52                nRF-CSN
Pin53                nRF-CE

With this last missing piece, I think documentation is now in BETA-phase.

However:  It may still contain severe errors.  So don't rely only on this documentation, double-check with official documentation and in the digistump forums.

This documentation needs your feedback!  Please take part!

[scm6079]

Have a look at the PDF with the documentation!  All yellow pins are high-current pins, as you can read in the legend!

Thanks!  I noticed an important distinction from the DUE, PWM pin 13 is shown as low current on the PDF -- but is marked as high current on the due.  For anyone expecting pin compatibility - that may be an issue.  And is, in-fact, what spurred my original post as I was looking for high-current PWM sinks.

Thanks again,
 - Scott

[gogol]

I noticed an important distinction from the DUE, PWM pin 13 is shown as low current on the PDF -- but is marked as high current on the due.

When this is marked high on some DUE documentation, that is wrong for the DUE as well.
The high-low-current PINs are the same on DUE and DIGIX, as those are core features of the MCU.
According to the documentation http://www.atmel.com/images/icon_pdf.gif (chapter 46.1, page 1391) PB27 is in group 3, which are low current pins!
PWM13 is also digital13, where the DUE also has the onboard LED via transistor connected!

However, that is an perfect example, why you should double-check documentation.

[gogol]

I will attach from now on the most current version to the TOP of this thread.  As soon, as I believe, that it is stable, it should go to the Wiki.