Yun rev2 versus rev1 hardware Vin became 5V_OUT

Hi,
I do not know why but VIN (input) on rev 1 has become 5V_OUT (so an output) on rev 2 but the name on the connector has not changed!
Similarly 5V has become an entry!

so to find the operation of my old shields, I simply replaced the diode D1 by a resistance of 0 ohm or a strap.
As far as I'm concerned I always mount a 5V regulator on the shield so the input is protected.

The diode is the first component on the bottom side starting from the VIN pin and following the track.

To your soldering iron!

I suspect the reason for the change is that the Yun doesn't have an onboard voltage regulator, so if someone tried to use the VIN pin as they would on a Leonardo/Uno/Mega, they destroy their board.

So the change was likely intentional, but it's extremely unfortunate that the label on the silkscreen and header was not updated to reflect that change. The situation is worsened by the lack of documentation on this topic. Actually, on the "Getting Started" page, the documentation is wrong:
https://www.arduino.cc/en/Guide/ArduinoYunRev2#toc7

you can apply power to the VIN and 5V pins on the board. If using the VIN pin, you cannot provide more than 5V, it will damage your board.

I guess they just copied that text over from the original Yun's Getting Started page, which contains the identical text (correct in that context).

Hello,
For my own needs, I continued to investigate thinking that it could still serve others.
Between revision 1 and revision 2, many components have been replaced by equivalents, so here we are only going to talk about functional differences that are of interest to the "maker".

The Arduino Yun 2 is shipped with the same MIPS-based, 400MHz Atheros AR9331 WiFi SoC, 64MB of DDR2 RAM, and 16MB of flash found on the Rev 1. The AR3991 chip’s built-in WiFi continues to be 2.4GHz 802.11b/g/n. Like its predecessor, the new model also offers a 16MHz Atmel ATmega32U4 chip running Arduino code, with 2.5KB RAM, 32KB flash, 20x DIO pins, 12x analog outputs, and 7x PWM interfaces.
The board is once again equipped with an Ethernet port, USB host port, and microSD slot. However, the 10/100 Ethernet port has been better integrated to the rev 2 board that avoids accidental short circuits when using certain Arduino shields.
The USB port has been flipped from vertical to horizontal to make for a more compact profile
these two improvements greatly facilitate the design and attachment of a personal shield.
But still that the space between the connectors is not at a space of 2.54! it remains a flaw to install a breadboard.
A micro-USB client port is used for a power input to the “much better, more robust power supply,” and and 4x LEDs are available. The board appears to have the same 73 x 53mm dimensions as the original.
And the location of the holes is as badly placed on one as on the other making difficult the fixing of a shield thanks to standard spacers !!

Regarding the electronic diagram, it has unfortunately not gained clarity or care and I think that a trainee should apply ...
Strangely, there are no more connectors, but to confuse the names of the headers have been changed
J11->J3
J12->J4
J10->J5
J9->J7

I already talked about the power supply VIN of the card and I will not go back on it, maybe precisely the fault to the trainee ... Moreover the HUB is not at 16MHz but 12MHz

Anyway the diagram shows a bi-directional protection by a resettable fuse if you use the micro USB port to feed your card the time of the focusing.
It would have been better to have a diode to protect your USB port I think.

The handshake was removed, making the feature at PE6/D7/INT6 available that was not completely free since this feature had not been documented.

In the same way the serial communication of the monitor by the micro USB and the GPIO 6 of the processor have been removed from the header.

Nothing to say about the Wifi module, which does not even appear on the diagram, just can we guess that it uses the pins P0_Tx+- / Rx+- Atheros. RJ45 “WAN” using P4_T +- / Rx+ -

Of course, the serial link wich is used by the bridge to communicated between the µP/µC through tty0/Serial1, and makes the strength of the YUN, has been maintained as well as the possibility of invalidating it by the GPIO 23 of the µP.

And the GPIO 18 always allows the µP to reset the µC.

Materially and functionally the two versions remain mostly compatible without much effort but it's a pity anyway.

Regarding the OS, revision 1 comes with “Linino” and revision 2 “LEDE” both come from OpenWrt but I admit that I do not understand the relationship between these two systems because the Linux side is very poorly documented.
See my post on the update.

https://forum.arduino.cc/index.php?topic=612524.0

Anyway, it does not seem silly to install on revision 2 an 1.5.3 software version with Linino available on the offical page:

