Попалась мне как-то старая книжка с прохождениями игр. Там каждое прохождение было в виде повествования и даже "прохождение" линейной стрелялки было интересно прочитать.
Автор мог бы потратить на написание прохождения чуть больше времени, добавить огонька. Глядишь кто-то почитал и подумал - а неплохо было бы сыграть в это...
Приветствую! Давненько это было) В свое время был приобретен осциллограф с логическим анализатором и проект благополучно зарос бурьяном. Поэтому отвечать буду по памяти.
На ваши вопросы в основном отвечает протокол SUMP (который, кстати, был выбран по причине наличия адекватных клиентов на то время)
1. Насколько я помню, SUMP не поддерживает непрерывную передачу.
2. SUMP-клиенту на ПК нужно указать COM-порт для подключения, поэтому CDC без вариантов.
Изохронная передача не гарантирует доставку, а выпадание сэмплов для данной задачи недопустимо.
И, да, если нужно добиться более высокой производительности, стоит сделать свой буферизующий (и передающий данные большими массивами) протокол, на базе libusb. Но придется добавлять поддержку в существующие sump-клиенты или найти что-то другое.
Пробовал такую камеру — не советую. Может мне, конечно, брак достался, но эта камера нормально видео показывает только метров до 5, дальше уже начинается слайдшоу, и метров с 10-15 сигнал вообще теряется. Да и когда работает — качество картинки весьма посредственное.
Коллега просит написать, что у вас на схеме диод D11 включен обратной полярностью. Конденсатор С11 зарядится до напряжения питания и компаратор работать не будет.
Когда в ТЗ стоит пунктик про отечественную элементную базу, любая задача внезапно на порядок усложняется :)
Про импульсы помнится еще несколько лет назад коллеги, используя Cyclone III, получали разрешение по времени в районе 1-2нс.
usStackDepth это параметр, который вы передаете в xTaskCreate, т.е. в данном случае 128
portSTACK_TYPE = unsigned long, а sizeof(unsigned long) = 4
128 * 4 =?
Порт FreeRTOS на STM32 работает с памятью не байтами, а 32-битными словами, см. тип portSTACK_TYPE файл portmacro.h для выбранной архитектуры, размер данного типа используется при выделении памяти под стек. Поэтому строчки
Означают что на таск выделяется 128*4=512 байт, а на всех 3000*4=12000 байт.
Когда сначала просматривал статью, первой мыслью было «О ужас! В новых FreeRTOS зачем-то изменили API». А оказалось это ST опять выпендрились и зачем-то понаделали оберток для функций FreeRTOS. Лучше этим чудом не пользоваться, во избежании проблем в будущем, а задействовать нормальный, свежий релиз FreeRTOS.
В микроконтроллерах даже отладка через JTAG не дает полной гарантии, т.к. есть свои тараканы. Любая операция несет какие-либо побочные эффекты. Например, при остановке ядра JTAG-ом — таймеры могут продолжать тикать, обычно можно настроить останов периферии при останове ядра, но не всегда и не везде.
Но если не заморачиваться сильно, то отладочный вывод в UART является простым и довольно надежным решением. Так самый удобный способ отловить причину аппаратного исключения — сделать обработчик с разбором стека и выдачей его в UART.
Не менее 8 тактов с момента возникновения запроса до его фактического исполнения, за 6 обращений к системной шине. Причем 8 тактов это в идеале, на деле больше, т.к. обращение к регистрам периферии на этом проце занимает по несколько тактов. Это ли не тормозной?
Тормознутость вообще обеспечивается как раз тем, что вы записали в достоинства — постоянным размещением TCB в RAM. В более прогрессивных DMA контроллерах TCB временно размещается в RAM, и копируется в регистры перед началом исполнения (DMA со связными списками). Что дает экономию по сравнению с Миландром по 4 такта на каждый обмен.
Эти «особенности» архитектуры приводят к весьма странному формату разработки: часто заранее очень трудно сказать, что выйдет быстрее по тактам — задействовать DMA или передать данные с использованием ядра. В итоге приходится в коде критичном ко времени исполнения по два варианта писать и проверять экспериментально.
К исправлению ошибок они подходят примерно по следующему принципу:
Критические ошибки, которые делают невозможным использование МК или его ключевых функций, исправляются в новой ревизии чипа.
Некритические ошибки, которые снижают характеристики или имеют возможность программного обхода исправляются «как повезет». Если МК прошел уже несколько ревизий и не имеет критических ошибок — ничего исправляться не будет.
Справедливости ради отмечу, что не только Миландр так работает. У тех же ST косяки кочуют не только из одной ревизии в другую, но и в новые версии МК, которые они регулярно выпускают.
У них есть IP-блоки собственной разработки, а есть покупные и DMA один из таких. Естественно документация на покупные блоки была исходно на английском. И мне, кстати, неизвестно ни одного иностранного МК использующего подобный контроллер DMA.
У нас тоже на многих проектах ограничительные перечни действуют, но вы лучше подумайте об основной аудитории данного сайта — указанный процессор большинство даже при желании пощупать не сможет, т.к. во-первых в розницу его частнику еще найти надо, а во-вторых стоит недешево.
Я сам с удовольствием почитаю о том, как автор борется с проблемами, с которыми самому, возможно, еще только предстоит столкнуться. Но для большинства читателей это будет чисто теоретический экскурс.
DMA контроллер от Миландра не лучший вариант для первого знакомства. Излишне навороченный, тормозной и косячный.
Большинство импортный МК имеют гораздо более гуманный DMA
Если уж генерить код в CubeMX, то логично продолжить написание кода в CubeIDE.
Попалась мне как-то старая книжка с прохождениями игр. Там каждое прохождение было в виде повествования и даже "прохождение" линейной стрелялки было интересно прочитать.
Автор мог бы потратить на написание прохождения чуть больше времени, добавить огонька. Глядишь кто-то почитал и подумал - а неплохо было бы сыграть в это...
На ваши вопросы в основном отвечает протокол SUMP (который, кстати, был выбран по причине наличия адекватных клиентов на то время)
1. Насколько я помню, SUMP не поддерживает непрерывную передачу.
2. SUMP-клиенту на ПК нужно указать COM-порт для подключения, поэтому CDC без вариантов.
Изохронная передача не гарантирует доставку, а выпадание сэмплов для данной задачи недопустимо.
И, да, если нужно добиться более высокой производительности, стоит сделать свой буферизующий (и передающий данные большими массивами) протокол, на базе libusb. Но придется добавлять поддержку в существующие sump-клиенты или найти что-то другое.
Про импульсы помнится еще несколько лет назад коллеги, используя Cyclone III, получали разрешение по времени в районе 1-2нс.
В мозгах как-то отложилось, что стек в лонгах.
В общем сие есть потенциальные грабли, про которые просто помнить надо.
и
www.freertos.org/a00125.html пояснение к usStackDepth
usStackDepth это параметр, который вы передаете в xTaskCreate, т.е. в данном случае 128
portSTACK_TYPE = unsigned long, а sizeof(unsigned long) = 4
128 * 4 =?
Про не кратность ничего не понял.
Означают что на таск выделяется 128*4=512 байт, а на всех 3000*4=12000 байт.
Когда сначала просматривал статью, первой мыслью было «О ужас! В новых FreeRTOS зачем-то изменили API». А оказалось это ST опять выпендрились и зачем-то понаделали оберток для функций FreeRTOS. Лучше этим чудом не пользоваться, во избежании проблем в будущем, а задействовать нормальный, свежий релиз FreeRTOS.
Но если не заморачиваться сильно, то отладочный вывод в UART является простым и довольно надежным решением. Так самый удобный способ отловить причину аппаратного исключения — сделать обработчик с разбором стека и выдачей его в UART.
Не менее 8 тактов с момента возникновения запроса до его фактического исполнения, за 6 обращений к системной шине. Причем 8 тактов это в идеале, на деле больше, т.к. обращение к регистрам периферии на этом проце занимает по несколько тактов. Это ли не тормозной?
Тормознутость вообще обеспечивается как раз тем, что вы записали в достоинства — постоянным размещением TCB в RAM. В более прогрессивных DMA контроллерах TCB временно размещается в RAM, и копируется в регистры перед началом исполнения (DMA со связными списками). Что дает экономию по сравнению с Миландром по 4 такта на каждый обмен.
Эти «особенности» архитектуры приводят к весьма странному формату разработки: часто заранее очень трудно сказать, что выйдет быстрее по тактам — задействовать DMA или передать данные с использованием ядра. В итоге приходится в коде критичном ко времени исполнения по два варианта писать и проверять экспериментально.
Критические ошибки, которые делают невозможным использование МК или его ключевых функций, исправляются в новой ревизии чипа.
Некритические ошибки, которые снижают характеристики или имеют возможность программного обхода исправляются «как повезет». Если МК прошел уже несколько ревизий и не имеет критических ошибок — ничего исправляться не будет.
Справедливости ради отмечу, что не только Миландр так работает. У тех же ST косяки кочуют не только из одной ревизии в другую, но и в новые версии МК, которые они регулярно выпускают.
Я сам с удовольствием почитаю о том, как автор борется с проблемами, с которыми самому, возможно, еще только предстоит столкнуться. Но для большинства читателей это будет чисто теоретический экскурс.
Большинство импортный МК имеют гораздо более гуманный DMA