[aaarrr 63]

4 minutes ago, jcxz said:

Я задал конкретный вопрос: "Какая разница "через раз засыпает" или сразу?"

Sleep-задача перед сном может выключать лишнюю периферию, переключать тактирование... и включать все назад после пробуждения.

Накладные расходы не нулевые. Сон бывает не только в контексте idle-task RTOS.

 

6 minutes ago, jcxz said:

И почему всем этим должна заниматься sleep-задача?

Потому что эти действия производятся непосредственно перед переходом в режим пониженного потребления.

[iiv 16]

3 hours ago, jcxz said:

Если не нужен, то какой смысл выбора именно ESP32? Думаю - можно подобрать что-то получше, с лучшей производительностью. Можно даже какой-нить DSP. Например тот же TMS320C674x выдаст 2 float-MACа/такт и 1 double-MAC/2 такта (а не 40 тактов на double-MAC как у Вас). И это - при тактовой <=456МГц.

 

PS: Да и с потреблением/рассеиванием тепла у QFP-корпуса TMS320C674x дела обстоят лучше.

полностью согласен с Вашими доводами, и сам последнее время часто пользую IMXRT1062, в котором дела обстоят существенно лучше, хоть там только одно ядро. Но гемор по прикручиванию камеры сильно отпугивает, а тут все из коробки сразу поехало.

 

И, кстати, сравнивая на одинарной точности потребление teensy 4.1 c IMXRT1062 и ESP32, заметил, что при практически одинаковых пиковых флопах на одинарной точности их потребление тоже примерно одинаково. Не спорю, что у IMXRT1062 внутренняя память существенно быстрее, и это сильно облегчает жизнь при разработке, но цена-то в 10 раз отличается. А у Техаса, к сожалению, не дешевле.

[rkit 1]

5 hours ago, iiv said:

хорошо, я согласен, что бубны будут, но хотелось бы иметь их минимум, решая эту задачу максимально быстро.

Ты не представляешь себе трудозататность задач машинного времени. Это не делается за год одним разработчиком на встраиваемой платформе.

  

4 hours ago, iiv said:

30фпс на 2/3 мегапикселя, то есть 160мбит/с, это уже обычным SPI не протащишь

Машинное зрение в реальном времени в таких разрешениях не работает

[jcxz 184]

7 минут назад, aaarrr сказал:

Sleep-задача перед сном может выключать лишнюю периферию

Выключать лишнюю периферию должны драйверы этой периферии. Каждый драйвер - свою. После того как она больше не нужна. А перед использованием - включать. Нет никакого смысла держать периферию включённой после того, как она стала ненужной.

Цитата

, переключать тактирование... и включать все назад после пробуждения.

Накладные расходы не нулевые. Сон бывает не только в контексте idle-task RTOS.

И все остальные манипуляции - тоже за пределами idle-задачи. В idle-задачу отдаётся только время CPU, не используемое никаким полезным процессом. В том числе и процессом переключения чего-либо.

И не важно - это idle-task RTOS, или это единственный цикл, исполняемый в фоне, когда вся полезная работа выполняется в IRQ.

 

Цитата

Потому что эти действия производятся непосредственно перед переходом в режим пониженного потребления.

Вот поэтому моему алгоритму без разницы: сразу ли CPU уйдёт в сон при первой WFI/WFE или провернётся ещё цикл. Поэтому такой подход лучше, чем ваш с натаскиванием всяких левых операций в idle-задачу.

[aaarrr 63]

2 minutes ago, jcxz said:

Поэтому такой подход лучше, чем ваш с натаскиванием всяких левых операций в idle-задачу.

Еще раз:

2 minutes ago, jcxz said:

Сон бывает не только в контексте idle-task RTOS.

валиться в DEEPSLEEP с раскочегаренным тактированием - так себе экономия.

[iiv 16]

5 minutes ago, rkit said:

Ты не представляешь себе трудозататность задач машинного времени. Это не делается за год одним разработчиком на встраиваемой платформе.

почему же, очень хорошо представляю, и алгоритм по расчету сдвигов картинки я за неделю запрограммировал. Так как всякие варианты Фурье на скалярных, суперскалярных, векторных, конвейерных и массивно-параллельных платформах я писал очень много раз за свою жизнь, то спортировать двухмерное Фурье на эту платформу совсем не вижу для себя больших проблем.

Для меня конечно же вызывают затруднения по освоению интерфейсов, но, как я понимаю, как раз в этой платформе тут все удалось пройти за неделю, и я этому несказанно рад.

 

9 minutes ago, rkit said:

Машинное зрение в реальном времени в таких разрешениях не работает

то, что мне нужно (я задачу выше формулировал), как раз в таком разрешении (1024х768 на 30fps) уже хорошо работает.

[jcxz 184]

1 час назад, aaarrr сказал:

валиться в DEEPSLEEP с раскочегаренным тактированием - так себе экономия.

