syoma 1 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба Привет всем. Такой вопрос - в одном очень legacy проекте надо замутить периодический прием/передачу нескольких переменных по UART между двумя устройствами на 8052. Переменных порядка 10шт байтовых. Сейчас устройства обмениваются данными, но только одним байтом с проверкой четности. Хочется сделать это самым экономичным способом, так как в ПЗУ осталось всего 500-700 байт памяти. Можно было бы попытаться сделать какое-то мультиплексирование, но не хочется изобретать велосипед, если он уже изобретен, поэтому хочется следовать какому-нибудь стандарту. Я вот подумал о том, чтобы тупо слать фрейм в формате Modbus ASCII с функцией 0x10 (Write Multiple Registers). Думаю, что это проще, чем RTU, так как LRC посчитать проще, чем CRC-16. Какие-нибудь еще простые варианты есть? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MegaVolt 25 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба Ну сложить переменные друг за другом в памяти и передать этот кусок памяти побайтно использую имеющуюся функцию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 6 minutes ago, MegaVolt said: Ну сложить переменные друг за другом в памяти и передать этот кусок памяти побайтно использую имеющуюся функцию. Так сейчас в имеющейся функции приема никакого контроля первого/последнего принимаемого байта нет. Как прием будет угадывать, где первый байт? Использовать бит четности или спец-символ? Кстати, с оперативкой тоже есть напряг. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 11 минут назад, syoma сказал: Так сейчас в имеющейся функции приема никакого контроля первого/последнего принимаемого байта нет. Как прием будет угадывать, где первый байт? Использовать бит четности или спец-символ? Можно byte stuffing применить. Можно применить четность как маркер начала пакета (встречал такое решение на практике). Если четность уже занята, можно сделать 9-и битовую посылку (8052 вроде это поддерживал). А вообще мало от вас данных. Эти два байта туда-сюда они какие? Фиксированные, разные, в диапазоне... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MegaVolt 25 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 11 минут назад, syoma сказал: Так сейчас в имеющейся функции приема никакого контроля первого/последнего принимаемого байта нет. Как прием будет угадывать, где первый байт? Использовать бит четности или спец-символ? Да некий флаг показывающий начало передачи. Например ещё одну переменную с фиксированным значением. Цитата Кстати, с оперативкой тоже есть напряг. Если переменные существуют значит они уже лежат в памяти. Я предлагаю лишь расположить их в этой памяти рядом. Никаких доп затрат не нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба У меня сейчас уже и используется 9-битовая посылка. По поводу четности, как маркера начала пакета я думал - это стандартная практика? Переменные все фиксированные - пока лежат по разным адресам, но да, могу сдвинуть вместе. Также пара переменных лежит в битовом пространстве - их нужно будет упаковать в один байт для пересылки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 33 minutes ago, syoma said: . . . Я вот подумал о том, чтобы тупо слать фрейм в формате Modbus ASCII с функцией 0x10 (Write Multiple Registers). Думаю, что это проще, чем RTU, так как LRC посчитать проще, чем CRC-16. Если в Вас фреймы, а не байтовый "поток" с интервалами то они (фреймы) могут выделяться паузами. CRC-любая, формат фрейма - любой. те. надо организовать "детектор молчания"/паузы. Это флаг "готовность приема следующего пакета" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба Переменные в каких диапазонах находятся? 1. Если там произвольные бинарные данные, то "магический символ начала фрейма" не подойдет. 2. Если же там не произвольные данные, то можно выделить 1 символ (который не будет использоваться в значениях всех переменных) в качестве маркера начала кадра. Если данные должны сопровождаться некой CRC, то автоматом попадаем в пункт 1. Данные передаются пакетами? Если да, то каков межпакетный интервал? Он есть? Вам и прием, и передачу замутить надо? Если переменные представляют бинарные данные и спецсимволов выделить не получается, то посмотрите в сторону байт-стаффинга, например, он простой. Если данные передаются пакетами (все переменные сразу за одну отправку), и всегда между пакетами существует минимальный гарантированный межкадровый интервал (например, в 1 байт), то можно выуживать кадры из потока с помощью таймера (ну или, если периферия МК позволяет, с помощью обнаружение IDLE шины). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 2 minutes ago, Arlleex said: Переменные в каких диапазонах находятся? Да, данные произвольные, но теоретически все меньше 128, то есть я могу найти символ начала фрейма, например 0xFF. Ну или битом четности пожертвовать. 5 minutes ago, Arlleex said: Данные передаются пакетами? Если да, то каков межпакетный интервал? Он есть? Вам и прием, и передачу замутить надо? Сейчас с одним байтом межпакетного интервала нет вообще - новые данные пихаются в SBUF прямо в прерывании TI от последовательного порта. Мне нужно переделывать и прием и передачу и если мутить межкадровый интервал, то надо будет что-то придумывать - насколько я смотрю у меня свободных таймеров нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 9 минут назад, syoma сказал: Да, данные произвольные, но теоретически все меньше 128, то есть я могу найти символ начала фрейма, например 0xFF. Ну или битом четности пожертвовать. Как правило, это слово уже предопределяет судьбу любого не кодонезависимого протокола не в лучшую сторону Посмотрите в сторону байт-стаффинга. Правда, и у него есть особенности: если они Вам не критичны - то решение огонь. Особенности там таковы, что при некотором наборе данных на отправку, реально отправится в 2 раза больше кодированных символов. Но это максимум. Т.е. не всегда, а при определенном наборе байт. Если интересно - почитайте за него, он прост как два пальца. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 3 minutes ago, syoma said: Сейчас с одним байтом межпакетного интервала нет вообще . . . На сайте обсуждалость, с подачи jcxz (насколько помню) байтовый протокол, COBS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 3 минуты назад, k155la3 сказал: На сайте обсуждалость, с подачи jcxz (насколько помню) байтовый протокол, COBS. Для COBS памяти (ОЗУ, по крайней мере) требуется больше и в реализации он чуть сложнее обычного стаффинга. А у ТС с памятью напряг (с ПЗУ, а учитывая это, предполагаю, с ОЗУ еще хуже дела). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nice_vladi 1 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба 14 minutes ago, Arlleex said: Для COBS памяти (ОЗУ, по крайней мере) требуется больше и в реализации он чуть сложнее обычного стаффинга. А у ТС с памятью напряг (с ПЗУ, а учитывая это, предполагаю, с ОЗУ еще хуже дела). COBS требует буфера размера не менее 256 байт. Но, в случае ТС, можно COBS подрезать и сделать его на 10 байт. Соответственно, буфер понадобится тоже на 10 байт. Избыточность - не более 1 байта. ИМХО, проще взять готовую реализацию, там будет буфер на 256 байт. Зато никакого ограничения на размер пересылаемых данных. ЗЫ. В интернетах куча примеров и реализаций - от pure C до python и delphi. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба Может быть не в тему, но WAKE? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 187 16 мая, 2020 Опубликовано 16 мая, 2020 · Жалоба Ну если "экономичным способом" и не критичен возникающий оверхед по передаваемым данным, то проще сделать SLIP-кодирование. Или типа него. Очень простое - кодировать/декодировать можно на лету, без буфера. COBS конечно красивее, но реализация будет более громоздкой + буфер. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
