'systemctl stop serial-getty@ttyMFD2.service' does stop the getty on ttyMFD2 after booted, it just doesn't seem to be disabled by running 'systemctl disable serial-getty@ttyMFD2.service'
Regardless neither of those fix my access to ttyMFD2 properly.
I haven't used the second serial port for other purposes besides the terminal communication. I know that the terminal communication can be disable when you use Serial2 in the Arduino IDE so I checked the code used for that and I found two methods that I think they are what you are looking for.
The methods are called _detach_console() and _reattach_console(). You can find them in the file C:\...\arduino-1.6.0+Intel\hardware\intel\i686\cores\arduino\TTYUART.cpp. There are some useful comments too about the code. Go ahead and check them out, I hope you find them useful.
Thank you I will check that out! Maybe I can write a helper app to run in Linux which runs those methods on demand if nothing else.
The TTYUART.cpp is mostly useless because it has been written for sysVinit manager and the newest Yocto uses systemd. The _detach_console() works only because it kills all processes which use ttyMFD2, which in systemd can be acheive much easier by systemctl as you've already noticed:
systemctl stop serial-getty@ttyMFD2.service
The second useful thing taken from TTYUART.cpp is:
dmesg -n 1
which disables all kernel logs apart of the panic messages:
For example, -n 1 or -n alert prevents all messages, except
emergency (panic) messages, from appearing on the console.
Here is other thread regarding MFD2 for reference:
Thanks for the further detail.
This is pretty weird, then because it looks like the above works for folks. One thing I'll say is I can confirm that with 'bootargs_console quiet' my latest firmware edison also crashes, does not boot. So that's a new bug.
But having kernel/console quiet at boot it doesn't seem necessary for this use case either, it just matters that it's disabled before we access the device on serial2.
In my case I AM able to make this work if
1) systemctl stop serial-getty@ttyMFD2.service
2) dmesg -n 1
3) plug and then unplug the serial console cable one time
4) activate my serial device
5) run my app
Maybe something unique is how I'm activating my serial device.
I'm using the TXB0104 level shifter (https://www.sparkfun.com/products/11771) to go between edison and my 3.3v serial devices. And I'm using a 50k pull-down resistor tied to the output enable pin of that to keep my serial ports from transmitting until step 4 above. I bring the output enable high with a GPIO pin (GPIO46).
This all works great on ttyMFD1 and when I do the above steps, it does work for ttyMFD2. But unless I plug and unplug the serial console cable to USB port one time, I'm getting garbage.
I wonder what it could be. Maybe the FTDI chip on the breakout board is getting toggled when I plug and unplug the USB console cable and that has something to do with it?
Well, I have an odd fix for an odd problem.
If I apply a 50k pull-up resistor between +3.3v and VBUS on the FTDI Micro USB interface (the console one), guess what, it works. The noise on the serial line goes away (I viewed it to be a quite nasty noise on the oscilloscope) and it's all good.
Now this is kind of an annoying fix, because I don't see VBUS broken out to any of the pins on the breakout board. Hope I don't have to wire a USB pigtail for every prototype to address this!
I've been checking the schematic of the Edison Breakout Board and I was wondering from which pins you are using the Tx/Rx lines: from the USB connector or from the J17-5 and J20-3.
If you are using the signals from the USB connector (FTDI - USB interface); the noise might be because the VBUS line is gone. The FTDI chip needs the Vcc provided by the USB interface to work and make the proper conversion between the USB data and the Serial data. That is the reason why the noise is gone when you apply a pull-up resistor between 3.3V and VBUS. Check the picture below:
But, if you take the serial data directly from GP134 and GP135 I would say that the noise should not be there. The pins are available in the J17-5 and J20-3 of the Breakout Board. If the noise is still there even though you are using the Jx-x pins, the noise source might be the FTDI chip because it is not powered through the VBUS line. If this is the case I think the only way to solve it would be using a pull-up resistor just as you already did.
Oh, man, I cannot thank you enough for this. I have spent the better part of the last two days trying to get the Sparkfun UART block to work on UART2 with an XBee. I could get it to write, but not read with any consistency at all. I'm using Java, so I used the following commands: (This is my first time having to execute shell commands, so I'm sure this is sloppy. If anyone knows how to do it right, please chime in)
Process p = Runtime.getRuntime().exec(new String("systemctl stop serial-getty@ttyMFD2.service")); Process q = Runtime.getRuntime().exec(new String("dmesg -n 1"));
I am now reading and writing on UART2 with ease. Seriously, thanks so much to everyone on this thread. I was about to give up on this one.
can anyone help with how to properly add these commands at startup? I'll be running an application on a custom board with Edison that will talk to host PC over serial link (ttyMFD2). Application is written in C, but was looking how to disable it in Linux (not in my code). I saw in another thread that someone put these commands in a script and then called it from systemd, but I cannot find that thread now. Is this the "best" way to do it?
i found a simple way to do it at http://stackoverflow.com/questions/21596384/cannot-disable-systemd-serial-getty-service
so it seems that all steps are:
systemctl stop serial-getty@ttyMFD2.service
systemctl mask serial-getty@ttyMFD2
this works for me so far.