CRC_CCITT 16-bit assembly language code

Anton Erasmus wrote:
> "Vy" <vywack@yahoo.com> wrote:
> 
... snip ...
>
>> I already went through that code. It's not right. I'm using ARM7
>> and ARM7 does not have instructions like ASL. It only has LSL.
>> Also the person uses $ signs in front of hex numbers which i
>> can't figure out why.
>>
>> Maybe an older version of ARM supported all that but with ARM7
>> none of that exists.
> 
> LSL and ASL are the same thing. The assembler used, probably has
> a few pseudo instructions to help with readability.

The $ sign is a fairly normal way of signifying that the following
value is expressed in hex.  While LSL and ASL are basically
identical, LSR and ASR are normally much different.  Firstly the L
versions shift in a zero bit, while the ASR version copies the sign
bit.  Secondly the L versions can't overflow, while the ASL can,
leaving undefined conditions.

There are often LRR and LRL instructions, which copy the carry bit
into the appropriate end.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

>On Fri, 26 Oct 2007 02:27:06 -0500, "Vy" <vywack@yahoo.com> wrote:
>
>>>On Wed, 24 Oct 2007 15:37:26 -0500, "Vy" <vywack@yahoo.com> wrote:
>>>
>>>>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.
>>>>
>>>
>>>Here is some ARM assembly code for implimenting CRC-CCITT.
>>>http://homepages.tesco.net/~rainstorm/crc-catalogue.htm
>>>
>>>Regards
>>>  Anton Erasmus
>>>
>>Hi Anton,
>>
>>I already went through that code. It's not right. I'm using ARM7 and
ARM7
>>does not have instructions like ASL. It only has LSL.
>>Also the person uses $ signs in front of hex numbers which i can't
figure
>>out why.
>>
>>Maybe an older version of ARM supported all that but with ARM7 none of
>>that exists.
>
>LSL and ASL are the same thing. The assembler used, probably has a few
>pseudo instructions to help with readability.
>
>Regards
>  Anton Erasmus
>
No, LSL and ASL are not the same thing. They have nothing to with the
assembler and is defined by ARM in the ARM Architecture Reference manual.

There is only LSL. ASL in not defined by ARM in the ARM Architecture
Reference manual for ARM7 v4.4 and above.

There is however both ASR and LSR. The difference between them being that
when you use LSR the bits on the left are padded with zeroes whereas with
ASR the bits on the left are padded with the bit that was present in
CARRY.
If carry was 1, all bits to the left will be 1 and if 0 all bits to the
left shall be zero.

Regards
Vy

On Fri, 26 Oct 2007 16:18:19 -0500, "Vy" <vywack@yahoo.com> wrote:

>>On Fri, 26 Oct 2007 02:27:06 -0500, "Vy" <vywack@yahoo.com> wrote:
>>
>>>>On Wed, 24 Oct 2007 15:37:26 -0500, "Vy" <vywack@yahoo.com> wrote:
>>>>
>>>>>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.
>>>>>
>>>>
>>>>Here is some ARM assembly code for implimenting CRC-CCITT.
>>>>http://homepages.tesco.net/~rainstorm/crc-catalogue.htm
>>>>
>>>>Regards
>>>>  Anton Erasmus
>>>>
>>>Hi Anton,
>>>
>>>I already went through that code. It's not right. I'm using ARM7 and
>ARM7
>>>does not have instructions like ASL. It only has LSL.
>>>Also the person uses $ signs in front of hex numbers which i can't
>figure
>>>out why.
>>>
>>>Maybe an older version of ARM supported all that but with ARM7 none of
>>>that exists.
>>
>>LSL and ASL are the same thing. The assembler used, probably has a few
>>pseudo instructions to help with readability.
>>
>>Regards
>>  Anton Erasmus
>>
>No, LSL and ASL are not the same thing. They have nothing to with the
>assembler and is defined by ARM in the ARM Architecture Reference manual.
>
>There is only LSL. ASL in not defined by ARM in the ARM Architecture
>Reference manual for ARM7 v4.4 and above.
>
>There is however both ASR and LSR. The difference between them being that
>when you use LSR the bits on the left are padded with zeroes whereas with
>ASR the bits on the left are padded with the bit that was present in
>CARRY.
>If carry was 1, all bits to the left will be 1 and if 0 all bits to the
>left shall be zero.

