Пакетный протокол обмена данными между МК и ПК

Леонид Иванович

OKF писал(а):А отчего CRC_INIT = 0xde? У Далласа, как я понимаю, 0.

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

Реклама

alexey6522

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

Реклама

Леонид Иванович

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

alexey6522

#include <Main.h>
#include <Commands.h>
Что это за библиотеки и как быть если пользуюсь WinAVR, у меня там таких нет

Можно глупый вопрос?!
Был вот по этой ссылочке http://caxapa.ru/lib/wake/
там есть полные исходники этого протокола WAKE
скачал просмотрел и не нашел int main(void), куда делась главная функция?

Реклама

Леонид Иванович

alexey6522 писал(а):#include <Main.h>
#include <Commands.h>
Что это за библиотеки и как быть если пользуюсь WinAVR, у меня там таких нет

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

alexey6522 писал(а):Можно глупый вопрос?!
Был вот по этой ссылочке http://caxapa.ru/lib/wake/
там есть полные исходники этого протокола WAKE
скачал просмотрел и не нашел int main(void), куда делась главная функция?

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

Реклама

alexey6522

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

Реклама

Леонид Иванович

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

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

Sergi

Здравствуйте!
Подскажите пожалуйста, как правильно организовать во времени работу такой сети:
устройство 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 байт.

menzoda

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

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

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

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

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

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

ILYAUL

Но что значит сбросить?

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

Леонид Иванович

menzoda писал(а):в начале и в конце кадра используют одинаковый флаг

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

menzoda писал(а):Но что значит сбросить?

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

menzoda писал(а):При получении стартового флага очередного кадра, приемник соберет весь мусор, что получил за время ожидания

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

menzoda писал(а):Можно конечно выделить несколько кадровых буферов

Зачем?

menzoda

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

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

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

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

Леонид Иванович писал(а):
menzoda писал(а):Можно конечно выделить несколько кадровых буферов
Зачем?

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

ILYAUL

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

menzoda

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

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

ILYAUL

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