How to access Pin 7 from linux

Hardware Arduino Yún
#1

Hi
I think I came to the point I want to use pin 7 to control the sending of serial messages from the arduino part of the yun.
I also think I know all there is to know except for ....
How to access pin 7 from linux.

I currently think that the "disable leonardo to send messges" script on the linux will look like

echo 18 > /sys/class/gpio/export
echo "high" > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value

But 18 is for the reset pin. What number do I need to use for pin 7?

Best regards
jantje

#2

I run through them one by one.
It seems to be 19
The direction seems to give an error. So I will continue with

echo 19 > /sys/class/gpio/export
echo "out" >/sys/class/gpio/gpio19/direction
echo 1 > /sys/class/gpio/gpio19/value

to set pin 7 high and

echo 19 > /sys/class/gpio/export
echo 0 > /sys/class/gpio/gpio19/value

to set it low

Note that the first line is only needed once so it will give an error. It works fine tough.
By setting the pin high in /etc/rc.local just before the exit 0 you can simply check the pin 7 state to know whether the linux part of the yun is up and running.
I think this will cover all cases if you add a reset-mcu to the reboot command.
But it is probably saver to set pin 7 low then call reset-mcu and then reboot

I hope this was helpful for others
Jantje

#3

I think you have some issues here...

First off, you are exporting (enabling for control) GP22, then in the next line you're controlling GP21. You've got your signals mixed up there.

Then you seem to have some confusion over the signals:

  • GP19 is the AR3391 signal that is routed as the handshake signal to the '32U4 processor's shield pin 7.
  • GP21 is the output enable for a level shifter that buffers the SPI signals between the two processors. (U5 on schematic sheet 4)
  • GP22 is the output enable for a level shifter that buffers the handshake line between the processors. (U7 on schematic sheet 4)

I wrote a fairly lengthy description of controlling that line HERE which includes code both on the Linux side to control the handshake line, and on the sketch side to wait for the signal to be active.

The Linux side code is:

# 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

The first thing it does is turn on the level shifter using GP22.

Then it exports GP19 so that it can be controlled. (GP22 is already exported by default, it does not need to be re-exported unless you unexport it at some point.)

Next, it sets GP19 as an output.

Finally, it sets the output low.

Up until this point, with the level shifter disabled, the output has been floating. By programming the sketch such that pin 7 is an input with pullup resistors, that floating signal is read as a high. Once the code above runs, the output is driven low, and the sketch reads it as a low.

The level shifter should be bi-directional, so it should also be valid to set GP19 as an input, and pin 7 as an output, and have the Linux side read the data that the sketch outputs.

Note that the code above is designed to run only once (I put it in /etc/rc.local so it runs once after booting is done.) I used it as a signal that Linux is fully booted, and the sketch can use the serial port without fear of interrupting the boot process. If you want to use the signal for more than that, of the four lines of actual code, the first three should only be done once. Then you can echo 0 or 1 to /sys/class/gpio/gpio19/value as needed.

#4

I noticed more was going on and the above is not stable
Thank you for the input. This was exactly what I was looking for and did not find.
I see you set the flag on 0. When I test on my yun 0 is low on pin 7.
I would assume the pin to be low by default.
Do you set it high somewhere else or should that be 1?

Best regards
Jantje

#5

oeps sorry I missed the last part
Thank you very mutch

#6

Txs for the help. I’m glad to see my boot documentation helped someone out and got even referenced.

  // 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.
  delay (2500);

However I found a way that better suits my needs. And probably yours as well.
My setup starts with

