Divisor Patch

[GoogleCodeExporter]

This patch adds the -D / --divisor option, which allows a custom divisor to be 
specified to the serial driver using the semi-standard 
TIOCSSERIAL/serial_struct interface, which is currently specific to Linux.

With this, you can easily specify a custom divisor and achieve custom baud 
rates with drivers that support the interface.

A number of Linux drivers will pull in this custom_divisor option to allow a 
custom baud rate to be used.

For example, if you set the baud rate to 38400, then the ftdi_sio driver allows 
you to specify the custom divisor to achieve a custom baud rate.

This has been tested to work with the ftdi_sio driver.

This interface could potentially be used by *BSD eventually (when/if they 
support this interface), but I doubt it.  Until all the Unixes figure out a 
standard way to do this, this will only work on Linux.

Original issue reported on code.google.com by sqra...@gmail.com on 29 Jan 2012 at 4:06

Attachments:

• picocom-divisor.patch

[GoogleCodeExporter]

Original comment by nick.pat...@gmail.com on 21 Feb 2012 at 6:42

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Thanks for the patch!

The feature is quite nice to have, but I have some objections regarding the 
implementation. My main problem is that the TCIOCSSERIAL ioctl, which sets 
(and, I assume, enables) the custom divisor is called in term_set_baudrate() 
which goes against the logic of the term.[ch] library. The various 
term_set_xxxx functions should *only* check and "record" the new settings, to 
be applied (latter) by term_apply().

Other than this, I have no objections to the patch.

Another thing I don't understand: Is the custom divisor aplicable only to a 
specific baudrate (e.g. 38400) or to all baudrates? If the former is true, then 
this "special" baudrate is always 38400, or it depends on the specific driver?

Original comment by nick.pat...@gmail.com on 21 Feb 2012 at 8:49

• Changed state: Started

[GoogleCodeExporter]

In order to do this, should I modify origtermios, currtermios, and nexttermios 
from being "struct termios" to a new struct which encapsulates termios, as 
below?

struct term_options {
  struct termios termios;
  int divisor;
};

Then term_apply can apply the custom divisor by reading the divisor from the 
term_options struct.

Yes, the baud rate is important for some drivers, particularly the ftdi_sio 
driver, where you *need* to set the base baud rate to 38400 for the custom 
divisor to work.  So, the speed options in termios should probably not include 
information on the custom divisor (esp. since it's non-standard anyway), 
necessitating the creation of a new struct.

I don't know of a good place to store the custom divisor in the termios struct 
itself, so I think this is how we should do it.  What do you think?

Original comment by sqra...@gmail.com on 7 Mar 2012 at 5:54

[GoogleCodeExporter]

Yes, adding a "divisor" field in "term_options" would be the way to go. If 
"divisor" is 0 (I guess it can never be *meaningfully* zero) it is ignored, and 
the speed indicated in the termios sctruct if used instead. Otherwise the 
divisor is used.

This covers the modifications in term.[ch]. Now in picocom there should be a 
way to allow the user to select between a standard baudrate and the custom 
baudrate indicated by the divisor. When the user specifies a non-zero "divisor" 
command-line arg, the port should be, initially, configured to the custom 
baudrate. The custom baudrate should also be (conceptually) added to the list 
of available baudrates (probably at either end of it) so that the user can 
circle through it using baud-up baud-down. Something like this: 9600, 19200, 
... 921600, custom-baud. *Alternatively* (and maybe that's cleaner and better) 
a  new key-stroke should be added that toggles between the custom baud-rate and 
the standard baud-rates. When baud-custom (the new command keystroke) is 
pressed the custom baudrate is selected. In this mode baud-up baud-down have no 
effect. When baud-custom is pressed again, the standard baudrate is selected 
and baud-up baud-down become effective.

I would implement these changes myself, but sadly I currently have no way to 
test them. So I guess this falls on you...

Original comment by nick.pat...@gmail.com on 7 Mar 2012 at 7:30

[GoogleCodeExporter]

All these of-course, provided that there ARE valid, real-world cases where 
somebody would need to use a custom baud-rate. If not, or if these cases are 
exteremely marginal, then maybe it's too much work to worth the trouble. 

I have no set opinion on this.

Original comment by nick.pat...@gmail.com on 7 Mar 2012 at 7:35

[GoogleCodeExporter]

Yes, there are many cases in my line of work where it is extremely useful to 
use an very high baud rate, etc. where a custom divisor is necessary.  It also 
helps out when the device you are talking to isn't *exactly* 115200, but is 
close, and tweaking the baud rate slightly allows you to communicate at all to 
the device.

On the interface side of things, I'll make it so a certain shortcut enables or 
disables the custom divisor IOCTL call, but I hesitate to tie it directly to 
the baud rate, because for certain drivers, the baud rate has to be a magic 
value (i.e. 38400) in order for the divisor to take effect.

Original comment by sqra...@gmail.com on 7 Mar 2012 at 4:19

[GoogleCodeExporter]

This version adds support for the TIOCGSERIAL and TIOCSSERIAL structures 
generically, and should comply with the term library design goals, I hope.  So, 
you could update other options that Linux's "serial_struct" supports; not just 
the custom divisor option.  Let me know if you need any more changes.  I've 
tested it and it works perfectly.

Original comment by sqra...@gmail.com on 10 Mar 2012 at 10:16

Attachments:

• picocom-divisor2.patch

[GoogleCodeExporter]

Sorry, the documentation says that the divisor option is -D, instead of -o.

Original comment by sqra...@gmail.com on 10 Mar 2012 at 11:04

[GoogleCodeExporter]

Thanks! I'll go through these changes and apply them some time this week...

One question: In order for the divisor to apply, the user must have selected 
B38400 (through the command line or by the commnad keys)? Or do you also set 
the baudrate to B38400 when the divisor is enabled? (Didn't have time to check 
the code....)

Original comment by nick.pat...@gmail.com on 10 Mar 2012 at 11:09

[GoogleCodeExporter]

The user has to know that 38400 is the magic baud rate (at least for the 
specific driver that I've been using); it is not automatically applied.  So you 
would do this to get a 2 Mbit baud rate on the FTDI serial hardware:

picocom /dev/ttyUSB0 -b 38400 -o 12

Because its base clock rate is 24 MHz.

Original comment by sqra...@gmail.com on 11 Mar 2012 at 4:07

[GoogleCodeExporter]

Hi, I use picocom a lot to talk to whatever currently sits on my bread board.  
After building a breakout for an FT232RL to replace the good old MAX232, I 
figured higher baud rates would be nifty - no, actually that was the main 
reason for the switch in the first place.  Need to get data to the host faster 
than 115200.
So that'd be a Me Too from my part.  This feature seems to be the only way to 
drive the FTDI device at rates above 230400 that are easily configurable on an 
ATmega*8 - like 500k, 1M, and 2M.

Long story short, Google took me here, I checked out the patch and it works as 
expected.  So question is: any update on the status?  Is this going into a 
future picocom release and if so roughly when could this happen?

Original comment by malte.st...@gmail.com on 6 Feb 2013 at 1:58