Neal,
Thanks very much for the insight.
In my application the Palm always initiates the communications - both
HotSync and my own comms. I wonder if I might modify the DLP code on the
Linux side and build on top of this. I guess I have to wonder how easy it
would be to implement my own DLP code on the Palm side. I imagine DLP is
just a series of 'opcodes' with parameters that are wrapped within SLP. So
perhaps I could extend and create my own opcodes, though I run the risk that
Palm will extend DLP and use the same opcode values I choose.
Anyone got any thoughts on implementing a stripped down DLP on the Palm side
? Does code exist somewhere ( source or library ) that could do this ?
John M.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Neal
Lippman
Sent: Friday, September 21, 2001 2:06 AM
To: [EMAIL PROTECTED]
Subject: Re: pilot-link & back channel (long)
I've been doing a fair amount of going through the pilot-link code, actually
spending some time trying to understand exactly how it works, and thinking
about how it might be slightly restructured to aid in aiding the USB support
for my palm m505.
I think your conclusions regarding SLP and the pi-socket interface are
correct. Although the code was clearly written with the "sockets" concept, I
assume (without direct info on this) that that was done primarily to make
coding for talking to the palm parallel any other interprocess/interdevice
communcations method, eg unix or internet sockets. I suppose the interface
could just as well have looked like the VFS interface (eg open calls instead
of bind, etc).
In any case, the communcations with the palm depend on opening and
connecting
the socket, and then the desktop software speaks to the palm and gets back a
response by listening for it. Only one channel for communication exists at a
time.
If you want to look at how the pi-sockets are actually used, loop at the DLP
layer in dlp.c. The important function is dlp_exec, which is used by all the
other DLP routines. dlp_exec basically takes a command and buffer with data
for the command from its caller (like DLP_WriteDBRecord, for instance),
formats the data, and then uses pi_write to send the data to the palm.
pi_write of course takes the socket and "does the right thing" via the lower
layers - PADP/SLP or an internet connection for network hotsync. dlp_exec
then reads the response back from the pilot, parses/analyses it, and returns
the data to the caller. Thus, there is no real mechanism to *asynchronously*
read data from the palm and then deliver it to the right place; rather, (as
far as I can tell) the palm is only read when data is expected/needed, and
it
goes to the socket specified in the pi_read call.
According to palm documentation on the New Serial Manager, multiple serial
connections are now supported by Palm OS. On the palm end, the new serial
manager supports multiple serial devices (the serial (or now "universal")
connector, IR port, etc). So, if you wrote code to run on the palm, it
could
use the new serial manager to handle multiple connections on that end.
The SLP packet header does include destination and source socket fields,
which presumably would be used to manage such multple connections.
I think that would be required for pilot-link to handle all of this would be
for the package, whenever a socket is connected, to spawn a background
thread
that waits to read data on the serial line. When a packet is received, it
then uses the socket data in the SLP header to place it on a receive queue
for the appropriate socket. The pi_read method then checks that read queue;
if there is something on it it can just return it, otherwise, it can block
waiting for data to appear. The interface could be made sophisticated
enought
to support non-blocking I/O or blocking, timeouts, etc.
Whether this would work, and whether the effort is more than it is worht, is
another question, of course.
Anyone else with some thoughts/help?
On Thursday 20 September 2001 05:18, you wrote:
> I am developing a fairly odd use for a Palm device. The Palm is to
function
> as a front end for what is effectively an embedded controller ( actually a
> Linux box with MP3 / Ogg player with a database that acts as an MP3
> jukebox ).
>
> I need to be able to download some data from the Linux box to the Palm
> periodically. This data is the complete list of songs in the jukebox, and
> the Palm needs this only when songs have been added to the Jukebox,
> probably once per week.
>
> I took pilot-xfer and modified it to act as a HotSync server so that a
> HotSync initiated from the Palm results in the .pdb file being generated
> and sent to the Palm. Works great.
>
>
> The problem now is that I need the Palm to be able to interactively
> communicate with the Linux side over the serial port. In other words, the
> Palm needs to HotSync to my process on the Linux side every week or so,
and
> also exchange simple short strings over the serial port when the user taps
> on actions on the screen ( skip song, add to playlist etc ). This has to
be
> done without the user needing to quit / launch different tasks on the
Linux
> side.
>
>
> At first glance it seemed this could be done easily enough since SLP
> includes the concept of sockets. I could have two socket listeners on the
> Linux side - one for HotSync as usual and a second with my own socket ID
> for my private communications.
>
> After digging through the SLP / DLP code in pilot-link, I think I've
> determined that the serial data is always read into a single socket. It's
> not read and then distributed to the appropriate socket. Correct ?
>
> Is my understanding of SLP correct, ie could it in theory permit the use I
> have described ?
>
> Anyone got any bright ideas on how I can achieve this ?
>
>
>
> John Marshall ( a different one )
>
> _______________________________________________
> Pilot-unix mailing list
> [EMAIL PROTECTED]
> http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
_______________________________________________
Pilot-unix mailing list
[EMAIL PROTECTED]
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
_______________________________________________
Pilot-unix mailing list
[EMAIL PROTECTED]
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
