Jump to content

    

jeka

Свой
  • Content Count

    449
  • Joined

  • Last visited

Community Reputation

0 Обычный

About jeka

  • Rank
    Administrator
  • Birthday 06/14/1980

Контакты

  • ICQ
    Array

Recent Profile Visitors

5570 profile views
  1. В итоге, сделал программный профайлер, который замеряет время блокировки прерываний у freertos. И сразу все стало ясно - мой косяк оказался. Со стеком всё нормально. как я понял, этой штукой точно замерить время не получится. Как-то пробовал запустить таймлайн через SWO, но всё наглухо подвисало, ощущение что клоки swo неверные были. Надеюсь, скоро будет j-trace pro, с ним должно быть повеселее такие штуки искать.
  2. Заметил странный спецэффект c LWIP. При интенсивном обмене по езернету (~30Мбит/с), IRQ с приоритетом ниже чем MAX_SYSCALL_INTERRUPT_PRIORITY стали очень сильно задеживаться (пордок - десятки тысяч CPU cycles). Т.е. где-то в стеке происходит длительная блокировка прерываний. Кто-нибудь сталкивался, разбирался где? такое положение вещей никуда не годится.
  3. Итак, коротко про параллельное исполнение в H7: (1) Базовая арифметика (+,-, логика, сдвиги): mov, mvn, cmp, cmn, add, sub, adc,sbc, srb, and, orr, eor, bic, orn, asr, lsl, lsr, ror, rrx - может выполняться по 2 операции за такт и параллелиться с остальным. (2) Остальная логика-арифметика (Всё остальное кроме FPU и умножения): SIMD (sadd8/16,...), PKH*, SXT,UXT, saturating - увы, только одна операция за такт. Может параллелиться со всем остальным. Поэтому их нужно чередовать с другими операциями. (3) Умножение - одна операция за такт. Может параллелиться со всем остальным. (4) FPU - может выполняться по 2 операции за такт и параллелиться с остальным. Латентность FPU инструкций - 2 такта. Т.е. результат можем использовать через 2 такта. (5) CPU load/store: одинарные операции могут параллелиться с остальными. dual load - ни с чем не параллелится, занимает 1 такт. LDM - кол-во тактов равно количеству регистров. Параллельно с LDM выполнится только одна инструкция. Т.е. для лучшего распараллеливания нужно разбивать LDM на единичные загрузки и мешать с другими инструкциями. Или использовать dual операции при работе с 64бит памятью. (6) FPU load/store: но занимают (5) и (4). В деталях не изучена. (7) CPU/FPU vmov: занимают (2) и (4). В деталях не изучена.
  4. Задался вопросом оптимизации кода. В интернетах не нашел какой-либо толковой информации по оптимизации кода под M7. Поэтому пришлось поставить несколько экспериментов по быстродействию. Пока только начал, но после изучения скудного описания cortex m7 pipeline результаты для меня весьма неожиданные. Итак, есть DWT, которым оценивал скорость выполнения инструкций на процессоре stm32h743. В нем использовался счетчик циклов CPU, счетчик циклов ожидания доступа к памяти, счетчик команд с нулевым кол-вом циклов (т.е. выполненных с чем-то параллельно). 1. максимальное число одновременно исполняемых команд за такт. Хотя в архитектуре есть 4 очереди: load-store, 2xAlu и 4xfpu, максимум что добился - 2 инструкции за такт, как ни крутил. 2. FPU. Судя по экспериментам, стандартная операция FPU длится 2 такта и модулей FPU - 4 шт. Т.е. код из только FPU инструкций исполнялся со скоростью 2 операции за такт, когда между формированием результата и его повторным использованием было не менее 3х FPU инстрцкций. Если же использовать результат в следующей инструкции, то получается по 2 такта на инструкцию. 3. Load/store. По моей логике, load-store должен выполняться в отдельной очереди и не мешать работать alu. Но на практике это не совсем так. Например, есть 16 FPU инструкций, выполняющиеся за 8 тактов. Если в начало добавить LDM 8ми CPU регистров из TCM памяти, то добавляется еще 6-7 тактов. 4. ALU. Тут всё гораздо приятней чем на FPU. Если результат использовать через 1 инструкцию, то стабильно получаем 2 инструкции за такт. За исключением умножения. Еще, в некоторых случаях, результат команд битовых манипуляций непосредственно в следующей инструкции выполнялся за 1 такт. Умножитель. Мне не удалось выполнить более одного умножения за такт (кроме инструкций SMUAD and SMUSD). т.е. умножение надо параллелить с другими операциями, либо использовать команды сдвоенного умножения. p.s. Это мои первые зксперименты, на истину не претендую, тем не менее общее представление уже начинает формироваться.
  5. Платы готовы, запаяны. С nRF52832, с ре ференс дизайна взят. Задача получается поднять на ней 5.2 low latency.
  6. Вы уверены что с этим нельзя ничего сделать? Если кто-то чегото намерял, это не значит что нельзя улучшить. Сейчас гуглю. bluetooth 5.2 поддерживает изохронную передачу, как раз для этих целей. С задержками порядка 1-2 мс как заявляют.
  7. Понимаю. Но в данном применении не нужны большие кодограммы и высокая скорость. Нужно передавать всего по несколько байт, но с минимальной задержкой. Поискал про bluetooth low latency. явно, есть варианты. Сразу например наткнулся - https://www.bluetooth.com/bluetooth-resources/low-latency-deterministic-bluetooth-technology/
  8. наверняка. И сделать самому можно. Но другой работы хватает, это хочется дать тому кто знает эти чипы. Ибо с nrf не работал, пока разберешься с периферией, нюансами, глюками - время жрёт. Предлагайте. думаю, в базовом варианте 50-100к. Обсуждаемо. Если внутрь стека залезете, это могут быть другие цифры. Вообще, это только начало. там задача довольно большая. Это понятно. поэтому и спрашиваю, ибо вроде всё просто, но чем дальше - тем сложнее. Нюансов много. Стандартов блютуса много разных, BLE из коробки при низком прирывистом трафике явно будет лагать. Возможно можно как-то таймслоты правильно резервировать или еще какие-то хитрости использовать для борьбы с лагами. в чем проблема? пакеты короткие. скорость хоть 15Мбит. По сравнению с десятками ms задержки радиоинтерфейса здержки уарта - ни о чем. upd. хотелки по зедержкам: до 20мс туда-обратно - отлично. Приемлимо до 50мс. Выше 100мс - плохо. Редкие глитчи и единичные потери не страшны.
  9. Есть задача сделать транспорт пакетов между android приложением и stm32h743. В качестве bluetooth трансивера установлена nRF52832, к которой подключена stm32h743 через 4х-проводный uart (есть rts/cts). Связь нужна пакетная (как udp), payload пакета до 64 байт. Перезапросы и отсутствие потерь пакетов не критичны, этим будет заниматься приложение. Нужно обеспечить максимальный реалтайм. Т.е. буфера в идеале нигде не должны накапливаться, вместо этого передающая сторона ожидает освобождения буферов и формирует кодограмму непосредственно перед передачей. в результате (как я вижу) - рыба android приложения, соединяющаяся с NRF и отправляющая пакеты c настраиваемой скоростью по этому интерфейсу и собирающая статистику по времени ответа (min/max/avg) и потерям. на стороне stm32 - преобразование потока uart <-> пакеты, и loopback пакетов (на очередях freertos). Москва. платы есть. Предпочтение - опытному человеку с наработками и пониманием нюансов работы таких трансиверов. Цены обсуждаемы, в приоритете безглючность и стабильность.
  10. я как-то баловался с этим. управлялка массивом лент-игрлянд ws2812 c midi интерфейса. Для управления множеством контроллеров одновременно. В любой DAW можно прописать автоматизацию под музыку или с пульта запускать эффекты. Только не pic, а stm32. и сс1101 для радио. Пример пробной инсталляции - https://vk.com/yaroshchukvideo?z=video52259628_456241891%2F3a43597acb5049ae04%2Fpl_wall_52259628 По сути, массив контроллеров лент (хоть 1, хоть 1000), и usb свисток с трансивером. позволяет обновлять прошивку одновременно всего массива контроллеров по воздуху (для отладки эффектов).
  11. А не пробовали сделать низкоскоростной процесс (по таймеру например), анализирующий факты перехода через 0 у таймеров энеодеров? Чуть сложнее, но я на похожей задаче делал, вариант рабочий.
  12. Спасибо за замечание, учту. Я не настолько глубоко копался в этом чтоб все идеально сделать.
  13. Всё верно. Я про ресет с помощью простой передачи управления по адресу. Запускал так бутлоадер прямо из irq. Ибо надо было не ресетить коммуникацию, иначе связь порвётся. получается очень легкий механизм заточеный на событийную коммуникацию. Замена RTOS в части многопоточности и сигнализирования обслуживающих коммуникацию потоков. заменяя цепочку irq периферии->сообщение RTOS->wakeup процесса->IRQ планировщика->переключение контекста->обработка, на irq->переключение контекста->обработа
  14. нет, я про софт-ресет чисто программный, а не про ресет установкой бита ресета
  15. жаль. (хотя я софт-ребут из IRQ делал и вроде всё сбрасывалось, но могу и ошибаться). Значит стек на возврат настроить и выполнить возврат, сразу в нужное место. А вот с восстановлением вопрос. Видимо так же.