[dimka76 63]

On 4/18/2022 at 7:49 PM, Arlleex said:

я хочу найти красивую удобную инструкцию копирования бита i из R0 в бит j в R1 (R1 как пример).

 

8 hours ago, Arlleex said:

Cortex-M3 у меня, да. Но bit-banding он просто сожрет куда больше тактов - не гуд.

Копирование бита i из R0 в бит j в R1, как я понимаю, вы подразумеваете одна инструкция, которая копирует один бит из одного регистра в другой. Т.е. из одной ячейки памяти в другую.

bit-banding так же будет копировать один бит из одной ячейки памяти в другую. Может и будет чуть больше инструкций за счет загрузки очередного адреса копируемой ячейки памяти в регистр. 

10 hours ago, jcxz said:

Не в каждом Cortex-M он есть.

https://developer.arm.com/documentation/ddi0337/h/programmers-model/bit-banding#:~:text=The processor memory map includes,bit-band region of memory.

А тема как раз про Cortex-M3.

On 4/18/2022 at 7:49 PM, Arlleex said:

Они все, естественно, не сходятся "как есть" с заложенным порядком в протоколе обмена. Значит, перед отправкой по интерфейсу их надо перекодировать в другой порядок.

И куда вы эти данные отправляете по протоколу ?

Если на компьютер, то может на него переформатирование возложить ?

У него и быстродействие побольше будет, чем у любого Cortex-M3.

[Obam 38]

Тогда можете показать Cortex-M без Bit-banding ?

XMC4xxx. Cortex-M4 без bit-banding.

И Cortex-M7 без оного ;-) "вааще"

[adnega 11]

25 минут назад, Obam сказал:

И Cortex-M7 без оного ;-) "вааще"

У ТС Cortex-M3, а в них эта фича встроенная. У М4-моделей - опциональная. У М0 - отсутствует. У М7 и прочих - не в курсе.

Забавно, что jcxz указал, что фича может отсутствовать, но когда я дополнил, что и инструкций выбранных может не быть - вспомнили о М3.

С М4 и М7 соглашусь, но М3-то есть без Bit-banding ?

[jcxz 242]

18 минут назад, adnega сказал:

но М3-то есть без Bit-banding ?

Кто их знает - может есть, может нет. Но в любом случае - это операции с памятью. А значит будут однозначно медленнее перекладывания битов в регистрах.

А ТС хочет "оптимально". А это видимо подразумевается = "быстро".

Если бы можно было использовать инструкции LDM/STM или POP/PUSH, то можно было бы попытаться ещё ускорить. Но они вроде как не поддерживаются в bit-band регионах.

[adnega 11]

Цитата

в протоколе обмена. Значит, перед отправкой по интерфейсу их надо перекодировать в другой порядок.

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

Тут оптимизировать лучше не поток команд, а качество исходника на ЯВУ. Кто сказал, что "оптимально" - это ="быстро"?

Я читаю, что "оптимально" это про качество исходника, его многократной применимости в других проектах, скорости разработки,

защиты от глупых ошибок - денег в конце концов. Да, если нужен быстрый код, то UBFX + BFI - самый лучший вариант, и довольно универсальный.

Но это ASM, совсем другие требования к разработчику, легко допустить ошибку, сложно сопровождать

(например, битик в протоколе потребуется поменять местом или раскладка матричной клавиатуры поменяется из-за снабжения).

И самое главное - это прибивание гвоздями исходника к процессору.

Я бы завел одну структуру с битовыми полями под клавиатуру, вторую - под пакет протокола. В исходнике - присвоение всех битов протокола битам клавиатуры.

Если меняется клавиатура - меняем только ее поля в структуре. Аналогично для протокола. Дальше пусть компилятор оптимизирует - я показал на что он способен.

[Arlleex 189]

9 часов назад, dimka76 сказал:

...bit-banding так же будет копировать один бит из одной ячейки памяти в другую...

Я это понимаю прекрасно, и Вы дальше правильно развили свою же мысль - сколько тактов будет занимать все это дело? Давайте просто прикинем: UBFX / BFI - это 1-тактные инструкции, LDR / STR - 2-тактные, и сделать их 1-тактными не получится (конвейеризовать) в силу необходимости предзагрузки адресов памяти источника и назначения. Итого разница в скорости вполне может составить 4-6 раз (не знаю, надо считать). Я всего лишь хотел инструкцию, которая сделает UBFX + BFI за 1 такт. Ее нет.

Цитата

И куда вы эти данные отправляете по протоколу? Если на компьютер, то может на него переформатирование возложить?

На компьютер, да. Протокол изменять нельзя - железок (этих "клавиатур") разных исполнений вагон и 2 тележки в силу дефицита комплектации.

P.S. Коллеги, моя хотелка заиметь одну 1-тактную инструкцию-аналог UBFX + BFI - это лишь хотелка. Если ее нет - значит ее нет

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

Всем спасибо.

[AVI-crak 0]

On 4/18/2022 at 10:49 PM, Arlleex said:

