Простая реализация Модбас-стека на MSP430. Часть вторая: Библиотека

Продолжаю тему работы простых МК-устройств с Модбасом. В предыдущей части я кратко описал сам Модбас, тот вариант работы, который я использую (RTU), а также свои подходы к реализации протокола у Слейва. Тепер я хочу рассказать об очень простой, но вполне рабочей библиотеке, написанной на Си, а потому годной не только для моего любимого MSP430FR57xx семейства.
А вот здесь — улучшеный вариант библиотеки.
Напомню, реализован Modbus RTU по последовательному протоколу RS-485.
Итак, программа создана в виде статической библиотеки и состоит из 5 файлов:

MB_header.h — дефайны из driverlib MSP430, дефайны Модбаса, несколько перечислений ENUM и простых макросов. При портировании сюда зайти обязательно, ясен перец.
MB_entries.c — для простоты и понятности создал 2 функции, к которым и обращаются внешние программы. Портируется без правок, здесь ничего аппаратно-зависимого.
MB_hardware.c — здесь 2 функции инициализации 3-х периферийных модулей: таймера, УАРТа и 3 битов порта (RxD, TxD и направление драйвера шины RS-485, сигнал, который я называю RTS). Конечно, это очень платформо-зависимый файл
MB_interrupts.c — собственно, подпрограммы отработки прерываний (ISR) от таймера и УАРТа. Несмотря на то, что оформление ISR традиционно скачет от компилятора к компилятору, сами процедуры править при портировании на другие МК нет необходимости.
MB_parsing.c — главная функция разбора запроса от Мастера (и подготовки ответа, разумеется), а также несколько ее помощников, включая вычислителя CRC.

По сути, вся работа идет в прерываниях и немножко в парсинге. Как же организована эта работа? Сам собой просится конечный автомат, машина состояний, фазовый автомат — кто как любит называть. Основой этого автомата является переменная MB_state, принимающая перечисленные значения:

typedef enum {
    STATE_IDLE,  /* Ready to get a frame from Master           */
    STATE_RCVE,  /* Frame is being received                    */
    STATE_PARS,  /* Frame is being parsed (may take some time) */
    STATE_SEND,  /* Response frame is being sent               */
    STATE_SENT   /* Last byte sent to shift register           */
} eMBState;

В исходном состоянии автомат готов принять первый символ от Мастера, после чего записывает этот символ в начало приемного буфера uint8_t MBBuff[] и сразу же переходит в фазу приема RCVE. В этой фазе автомат находится до тех пор, пока символы идут сплошной чередой, даже если информация в них — полная чушь. Наше дело — принимать и ждать конца фрейма. Как только возникнет разрыв между символами, больший t3.5 (длительность передачи 3,5 символов) — автомат переходит в фазу разбора фрейма PARS.
Парсинг заканчивается сам по себе, без внешних событий. На моем неспешном 7-мегагерцовом МК она может выполняться, скажем, 300-400 мкс. Это «искусственная» фаза, но удобная для понимания и отладки программы.
В ходе парсинга выявляется один момент, существенный для фазовых переходов: будем слать ответ или ну его… Отсутствие ответа — это и плохой фрейм (например, разрыв в принимаемых символах, больший t1.5), и адресация запроса не нам, и широковещательный запрос. В любом случае, следующей фазой будет IDLE, ибо ждать t3.5 просто незачем — мы же только что его поймали.
Если же отвечать придется, то из парсинга переходим в фазу передачи SEND. При этом парсер бросает в передатчик первый символ, переключает микросхему драйвера шины на передачу, а уж дальше все проходит в прерываних. Там же, в очередном прерывании, обнаруживается, что послан последний символ. И там же ставится фаза SENT, короткая, всего лишь ожидание последнего вытолкнутого в линию бита. По прерыванию от УАРТа «Сдвиговый регистр пуст» драйвер шины переключается на прием и автомат переходит в фазу ожидания IDLE.

Работа с фазами непосредственно в прерываниях позволила получить простой код, к тому же, не требующий большого быстродействия МК или пристального внимания к работе Модбас-стека. Фактически, из основной программы следует один раз вызвать функцию MB_HW_init(), а затем в цикле вызывать MB_serve(). Как часто? Нечасто. Все переходы фазового автомата происходят в прерываниях, пропуска события при приеме и передаче не будет. Единственное — парсинг принятой команды запускается при очередном вызове из главной петли функции MB_serve(). Поэтому и формирование ответа Мастеру будет зависеть от того, как часто эта фунция вызывается. В моем девайсе это максимум 1...2 мс, но даже какой-то неспешный девайс редко крутится с периодом больше пары десятков миллисекунд. За это время Мастер не махнет рукой на больного Слейва.
Есть еще более быстрый вариант: не выходить за пределы прерываний вообще. В чем суть: впихнуть функцию MB_Parsing() прямо в прерывание таймера, в котором стало ясно, что пора переходить к парсингу:

__interrupt void TIMER1_A0_ISR_HOOK(void) {   // t3.5 hunting
  if( STATE_RCVE == MBState) {                // It`s the end event: t3.5
    SET_ST(STATE_PARS);                       // Begin parsing of a frame
    STOP_TIMER;
    MBParsing();   // Д О Б А В Л Е Н А Я   С Т Р О К А
  }
}

