аз те разбрах за ТСР-то, явно моя е грешката... Можеш ли да дадеш някакъв съвет за MD5 понеже никога досега не съм се занимавал с чек суми? Това за УРТА ще го проверя, но ми смениха малко приоритетите - да се било доказало hard flow contol-а дали уж работи....

Всички чипъри работят по следния алгоритъм:

1. Инициализарат се шифт регистрите с инициализационен вектор или някаква константа.
2. Обработва се на парче с размер един блок и така колкото цели блока можеш
3. Ако остане накрая по-малко от един блок се пад-ва по определен начин и се смята и той.

Затова обикновено API-та имат функции за
1. инициализация - викаш я еднократно в началото
2. смятане на 1 блок. Викаш я за всеки блок данни
3. пад-ване - евентуално за последния непълен блок (ако имаш такъв)

Това е общо взето за всички... Някои библиотечки са удобство имат и функция, която прави всичко по-горе накуп, но трябва и да й дадеш всичку данни накуп

В твоя случай MD5 доколкото помня се работи с 512 бита, така че е силно желателно буферът ти да е кратен на 64 байта. Може да е 64, 128.. и т.н. но 80 байта нещо ми се струва неподходящ
Иначе огледай си функциите на твоята библиотечка и си организирай викането като спазваш горния алгоритъм (или както се казва RTFM)

10x !

Здравей, извинявай че пак ще питам за MD5, но успях да поразуча библиотеката за въпросното MD5 която инклууднах днес към проектът който билдвам. А мамлко по малко започна да се дига мъглата около тази контролна сума, но все пак има някои неща които ме объркват и затова реших да пиша:

Сега ще се опитам да обясня малко идеята - първо while(1) е различен от този за които дискутирахме Bridge mode-ът. Този тук е просто тестов с който се опитвам да изчисля MD5 на порцията данни която пращам по RS-а. Ако правилно съм разбрал това което казваш, съм се опита в кодът по горе да направя нещо подобно на твоите подточки. md5() функцията изпълнява трите точки в последователност в която ти си описал - инициализация, смятане на блок и пад-ване. ReadRingBuff() ми чете байтове от Ринг буферът и ги слага в ucCmdUARTBuffer, който е с размер BUFF_CMD_SIZE. BUFF_CMD_SIZE има стойност 128. Ако пратя данни които надвишават този размер в ReadRingBuff() има чек, които следи за достигане на този размер и ако това стане нулирам ringBuff.usCmdCount и изчиствам цялото съдържание на ucCmdUARTBuffer. Или казано по друг начин ако пратя 129 байта, 129-тият ще го запиша в ucCmdUARTBuffer[0] след изчистването и нулирането на променливата. Това което наблюдавам в случаят е md5() зависи както от ucCmdUARTBuffer, така и от iLen(дължината на блокът който й се подава). Механизъмът си работи и ако му пратя 10Кбайта данни по УАРТ-ът той ще ги изчете, но ще сметне MD5-то (в MD5output буферът) на последната порция байтове в ucCmdUARTBuffer и ще ги запише в MD5output. Която порция в повечето случай може да бъде по-малка от 128 байта. Има ли начин при изчислението на MD5, в MD5output да се отрази чек сумата на целият блок данни, а не порционно, т.е да се направи нещо като наслагване (незнам дали терминът енай-точен)? Мислил съм вариант в който съдържанието на MD5output да го парсвам на променлива от тип short int, и съдържанието й да го опреснявам посредством += операторът ....

По принцип има всякакви начини. Но с тия безкрайни цикли и безмислени сравнения нещо не ми е ясно какво се опитваш да постигнеш.

Аз се опитах да ти обясня как работят тоя сорт алгоритми. Пак ще кажа, че ако има някакви данни може да сметнеш на една част, на друга част и на всички накуп, но ще получиш 3 различни резултата. Не знам кой резултат ти трябва, но ако искаш да получиш чек сума данни, които получаваш на порции трябва да ги смяташ последователно на точно определен размер (а не такъв, какъв ти дойде).

Това MD5 за интегрити на пакета ли мислиш да го слагаш?
Слез на земята, погледни CRC16 или CRC32 и не се мъчи. Там спокойно можеш да подаваш малки "парчета" от 16 или 32 бита. Отделно защо го слагаш това чудо (чексумата), мрежовите протоколи си имат чексуми. Ако искаш да го прекарваш през друг транспорт може да сложиш нещо, но досега не съм виждал някой да ползва повече от CRC16 на сериен.

Здравей, аз целя точно това - да гетна сумата на "всички накуп данни". Т.е. като пратя 10 Mбайта, да мога да ги гетна всичките и да извадя на тях чек сумата, без да се налага да правя буфер в програмата с размер от 10Мбайта (което очевидна няма да стане понеже RAM паметта не ми е толкова голяма ).

gocho, това MD5 възникна като таргет да мога да си изтествам хард-флоу котролът на УАРТ-ът. Иначе изобщо не влиза като замисъл да го интегрирам в проектът (но чакай да не дърпам Нещото за опашката ), че все пак аз съм изпълнител и непоръчвам музиката в случаят). Чета че има много алгоритми да се провери дали има загуба на данни пр изпращане от едно място на друго, но понеже несъм се занимавал с такъв вид суми досега ми сложиха на масата този вид алгоритъм да го разуча, приложа и да си направя тестът, след което да продължа с Bridge mode-ът за които съм отзи пост.

