Кто любит RISC в жизни, заходим, не стесняемся.
Чт апр 15, 2021 23:15:43
а как сделать задержку таймером базовым?
Элементарно. Вот так можно сделать паузу примерно на SCREEN_PAUSE миллисекунд в конечном автомате:
- Код:
case SCREEN_WAIT: // wait
if(Tms - Tscr_last > SCREEN_PAUSE){
//USB_send("Pause ends\n");
ScrnState = SCREEN_UPDATENXT;
}
А переменная Tms глобальная:
- Код:
volatile uint32_t Tms = 0;
void sys_tick_handler(void){
++Tms;
}
И вообще, блокирующие паузы нельзя делать нигде, кроме инициализации. Особенно если эти паузы больше, чем на пару-тройку тактов ядра! А уж блокирующие паузы по полсекунды, как тупые абдуринщики делают, так вообще нонсенс!
Сб апр 17, 2021 00:55:45
Уже задержку в 3 такта ядра делают на КА, которые отожрут на порядок (а то и не один) больше времени.
Веселуха ...
Сб апр 17, 2021 03:24:25
LCD какой? О каких задержках идёт речь? мкс, мс? Я с AVR работаю, потому приведу пример, как я делаю на них. К примеру, берём символьный дисплей. Самые большие задержки это после включения питания перед инициализацией дисплея. Кажется, 40 мс. И после команды Clear_display нужно выдержать 20 мс. Все остальное идёт в мкс. Также определённая задержка должна быть после каждой отправки команды или данных.
У меня реализовано так. Флаг готовности я не проверяю. То есть, дисплей работает только на запись. Пусть дисплей 20х4. Создаётся буфер 80 байтов. Алгоритм функции работы с дисплеем у меня сделан на конечном автомате. Сначала задержка 40 мс, инициализация дисплея. Затем, в зависимости от состояния автомата, каждую миллисекунду отправляется либо по индексу счётчика строки считывается адрес начала строки, либо отправляются данные из буфера строки. Задержки для работы с дисплеем на мкс сделаны тупо на nop-ах. АРМ пошустрее работают, так что делайте простые задержки. Типа delay_us.