Задача : девайс на микроконтроллере должен нормально взаимодействовать с операционкой.
Память ограничена поэтому табличные алгоритмы неподходят.
Для отладки алгоритма написан такой код:

;
include def32.inc
include kernel32.inc
include user32.inc
include mapi32.inc

.386
.model flat
.const
; заголовок окна
hello_title db 'CRC computation.',0
; сообщение 123456789012345678901234567890
hello_message db ' ',0
;frame2 db 0,1,2,3,4,5,6,7,8,9,0,0,0,0,0,0,0,0
;frame2 db '123456789',0,0,0,0,0,0,0,0
;byte_counter EQU 9
;frame2 db 0FFh,03Fh,001h,00Bh,0D6h,01Dh,0C9h,0FFh,0FFh,0FFh,0FFh,001h ,000h,000h,0,0,0,0,0,0 ;C0 BD -phone
frame2 db 0FFh,03Fh,001h,071h,0AEh,034h,041h,0FFh,0FFh,0FFh,0FFh,001h, 001h,000h,0,0,0,0,0,0 ;BF 88 -phone
byte_counter EQU 14
;frame2 db 0FFh,03Fh,001h,03Ch,0A2h,04Fh,065h,0FFh,0FFh,0FFh,0FFh,001h ,005h,000h,02Ch,0ABh,0,0,0,0;-phone
;byte_counter EQU 16
;frame2 db 0,0,0,0,0,0,0,0,0,0;
;frame2 db 0FFh,0FFh,0,0,0,0,0,0,0;
;byte_counter EQU 2;

;сообщение должно быть выровнено, тоесть дополнено 2мя 0ми байтами
;в современных табличных реализации сообщение может не выравниваться
;полученный от деления остаток должен быть сохранен на место этих двух байт
;polinom EQU 01021h
;polinom EQU 08005h
polinom EQU 08408h
goodFCS EQU 0f0b8h ;не уч в вычислениях
FCSinit EQU 0ffffh
;на экран будет выводиться в обр послед [мл.байт ..... старший байт]


.code
_start:
mov edi,offset frame2 ;ds:di -> frame
mov bx,FCSinit ;inicial FCS
mov cx,byte_counter+2 ;counter byte

call crc_computation

not bx
dec edi
mov [edi],bh
dec edi
mov [edi],bl

add edi,6

not bx
dec edi
mov [edi],bh
dec edi
mov [edi],bl

mov edi,offset frame2 ;ds:di -> frame
mov bx,FCSinit ;inicial FCS
mov cx,byte_counter+4 ;counter byte

call crc_computation

; inc edi
; inc edi

dec edi
mov [edi],bh
dec edi
mov [edi],bl

push offset hello_message
push byte_counter+6
push offset frame2
call HexFromBin
POP AX

push MB_ICONINFORMATION ; стиль окна
push offset hello_title ; адрес строки с заголовком
push offset hello_message ; адрес строки с сообщением
push 0 ; идентификатор предка
call MessageBox
push 0 ; код выхода
call ExitProcess ; завершение программы

crc_computation:
next_byte:
jcxz end_crc_computation
mov byte ptr al,[edi] ;load next byte
inc edi
dec cx
mov dx,9

rotate_byte:
dec dx
jz next_byte
shr ax,1
rcr bx,1
jnc rotate_byte
xor bx,polinom
jmp rotate_byte

end_crc_computation:
ret


end _start


Анологичный код есть под AT90s2313, результаты идентичны, а вот при подсчете CRC захваченных пакетов, стабильно получается другое конечное значение, зависящее от длинны посылки.
Доступные документы в интернете на эту тему, как правило, описывают табличную реализацию.
Или псевдо табличную, она сложнее на первый взгляд, но дает большую производительность, чем в лоб.
Заранее спасибо за участие.

Gennadiy
Не бойтесь тэга code! Так совершенно неудобно читать...

Память ограничена поэтому табличные алгоритмы неподходят.
Ограничена на диске? Тогда можно создавать и заполнять таблицу в рантайме (исходники на masm32 есть в сети).

а вот при подсчете CRC захваченных пакетов, стабильно получается другое конечное значение, зависящее от длинны посылки.
Так оно и должно зависеть от длинны, разве не так?

Quantum
Спасибо за ответ.

Не бойтесь тэга code! Так совершенно неудобно читать...
Я о нем неимел представления-надо будет попробовать.

