Инициализация CRC - это частности. Полином используется тот же. А инициализация не нулем устраняет неприятный глюк, когда все нулевые байты дают нулевую CRC. Например, если панельку для Touch Memory позамыкать отверткой, то иногда будет считываться ключ с номером 0 и верной CRC. Это не очень хорошо.

Очень заинтересовала эта тема! Но я так и не уловил для какого интерпретатора была написана программа для МК, пробовал скомпилировать в WinAVR, подскажите можно ли это чудо перевести в WinAVR?

Исходники для IAR. Можно доработать напильником и компилить в любой среде.

#include <Main.h>
#include <Commands.h>
Что это за библиотеки и как быть если пользуюсь WinAVR, у меня там таких нет
Можно глупый вопрос?!
Был вот по этой ссылочке http://caxapa.ru/lib/wake/
там есть полные исходники этого протокола WAKE
скачал просмотрел и не нашел int main(void), куда делась главная функция?

Это не библиотеки, а заголовочные файлы моих модулей. Ничего интересного в них нет, только объявление функций, которыми могут пользоваться другие модули.



Main принадлежит основной программе. А это всего лишь модули организации обмена по протоколу Wake. Законченного приложения там, разумеется, нет. Main Вы должны написать сами под ваши задачи.

Программа не хочет компилироваться без этих заголовочных файлов, мне просто удалить эти строки?
#include <Main.h>
#include <Commands.h>

В Commands.h Вы должны поместить прототипы функций, которые содержатся в модуле Commands.c и котрые Вы хотите вызывать из других модулей.

Main.h - это заголовочный файл главного модуля моей программы. У Вас же главный модуль будет другой, поэтому и Main.h нужен другой. Вам виднее, что там должно быть.

Здравствуйте!
Подскажите пожалуйста, как правильно организовать во времени работу такой сети:
устройство 1- пульт управления или PC на время тестирования, работает master/slave
устройство 2- чистый slave, по принятию пакета от 1 отдает ack/nak
устройства 3-5 - одинаковые датчики, а) от 1 индивидуально получают настройки,инициатор -1 б) после срабатывания внутреннего прерывания передают 1му параметры, инициаторы 345 и может быть одновременно
предусмотрено два режима работы 1--2 и 1--3,4,5
все устройства висят на одном проводе и мешают друг другу
непойму как организовать режим 1--345. Есть идея: ждать чистой линии разное время, причем 1 ждет дольше всех
пакеты содержат преамбулу,адрес приемника,предатчика,команду,поле данных, ack/nak,crc8. Размер поля данных, для простоты, одинаков для всех -6 байт.

У меня тут возникло несколько мыслей по поводу этих протоколов. Интересно мнение других.

Первая мысля касается протоколов, которые в начале и в конце кадра используют одинаковый флаг. В описании того же SLIP написано, что начальный флаг служит для того, чтобы сбросить (flush) символы-помехи, которые могли быть получены во время ожидания очередного кадра. Но что значит сбросить? Приемник не может определить мусор это или нет. Он видит флаг, берет все полученные на данный момент данные и отправляет наверх - Все, я получил посылку. Получается вся надежда на CRC? А вдруг там будет много мусора? Насиловать каждый раз эту бедную CRC? Ну как-то не очень хорошо. Почему тогда все протоколы упорно используют один флаг в начале и в конце кадра, вместо двух разных? Это бы сделало распознавание кадров более надежным.

Вторая мысль по поводу вынесения из прерывания всего и вся. Возьмем, например, и вынесем вычисление контрольной суммы в фон, и представим следующую ситуацию. Приемник ожидает входящих данных. При получении стартового флага очередного кадра, приемник соберет весь мусор, что получил за время ожидания, установит флаг готовности и будет ждать, пока фон не проверит данные и не освободит входной буфер, чтобы он мог принять следующий кадр. Стоит фону немного замешкаться и вуаля! Приемник пропускает первый значащий символ того самого кадра. Все, кадр для нас потерян.

Таким макаром приемник может пропустить не один кадр. Если бы у нас были разные флаги начала и конца кадра, то мы сразу смогли бы отбросить откровенный мусор и это бы несколько спасло ситуацию. А вот если мы не вынесли бы вычисление CRC из прерывания, то такой ситуации вообще бы не было. Мы бы отбрасывали весь мусор и поврежденные кадры, пока не примем нормальный. То есть мы бы гарантированно получили один правильный кадр. Так что делать? Я тоже не хочу загружать прерывание, но получается придется.

Можно конечно выделить несколько кадровых буферов и все пихать туда, но сколько их придется взять? Память то тоже не бесконечная. Да и фону от этого не легче - вместо вычисления CRC для одного буфера ему придется проверять N буферов. Кто его знает насколько это замедлит всю систему. Тоже нехорошо. Кто что думает по этому поводу?

Да, и еще. Вычисляем ли мы CRC в прерывании или нет, нам все-равно могут пригодиться несколько кадровых буферов. Как это лучше организовать? Выделить N буферов максимального размера? Но если кадры не всегда будут максимального размера, то память будет использоваться не эффективно. Хорошо бы что-то типа кольцевого буфера, куда можно было бы подряд помещать кадры, но как их тогда отделать друг от друга? В голову лезут какие-то монструозные решения. Кто-нибудь подобное реализовывал?

ДА , так вот просто в помойку всё.
Начало передачи пакета и конец обозначены одим сиволом END. Он уникален т.к. протоколом предусмотрена его подмена, если такой символ встречается в данных. Так вот если Вы грузили в буфер всё , что было до первого END - всё в помойку

Wake использует только флаг начала кадра. В конце кадра никакой специальный символ не передается. Конец кадра определяется по количеству байт в кадре.



Как только приходит символ начала кадра, разбор начинается снова.



При получении стартового флага буфер очищается. Вернее, укзатель ставится в начало буфера.



Зачем?

Но приемник в общем случае не знает, что есть мусор, а что данные. Вот отправили ему такую последовательность: мусор-флаг-кадр-флаг. Он принял мусор, и тут появляется начальный флаг кадра. Приемник не знает, что до этого был мусор и говорит "я принял что-то похожее на кадр, кто-нибудь проверьте точнее" и останавливает прием, ведь буфер занят этим "чем-то". А в это время передается уже нормальный кадр, тот, по чьему начальному сфлагу срубился приемник. И пока фон проверяет принятый мусор иосвобождает буфер, этот самый кадр может потеряться.


Это понятно. Я не именно про WAKE говорил.


В описанной абзацем выше ситуации это помогло бы принять следующий за мусором нормальный кадр. Ну или надо было вычислять контрольную сумму в прерывании, тогда бы приемник не ждал пока фоновый процесс проверит кадр, а сам бы быстренько понял, что это мусор.

Вы поймите , Вы принимаете всё , что передаётся по лини , но у Вашего приёмника нет отметки , что он принимал начальный флаг.
Он уникален. И как только он его принял , все то шло ему раньше флага , сбрасывается. И с этого момента он считает , что идет кадр , по приходу второго флага , он сбрасывает отметку начального флага. Всё кадр принят.

Ну ок, а если приемник включился в середине передачи и получил "полкадра-флаг-мусор-флаг-кадр-флаг"? Если использовать описанную Вами логику, то получается он будет считать каждый кадр мусором, а каждый мусор кадром.

Может это поможет понять