[Arlleex 188]

19 минут назад, jcxz сказал:

При желании - можно сделать на двух сцепленных аппаратно 32-битных таймерах. С простой процедурой чтения 64-битного значения, состоящей из 3 чтений счётчиков и одного сравнения с возвратом (циклическим).

Тут я исхожу только лишь из предположения, что автору нужен таймер ядра (т.е. по аналогии с SysTick в Cortex-M), к которому будет доступ "здесь и сейчас", минуя лес периферийных шин и зависимостей

[repstosw 18]

Just now, Arlleex said:

Тут я исхожу только лишь из предположения, что автору нужен таймер ядра (т.е. по аналогии с SysTick в Cortex-M), к которому будет доступ "здесь и сейчас", минуя лес периферийных шин и зависимостей

К счастью всё проще.   Задержка нужна в одном потоке и более нигде не нужна.😀

[Arlleex 188]

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

К счастью всё проще.   Задержка нужна в одном потоке и более нигде не нужна.😀

Тогда, раз уж нужно всего лишь 100 мкс, выкинуть 64-битные хотелки и сделать на разрядности атомарного доступа к таймеру - 32 бита, я так понял.

Примерно вот так

u32 getTimer(void) {
  return TIMER->CNT;
}

...

void process(void) {
  static u32 oldTickCnt = 0;
  
  while (getTimer() - oldTickCnt < 60000);
}

[repstosw 18]

22 minutes ago, Arlleex said:

void process(void) {
  static u32 oldTickCnt = 0;
  
  while (getTimer() - oldTickCnt < 60000);
}

Что будет при переполнении таймера?  Задержка корректно отработает?

Изменено 25 октября, 2023 пользователем repstosw

[jcxz 242]

39 минут назад, repstosw сказал:

Там есть прерывание по достижению конкретного значения. Можно инкрементировать переменную в обработчике.  Но это более ресурсоёмко, по сравнению с чтением одного волатильного регистра.  Делителя к сожалению нет, так как это счётчик тактов ядра.

А аппаратная сцепка таймеров есть? Чтобы 2-й считал события переполнения первого.

[Arlleex 188]

9 минут назад, repstosw сказал:

Что будет при переполнении таймера?  Задержка корректно отработает?

Корректно, если таймер 32-битный, считает от 0 до 0xFFFFFFFF, затем оборачивается снова в 0.

[jcxz 242]

47 минут назад, repstosw сказал:

P.S.  Кстати, вопрос всем.   Кто-нибудь  пробовал вместо прерываний IRQ  задействовать FIQ ?

Конечно. В обязательном порядке. На ARM7 и на ARM9 - везде использовал.

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

Что будет при переполнении таймера?  Задержка корректно отработает?

Конечно. Почему нет? Если длительность задержки меньше периода таймера.

Но писать лучше:

while (getTimer() - oldTickCnt < 60000u);

иначе возможны проблемы на больших задержках.

[repstosw 18]

14 minutes ago, jcxz said:

А аппаратная сцепка таймеров есть? Чтобы 2-й считал события переполнения первого.

Скорее всего нет.

15 minutes ago, Arlleex said:

Корректно, если таймер 32-битный, считает от 0 до 0xFFFFFFFF, затем оборачивается снова в 0.

Это хорошо 🙂

 

[Arlleex 188]

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

Но писать лучше:

while (getTimer() - oldTickCnt < 60000u);

иначе возможны проблемы на больших задержках.

Типы getTimer() и oldTickCnt итак u32, поэтому константу можно не приводить принудительно - компилятор обработает ее как unsigned int.

[repstosw 18]

Номер внешнего прерывания для USB OTG со стороны DSP: 18 (18-й бит в регистрах: pintc_regs->mask, pintc_regs->enable )

#define USB_INTC_SOURCE   18

 

Изменено 29 октября, 2023 пользователем repstosw

[repstosw 18]

В 13-м GCC под ARM начали заниматься вредительством:  https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

1. тупые и ненужные предупреждения, которых не было в 10.3

2. эффективность работы программ стала меньше.

Замеры GCC v.10.3:

T113-s3 CPU ===> Encode: 31.38 FPS   Decode: 14.41 FPS
T113-s3 CPU ===> Encode: 31.37 FPS   Decode: 14.42 FPS
T113-s3 CPU ===> Encode: 31.39 FPS   Decode: 14.41 FPS
T113-s3 CPU ===> Encode: 31.37 FPS   Decode: 14.42 FPS
T113-s3 CPU ===> Encode: 31.37 FPS   Decode: 14.40 FPS

Замеры GCC v.13:

T113-s3 CPU ===> Encode: 31.47 FPS   Decode: 13.29 FPS
T113-s3 CPU ===> Encode: 31.47 FPS   Decode: 13.30 FPS
T113-s3 CPU ===> Encode: 31.47 FPS   Decode: 13.30 FPS
T113-s3 CPU ===> Encode: 31.47 FPS   Decode: 13.30 FPS
T113-s3 CPU ===> Encode: 31.47 FPS   Decode: 13.29 FPS

Ну и ботва, которой нет в v.10.3:

 

Остаюсь на v.10.3

Изменено 30 октября, 2023 пользователем repstosw

[repstosw 18]

Проверил несколько тулчейнов GCC под ARM:  версии 7.3, 9.3, 10.3, 11.3, 12,3, 13.3

Самые быстрыми оказались -  9.3 и 10.3.  Остальное по-медленее.

Начиная с 12.3 компилируется в 4 раза дольше, чем в 10.3. Что они там валидируют - Х.З.

Пробовал ARMCC и IAR ARM.  - у этих скорость вообще в 1,5 раза просела (при этом включена High Speed оптимизация, у IAR пробовал убрать loop unroll и добавить vectorization - получилось только хуже )

[sasamy 0]

On 9/18/2023 at 3:36 PM, repstosw said:

На CPU  быстрее:

Encode: 26.2 FPS   Decode: 12.4 FPS
Encode: 26.2 FPS   Decode: 12.2 FPS
Encode: 26.2 FPS   Decode: 12.3 FPS

на Linux быстрей работает

Quote

bsize: 5952, fsize: 4784
Encode: 32 FPS   Decode: 14 FPS
Encode: 32 FPS   Decode: 15 FPS
Encode: 32 FPS   Decode: 15 FPS

Quote

arm-none-linux-gnueabihf-gcc -O3 -DUSE_JPWL FEC.c main.c rs.c -o fec

// AVS_CNT0_REG=0;
 clock_gettime(CLOCK_MONOTONIC, &start);
 FEC_Encode((u16*)data);
// t=AVS_CNT0_REG;
 clock_gettime(CLOCK_MONOTONIC, &end);
 printf("Encode: %d FPS   ", 1000000000L / (end.tv_nsec - start.tv_nsec)); //"%llu\n"

 

[mantech 53]

27 минут назад, sasamy сказал:

на Linux быстрей работает

Может компилятор другой версии и другие флаги? 

Изменено 8 ноября, 2023 пользователем mantech

[sasamy 0]

On 11/8/2023 at 12:04 PM, mantech said:

Может компилятор другой версии и другие флаги? 

компилятор с сайта arm только для Linux а не бареметал

arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621

надо будет потом попробовать свой собрать в буилдрут  может ещё быстрей будет