Перейти к содержанию
    

adnega

Свой
  • Постов

    3 603
  • Зарегистрирован

  • Посещение

  • Победитель дней

    3

Весь контент adnega


  1. Я так понял софт по VID/PID узнает модель, а затем грузит соответствующую конфигурацию в ПЛИС. Можно пошаманить с файликами конфигураций ПЛИС, но кроме переименовываний, на мой взгляд, особо ничего не сделаешь.
  2. У меня такая же версия. Если поменять байтики с 0x29 на 0x20, то анализатор вечно ждет сработки триггера. Если U2Basic превратить в Basic, то буфер сильно уменьшается (256к), но в старых версиях (0.9.9) можно захватить на 400Ms. Хотя захват может быть на 100Ms, а 400Ms - это просто циферка в GUI. Статью дополнили в районе 10 января.
  3. Там, вроде, если только два байта поправить, то 400Ms только в старых версиях ПО будет. Я чипы памяти заказал, но они еще не пришли - снял с отладочной платы какой-то. Свежачок по переделке
  4. U2Basic? Без паяльника буфер будет в 4 раза меньше. Есть энтузиасты, которые 512Мбит памяти жаждут получить.
  5. "два значения скорости ... соответственно для терминированной и нетерминированной линии". 1. В терминированную линию 1 метр трансиверами RS485 передаем 100 каких-то пакетов на малой скорости. 2. На другом конце принимаем эти пакеты и сравниваем с тем, что передавали. 3. Если есть более одного битого пакета, то запоминаем скорость передачи. Тестирование закончено. 4. Если битых пакетов нет или всего один, то увеличиваем скорость на 10% и продолжаем с п.1. Повторяем эксперименты с нетерминированной линией - в результате запоминаем второе значение скорости. Сравниваем два запомненных значения.
  6. На днях переделал U2Basic (c Али) в Plus. Работает на 400Ms @ 4ch в буферном режиме. Буфер 256Мбит. Рекомендую.
  7. Берем линию 1 метр. Берем два узла RS485, и, постепенно повышая скорость передачи, получаем два значения скорости, выше которой происхоит >1% ошибок передачи соответственно для терминированной и нетерминированной линии. Получаем аналогичные два числа для CAN узлов. Я утверждаю, что разница между двумя значениями для случая RS485 будет ощутимо меньше чем для случая CAN. Кто не согласен?
  8. У меня шина порядка 20~40 метров всего на скорости 50 кбит/с. Но даже при этом без согласования не работает. Могу снять осциллограммы с терминатором и без если нужно. Медленный спад удлиняет доминантное состояние по версии приемника, и это приводит к ошибкам на шине. Терминатор не только борется с отражениями, но и ускоряет этот переход. Вот любите вы, jcxz, додумывать и притягивать то, чего нет: я не утверждал, что моя задача == задаче ТС. Я утверждаю, что для CAN важно: - правильная топология с терминаторами; - правильное положение точки семплирования; - правильное распределение идентификаторов. Я умный дом на CAN, скорее иллюстрация того как узлы в CAN должны относиться к обмену в противоположенность обмену в духе RS485. С RS485 было дело лет 7 назад на оном объекте в системе УД - куча проводов, куча узлов, медленный опрос - пришлось придумывать схемы с приоритетами опроса узлов, обрабатывать отвалы узлов без последующих тормозов на шине и т.п. Там где много мелких редких посылок от множества узлов и отсутствует необходимость в мастере, считаю, можно и нужно применять CAN. Может да, а может и нет... Мы инженеры и должны разрабатывать по-науке, а не в режиме "и так сойдет". Цена вопроса меньше рубля. Мы рубль экономим? Я думаю сотня, устройств скорее добавит емкости шине, чем проводимости. Ну и отражения никто не отменял. Кста, у некоторых CAN-phy есть вход управления крутизной. Иногда повышенная крутизна отрицательно сказывается на распространяемом сигнале. Это картинка линии, в которой есть хотя бы один терминатор. Попробуйте отключить все терминаторы и увидите при попытке передачи резкий переход в доминантное состояние, затем падение по экспоненте, при этом передатчик зафиксирует ошибку перехода в рецессивное состояние, включится ретрансмиссия, и так до BUSOFF.
  9. Без терминаторов переход линии из доминантного состояния в рецессивное будет по экспоненте. В RS485-физике переходы 0<->1 всегда выполняются активным способом, т.е. быстрее. 8 байт в поле данных максимум. Можно чуть чуть информации передать в поле идентификатора. Есть FD-версия CAN (где до 64 байт); не использовал, т.к. редко где он есть. Мультимастер и система приоритетов - это в некоторых случаях спасение. Например, у меня шина умного дома вся на CAN. Мастеров нет, все живет само, друг с другом общается, спокойно можно гонять низкоприоритетный трафик (например, интерком), не мешая никому важному. Обидно, когда люди используют CAN в режиме полудуплекса по старой привычке (RS485-стайл). Я же отношусь к обмену по CAN как "поставил задачу" - "получил результат", где между ними могут быть поставлены другие задачи и получены другие результаты, и ПО должно быть к этому готово, а не ждать результата в течение некоторого таймаута. Если вы настаиваете на CAN, то советую вам продумать адресацию узлов и приоритеты сообщений. Они же у вас короткие будут (до 8 байт включительно)? Насчет дробления, я бы рекомендовал разбить на такие группы, чтобы они питались от одного БП. Напряжение узлов лучше поднять по максимуму, чтобы снизить потребляемый ток, и т.о. снизить негативное влияние тонких проводов.
  10. "Крылья, ноги... главное хвост". Проблемы длинных линий обычно связаны с необходимостью согласования такой линии. Если теряются байты, то это не только из-за кривого драйвера, но и из-за отсутствия согласования линии. CAN в этом плане менее терпим ;) Это довольно неплохая конструкция: мастер на 60 слейвов, затем мастера в своей шине с одним супер-мастером. Мастера делают всю грязную работу по опросу узлов. Отвалившиеся узлы должны опрашиваться реже. Например, после каждого 10 опроса мы опрашиваем один раз один из "отвалившихся" узлов. Супер-мастер выдает высокоуровневые задания мастерам и получает от них высокоуровневые ответы подчиненных узлов. Уровни тут условные, главное различие - в адресации узлов на разных уровнях. В "приготовлении" RS485 есть много тонкостей, если их знать и учитывать, то никаких проблем, кроме скорости опроса не будет. Например, очень вредит неопределенное состояние линии, когда не работает ни один передатчик - решается либо растяжкой линии, либо задержкой передачи после активации передатчика, либо вставкой спецсимволов в начало кадра. CAN хорош, но у него все сложнее - точку сэмплирования бита не так выставил и через опторазвязку может на больших скоростях и/или растояниях не заработать. В AVR, например, положение точки семплирования не так гибко задается как в STM32.
  11. У меня супруга делала дисер в Либре - все там есть. Могу показать как это делается.
  12. Вроде, в приборе ЭТС-223 последней версии есть эмуляция DS18b20.
  13. 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() в МК не имеет смысла.
  14. А, может, половину ленты код нарастающий, а другую половину спадающий? Можно сэкономить 1 бит (или увеличить длину ленты в два раза).
  15. У вас там флюс CF-10 фигурирует. Он, вроде, "RA". Что обычно им паяете? Вы его смываете после пайки? Чем?
  16. Согласен на все 100. При старте управление должен получать загрузчик, считать контрольные суммы, обновлять, шифровать, предоставлять экспортируемые функции - тоже его задача. В конце он должен передать управление приложению. Размер приложения лучше сделать фиксированным, а в самом конце держать CRC32.
  17. CAN шина STM32F103

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

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

    Мультимастер должен не пугать, а привлекать. Меня в CAN больше всего напрягает максимальный размер пакета в 8 байт - чтобы передать что-то длиннее нужно придумывать какой-то транспорт.
  20. Так точно! Все неиспользуемые тупо в воздухе. Тут как бы есть шанс сделать цифру+аналог на стороне HDMI, но VGA сторона к обычному оборудованию не подойдет - видимо, есть какие-то нестандартные мониторы с нестандартным VGA-входом. Сейчас станица с этим товаром не доступна, но мне казалось - это был переходник для некоторых универсальных видеорегистраторов и стандартных мониторов. Видимо, монитор тоже должен быть особенный.
  21. VGA доковырять до конца нервов не хватило )) Но, поверьте, там ничего нет, кроме проводов.
  22. Воспользовался генератором и осциллографом - на других пинах жизни нет. Надрезал кабель - там 6 цветных проводов и один без изоляции. Кабель точно пассивный, т.к. при подключении в ПК в отличии от активного не мигает экраном и не "булькает".
×
×
  • Создать...