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

Mahagam (01.05.2022 10:25, просмотров: 214) ответил VladislavS. на Справедливости ради, код от начала прерывания до отправки данных по назначению одинаков в случае связного списка и инкремента указателя. Если общая загрузка процессора не зашкалит, то результат будет одинаков. Но зачем делать плохо, если можно сделать хорошо.

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

Ответить

- Для полноты картины посмотрим листинг и этого варианта. За сдвиг записи полезных данных на одну команду к началу прерывания платим дополнительной переменной в SRAM и более длинным прерыванием: VladislavS.(811 знак., 02.05.2022 10:06)
  - Для полноты картины надо мой вариант было рассмотреть, причём желательно использовать для массива индекс типа uint16_t. Тогда в моём варианте читать из флеша в 2 раза меньше, но использовать 1 РОН. И на частотах выше 25 МГц (предел флеша), думаю, будет профит. - Costic(02.05.2022 16:54)
    - Во-первых, даже для чтения переменной из RAM надо сначала загрузить её адрес из флэшь. Во-вторых, РОН экономить смысла нет, они при входе в прерывание сохраняются в достаточгом количестве. В-третьих, чтение 8/16/32 бит из флэшь занимает одинаково времени, ничего тут не сэкономишь. Ну и самое главное, зачем в рантайме вычислять из индекса адрес элемента массива, если его можно вычислить на этапе компиляции? Так что, приводите листинг вашего варианта - будем посмотреть. - VladislavS.(02.05.2022 17:31)
      - По-вашему, наверное как-то так: Costic(209 знак., 02.05.2022 20:59, ссылка)
        
        Даже проверять не буду. Кода будет стопудово больше. Надо загрузить адрес начала массива, загрузить адрес текущего индекса, загрузить сам индекс и сложить их. Вместо того чтобы загрузить сразу указатель. Желание на 32-битной системе сэкономить на разрядности переменной улыбает - обычно эффект обратный получается. Кстати, Cortex-M0 не умеет невыровненный доступ к памяти. Если вы сделаете упакованную структуру с малоразрядным индексом, то получите вместо экономии VladislavS.(146 знак., 02.05.2022 21:56)
        
        Чушь. Вы грузите свой 32-битный указатель, у которого старшие 16+ битов всегда одни и те же. Т.е. впустую гоняете данные из медленной флеш. В моем варианте загружается только смещение (младшие 16 бит). О выравнивании структуры пусть компилятор заботится. короче, демагогия. - Costic(02.05.2022 23:18)
        
        Компилятор как раз таки позаботится о выравнивании и будет ваши 16 бит гонять в 32-битных словах. А если вы ему выкрутите руки и упакуете структуры, то будет побайтово их читать, ибо не умеет контроллер невыровненный доступ. Збсь такая "экономия". Адресация 32-битная, а значит к вашим 16 младшим битам нужно подгрузить и прибавить старшие вместо того чтобы одним чтением загрузить сразу указатель. И нет никакой проблемы с пропускной способностью флэша в современных VladislavS.(187 знак., 02.05.2022 23:57)
        
        Посмотрел таки что получится. Всё с точностью как я и писал. Вместо экономии лишнее чтение адреса начала массива и вычисления адреса элемента массива в рантайме. Скучно. А потом из любопытства упаковал структуру. Вот тут то веселуха и пошла: VladislavS.(2577 знак., 03.05.2022 01:19)
- Ирония судьбы в том, что загрузить заготовленную заранее переменную в прерывании это то же самое что выбрать по заранее заготовленному указателю из массива. В смысле равномерности. Смотрим листинги, не ленимся. Шах и мат. - VladislavS.(01.05.2022 11:45)

Средства и методы разработки