Hi John! John Machin escribió:
>On 22/05/2006 5:22 AM, Gonzalo Monzón wrote: > > >>Thank you for all the suggestions! :-) >> >>The C routine is almost -changing data type long for word- a copy of the >>function given by a hardware manufacturer, the same code used in their >>firmware to calc the checksum of every piece of data sent or received, >>and that data is somewhat special: it does not contain only plain ascii >>character data (only 0x01 - 0x09 as delimiters) and every data set ends >>with a 0x00 null byte so its fine to calculating checksum until "\x00" >>is reached. And I must get the same crc calculations. That C routine >>(and a very similar PHP one too) are tested for months and work smoothly. >> >>And of course I should use integer not long!!... we aren't anymore in >>the 8 bit computer era... ;-) original code from hardware manufacturer >>use words by the way. And now really don't know why I used long. I >>thought I did that way 'cause see pyrex C generated glue code always >>using PyInt_FromLong so thought would use the same type. >> >> > >Perhaps we need some amplification of "of course I should use integer >not long" :-) > >Is the transmitted checksum (which your routine must create and/or >verify) 2 bytes long or 4 bytes long??? This is the most important >thing; once that is established, then you choose the C and/or Python >types and the mask (0xFFFF or 0xFFFFFFFF) as/if necessary. In that >original specification from the manufacturer, how wide was a "word"? > > > Is only 2 bytes long (0x0 to 0xFFFF). I really don't know how wide is a "word" but I guess its 2 bytes long. >Note that in most/many C compilers at the moment, "int" and "long" >*both* mean 32 bits, to get 64 bits you need "long long" [or "_int64" or >whatever in realms under the sway of the dark tower], and "short" may >get you 16 bits if you are lucky. In a typical Python environment at the >moment, "int" uses the C "long", and thus typically will be 32 bits. >Python "long" is a variable-length data type. > >Also note that even if the "checksum" is 32 bits wide, the high-order 16 >bits are not verifiably useful, so you could use a [faster] 16-bit >version when receiving. > > > >>I changed the C function to use integer, and it is performing a little >>bit slowly than using longs (best with long: 0.614us, best with int: >>0.629us), that is maybe as I said due pyrex glueing always the return >>values with PyObject* PyInt_FromLong for all kind of short int to long >>data types? Anyway both results are fine, and the timming gap is >>insignificant (int: 1580403 loops -> 0.973 secs, long: 1601902 loops -> >>1.01 secs) as i usually never have to call more than 100,000 times when >>loading a full file data backup. >> >> > >I'm somewhat puzzled: Do you have the facility to cross-compile C to run >on the Pocket PC? If NO, why do you continue to mention fast versions >coded in C and glued with Pyrex? If YES, why did you include a Python >version in your initial question? > > That is just because I have some modules for common communication tasks with that hardware interface, and I use them in some PC applications, but now I'm coding a similar application that runs on PocketPC, so I use both versions of crc calculation in different applications: C/Pyrex on the PC -compiled with distutils/gcc- , and the Python one I was having trouble, only intended for PocketPC. I still have to setup a ms.evc compiling environment for the new PythonCE 2.4.3 release, but now haven't got the time so far, I'm in hurry to finish a first demo release for the PocketPC app, so as I had few C dependencies -modules in C/Pyrex for what I haven't got a working Python version yet like that crc calc.- I thought would be a better idea to re-code them in Python. If you are curious about, I'm glad to show some screenshots of the PocketPC app. -well, it runs fine both on the PC & PPC-. It is a sports timing "remote point" application, it connects to timing hardware, send data to main timing software via Internet and in the meanwhile gets other point data and race results so you can have that info live on every timing point while the race goes: http://serveisw3.net/temp/ppc_preview/ppc_preview.html >Cheers, > >John > > Regards, Gonzalo. -- http://mail.python.org/mailman/listinfo/python-list
