Reply by Bo November 6, 20072007-11-06
"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
Reply by Vy November 2, 20072007-11-02
> >"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 > > >
Reply by Wilco Dijkstra October 31, 20072007-10-31
"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
Reply by Vy October 29, 20072007-10-29
> >"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
Reply by Wilco Dijkstra October 29, 20072007-10-29
"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
Reply by Vy October 29, 20072007-10-29
>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
Reply by October 29, 20072007-10-29
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?
Reply by Arlet October 28, 20072007-10-28
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
Reply by Vy October 28, 20072007-10-28
> >"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
Reply by Wilco Dijkstra October 28, 20072007-10-28
"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