CRC_CCITT 16-bit assembly language code

>
>"Vy" <vywack@yahoo.com> wrote in message
news:8IadnVeJarjGubvanZ2dnUVZ_tOtnZ2d@giganews.com...
>
>> I've checked out Lammert's website. He does not append zeroes (equal
to
>> width) to his calculation and also as i mentioned in the beginning my
>> initial value is 1d0f. So my calculations and his never match.
>
>You don't need to worry about the zeroes, as they are typically part of
>the data, even if they are not part of the message. For example you are
>processing one word at a time, so if there is only one bit data in it
there
>will be 31 zeroes in the word.
>
>> Having said that, i have just finished writing and testing my own code
and
>> voila it works. However i must mention that it's an application
specific
>> code that may or may not be of use to one and all.
>
>I'd test it a bit more before calling it finished... I found at least 3
mistakes in
>it that will cause it to fail in various ways. Apart from that you could
speed it
>up a lot by removing all the redundant instructions. As I said before, it
would
>be best to start with C, as you'd get much smaller and faster code that
way.
>
>Wilco 
>
>
Read the article by Joe Geluso about appending zeroes and also read the
CRC_CCITT specifications document. Zeroes have nothing to do with data.

my code as i said is application specific. Also i don't need to start with
C as there is a lot of good code already written in C that is free for all
to use. Why would anybody want to develop source code in C from scratch
when there's superfast crc code already splattered across websites all
over the world?

My code spits out the right answer for data ranging from 1 byte to as many
words in any permutation and combination (for example 2 words and 1 byte)
as i possibly require for my application. My application will never have a
single bit data so it does not interest to me pursue those avenues.

State those 3 mistakes instead of just making a blank statement and also
state the redundant instructions.

Undoubtedly the code can be speeded up. 

Only make statements if you have concrete "assembly language " code to
support your statements.

Vy

"Vy" <vywack@yahoo.com> wrote in message news:ZuydnTetNLdhxLvanZ2dnUVZ_jmdnZ2d@giganews.com...
> >
>>"Vy" <vywack@yahoo.com> wrote in message
> news:8IadnVeJarjGubvanZ2dnUVZ_tOtnZ2d@giganews.com...

> Read the article by Joe Geluso about appending zeroes and also read the
> CRC_CCITT specifications document. Zeroes have nothing to do with data.

There are lots of ways of appending zeroes, but few would put code to do
this in the middle of the inner loop...

> my code as i said is application specific. Also i don't need to start with
> C as there is a lot of good code already written in C that is free for all
> to use. Why would anybody want to develop source code in C from scratch
> when there's superfast crc code already splattered across websites all
> over the world?

So why don't you use it then? Assembler is really only necessary if you
can't get the required performance from C.

> My code spits out the right answer for data ranging from 1 byte to as many
> words in any permutation and combination (for example 2 words and 1 byte)
> as i possibly require for my application. My application will never have a
> single bit data so it does not interest to me pursue those avenues.

If you only process bytes then any of the routines posted would be fine.

> State those 3 mistakes instead of just making a blank statement and also
> state the redundant instructions.

I'd like you to have a good look at the code yourself. For example, the code
enters an infinite loop if you call crc_16 with R3 = 8 or 16. With R3 = 24 or 32
the code simply ignores the given data and enters the zero bit loop instead.
It corrupts bit 0 of the CRC when it returns. Finally it uses various registers
without saving/restoring them, so if you call the routine from C the application
will crash.

Wilco 

>
>"Vy" <vywack@yahoo.com> wrote in message
news:ZuydnTetNLdhxLvanZ2dnUVZ_jmdnZ2d@giganews.com...
>> >
>>>"Vy" <vywack@yahoo.com> wrote in message
>> news:8IadnVeJarjGubvanZ2dnUVZ_tOtnZ2d@giganews.com...
>
>> Read the article by Joe Geluso about appending zeroes and also read
the
>> CRC_CCITT specifications document. Zeroes have nothing to do with
data.
>
>There are lots of ways of appending zeroes, but few would put code to do
>this in the middle of the inner loop...
>
>> my code as i said is application specific. Also i don't need to start
with
>> C as there is a lot of good code already written in C that is free for
all
>> to use. Why would anybody want to develop source code in C from
scratch
>> when there's superfast crc code already splattered across websites all
>> over the world?
>
>So why don't you use it then? Assembler is really only necessary if you
>can't get the required performance from C.
>
>> My code spits out the right answer for data ranging from 1 byte to as
many
>> words in any permutation and combination (for example 2 words and 1
byte)
>> as i possibly require for my application. My application will never
have a
>> single bit data so it does not interest to me pursue those avenues.
>
>If you only process bytes then any of the routines posted would be fine.
>
>> State those 3 mistakes instead of just making a blank statement and
also
>> state the redundant instructions.
>
>I'd like you to have a good look at the code yourself. For example, the
code
>enters an infinite loop if you call crc_16 with R3 = 8 or 16. With R3 =
24 or 32
>the code simply ignores the given data and enters the zero bit loop
instead.
>It corrupts bit 0 of the CRC when it returns. Finally it uses various
registers
>without saving/restoring them, so if you call the routine from C the
application
>will crash.


thanks !!!


>Wilco 
>
>
>

"Vy" <vywack@yahoo.com> wrote in message 
news:pIKdnXCiGNCbMILanZ2dnUVZ_sytnZ2d@giganews.com...
> Is there someone who has access to the CRC_CCITT 16-bit code written in
> ARM7 assembly language?
>
> I'm well aware that there's a ton of code in C for the same.
>
> What's funny is i can do the CRC calculation by hand and have also
> developed the algorithm but i'm unable to get the code up and running.
>
> I'd be happy to share the code that i wrote. If you can help me kindly
> send me an e-mail at vywack@yahoo.com or we can settle it on this forum.
>
> Thanks a ton
>
> Vy

Why not use a lookup table? Like:

http://www.nulib.com/library/Crc16.c.txt


What is driving assembly language? The table solution is FAST--if you have 
sufficient memory.

Bo