Ещё раз:

1 час назад, jcxz сказал:

все остальные манипуляции - тоже за пределами idle-задачи.

т.е. - отключаем все лишние тактирования, настраиваем сигналы пробуждения, через регистры управления питанием разрешаем DEEPSLEEP, понижаем тактовую ядра до минимума. Всё это выполняем в полезной задаче, не в idle-задаче. Затем эта задача переходит на ожидание объекта синхронизации ОС, т.е. - отдаёт выполнение в idle-задачу. Которая и активирует сон, выполнив WFE/WFI.

[_pv 52]

1 hour ago, iiv said:

Вот после такого сжатия сдвиг посчитать уже очень сложно. Я брал камеру с мобильника (от нескольких мегапикселей до сотни мегапиксилей) и получаемый сжатый стрим раскрывал потактно и считал сдвиги через Фурье, получалась довольно плохо. А если взять raw дата пусть даже 480х320, и для него считать эти сдвиги, то результат получается существенно лучше.

алгоритмы сжатия вроде как ровно это и делают, смотрят куда какая часть картинки съехала между кадрами и жмут разницу между кадрами, но  с учётом сдвига, которая этом случае в основном около нулевая.

я как-то давно на фотограмметрию поглядывал с точки зрения как раз именно восстановления траектории движения камеры.

ничего особо не сделал, но играясь с какими-то пережатыми роликами с ютуба с полетами квадракоптеров что-то не было ощущения что вот raw без сжатия чем-то сильно бы помог.

 

з.ы. а картинка между кадрами может успеть сильно далеко уехать? то есть от полной кросскорреляции через ФФТ прям есть заметный выигрыш, по сравнению тупым прямым вычислением по всей картинке но для сетки сдвигов ~10х10, там более что можно ещё и предыдущий посчитанный сдвиг запомнить и считать вокруг него?

[iiv 16]

26 minutes ago, _pv said:

алгоритмы сжатия вроде как ровно это и делают,

Спасибо большое за комментарии!

 

Как я понимаю, во время движения этим алгоритмам проще картинку размазать, всяко человек это движение не видит. ИМХО, именно из-за этого там все юзом идет. Это можно обойти, если кросс-коррелировать не только соседние картинки, но и те, что далеко друг от друга во времени, но, лень этим заниматься, проще raw взять.

 

26 minutes ago, _pv said:

з.ы. а картинка между кадрами может успеть сильно далеко уехать? то есть от полной кросскорреляции через ФФТ прям есть заметный выигрыш, по сравнению тупым прямым вычислением по всей картинке но для сетки сдвигов ~10х10, там более что можно ещё и предыдущий посчитанный сдвиг запомнить и считать вокруг него?

я надеюсь, что нет, но с кросс-корреляцией тоже свои заморочки. Во-первых, ее можно разреженной делать, чтобы флопы экономить и тогда она на маленьких наборах сдвигов может Фурье по флопам уделать, но, у нее есть недостаток, у нее тогда очень сложный алгоритм доступа к памяти, а в этом процессоре память при линейном доступе в 16 раз медленнее процессора, а при случайном - вообще в сотню, то есть мудрить много придется.

 

 

[aaarrr 63]

1 hour ago, jcxz said:

...понижаем тактовую ядра до минимума.

...и ловим в этот момент переключение контекста, например.

 

Ладно, ответа на вопрос "почему WFE" не будет, я уже понял.

[jcxz 184]

8 минут назад, aaarrr сказал:

...и ловим в этот момент переключение контекста, например.

Если у вас в "этот момент" случаются переключения контекста, то явно что-то нужно править в консерватории программе.  

8 минут назад, aaarrr сказал:

Ладно, ответа на вопрос "почему WFE" не будет, я правильно понимаю?

Ответ уже был. Только вы, увлёкшись листанием своего блохнотика, его видимо зевнули.  

[aaarrr 63]

5 minutes ago, jcxz said:

Если у вас в "этот момент" случаются переключения контекста, то явно что-то нужно править в консерватории программе

У вас - это не моё описание, и мер по предотвращению такой ситуации оно не содержит.

 

6 minutes ago, jcxz said:

Ответ уже был

Ложь!

[SII 0]

Только что тема про ESP32 делает в разделе про ARMы? Там же другая архитектура совсем.

[mantech 33]

4 часа назад, SII сказал:

что тема про ESP32 делает

Наверно поэтому "

• TI, Allwinner, Nordic Semiconductor, Espressif Systems и другие

"

Изменено 14 апреля, 2022 пользователем mantech

[SII 0]

6 hours ago, mantech said:

Наверно поэтому "

• TI, Allwinner, Nordic Semiconductor, Espressif Systems и другие

"

 

Ага, но сам этот подраздел входит в раздел ARM... Думается, правильней было б Эспрессифы вынести в отдельный раздел -- ну не АРМы они ни разу.