Indeed, the updated version “LEDE” is not available on the Arduino site and seems more in the state of development than release (Available on GitHub).

Due to continuous improvements and suggestions coming from both the OpenWrt community and the Arduino community, version of OpenWrt-Yun installed on your Yún rev. 2 may be out of date. Please check the upgrade tutorial and be sure you're running the latest version available.

https://www.arduino.cc/en/Tutorial/YunSysupgrade

That website does not make the difference between a Yun Rev 1 with linino 1.5.2 and a Yun Rev 2 with LEDE 17.11 ...
Very weird!

For the moment, I have not managed with this version to completely inhibit the bridge that seems to interfere with my μC / μP C exchanges on the Serial1 ATMega / ttyATH0 Atheros port:
See :

https://forum.arduino.cc/index.php?topic=557667.0

As a general conclusion, the Linux side remains very poorly documented for both versions (Applications Startup, Bridge Usage, Python, C / C ++ and GPIO access / use) for the hobbyist and even the professional in electronic. Perhaps more clear for a linux developer.

I think the community may be losing interest because of that!
And I only have the excellent "Arduino meets linux” to recommend.

Good luck to you.

JustVince:
For my own needs, I continued to investigate thinking that it could still serve others.

Thanks for doing the research, and for posting your findings! I'm sure it will be helpful to someone.

The handshake was removed, making the feature at PE6/D7/INT6 available that was not completely free since this feature had not been documented.

I'm sad to see this go, I made extensive use of that signal in my projects. There is no official documentation on it, but I found it pretty easy to derive the use of it from the schematics.

In the same way the serial communication of the monitor by the micro USB and the GPIO 6 of the processor have been removed from the header.

I don't understand what you're saying here. On the original schematic, I see GPIO 6 going through the same level shifter as the handshake line. I never really paid much attention to this, that it goes to a 5V test point. But I don't know what you mean about the monitor and the micro USB?

Nothing to say about the Wifi module, which does not even appear on the diagram, just can we guess that it uses the pins P0_Tx+- / Rx+- Atheros. RJ45 “WAN” using P4_T +- / Rx+ -

There is no separate WiFi module. The WiFi and Ethernet interfaces are built into the Atheros processor. They are one and the same. The Atheros processor actually has 5 Ethernet interfaces on it - it is basically a complete WiFi/Ethernet router on a chip.

Regarding the OS, revision 1 comes with “Linino” and revision 2 “LEDE” both come from OpenWrt but I admit that I do not understand the relationship between these two systems because the Linux side is very poorly documented.

