Modbus ASCII的设计与实现
前面我们已经分析了modbus rtu的更新设计和具体实现（如果不清楚可查看前一篇文章）。其实modbus ascii与modbus rtu都是基于串行链路实现的，所以有很多的共同点，基于此，这篇文章我们只讨论与modbus rtu所不同的部分。
1 、更新设计
关于原来的协议栈在modbus ascii主站应用时所存在的局限性与modbus rtu也是一样的，所以我们不分析它的不足，只讨论更新设计。我们将主站及其所访问的从站定义为通用的对象，而当我们在具体应用中使用时，再将其特例化为特定的主站和从站对象。
首先我们来考虑主站，原则上我们规划的每一个主站对象对应我们设备上的一个端口，这里所说端口就是指串口。那么在同一端口下，也就是在一个特定主站下，我们可以定义多个地址不同的从站。而在不同的端口上可以具有地址相同的从站。如下图所示：
从上图中我们可以发现，我们的目的就是让协议栈支持，多主站和多从站，并且在不同主站下，从站的地址重复不受影响。从上图看视乎一个主站对象可以同时管理254个从站对象，事实上还要受到带载能力的影响。
接下来我们还需要考虑从站对象。主站对从站的操作无非两类：读从站信息和写从站信息。对于读从站信息来说，主站需要发送请求命令，等待从站返回响应信息，然后主站解析收到的信息并更新对应的参数值。有两点需要我们考虑，第一返回的响应消息是没有对应的寄存器地址的，所以要想在解析的时候定位寄存器就必须知道发送的命令，为了便于分辨我们将命令存放在从站对象中。第二在解析响应时，如果两条命令的响应类似是没法分辨的，所以我们还需要记住上一条命令是什么。也存储于从站对象中。
而对于写从站操作，无论写的要求来自于哪里，对于协议栈来说肯定是其它的数据处理进程发过来的，所接到要求后我们需要记录是哪一个主站管理的哪一个从站的哪些参数。对于主站我们不需要分辨，因为每个主站都是独立的处理进程，但是对于从站和参数我们就需要分辨。每一个主站可以带的站地址为0到255，但0和255已有定义，所以实际是1到254个。所以我们使用一个256位的变量，每位对应站号来标志其是否有需要写的请求。记录于主站，具体如下：
事实上，我们不可能会用到256个标志位，因为modbus ascii本身就是为简单应用而设定的。我们使用256个标志位，主要是考虑到站地址的取值范围，方便软件操作而定的。还有每个从站的写参数请求标志，我们将其存储于各个从站对象，因为不同的从站可能有很大区别，存储于各个从站更加灵活方便。
2 、编码实现
我们已经设计了我们的更新，接下来我们就根据这一设计来实现它。我们主要从以下几个方面来操作：第一，实现主站对象类型和从站对象类型；第二，主站对象的实例化及从站对象的实例化；第三，读从站的主站操作过程；第四，写从站的主站操作过程。接下来我们将一一描述之。
2.1 、定义对象类型
与在modbus rtu一样，在modbus ascii协议栈的封装中，我们也需要定义主站对象和从站对象，自然也免不了要定义这两种类型。
首先我们来定义本地主站的类型，其成员包括：一个uint32_t的写从站标志数组；从站数量字段；从站顺序字段；本主站过管理的从站列表；4个数据更新函数指针。具体定义如下：
1 /* 定义本地ascii主站对象类型 */ 2 typedef struct localasciimastertype{ 3 uint32_t flagwriteslave[8]; //写一个站控制标志位，最多256个站，与站地址对应。 4 uint16_t slavenumber; //从站列表中从站的数量 5 uint16_t readorder; //当前从站在从站列表中的位置 6 asciiaccessedslavetype *pslave; //从站列表 7 updatecoilstatustype pupdatecoilstatus; //更新线圈量函数 8 updateinputstatustype pupdateinputstatus; //更新输入状态量函数 9 updateholdingregistertype pupdateholdingregister; //更新保持寄存器量函数10 updateinputresgistertype pupdateinputresgister; //更新输入寄存器量函数11 }asciilocalmastertype;关于主站对象类型，在前面的更新设计中已经讲的很清楚了，只有两个字段需要说明一下。第一，从站列表是用来记录本主站所管理的从站对象。第二，readorder字段表示为当前访问从站在列表中的位置，而slavenumber是从站对象的数量，即列表的长度。具体如下图所示：
还需要定义从站对象，此从站对象只是便于主站而用于表示真是的从站。主站的从站列表中就是此对象。具体结构如下：
1 /* 定义被访问ascii从站对象类型 */ 2 typedef struct accessedasciislavetype{ 3 uint8_t stationaddress; //站地址 4 uint8_t cmdorder; //当前命令在命令列表中的位置 5 uint16_t commandnumber; //命令列表中命令的总数 6 uint8_t (*preadcommand)[17]; //读命令列表 7 uint8_t *plastcommand; //上一次发送的命令 8 uint32_t flagpresetcoil; //预置线圈控制标志位 9 uint32_t flagpresetreg; //预置寄存器控制标志位10 }asciiaccessedslavetype;关于从站对象有三个字段需要说明一下。首先我们来看一看“读命令列表（uint8_t (*preadcommand)[17]）”字段，与modbus rtu不同，它是17个字节，这是由modbus ascii消息格式决定的。如下：
还有就是flagpresetcoil和flagpresetreg字段。这两个字段用来表示对线圈和保持寄存器的写请求。
2.2 、实例化对象
我们定义了主站即从站对象类型，我们在使用时就需要实例化这些对象。一般来说一个硬件端口我们将其实例化为一个主站对象。
asciilocalmastertype hgramaster;
/ 初始化ascii主站对象 /
initializeasciimasterobject(&hgramaster,2,hgraslave,null,null,null,null);
而一个主站对象会管理1到254个从站对象，所以从站对象我们可以将多个从站对象实例组成数组，并将其赋予主站管理。
asciiaccessedslavetype hgraslave[]={{1,0,2,slave1readcommand,null,0x00,0x00},{2,0,2,slave2readcommand,null,0x00,0x00}};
所以，根据主站和从站实例化的条件，我们需要先实例化从站对象才能完整实例化主站对象。在主站的初始化中，我们这里将4的数据处理函数指针初始化为null，有一个默认的处理函数会复制给它，该函数是上一版本的延续，在简单应用时简化操作。从站的上一个发送的命令指针也被赋值为null，因为初始时还没有命令发送。
2.3 、读从站操作
读从站操作原理上与以前的版本是一样的。按照一定的顺序给从站发送命令再对收到的消息进行解析。我们对主站及其所管理的从站进行了定义，将发送命令保存于从站对象，将从站列表保存于主站对象，所以我们需要对解析函数进行修改。
1 /*解析收到的服务器相应信息*/ 2 void parsingasciislaverespondmessage(asciilocalmastertype *master,uint8_t *recievedmessage, uint8_t *command,uint16_t rxlength) 3 { 4 int i=0; 5 int j=0; 6 uint8_t *cmd=null; 7 8 /*判断是否为modbus ascii消息*/ 9 if (0x3a != recievedmessage[0])10 {11 return ;12 }13 14 /*判断消息是否接收完整*/15 if ((rxlength pslave[i].stationaddress==hexmessage[0])46 {47 break;48 }49 i++;50 }51 52 if(i>=master->slavenumber)53 {54 return;55 }56 57 if((master->pslave[i].plastcommand==null)||(!checkmessageagreewithcommand(recievedmessage,master->pslave[i].plastcommand)))58 {59 j=findasciicommandforrecievedmessage(recievedmessage,master->pslave[i].preadcommand,master->pslave[i].commandnumber);60 61 if(jpslave[i].preadcommand[j];67 }68 else69 {70 cmd=master->pslave[i].plastcommand;71 }72 }73 else74 {75 cmd=command;76 }77 78 uint8_t hexcommand[256];79 covertasciimessagetohex(cmd + 1, hexcommand, 14);80 81 uint16_t startaddress = (uint16_t)hexcommand[2];82 startaddress = (startaddress << 8) + (uint16_t)hexcommand[3];83 uint16_t quantity = (uint16_t)hexcommand[4];84 quantity = (quantity <= readcoilstatus) && (fuctioncode <= readinputregister))87 {88 handleasciislaverespond[fuctioncode - 1](master,hexmessage,startaddress,quantity);89 }90 }解析函数的主要部分是在检查接收到的消息是否是合法的modbus ascii消息。检查没问题则调用协议站解析。而最后调用的数据处理函数则是我们需要在具体应用中编写。在前面主站初始化时，回调函数我们初始化为null，实际在协议占中有弱化的函数定义，需要针对具体的寄存器和变量地址实现操作。特别要说明的是，解析modbus ascii消息时，在去除开始字符和结束字符后，需要将ascii码转化为二进制数才能完成解析。
2.4 、写从站操作
写从站操作则是在其它进程请求后，我们标识需要写的对象再统一处理。对具体哪个从站的写标识存于主站实例。而该从站的哪些变量需要写则记录在从站实例中。
所以在进程检测到需要写一个从站时则置位对应的位，即改变flagwriteslave中的对应位。而需要写该站的哪些变量则标记flagpresetcoil和flagpresetreg的对应位。修改这些标识都在其它请求更改的进程中实现，而具体的写操作则在本主站进程中，检测到标志位的变化统一执行。
这部分不修改协议栈的代码，因为各站及各变量都至于具体对象相关联，所以在具体的应用中修改。
3 、回归验证
考虑到modbus ascii和modbus rtu的相似性，我们设计同样的的网络结构。但考虑到modbus ascii一般用于小数据量通讯，所以我们设计相对简单的从站。所以我们设计的网络为：协议栈建立2个主机，每个主机管理2个从站，每个从站有8个线圈及2个保持寄存器。具体结构如图：
从上图我们知道，该modbus网关需要实现一个modbus从站用于和上位的通讯；需要实现两个modbus主站用于和下位的通讯。
在这个实验中，读操作没有什么需要说的，只需要发送命令解析返回消息即可。所以我们中点描述一下为了方便操作，在需要写的连续段，我们只要找到第一个请求写的位置后，就将后续连续可写数据一次性写入。修改写标志位的代码如下：
1 /* 修改从站线圈量使能控制 */ 2 static void presetslavecoilcontroll(uint16_t startaddress,uint16_t endaddress) 3 { 4 if((8<=startaddress)&&(startaddress<=15)&&(8<=endaddress)&&(endaddress<=15)) 5 { 6 modifywritertuslaveenableflag(&hgramaster,hgramaster.pslave[0].stationaddress,true); 7 8 if((startaddress<=8)&&(8<=endaddress)) 9 { 10 hgramaster.pslave[0].flagpresetcoil|=0x01; 11 } 12 if((startaddress<=9)&&(9<=endaddress)) 13 { 14 hgramaster.pslave[0].flagpresetcoil|=0x02; 15 } 16 if((startaddress<=10)&&(10<=endaddress)) 17 { 18 hgramaster.pslave[0].flagpresetcoil|=0x04; 19 } 20 if((startaddress<=11)&&(11<=endaddress)) 21 { 22 hgramaster.pslave[0].flagpresetcoil|=0x08; 23 } 24 if((startaddress<=12)&&(12<=endaddress)) 25 { 26 hgramaster.pslave[0].flagpresetcoil|=0x10; 27 } 28 if((startaddress<=13)&&(13<=endaddress)) 29 { 30 hgramaster.pslave[0].flagpresetcoil|=0x20; 31 } 32 if((startaddress<=14)&&(14<=endaddress)) 33 { 34 hgramaster.pslave[0].flagpresetcoil|=0x40; 35 } 36 if((startaddress<=15)&&(15<=endaddress)) 37 { 38 hgramaster.pslave[0].flagpresetcoil|=0x80; 39 } 40 } 41 42 if((16<=startaddress)&&(startaddress<=23)&&(16<=endaddress)&&(endaddress<=23)) 43 { 44 modifywritertuslaveenableflag(&hgramaster,hgramaster.pslave[1].stationaddress,true); 45 if((startaddress<=16)&&(16<=endaddress)) 46 { 47 hgramaster.pslave[1].flagpresetcoil|=0x01; 48 } 49 if((startaddress<=17)&&(17<=endaddress)) 50 { 51 hgramaster.pslave[1].flagpresetcoil|=0x02; 52 } 53 if((startaddress<=18)&&(18<=endaddress)) 54 { 55 hgramaster.pslave[1].flagpresetcoil|=0x04; 56 } 57 if((startaddress<=19)&&(19<=endaddress)) 58 { 59 hgramaster.pslave[1].flagpresetcoil|=0x08; 60 } 61 if((startaddress<=20)&&(20<=endaddress)) 62 { 63 hgramaster.pslave[1].flagpresetcoil|=0x10; 64 } 65 if((startaddress<=21)&&(21<=endaddress)) 66 { 67 hgramaster.pslave[1].flagpresetcoil|=0x20; 68 } 69 if((startaddress<=22)&&(22<=endaddress)) 70 { 71 hgramaster.pslave[1].flagpresetcoil|=0x40; 72 } 73 if((startaddress<=23)&&(23<=endaddress)) 74 { 75 hgramaster.pslave[1].flagpresetcoil|=0x80; 76 } 77 } 78 79 if((24<=startaddress)&&(startaddress<=31)&&(24<=endaddress)&&(endaddress<=31)) 80 { 81 modifywritertuslaveenableflag(&hgpjmaster,hgpjmaster.pslave[0].stationaddress,true); 82 if((startaddress<=24)&&(24<=endaddress)) 83 { 84 hgpjmaster.pslave[0].flagpresetcoil|=0x01; 85 } 86 if((startaddress<=25)&&(25<=endaddress)) 87 { 88 hgpjmaster.pslave[0].flagpresetcoil|=0x02; 89 } 90 if((startaddress<=26)&&(26<=endaddress)) 91 { 92 hgpjmaster.pslave[0].flagpresetcoil|=0x04; 93 } 94 if((startaddress<=27)&&(27<=endaddress)) 95 { 96 hgpjmaster.pslave[0].flagpresetcoil|=0x08; 97 } 98 if((startaddress<=28)&&(28<=endaddress)) 99 {100 hgpjmaster.pslave[0].flagpresetcoil|=0x10;101 }102 if((startaddress<=29)&&(29<=endaddress))103 {104 hgpjmaster.pslave[0].flagpresetcoil|=0x20;105 }106 if((startaddress<=30)&&(30<=endaddress))107 {108 hgpjmaster.pslave[0].flagpresetcoil|=0x40;109 }110 if((startaddress<=31)&&(31<=endaddress))111 {112 hgpjmaster.pslave[0].flagpresetcoil|=0x80;113 }114 }115 116 if((32<=startaddress)&&(startaddress<=39)&&(32<=endaddress)&&(endaddress<=39))117 {118 modifywritertuslaveenableflag(&hgpjmaster,hgpjmaster.pslave[1].stationaddress,true);119 if((startaddress<=32)&&(32<=endaddress))120 {121 hgpjmaster.pslave[1].flagpresetcoil|=0x01;122 }123 if((startaddress<=33)&&(33<=endaddress))124 {125 hgpjmaster.pslave[1].flagpresetcoil|=0x02;126 }127 if((startaddress<=34)&&(34<=endaddress))128 {129 hgpjmaster.pslave[1].flagpresetcoil|=0x04;130 }131 if((startaddress<=35)&&(35<=endaddress))132 {133 hgpjmaster.pslave[1].flagpresetcoil|=0x08;134 }135 if((startaddress<=36)&&(36<=endaddress))136 {137 hgpjmaster.pslave[1].flagpresetcoil|=0x10;138 }139 if((startaddress<=37)&&(37<=endaddress))140 {141 hgpjmaster.pslave[1].flagpresetcoil|=0x20;142 }143 if((startaddress<=38)&&(38<=endaddress))144 {145 hgpjmaster.pslave[1].flagpresetcoil|=0x40;146 }147 if((startaddress<=39)&&(39<=endaddress))148 {149 hgpjmaster.pslave[1].flagpresetcoil|=0x80;150 }151 }152 153 }与modbus rtu一样也是在请求修改进程中置位索要写的从站的写请求标志位和对应参数的写请求标志位。然后在主站对象的进程中检测标志位，根据标志位的状态来实现操作。
告之： 源代码可上github下载：https://github.com/foxclever/modbus
HP8753ES/HP8714ET/HP8719C/HP87
LED可见光通信技术九大发展趋势分析
小米12 Pro突破行业瓶颈 带来五大技术突破
中国联通与紫光展锐共同推出eSIM版CPE终端，快速丰富5G应用场景
HLA高级体系结构介绍
Modbus ASCII的设计与实现
为什么ARM工控主板的应用前景那么好
守护绿水青山 曙光打造生态治理“智慧大脑”
旭宇光电建设省工程技术研究中心推动深紫外LED杀菌消毒应用
倘若世界没有MEMS传感器 它将带来哪些变化？
洁面仪什么牌子好,肌肤清洁护理就用它
服务机器人智能化发展加速 未来家庭必不可少
LM3406/LM3406HV—驱动高功率 LED 的 Po
商汤智能发布 智能平台白皮书
摩尔定律跟比特币有什么关系
工业物联网通信解决方案分享
SolidPower与福特汽车合作 为下一代电动汽车研发全固态电池
小米造车时机已经到来?
AI高带宽内存的芯片离不开国产先进技术的支持
海天雄电子S5P6818核心板（邮票口）介绍
1 、更新设计
关于原来的协议栈在modbus ascii主站应用时所存在的局限性与modbus rtu也是一样的，所以我们不分析它的不足，只讨论更新设计。我们将主站及其所访问的从站定义为通用的对象，而当我们在具体应用中使用时，再将其特例化为特定的主站和从站对象。
首先我们来考虑主站，原则上我们规划的每一个主站对象对应我们设备上的一个端口，这里所说端口就是指串口。那么在同一端口下，也就是在一个特定主站下，我们可以定义多个地址不同的从站。而在不同的端口上可以具有地址相同的从站。如下图所示：
从上图中我们可以发现，我们的目的就是让协议栈支持，多主站和多从站，并且在不同主站下，从站的地址重复不受影响。从上图看视乎一个主站对象可以同时管理254个从站对象，事实上还要受到带载能力的影响。
接下来我们还需要考虑从站对象。主站对从站的操作无非两类：读从站信息和写从站信息。对于读从站信息来说，主站需要发送请求命令，等待从站返回响应信息，然后主站解析收到的信息并更新对应的参数值。有两点需要我们考虑，第一返回的响应消息是没有对应的寄存器地址的，所以要想在解析的时候定位寄存器就必须知道发送的命令，为了便于分辨我们将命令存放在从站对象中。第二在解析响应时，如果两条命令的响应类似是没法分辨的，所以我们还需要记住上一条命令是什么。也存储于从站对象中。
而对于写从站操作，无论写的要求来自于哪里，对于协议栈来说肯定是其它的数据处理进程发过来的，所接到要求后我们需要记录是哪一个主站管理的哪一个从站的哪些参数。对于主站我们不需要分辨，因为每个主站都是独立的处理进程，但是对于从站和参数我们就需要分辨。每一个主站可以带的站地址为0到255，但0和255已有定义，所以实际是1到254个。所以我们使用一个256位的变量，每位对应站号来标志其是否有需要写的请求。记录于主站，具体如下：
事实上，我们不可能会用到256个标志位，因为modbus ascii本身就是为简单应用而设定的。我们使用256个标志位，主要是考虑到站地址的取值范围，方便软件操作而定的。还有每个从站的写参数请求标志，我们将其存储于各个从站对象，因为不同的从站可能有很大区别，存储于各个从站更加灵活方便。
2 、编码实现
我们已经设计了我们的更新，接下来我们就根据这一设计来实现它。我们主要从以下几个方面来操作：第一，实现主站对象类型和从站对象类型；第二，主站对象的实例化及从站对象的实例化；第三，读从站的主站操作过程；第四，写从站的主站操作过程。接下来我们将一一描述之。
2.1 、定义对象类型
与在modbus rtu一样，在modbus ascii协议栈的封装中，我们也需要定义主站对象和从站对象，自然也免不了要定义这两种类型。
首先我们来定义本地主站的类型，其成员包括：一个uint32_t的写从站标志数组；从站数量字段；从站顺序字段；本主站过管理的从站列表；4个数据更新函数指针。具体定义如下：
1 /* 定义本地ascii主站对象类型 */ 2 typedef struct localasciimastertype{ 3 uint32_t flagwriteslave[8]; //写一个站控制标志位，最多256个站，与站地址对应。 4 uint16_t slavenumber; //从站列表中从站的数量 5 uint16_t readorder; //当前从站在从站列表中的位置 6 asciiaccessedslavetype *pslave; //从站列表 7 updatecoilstatustype pupdatecoilstatus; //更新线圈量函数 8 updateinputstatustype pupdateinputstatus; //更新输入状态量函数 9 updateholdingregistertype pupdateholdingregister; //更新保持寄存器量函数10 updateinputresgistertype pupdateinputresgister; //更新输入寄存器量函数11 }asciilocalmastertype;关于主站对象类型，在前面的更新设计中已经讲的很清楚了，只有两个字段需要说明一下。第一，从站列表是用来记录本主站所管理的从站对象。第二，readorder字段表示为当前访问从站在列表中的位置，而slavenumber是从站对象的数量，即列表的长度。具体如下图所示：
还需要定义从站对象，此从站对象只是便于主站而用于表示真是的从站。主站的从站列表中就是此对象。具体结构如下：
1 /* 定义被访问ascii从站对象类型 */ 2 typedef struct accessedasciislavetype{ 3 uint8_t stationaddress; //站地址 4 uint8_t cmdorder; //当前命令在命令列表中的位置 5 uint16_t commandnumber; //命令列表中命令的总数 6 uint8_t (*preadcommand)[17]; //读命令列表 7 uint8_t *plastcommand; //上一次发送的命令 8 uint32_t flagpresetcoil; //预置线圈控制标志位 9 uint32_t flagpresetreg; //预置寄存器控制标志位10 }asciiaccessedslavetype;关于从站对象有三个字段需要说明一下。首先我们来看一看“读命令列表（uint8_t (*preadcommand)[17]）”字段，与modbus rtu不同，它是17个字节，这是由modbus ascii消息格式决定的。如下：
还有就是flagpresetcoil和flagpresetreg字段。这两个字段用来表示对线圈和保持寄存器的写请求。
2.2 、实例化对象
我们定义了主站即从站对象类型，我们在使用时就需要实例化这些对象。一般来说一个硬件端口我们将其实例化为一个主站对象。
asciilocalmastertype hgramaster;
/ 初始化ascii主站对象 /
initializeasciimasterobject(&hgramaster,2,hgraslave,null,null,null,null);
而一个主站对象会管理1到254个从站对象，所以从站对象我们可以将多个从站对象实例组成数组，并将其赋予主站管理。
asciiaccessedslavetype hgraslave[]={{1,0,2,slave1readcommand,null,0x00,0x00},{2,0,2,slave2readcommand,null,0x00,0x00}};
所以，根据主站和从站实例化的条件，我们需要先实例化从站对象才能完整实例化主站对象。在主站的初始化中，我们这里将4的数据处理函数指针初始化为null，有一个默认的处理函数会复制给它，该函数是上一版本的延续，在简单应用时简化操作。从站的上一个发送的命令指针也被赋值为null，因为初始时还没有命令发送。
2.3 、读从站操作
读从站操作原理上与以前的版本是一样的。按照一定的顺序给从站发送命令再对收到的消息进行解析。我们对主站及其所管理的从站进行了定义，将发送命令保存于从站对象，将从站列表保存于主站对象，所以我们需要对解析函数进行修改。
1 /*解析收到的服务器相应信息*/ 2 void parsingasciislaverespondmessage(asciilocalmastertype *master,uint8_t *recievedmessage, uint8_t *command,uint16_t rxlength) 3 { 4 int i=0; 5 int j=0; 6 uint8_t *cmd=null; 7 8 /*判断是否为modbus ascii消息*/ 9 if (0x3a != recievedmessage[0])10 {11 return ;12 }13 14 /*判断消息是否接收完整*/15 if ((rxlength pslave[i].stationaddress==hexmessage[0])46 {47 break;48 }49 i++;50 }51 52 if(i>=master->slavenumber)53 {54 return;55 }56 57 if((master->pslave[i].plastcommand==null)||(!checkmessageagreewithcommand(recievedmessage,master->pslave[i].plastcommand)))58 {59 j=findasciicommandforrecievedmessage(recievedmessage,master->pslave[i].preadcommand,master->pslave[i].commandnumber);60 61 if(jpslave[i].preadcommand[j];67 }68 else69 {70 cmd=master->pslave[i].plastcommand;71 }72 }73 else74 {75 cmd=command;76 }77 78 uint8_t hexcommand[256];79 covertasciimessagetohex(cmd + 1, hexcommand, 14);80 81 uint16_t startaddress = (uint16_t)hexcommand[2];82 startaddress = (startaddress << 8) + (uint16_t)hexcommand[3];83 uint16_t quantity = (uint16_t)hexcommand[4];84 quantity = (quantity <= readcoilstatus) && (fuctioncode <= readinputregister))87 {88 handleasciislaverespond[fuctioncode - 1](master,hexmessage,startaddress,quantity);89 }90 }解析函数的主要部分是在检查接收到的消息是否是合法的modbus ascii消息。检查没问题则调用协议站解析。而最后调用的数据处理函数则是我们需要在具体应用中编写。在前面主站初始化时，回调函数我们初始化为null，实际在协议占中有弱化的函数定义，需要针对具体的寄存器和变量地址实现操作。特别要说明的是，解析modbus ascii消息时，在去除开始字符和结束字符后，需要将ascii码转化为二进制数才能完成解析。
2.4 、写从站操作
写从站操作则是在其它进程请求后，我们标识需要写的对象再统一处理。对具体哪个从站的写标识存于主站实例。而该从站的哪些变量需要写则记录在从站实例中。
所以在进程检测到需要写一个从站时则置位对应的位，即改变flagwriteslave中的对应位。而需要写该站的哪些变量则标记flagpresetcoil和flagpresetreg的对应位。修改这些标识都在其它请求更改的进程中实现，而具体的写操作则在本主站进程中，检测到标志位的变化统一执行。
这部分不修改协议栈的代码，因为各站及各变量都至于具体对象相关联，所以在具体的应用中修改。
3 、回归验证
考虑到modbus ascii和modbus rtu的相似性，我们设计同样的的网络结构。但考虑到modbus ascii一般用于小数据量通讯，所以我们设计相对简单的从站。所以我们设计的网络为：协议栈建立2个主机，每个主机管理2个从站，每个从站有8个线圈及2个保持寄存器。具体结构如图：
从上图我们知道，该modbus网关需要实现一个modbus从站用于和上位的通讯；需要实现两个modbus主站用于和下位的通讯。
在这个实验中，读操作没有什么需要说的，只需要发送命令解析返回消息即可。所以我们中点描述一下为了方便操作，在需要写的连续段，我们只要找到第一个请求写的位置后，就将后续连续可写数据一次性写入。修改写标志位的代码如下：
1 /* 修改从站线圈量使能控制 */ 2 static void presetslavecoilcontroll(uint16_t startaddress,uint16_t endaddress) 3 { 4 if((8<=startaddress)&&(startaddress<=15)&&(8<=endaddress)&&(endaddress<=15)) 5 { 6 modifywritertuslaveenableflag(&hgramaster,hgramaster.pslave[0].stationaddress,true); 7 8 if((startaddress<=8)&&(8<=endaddress)) 9 { 10 hgramaster.pslave[0].flagpresetcoil|=0x01; 11 } 12 if((startaddress<=9)&&(9<=endaddress)) 13 { 14 hgramaster.pslave[0].flagpresetcoil|=0x02; 15 } 16 if((startaddress<=10)&&(10<=endaddress)) 17 { 18 hgramaster.pslave[0].flagpresetcoil|=0x04; 19 } 20 if((startaddress<=11)&&(11<=endaddress)) 21 { 22 hgramaster.pslave[0].flagpresetcoil|=0x08; 23 } 24 if((startaddress<=12)&&(12<=endaddress)) 25 { 26 hgramaster.pslave[0].flagpresetcoil|=0x10; 27 } 28 if((startaddress<=13)&&(13<=endaddress)) 29 { 30 hgramaster.pslave[0].flagpresetcoil|=0x20; 31 } 32 if((startaddress<=14)&&(14<=endaddress)) 33 { 34 hgramaster.pslave[0].flagpresetcoil|=0x40; 35 } 36 if((startaddress<=15)&&(15<=endaddress)) 37 { 38 hgramaster.pslave[0].flagpresetcoil|=0x80; 39 } 40 } 41 42 if((16<=startaddress)&&(startaddress<=23)&&(16<=endaddress)&&(endaddress<=23)) 43 { 44 modifywritertuslaveenableflag(&hgramaster,hgramaster.pslave[1].stationaddress,true); 45 if((startaddress<=16)&&(16<=endaddress)) 46 { 47 hgramaster.pslave[1].flagpresetcoil|=0x01; 48 } 49 if((startaddress<=17)&&(17<=endaddress)) 50 { 51 hgramaster.pslave[1].flagpresetcoil|=0x02; 52 } 53 if((startaddress<=18)&&(18<=endaddress)) 54 { 55 hgramaster.pslave[1].flagpresetcoil|=0x04; 56 } 57 if((startaddress<=19)&&(19<=endaddress)) 58 { 59 hgramaster.pslave[1].flagpresetcoil|=0x08; 60 } 61 if((startaddress<=20)&&(20<=endaddress)) 62 { 63 hgramaster.pslave[1].flagpresetcoil|=0x10; 64 } 65 if((startaddress<=21)&&(21<=endaddress)) 66 { 67 hgramaster.pslave[1].flagpresetcoil|=0x20; 68 } 69 if((startaddress<=22)&&(22<=endaddress)) 70 { 71 hgramaster.pslave[1].flagpresetcoil|=0x40; 72 } 73 if((startaddress<=23)&&(23<=endaddress)) 74 { 75 hgramaster.pslave[1].flagpresetcoil|=0x80; 76 } 77 } 78 79 if((24<=startaddress)&&(startaddress<=31)&&(24<=endaddress)&&(endaddress<=31)) 80 { 81 modifywritertuslaveenableflag(&hgpjmaster,hgpjmaster.pslave[0].stationaddress,true); 82 if((startaddress<=24)&&(24<=endaddress)) 83 { 84 hgpjmaster.pslave[0].flagpresetcoil|=0x01; 85 } 86 if((startaddress<=25)&&(25<=endaddress)) 87 { 88 hgpjmaster.pslave[0].flagpresetcoil|=0x02; 89 } 90 if((startaddress<=26)&&(26<=endaddress)) 91 { 92 hgpjmaster.pslave[0].flagpresetcoil|=0x04; 93 } 94 if((startaddress<=27)&&(27<=endaddress)) 95 { 96 hgpjmaster.pslave[0].flagpresetcoil|=0x08; 97 } 98 if((startaddress<=28)&&(28<=endaddress)) 99 {100 hgpjmaster.pslave[0].flagpresetcoil|=0x10;101 }102 if((startaddress<=29)&&(29<=endaddress))103 {104 hgpjmaster.pslave[0].flagpresetcoil|=0x20;105 }106 if((startaddress<=30)&&(30<=endaddress))107 {108 hgpjmaster.pslave[0].flagpresetcoil|=0x40;109 }110 if((startaddress<=31)&&(31<=endaddress))111 {112 hgpjmaster.pslave[0].flagpresetcoil|=0x80;113 }114 }115 116 if((32<=startaddress)&&(startaddress<=39)&&(32<=endaddress)&&(endaddress<=39))117 {118 modifywritertuslaveenableflag(&hgpjmaster,hgpjmaster.pslave[1].stationaddress,true);119 if((startaddress<=32)&&(32<=endaddress))120 {121 hgpjmaster.pslave[1].flagpresetcoil|=0x01;122 }123 if((startaddress<=33)&&(33<=endaddress))124 {125 hgpjmaster.pslave[1].flagpresetcoil|=0x02;126 }127 if((startaddress<=34)&&(34<=endaddress))128 {129 hgpjmaster.pslave[1].flagpresetcoil|=0x04;130 }131 if((startaddress<=35)&&(35<=endaddress))132 {133 hgpjmaster.pslave[1].flagpresetcoil|=0x08;134 }135 if((startaddress<=36)&&(36<=endaddress))136 {137 hgpjmaster.pslave[1].flagpresetcoil|=0x10;138 }139 if((startaddress<=37)&&(37<=endaddress))140 {141 hgpjmaster.pslave[1].flagpresetcoil|=0x20;142 }143 if((startaddress<=38)&&(38<=endaddress))144 {145 hgpjmaster.pslave[1].flagpresetcoil|=0x40;146 }147 if((startaddress<=39)&&(39<=endaddress))148 {149 hgpjmaster.pslave[1].flagpresetcoil|=0x80;150 }151 }152 153 }与modbus rtu一样也是在请求修改进程中置位索要写的从站的写请求标志位和对应参数的写请求标志位。然后在主站对象的进程中检测标志位，根据标志位的状态来实现操作。
告之： 源代码可上github下载：https://github.com/foxclever/modbus
HP8753ES/HP8714ET/HP8719C/HP87
LED可见光通信技术九大发展趋势分析
小米12 Pro突破行业瓶颈 带来五大技术突破
中国联通与紫光展锐共同推出eSIM版CPE终端，快速丰富5G应用场景
HLA高级体系结构介绍
Modbus ASCII的设计与实现
为什么ARM工控主板的应用前景那么好
守护绿水青山 曙光打造生态治理“智慧大脑”
旭宇光电建设省工程技术研究中心推动深紫外LED杀菌消毒应用
倘若世界没有MEMS传感器 它将带来哪些变化？
洁面仪什么牌子好,肌肤清洁护理就用它
服务机器人智能化发展加速 未来家庭必不可少
LM3406/LM3406HV—驱动高功率 LED 的 Po
商汤智能发布 智能平台白皮书
摩尔定律跟比特币有什么关系
工业物联网通信解决方案分享
SolidPower与福特汽车合作 为下一代电动汽车研发全固态电池
小米造车时机已经到来?
AI高带宽内存的芯片离不开国产先进技术的支持
海天雄电子S5P6818核心板（邮票口）介绍