Портирование FreeModbus 1.5 под STM32 HAL rs485 без RTOS

Отличная статья! Очень наглядно и доступно.
А можно ли применять STM32CubeMX для генерации кода для камней STM32 F0 и F1?

Похоже каждый уважающий себя Программист написал свой вариант модбаса на стм32!)))

как по мне хуарт так называется неспроста. его использование во многих случаях чрезмерно. единственное что есть переносимость с f0 на другие кристаллы вплоть до л4. хотя я не вижу ничего страшного в правке имен пары регистров для настройки, а вот висеть столько в прерывание — не камильфо. имхо далеко не лушая реализация поставленной перед ТС задачи.

Благодарю за статью. Мне как раз предстоит в ближайшем будущем реализовывать поддержку Modbus/RTU.

Только я не вижу обработки интервалов. Их нет вообще или просто Вы не включили их в статью? Я имею в виду межсимвольный интервал t1.5 и межпакетный интервал t3.5 (по оф. терминологии).

Я хочу сделать следующим образом. Согласно документации, интервалы таковы:

19200 бод и ниже: t1.5 = 1.5 char = 3 x 0.5 char; t.3.5 = 3.5 char = 7 x 0.5 char;
19200 бод и выше: t1.5 = 750 мкс = 3 x 250 мкс; t3.5 = 1750 мкс = 7 x 250 мкс.

Т.о. таймер программируется на t0.5 (по моей терминологии). Прикинул, что значение Prescaler = 125(-1) будет оптимальным. Оно позволяет получить целочисленное значение Period, а также единую формулу вычисления для различных камней/частот и скоростей обмена.

Понадобятся 2 счётчика:

счётчик повторений, c_rep — количество срабатываний таймера;
счётчик «ошибок», c_err — количество «косых» фреймов.

При получении байта счётчик c_rep сбрасывается. Когда c_rep == 3, счётчик c_err увеличивается. Т.о. если c_rep == 7, то пакет получен. При этом, если c_err == 1, то пакет целый, в противном случае — битый.

Поскольку я далеко не профи в данной области, прошу прокомментировать мой [пока] чисто умозрительный подход.

Вот теперь Вы поняли, почему многие так любят Ардуино?

По поводу костыля. Вы обрабатываете событие TXE передатчика, поэтому линия DE деактивируется в момент начала передачи последнего байта, а не тогда, когда этот байт уже целиком «выдвинется». Поэтому либо Ваш костыль, либо после записи последнего байта нужно ждать события TC (transmission complete).

Далее нас интересуют макросы ENTER_CRITICAL_SECTION( ) и EXIT_CRITICAL_SECTION( ). Заменяем их на __disable_irq() и __enable_irq() соответственно.

С таким можно отгрести, если произойдёт вложенный вызов. У меня (Bare-metal ARM926E-JS, правда ещё ThreadX есть, но временами и прерывания гасить нужно) сделано с сохранением прерывания и при выходе из критической секции восстанавливается исходное. Т.е. если оно было и так выключено — оно выключенным и останется:

// Declare interrupt save area
#define INTR_SAVE_AREA unsigned int _interrupt_save, _interrupt_temp

// Disable iterrupts and save old status register
#define INTR_DISABLE __asm volatile (\
    "mrs %0, CPSR\n\t" \
    "orr %1, %0, #128\n\t" \
    "msr CPSR_c, %1" \
    : "=r"(_interrupt_save), "=r"(_interrupt_temp) /* output  */ \
    : /* input   */ \
    : /* clobber */ \
    )

// Restore status register
#define INTR_RESTORE __asm volatile (\
    "msr CPSR_c, %0" \
    : /* output  */ \
    : "r"(_interrupt_save)/* input   */ \
    : /* clobber */ \
    )

В вашем случае нужно совместить INTR_SAVE_AREA и INTR_DISABLE. Правда как оно будет выглядеть без C99 (при объявлении переменной не в начале функции) и при наличии goto — нужно думать.

Кстати, попытался поискать как используются эти вызовы и наткнулся: http://we.easyelectronics.ru/Yanichar/portiruem-freemodbus-rtu-na-primere-stm8l.html, в прочем вышеописанная проблема там тоже присутствует, на что так же указали в комментарии.

Вот ещё описание портирования: http://ctrl-v.biz/blog/6 — на STM32F4 (плата STM32F4Discovery). Похоже, что всё изобретено до нас :)