[Bitpim-devel] Patch for GSM phone + MSOutlook read support

[Scott Heavner]

I'm sending a patch + zip which adds preliminary support
for MSOutlook and GSM phones. At the moment, both only
support reads and have problems with recurring
appointments. The "Profile" classes for both probably
need some work as I'm not really sure what goes on in
here and where they could inherit from.

1. commport.py - add some multi-character terminators,
might slow things down, but i doubt it is a significant
performance impact.

the problem - reads come in spurts, if say wait for a '\r'
sometimes it will read 'line1\r line2\r line3\r" and
other times it will return right away after "line1\r"

2. gui.py - skip over serial init routines for non-serial
devices, tests for existance + trueness of variable in **Phone
class.

3. GSM driver - labelled as generic, but is probably Samsung
S105 specific, for sure the calendar stuff is, the phone numbers
should be generic enough to work across multiple models/vendors.

I'm gonna send this out now, I'll try to comment
more on bitpim later - things I'm concerned with are the base
classes which are tied to brew and where a non-brew/non-serial
com_* interface should start from - i added two new classes
com_nofiles.py (the non-brew starting point) and
com_nonphone.py (a base class for non-serial phones). I'm
attaching a zip containing the new files and "gsmout_diff"
which is the cvs diff of the existing files. The zipfile is
named .zep b/c comcast is being "smart" and blocking sends with
.zip file attachments.


-scott


===========

? com_gsm.py
? com_nofiles.py
? com_nonphone.py
? com_outlook.py
? p_gsm.p
? p_gsm.py
? p_sanyo5500.py
Index: commport.py
===================================================================
RCS file: /cvsroot/bitpim/bitpim/commport.py,v
retrieving revision 1.28
diff -u -r1.28 commport.py
--- commport.py 23 Feb 2004 20:54:04 -0000 1.28
+++ commport.py 27 Feb 2004 06:44:08 -0000
@@ -12,6 +12,7 @@
import serial
import common
import time
+import re
try:
import native.usb as usb
except:
@@ -237,15 +238,32 @@
self.logdata("Reading remaining data", res)
return res

+ def termmatch( self, char, buf ):
+ if ( len(buf) == 0 ):
+ return False
+ elif ( char == '\r\n' and len(buf) > 1 and buf[-1] == '\r' and
buf[-2] == '\n' ):
+ return True
+ elif ( char == "OKEOL" ):
+ if ( re.search("(OK)|(ERROR)[\n\r]+$", buf ) ):
+ return True
+ else:
+ return False
+ elif ( char == "EOL" and ( buf[-1] == '\r' or buf[-1] == '\n' ) ):
+ return True
+ elif ( char == buf[-1] ):
+ return True
+ return False
+
def readuntil(self, char, log=True, logsuccess=True, numfailures=0):
# Keeps reading until it hits char
self.readrequests+=1
- if False: # don't log this anymore
- self.logdata("Begin reading until 0x%02x" % (ord(char),), None)
+ if log: # don't log this anymore
+ self.logdata("Begin reading until 0x%02x" % (ord(char[0]),),
None)

# set numfailures to non-zero for retries on timeouts
res=''
- while len(res)==0 or res[-1]!=char:
+ while not self.termmatch( char, res ):
+
if hasattr(self.ser, 'readuntil'):
# usb does it directly
res2=self.ser.readuntil(char)
@@ -253,12 +271,12 @@
else:
b=self.ser.inWaiting()
if b<1: b=1
- res2=self.read(b,0)
+ res2=self.read(b,log)
if len(res2)<1:
if numfailures==0:
if log:
self.log("Timed out waiting for %02x, requested
bytes %d - %d bytes read" %
- (ord(char), b, len(res)))
+ (ord(char[0]), b, len(res)))
self.logdata("Incomplete read was", res)
self.readbytes+=len(res)
raise CommTimeout(partial=res)
Index: gui.py
===================================================================
RCS file: /cvsroot/bitpim/bitpim/gui.py,v
retrieving revision 1.114
diff -u -r1.114 gui.py
--- gui.py 24 Feb 2004 17:40:05 -0000 1.114
+++ gui.py 27 Feb 2004 06:44:10 -0000
@@ -1016,6 +1016,10 @@