So what is the difference between LSL and ASL ? 
Having worked with ARM since the ARM2 days on Acorn Archimedes
computers, I know that the assemblers had an LSL and ASL mnemonic, but
they both generated an LSL instruction. One would normally have used
the ASL to just remind oneself that one is working with signed values.
It is easy to forget that when shifting right that one should have
used an ASR and not a LSR.  So when working with signed values one
used ASL and ASR, and when working with unsigned values one used LSL
and ASL.

Regards
  Anton Erasmus

>On Fri, 26 Oct 2007 16:18:19 -0500, "Vy" <vywack@yahoo.com> wrote:
>
>>>On Fri, 26 Oct 2007 02:27:06 -0500, "Vy" <vywack@yahoo.com> wrote:
>>>
>>>>>On Wed, 24 Oct 2007 15:37:26 -0500, "Vy" <vywack@yahoo.com> wrote:
>>>>>
>>>>>>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.
>>>>>>
>>>>>
>>>>>Here is some ARM assembly code for implimenting CRC-CCITT.
>>>>>http://homepages.tesco.net/~rainstorm/crc-catalogue.htm
>>>>>
>>>>>Regards
>>>>>  Anton Erasmus
>>>>>
>>>>Hi Anton,
>>>>
>>>>I already went through that code. It's not right. I'm using ARM7 and
>>ARM7
>>>>does not have instructions like ASL. It only has LSL.
>>>>Also the person uses $ signs in front of hex numbers which i can't
>>figure
>>>>out why.
>>>>
>>>>Maybe an older version of ARM supported all that but with ARM7 none
of
>>>>that exists.
>>>
>>>LSL and ASL are the same thing. The assembler used, probably has a few
>>>pseudo instructions to help with readability.
>>>
>>>Regards
>>>  Anton Erasmus
>>>
>>No, LSL and ASL are not the same thing. They have nothing to with the
>>assembler and is defined by ARM in the ARM Architecture Reference
manual.
>>
>>There is only LSL. ASL in not defined by ARM in the ARM Architecture
>>Reference manual for ARM7 v4.4 and above.
>>
>>There is however both ASR and LSR. The difference between them being
that
>>when you use LSR the bits on the left are padded with zeroes whereas
with
>>ASR the bits on the left are padded with the bit that was present in
>>CARRY.
>>If carry was 1, all bits to the left will be 1 and if 0 all bits to the
>>left shall be zero.
>
>So what is the difference between LSL and ASL ? 
>Having worked with ARM since the ARM2 days on Acorn Archimedes
>computers, I know that the assemblers had an LSL and ASL mnemonic, but
>they both generated an LSL instruction. One would normally have used
>the ASL to just remind oneself that one is working with signed values.
>It is easy to forget that when shifting right that one should have
>used an ASR and not a LSR.  So when working with signed values one
>used ASL and ASR, and when working with unsigned values one used LSL
>and ASL.
>
>Regards
>  Anton Erasmus
>
>
>You're right. As far as the functioning is concerned you hit the nail on
the head. I apologize for any irritation caused.

I was going purely by the fact that ASL is not defined in the current
reference manual and hence it's a good practice to avoid a shifter_operand
that isin't supported.

Regards
Vy

"Vy" <vywack@yahoo.com> wrote in message news:pKKdnZe18aYGxL_anZ2dnUVZ_uyinZ2d@giganews.com...
> >On Fri, 26 Oct 2007 02:27:06 -0500, "Vy" <vywack@yahoo.com> wrote:

>>LSL and ASL are the same thing. The assembler used, probably has a few
>>pseudo instructions to help with readability.
>>
>>Regards
>>  Anton Erasmus
>>
> No, LSL and ASL are not the same thing. They have nothing to with the
> assembler and is defined by ARM in the ARM Architecture Reference manual.

