adnega

Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте. В RS485-физике переходы 0<->1 всегда выполняются активным способом, т.е. быстрее. 8 байт в поле данных максимум. Можно чуть чуть информации передать в поле идентификатора. Есть FD-версия CAN (где до 64 байт); не использовал, т.к. редко где он есть. Мультимастер и система приоритетов - это в некоторых случаях спасение. Например, у меня шина умного дома вся на CAN. Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). Я же отношусь к обмену по CAN как "поставил задачу" - "получил результат", где между ними могут быть поставлены другие задачи и получены другие результаты, и ПО должно быть к этому готово, а не ждать результата в течение некоторого таймаута. Если вы настаиваете на CAN, то советую вам продумать адресацию узлов и приоритеты сообщений. Они же у вас короткие будут (до 8 байт включительно)? Насчет дробления, я бы рекомендовал разбить на такие группы, чтобы они питались от одного БП. Напряжение узлов лучше поднять по максимуму, чтобы снизить потребляемый ток, и т.о. снизить негативное влияние тонких проводов.

"Крылья, ноги... главное хвост". Проблемы длинных линий обычно связаны с необходимостью согласования такой линии. Если теряются байты, то это не только из-за кривого драйвера, но и из-за отсутствия согласования линии. CAN в этом плане менее терпим ;) Это довольно неплохая конструкция: мастер на 60 слейвов, затем мастера в своей шине с одним супер-мастером. Мастера делают всю грязную работу по опросу узлов. Отвалившиеся узлы должны опрашиваться реже. Например, после каждого 10 опроса мы опрашиваем один раз один из "отвалившихся" узлов. Супер-мастер выдает высокоуровневые задания мастерам и получает от них высокоуровневые ответы подчиненных узлов. Уровни тут условные, главное различие - в адресации узлов на разных уровнях. В "приготовлении" RS485 есть много тонкостей, если их знать и учитывать, то никаких проблем, кроме скорости опроса не будет. Например, очень вредит неопределенное состояние линии, когда не работает ни один передатчик - решается либо растяжкой линии, либо задержкой передачи после активации передатчика, либо вставкой спецсимволов в начало кадра. CAN хорош, но у него все сложнее - точку сэмплирования бита не так выставил и через опторазвязку может на больших скоростях и/или растояниях не заработать. В AVR, например, положение точки семплирования не так гибко задается как в STM32.

У меня супруга делала дисер в Либре - все там есть. Могу показать как это делается.

С Новым Годом! Всем успехов!

Вроде, в приборе ЭТС-223 последней версии есть эмуляция DS18b20.

void Reset_Handler(void) { unsigned long *pulSrc, *pulDest; enable_fpu(); // Инициализация стека for(pulDest = &_susrstack; pulDest < &_estack;) *(pulDest++) = 0xCCCCCCCC; // Инициализация данных в секции .data pulSrc = &_sidata; for(pulDest = &_sdata; pulDest < &_edata;) *(pulDest++) = *(pulSrc++); // Обнуление данных в секции .bss for(pulDest = &_sbss; pulDest < &_ebss;) *(pulDest++) = 0; // Вызов функции main main(); } У меня такой стартап. При выходе из main() вернемся в Reset_Handler. Попытка выйти из Reset_Handler приведет к краху стека. Можно или так сделать: void Reset_Handler(void) { . . . // Вызов функции main main(); while(1); } или так: void Reset_Handler(void) { . . . // Вызов функции main while(1) main(); } void Reset_Handler(void) { . . . // Вызов функции main main(); while(1) NVIC_SystemReset(); } Но выход из main() в МК не имеет смысла.

А, может, половину ленты код нарастающий, а другую половину спадающий? Можно сэкономить 1 бит (или увеличить длину ленты в два раза).

У вас там флюс CF-10 фигурирует. Он, вроде, "RA". Что обычно им паяете? Вы его смываете после пайки? Чем?

Видео на тему.

Согласен на все 100. При старте управление должен получать загрузчик, считать контрольные суммы, обновлять, шифровать, предоставлять экспортируемые функции - тоже его задача. В конце он должен передать управление приложению. Размер приложения лучше сделать фиксированным, а в самом конце держать CRC32.

ID - это Никакой путаницы быть не может. Видимо, вам под ID хочется понимать "какой-нить адрес" или "какой-нить серийник". Дык, и называйте это адресами или серийниками. Я, например, поле ID использую для приоритетов сообщений и адресации источника. Фильтрация софтовая, аппаратные фильтры не использую. У узла есть серийник. Зная серийник, можно задать/поменять адрес узла (т.е. часть поля ID).

Это называется BIT ERROR Т.е. все что пишем необходимо читать и сравнивать. Несовпадения допускаются только в полях арбитража и подтверждения. Если арбитраж выигран, данные отправляются (но, видимо, несколькими узлами), то в какой-то момент произойдет ошибка бита. Передатчик это обнаруживший должен отправить рецессивную ошибку, которая второму передатчику никак не помешает. Видимо, счетчик ошибок передачи должен подрасти. Видимо, какое-то событие контроллер can в МК тоже может получить. Например, у stm32 такие ошибки: Я всегда считал, что несколько узлов на шине с одним и тем же ID - трагедия, чреватая BUSOFF-ами. Насчет повторной передачи: Если передача закончилась успехом, то все ок. Иначе - автоматическая повторная посылка. В контроллере can в МК это может гибко настраиваться: отключаться, перепосылаться уже с учетом порядка и приоритетов в мэйлбоксах и т.п.

Мультимастер должен не пугать, а привлекать. Меня в CAN больше всего напрягает максимальный размер пакета в 8 байт - чтобы передать что-то длиннее нужно придумывать какой-то транспорт.

Я пользовался такой нумерацией

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

VGA доковырять до конца нервов не хватило )) Но, поверьте, там ничего нет, кроме проводов.

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

Все очень плохо :( Пробрасывает только питание и I2C. Может, там пассивка какая есть...

У меня есть интересующий вас кабель (см. фотку). Есть монитор SAMSUNG SyncMaster 205bw с нативным 1680х1050@60Гц. Вам распиновку кабеля сделать? Или попробовать VGA через него передать?

У кого есть опыт оплаты таких отчислений? Мне казалось, что все отчисления заложены уже в цене МК с интерфейсом CAN. Разве нет?

Спецификация CAN не описывает физический уровень: Я понимаю, что данный документ (ГОСТ) определяет физический уровень, как того требует спецификация CAN. Т.е. это скорее технический документ, а не юридический. Иначе каждый начнет применять нестандартный физический уровень, и устройства не смогут работать на одной шине.

Какие напряжения на 16, 2, 6 пинах относительно GND? Где конденсатор между 15 и 16 пинами? Какова скорость импульсов?

При соединении отладчика с контроллером использовали вывод RESET? Используйте "Connect Under Reset".

Не проще готовое взять? Можете ТЗ скинуть?

Один канал настроить для захвата и перезапуска счета (см. SMCR.TS и SMS). Второй канал настроить на выдачу pwm (см. CCMR). Сам таймер настроить в режиме одиночного импульса (см. CR1.OPM).