l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
January 6: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2001 Dec 30 17:11

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] polaroid pdc700 - partial success
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] polaroid pdc700 - partial success



On Wed, 19 Sep 2001, Peter Jay Salzman wrote:

> here is an email i sent to the gphoto developer's list.  if anybody knows
> serial programming, can you answer the questions at the bottom of the email?

[...]

> i know nothing about serial programming.  if the baud is wrong, would there
> be no communication at all or would there be "some" communication until the
> program desyncronizes with the camera?

Garbage received.  The bytes always resynchronize at the beginning of each
new byte, but if the bit times don't match you get garbage.

>  this is the only thing i can think of
> that would be souring the communication midway between the handshake.
> 
> is there anything i should be looking for that would cause the last byte not
> to be read?

It doesn't look like the "last byte" drops so much as serial reads simply
stop working, period.  I presume you have done this more than once, and
re-opening the tty is re-enabling communication somehow.  It is possible
that hardware handshaking signals are interfering with either the camera's
transmission or the tty's reception of data.

Another possible problem: I looked at the source for gphoto2, and noticed
that they are using a nonzero value (1) for tio.c_cc[VMIN].  This is a
poorly-documented option that is supposed to make it possible to read some
number of bytes at a time from the port with a timeout.  However, I was
unable to get this mode to work correctly while working with serial io
this summer, and ended up using c_cc[VMIN]=0 and c_cc[VTIME]=0.  Both
gphoto and I use select() anyway for the timeouts and never read unless
select() indicates that data are ready, so I don't think the 1 is needed.

I don't know whether I just don't understand the semantics of this tty
mode or if Linux's implementation of NOCTTY mode is broken.  I can see how
one might expect the gphoto code to work based on the documentation, but
it didn't for me.  To dig in yourself, one source of information on this
is http://www.erlenstar.demon.co.uk/unix/faq_4.html.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!