pycrc-users — This list is now closed.

[Pycrc-users] Mailing list closed

[Thomas P. <te...@gm...>]

Hi all,

this mailing list will be closed for new mails today. A read-only 
archive of the mailing list will remain available.
Please file feature requests and bug reports for pycrc at 
https://github.com/tpircher/pycrc

Thanks,
Thomas

[Pycrc-users] pycrc v0.8.3 released.

[Thomas P. <te...@gm...>]

Version 0.8.3 is a minor bugfix release.

- pycrc has a new homepage: https://pycrc.org
- Removed the experimental --bitwise-expression option to facilitate
   restructuring of the code.
- Applied some minor optimisations to the generated table-driven code.
- Changed the signature of the crc_update() function: the data argument 
is now
   a pointer to void to improve compatibility with C++.
- Added a AUTHORS file. If I have forgotten to mention someone please 
don't
   hesitate to send a mail.
- Upgraded documentation to DocBook 5.


Other changes:
=============

In an effort to move away from Sourceforge, a few changes in the 
organisation
of pycrc: the Sourceforge issue tracker is now closed and people are 
encouraged
to use the GitHub tracker. All past releases can be downloaded from
https://pycrc.org/news.html


About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated
C source code can be optimized for simplicity, speed or tight memory 
constraints
for embedded platforms. pycrc contains a long list of the parameters of 
common
CRC models.

License: MIT
Homepage: https://pycrc.org
           https://github.com/tpircher/pycrc/
Download: https://pycrc.org/download.html
Issues:   https://github.com/tpircher/pycrc/issues

Re: [Pycrc-users] Some suggestions :)

[Thomas P. <te...@gm...>]

On 2015-07-12 15:59, Jesus Cea wrote:
> 1. Thomas, would you consider to publish this project in PYPI?. Would 
> be
> amazing if I could do a simple "pip install pycrc" to install it.

I have looked into this some time ago, and also found that there is 
already a project pycrc, so I didn't pursue this further. Installing 
pycrc on a computer is not that high on my priority list, since most 
people I know tend to download it, run it to generate source code and 
then forget about it.

> 2. In the FAQ I miss an entry saying if this project is Python 3
> compatible or not :).

Good spot. I have added this to the FAQ:
http://www.tty1.net/pycrc/faq_en.html#pythonversion

> 3. Would be great to document how to call the C generated code from
> Python, using ctypes and/or CFFI and/or cython.

This is worth a thought. I haven't used any of these in anger, but this 
might be a useful resource for pycrc users. I guess improving the 
performance of the generated code takes priority.

> 4. In my laptop, unrolling the C loop four times increase performance
> 4%.

This is definitely something I will try to improve, in my spare time. I 
am evaluating which approach would be best. I'm thinking about  
slicing-by-X (https://github.com/tpircher/pycrc/issues/3), but I meant 
to do some profiling to make sure it is really a better approach than 
the one you suggest. I also think the cache misses might actually be 
significant, but I don't have any hard evidence.

> 5. Would you consider a 16 bits table?. Performance would be quite CPU
> specific to the L1 cache size. Could be detrimental. Testing is needed.

Ack, some profiling is needed. Yesterday I have revived some old 
profiling script, but I need to update it with an loop-unrolled version 
and a slice-by-4 or slice-by-8 version.

> 6. How about generating x86 (and ARM) machine code?. Seeing the
> assembler from the C version I see it is quite suboptimal. Trivial
> cleanup of the generated C code (delete three unnecessary instructions)
> improves performance by 11.3%. The resulting code has plenty of
> optimizations opportunities yet.

I'd rather let the C compiler do the optimisations. But I do agree that 
the generated code could and should be better, in the case when all 
parameters are specified.

> 7. "crc = (crc_table[tbl_idx] ^ (crc >> 8)) & 0xffffffff;". For CRC-32
> the final "&ffffffff" is wasteful, whatever datasize is "crc" (for
> instance, 64 bits). This is because "crc_table" is 32 bits and if "crc"
> only had 32 significant bits, "crc>>8" will only have 24 bits. So, if
> "crc" starts with 32 significant bits, you don't need the masking to
> keep "crc" 32 bits significant.
> 
> You can drop the final masking too.

Ack. These type of optimisations are definitely on my list of things to 
do for the near future. I have dropped some experimental feature so I 
thnk the code should be better maintainable and easier to optimise.

Cheers,
Thomas

[Pycrc-users] Some suggestions :)

