AHTOXA 0 Posted June 28, 2019 · Report post 40 минут назад, mantech сказал: Всякую муть типа, широковещательное чудо-юдо с 48, 64 битными уникальными кодами, таблицы хэшей и пр... были отвергнуты сразу по причине ненадежности и значительному усложнению кода. Данный протокол предназначался для 8 и 32х битных контроллеров... Потому и "чудо-юдо", что, даже имея уникальные коды в каждом устройстве, на шине RS-485 нельзя сделать нормальное обнаружение подключённых устройств. Потому что нет арбитража. А на CAN шине - можно. Quote Ответить с цитированием Share this post Link to post Share on other sites
=AK= 0 Posted June 29, 2019 · Report post 23 hours ago, mantech said: Здесь нет смысла впиндюривать КАН. Самое удачное - RS-485. Очень дешево и сердито, уарт есть в каждом МК сегодня... UART - это правильно. Но непонятно зачем к нему приделывать такое допотопное угробище, как RS485 трансивер. Никто не мешает использовать совместно с UART трансивер CAN. Со всеми полагающимися при этом плюшками: отсутствием мастера, парадигмой "производитель-потребитель", избеганием столкновений (CSMA-CA) или в крайнем случае обнаружением столкновений (CSMA-CD), и т.п. А вот контроллер CAN и протокол CAN, действительно, обычно и нафиг не нужны. Я думаю, что их используют в основном в силу косности мышления, "чтобы не думать". Равно как RS485 трансивер с UART используют ровно по той же причине. Пример интерфейса на связке UART + трансивер CAN, без протокола CAN и без контроллеров CAN, можно посмотреть здесь. Все делается на самой дешевой Ардуинке. Quote Ответить с цитированием Share this post Link to post Share on other sites
mantech 0 Posted June 29, 2019 · Report post 17 минут назад, =AK= сказал: UART - это правильно. Но непонятно зачем к нему приделывать такое допотопное угробище, как RS485 трансивер. Никто не мешает использовать совместно с UART трансивер CAN. Со всеми полагающимися при этом плюшками: отсутствием мастера, парадигмой "производитель-потребитель", избеганием столкновений (CSMA-CA) Тоже вариант, хотя я привык к архитектуре мастер-слейв, она мне просто больше нравится своей предсказуемостью... 19 минут назад, =AK= сказал: А вот контроллер CAN и протокол CAN обычно и нафиг не нужны. Чаще всего их используют в силу косности мышления, "чтобы не думать". Вот тут сомневаюсь - посмотрел на доки по собственно контроллеру - так мне с уартом куда проще, чем разгребать все эти мейлбоксы, фильтры и пр... Причем на разных МК все это по-разному конфигурируется. ЗЫ. не имею ввиду "кубокодеров", у которых вроде, как все просто, но потом кучи вопросов тут на форуме, что что-то все не работает никак... Quote Ответить с цитированием Share this post Link to post Share on other sites
=AK= 0 Posted June 29, 2019 · Report post Just now, mantech said: Тоже вариант, хотя я привык к архитектуре мастер-слейв, она мне просто больше нравится своей предсказуемостью... Никто не запрещает использовать "мастер-слэйв" связке (UART + трансивер CAN). В приведенном выше примере шина работает в двух режимах; "мастер-слэйв" при конфигурировании узлов и "производитель-потребитель" в рабочем режиме. Одно другому не мешает. Quote Ответить с цитированием Share this post Link to post Share on other sites
mantech 0 Posted June 29, 2019 · Report post 3 минуты назад, =AK= сказал: Никто не запрещает использовать "мастер-слэйв" связке (UART + трансивер CAN). Как я и сказал - вполне годный вариант, про 485 говорил про сугубо мое мнение - ибо система уже более 5 лет назад разработана, полностью реализует весь необходимый функционал - так зачем что-то менять. В смысле новых разработок, с необходимостью работы напрямую устройство - устройство - вполне годный вариант. Quote Ответить с цитированием Share this post Link to post Share on other sites
baritono 0 Posted June 30, 2019 · Report post Т.е. на RS-485 можно сделать физически шинную топологию: один кабель на все устройства? Quote Ответить с цитированием Share this post Link to post Share on other sites
SSerge 0 Posted June 30, 2019 · Report post 14 минут назад, baritono сказал: Т.е. на RS-485 можно сделать физически шинную топологию: один кабель на все устройства? Так RS-485 именно для этого и придуман. Чаще всего используют двухпроводную симметричную линию (витую пару), но есть вариант (и соответствующие ему микросхемы драйверов) с двумя парами, отдельно для приёма и передачи. Quote Ответить с цитированием Share this post Link to post Share on other sites
Сергей Борщ 0 Posted June 30, 2019 · Report post В 28.06.2019 в 17:56, mantech сказал: Как ни странно - да! ... Не вижу ничего плохого в опросе. Спасибо, уже наелись. Quote Ответить с цитированием Share this post Link to post Share on other sites
AlexandrY 0 Posted June 30, 2019 · Report post 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 Quote Ответить с цитированием Share this post Link to post Share on other sites
one_eight_seven 0 Posted June 30, 2019 · Report post On 6/29/2019 at 10:54 AM, =AK= said: UART - это правильно. Но непонятно зачем к нему приделывать такое допотопное угробище, как RS485 трансивер. Никто не мешает использовать совместно с UART трансивер CAN. На выходе получается очередное ущербное угробище. Приходилось несколько раз работать с таким. Перед началом работ с подобными приборами производитель говорит: "У нас CAN, всё работает". Начинаешь работать, и никакого CAN и в помине нет. А сроки уже обозначены, деньги получены. Приходится заниматься не работой, каким-то непотребством. Quote Ответить с цитированием Share this post Link to post Share on other sites
mantech 0 Posted June 30, 2019 (edited) · Report post 20 минут назад, one_eight_seven сказал: Перед началом работ с подобными приборами производитель говорит: "У нас CAN, всё работает". ИМХО С такими производителями, которые белое выдают за черное лучше вообще не работать. А про уарт с кан трансивером разработчики честно написали, что это "HBus". Хотя сам все-таки стараюсь делать если уж RS-485 так и вся обвеска соответствующая что и пишем везде... Edited June 30, 2019 by mantech Quote Ответить с цитированием Share this post Link to post Share on other sites
=AK= 0 Posted June 30, 2019 · Report post 2 hours ago, one_eight_seven said: На выходе получается очередное ущербное угробище. Приходилось несколько раз работать с таким. Перед началом работ с подобными приборами производитель говорит: "У нас CAN, всё работает". Начинаешь работать, и никакого CAN и в помине нет. А сроки уже обозначены, деньги получены. Приходится заниматься не работой, каким-то непотребством. Угробище получается не из-за использованных составных частей, а из-за дырок в головах разработчиков. На такое и на "генетически чистом CAN" можно напороться. "Хождение по камушкам" (т.е. привязка к накатанным шаблонам) никак не гарантирует наличие мозгов. Quote Ответить с цитированием Share this post Link to post Share on other sites
AHTOXA 0 Posted June 30, 2019 · Report post В 29.06.2019 в 12:54, =AK= сказал: Пример интерфейса на связке UART + трансивер CAN, без протокола CAN и без контроллеров CAN, можно посмотреть здесь. Все делается на самой дешевой Ардуинке. Подскажите, для чего в протоколе введён такой вариант: 0x1B-0x09 - insert 0x1B, 0x1B into data flow ? Для экономии трафика? Quote Ответить с цитированием Share this post Link to post Share on other sites
=AK= 0 Posted July 1, 2019 · Report post 16 hours ago, AHTOXA said: Подскажите, для чего в протоколе введён такой вариант: 0x1B-0x09 - insert 0x1B, 0x1B into data flow ? Для экономии трафика? Чтобы много памяти под буфера не отводить. Ну и трафик тоже. Хоть и далается вставка/удаление байтстаффинга "на лету", все же иногда приходится держать в буфере пакет с байтстаффингом. Quote Ответить с цитированием Share this post Link to post Share on other sites
jcxz 0 Posted July 1, 2019 · Report post 18 часов назад, AHTOXA сказал: Подскажите, для чего в протоколе введён такой вариант: 0x1B-0x09 - insert 0x1B, 0x1B into data flow ? Для экономии трафика? Думаю: для уменьшения оверхеда кодирования в тех случаях, когда данные состоят из множества подряд идущих 0x1B. Чтобы увеличение было не 2-кратным, а "только" 1.5-кратным. Если не хочется большого оверхеда, то лучше использовать протокол COBS. Очень приятный протокол С оверхедом всего-лишь порядка на +0.5%. Не зависимо от значений данных. 1 час назад, =AK= сказал: все же иногда приходится держать в буфере пакет с байтстаффингом. Зачем? Quote Ответить с цитированием Share this post Link to post Share on other sites
