I am writing a Python program that I would like to be able to run either on my Yun or my PC.
I came across this website that explains how to disable the Yun's use of bridge so that pyserial can work. Specifically it says to disable this line in /etc/inittab
# ttyATH0::askfirst:/bin/ash --login
followed by a re-login.
Has anyone here any experience of this, or any other advice on the subject?
...R
In case we need access console again (recover or whatever reason)
Work around (backup plan):
http://forum.arduino.cc/index.php?topic=191820.msg1679588#msg1679588
Thanks @sonnyyu. I have already done the expansion thing.
I haven't tried, but I presume I can also edit the files on the microSD on another PC to change the settings back to the original if I can't do it on the Yun.
I have the impression that the bridge is intended to allow the Arduino side to access Linux facilities. At the moment I can't see myself wanting to do that. My concept is to use the Linux side to control the Arduino side just as I do when my PC is connectd to an Uno. However, time will tell.
You say, in your reply "In case we need access console again" which leads me to think that the modification to /etc/inittab disables a console program - or perhaps it stops it being loaded at startup?. Is that correct?
If so, can it be started and stopped from the command line like any other program?
I would be very interested if anyone can share there experience of using a Yun with the bridge disabled.
...R
Robin2:
I haven't tried, but I presume I can also edit the files on the microSD on another PC to change the settings back to the original if I can't do it on the Yun.
You could do that if the PC knows how to read Linux style file systems. When you did the disk expansion, you created two partitions on the SD card: the system files are in one partition with an ext4 format, and the data files (/mnt/sda1) are in another partition with a FAT format. The files you would need to edit are in the ext4 partition.
A standard Windows installation cannot read ext4 partitions (though there are likely software packages available that can.) A standard Linux installation can read ext4 partitions. I assume a Mac an read ext4 parititions (but I have no experience with that, all my Mac experience is out of date and pre-dates the Linux based MacOS X.)
I have the impression that the bridge is intended to allow the Arduino side to access Linux facilities. At the moment I can't see myself wanting to do that. My concept is to use the Linux side to control the Arduino side just as I do when my PC is connectd to an Uno. However, time will tell.
Yes, the Bridge is generally driven by the sketch. However, you could have the sketch start a Linux process (using Process.runasynchronously()) and then that Linux process could communicate back and forth over the serial port. This is similar to what you are proposing, but likely not as efficient, but it still allows you to use the other Bridge functions such as having the sketch make outgoing web requests, respond directly to incoming web requests, or directly read/write files on the SD card.
You say, in your reply "In case we need access console again" which leads me to think that the modification to /etc/inittab disables a console program - or perhaps it stops it being loaded at startup?. Is that correct?
That line in inittab starts a program that runs a command interpreter on that port. It lets you use something like the YunSerialTerminal sketch to access the Linux command line when you can't get to the board over the network. By disabling that line, you still get the startup messages during booting, and you can still get access to uboot and preinit, but you won't be able to use that serial port to get to the Linux command line once it's up and running.
If so, can it be started and stopped from the command line like any other program?
Perhaps. But if you can get to the command line (presumably over the network with SSH) you already have a CLI interface, and you don't really need to start it on that serial port to get you out of trouble - you already have everything you would need. The value of having the command line on the serial port is to get you out of trouble when you have no other way to get to a command line. You'd be stuck at that point, since you don't have a command line where you could enable the command line on the serial port.
That's probably the main reason sonnyyu suggested the system expansion on to the SD card. You edit the inittab on the SD card, so when the system boots normally, the command interpreter on that serial port is disabled. But if you get into trouble, you pull out the SD card, reboot, and the system boots up with the original inittab that is stored on the flash file system on the board. Presumably, you didn't also modify that copy of initab, so the command line will now be present on the serial port.
Thanks for all your time, @ShapeShifter.
Sorry for wasting your time on the first point - I should have said that I use Linux all the time on my PC.
At the moment I don't envisage my Arduino code needing to make web-requests. That will be the role of the Python code.
if you can get to the command line (presumably over the network with SSH) you already have a CLI interface, and you don't really need to start it on that serial port to get you out of trouble
I am just wondering aloud about the possibility of restoring the usual bridge function without needing to reboot or relogin. At this stage the issue is of only minor interest - just trying to get the full picture.
Am I correct in thinking that you have not actually used serial to communicate from the Linux side to the Arduino ?
I wonder if anyone has?
Again, thanks.
...R
Some have, but I have not. But I know it's been discussed, because I've read it, and it is where a lot of my information is coming from.
I would probably put "ttyATH0" in the search box up top to look for posts about doing that. It's a safe bet that any thread that deals with the subject will mention that word somewhere, since it is essential information for getting that to work. It is also a term that won't be in too many other discussions, so you shouldn't have a lot of noise to weed through.
I am just wondering aloud about the possibility of restoring the usual bridge function without needing to reboot or relogin. At this stage the issue is of only minor interest - just trying to get the full picture.
At normal Linux, we need to send HUP single to init process to re-read /etc/inittab on fly using kill command. This is the only way to avoid reboot and make changes to the init configuration take effect immediately.
kill command to send HUP single
Type the command as follows after updating /etc/inittab, enter:
#kill -HUP 1
Here is the catch, openwrt's kill is busybox's package.
We need install standard kill
opkg update
opkg install coreutils-kill
/usr/bin/kill -HUP 1
If I were you, I will turn off and on power of Yun then take coffee or tea break and forget about it. 
I have disabled the line in inittab and routinely use ATH0 to communicate serially between the controller and linux chip.
I don't use the bridge software as I have created my own environment to do everything the bridge does and more.
heggood:
I have disabled the line in inittab and routinely use ATH0 to communicate serially between the controller and linux chip.
Thanks. That's good to know.
I infer from your reply that it all works smoothly and there are no gotcha's that I need to watch for ?
...R
Nothing negative so far. I've setup a process group on the linux side that interfaces with the serial. Each process is task oriented and communicates via shared memory, message queues and semaphores.
I published something about it early on, but was poorly received with criticism. Probably because my publication was premature. I only published at that time because I was hoping to attract contributors. Consequently, Only comment I got that it wasn't mature enough to consider. I learned my lesson well as Rick Nelson said "You can't please everyone, so you have to please yourself". La Da Da Dah.
heggood:
I published something about it early on,
Are you willing to post a link to it?
...R
Of course! The spirit of it from the outset was to attract folks with reflective thinking and birds with feathers! GitHub - cephalotus/avrbuddy: IPC based data interchange and transport for arduino yun
If that doesn't work for you try: heggood.com/FILES
heggood:
Of course! The spirit of it from the outset was to attract folks with reflective thinking and birds with feathers! GitHub - cephalotus/avrbuddy: IPC based data interchange and transport for arduino yun
Thanks. But that is all in C/C++
I don't do C/C++ except on the Arduino. The Yun can run Python.
...R