Actually, there are two different "original" Yuns. The board was originally markets and sold by Arduino.cc (this site.) The, there was a rift between the Arduino founders, and it split into two independent companies, the second one using the web site Arduino.org. My recollection is that when it was sold by Arduino.cc, it came with a variant of OpenWRT (at least, that's what's on the ones I have.) Then, when the split happened, Arduino.org had the production capability to make more, but there may have been a problem with the software rights (my own speculation) and boards sold by Arduino.org were shipped with Linino, a somewhat different version of the Linux software. The two companies have reconciled and recombined, and now we have the Rev 2 (which seems to me it's based more on the Dragino Yun Shield?) and yet a third distribution.

The worst part of all of this confusion is that the official documentation has not been updated. There are clearly some differences between the boards, and what software can run on which version, but that does not seem to be explained anywhere. It's a pity.

I think the community may be losing interest because of that!

I don't know if that is cause or effect. Has the documentation hindered adoption of the Yun, or has the Yun fallen out of favor and therefore the documentation is not being updated?

When the Yun first came out, there was some initial excitement about it, and a bunch of people actively using it, discovering how to do things, and updating the documentation. But it never seemed to be very widely used outside of a core group of people - perhaps because it was too different from the other Arduino boards and not embraced by those with limited Linux experience? Also, it was very expensive, and while Rev2 is significantly less expensive, it is still more expensive than more powerful Linux systems like Raspberry Pi, so it has limited adoption by the Linux users.

I'm guessing I'm a fairly typical Yun user: I was initially very enthusiastic about them, bought four of the original ones, and used them on a variety of projects: two "permanent" ones and two for various experimentation and temporary projects. But now, there are improved WiFi modules, more powerful 32-bit Arduino boards, and the Yun doesn't have as much appeal - I still use them occasionally, but they are no longer the first board that I reach for.

Recently, I haven't been able to resist using the very capable and inexpensive Raspberry Pi Zero W for embedded processors, and a Raspberry Pi 3 B+ with PoE for the ones that need more capability. Given how "dead" this forum has been recently, I would guess I am far from unique in moving away from the Yun. With less people using it, there is less desire to update the documents? With the documents not been updated, there are less people interested in using it? It seems to be a vicious circle, and a self-fulfilling prophecy.[/quote]
[/quote]

Hi ShapShifter,

The handshake was removed...

I'm sad to see this go, I made extensive use of that signal in my projects.

Any exemple in C/C++ or python? Thanks

by:

In the same way the serial communication of the monitor by the micro USB and the GPIO 6 of the processor have been removed from the header.

I meant that D+/D-, LED2, and GP6 have been removed from the J9 header (Vin,5V etc...) off Rev1.
In the corner near the USB. The signals were visible on the header but not on the schematic...

Regarding the wifi, thanks to your precision, then it is not P4_TX / RX that is used but directly the antenna "ANT1" which, unless I'm mistaken, did not appear on the diagram of revision 1.

The two companies have reconciled and recombined, and now we have the Rev 2

it's good to read it but so the revision 2 is not a celebration at the height of the event ...especially speaking of the OpenWrt / Lede distribution and its updates.

upgrade firmware openwrt yun rev2

and

Yun 17.11 Reboot prerelease

Finally, it is true that the RPI is very popular and well documented.
If it is ideal for small applications like Multimedia / IOT / PC / Server / Retrogaming ...,
it must still add additional modules (cap / shield) to have professional-level physical applications while a microcontroller does it natively (capture modules, interrupts, high speed PWM, SPI / UART / I2C, timer and especially real time and 6 ADC...)
I will also recommend the Beagle Bone Black / green for linux enthusiasts and the Nucleo / STM32 + Cube for microcontroller programmers in C / C +.
But I chose the yun because I was a beginner and not at all comfortable with linux to make IOT
But we go beyond the scope of this topic :wink:

Thank you anyway!

JustVince:
Any exemple in C/C++ or python? Thanks

Take a look here: Making sense of the YUN wifi and the Linino configuration.

Based on ideas from other users (for example, HERE), I have since modified it so that while waiting for the handshake line to go active, it copies any data received on Serial1 to Serial, so that Linux bootup messages can be seen on the USB serial port.

// Macros to simplify output control
#define  GREEN_LED_IS_ON      (digitalRead(GREEN_LED_PIN) == HIGH)
#define  GREEN_LED_ON         {digitalWrite(GREEN_LED_PIN, HIGH);}
#define  GREEN_LED_OFF        {digitalWrite(GREEN_LED_PIN,  LOW);}
#define  GREEN_LED_TOGGLE     {digitalWrite(GREEN_LED_PIN, !digitalRead(GREEN_LED_PIN));}
#define  RED_LED_IS_ON        (digitalRead(RED_LED_PIN) == HIGH)
#define  RED_LED_ON           {digitalWrite(RED_LED_PIN, HIGH);}
#define  RED_LED_OFF          {digitalWrite(RED_LED_PIN,  LOW);}
#define  RED_LED_TOGGLE       {digitalWrite(RED_LED_PIN, !digitalRead(RED_LED_PIN));}


// Echo boot messages to the serial port.
// Echos up to the specified number of milliseconds.
void echoBoot(unsigned long int delay)
{
   unsigned long int time = millis();
   while ((millis() - time) < delay)
      if (Serial1.available())
         Serial.print((char)Serial1.read());
}

And then later on, in the middle of setup():

   GREEN_LED_ON;
   RED_LED_OFF;

   Serial.println();
   Serial.println(F("Sketch startup..."));
   Serial.println();
   Serial.println();

   // Initialize the Serial debug port
   Serial.begin(115200);

   // Initialize the serial port to the Linux side so we can echo characters.
   Serial1.begin(250000);

   // Give a delay for the AR3391 to reset, in case we were reset as part of a reboot command.
   // See http://playground.arduino.cc/Hardware/Yun#rebootStability, case 3.
   // 20 loops of 250ms flashing gives 5 seconds - more than enough
   for (int i=0; i<20; i++)
   {
      echoBoot(250);
      GREEN_LED_TOGGLE;
      RED_LED_TOGGLE;
   }

   // Wait for the ready pin to go low, signaling that the AR3391 is fully booted.
   // This code requires the following addition to /etc/rc.local:
   //
   //  # Added section to set the handshake line.
   //  # GP19 is connected to D7 of the 32U4 processor.
   //  # This requires setting GP22 high to enable the U7 level shifter.
   //  # This GPIO is already exported.
   //  # Then GP19 needs to be exported, set to output, and finally brought low.
   //  echo 1 > /sys/class/gpio/gpio22/value
   //  echo 19 > /sys/class/gpio/export
   //  echo "high" > /sys/class/gpio/gpio19/direction
   //  echo 0 > /sys/class/gpio/gpio19/value
   Serial.println();
   Serial.println();
   Serial.println(F("Waiting for the handshaking pin..."));
   Serial.println();
   Serial.println();


   while (digitalRead(READY_PIN))
   {
      echoBoot(100);
      GREEN_LED_TOGGLE;
      RED_LED_TOGGLE;
   }
   // When this point is reached, AR3391 is ready.

   Serial.println();
   Serial.println();
   Serial.println(F("Linux ready, starting Bridge..."));

   // Signal that the bridge is starting up
   GREEN_LED_ON;
   RED_LED_ON;;
   Bridge.begin();
   RED_LED_OFF;

   Serial.println(F("Bridge started."));

I meant that D+/D-, LED2, and GP6 have been removed from the J9 header (Vin,5V etc...) off Rev1.
In the corner near the USB. The signals were visible on the header but not on the schematic...

I guess I'm being slow, but I still don't follow. Are you saying that the USB data lines, LED2, and Linux GPIO6 are connected to J9 (the 8 pin shield header with all of the power connections)? How is that possible?

Or are you saying that TP27/TP28 (USB D+/D-) and TP46 (GPIO6) are located near J9 (I don't know where they are physically located) and these are not available on Rev2? Without the physical location of those test points being documented, they have limited utility, but if you can figure out where they are, I can see where they could be useful. But I still don't understand the LED2 reference, oh well...

Regarding the wifi, thanks to your precision, then it is not P4_TX / RX that is used but directly the antenna "ANT1" which, unless I'm mistaken, did not appear on the diagram of revision 1.

P4_TX/RX are the Ethernet signals that go directly to the RJ-45 connector. P4 is one of the set of ethernet PHY interfaces.

The Rev2 schematic does show than signal coming from the Linux system chip to the antenna, while the Rev1 schematic doesn't show this (while it's many more pages than the Rev2 schematic, it does not show full details of the Linux system chip. Neither schematic is ideal. (Is it just me, or are the light green traces and overlapping pin circles on the Rev2 schematics hard on the eyes? My eyes water and go blurry after just a few seconds of looking at it.)

Hi,
Regarding the header, see my first attachment it may be clearer.

A lot of valuable information in these topics.
Incidentally, I do not understand why, while it is the same function (signal + enable) GP19 need to be exported unlike GP22?
But that's part of the mysteries of linux ...

/etc/rc.local

# Added section to set the handshake line.
# GP19 is connected to D7 of the 32U4 processor.
# This requires setting GP22 high to enable the U7 level shifter.
# This GPIO is already exported.
# Then GP19 needs to be exported, set to output, and finally brought low.
echo 1 > /sys/class/gpio/gpio22/value
echo 19 > /sys/class/gpio/export
echo "high" > /sys/class/gpio/gpio19/direction
echo 0 > /sys/class/gpio/gpio19/value

Anyway GPIO22 and GPIO19 are no longer!
And we will have to consider another mode of synchronization and communication.
Indeed, see my topic:

How to disable the Bridge on Yun Rev2

with the bridge disabled (I specify)

/etc/inittab line commented

#ttyATH0::askfirst:/bin/ash --login  (quote it in order to disable the Bridge)

/etc/rc.local

echo 0 > /proc/sys/kernel/printk  (add this line in order to prevent unexpected messages)

the link "Serial1" suffers from a jitter (between 210 and 270 kbps) which generates framing errors on the arduino side for a configuration of 250kbps with the distribution Lede 17.11.
Second and third attachment.
while it works at 115 kbps.
which involves using the link at 115 kbps instead of 250 kbps

//Serial1.begin(250000)
Serial1.begin(115200)

I realize that the disappearance of the handshake could potentially be a tragedy.
And I'm looking for C / C ++ or python code to make a fast and reliable MCU/MPU synchronization AND data communication via the SPI ...

JustVince:
Regarding the header, see my first attachment it may be clearer.

That does help! I've never seen a shield connector with the extra pins like that. None of mine have it, and none of the pictures of Yun's that I've seen have it.

Is your board from Arduino.cc, Arduino.org, or somewhere else?

I did an image search, and I did find one picture that had the header you mention, on a clone board: TURQUOISE BOARD ARDUINO YUN COMPATIBLE- Based on the ATmega32u4 microcontroller and the Atheros AR93 Perhaps you have one of these clone boards, and not an official Arduino board? being a clone, I guess that's why those pins don't show up on the official schematics.

Incidentally, I do not understand why, while it is the same function (signal + enable) GP19 need to be exported unlike GP22?

I have no idea. I just know that GP22 was already exported on my units, and if I tried to export them again, I would get an error message. Perhaps it's because GP22 is dedicated as an output to control the level shifter chip output enable, so they figured it was safe to initialize it as an output. But GP19 is the data signal passing through the level shifter, and it could be used as either an input or an output. Since they don't know how it would be used, they don't initialize it ahead of time?

the link "Serial1" suffers from a jitter (between 210 and 270 kbps) which generates framing errors on the arduino side for a configuration of 250kbps with the distribution Lede 17.11.

That's rather disturbing! Seems to me that it would make all Bridge communications unstable on Rev 2 boards.

And I'm looking for C / C ++ or python code to make a fast and reliable MCU/MPU synchronization AND data communication via the SPI ...

Seems like it would be a matter of first turning on the output enables for the level shifter pins, and setting up the appropriate pins as inputs and outputs. On the '32U4 side, you should be able to use the SPI hardware interface, but on the Linux side you will need to bit-bang the interface, as it is not using SPI hardware on that end. It will take some research to see if there is an existing bit-bang driver you can use, or if you will have to do all of the bit twiddling yourself. If it's the latter, it's fortunate that SPI is a very easy protocol to manually bit-bang. I would make the Linux side the master, so that it has control of the clock, which will make the timing easier. Unfortunately, if you are looking for raw speed, bit-banging the interface is not the fastest way to go.

Hi,

@ShapeShifter,

no I confirm, this is an official brand "arduino.org" see attachment.

I was inspired by your example and others.
And so the pins GPIO8, 11, 26 or 27 can still be used to make a handshake provided you validate the level shifter outputs by exporting and setting high the GPIO21 pin of the Atheros.

example with the "D17/PB0/RxLED/SS" of the ATMega.

Add these lines to your /etc/rc.local

export 21 > /sys/class/gpio/gpio21/export
echo 1 > /sys/class/gpio/gpio21/direction
echo 1 > /sys/class/gpio/gpio21/value
export 26 > /sys/class/gpio/gpio26/export
echo 1 > /sys/class/gpio/gpio26/direction
echo 1 > /sys/class/gpio/gpio26/value

Then I created a code and a sketch in C to connect the processor (Master) with the microcontroller (slave) through the SPI.
It would be useful for someone to translate it into python on the linux side...
See attachment.

Thanks

ATmega_SPI_Slave_Hardware.ino (1.99 KB)

Atheros_SPI_Master.c (4.09 KB)

Atheros_SPI_Master_py.txt (227 Bytes)

JustVince:
no I confirm, this is an official brand "arduino.org" see attachment.

Interesting! I've never seen or used the .ORG boards, all of my Yuns are the original revision .CC boards. At the time that a few of the Arduino founders split off and formed the .ORG group, there were many people coming here to this forum for help with .ORG boards, but the help we could give was limited because there were some definite differences between the original .CC boards and the later .ORG boards. I thought the differences were primarily software, but it looks like there were some significant hardware differences.

Since your board was produced by what was at the time a different company, it's not much of a surprise that the hardware doesn't match the schematics that you will find there on this site. I never went looking for schematics over on the arduino.org site, so I can't say if their schematics contained the level of detail that shows these extra header pins.

Interestingly, I did an image search again, and paid more attention while looking for boards that has the arduino.org identifier. And what do I find in the retired products section of this arduino.cc site, but a picture of an arduino.org board with the pads for the extra pins, but no header installed in them:

Then I created a code and a sketch in C to connect the processor (Master) with the microcontroller (slave) through the SPI.

Very nice! So it looks like there is a SPI device driver on the Linux side that uses the software bit-bang interface. I know that avrdude uses a software SPI interface to load a sketch onto the '32U4 processor, but I didn't know whether the bit-banging was inside of avrdude, or if it used a software interface device driver. I guess it was the latter.

What data transfer rates are you able to sustain? I see you set the clock speed to 4 MHz, which would give a theoretical maximum of 500,000 bytes per second. But that doesn't mean that the Linux side can transmit the data that fast, nor that the sketch side can receive the data that quickly without dropping bytes. (After all, that only leaves 24 clock cycles for the '32U4 to process each byte, which ain't much! :o )

Hi,

I do not understand the war between “.org” and “.cc”, and I hope that the conflict is over because that is where most of the problems I encounter with YUN are today!

Indeed, at the beginning, with a rev1 & linino, I had bypassed the bridge to exchange the data faster through the UART. But I did not succeed with the rev2 & Lede. That's why, I tried to exchange by the SPI. Unfortunately, on the contrary, if my code works on rev2 & lede , it fails on rev2 & linino:

Echo 26> / sys / class / gpio / export => Busy
Unable to set mode 0 ...

Attached is a capture of the signal configured at 4Mhz. And indeed, we see that the frequency is not reached or even not configurable (0,6 MHz)...
By cons, my program works because I do not exceed the frequency recommended by the datasheet of 32u4 (Fosc / 4 = 16MHz / 4 = 4MHz) and that I transmit byte by byte.
So to emit longer frames it gets hard ...

I would appreciate to see the code of avrdude...

JustVince:
I do not understand the war between “.org” and “.cc”, and I hope that the conflict is over because that is where most of the problems I encounter with YUN are today!

It was a dark time in the Arduino community, and not the proudest moment for the companies behind the name. Here's a little reading, it shouldn't take much searching to find a lot more information: Arduino V Arduino: Part II | Hackaday

I would appreciate to see the code of avrdude...

I'm sure it's in the public domain, probably on GitHub. I wouldn't think you would have much trouble finding it.

JustVince:
I do not understand the war between “.org” and “.cc”, and I hope that the conflict is over because that is where most of the problems I encounter with YUN are today!

It's over long ago:

Well, OK, there was one last battle, but still long ago:

We are left with the legacy of some poorly supported hardware that .org created during their short existence.

JustVince:
I would appreciate to see the code of avrdude...

You can browse the official AVRDUDE repository here:
http://svn.savannah.gnu.org/viewvc/avrdude/
You can download the release versions of the official AVRDUDE here:
http://download.savannah.gnu.org/releases/avrdude/

Arduino uses a modified version of AVRDUDE. The source code is currently hosted here (though this is only intended to be temporary while they wait for some patches to be merged in the mainline AVRDUDE):

Arduino's AVRDUDE build script with patches for their modifications is here:

Thank you for your feedback,
So I discovered after some research in the source files that there is a file "spi-gpio-custom".
So in fact the atheros only has one SPI that is already used to read flash memory.
The second SPI is virtual and obtained by GPIO status changes.
This explains that system calls "ioctl" can not configure the speed of the SPI ...
So I created a github, not yet updated, on SPI or UART communication between arduino and atheros ...
Best regards.

I have a Yun Rev 2 and a Braccio arm shield. The Braccio shield has a switch for its power supply to provide power to the Arduino via "Vin" or "5V". Obviously "Vin" no longer works for the Yun Rev 2. Do I dare risk providing the Braccio power to the "5V" pin on the Yun Rev 2, or just stick with also needing USB power to the Yun board (as well as the Braccio arm shield power supply)?

Thanks for the useful information JustVince..
It's good you shared your findings.
Karma++;

That int.6 part is interesting for me. For a project we have PCBs that were designed for the rev 1. Latest changes were made just for that int.6 use.
I must investigate how that affects our project when using a rev2 Yún.

edit: My multiple rev 1 Yúns also do not have those extra pins at the end. I also checked the schematics in search for an interrupt line i could use.. like ShapeShifter did.

pert:
Actually, on the "Getting Started" page, the documentation is wrong:
https://www.arduino.cc/en/Guide/ArduinoYunRev2#toc7I guess they just copied that text over from the original Yun's Getting Started page, which contains the identical text (correct in that context).

This documentation error has now been fixed:
https://www.arduino.cc/en/Guide/ArduinoYunRev2#please-read