AHTOXA 14 28 июня, 2019 Опубликовано 28 июня, 2019 · Жалоба 40 минут назад, mantech сказал: Всякую муть типа, широковещательное чудо-юдо с 48, 64 битными уникальными кодами, таблицы хэшей и пр... были отвергнуты сразу по причине ненадежности и значительному усложнению кода. Данный протокол предназначался для 8 и 32х битных контроллеров... Потому и "чудо-юдо", что, даже имея уникальные коды в каждом устройстве, на шине RS-485 нельзя сделать нормальное обнаружение подключённых устройств. Потому что нет арбитража. А на CAN шине - можно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 29 июня, 2019 Опубликовано 29 июня, 2019 · Жалоба 23 hours ago, mantech said: Здесь нет смысла впиндюривать КАН. Самое удачное - RS-485. Очень дешево и сердито, уарт есть в каждом МК сегодня... UART - это правильно. Но непонятно зачем к нему приделывать такое допотопное угробище, как RS485 трансивер. Никто не мешает использовать совместно с UART трансивер CAN. Со всеми полагающимися при этом плюшками: отсутствием мастера, парадигмой "производитель-потребитель", избеганием столкновений (CSMA-CA) или в крайнем случае обнаружением столкновений (CSMA-CD), и т.п. А вот контроллер CAN и протокол CAN, действительно, обычно и нафиг не нужны. Я думаю, что их используют в основном в силу косности мышления, "чтобы не думать". Равно как RS485 трансивер с UART используют ровно по той же причине. Пример интерфейса на связке UART + трансивер CAN, без протокола CAN и без контроллеров CAN, можно посмотреть здесь. Все делается на самой дешевой Ардуинке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 29 июня, 2019 Опубликовано 29 июня, 2019 · Жалоба 17 минут назад, =AK= сказал: UART - это правильно. Но непонятно зачем к нему приделывать такое допотопное угробище, как RS485 трансивер. Никто не мешает использовать совместно с UART трансивер CAN. Со всеми полагающимися при этом плюшками: отсутствием мастера, парадигмой "производитель-потребитель", избеганием столкновений (CSMA-CA) Тоже вариант, хотя я привык к архитектуре мастер-слейв, она мне просто больше нравится своей предсказуемостью... 19 минут назад, =AK= сказал: А вот контроллер CAN и протокол CAN обычно и нафиг не нужны. Чаще всего их используют в силу косности мышления, "чтобы не думать". Вот тут сомневаюсь - посмотрел на доки по собственно контроллеру - так мне с уартом куда проще, чем разгребать все эти мейлбоксы, фильтры и пр... Причем на разных МК все это по-разному конфигурируется. ЗЫ. не имею ввиду "кубокодеров", у которых вроде, как все просто, но потом кучи вопросов тут на форуме, что что-то все не работает никак... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 29 июня, 2019 Опубликовано 29 июня, 2019 · Жалоба Just now, mantech said: Тоже вариант, хотя я привык к архитектуре мастер-слейв, она мне просто больше нравится своей предсказуемостью... Никто не запрещает использовать "мастер-слэйв" связке (UART + трансивер CAN). В приведенном выше примере шина работает в двух режимах; "мастер-слэйв" при конфигурировании узлов и "производитель-потребитель" в рабочем режиме. Одно другому не мешает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 29 июня, 2019 Опубликовано 29 июня, 2019 · Жалоба 3 минуты назад, =AK= сказал: Никто не запрещает использовать "мастер-слэйв" связке (UART + трансивер CAN). Как я и сказал - вполне годный вариант, про 485 говорил про сугубо мое мнение - ибо система уже более 5 лет назад разработана, полностью реализует весь необходимый функционал - так зачем что-то менять. В смысле новых разработок, с необходимостью работы напрямую устройство - устройство - вполне годный вариант. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
baritono 0 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба Т.е. на RS-485 можно сделать физически шинную топологию: один кабель на все устройства? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 4 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба 14 минут назад, baritono сказал: Т.е. на RS-485 можно сделать физически шинную топологию: один кабель на все устройства? Так RS-485 именно для этого и придуман. Чаще всего используют двухпроводную симметричную линию (витую пару), но есть вариант (и соответствующие ему микросхемы драйверов) с двумя парами, отдельно для приёма и передачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба В 28.06.2019 в 17:56, mantech сказал: Как ни странно - да! ... Не вижу ничего плохого в опросе. Спасибо, уже наелись. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба On 2/1/2019 at 9:35 PM, baritono said: Нравится идея контроллера со встроенным трансивером, например NXP LPC11C24, но цена кусается ($20). Ну что, тогда я прописал бы вам Renesas - https://www.digikey.com/product-detail/en/R7FS128783A01CFJ%23AA1/R7FS128783A01CFJ%23AA1-ND/7670041?utm_campaign=buynow&WT.z_cid=ref_octopart_dkc_buynow&utm_medium=aggregator&curr=usd&site=us&utm_source=octopart Там вы дополнительно получите EEPROM и USB. Благодаря этому сможете очень удобно конфигурировать свои устройства. Сможете делать сенсорные кнопки и подключаться к умным системам освещения через DALI. А главное не придется ковыряться во всяческих сторонних проектах ради CAN-а или USB , все готовые стеки , фреймворки и API найдете в Synergy Software Package Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
one_eight_seven 3 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба On 6/29/2019 at 10:54 AM, =AK= said: UART - это правильно. Но непонятно зачем к нему приделывать такое допотопное угробище, как RS485 трансивер. Никто не мешает использовать совместно с UART трансивер CAN. На выходе получается очередное ущербное угробище. Приходилось несколько раз работать с таким. Перед началом работ с подобными приборами производитель говорит: "У нас CAN, всё работает". Начинаешь работать, и никакого CAN и в помине нет. А сроки уже обозначены, деньги получены. Приходится заниматься не работой, каким-то непотребством. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 34 30 июня, 2019 Опубликовано 30 июня, 2019 (изменено) · Жалоба 20 минут назад, one_eight_seven сказал: Перед началом работ с подобными приборами производитель говорит: "У нас CAN, всё работает". ИМХО С такими производителями, которые белое выдают за черное лучше вообще не работать. А про уарт с кан трансивером разработчики честно написали, что это "HBus". Хотя сам все-таки стараюсь делать если уж RS-485 так и вся обвеска соответствующая что и пишем везде... Изменено 30 июня, 2019 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба 2 hours ago, one_eight_seven said: На выходе получается очередное ущербное угробище. Приходилось несколько раз работать с таким. Перед началом работ с подобными приборами производитель говорит: "У нас CAN, всё работает". Начинаешь работать, и никакого CAN и в помине нет. А сроки уже обозначены, деньги получены. Приходится заниматься не работой, каким-то непотребством. Угробище получается не из-за использованных составных частей, а из-за дырок в головах разработчиков. На такое и на "генетически чистом CAN" можно напороться. "Хождение по камушкам" (т.е. привязка к накатанным шаблонам) никак не гарантирует наличие мозгов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 30 июня, 2019 Опубликовано 30 июня, 2019 · Жалоба В 29.06.2019 в 12:54, =AK= сказал: Пример интерфейса на связке UART + трансивер CAN, без протокола CAN и без контроллеров CAN, можно посмотреть здесь. Все делается на самой дешевой Ардуинке. Подскажите, для чего в протоколе введён такой вариант: 0x1B-0x09 - insert 0x1B, 0x1B into data flow ? Для экономии трафика? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 10 1 июля, 2019 Опубликовано 1 июля, 2019 · Жалоба 16 hours ago, AHTOXA said: Подскажите, для чего в протоколе введён такой вариант: 0x1B-0x09 - insert 0x1B, 0x1B into data flow ? Для экономии трафика? Чтобы много памяти под буфера не отводить. Ну и трафик тоже. Хоть и далается вставка/удаление байтстаффинга "на лету", все же иногда приходится держать в буфере пакет с байтстаффингом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 1 июля, 2019 Опубликовано 1 июля, 2019 · Жалоба 18 часов назад, AHTOXA сказал: Подскажите, для чего в протоколе введён такой вариант: 0x1B-0x09 - insert 0x1B, 0x1B into data flow ? Для экономии трафика? Думаю: для уменьшения оверхеда кодирования в тех случаях, когда данные состоят из множества подряд идущих 0x1B. Чтобы увеличение было не 2-кратным, а "только" 1.5-кратным. Если не хочется большого оверхеда, то лучше использовать протокол COBS. Очень приятный протокол С оверхедом всего-лишь порядка на +0.5%. Не зависимо от значений данных. 1 час назад, =AK= сказал: все же иногда приходится держать в буфере пакет с байтстаффингом. Зачем? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
