Использование FreeModbus версии V1.6 для хоста

1. Краткое описание

FreeModbus — это открытый исходный код протокола Modbus, но только для ведомых устройств. Исходный код для хост-части является платным. В интернете также не найдено хорошей открытой хост-версии Modbus. Поэтому была разработана поддерживающая режим хоста версия FreeModbus. Версия FreeModbus изменена на V1.6 и имеет следующие характеристики:

• Добавлен новый исходный код хоста, который соответствует стилю и интерфейсу существующей ведомой части;
• Поддерживает работу ведомого и хоста в одном стеке протоколов;
• Поддержка операционных систем реального времени и переносов на «голое железо»;
• Предоставляет различные режимы запросов для приложений, позволяя пользователям выбирать между блокирующими и неблокирующими режимами, настраивать таймауты и т. д., что делает вызов прикладного уровня более гибким;
• Поддерживаются все распространённые методы Modbus.

1.1 Структура файлов

Примечание: Все файлы с суффиксом _m являются обязательными для использования в режиме хоста.

2. Перенос

Перенос протокола включает в себя две части: аппаратное обеспечение и программное обеспечение. Пользователи могут выбрать в соответствии со своими потребностями.

Примечание: Следующее описание в основном относится к режиму хоста FreeModbus.

2.1 Программное обеспечение

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

2.1.1 Операционные системы и «голая» система

В настоящее время протокол поддерживает операционные системы, включая RT-Thread (подробности см. в исходном коде проекта), UCOS и FreeRTOS. При переносе операционной системы и «голой» системы задействованы файлы FreeModbus\port\portevent_m.c. Этот файл содержит следующие обратные вызовы, которые необходимо перенести:

При переносе на операционную систему в основном используются технологии синхронизации потоков, связанные с событиями операционной системы. Протоколу Modbus требуется использовать механизм событий операционной системы для реализации уведомлений о событиях и ожидании получения. Потоки Modbus и Modbus Poll должны синхронизироваться через механизм событий. Хосту также нужен сигнал для управления использованием ресурсов, инициализированный по умолчанию как 1, и используется семафор для обеспечения того, чтобы только один поток мог использовать хост при одновременной отправке нескольких запросов хоста.

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

2.1.2 Буфер данных

Определение буфера данных находится в верхней части файла FreeModbus\port\user_mb_app_m.c, всего существует 4 типа буферов данных. По умолчанию FreeModbus использует одномерный массив в качестве структуры данных буфера для ведомого устройства. Хост может хранить данные всех ведомых узлов в сети, поэтому хост использует двумерный массив для хранения данных всех узлов. Индекс столбца двумерного массива представляет адрес регистра, катушки или дискретного входа, а индекс строки представляет идентификатор узла ведомого устройства (но необходимо вычесть 1), например, usMRegHoldBuf[2][1] представляет данные ведомого устройства с идентификатором 3, адрес регистра — 1.

2.1.3 Обратные вызовы обработки данных Modbus

Всего существует 4 различных типа данных Modbus, и все функции Modbus вращаются вокруг этих типов данных. Поскольку структура данных разных пользователей может отличаться, соответствующий способ обработки Modbus также будет отличаться. Таким образом, пользователям необходимо настроить обработку каждого типа данных в соответствии с собственной структурой данных буфера. Все обратные вызовы обработки данных Modbus следующие:

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

2.2. Аппаратное обеспечение

При переносе стека протокола Modbus на хост-машину необходимо изменить конфигурацию последовательного порта и таймера. Файлы находятся в папке port. Пользователь должен выполнить перенос в соответствии с характеристиками своего центрального процессора.

Примечание: стек протоколов по умолчанию включает файл переноса для STM32F103X. Пользователи могут использовать его в качестве примера для переноса.

Здесь мы кратко обсудим перенос на основе операционной системы и фреймворка драйвера устройства. В будущем стек протоколов будет поддерживать перенос на фреймворк драйвера устройства RT-Thread. Пользователям не нужно беспокоиться о процессе переноса нижнего уровня, если их микроконтроллеры поддерживают BSP (Board Support Package) от RT-Thread, что снижает стоимость переноса.

2.2.1. Последовательный порт

Файлы переноса для последовательного порта находятся в FreeModbus\port\portserial_m.c. В этом файле пользователь должен внести изменения в следующие интерфейсы:

Кроме того, в конце файла необходимо добавить программу обслуживания последовательного порта, предоставленную центральным процессором. Переместите интерфейсы программы обработки прерываний отправки и приёма в соответствующие программы обработки прерываний.

2.2.2. Таймер

Файлы переноса таймера находятся в FreeModbus\port\porttimer_m.c. В этом файле пользователю необходимо внести изменения в следующие интерфейсы:

Примечание:

1. usPrescalerValue и usT35TimeOut50us определены в верхней части файла.
2. Задержки преобразования кадров и тайм-аут ответа определяются в файле mbconfig.h в каталоге FreeModbus\modbus\include. Пользователи могут настроить их в соответствии со своими потребностями.

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

Три. API

Использование Modbus Master отличается от использования Modbus Slave. Slave ожидает запросов от Master, а Master активно отправляет запросы и обрабатывает ответы Slave. Когда Master отправляет широковещательный запрос, Slave не должен отправлять ответ, поэтому широковещательные запросы подходят для команд записи данных Slave, но не подходят для чтения данных Slave. Все методы запроса в API возвращают значения одного формата. Значения возврата имеют следующее значение:

Все методы запроса Master являются потокобезопасными и блокирующими. Во время использования, если ресурсы Master не могут быть получены в течение установленного тайм-аута, возвращается сообщение о том, что Master занят; если ресурсы Master могут быть получены в течение установленного тайм-аута, необходимо дождаться результата запроса перед возвратом.