Ограничена на диске? Тогда можно создавать и заполнять таблицу в рантайме (исходники на masm32 есть в сети).
Диск отсутствует по определению. Память программ 1кб, команды 2 байта, память оперативная 128 байт, flash 128 байт - медленный доступ. Код перенесен на MASM для более удобной отладки. Возможно применение мс с объёмом памяти програм до 8кб, но они имеют более низкую тактовую частоту, ну и стоят дороже. Кроме того, такой алгоритм удобен если программно формируеш побитную передачу данных.

а вот при подсчете CRC захваченных пакетов, стабильно получается другое конечное значение, зависящее от длинны посылки.
Так оно и должно зависеть от длинны, разве не так?


При вычислении FCS от пакета уже содержащего в конце FCS вычисленного по томуже алгоритму и с темже полиномом, должно получаться значение goodFCS.
Что и происходит при обработке приведенным алгоритмом пакетов сформированных микроконтроллером, с использованием
этой версии алгоритма. При расчете FCS от захваченных пакетов сформированных, например, сотовым телефоном получается badFCS :))

Вот код для AT90S2313:

;_______________________CRC code computation subroutine
;INPUT
;XL=start_offset memory code computation
;"end_data_offset" end offset+1 memory code computation
;OUTPUT
;CRC2=highCRC
;CRC3=low CRC
;X=end_offset memory code computation
;USING
;CRC0	= r0		; Lower byte of lower word
;CRC2	= r2		; Lower byte of upper word
;CRC3	= r3		; Upper byte of upper word
;crdivl	= r4		; CRC divisor register
;crdivh	= r5		; CRC divisor register
;CRC_count= 		; Bit counter 

;***** Constants
.equ	CR		= 0x8408	; CRC divisor value for PPP CCITT

.macro CRC_init
	ldi 	temp,high(CR)	;Load divisor value
	mov 	crdivh,temp	;Load divisor value
	ldi	temp,low(CR)
	mov	crdivl,temp
	ldi	temp,9
	mov	CRCofBIT,temp
.endm

        .cseg
crc_computation:
;___________________________ Start loop
CRC_new_word:
	cp	XL,end_data_offset	;Loop starts here
	brge	CRC_end			;Jump if end of code
	ld	CRC0,X+		;Move to upper byte
	mov	CRC_count,CRCofBIT
CRC_rot_loop:
	dec 	CRC_count	;Decrement bit counter
	breq	CRC_new_word	;Break if bit counter = 0
	lsr	CRC0		;Shift zero into lowest bit
	ror	CRC2		;Preceede shift
	ror	CRC3			
	brcc	CRC_rot_loop	;Loop if MSB = 0			
	eor 	CRC2,crdivh
	eor 	CRC3,crdivl	;XOR high word if MSB = 1
	rjmp	CRC_rot_loop
CRC_end:	
;___________________________ End loop
ret
.exit

Gennadiy
Всё ясно. Реализаций CRC совсем без таблицы я не встречал (но и не искал). Вы смотрели в разделе "документы"? Там есть большой справочник по CRC. Дополнительно есть статья по реверсингу CRC в Codebreakers (тоже в "документах"). Там вполне может быть нетабличный алгоритм на ассемблере.

получается badFCS :))
Так может там другой полином? Или разрядность другая. Или вообще другой алгоритм. Помнится, я когда-то обрабатывал пакеты с CRC полученные по телефонной линии. Так мне производитель оборудования любезно предоставил таблицу промежуточных значений, которая заметно отличалась от стандартной :-)

Один образец кода на ассемблере с другим полиномом у меня есть - пытаюсь понять, что он там "крутит".
Я опирался на два документа: IrLAP11.pgf
взят с www.irda.org и нашел через поисковик crcguide.pdf там разжевано почти всё. Есть два сайта с примерами кода именно под эти микрухи, там реализация с псевдо таблицей - тоесть, операции над битами производят не в цикле, а путем их комбинаций по установленному для данного полинома закону.
Согласно IrLAP11.pgf на этом уровне применен PPP Slip протокол. Ничего не остается как проверять таблицу.
Я пробовал два байта посчитать руками по таблице - результат совпал - вот будет интересно если твой опыт повторится.

Два решения нашел сам. Кому интересно пишите.
Так может там другой полином? Или разрядность другая. Или вообще другой алгоритм.
Таблица указана верно. Код представленный мной, написан верно(если несчитать мусор в стеке). Ошибок было несколько, сначала читал невнимательно потом в экспериментах ошибался.

В документах на сайте в ручную не рылся, а поисковик недал ничего лучше того, что у меня уже было.

Люди, так Вы тут как раз про связь телефона с компом говорите????
Может мне что подскажете? Можно пару вопросов то?