def setupcomm(self):
if __debug__: self.checkthread()
+ # FIXME: Is there a cleaner way to handle this?
+ if getattr( self.dispatchto.phonemodule.Phone,
'isNonSerialDriver', False ):
+ self.commphone=self.dispatchto.phonemodule.Phone(self, None)
+ return
if self.commphone is None:
import commport
if self.dispatchto.commportsetting is None or \
Index: guiwidgets.py
===================================================================
RCS file: /cvsroot/bitpim/bitpim/guiwidgets.py,v
retrieving revision 1.138
diff -u -r1.138 guiwidgets.py
--- guiwidgets.py 24 Feb 2004 17:40:05 -0000 1.138
+++ guiwidgets.py 27 Feb 2004 06:44:12 -0000
@@ -291,6 +291,8 @@
'SCP-5300': 'com_sanyo5300',
'SCP-8100': 'com_sanyo8100',
# 'SCP-5500': 'com_sanyo5500',
+ 'generic GSM': 'com_gsm',
+ 'MSOutlook': 'com_outlook',
}

setme="<setme>"
Index: makepackets.bat
===================================================================
RCS file: /cvsroot/bitpim/bitpim/makepackets.bat,v
retrieving revision 1.9
diff -u -r1.9 makepackets.bat
--- makepackets.bat 23 Feb 2004 02:14:49 -0000 1.9
+++ makepackets.bat 27 Feb 2004 06:44:12 -0000
@@ -3,6 +3,7 @@
python protogen.py p_lgvx4500.p p_lgvx4500.py
python protogen.py p_lgvx6000.p p_lgvx6000.py
python protogen.py p_brew.p p_brew.py
+python protogen.py p_gsm.p p_gsm.py
python protogen.py p_lgtm520.p p_lgtm520.py
python protogen.py p_lg.p p_lg.py
python protogen.py p_sanyo4900.p p_sanyo4900.py

[Roger Binns]

[Note I will not be applying any of this until after the
weekend build otherwise it won't have had sufficient
testing time]

Post by Scott Heavner
I'm sending a patch + zip which adds preliminary support
for MSOutlook

Although it is a good way of thinking, the current design
doesn't treat non-phone devices as phones. For the moment
I would prefer to keep Outlook as an import source like
CSV files, not as a phone workalike.

But please do keep thinking about it. Synchronization
is going to involve multiple sources and destinations
for data, and the generation of transaction logs.

Post by Scott Heavner
appointments. The "Profile" classes for both probably
need some work as I'm not really sure what goes on in
here and where they could inherit from.

Yes, there does need to be a base Profile class. I guess this
is the spur I need to do that.

Post by Scott Heavner
1. commport.py - add some multi-character terminators,
might slow things down, but i doubt it is a significant
performance impact.
the problem - reads come in spurts, if say wait for a '\r'
sometimes it will read 'line1\r line2\r line3\r" and
other times it will return right away after "line1\r"

As far as I can tell you actually need a method corresponding
to the normal Python readline method. I think that is best
placed in the comm port class.

The reason for the "spurts" is due to lazyness (-ish :-) I
didn't want to have to implement any form of buffers. There
are two ways to do the readuntil. One is read one byte at
a time. The other is just to read as much as is available
and check the last byte.

The latter approach is very useful with the CDMA phones since
comms with them is somewhat flaky, and you can end up with
previous responses.

However this does all require fixing:

- Adding a readline method to comm class
- Adding buffering to comm class (especially for readline)

The comm class needs a method of sending AT commands and
reading the responses, including dealing with echoed commands, OK/ERRORs
and resets.

Can you post what a sequence of commands normally looks like?

Post by Scott Heavner
2. gui.py - skip over serial init routines for non-serial
devices, tests for existance + trueness of variable in **Phone
class.

That is only needed if Outlook is treated as a phone which I would
prefer to avoid for the moment.

Post by Scott Heavner
3. GSM driver - labelled as generic, but is probably Samsung
S105 specific, for sure the calendar stuff is, the phone numbers
should be generic enough to work across multiple models/vendors.

I think the best thing to do is make a com_obex.py file that does
the GSM stuff and then inherit specific models from that deal
with specific quirks.

Can you also think a bit more about how to specify the protocol
itself? The current packetdescription stuff is perfect for
binary encodings, but not best suited for CSV style encoding.
I am thinking that printf/scanf style encoding of the packets may
be a better way of dealing with it, quoting issues (double quotes
and commas in fields), character set encoding etc.

Post by Scott Heavner
i added two new classes com_nofiles.py (the non-brew starting point)

That definitely needs to be added, together with the base
Profile.

The Outlook stuff looks good. I will have to change the COM gencache
stuff since that won't work in a distributed binary build.

Thanks for the code and updates!

Roger