--- Thu Oct 9 2014 | 00:00 | |
DocScrutinizer05 | hey, maybe somebody here can help me out. Trying to control a PSU (PPS-11xxx Voltcraft http://www.reinhardweiss.de/german/sonstiges.htm) via shell, and everything finally works with "echo -e GMOD\r >/dev/ttyUSB0". But I can't for the life of mine find the right stty setting to set up the tty so it does convert <ENTER> into a "\r" (e.g. a "cat >/dev/ttyUSB0" simply doesn't work, no matter what I do via stty). Am I suffering some | 14:13 |
---|---|---|
DocScrutinizer05 | misconception there regarding what stty can do and that it maybe doesn't work at all for cat>somwehere, or is there a trick how to use the stty parameters? | 14:13 |
DocScrutinizer05 | in short: what do I need to do so the "\r" in "echo -e GMOD\r >/dev/ttyUSB0" is not needed anymore? | 14:15 |
roh | DocScrutinizer05: forget stty and similar pita. (serials termios suck).. take pyserial and hack up a python script | 15:04 |
roh | also some drivers forget the settings on serial close, so you cannot properly set stuff on shellscripts | 15:04 |
DocScrutinizer05 | well, you can, opening tty on evak on fdN | 15:05 |
DocScrutinizer05 | eval 4<ttyUSB | 15:05 |
DocScrutinizer05 | been there, done that. but it seems stty and/or ioctl of tty doesn't work like supposed to | 15:07 |
DocScrutinizer05 | I wrote a stepper motor controller a while back, and I ran into exactly same problem back when. Seems tty doesn't obey what man 1 stty suggests onlcr etc are supposed to accomplish | 15:09 |
DocScrutinizer05 | talk2controller(){echo -en "$@\r"} | 15:11 |
DocScrutinizer05 | which is kinda insane | 15:11 |
DocScrutinizer05 | tty driver SHOULD handle this | 15:11 |
DocScrutinizer05 | I wasted 4 hours trying to talk to that sucker PSU via minicom | 15:13 |
DocScrutinizer05 | no luck, probably just because I wasn't able to terminate COMMAND by \r | 15:14 |
DocScrutinizer05 | there must be a bug in tty driver since 2007 | 15:15 |
DocScrutinizer05 | at least | 15:15 |
DocScrutinizer05 | but hey, you might be right, I tried to set ourput properties before output channel (fd) been opened | 15:18 |
DocScrutinizer05 | nope :-/ | 15:22 |
DocScrutinizer05 | I seem to recall some settings in /dev/tty* were sticky and stty didn't take effect on second time. But I forgot what to do to reset the tty, except the obvious powercycling | 15:23 |
DocScrutinizer05 | sounds like http://stackoverflow.com/questions/7812142/how-to-toggle-cr-lf-in-gnu-screen >>In the past, onlcr didn't work on USB to serial adapters using the pl2303 driver. That bug has been fixed, but some devices use old Linux kernels. dreamlayers Nov 1 '11 at 2:26<< | 15:28 |
DocScrutinizer05 | or like this: http://stackoverflow.com/questions/10068886/expect-script-not-sending-new-line-correctly | 15:36 |
eintopf | https://www.youtube.com/watch?v=J7K91g8yG_w | 16:20 |
DocScrutinizer05 | LOL | 17:28 |
wpwrak | i'm speechless :) | 17:33 |
kyak | every kid's dream :( | 17:35 |
wpwrak | DocScrutinizer05: (serial) roh has a good point there - you often need more control over the comm channel with this sort of devices than you may expect. it's VERY common to run into subtle communication problems. | 17:49 |
DocScrutinizer05 | ok, now I know *I* have a problem (=bug), not stty. | 17:49 |
wpwrak | heh, good timing, eh ? :-) | 17:49 |
DocScrutinizer05 | yep | 17:49 |
DocScrutinizer05 | echo -e 'GETD\r' >/dev/ttyUSB0 | 17:49 |
DocScrutinizer05 | works | 17:49 |
DocScrutinizer05 | echo -e 'GETD' | tr \n \r >/dev/ttyUSB0 | 17:49 |
DocScrutinizer05 | doesn't | 17:49 |
wpwrak | and yes, what i meant is bugs :) e.g., my fluke sometimes fails to answer. then you have to restart the connection. but that sometimes fails too, but only after the next operation. | 17:50 |
wpwrak | the rigol DS1xxxCD has a whole catalog of such issues, apparently caused by lack of internal flow control. `C, ~D, and ~E probably, too. (same platform) | 17:51 |
wpwrak | these are the two i use(d) the most. so i know their bugs best. i think the picotest DMM (usbtmc) also has some quirks | 17:53 |
DocScrutinizer05 | well, whatever | 17:54 |
wpwrak | naw, you really want to know exactly which bytes are going over the line and when. with shell scripts you're at a far too high level. | 17:54 |
DocScrutinizer05 | I'm not able to grok what's going on with \r on my shell | 17:54 |
wpwrak | e.g., you'll probably also run into timing constraints. things like having to wait for the unit to process a command before it can accept the next (without overrunning buffers). etc. | 17:55 |
DocScrutinizer05 | echo -e 'GETDx\n' | tr x \r >/dev/ttyUSB0 fails | 17:55 |
wpwrak | you can see with strace what really happens underneath | 17:56 |
DocScrutinizer05 | is \r a delimiter that gets handled even in pipes? | 17:56 |
wpwrak | but it's easier just to write these things in C | 17:56 |
DocScrutinizer05 | or what? | 17:56 |
wpwrak | if you want a library that gives you access to such stuff, you could look here: https://gitorious.org/lab-tools/tmc | 17:58 |
DocScrutinizer05 | meh, escaping | 17:58 |
wpwrak | low-level comms in C, the rest in python. there's also lib/power.py with very simple power supply control | 17:58 |
DocScrutinizer05 | saturn:~ # echo -e 'GETDx\n' | tr x \r | od -xa | 17:58 |
DocScrutinizer05 | 0000000 4547 4454 0a72 000a | 17:58 |
DocScrutinizer05 | G E T D r nl nl | 17:58 |
DocScrutinizer05 | saturn:~ # echo -e 'GETDx\n' | tr x \\r | od -xa | 17:59 |
DocScrutinizer05 | 0000000 4547 4454 0a0d 000a | 17:59 |
DocScrutinizer05 | G E T D cr nl nl | 17:59 |
DocScrutinizer05 | \o/ I'm not completely braindamaged | 18:01 |
DocScrutinizer05 | saturn:~ # echo -e 'GETD\n\n' | tr \\n \\r >/dev/ttyUSB0 | 18:01 |
DocScrutinizer05 | saturn:~ # 040200000 | 18:01 |
DocScrutinizer05 | saturn:~ # echo 'GETD' | tr \\n \\r >/dev/ttyUSB0 | 18:02 |
DocScrutinizer05 | saturn:~ # 040200000 | 18:02 |
DocScrutinizer05 | alas this still doesn't explain why damn stty reduses to do same like tr does, despite | 18:04 |
DocScrutinizer05 | * [-]onlcr | 18:04 |
DocScrutinizer05 | translate newline to carriage return-newline | 18:04 |
DocScrutinizer05 | suggests it should | 18:04 |
DocScrutinizer05 | refuses* | 18:05 |
DocScrutinizer05 | saturn:~ # stty -a </dev/ttyUSB0|grep onl | 18:07 |
DocScrutinizer05 | -opost -olcuc -ocrnl onlcr -onocr onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 | 18:07 |
DocScrutinizer05 | ((lib/power.py)) sorry what? | 18:09 |
DocScrutinizer05 | I find backup-20090831/usr/share/paroli/services/hardware/power.pyo and /usr/lib/python2.7/site-packages/synaptiks/monitors/power.py | 18:11 |
wpwrak | in https://gitorious.org/lab-tools/tmc | 18:12 |
DocScrutinizer05 | Written by Werner Almesberger <werner@openmoko.org> -- hehe | 18:13 |
DocScrutinizer05 | ta | 18:13 |
wpwrak | power.py is a (very simple) class for power supplies. you could add yours there. the infrastructure gives you communications and "active" variables | 18:13 |
DocScrutinizer05 | much appreciated | 18:13 |
wpwrak | yea, these were the old days :) | 18:13 |
wpwrak | the basic idea is that you have a "nice" python interface on top to model your instrument, and C at the bottom to get low-level comms right | 18:14 |
wpwrak | if you look at telnet.c, you'll see what nightmares may await you down there :) | 18:15 |
eintopf | everywhere you will find code written by werner | 18:16 |
eintopf | cool | 18:16 |
wpwrak | eintopf: maybe i should sue poettering for stealing my trademark ;-) | 18:19 |
eintopf | wpwrak: you are like "eric s. raymond" for me, I stumble sometimes also much on "eric s. raymond" patches | 18:23 |
eintopf | and then I am "raymoning" again, something like "rickrocklling" | 18:24 |
wpwrak | hmm, i guess that's what i deserve from comparing my style with poettering :) | 18:24 |
eintopf | maybe we should introduce "almesbergering" | 18:24 |
DocScrutinizer05 | hmmm >> These libraries are not documented yet, but there is a number of annotated examples in the demo/ directory.<< | 18:24 |
eintopf | everytime you stumble over code by you | 18:24 |
wpwrak | but i have to admit that i'm a happy and very regular user of fetchmail :) | 18:25 |
DocScrutinizer05 | don't tell me it's written by poettering | 18:26 |
wpwrak | DocScrutinizer05: yes, i left them out in the "migrated" version (from openmoko). examples are for sissies :) | 18:26 |
wpwrak | (fetchmail) no, by esr | 18:26 |
DocScrutinizer05 | I dunno if I want to use stuff that I basically have to read top-down every single line, to understand _how_ to use it. Prolly simpler to fix tty.ko and write stuff myself ;-) | 18:27 |
roh | eeeh.. are you flushing the tty buffers? | 18:43 |
roh | no /n means no automatic buffer flush. when you have so few chars, they are prolly still idling in your fifo :) | 18:44 |
roh | i urge you. do it in python or C. speaking anything not crlf-auto-default linefeeds in shell is breaking your knees madness | 18:44 |
roh | also every > /dev/serialdevice call opens and closes the serial once. some serials 'forget' some details of their config inbetween (bad drivers i guess). so using stty doesnt help | 18:45 |
roh | open, config termios (thats what pyserial does for you then, yay!!1!) then your 'traffic' and close when done is what one wants to do.. to avoid weird drivers/hardware | 18:46 |
DocScrutinizer05 | my problem is with \r, NOT with \n | 18:55 |
DocScrutinizer05 | and that's the only problem I have, rather it's an inconventience since nothing on linux is ever sending a \r when EOL | 18:56 |
DocScrutinizer05 | I don't even see how pyserial would help there | 18:56 |
DocScrutinizer05 | still would need the equivalent to talk2controller(){echo -en "$@\r"} | 18:57 |
DocScrutinizer05 | and I told you even shellscript is capable of keeping a file handle open: eval 5>/dev/ttyUSB 6</dev/ttyUSB | 18:59 |
DocScrutinizer05 | my problem is that neither minicom nor screen nor any other approach is capable to allow me talking interactively to device, for testing stuff. | 19:01 |
DocScrutinizer05 | cat|tr \\n \\r>/dev/ttyUSB0; however should do | 19:02 |
DocScrutinizer05 | just it sucks donkeyballs | 19:02 |
DocScrutinizer05 | no, it doesn't. Here buffering kicks in | 19:04 |
DocScrutinizer05 | obviously tr needs EOF on STDIN to print filtered stuff to STDOUT | 19:07 |
DocScrutinizer05 | :-/ | 19:07 |
DocScrutinizer05 | while read ... | 19:07 |
roh | *blblbl* | 19:09 |
whitequark | DocScrutinizer05: http://www.plunk.org/~grantham/cgi-bin/blog.cgi?id=00015 | 19:09 |
whitequark | may or may not help | 19:10 |
DocScrutinizer05 | http://privatepaste.com/d26dd00abf | 19:11 |
DocScrutinizer05 | whitequark: ta | 19:19 |
DocScrutinizer05 | btw prolly smarter than previous version: while read; do echo $REPLY|tr \\n \\r; done >/dev/ttyUSB0; | 19:21 |
DocScrutinizer05 | still pissed why stty onlcr doesn't work | 19:23 |
DocScrutinizer05 | ok, so much for "improving UI via remote control". The PSU has no switch to conveniently beak output for a short period of time (like 1s or 2). Using power switch is a PITA since it a) takes ages to deplete the primary side buffer caps of SPSU and b) the device runs a full selftest on power-up which again takes 10s or sth | 19:45 |
DocScrutinizer05 | however SOUT1 instantly breaks and SOUT0 instantly enables output | 19:46 |
DocScrutinizer05 | of course a VOLT060 is also more conventient than fiddling with that incremental turn dial | 19:47 |
--- Fri Oct 10 2014 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!