[Jesus C. <jc...@jc...>]

On 04/12/14 22:56, Thomas Pircher wrote:
> Version 0.8.2 is a minor bugfix release.

1. Thomas, would you consider to publish this project in PYPI?. Would be
amazing if I could do a simple "pip install pycrc" to install it.

There is a "pycrc" project already posted there, though.

Maybe not really applicable for this particular project, since the
interesting usage is to generate C code to include in other projects.

2. In the FAQ I miss an entry saying if this project is Python 3
compatible or not :).

3. Would be great to document how to call the C generated code from
Python, using ctypes and/or CFFI and/or cython.

4. In my laptop, unrolling the C loop four times increase performance
4%. In my old Raspberry PI B the improvement is 15.5%. This is a trivial
change, but missaligned loads must be accounted. Something like:

switch(pointer&3) {
case 1: do a byte; (it will continue to the next case, so doing 3 bytes)
case 2: do a byte; (it will continue to the next case, so doing 2 bytes)
case 3: do a byte;
default: we are aligned now. Load 4 bytes with a single load and
do four bytes per loop. Special case last bytes.
}

Maybe more easy to have a special "update" version where alignment and
size multiple of 4 is guaranteed.

Beware bigendian/littleendian.

5. Would you consider a 16 bits table?. Performance would be quite CPU
specific to the L1 cache size. Could be detrimental. Testing is needed.

6. How about generating x86 (and ARM) machine code?. Seeing the
assembler from the C version I see it is quite suboptimal. Trivial
cleanup of the generated C code (delete three unnecessary instructions)
improves performance by 11.3%. The resulting code has plenty of
optimizations opportunities yet.

7. "crc = (crc_table[tbl_idx] ^ (crc >> 8)) & 0xffffffff;". For CRC-32
the final "&ffffffff" is wasteful, whatever datasize is "crc" (for
instance, 64 bits). This is because "crc_table" is 32 bits and if "crc"
only had 32 significant bits, "crc>>8" will only have 24 bits. So, if
"crc" starts with 32 significant bits, you don't need the masking to
keep "crc" 32 bits significant.

You can drop the final masking too.

Dropping the unnecessary masking and unrolling 4 times, I get an
improvement of 14.6% in my laptop, compiling X86-64.

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jc...@jc... - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jc...@ja...  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

[Pycrc-users] pycrc v0.8.2 released.

[Thomas P. <te...@gm...>]

Version 0.8.2 is a minor bugfix release.

- Removed warning about even polynomials.
- Updated the generated code to cope with big Widths (>32 bits) on 32 bit
  processors.
- The table-driven code for polynomials of width < 8 using a table index width
  less than 8 was producing a wrong checksum.
- Updated the the documentation.


About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated C source code can be optimized for simplicity, speed or tight memory 
constraints for embedded platforms. pycrc contains a long list of the 
parameters of common CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Git source: http://github.com/tpircher/pycrc/
Mailing list: https://lists.sourceforge.net/lists/listinfo/pycrc-users

Re: [Pycrc-users] PyCrc 0.8.1 - bad code for CRC-5, CRC-7 and table index width 4?

[Radosław G. <ra...@he...>]

Hi Thomas,