ASL and LSL are of course identical. LSL is the official mnemonic and
some older assemblers allowed ASL as a synonym. So you can do a
search and replace.

> There is only LSL. ASL in not defined by ARM in the ARM Architecture
> Reference manual for ARM7 v4.4 and above.
>
> There is however both ASR and LSR. The difference between them being that
> when you use LSR the bits on the left are padded with zeroes whereas with
> ASR the bits on the left are padded with the bit that was present in
> CARRY.
> If carry was 1, all bits to the left will be 1 and if 0 all bits to the
> left shall be zero.

Wrong. ASR doesn't shift the carry, it simply copies bit 31 (the sign bit). Implicit bit 32
is the carry. The only instruction that can shift the carry is RRX, but it only shifts one bit.

Wilco 

>
>"Vy" <vywack@yahoo.com> wrote in message
news:pKKdnZe18aYGxL_anZ2dnUVZ_uyinZ2d@giganews.com...
>> >On Fri, 26 Oct 2007 02:27:06 -0500, "Vy" <vywack@yahoo.com> wrote:
>
>>>LSL and ASL are the same thing. The assembler used, probably has a few
>>>pseudo instructions to help with readability.
>>>
>>>Regards
>>>  Anton Erasmus
>>>
>> No, LSL and ASL are not the same thing. They have nothing to with the
>> assembler and is defined by ARM in the ARM Architecture Reference
manual.
>
>ASL and LSL are of course identical. LSL is the official mnemonic and
>some older assemblers allowed ASL as a synonym. So you can do a
>search and replace.
>
>> There is only LSL. ASL in not defined by ARM in the ARM Architecture
>> Reference manual for ARM7 v4.4 and above.
>>
>> There is however both ASR and LSR. The difference between them being
that
>> when you use LSR the bits on the left are padded with zeroes whereas
with
>> ASR the bits on the left are padded with the bit that was present in
>> CARRY.
>> If carry was 1, all bits to the left will be 1 and if 0 all bits to
the
>> left shall be zero.
>
>Wrong. ASR doesn't shift the carry, it simply copies bit 31 (the sign
bit). Implicit bit 32
>is the carry. The only instruction that can shift the carry is RRX, but
it only shifts one bit.
>
>Wilco 
>
>
>ur right. Wilco

On Oct 24, 9:37 pm, "Vy" <vyw...@yahoo.com> wrote:

> Is there someone who has access to the CRC_CCITT 16-bit code written in
> ARM7 assembly language?

I use the following C code:

uint16_t crc_ccitt_update( uint16_t crc, uint8_t data )
{
    uint16_t tmp;

    tmp = data ^ (crc >> 8);
    tmp ^= tmp >> 4;
    crc = (crc << 8) ^ tmp ^ (tmp << 5) ^ (tmp << 12);
    return crc;
}

Using an initialization of 0xffff for the CRC, the results agree with
this on-line CRC calculator:

http://www.lammertbies.nl/comm/info/crc-calculation.html

The ARM7 assembly version could be something like this (not tested)

// a1 contains old crc (initialize with 0xffff)
// a2 contains data byte
// result: a1 contains new crc

    eor a2, a2, a1, lsr #8
    eor a2, a2, a2, lsr #4
    eor a1, a2, a1, lsl #8
    eor a1, a1, a2, lsl #5
    eor a1, a1, a2, lsl #12
    bic a1, a1, #0xff0000

(The last 'bic' converts the result to 16 bit, using the observation
that the MSB remained 0)

A table based approach could probably save a couple of instructions,
but requires 512 bytes of fast memory for the table, which is often
not desirable on an embedded system.

Regards,
Arlet Ottens

Arlet <usenet+5@c-scape.nl> writes:

