Има различни алгоритми за смятането... Има различни полиноми, зависи дали се смята LSB или MSB данни, зависи от размера на данните и т.н.

В зависимост от размера може да е:
- побитово
- на тедради
- на байтове
- на думи

Разликата е както в скоростта на смятане, така и в размера на функцията и евентуално размера на таблицата. Въпросът е че понякога си трябва скорост, а понякога е важно мястото, щото в един буутстрап е грехота да шибнеш 1к CRC таблица...
Проблемът е, че в нета поне аз не намирам всички варианти на едно място, а не ми се губи време да ги разписвам... Всъщност в Boots има Ц++ шаблони, ама да се вади от тях е кошмар.

Та дайте да съберем на едно място, говоря за стандартно CRC 32 (polinom 0x04C11DB7 / 0xEDB88320) и LSB данни...

Побитово е така (взаимствано от лайнукс):


Вариант за побайтово има тук. Някъде имаше и вариант със смятане на таблицата в RAM... Нещо обаче не намирам варианта с тедради, в ST форумите май имаше, ама с ревърс (MSB) но не ми се свапват битове...

Ето и мнението на TI CRC Implementation with MSP430
http://www.ti.com/mcu/docs/litabsmultip ... ilyId=1615
Тествано е работи със софтуерен битбанг ethernet.

За да не цапам повече темата допълвам тук.
miro_atc във архива има няколко имплементации на асемблер и на С. С таблици и без таблици.
Ако ти трябва имплементация за msp430 е просто копи/паста. Ако ти трябва за друг контролер С кода сигурно, ще може да се портне за 15 минути.

идеята беше да съберем на едно място работещ код.... Имам предвид сорс код, а не pdf-и за четене, нито пък асемблери за портване

Въпросът е да не се губи време за нещо толкова елементарно като CRC, даже аз се изненадах колко време изгубих да се ровя

Това е една руска библиотека дето съм я бутнал малко и аз.

мерси, ама в нея виждам само побитовия и побайтовия вариант... за тях вече дадох код по-горе

търси се на нибъли

ето тук има вариации на big/little endian и смятане на байт и на дума, плюс опция за ънролване до 32 байта...

Тук има и табличния вариант за смятане. Затова я постнах

Това с нибълите не е проблем. Връзката между побитовия и побайтовия вариант е много проста - побайтовата таблица е сметната като побитово за всички 256 числа - 0 .. FF. Може да си сметнеш само за нибъли като повтаряш 4 пъти (за 4 бита) побитово CRC за всички числа от 0 до F. Разбира си има значение и в каква посока ще въртиш битовете - но като цяло е проста работа.

И нещо което е полезно да се знае - CRC е линейна функция - т.е:

в случая оператора е "^" а не "+" или "*" защото този оператор се ползва в самия CRC полином.

Абе теорията е ясна... ама просто ми трябваше да сравня вариантите и да видя как излизат като код и после да реша кое да ползвам. Че тъпанарите от ST пак са си оставили ръцете, сложили хардуерно црц ама биг ендиан (идиоти ) така че да не става да се ползва ДМА, сложили го и да бачка само на думи, да се чудиш как да довършваш...

Иначе ето кода за нибъли дето съчиних:

Ами супер. Значе ще можеш да си битбангваш ethernet и да ползваш това хардуерното црц.

Miro, аз избягвам типа "int" по обясними причини: ползвам и 8, и 16, и 32 битови ядра.
Вместо него добре пасват char, short, long

bate, не гледай типовете... копирал съм квото ми падне

Иначе аз нямам проблем с int, просто не ползвам 8-бит отдавна...

Относно црц-тата общо взето стигнах до следните заключения:
- Побайтовия вариант дето масово циркулира из нета е тъпо решение за контролери. Не само че яде 1к за таблица, ами е и доста бавничък - при АРМ излиза някъде 10-на клока на сметнат байт. Задължително трябва да се добави оптимизация за смятане на думи, тогава пада под 6 клока/байт.
- Вариантът с нибъли/тетради ползва само 64 байта таблица и ако се добави ънролването на думи е 9.5 клока/байт, демек е по-бързо от стандартното решение и заема къде къде по-малко място.
- Побитовия вариант е поне 20 клока и не подлежи на оптимизация, така че не става. Всъшност 20 е оптимизираната версия с ънролнат цикъл на битовете, абе не става и тва е...
- Вариантът с хардуерната сметалка на ST се оказа по-добър отколкото очаквах, ако се разгъне цикъла да смята на по 32 байта, въпреки ревърсването на битове сметките отиват под 1 клок/байт... или поне се надявам, понеже ST нищо не споменават за waitstates...

Според производителите значи за АРМ-чета може да се обобщи така:
- При Луминари голямата таблица я има на РОМ така че решението побайтовия вариант + оптимизация на думи.
- При ST за големи обеми и ако няма нужда от мултитаскинг най-добре е хардуерната сметачка, оптимизирана на 32 байта плюс падване на тетради
- При Атмел някои имат сметачка и доколкото си спомням тя е ОК, а където няма избора е между тетради и побайтово, според това дали има място за голямата таблица... Естествено и в двата случая си трябва оптимизацията за сметки на думи...

И те така

ами на мен ми харесват два варианта
http://www.cs.miami.edu/~burt/learning/ ... c/crc-32.c

и този на апле:

http://www.opensource.apple.com/source/ ... rn/crc32.c


като цяло са еднакви

@MYXATA, тва си е стандартното црц... само че както казах в тоя си вид не е особено подходящо (яде над 1к флаш и смята един байт за ~10 клока).

Поне тая преработка трябва да се направи:


По-горе мисля дадох линк с вариант с цялата функция, т.е. първо смята на цели думи докато дължината е >=4 и после байт по байт в случай че не е кратно на 4. С тая преработка кодът се увеличава съвсем малко - около 30-40 байта, което е нищо на фона от 1К. Обаче бързодействието се вдига с 40%