void setup()
{
	waitForYunToBoot();
...//your code

And waitForYunToBoot looks like:

void waitForYunToBoot()
{
	pinMode(7,INPUT_PULLUP);
	delay(20);
	while(digitalRead(7)==HIGH) //wait for yun to startup
		{
    // The pin is still high, so give the LED a quick flash to show we're waiting.
    digitalWrite(LED_BUILTIN, HIGH);
    delay(100);
    digitalWrite(LED_BUILTIN,LOW);
    delay(100);
		}
}

As you can see this is nearly your code but I only have a delay of 20ms :slight_smile:
This is possible because I modded the reboot script to

echo 1 > /sys/class/gpio/gpio19/value
reset-mcu
/sbin/reboot

By setting pin 7 high the delay before the reboot becomes unimportant. I’m not even sure the 20ms delay is needed.

Txs again
Jantje

#7

I have done a similar “dual processor reset” modification to the reboot command. I agree that the delay is probably not needed, but it doesn’t hurt. Even the 2.5 seconds delay is trivial compared to the time it takes Linux to boot - that delay is lost in the noise. The main reason I left it in is in case /sbin/reboot takes some time before the processor is physically reset and the line becomes floating again. Belt AND suspenders - better safe than sorry.

PS: I have pointed many people to that boot stability article… good stuff.

#8

ShapeShifter:
Even the 2.5 seconds delay is trivial compared to the time it takes Linux to boot - that delay is lost in the noise.

I know, but I use reset-mcu and upload sketch quite often. So saving 2.5 seconds (on top of lots more) is appreciated.
without the

echo 1 > /sys/class/gpio/gpio19/value

in the reboot the 2.5 seconds are needed.
It looks like the leonardo is rebooted before the linux is closed down.
Have you een trying to get those changes in the arduino code?
Jantje

PS thanks for the nice words

#9

Jantje:
I know, but I use reset-mcu and upload sketch quite often. So saving 2.5 seconds (on top of lots more) is appreciated.

Well, then, you have a different use case than I. No wonder we have different needs and opinions. :wink:

It looks like the leonardo is rebooted before the linux is closed down.

Yes, the '32U4 will reboot much faster. Setting the handshake line high is one potential solution, adding a delay is another. I’ll have to give it some thought whether setting the line high covers all potential situations…

Have you een trying to get those changes in the arduino code?

No, I don’t see it being widely applicable, I see it as more of a specials needs solution. If it were added to the mainstream code, then it would tie up one of the precious few shield pins that might be needed for something else. Unless you know your application can specifically spare pin 7, I see this solution as just causing potential conflicts if used universally.

#10

ShapeShifter:
No, I don't see it being widely applicable, I see it as more of a specials needs solution. If it were added to the mainstream code, then it would tie up one of the precious few shield pins that might be needed for something else. Unless you know your application can specifically spare pin 7, I see this solution as just causing potential conflicts if used universally.

I'm not so sure about that. I have seen numerous posts about the yun and pin 7 not functioning (as expected) which was explained as "it is connected to the AR3391 so don't use it" http://forum.arduino.cc/index.php?topic=188733.0
And even if it is a problem one could disable pin 19 on linux once the ttyATH0 starts pouring messages :slight_smile:

That was in the first days of yun when I was still very active on this part of the forum. It may have been fixed in later versions of the os. If so I agree with your statement, if not I think we should give it a try.

Jantje

ps I even remember federico asking to make a note of this use for the pin 7 not to forget it.

#11

Jantje:
I have seen numerous posts about the yun and pin 7 not functioning (as expected) which was explained as "it is connected to the AR3391 so don't use it"

Your experience on this forum goes back a lot farther than mine, so I don't doubt what you're saying. But in the eight months since I've been active here, I don't recall a single problem like that being reported. So, maybe something has changed during the intervening time?

On the other hand, there have been several reported issues from people trying to use pins 0 and 1 for various purposes, and running into problems because of the bridge communications lines. I just fear that implementing pin 7 now could trigger a bunch of similar new problem reports.

I'm not trying to talk you out of it if you want to pursue it, but I have no interest in doing so (or the time to do it.) Perhaps a compromise is a set of scripts being put in place to make the line functional. By default they are not enabled, but it includes a way to easily enable that functionality if people want it?

A possible implementation could be:

  • On the basic configuration screen, where there are the radio buttons for controlling RESTful API authentication, there could be another set of controls to enable pin 7 handshaking (off by default.)
  • In the Arduino Bridge library, there could be a new function Bridge.waitForHandshake() that sets up pin 7 for input and waits for it to go active. Maybe it could have an optional parameter for an LED PIN number to blink while it's waiting?

Just an idea for a compromise to get the thought processes going...

#12

I made a github issue pin 7 to report status from linux to yun. · Issue #39 · arduino/openwrt-yun · GitHub

#13