From: Scott H. <sco...@us...> - 2004-02-27 17:38:42
Attachments:
gsmout.zep
|
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 |
From: Roger B. <ro...@ro...> - 2004-02-28 00:07:28
|
[Note I will not be applying any of this until after the weekend build otherwise it won't have had sufficient testing time] > 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. > 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. > 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? > 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. > 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. > 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 |