> On Oct 24, 9:37 pm, "Vy" <vyw...@yahoo.com> wrote:
> 
> > Is there someone who has access to the CRC_CCITT 16-bit code written in
> > ARM7 assembly language?
> 
> I use the following C code:
> 
> uint16_t crc_ccitt_update( uint16_t crc, uint8_t data )
> {
>     uint16_t tmp;
> 
>     tmp = data ^ (crc >> 8);
>     tmp ^= tmp >> 4;
>     crc = (crc << 8) ^ tmp ^ (tmp << 5) ^ (tmp << 12);
>     return crc;
> }

The optimal routine depends upon the width of the incoming data and
the amount of memory you have to store a table. If you have 128kB of
FLASH to store a table you can get along with doing a single table
lookup and a xor operation per 16-bit input (in Common Lisp):
http://tinyurl.com/2hswl5

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

>On Oct 24, 9:37 pm, "Vy" <vyw...@yahoo.com> wrote:
>
>> Is there someone who has access to the CRC_CCITT 16-bit code written
in
>> ARM7 assembly language?
>
>I use the following C code:
>
>uint16_t crc_ccitt_update( uint16_t crc, uint8_t data )
>{
>    uint16_t tmp;
>
>    tmp = data ^ (crc >> 8);
>    tmp ^= tmp >> 4;
>    crc = (crc << 8) ^ tmp ^ (tmp << 5) ^ (tmp << 12);
>    return crc;
>}
>
>Using an initialization of 0xffff for the CRC, the results agree with
>this on-line CRC calculator:
>
>http://www.lammertbies.nl/comm/info/crc-calculation.html
>
>The ARM7 assembly version could be something like this (not tested)
>
>// a1 contains old crc (initialize with 0xffff)
>// a2 contains data byte
>// result: a1 contains new crc
>
>    eor a2, a2, a1, lsr #8
>    eor a2, a2, a2, lsr #4
>    eor a1, a2, a1, lsl #8
>    eor a1, a1, a2, lsl #5
>    eor a1, a1, a2, lsl #12
>    bic a1, a1, #0xff0000
>
>(The last 'bic' converts the result to 16 bit, using the observation
>that the MSB remained 0)
>
>A table based approach could probably save a couple of instructions,
>but requires 512 bytes of fast memory for the table, which is often
>not desirable on an embedded system.
>
>Regards,
>Arlet Ottens
>
>
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.

A better place to check values and according to me the best online
calculator on the web for CRC where one can change all the parameters
according to one's choice can be found at

http://www.zorc.breitbandkatze.de/crc.html

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.

;R0= initial value
;R1= data word
;R2= polynomial
;R3= length of message in bits which shall be the outermost counter in the
program 
;R4=R8 tells us when to stop rotating the word in case there are less than
4 bytes in the word, R8 is in bits
		

crc_16 	
ldr	R0,=0x1d0f
		ldr	R2,=2_10001000000100001
		subs	R3,R3,#16			
		;mov	R3				;load in program, 
		

crc16_next	mov	R0,R0,LSL#1			;since the poly is actually 17 bits long and
not 16 bits the first 	

							;step is to shift it left by one to accomodate the first bit of the
	

							;message and then start the XOR process	
		mov	R4,R8				;this is for when to stop rotating the
word,1-9,2-17,3-25,4-33
				 	
	
mainloop						
		subs	R3,R3,#1			;if zero, crc calc ic over and result is present in R0
		beq	finish
		cmp	R3,#16				;If R3 is <=16, go to the subroutine that appends the
zeroes
		bls	append_zeroes
		subs	R4,R4,#1			

bit_shift	
		mov	R1,R1,ROR#31			;R1 is the data word
		mov	R5,R1	
		and	R5,R5,#0x00000001
		orr	R0,R0,R5

append_zeroes	
		mov     R10,R0
		ands	R10,R10,#0x00010000		;to check if CRC must be Exclusive ORed 
		bne	docrc
next		mov	R0,R0,LSL#1
		bal	mainloop
		
docrc		eor	R0,R0,R2
		bal	next

		
next_word	mov	R0,R0,LSR#1
		BX	R14
				
finish		mov	R0,R0,LSR#1
	   	BX	R14

"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