#define DELAY(CY), Как задать выбор вариантов определения? Опции

[ViKo]

Конкретно, хочу, чтобы
DELAY(1) превратилось в
__nop()
DELAY(2)
__nop();
__nop()
...
DELAY(20)
for(uint32_t i = 4; i--; ) __nop()
Варианты найдутся. Вопрос, как их задать в одном макроопределении?

[ViKo]

Чтобы не было зависимости от уровня оптимизации напишите асмовую вставку.

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

Угу. Вместо последнего цикла. А потом вспомнить про прерывания и забить на эту погрешность.

Да, прерывания меня уже смутили, при проверке на больших длительностях. Но эта функция написана для коротких интервалов. Конкретно, для работы с двухстрочным ЖКИ. А для "серьезных" задержек у меня есть макро с таймером. И др.

Что-то "не лезет" asm, не принимает его компилятор! В чем дело?

Код

#define DELAY_CY(CY)    \
  if (CY >= 10)        \
    { __asm {"MOVS R1,#CY; LOOP: SUBS R1,R1,#1; BEQ LOOP;"} }

(407): error: #2901: Expected an inline assembly instruction
(407): error: #3081: expected end of line or a ";"
Никак.

Из ARM документа:
The inline assembler supports ARM assembly language only.
The embedded assembler can be used for Thumb and Thumb-2 support.

Отдельно писать?

Код

void DelAsm(uint32_t CY)
{
  uint32_t Reg;
__asm {
  MOVS Reg, #CY
  LOOP:
  SUBS Reg, Reg, #1
  BEQ LOOP
  }
}

[Леонид Иванович]

Конкретно, для работы с двухстрочным ЖКИ.

А я для таких целей использую функции микросекундных задержек, которая пользуется таймером SysTick, не мешая ему выполнять свою основную функцию - генерирование системного интервала 1 мс:

Код

void TSysTimer::Delay_us(uint16_t d)
{
  uint32_t DelayStart = SysTick->VAL;
  uint32_t DelayTicks = d * CLK_PER_US;
  int32_t  Delta;
  do
  {
    Delta = DelayStart - SysTick->VAL;
    if(Delta < 0) Delta += CLK_PER_MS;
  }
  while(Delta < DelayTicks);
}

[ViKo]

А я для таких целей использую функции микросекундных задержек, которая пользуется таймером SysTick, не мешая ему выполнять свою основную функцию - генерирование системного интервала 1 мс

Годится, но только для интервалов короче 1 мс.
А для этого ЖКИ есть интервалы и по 30 мс. (Вообще, темный лепс, скачал несколько datasheet-ов на разные ЖКИ, есть такие странные процедуры установки режимов...)

[toweroff]

Годится, но только для интервалов короче 1 мс.
А для этого ЖКИ есть интервалы и по 30 мс. (Вообще, темный лепс, скачал несколько datasheet-ов на разные ЖКИ, есть такие странные процедуры установки режимов...)

а у него нет никакого флага BUSY? чтобы не городить с задержками, а когда можно флаг опросить и дальше работать

[ViKo]

а у него нет никакого флага BUSY? чтобы не городить с задержками, а когда можно флаг опросить и дальше работать

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

[toweroff]

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

ок, можно отдать SysTick генерить все управляющие сигналы по стэйт-машине некой, а из него уже отсылать программный сигнал (или просто флаг) ждущей задаче
я так понимаю, этот таймер все равно по микросекундам генерится?

[ViKo]

ок, можно отдать SysTick генерить все управляющие сигналы по стэйт-машине некой, а из него уже отсылать программный сигнал (или просто флаг) ждущей задаче
я так понимаю, этот таймер все равно по микросекундам генерится?

У меня задержка считается в ns. С точностью до такта микроконтроллера. SysTick Timer считает такты (или поделенные на 8) до 1-10 ms для RTOS (и у меня тоже есть), потом перезагружается. Поэтому более длинные интервалы не получить.
Можно большие задержки считать одним способом, а малые другим. А можно все одним.

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

Так уж в три...? Задержка занимает у меня от 3 до 6 ассемблерных команд. Куда уж проще? И выполняется именно столько времени, сколько мне нужно.
Там же все обращения к контроллеру ЖКИ идут ногодрыгом, без задержек - никак не обойтись.
А для выполнения ЖКИ команд нужны задержки побольше. Зачем мне терять время, если не проверять, когда они закончатся, а тупо ждать больше срока?

[Сергей Борщ]

Так уж в три...? Задержка занимает у меня от 3 до 6 ассемблерных команд. Куда уж проще?

Выкинуть чение Busy, дав задержки на выполнение команд дисплеем вдвое от максимальных в даташите (50мкс на все команды кроме очистки экрана, на нее 2мс или вообще не использовать). Уже только избавление он необходимости переключать порт на ввод и анализивровать Busy сводит все управление дисплеем к трем примитивнейшим функциям:

Код

void hd44780::write_tetrade(uint8_t tetrade)    // assume data in upper tetrade, lower tetrade is all zeros
{
    ON(LCD_EN);
    LCD_PORT = (LCD_PORT & 0x0F) | tetrade;
    _delay_us(1);
    OFF(LCD_EN);
    _delay_us(1);
}

void hd44780::write_data(uint8_t byte)
{
    write_tetrade(byte & 0xF0);
    write_tetrade(byte << 4);
    _delay_us(50);
    ON(LCD_RS);
}

void hd44780::write_command(uint8_t command)
{
    OFF(LCD_RS);
    write_data(command);
}

Сравните со своим ногодрыгом с чтением Busy.

Ну хорошо, еще инициализация:

Код

