Argon (19.12.2021 20:09, просмотров: 7271)-
- Черкну тут для истории: осилить CAN Kingdom не сумел, вернее бросил
это занятие. Несмотря на то, что сама идея неплохая, ее описание
плохо ложится на мозги. Началось это при попытке освоить эфемерные
сущности: "каталоги", "формы", "списки форм", "списки документов".
И уж совсем добила тема сжатых сообщений. Argon(1107 знак., 23.12.2021 21:43)
- а зачем приказывать всем заткнуться ??? у меня апдейты при родном
траффике авто замечательно проходят, при отладке гонял файлы
размером 4мб. - Aleksey_75(23.12.2021 21:50)
- чтоб знали хозяина ) - Argon(23.12.2021 21:57)
- а зачем приказывать всем заткнуться ??? у меня апдейты при родном
траффике авто замечательно проходят, при отладке гонял файлы
размером 4мб. - Aleksey_75(23.12.2021 21:50)
- А что за функционал протокола нужен? Я делал простую передачу
поверх CAN и все было очень просто. И адаптер COM/CAN был. - VLLV(20.12.2021 08:17)
- синхронизация времени узлов, обнаружение отвала узлов,
присоединение новых и главное - возможность передавать объемные
пакеты данных (прошивки, например). Argon(386 знак., 20.12.2021 09:02)
- Я банально перевел в CAN свой последовательный протокол, ну а там
команды, для загрузчика передавалась строка HEX-файла с оберткой
команды, естественно. Потому что все равно нужен доступ с
компьютера для тестирования, логгирования, и обновления ПО. Есть же
опыт с последовательными протоколами? CAN всего лишь дробит пакеты
на мелкие части. - VLLV(20.12.2021 11:53)
- А как же адресация? Или у вас только 2 узла связаны по CAN? - Argon(20.12.2021 12:05)
- Четыре узла. Адресацию можно сделать как угодно - по идентификаторам, можно в верхний уровень положить. Может, при большом трафике и есть разница, но у меня небольшой трафик. Могу отдать все исходники, IAR AVR, правда там X-макросы в протоколе, будет тяжело, если опыта нет. - VLLV(20.12.2021 12:21)
- есть подозрение что вы голову себе морочите! Все что вы хотите
реализуется без какого либо протокола. Раздайте узлам уникальные id
после второй сотни. Каждый узел через N времени отправляет пакет о
своем состоянии. Синхронизация времени по пакетам с 0x000 id. - Aleksey_75(20.12.2021 12:10)
- Реализуется, только потом называется "самописным протоколом".
Особенно если предусмотреть какой-то больший функционал, чем
принял-послал. - Argon(20.12.2021 12:19)
- Слона нужно есть по частям. - VLLV(20.12.2021 12:22)
- хотелось бы предусмотреть большой холодильник, чтобы была возможность доесть попозже, но до конца ) - Argon(20.12.2021 12:26)
- Слона нужно есть по частям. - VLLV(20.12.2021 12:22)
- Реализуется, только потом называется "самописным протоколом".
Особенно если предусмотреть какой-то больший функционал, чем
принял-послал. - Argon(20.12.2021 12:19)
- А как же адресация? Или у вас только 2 узла связаны по CAN? - Argon(20.12.2021 12:05)
- Я банально перевел в CAN свой последовательный протокол, ну а там
команды, для загрузчика передавалась строка HEX-файла с оберткой
команды, естественно. Потому что все равно нужен доступ с
компьютера для тестирования, логгирования, и обновления ПО. Есть же
опыт с последовательными протоколами? CAN всего лишь дробит пакеты
на мелкие части. - VLLV(20.12.2021 11:53)
- синхронизация времени узлов, обнаружение отвала узлов,
присоединение новых и главное - возможность передавать объемные
пакеты данных (прошивки, например). Argon(386 знак., 20.12.2021 09:02)
- Протокол хороший, но сам стиль документации "В одном сказочном королевстве жили-были..." сбивает с толку. Авторы наверное пытались подать техническую документацию "доступно и понятно". Доподавались, блин, черт ногу сломит... - il-2(20.12.2021 05:13)
- Вообще накурено здорово. Evgeny_CD(1 знак., 20.12.2021 02:21, ссылка)
- Вот тут классное сравнение, но сдается мне, что вкурить все это будет сильно непросто. Evgeny_CD(1 знак., 20.12.2021 01:30, ссылка)
- Чисто ИМХО, если Вам не требуется совместимости с Kingdom (и
прочими), то самопал, в части душевных и временных затрат, будет
дешевле. - Chum_A(19.12.2021 20:21)
- Строго говоря, "совместимость с Kingdom" - вроде бы нонсенс, т.к.
это для замкнутых, нерасширяемых систем (если я верно понял).
Интересует этот протокол поскольку ему поют дифирамбы якобы самое
то для систем близких к реалтайму. Как будто все дела с
перезапросами посылок там уже обдуманы. Argon(106 знак., 19.12.2021 21:15)
- ну слава микрочипу... нашол хоть какую-то реализацию Argon(1 знак., 20.12.2021 19:50, ссылка)
- Постер от автомобилистов, чисто для примера. У них вполне себе real-time требуется Chum_A(1 знак., 20.12.2021 08:56, картинка)
- Да хотелось бы поучиться у умных людей как писать протоколы поверх
нижнего уровня. DeviceNet и CanOpen показались уж очень громоздкими
для моих дел. Argon(285 знак., 19.12.2021 20:27 - 20:30)
- Берите за основу какой либо из существующих протоколов и реализуйте ограниченное подмножество. В первую очередь тот на который есть библиотеки, документация и анализатор протокола (не логгер кан шины а именно анализатор протокола верхнего уровня). В CanOpen слив многокилобайтных бинарных объектов реализован, причем с возможностью перезапроса сбойных кусков. - 3m(20.12.2021 11:48)
- Подозреваю, что у вас с ними нестыковка на уровне
целеполаганияпостановки задачи. А значит ничего путнего вы почерпнуть просто не сможите. - Cкpипaч(19.12.2021 20:32)
- Строго говоря, "совместимость с Kingdom" - вроде бы нонсенс, т.к.
это для замкнутых, нерасширяемых систем (если я верно понял).
Интересует этот протокол поскольку ему поют дифирамбы якобы самое
то для систем близких к реалтайму. Как будто все дела с
перезапросами посылок там уже обдуманы. Argon(106 знак., 19.12.2021 21:15)
- Черкну тут для истории: осилить CAN Kingdom не сумел, вернее бросил
это занятие. Несмотря на то, что сама идея неплохая, ее описание
плохо ложится на мозги. Началось это при попытке освоить эфемерные
сущности: "каталоги", "формы", "списки форм", "списки документов".
И уж совсем добила тема сжатых сообщений. Argon(1107 знак., 23.12.2021 21:43)