On 2013-12-23 19:55, Thomas Pircher wrote:
> On 2013-12-13 5:02 pm, Thomas Pircher wrote:
>> I'm afraid this is a bug in pycrc which was not covered in the
>> test script. I hope I'll be able to fix that next week.
>
> Hi Radosław,
>
> this should be fixed now on github:
> https://github.com/tpircher/pycrc
>
> You can also download a development snapshot from
> https://github.com/tpircher/pycrc/archive/master.zip
>
> Please let me know if this works for you.

It works for me. This version seems to give correct results.
Thank you very much.

PS. I played a bit with pycrc output code and right-aligning CRC
     gave me faster and smaller machine code (CRC4 with table-idx-width=4
     on ATmega8).

Best regards,
-- 
Radosław Gancarz                             r a d e k g @ h e l l . p l
http://bugs.from.hell.pl/

Re: [Pycrc-users] PyCrc 0.8.1 - bad code for CRC-5, CRC-7 and table index width 4?

[Thomas P. <te...@gm...>]

On 2013-12-13 5:02 pm, Thomas Pircher wrote:
> I'm afraid this is a bug in pycrc which was not covered in the
> test script. I hope I'll be able to fix that next week.

Hi Radosław,

this should be fixed now on github:
https://github.com/tpircher/pycrc

You can also download a development snapshot from 
https://github.com/tpircher/pycrc/archive/master.zip

Please let me know if this works for you.

Thanks,
Thomas

Re: [Pycrc-users] PyCrc 0.8.1 - bad code for CRC-5, CRC-7 and table index width 4?

[Thomas P. <te...@gm...>]

On 2013-12-12 6:21 pm, Radosław Gancarz wrote:
> Am I doing something wrong or I have found bug in pycrc?

Hi Radosław,

you are not doing anything wrong, I'm afraid this is a bug in pycrc 
which was not covered in the test script. I hope I'll be able to fix 
that next week.

Thanks,
Thomas

[Pycrc-users] PyCrc 0.8.1 - bad code for CRC-5, CRC-7 and table index width 4?

[Radosław G. <ra...@he...>]

Hi,

I'm trying to generate table based code for CRC-5 and pycrc-0.8.1
generates code that produces different CRC for most data when
I'm using --alogrithm-tbl --table-idx-width=4.
I am getting similar results for CRC-4, CRC-6 and CRC-7.

Am I doing something wrong or I have found bug in pycrc?

Thanks in advance for your help.

My code is:

================================== main.c ============================
#include <stdio.h>
#include "crcbbf.h"
#include "crcidx4.h"
#include "crcidx8.h"

int main(int argc,char * argv)
{

     crc5_bbf_t bbf;
     crc5_idx4_t idx4;
     crc5_idx8_t idx8;
     #define data_len 1


     unsigned char data[data_len] = { 0x01 } ;//, 0x02 , 0x03 , 0x44};


     int i;
     for (i=0;i<256;i++)
     {
         data[0]=i;

         bbf= crc5_bbf_init();
         bbf= crc5_bbf_update(bbf, data, data_len);
         bbf= crc5_bbf_finalize(bbf);

         idx4= crc5_idx4_init();
         idx4= crc5_idx4_update(idx4, data, data_len);
         idx4= crc5_idx4_finalize(idx4);

         idx8= crc5_idx8_init();
         idx8= crc5_idx8_update(idx8, data, data_len);
         idx8= crc5_idx8_finalize(idx8);
         if ( (bbf != idx4 ) || (bbf != idx8) )
         {
             printf("data[]={0x%02x} bbf=0x%02x, idx4=0x%02x,"
                    "idx8=0x%02x\n", data[0],bbf, idx4, idx8);
         }
     }
     return 0;
}

=============== Script that generates and compiles code ==============
#!/bin/bash
model="--poly=5 --width=4 --xor-in=0 --xor-out=0"
model="$model --reflect-in=0 --reflect-out=0"

../pycrc.py --algorithm=tbl --table-idx-width=4 $model\
   --std=C99 --symbol-prefix=crc5_idx4_ --generate=c \
   --o crcidx4.c

