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

Alex_2015

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный

Информация о Alex_2015

  • Звание
    Участник
    Участник

Посетители профиля

1 223 просмотра профиля
  1. crc32 stm32

    Всем спасибо, кто откликнулся. Проблему я решил. Надо было изменить опции для команды checksum, а именно --checksum u32_ielftool_checksum:4,crc=0x04c11db7:Li,0xffffffff;0x08004000-u8_checksum_end+3 Опции Li вместо ir. Тогда расчёт через встроенный аппаратный модуль проца возвращает ноль в качестве результата. Иар версии 7.80. Возможно, в более ранних версиях было по другому https://www.iar.com/support/tech-notes/general/calculate-crc32-as-in-stm32-hardware-v.5.50-and-later/ https://www.cnblogs.com/shangdawei/p/4603924.html
  2. crc32 stm32

    Эту статью я читал. Я пробовал рассчитать контрольную сумму для одного слова (4 байта). Результат оказался верным, но побайтно отзеркаленным. Тут и получается, что не взирая на установку флага r результат остаётся неизменным.
  3. crc32 stm32

    День добрый. Если кто сталкивался, подскажите. Посредством ИАР пытаюсь генерить контрольную сумму прошивки. Генерит, но она не совпадает с той, которую считает аппаратный модуль процессора. Несколько дней искал причину. В конечном счёте не работает перестановка байт при расчёте CRC. Использую в бат файле команду ielftool.exe --fill 0xFF;0x08004000-u8_checksum_end+3 --checksum u32_ielftool_checksum:4,crc=0x04c11db7:ir,0xffffffff;0x08004000-u8_checksum_end+3 --verbose %OUT% %OUT% Так вот, не работает опция r, которая указана после алгоритма ,crc=0x04c11db7. Что и где её может запретить.
  4. Попробовал DeviceIoControl попользовать. Ожидаемого результата не увидел. Видимо не реализована она на уровне драйвера или чтобы она работала правильно, надо что то ещё допилить, но пока не нашёл. А можно ли запрячь драйвер, чтобы он возвращал явном виде о событии Idle в линии данных. То есть об отсутствии данных судить не по отсутствию Rxchar, а чтоб драйвер об этом сообщил. Есть такая программка - Modbus Poll. Вот она как-то умудряется по паузам между сообщениями работать, причём при обработке сообщений, не являющимися в чистом виде Модбасовскими. Вот как она это делает, мне очень интересно.
  5. В моём случае пауза определяется временем опроса драйвера виртуального порта системой. Это время составляет 1 мс. Вот 2 мс это и есть граница. Если система будет загружена выполнением большого количества дополнительных задач, то в таком случае спайки и на 30 мс неожиданностью не станут. Особенность в том, что DeviceIoControl позволяет добавлять в поток дополнительные данные о статусе устройства. Делается это на уровне драйвера, как мне удалось понять. Но повторюсь, информация очень скудная и будет ли в ней прок, хотел посоветоваться со знающими людьми. Может быть и другим интересно будет. Упоминания об использовании этой функции в связке с IOCTL_SERIAL_LSRMST_INSERT находил преимущественно на зарубежных сайтах. У нас как-то об этом не упоминают или ни кто не пробовал с ней работать.
  6. День добрый всем. У меня появилась возможность вернуться к решению задачи о построении сниффера и частично я её решил. 2 мс между посылками в компьютерной программе ловлю на ура. Причём не пришлось повышать приоритеты ни процесса, ни потока. Теперь хочу закрепить результат и поймать паузы менее 2 мс. В связи с чем вопрос - с функцией DeviceIoControl применительно к виртуальному порту кто-нибудь упражнялся. А то на всех ресурсах описание её очень скудное. В выходные попробую реализовать и посмотреть её результат. Но может кто что скажет из опыта работы с ней.
  7. Я всё-таки внесу некоторые дополнения. Использую преобразователь USB-RS485. Провёл несколько экспериментов и выяснил, что данные из порта читаются пачками по 4-16 байт. Причём начало запроса всегда читается с начала, начало ответа читается вместе с хвостом запроса. Эксперименты с таймаутами мало что меняют. Здесь, я думаю, большую роль играет характер устройства (виртуальный порт). Так случилось, что преобразователь построен на основе FTDI микросхемы. У неё есть возможность работы через D2XX драйвер, который, если верить описанию, в большей степени позволяет мониторить события железки. Если кто работал с ним, насколько это так. Сейчас вынужден временно переключиться на другую задачу, поэтому по этой буду только инфу изучать в свободное время.
  8. Я не утверждаю, что MSDN врёт. Просто констатирую факты. Возможно ошибка есть более глубоко в моём коде и я её пока не вижу. Поэтому пытаюсь освежить информацию по работе с портом, возможно пока та самая ошибка не проявлялась за несколько лет работы проги.
  9. Читал я MSDN в своё время, когда осваивал программирование ком порта. Но это ни чего не даёт. Когда драйвер захочет вернуть данные пользовательской программе, тогда и вернёт. И совсем не в режиме реального времени. А с таймоутами я экспериментировал, результат далёк от желаемого.
  10. На тему конвертора мысли были. Но только на самый крайний случай. Сейчас пока используется модифицированный модбас, в котором есть признаки, позволяющие однозначно определять начало и конец посылок. Есть потребность перейти к стандартному модбасу и будет нужна прога, которая позволит в реальном времени отслеживать обмен между устройствами в целях отладки. Сегодня перечитывал старую информацию, которую использовал при освоении программирования ком порта и нашёл то, что пропустил. Есть в структуре DCB символ XOFCHAR, который позволяет определить конец посылки. Осталось непонятным, его записывает драйвер в массив приёма или этот символ должен быть записан передатчиком в конец сообщения. Интернет по этому поводу подробностей пока не дал. Буду пробовать экспериментально. Была ещё мысль отслеживать событие DCD data carrier detect, но боюсь оно ожидаемого результата не даст. Была мысль алгоритмически ловить конец посылки через подсчёт CRC, но вариант не самый красивый. Хотя должен привести к результату.
  11. Такой вариант я рассматривал, но здесь ключевая фраза, если принята без ошибок. Самый надёжный способ - именно ловить паузы. Эксперименты с таймаутом особо не помогают. При скорости 115200 время передачи байта составляет 95мкс, а таймауты устанавливаются в миллисекундах. Основную проблему я вижу в том, что драйвер подбирает у системы данные с некоторым периодом. Программа у драйвера запрашивает данные тоже с каким-то периодом. За это время фактически драйвер может взять у системы несколько байт. Причём может схватить хвост запроса и начало ответа. Отсюда и лезут проблемы.
  12. Всем доброго дня. Есть сеть устройств, работающих по протоколу модбас через RS485. Необходимо написать перехватчик сообщений для ком порта, способный ловить паузы между сообщениями. Вот как поймать паузы, пока не соображу. Драйвер возвращает пачки по несколько байт, но поймать получается только длинные паузы (между запросами), а вот разделить запрос-ответ пока не могу. Есть программы снифферы, которые как-то реализуют такую возможность. Надо написать свою, в которой данные преобразовать в удобоваримый вид, удобный для отладки работы сети устройств. В винде это наверное тяжело будет сделать, но может есть способ, о котором я пока не знаю.
  13. aduc845 и PSEN

    День добрый! Проблема решилась. По всем признакам, формировался резет из-за многочисленных помех (устройство-мощное ЗУ) и проц уходил в загрузчик или что-то похожее (по косвенным признакам). Добавили кучу фильтров в питание и разделили по питанию процессор и перефирию, скорректировали трассировку нулевого провода. Хотя на удивление предыдущая версия прибора при тех же технических характеристиках и похожей трассировке платы проблем не доставляла. Всем спасибо.
  14. aduc845 и PSEN

    День добрый. Хотелось бы в продолжение темы задать ещё один вопрос. Как мне казалось, с процессором я разобрался, первую версию изделия собрали уже в нескольких экземплярах и всё чудненько работает. Но не бывает всегда всё хорошо. Сейчас делаем обновлённую версию и я достаточно серьёзно перепахал программу с целью ввести дополнительны возможности в прибор. И на столе всё работает изумительно, а вот в приборе... Вопрос в следующем. В самом начале основного цикла вставил переключение состояния пина, управляющего светодиодом, для контроля перехода программы через нулевой адрес в процессе работы (было замечено, что при некоторых внешних условиях программа будто перезапускается) и светодиод действительно переключается. А вот теперь пытаюсь понять, что его на это сподвигает. Проблемы с кодом не вижу. Подскажите, кто сталкивался, какие внешние события могут приводить к подобному сбою. Быть может это POR так себя проявляет?
  15. aduc845 и PSEN

    Видимо это было у очень старых атмеловских процессоров или у 51 архитектуры. У арма я такое не припомню. Но пока я решил остановиться с копанием PSENа. Программа сейчас работает без сбоев и надо уже по основным изменениям отработать. А времени, как всегда, мало, а сделать надо много. Хотя подозрение возникло. Проверю его чуть позже. Некоторые моменты в описании структуры памяти не совсем однозначно можно толковать. За подсказки спасибо.
×
×
  • Создать...