3.1. Запись в отдельный регистр хранения

Запись данных в определённый регистр хранения Slave.

eMBMasterReqErrCode eMBMasterReqWriteHoldingRegister( UCHAR ucSndAddr, 
                                                      USHORT usRegAddr,
                                                      USHORT usRegData,
                                                      LONG lTimeOut );

3.2. Запись в несколько регистров хранения

Запись данных в несколько регистров хранения Slave.

eMBMasterReqErrCode eMBMasterReqWriteMultipleHoldingRegister( UCHAR ucSndAddr,
                                                              USHORT usRegAddr,
                                                              USHORT usNRegs, 
                                                              USHORT * pusDataBuffer,
                                                              LONG lTimeOut )

3.3 Чтение данных из нескольких регистров хранения

Чтение данных из нескольких регистров хранения.

eMBMasterReqErrCode eMBMasterReqReadHoldingRegister( UCHAR ucSndAddr, 
                                                     USHORT usRegAddr,
                                                     USHORT usNRegs,
                                                     LONG lTimeOut );

3.4 Чтение и запись в несколько регистров хранения

Сначала чтение из нескольких регистров, затем запись в них.

eMBMasterReqErrCode eMBMasterReqReadWriteMultipleHoldingRegister( UCHAR ucSndAddr,
                                                                  USHORT usReadRegAddr,
                                                                  USHORT usNReadRegs,
                                                                  USHORT * pusDataBuffer,
                                                                  USHORT usWriteRegAddr,
                                                                  USHORT usNWriteRegs,
                                                                  LONG lTimeOut )

3.5 Чтение данных из нескольких входных регистров

Чтение данных из нескольких входных регистров.

eMBMasterReqErrCode eMBMasterReqReadInputRegister( UCHAR ucSndAddr, 
                                                   USHORT usRegAddr,
                                                   USHORT usNRegs,
                                                   LONG lTimeOut );

3.6 Запись в одну катушку

Запись данных в катушку запрашиваемого устройства.

eMBMasterReqErrCode eMBMasterReqWriteCoil( UCHAR ucSndAddr,
                                           USHORT usCoilAddr,
                                           USHORT usCoilData,
                                           LONG lTimeOut )

3.7 Запись в несколько катушек

Запись данных в несколько катушек запрашиваемого устройства.

eMBMasterReqErrCode eMBMasterReqWriteMultipleCoils( UCHAR ucSndAddr,
                                                    USHORT usCoilAddr,
                                                    USHORT usNCoils,
                                                    UCHAR * pucDataBuffer,
                                                    LONG lTimeOut)

3.8 Чтение данных из нескольких катушек

Чтение данных из нескольких катушек.

eMBMasterReqErrCode eMBMasterReqReadCoils( UCHAR ucSndAddr,
                                           USHORT usCoilAddr,
                                           USHORT usNCoils)
``` **Чтение данных из нескольких дискретных входов**

Чтение данных из нескольких дискретных входов.

```C
eMBMasterReqErrCode eMBMasterReqReadDiscreteInputs( UCHAR ucSndAddr,
                                                    USHORT usDiscreteAddr,
                                                    USHORT usNDiscreteIn,
                                                    LONG lTimeOut )

4. Процесс

4.1. Инициализация конфигурации процесса

Все конфигурационные параметры протокола стека находятся в файле FreeModbus\modbus\include\mbconfig.h. В настоящее время стек протоколов поддерживает два режима: хост и клиент, а также позволяет одновременно использовать оба режима. Клиент поддерживает три режима Modbus RTU, Modbus ASCII и Modbus TCP, в то время как хост в настоящее время поддерживает только широко используемый режим Modbus RTU. При использовании хоста пользователь должен настроить задержку преобразования широковещательной рассылки, время ожидания ответа команды и количество клиентов. Следует отметить, что в настоящее время протокол стека поддерживает только последовательные адреса клиентов, начиная с адреса 1.

4.2. Нормальный процесс использования

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

• 1. Вызов метода eMBMasterInit для инициализации стека протокола Modbus хоста, при этом выполняется инициализация некоторого оборудования, связанного с хостом.
• 2. Вызов метода eMBMasterEnable для запуска стека протокола Modbus хоста.
• 3. Опрос методом eMBMasterPoll через поток или таймер для определения периода опроса, который определяет время отклика команды.
• 4. Вызов API метода запроса хоста и установка определённого времени ожидания запроса, метод будет возвращать результат только после успешного выполнения команды. Если команда выполнена успешно и является командой чтения, данные последнего клиента могут быть получены путём просмотра буфера данных хоста Modbus.

4.3. Процесс обработки исключений

Обработка исключений в основном происходит во время нормального процесса использования хоста. Все коды ошибок API запросов хоста описаны в начале третьей главы, и пользователи должны выполнять различные действия в соответствии с характеристиками своих продуктов. Рекомендуется, чтобы пользователи самостоятельно инкапсулировали механизм повторной отправки методов запроса хоста, этот метод реализации более гибкий. Обычно повторная отправка требуется при получении ошибки кадра данных и ошибки тайм-аута команды ответа. Количество повторных отправок автоматически увеличивается на единицу. Если количество повторных отправок превышает установленное значение, считается, что клиент отключён, и все последующие команды, отправленные этому клиенту, будут заблокированы заранее; если вторая повторная отправка команды выполнена успешно, количество повторных отправок этого клиента автоматически сбрасывается до нуля.

Все эти функции могут быть реализованы с помощью методов запроса хоста или интерфейса обратного вызова в FreeModbus\port\portevent_m.c, и пользователи могут выбирать их гибко в соответствии со своими потребностями.

5. Лицензия

Основано на лицензии BSD, подробности см. в файле LICENSE.