Смысл в том, что в некотором простом алгоритме обрабатываются бинарные данные, причем сразу "пачками" по разрядности регистра (32 бита).

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

В случае автономной клавиатуры, со своим мк - имеет смысл переложить на него всю обработку кнопок. Сырые данные никому не нужны.

Я так и не услышал самого важного - последовательности сортировки. Например 31,1,2,16,0,3,4,5,6,7,8,9,10,11,12,13,14,15,17,18,19,20,21,22,23,24,25,26,27,28,29,30. Потому как сам алгоритм сортировки всегда подгоняется под реальную задачу. Там нет идеальных универсальных решений.

[Arlleex 189]

6 часов назад, AVI-crak сказал:

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

О чем Вы? Объясните мне что значит "дешифровка конкретной кнопки" в Вашем понимании?

Цитата

С очень существенной экономией энергии которую жрёт мк - это важно при батарейном питании.

Я еще в начале топика написал, что МК опрашивает матричную клавиатуру (11 x 11 в моем случае). Сканировать нужно так, чтобы данные каждого столбца защелкивались с частотой не менее 2.5 кГц, и оценка "нажатия" ведется по одинаковым значениям семплов в течение 20 мс интервала времени. Если хоть один семпл для каждой кнопки отличается в этом 20 миллисекундном интервале от своих прошлых значений, результат отбрасывается, ибо это помеха или дребезг.

Цитата

В случае автономной клавиатуры, со своим мк - имеет смысл переложить на него всю обработку кнопок.

У меня так и есть. Опять же в начале топика писал, что МК опрашивает кнопки и пуляет их в определенный интерфейс. Я прекрасно понимаю, что перекодировка в нужный формат должна вестись непосредственно перед отправкой в интерфейс, а не каждый цикл в сканировании / фильтрации. Об этом и речь.

Цитата

Я так и не услышал самого важного - последовательности сортировки.

А какая разница какая там последовательность? Это не сортировка а перекодировка - это немного разные вещи. Лапы на МК разработчик платы раскидал как ему было удобнее; я же как программист в каждой железке (в каждой вариации железа) должен иметь одну единственную функцию перекодировки всего этого безобразия в единый формат выдачи. Эти функции в каждой железке, естественно, свои. А какой бит в какой перенаправить можно #define-ми задать.

Цитата

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

Еще раз: алгоритм перекодировки - он разный. А вот сортировка может быть реализована и без привязки к данным (и это самая крутая реализация).

[AVI-crak 0]

1 hour ago, Arlleex said:

А какая разница какая там последовательность?

Есть разница. В случае совпадения порядка нескольких бит (допустим 3,4,5) - имеет смысл двигать весь регистр и использовать маску. В остальных случаях использовать UBFX + BFI.

На си получается классика: (x) старая позиция, (y) новая позиция.

out = 0;
tmp = (in >> (x)) & 1;
out |= tmp << (y); 

Временный регистр обязателен, именно с ним получаются те 2 команды на асме. Для ускорения использовать два регистра, потому как сдвиг в ARM требует два такта конвейера. 

[Arlleex 189]

3 минуты назад, AVI-crak сказал:

В случае совпадения порядка нескольких бит (допустим 3,4,5) - имеет смысл двигать весь регистр и использовать маску.

В этом случае тоже будет UBFX + BFI. Просто извлечется + вставится сразу группа битов. Но такие моменты мне лень "выковыривать" из схемы девайса. Разве что если только "на глаз" сразу видно, что их таких не мало.

[adnega 11]

У меня задача сложнее была нужно было выполнять транспонирование битов: есть 8 байт, нужно первые биты всех байт по порядку сложить в первый выходной байт, вторые биты - во второй и т.д. И делать это 100 раз в секунду, и байтов там под тыщу - вывод картинки на матрицу светодиодов. Делал с использованием BB. Вот бы одну инструкцию или трюк какой...

[Arlleex 189]

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

Делал с использованием BB...

BB? Что это? А, bit-band, что ли.

[adnega 11]

45 минут назад, Arlleex сказал:

BB? Что это? А, bit-band, что ли.

Да.

[Edit2007 3]

Цитата

Делал с использованием BB.

*

Изменено 21 апреля, 2022 пользователем Edit2007
Понял что не RBIT

[Eddy_Em 2]

13 hours ago, adnega said:

трюк какой

Я для этих целей просто сразу же готовлю правильный экранный буфер. Т.е. функции типа setpixel работают с конкретным битом, как он будет выводиться, а не промежуточным каким-то. А потом - просто при помощи таймера и DMA загоняю весь массив данных в матрицу. Учитывая то, что для динамической индикации буфер должен отправляться в матрицу намного чаще, чем происходят какие-то изменения в нем, именно такой способ наиболее целесообразен. Ну, в МК с большим объемом оперативки можно двойной буфер сделать: в одном хранить изображение в "нормальном" формате, а во втором - в "родном" для матрицы. Только зачем?

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