Go Down

Topic: Yun rev2 versus rev1 hardware Vin became 5V_OUT (Read 209 times) previous topic - next topic

JustVince

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!

pert

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
Quote
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).


JustVince

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:
https://www.arduino.cc/en/Main/Software

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

https://github.com/arduino/yun-go-updater

Quote
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.




ShapeShifter

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.

Quote
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.

Quote
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?

Quote
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.

Quote
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.

Quote
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]

JustVince

Hi ShapShifter,

Quote
The handshake was removed...
Quote
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:
Quote
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.

Quote
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  ;)

Thank you anyway!

ShapeShifter

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.

Code: [Select]
// 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():

Code: [Select]

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



Quote
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...

Quote
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.)

JustVince

#6
May 18, 2019, 08:41 pm Last Edit: May 18, 2019, 09:09 pm by JustVince
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
Code: [Select]

# 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
Code: [Select]

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


/etc/rc.local
Code: [Select]

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

Code: [Select]

//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 ...

Go Up