CRC_CCITT 16-bit assembly language code

Is there someone who has access to the CRC_CCITT 16-bit code written i 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 als 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 kindl send me an e-mail at snipped-for-privacy@yahoo.com or we can settle it on this forum.

Thanks a ton

Vy

Reply to
Vy
Loading thread data ...

Just a wild-assed guess, are you remembering to "flush" the crc routine with zeros at the end?

Reply to
Jim Stewart

Does someone have access to CRC_CCITT 16-bit code written in ARM7 assembl language.

I am well aware of the fact that there is a ton of code in C for th same.

What's funny is that i can do the calculation by hand and also have th algorithm but i'm not able to get the code up and running.

If someone is able to help me out i'd be happy to share the code.

Vy snipped-for-privacy@yahoo.com

Reply to
Vy

in

forum.

Here's the detail...for more detail check out the paper by Mr Ros Williams

The initial value is 0x1d0f The Poly is 0x1021 which is actually 1 0001 0000 0010 0001 The width is 16 so 16 zeroes are appended to the message for example the message is 41h - 0100 0001

poly= ------------------------------------------

10001000000100001 ) 1111111111111111010000010000000000000000

my problem is how do i position the 17 bits (Poly) within a 32 bi register. Do i keep it at the far right (towards MSB)?

thanks

Vy

Reply to
Vy

Will the below link help you ?

formatting link

Try looking at the Linux implementation w.r.t this on ARM . I think, the ARM CRC routines should be in assembly and they may help you.

Karthik Balaguru

Reply to
karthikbalaguru

How about starting with a working C implementation and optimise it? After that you will realise that it isn't possible to do any better in assembler... A good implementation needs about 4-5 instructions for every 8 input bits.

Wilco

Reply to
Wilco Dijkstra

1) How does the data come in: a) by octet (byte) or by bit? 2) Study project / homework?

For the CRC_CCITT there are at least 3 ways to implement:

- 1 bit at a time - 4 bits at a time - 8 bits (1 byte/octet) at a time

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

Here is some ARM assembly code for implimenting CRC-CCITT.

formatting link

Regards Anton Erasmus

Reply to
Anton Erasmus

in

forum.

the data could come in anywhere from a byte to a word (32bits) to severa words. The words are broken down into bytes. The byte is broken down t bits to feed it to the CRC, check if the topmost bit is 1, if yes XOR i if not get the next bit in.

i'm working with a Fujitsu MC that uses SPI to talk to the host. An SPI i a very simple protocol with no CRCs and ACKs but they have added their ow pyrotchnics to included CRC checking and ACK at the end of evey stream o message.

thanks for the input Tauno

Reply to
Vy

forum.

Hi Anton,

I already went through that code. It's not right. I'm using ARM7 and ARM does not have instructions like ASL. It only has LSL. Also the person uses $ signs in front of hex numbers which i can't figur out why.

Maybe an older version of ARM supported all that but with ARM7 none o that exists.

THanks Anton

Reply to
Vy

LSL and ASL are the same thing. The assembler used, probably has a few pseudo instructions to help with readability.

Regards Anton Erasmus

Reply to
Anton Erasmus

... snip ...

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.
Reply to
CBFalconer

in

running.

kindly

ARM7

figure

No, LSL and ASL are not the same thing. They have nothing to with th 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 Architectur Reference manual for ARM7 v4.4 and above.

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

Regards Vy

Reply to
Vy

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

Reply to
Anton Erasmus

written

of

manual.

that

with

the head. I apologize for any irritation caused.

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

Regards Vy

Reply to
Vy

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.

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

Reply to
Wilco Dijkstra

news:pKKdnZe18aYGxL_anZ2dnUVZ snipped-for-privacy@giganews.com...

manual.

that

with

the

bit). Implicit bit 32

it only shifts one bit.

Reply to
Vy

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

Reply to
Arlet

Reply to
Petter Gustad

in

I've checked out Lammert's website. He does not append zeroes (equal t width) to his calculation and also as i mentioned in the beginning m initial value is 1d0f. So my calculations and his never match.

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

formatting link

Having said that, i have just finished writing and testing my own code an voila it works. However i must mention that it's an application specifi 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 th program ;R4=R8 tells us when to stop rotating the word in case there are less tha

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 an not 16 bits the first

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

;message and then start the XOR process mov R4,R8 ;this is for when to stop rotating th 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

Reply to
Vy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.