../pycrc.py --algorithm=tbl --table-idx-width=4 $model\
   --std=C99 --symbol-prefix=crc5_idx4_ --generate=h \
   --o crcidx4.h

../pycrc.py --algorithm=tbl --table-idx-width=8 $model\
   --std=C99 --symbol-prefix=crc5_idx8_ --generate=c \
   --o crcidx8.c

../pycrc.py --algorithm=tbl --table-idx-width=8 $model\
   --std=C99 --symbol-prefix=crc5_idx8_ --generate=h \
    --o crcidx8.h

../pycrc.py --algorithm=bbf $model\
   --std=C99 --symbol-prefix=crc5_bbf_  --generate=c \
   --o crcbbf.c

../pycrc.py --algorithm=bbf $model\
   --std=C99 --symbol-prefix=crc5_bbf_  --generate=h \
   --o crcbbf.h

gcc -c crcidx4.c
gcc -c crcidx8.c
gcc -c crcbbf.c
gcc -c main.c
gcc -o main main.o crcbbf.o  crcidx8.o crcidx4.o
./main | head
================================== Output ============================
data[]={0x10} bbf=0x1a, idx4=0x00,  idx8=0x1a
data[]={0x11} bbf=0x1f, idx4=0x05,  idx8=0x1f
data[]={0x12} bbf=0x10, idx4=0x0a,  idx8=0x10
data[]={0x13} bbf=0x15, idx4=0x0f,  idx8=0x15
data[]={0x14} bbf=0x0e, idx4=0x14,  idx8=0x0e
data[]={0x15} bbf=0x0b, idx4=0x11,  idx8=0x0b
data[]={0x16} bbf=0x04, idx4=0x1e,  idx8=0x04
data[]={0x17} bbf=0x01, idx4=0x1b,  idx8=0x01
data[]={0x18} bbf=0x17, idx4=0x0d,  idx8=0x17
data[]={0x19} bbf=0x12, idx4=0x08,  idx8=0x12
=======================================================================
My system is Debian 7.2 (gcc4.7):

radekg@debian64:~/pycrc-0.8.1/crctest$ uname -a
Linux debian64 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
radekg@debian64:~/pycrc-0.8.1/crctest$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' 
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs 
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.7 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --enable-plugin --enable-objc-gc 
--with-arch-32=i586 --with-tune=generic --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)

Best Regards

-- 
Radosław Gancarz                             r a d e k g @ h e l l . p l

[Pycrc-users] pycrc v0.8.1 released.

[Thomas P. <te...@gm...>]

Version 0.8.1 is a bugfix release.

- Remove obsolete and unused 'direct' parameter.
  Thanks to Matthias Urlichs.
- Don't recurse into main() when an unknown algorithm is selected.
  Thanks to Matthias Urlichs.
- Fixed a bug in the handling of hexstrings in Python3.
  Thanks to Matthias Kuehlewein.
- The input to the CRC routines can now be bytes or strings.
- Re-organised the symbol table.
- Updated qm.py from https://github.com/tpircher/quine-mccluskey.

About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated C source code can be optimized for simplicity, speed or tight memory 
constraints for embedded platforms. pycrc contains a long list of the 
parameters of common CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Git source: http://github.com/tpircher/pycrc/
Mailing list: https://lists.sourceforge.net/lists/listinfo/pycrc-users

[Pycrc-users] pycrc v0.8 released.

[Thomas P. <te...@gm...>]

Version 0.8 is a feature release.

- Added the experimental bitwise-expression generator target.
- Allow to specify the --include option multiple times.
- Completely revisited and reworked the documentation.
- Allow to abbreviate the names of the algorithms.
- Minor documentation changes.

The bitwise-expression generator is an experimental feature, which might one 
day be almost as fast as the table-driven code but much smaller.
At the moment the generated code is bigger and slower than any other 
algorithm, so use at your own risk.