Значи, брейчо, има протоколи за обмен на файлове. Те използват някакъв вид stream (например TCP или сериен), но слагат отгоре техен протокол, т.е. пакети с хедъри.
Та там вече има концепция за събития за начало на трансфер на нещото, междинни и последен пакет. Т.е. фрагментиране на голямо парче данни към по-малки пакетчета.
Получателя използва тези контролни пакети за да си нагласи state машината и да може да знае кога да инициализира, кога да трупа (смята crc) и кога да проверява.
Каква е твоята идея? Искаш да направиш свой протокол за файл транфер? Или искаш stream обработката да ти го осигури (което няма как да стане без знание за начало и край, което пък е несъвместимо с идеята за stream)?
Макар и позабравени, има доста протоколи за ефективно прехвърляне на файлове по сериен, които вървят добре и по TCP. Например XModem, YModem. Другото е TFTP, или дори FTP, където вече имаш и концепция за достъп до файлова система.

Едит: за теста миро ти го е казал. Не е необходимо да имаш всичките данни накуп, за да сметнеш. Трябва обаче да знаеш началото, за да инициализираш, после да знаеш колко са големи междинните парчета и те да са кратни на минималния размер на дадения алгоритъм, и да знаеш кога са свършили данните. Ако е за тест не виждам проблем да си нагласиш "файла" от 10МБ да е кратен на парчето от 512бита на MD5. Но част от теста ти ще е да синхронизираш двете страни така че да знаят кога започват и свършват 10-те мегабайта.

Ето ти едно SHA1 дето работи:



TSHA1Context sha;
char buff[x];

1. В началото викаш sha1reset(&sha); за начално установяване;
2. Като напълниш буфера викаш sha1input(&sha, buff, sizeof(buff)); - докато има данни;
3. Като свършат данните викаш sha1result(&sha);
4. Изчислената сума е във: sha.Message_Digest[];

Брейчо, не се опитвам да правя нищо ново, нито да измислям топлата вода. Просто се опитвам да направя нещо както ти го казваш "stream"- все едно има едно празно шише и второ пълно, на празнато слагам фуния през която се опитвам да прелея наведнъж течността от второто шише в първото, и в един момент да проверя че нищо не съм разлял. Може би аз немога да го обясня за какво става на въпрос, но именно и заради това не съм станал преподавател . Това което е предложил relsys, имам подобна библиотека, само че функициите са ми :
1.за начално установяване - md5_starts(&MD5);
2.за ъпдейтване на чек сумата - md5_updates(&MD5,ucCmdUARTBuffer,iLen);
3.и за край на данните - md5_finish(&MD5,MD5output); като сумата в краят ми се намира в MD5output

междинните парчета са ми по 127 байта

а за край на данните използвам символ който съм си аз избрал (в случая "#")- като се появи, извикам md5_finish. Този подход съм го измислил понеже мога да контролирам инфото в самият файл, знам че на практика въпросният символ може да бъде част от полезната информация, но го правя само заради тестът. Сутринта се опитах да направя алгоритъм подобен на този който е посочил relsys, но отново имам ралики в сумите от двете страни ....

Това което не съм пробвал е идеята с "+=" за която споменах по-горе...

Я сметни тук:

http://www.md5.cz/

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

Здравей, аз използвам и една програмка НхD, това което пускам от РС-то към контролерът (като файл) го пуснах и на НхD и на линка който си дал - двете чек суми са едно към едно еднакви. Проблемът е в моят скрипт, сигурен съм. Просто трябва да се подредя правилно самия алгоритъм на викане на функциите дето споменах по-горе и просто ми е малко каша на къде да тръгна - пробвах го с въпросният интеръпт на УАРТ-ът(понеже той ще ми е активен и ще присъства като поведение в устройството занапред), сутринта забраних този интеръпт и пробвах алгоритъм подобен на този който ти спомена(понеже снощи намерих такива и в Интернет). И сега мисля да пробвам последно това с "+=", след което нямам резервни идеи как може да стане ...

ucCmdUARTBuffer - буфера нулираш ли го някога?
Щото strlen() иначе няма да връща правилната дължина...

Този буфер го нулирам когато достигна 127 байта. След това нулирам ringBuff.usCmdCount (който всъщност ми представлява индексаторът на самият буфер - все едно като записвам в него правя нещо подобно
ucCmdUARTBuffer[ringBuff.usCmdCount]=ringBuff.rx[ringBuff.rx_tail];
). На отделните порции, чек сумите ги смята правилно все едно ако пратя 130 байта, на първите 127 байта ще ми я сметне правилно, на следващите 3 байта сумата вече ще е различна (ясно защо) но пак ще е правилна . И аз сега се двоумя ако събера чек сумата на първите 127 с тази на оставащите 3 байта, дали няма да получа чек сумата на целите 130 байта. За сега това опитвам да постигна и след това ще пробвам с по-голяма порция данни...