Jump to content

    

adnega

Свой
  • Content Count

    2994
  • Joined

  • Last visited

Community Reputation

0 Обычный

About adnega

  • Rank
    Гуру
  • Birthday 05/01/1982

Контакты

  • Сайт
    http://www.grtc.ru
  • ICQ
    231861733

Информация

  • Город
    Ярославль, Россия

Recent Profile Visitors

8592 profile views
  1. Я так понял софт по VID/PID узнает модель, а затем грузит соответствующую конфигурацию в ПЛИС. Можно пошаманить с файликами конфигураций ПЛИС, но кроме переименовываний, на мой взгляд, особо ничего не сделаешь.
  2. У меня такая же версия. Если поменять байтики с 0x29 на 0x20, то анализатор вечно ждет сработки триггера. Если U2Basic превратить в Basic, то буфер сильно уменьшается (256к), но в старых версиях (0.9.9) можно захватить на 400Ms. Хотя захват может быть на 100Ms, а 400Ms - это просто циферка в GUI. Статью дополнили в районе 10 января.
  3. Там, вроде, если только два байта поправить, то 400Ms только в старых версиях ПО будет. Я чипы памяти заказал, но они еще не пришли - снял с отладочной платы какой-то. Свежачок по переделке
  4. U2Basic? Без паяльника буфер будет в 4 раза меньше. Есть энтузиасты, которые 512Мбит памяти жаждут получить.
  5. 1000 устройств CAN в сети

    "два значения скорости ... соответственно для терминированной и нетерминированной линии". 1. В терминированную линию 1 метр трансиверами RS485 передаем 100 каких-то пакетов на малой скорости. 2. На другом конце принимаем эти пакеты и сравниваем с тем, что передавали. 3. Если есть более одного битого пакета, то запоминаем скорость передачи. Тестирование закончено. 4. Если битых пакетов нет или всего один, то увеличиваем скорость на 10% и продолжаем с п.1. Повторяем эксперименты с нетерминированной линией - в результате запоминаем второе значение скорости. Сравниваем два запомненных значения.
  6. На днях переделал U2Basic (c Али) в Plus. Работает на 400Ms @ 4ch в буферном режиме. Буфер 256Мбит. Рекомендую.
  7. 1000 устройств CAN в сети

    Берем линию 1 метр. Берем два узла RS485, и, постепенно повышая скорость передачи, получаем два значения скорости, выше которой происхоит >1% ошибок передачи соответственно для терминированной и нетерминированной линии. Получаем аналогичные два числа для CAN узлов. Я утверждаю, что разница между двумя значениями для случая RS485 будет ощутимо меньше чем для случая CAN. Кто не согласен?
  8. 1000 устройств CAN в сети

    У меня шина порядка 20~40 метров всего на скорости 50 кбит/с. Но даже при этом без согласования не работает. Могу снять осциллограммы с терминатором и без если нужно. Медленный спад удлиняет доминантное состояние по версии приемника, и это приводит к ошибкам на шине. Терминатор не только борется с отражениями, но и ускоряет этот переход. Вот любите вы, jcxz, додумывать и притягивать то, чего нет: я не утверждал, что моя задача == задаче ТС. Я утверждаю, что для CAN важно: - правильная топология с терминаторами; - правильное положение точки семплирования; - правильное распределение идентификаторов. Я умный дом на CAN, скорее иллюстрация того как узлы в CAN должны относиться к обмену в противоположенность обмену в духе RS485. С RS485 было дело лет 7 назад на оном объекте в системе УД - куча проводов, куча узлов, медленный опрос - пришлось придумывать схемы с приоритетами опроса узлов, обрабатывать отвалы узлов без последующих тормозов на шине и т.п. Там где много мелких редких посылок от множества узлов и отсутствует необходимость в мастере, считаю, можно и нужно применять CAN. Может да, а может и нет... Мы инженеры и должны разрабатывать по-науке, а не в режиме "и так сойдет". Цена вопроса меньше рубля. Мы рубль экономим? Я думаю сотня, устройств скорее добавит емкости шине, чем проводимости. Ну и отражения никто не отменял. Кста, у некоторых CAN-phy есть вход управления крутизной. Иногда повышенная крутизна отрицательно сказывается на распространяемом сигнале. Это картинка линии, в которой есть хотя бы один терминатор. Попробуйте отключить все терминаторы и увидите при попытке передачи резкий переход в доминантное состояние, затем падение по экспоненте, при этом передатчик зафиксирует ошибку перехода в рецессивное состояние, включится ретрансмиссия, и так до BUSOFF.
  9. 1000 устройств CAN в сети

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

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

    У меня супруга делала дисер в Либре - все там есть. Могу показать как это делается.
  12. С Новым Годом! Всем успехов!
  13. Вроде, в приборе ЭТС-223 последней версии есть эмуляция DS18b20.
  14. 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() в МК не имеет смысла.
  15. А, может, половину ленты код нарастающий, а другую половину спадающий? Можно сэкономить 1 бит (или увеличить длину ленты в два раза).