About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated
C source code can be optimized for simplicity, speed or tight memory 
constraints
for embedded platforms. pycrc contains a long list of the parameters of common
CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Git source: http://github.com/tpircher/pycrc/
Mailing list: https://lists.sourceforge.net/lists/listinfo/pycrc-users

[Pycrc-users] pycrc v0.7.11 released.

[Thomas P. <te...@gm...>]

Version 0.7.11 is a minor bugfix release.

- Improved Python3 compatibility. pycrc now requires Python 2.6 or later.
- Fixed a wrong "check" value of the crc-64-jones model.
- Don't use snprintf() with c89 code, changed to sprintf().
- Rewrote the regression test script in Python.


About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated
C source code can be optimized for simplicity, speed or tight memory 
constraints
for embedded platforms. pycrc contains a long list of the parameters of common
CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Git source: http://github.com/tpircher/pycrc/
Mailing list: https://lists.sourceforge.net/lists/listinfo/pycrc-users

Re: [Pycrc-users] crc_init value for bit-by-bit algo

[Thomas P. <te...@gm...>]

On Thursday 09 Aug 2012 01:25:24 Dave Wong wrote:
> The test data is 43 bytes of 0x0 followed by one byte of 0x28. The
> expected crc value is 0x864d7f99.

Hi Greg,

I have tried this:

| pycrc.py --check-hex 
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000028 
--model crc-32-bzip2

And this gives me your expected result of 0x864d7f99. So far so good.

> It turns out the difference is in the initial crc value. The c code
> (bit-by-bit) generated an init value "init = crc.NonDirectInit" which is
> 0x46af6449. Based on the ITU standard, it says to initialize the crc reg
> to all 1's first. So I have always initialize my crc reg to 0xfffffff.

The RockSoft Model, defined in http://www.ross.net/crc/download/crc_v3.txt and 
used nowadays to define a CRC model, uses the init values of the table-driven 
algorithm or the bit-by-bit-fast algorithm.

These two algorithms work on all bits of the message, while the straight-
forward bit-by-bit algorithm works on the "augmented message", which is the 
message plus "Width" zeroes appended at the end. (Width is the width of the 
polynom.)

Now, there is no reason you would prefer the bit-by-bit algorithm over the 
bit-by-bit-fast one, because the latter one avoids looping over Width null-
bits at the end.

The exact method how to calculate the init value for the bit-by-bit algorithm 
is described in http://www.ross.net/crc/download/crc_v3.txt, section "10. A 
Slightly Mangled Table-Driven Implementation", but the sloppy answer is: you 
calculate a kind of reverse CRC that will give you the same same result as the 
table-driven and bit-by-bit-fast algorithms. This new init value depends only 
on the RockSoft init model and the width of the polynom.

A pycrc-generated routine for the init value is:

/**
 * Calculate the initial crc value.
 *
 * \param cfg  A pointer to a initialised crc_cfg_t structure.
 * \return     The initial crc value.
 *****************************************************************************/
crc_t crc_init(const crc_cfg_t *cfg)
{
    unsigned int i;
    bool bit;
    crc_t crc = cfg->xor_in;
    for (i = 0; i < cfg->width; i++) {
        bit = crc & 0x01;
        if (bit) {
            crc = ((crc ^ cfg->poly) >> 1) | cfg->msb_mask;
        } else {
            crc >>= 1;
        }
    }
    return crc & cfg->crc_mask;
}

Hope that helps,
Thomas

[Pycrc-users] crc_init value for bit-by-bit algo

[Dave W. <to_...@ya...>]

First off, this pycrc is great stuff! Thx for the great work. 

I'm new to this crc business but need to code up a python script to implement the ITU I363.5 crc32 checker. I've googled and read a lot before coding up a bit-by-bit version of the checker. My crc value was always wrong. The test data is 43 bytes of 0x0 followed by one byte of 0x28. The expected crc value is 0x864d7f99. I used pycrc to generate the c code (bit-by-bit) to try to understand what I did wrong. Long story short. It turns out the difference is in the initial crc value. The c code (bit-by-bit) generated an init value "init = crc.NonDirectInit" which is 0x46af6449. Based on the ITU standard, it says to initialize the crc reg to all 1's first. So I have always initialize my crc reg to 0xfffffff. 