inline hd44780::hd44780()
{
    OFF(LCD_RS);
    _delay_ms(200);
    write_tetrade(3 << 4);      // set 8-bit mode
    _delay_ms(50);
    write_tetrade(3 << 4);      // set 8-bit mode again
    _delay_ms(50);
    write_tetrade(3 << 4);      // set 8-bit mode again, see http://electronix.ru/forum/index.php?s=&showtopic=19594&view=findpost&p=143374
    _delay_us(50);              // delay slightly longer than typical command execution time.
    write_tetrade(2 << 4);      // set 4-bit mode
    _delay_us(50);
    write_command(CURSOR_HOME);
    _delay_ms(2);
    write_command(0x06);        // increment cursor position during data write, disable display shift
    write_command(CURSOR_OFF);
}

а тупо ждать больше срока?

А вы и так "тупо ждете больше срока" потому что в вашу задержку вклиниваются прерывания. Вывод на дисплей происходит так редко, что будет там задержка 50мкс или 20мкс на байт не заметит никто. Ну пусть у вас дисплей 4*40, пусть обновляете его целиком 4 раза в секунду (быстрее он не успеет отобразить, а оператор воспринять), ну потеряете вы лишних (50-20)*40*4*4=19200 мкс. Ах, 19мс каждую секунду ушло впустую, катастрофа. Зато сэкономлена неделя рабочего времени, за которую эти 19мс можно с большей пользой отыграть где-то в другом месте.

[ViKo]

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

Зато я могу посылать в ЖКИ символы, когда захочу. Совсем не обязательно "тупо ждать" задержку или флаг Busy, можно заняться чем-нибудь общественно-полезным между выводами, не опасаясь "уже можно посылать, или еще подождать?".

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

[demiurg_spb]

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

Это не нюанс, это стандартное поведение.
Для решения подобных задач нужно всё в заголовочном файле размещать:

Код

static __inline void delay(int x)
{
    ....
}

не панацея, конечно, но позволит уйти от асма, тем более что точная задержка как таковая не критична прям уж так

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

Тут у меня самого возник вопрос, касательно задержек в gcc.
Вот такой код упорно приводит проект в нерабочее состояние:

Код

#define delay_4cycles(cy)                \
(__extension__({                         \
    uint32_t __x = (uint32_t)(cy);       \
    __asm__ __volatile__                 \
    (                                    \
        "loop%=: subs %[cnt],#1"  "\n\t" \
        "        bne  loop%="     "\n\t" \
        :                                \
        : [cnt]"r"(__x)                  \
        : "cc"                           \
    );                                   \
}))

for(;;)
{
    delay_4cycles(1);
    pin_toggle(LED_RED);
}

А именно не производится перезагрузка счётчика цикла внутри цикла for.
В данном примере 1 загружается в регистр единожды перед циклом for, что собственно является нежелательным поведением:

Код

8001df6:    f04f 0001     mov.w    r0, #1
...
8001e0a:    3801          subs    r0, #1
8001e0c:    d1fd          bne.n    8001e0a
8001e0e:    682b          ldr    r3, [r5, #0]
8001e10:    ea6f 0703     mvn.w    r7, r3
8001e14:    6037          str    r7, [r6, #0]
8001e16:    e7f8          b.n    8001e0a

А без использования асм всё нормально:

Код

8001e04:    bf00          nop
8001e06:    bf00          nop
8001e08:    bf00          nop
8001e0a:    bf00          nop
8001e0c:    6806          ldr    r6, [r0, #0]
8001e0e:    ea6f 0306     mvn.w    r3, r6
8001e12:    602b          str    r3, [r5, #0]
8001e14:    e7f6          b.n    8001e04

Прошу помощи у аудитории!

arm-none-eabi-gcc.EXE (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-131005) 4.7.4 20130913 (prerelease)
CFLAGS += -flto
CFLAGS += -fomit-frame-pointer
CFLAGS += -falign-functions=16
CFLAGS += -fgraphite
CFLAGS += -funroll-loops
CFLAGS += -ffunction-sections
CFLAGS += -fdata-sections
CFLAGS += -O3
#CFLAGS += -O1

[Сергей Борщ]

Прошу помощи у аудитории!

cnt у вас меняется в асм-вставке, а компилятору вы об этом не сообщаете.
Попробуйте так, если в синтаксисе не ошибся:

Код

    __asm__ __volatile__                 \
    (                                    \
        "loop%=: subs %[cnt],#1"  "\n\t" \
        "        bne  loop%="     "\n\t" \
        : =[cnt]"r"(__x)                 \
        :                   \
        : "cc"                           \
    );                                   \

[demiurg_spb]

cnt у вас меняется в асм-вставке, а компилятору вы об этом не сообщаете.

Согласно доке и не должен я об этом ничего сообщать.
Вы предлагаете использовать cnt как выходной write only регистр:

Код

#define delay_4cycles(cy)                \
(__extension__({                         \
    uint32_t __x = (uint32_t)(cy);       \
    __asm__ __volatile__                 \
    (                                    \
        "loop%=: subs %[cnt],#1"  "\n\t" \
        "        bne  loop%="     "\n\t" \
        : [cnt]"=r"(__x)                 \
        :                                \
        : "cc"                           \
    );                                   \
}))

что на мой взгляд несколько неверно, т.к. компилятор его вообще перестал инициализировать:

Код

8001e06:    3b01          subs    r3, #1
8001e08:    d1fd          bne.n    8001e06 <loop3411>
8001e0a:    6806          ldr    r6, [r0, #0]
8001e0c:    ea6f 0306     mvn.w    r3, r6
8001e10:    602b          str    r3, [r5, #0]
8001e12:    e7f8          b.n    8001e06 <loop3411>

На мой взгляд cnt - это input, а не output операнд (кстати =&r даёт такой же результат).