Здесь я добавил вызов парсинга (компилятор, если он не дурак, предупредит, что это не есть гут) там, где фаза становится PARS. И все, ребята! Достаточно теперь в главной программе произвести инициализацию Модбас-стека, как он начнет сам следить за линией, принимать, отвечать — и все это асинхронно к работе основной программы. Очень интересный вариант, но я его не использую: во-первых, некуда спешить, во-вторых, нужно побеспокоиться о правильном обращении к регистрам со стороны главной программы и Модбас-стека. Фокусы могут быть при изменении части переменной…

Замечание по использованию библиотеки
Приведенные в приложении файлы можно использовать для наскальной росписи, как основу для создания своих вариантов, но можно и как готовую библиотеку. Каковы связи с основной программой и с «железом»:

1) Используется таймер, УАРТ и 3 вывода МК (или 2, если работать с RS-232). Они должны быть инициализированы:
— таймер нужно настроить на генерацию прерывания через 3,5 символа после его запуска (формула расчета видна в инициализации массива Nt35[], файл MB_hardware.c), а также иметь возможность читать его текущее состояние, чтобы отловить пробел 1,5 символа;
— УАРТ настраивается по стандартным требованиям Модбаса, они видны в тексте функции MBUART_init();
— порты RxD и TxD могут становиться таковыми при инициализации УАРТа, а могут (как в MSP430) требовать отдельной инициализации — как вторичная альтернативная функция порта. Кстати, удивился, обнаружив, что порт RxD принимает линию даже если его забыть переключить в альтернативную функцию! Ну, это подробности моего ФРАМ МК.

2) Частота тактирования таймера и УАРТа получается из какого-то генератора, поэтому в файл MB_header.h нужно внести информацию о частоте тактирования.

3) При инициализации Модбас-стеку передаются параметры:
— baudrate_code и IDcode — коды скорости работы и адреса Слейва в системе. Эти коды служат индексами для выборки из таблиц, поэтому можно сделать их и не 2-битовыми (как у меня), а любой размерности- только таблицы правьте;
— regsinp и regsout — указатели на начало двух массивов регистров, работающих с Модбасом. У меня их 2 для того, чтобы с одним работать (и из него Мастер получает данные, если делает запрос чтения), а в другой принимать данные от Мастера — и иметь возможность либо акцептировать данные, либо отказаться от них. Соответствующее уведомление Мастеру никак не оговорено в стандарте, но я использую один из регистров как Статус — в нем и поднимаю флажок, ежели что. Пусть Мастер читает и знает, что мы тут тоже не лыком шиты, можем и послать…
— regsnumb — размер массивов регистров (одинаковый для обоих массивов)
Собственно вот часть главной программы:

#define	FQUARZ_HZ	7372800UL
#define	REGISTERS	25		

void vInit(void);
extern void MB_HW_init( uint16_t, uint16_t, uint16_t*, uint16_t*, uint16_t);
extern void MB_serve( void);

uint16_t	ParsWk[REGISTERS];
uint16_t	ParsIn[REGISTERS];

int
main(void) {
	uint16_t	BR_code, ID_code;
 	vInit();
    BR_code  = CHK_PIN( BR0_PORT, BR0_PIN)? 1:0;
    BR_code |= CHK_PIN( BR1_PORT, BR1_PIN)? 2:0;
	ID_code  = CHK_PIN( SLVID0_PORT, SLVID0_PIN)? 1:0;
	ID_code |= CHK_PIN( SLVID1_PORT, SLVID1_PIN)? 2:0;

 	MB_HW_init( BR_code, ID_code, ParsIn, ParsWk, REGISTERS);
    __bis_SR_register(GIE);

    do {
    	MB_serve();
    } while( 1);
}

4) Я добавил (спасибо коллеге Lagman) вариант работы без прерывания по приему первого бита посылки. Такое прерывание есть у «моего» МСП430, но в той же Атмеге168 — увы. Поэтому я просто поставил директиву условной компиляции NO_06_INTERRUPT — и если это дефинировать, то Атмега сможет работать;

5) В макросе SET_ST(s) я оставил закомментированный вывод кода текущей фазы на 3 порта. Собственно, и весь макрос для этого создан. Желающие могут открыть комментарии, использовав те средства визуализации, которые им доступны. Очень красиво наблюдать смену фаз:


Слева имеем фазу 000 — это IDLE. Когда принят первый символ, код фазы становится 001 — это RCVE. Кстати, это картинка с включенным NO_06_INTERRUPT, поэтому переход в прием происходит в конце первого символа, а не в его начале.
Через 1780 мкс после приема последнего импульса видим код фазы 010 — это PARS. И продолжается парсинг и подготовка ответа около 340 мкс (короткий нулевой импульс в самом нижнем сигнале). А потом идет код 011 — это передача, SEND. Короткий импульс длиной 260 мкс — фаза SENT, когда ждем сигнала на разворот драйвера шины на прием. Спасибо коллеге reptile за ЛА!

6) CRC. Эх, братцы, жаль, что в MSP430FR57xx модуль CRC имеет другой полином! Пришлось взять известную (она приведена прямо в описании Модбаса) функцию с таблицами. Конечно, желающие могут легко ее заменить, секономив 512 байт флеша.

Прилагаю 2 архива: один с файлами библиотеки, второй — с простой вызывающей оболочкой, в которой желающие могут посмотреть мою реализацию работы с портами МК (файл pins.h с кучей макросов). Все вместе компилится CCS от TI и результирующая программа весело отвечает на запросы Мастера нулевыми значениями регистров :)