Can someone educate me a bit on how to come up with this init value of 0x46af6449? Much appreciated!!

dave

[Pycrc-users] pycrc v0.7.10 released.

[Thomas P. <te...@gm...>]

Version 0.7.10 is a minor feature and bugfix release.

- Added the models crc-12-3gpp, crc-16-genibus, crc-32-bzip2
  and crc-64-xz.
- Bad-looking C code generated; Thanks to "intgr" for the fix.
- Fixed a mistake in the man page that still used the old model
  name crc-32mpeg instead of crc-32-mpeg.
  Thanks to Marek Erban.
- Smaller code cleanups.


About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated
C source code can be optimized for simplicity, speed or tight memory 
constraints
for embedded platforms. pycrc contains a long list of the parameters of common
CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Mailinglist: https://lists.sourceforge.net/lists/listinfo/pycrc-users

[Pycrc-users] pycrc v0.7.7 released.

[Thomas P. <te...@gm...>]

Version 0.7.7 is a minor bugfix release.

- Substituted the deprecated function atoi() with int(). Closes issue 3136566.
  Thanks to Tony Smith.
- Updated the documentation with a Windows-style call of the python 
interpreter.
- Fixed a few coding style issues found by pylint and pychecker.


About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated
C source code can be optimized for simplicity, speed or tight memory 
constraints
for embedded platforms. pycrc contains a long list of the parameters of common
CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Mailinglist: https://lists.sourceforge.net/lists/listinfo/pycrc-users

[Pycrc-users] pycrc v0.7.6 released.

[Thomas P. <te...@gm...>]

Version 0.7.6 is a minor bugfix release.

- Fixed a minor bug in the command line parsing of the generated main 
function.
- Use integer division for Python3 compatibility.
- Complete rewrite of the internal macro language and code generator.


About pycrc:
===========

pycrc is an easy to use CRC calculator and source code generator. The 
generated
C source code can be optimized for simplicity, speed or tight memory 
constraints
for embedded platforms. pycrc contains a long list of the parameters of common
CRC models.

License: MIT
Homepage: http://www.tty1.net/pycrc/
          http://sourceforge.net/projects/pycrc/
Download: http://sourceforge.net/projects/pycrc/files/
Mailinglist: https://lists.sourceforge.net/lists/listinfo/pycrc-users

[Pycrc-users] only XOR operation , please, We need your help.

[Sebastian C. <jca...@in...>]

We need your help. It is possible to calculate the CRC (only XOR 
operation) of the following numbers in hexadecimal through pycrc.py? How 
We can do?

24 5A 39 30 22 00 23 10 1D 0E 04 28 E2 05 4A 03 8D 13 3B 00 6A 00 13 04 
0A FB 09 E3 92 D5 00 00 00 = 26 = CRC

I need exactly the operation is as follows:

0x24 xor 0x5A xor 0x39 xor 0x30 xor 0x22 xor 0x00 xor 0x23 xor 0x10 xor 
0x1D xor 0x0E xor 0x04 xor 0x28 xor 0xE2 xor 0x05 xor 0x4A xor 0x03 xor 
0x8D xor 0x13 xor 0x3B xor 0x00 xor 0x6A xor 0x00 xor 0x13 xor 0x04 xor 
0x0A xor 0xFB xor 0x09 xor 0xE3 xor 0x92 xor 0xD5 xor 0x00 xor 0x00 xor 
0x00 = 0x26 = CRC

Re: [Pycrc-users] type mismatches solved

[C. M. <cm...@gm...>]

My bad!  As I was experimenting, I forgot to specify the xor and reflection
options.  So pycrc could not generate the table and I had to set it up
myself.  When I define all the options, pycrc builds the table for me.

Thank you for the sanity check!




On Sat, Apr 3, 2010 at 11:09 AM, C. Mundi <cm...@gm...> wrote:

> Thanks for your quick response.  I am out of the office today but will
> send my command line and output files tomorrow or Monday.  I did
> specify individual parameters on the command line and generated
> separate c and h files -- no main().
>
> BTW, I took a quick look at the py files.  Wow.  A whole macro
> language.  Impressive.
>
> Thanks!
>
>
> On 4/3/10, Thomas Pircher <te...@gm...> wrote:
> > C. Mundi wrote:
> >> I was a little surprised that all my crc's were coming back zero until I
> >> realized I forgot to initialize the table!
> >
> > Oh! Sorry, I guess I should state that more prominently in the
> > documentation.
> >
> >> It would be nice to update the example at the end of the man page now
> that
> >> the most functions require a pointer to a crc_config_t.
> >
> > There are actually two examples in pycrc:
> > - The fully fledged version contained in test/main.c
> > - A shorter version generated by the --generate c-main option
> >
> > I have updated the man page (http://www.tty1.net/pycrc/pycrc.html) with
> an
> > additional paragraph that points to the example code.
> >
> >
> > But I don't understand the second part of your last sentence. If your
> model
> > is
> > fully defined when you generate the C code (using either the --model
> option
> > or
> > each of the options --width, --poly, --reflect-in, --xor-in,
> --reflect-out
> > and
> > --xor-out) then you do not need to pass a pointer to a crc_cfg_t
> structure.
> > You also don't need to call crc_table_init() and in general, the code
> runs
> > faster.
> >
> > I spent some time for the last version to further reduce the cases where
> the
> > crc_cfg_t structure is used, so if you have come across of a case where
> it
> > is
> > still used unnecessarily, please let me know!
> >
> > Thank you,
> > Thomas
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Pycrc-users mailing list
> > Pyc...@li...
> > https://lists.sourceforge.net/lists/listinfo/pycrc-users
> >
>

Re: [Pycrc-users] type mismatches solved

[C. M. <cm...@gm...>]

Thanks for your quick response.  I am out of the office today but will
send my command line and output files tomorrow or Monday.  I did
specify individual parameters on the command line and generated
separate c and h files -- no main().

BTW, I took a quick look at the py files.  Wow.  A whole macro
language.  Impressive.

Thanks!


On 4/3/10, Thomas Pircher <te...@gm...> wrote:
> C. Mundi wrote:
>> I was a little surprised that all my crc's were coming back zero until I
>> realized I forgot to initialize the table!
>
> Oh! Sorry, I guess I should state that more prominently in the
> documentation.
>
>> It would be nice to update the example at the end of the man page now that
>> the most functions require a pointer to a crc_config_t.
>
> There are actually two examples in pycrc:
> - The fully fledged version contained in test/main.c
> - A shorter version generated by the --generate c-main option
>
> I have updated the man page (http://www.tty1.net/pycrc/pycrc.html) with an
> additional paragraph that points to the example code.
>
>
> But I don't understand the second part of your last sentence. If your model
> is
> fully defined when you generate the C code (using either the --model option
> or
> each of the options --width, --poly, --reflect-in, --xor-in, --reflect-out
> and
> --xor-out) then you do not need to pass a pointer to a crc_cfg_t structure.
> You also don't need to call crc_table_init() and in general, the code runs
> faster.
>
> I spent some time for the last version to further reduce the cases where the
> crc_cfg_t structure is used, so if you have come across of a case where it
> is
> still used unnecessarily, please let me know!
>
> Thank you,
> Thomas
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pycrc-users mailing list
> Pyc...@li...
> https://lists.sourceforge.net/lists/listinfo/pycrc-users
>

[Pycrc-users] type mismatches solved

[C. M. <cm...@gm...>]

I have not fully validated the results, but casting the return value of
crc_reflect() to crc_t seems to give good results (not just quiet the
compiler).

I was a little surprised that all my crc's were coming back zero until I
realized I forgot to initialize the table!

It would be nice to update the example at the end of the man page now that
the most functions require a pointer to a crc_config_t.

Thank you very much!

[Pycrc-users] type mismatches

[C. M. <cm...@gm...>]

This question must come up all the time, but I'm not picking the right
keywords for searching the archives...

I just grabbed pycrc-0.7.5 and generated C99 code for CRC16 with the default
polynomial.

My platform is Visual Studio (various versions) and I am using Alexander
Chemeris's implementation of stdint.h, which I think is probably fine.

All three generated functions crc_init(), crc_table_gen(), and
crc_finalize() implicitly cast the return value of crc_reflect() [which
returns unsigned_long] to crc_t.  The latter is uint16_t which is an
unsigned short (per Chemeris's stdint.h).  So naturally, the compiler warns
about possible loss of data.

It's clear enough to me that we want the final crc value to be 16 bits.  But
do we really mean to discard the upper-half of crc_reflect?  And if so, why
is there not an explicit cast?  If that answer is efficiency, fine.  But I'm
afraid I do not understand the CRC algorithm well enough to be sure.

Thanks!

Re: [Pycrc-users] pypi registration [was: pycrc v0.7.3 released.]

[Jesus C. <jc...@jc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Pircher wrote:
> Jesus Cea wrote:
>> Thomas, please consider submitting your code to PYPI
>> (http://pypi.python.org/):
> I didn't know about this project. Thanks for pointing out!
> What I gather from their web site is that it is a list of python modules,
> where pycrc doesn't really qualify for. Am I wrong?

Python modules people create and want other to find, download and
install easily. Somewhat similar to Perl CPAN, for example.

You can (and I think you should :) upload pycrc to PYPI.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jc...@jc... - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jc...@ja...         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSu7/EJlgi5GaxT1NAQI8ygP/eQL1PLxEvMxtD4SgDsddibgxSehspaay
9SggxIlAHLsFADZOHW6SHy/opF65kDKwJKHYahdaU0wbOx5II1bs9lLeJczqytij
E6i7JDhegyixOJ6s4QPM5pl8aLSyvTd/ZLe8RFOzJiInJqMMR3WG/Ht0F+Jdf4Nb
OyWrOB0ymTg=
=cHdk
-----END PGP SIGNATURE-----

Re: [Pycrc-users] pycrc v0.7.3 released.

[Jesus C. <jc...@jc...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Pircher wrote:
> Version 0.7.3 is only a small feature enhancement release:

Thomas, please consider submitting your code to PYPI
(http://pypi.python.org/):

[root@stargate-host /]# easy_install -U pycrc
Searching for pycrc
Reading http://cheeseshop.python.org/pypi/pycrc/
Couldn't find index page for 'pycrc' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
No local packages or download links found for pycrc
error: Could not find suitable distribution for Requirement.parse('pycrc')

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jc...@jc... - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jc...@ja...         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSucv6Zlgi5GaxT1NAQJz4gP/f3yzXK/GQFJFWmZTR/wN9A0Fv+my99CQ
eNThManS5xJFlpV1VuP5Ca1VGu+aMgDFO9zrmFw6r4zVgqdPheyKp+xMjLHFxH1S
+Hua+HPEN5E6UhABptJPJ0nOVyBzFIldOzuUXPD7bj4IACA4XfDPpI8OcwN5lDBZ
HnzvwiN93XE=
=MzJM
-----END PGP SIGNATURE-----

[Pycrc-users] Clarity restored

[Bruce G. <bg...@wa...>]

OK, I see it now.  I was led astray by the thought, that since the table 
driven method would not work on the CRC-7 used on MMC/SD cards,  that 
the two bit by bit methods actually gave different results for lengths 
that were not a multiple of eight.  The link you gave is a terrific 
article by the way.

Thanks