搜索
bottom↓
回复: 89

[OurDev开源充电器][任务6] 1.上下位机通讯协议设计 更新v0.6 (by 村长)

[复制链接]
(408112336)

出0入0汤圆

发表于 2007-11-21 08:28:43 | 显示全部楼层 |阅读模式
版本 v0.6,更新内容:

1)修正从机应答时无应答状态
2)加入获取参数设置
3)加入连续表的方式
4)在设备搜索指令中加入协议支持方式


















































下载链接:
Battery Charger Software Protocol v0.6.pdf(文件大小:1.61M)





历史版本:

版本 v0.5,更新内容:
1)、加入涓流设置,充不满设置
2)、应lvhaian 安哥要求,加入电池种类
3)、加入液晶设置,脉冲设置,其它设置

下载链接:
Battery Charger Software Protocol (v0.5).pdf(文件大小:1.55M)


版本 v0.4,更新内容:
1)、加入放电设置,快充设置.
2)、加入电压上限,温度上限.
3)、重新排版.

下载链接:
Battery Charger Software Protocol (v0.4).pdf(文件大小:1.07M)


版本 v0.3

下载链接:
Battery Charger Software Protocol.pdf V0.3(文件大小:727K)

版本 v0.2 ,更新内容:
1)、参考了一下Modbus协议,然后把数据结构方面做了一点点修正,主要是加入了设备搜索的命令解释.

下载链接:
Battery Charger Software Protocol.pdf V0.2(文件大小:458K)

版本 v0.1
??
(408110875)

出0入0汤圆

发表于 2007-11-21 08:53:04 | 显示全部楼层
如果数据串刚好有要发送的数据是转义符怎么办?

例如我就想发送 0x1B 0x11 2个字节,而不是0x1A字节,怎么办?
(408110428)

出0入0汤圆

发表于 2007-11-21 09:00:31 | 显示全部楼层
估计数据先要转成ascci码,才可以传
(408094682)

出0入0汤圆

发表于 2007-11-21 13:22:57 | 显示全部楼层
PDF很漂亮
村长,是否考虑可以修改一下,类似 MODBUS 的协议。直接而且方便
(408093597)

出0入0汤圆

发表于 2007-11-21 13:41:02 | 显示全部楼层
【1楼】 ATMEGA_007
>>例如我就想发送 0x1B 0x11 2个字节,而不是0x1A字节,怎么办?

那经过编码就是0x1B 0x0B 0x11,只做单次解码是没有问题的。
(408091840)

出0入0汤圆

 楼主| 发表于 2007-11-21 14:10:19 | 显示全部楼层
to 【1楼】 ATMEGA_007
Cocal 已经回答正确。

to【2楼】 junsi
不需要转成ASCII码

to 【3楼】 trinove 阿力
MODBUS协议我不懂,如果要修改成MODBUS的样子,估计要费不少力气,时间上花不来,还是算了,用现在成熟的稍改一下算了。
(408090815)

出0入0汤圆

发表于 2007-11-21 14:27:24 | 显示全部楼层
你的协议和MODBUS已经差不多了,只是格式上有些区别。

MODBUS的格式一般是这样的,详细的指令格式是有一些不同的。
1      2     3     4     5     6     7     ……  n      n+1
地址   指令  地址L 地址H 数量  内容L 内容H ……  CRC16  CRC16

这个MODBUS用的比较多,可以多机通讯。

我只是建议一下而已,呵呵!
(408088962)

出0入0汤圆

 楼主| 发表于 2007-11-21 14:58:17 | 显示全部楼层
呵呵,原來跟MODBUS差不多,我的协议是解码之后,才会有接收端地址,看来是有不足的地方。
不过没关系了,这个协议对充电器来说,应该是够用了。
感谢【6楼】 trinove 阿力 的指点。
(408082028)

出20入4汤圆

发表于 2007-11-21 16:53:51 | 显示全部楼层
有怎么复杂吗?用MODBUS协议不就可以了

楼主小题大做了,有点自大了,你能制定协议,但成不了标准..这个没有意义

用了MODBUS好处多多,直接可以用组态王等组态软件.(当然自己做软件也可以)
(408080449)

出0入0汤圆

发表于 2007-11-21 17:20:10 | 显示全部楼层
顶一下村长。Modbus不算复杂,但是否使用,还是由你来定,合适就好。
(408078695)

出0入0汤圆

发表于 2007-11-21 17:49:24 | 显示全部楼层
村长是个高人
(408078277)

出0入0汤圆

 楼主| 发表于 2007-11-21 17:56:22 | 显示全部楼层
【8楼】 john78

----有怎么复杂吗?用MODBUS协议不就可以了
不懂,也没学过,所以就认为复杂了,俺本事小,学不会复杂的东西。。。

----楼主小题大做了,有点自大了,你能制定协议,但成不了标准..这个没有意义
自创协议也叫小题大做的话,俺无语。。。至於成不成得了标准,那是高手做的了,俺菜手做的协议,也就自家用用而已。

----用了MODBUS好处多多,直接可以用组态王等组态软件.(当然自己做软件也可以)
MODBUS,组态王,这些俺都没用过,还请大侠指教。
(408075631)

出0入10汤圆

发表于 2007-11-21 18:40:28 | 显示全部楼层
不妨把MODBUS贴出来,让大家看看。 我没用过,但应该可以看得懂一点。
(408073988)

出0入0汤圆

发表于 2007-11-21 19:07:51 | 显示全部楼层
第952篇:Modbus通讯协议详解
发布时间:2005年10月14日 点击次数:8163  
来源:   作者:
  
工业控制已从单机控制走向集中监控、集散控制,如今已进入网络时代,工业控制器连网也为网络管理提供了方便。Modbus就是工业控制器的网络协议中的一种。
一、 Modbus 协议简介
Modbus 协议是应用于电子控制器上的一种通用语言。通过此协议,控制器相互之间、控制器经由网络(例如以太网)和其它设备之间可以通信。它已经成为一通用工业标准。有了它,不同厂商生产的控制设备可以连成工业网络,进行集中监控。此协议定义了一个控制器能认识使用的消息结构,而不管它们是经过何种网络进行通信的。它描述了一控制器请求访问其它设备的过程,如果回应来自其它设备的请求,以及怎样侦测错误并记录。它制定了消息域格局和内容的公共格式。
当在一Modbus网络上通信时,此协议决定了每个控制器须要知道它们的设备地址,识别按地址发来的消息,决定要产生何种行动。如果需要回应,控制器将生成反馈信息并用Modbus协议发出。在其它网络上,包含了Modbus协议的消息转换为在此网络上使用的帧或包结构。这种转换也扩展了根据具体的网络解决节地址、路由路径及错误检测的方法。
1、在Modbus网络上转输
标准的Modbus口是使用一RS-232C兼容串行接口,它定义了连接口的针脚、电缆、信号位、传输波特率、奇偶校验。控制器能直接或经由Modem组网。
控制器通信使用主—从技术,即仅一设备(主设备)能初始化传输(查询)。其它设备(从设备)根据主设备查询提供的数据作出相应反应。典型的主设备:主机和可编程仪表。典型的从设备:可编程控制器。
主设备可单独和从设备通信,也能以广播方式和所有从设备通信。如果单独通信,从设备返回一消息作为回应,如果是以广播方式查询的,则不作任何回应。Modbus协议建立了主设备查询的格式:设备(或广播)地址、功能代码、所有要发送的数据、一错误检测域。
从设备回应消息也由Modbus协议构成,包括确认要行动的域、任何要返回的数据、和一错误检测域。如果在消息接收过程中发生一错误,或从设备不能执行其命令,从设备将建立一错误消息并把它作为回应发送出去。
2、在其它类型网络上转输
在其它网络上,控制器使用对等技术通信,故任何控制都能初始和其它控制器的通信。这样在单独的通信过程中,控制器既可作为主设备也可作为从设备。提供的多个内部通道可允许同时发生的传输进程。
在消息位,Modbus协议仍提供了主—从原则,尽管网络通信方法是“对等”。如果一控制器发送一消息,它只是作为主设备,并期望从从设备得到回应。同样,当控制器接收到一消息,它将建立一从设备回应格式并返回给发送的控制器。
3、查询—回应周期
(1)查询
查询消息中的功能代码告之被选中的从设备要执行何种功能。数据段包含了从设备要执行功能的任何附加信息。例如功能代码03是要求从设备读保持寄存器并返回它们的内容。数据段必须包含要告之从设备的信息:从何寄存器开始读及要读的寄存器数量。错误检测域为从设备提供了一种验证消息内容是否正确的方法。
(2)回应
如果从设备产生一正常的回应,在回应消息中的功能代码是在查询消息中的功能代码的回应。数据段包括了从设备收集的数据:象寄存器值或状态。如果有错误发生,功能代码将被修改以用于指出回应消息是错误的,同时数据段包含了描述此错误信息的代码。错误检测域允许主设备确认消息内容是否可用。

二、两种传输方式
控制器能设置为两种传输模式(ASCII或RTU)中的任何一种在标准的Modbus网络通信。用户选择想要的模式,包括串口通信参数(波特率、校验方式等),在配置每个控制器的时候,在一个Modbus网络上的所有设备都必须选择相同的传输模式和串口参数。
所选的ASCII或RTU方式仅适用于标准的Modbus网络,它定义了在这些网络上连续传输的消息段的每一位,以及决定怎样将信息打包成消息域和如何解码。
在其它网络上(象MAP和Modbus Plus)Modbus消息被转成与串行传输无关的帧。
1、ASCII模式
当控制器设为在Modbus网络上以ASCII(美国标准信息交换代码)模式通信,在消息中的每个8Bit字节都作为两个ASCII字符发送。这种方式的主要优点是字符发送的时间间隔可达到1秒而不产生错误。
代码系统
·   十六进制,ASCII字符0...9,A...F
·   消息中的每个ASCII字符都是一个十六进制字符组成
每个字节的位
·   1个起始位
·   7个数据位,最小的有效位先发送
·   1个奇偶校验位,无校验则无
CRC域是两个字节,包含一16位的二进制值。它由传输设备计算后加入到消息中。接收设备重新计算收到消息的CRC,并与接收到的CRC域中的值比较,如果两值不同,则有误。
CRC是先调入一值是全“1”的16位寄存器,然后调用一过程将消息中连续的8位字节各当前寄存器中的值进行处理。仅每个字符中的8Bit数据对CRC有效,起始位和停止位以及奇偶校验位均无效。
CRC产生过程中,每个8位字符都单独和寄存器内容相或(OR),结果向最低有效位方向移动,最高有效位以0填充。LSB被提取出来检测,如果LSB为1,寄存器单独和预置的值或一下,如果LSB为0,则不进行。整个过程要重复8次。在最后一位(第8位)完成后,下一个8位字节又单独和寄存器的当前值相或。最终寄存器中的值,是消息中所有的字节都执行之后的CRC值。
CRC添加到消息中时,低字节先加入,然后高字节。
CRC简单函数如下:
unsigned short CRC16(puchMsg, usDataLen)
unsigned char *puchMsg ; /* 要进行CRC校验的消息 */
unsigned short usDataLen ; /* 消息中字节数 */
{
unsigned char uchCRCHi = 0xFF ; /* 高CRC字节初始化 */
unsigned char uchCRCLo = 0xFF ; /* 低CRC 字节初始化 */
unsigned uIndex ; /* CRC循环中的索引 */
while (usDataLen--) /* 传输消息缓冲区 */
{
uIndex = uchCRCHi ^ *puchMsgg++ ; /* 计算CRC */
uchCRCHi = uchCRCLo ^ auchCRCHi[uIndex} ;
uchCRCLo = auchCRCLo[uIndex] ;
}
return (uchCRCHi << 8   uchCRCLo) ;
}
/* CRC 高位字节值表 */
static unsigned char auchCRCHi[] = {
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40,
0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1,
0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40
} ;
/* CRC低位字节值表*/
static char auchCRCLo[] = {
0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06,
0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04, 0xCC, 0x0C, 0x0D, 0xCD,
0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09,
0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A,
0x1E, 0xDE, 0xDF, 0x1F, 0xDD, 0x1D, 0x1C, 0xDC, 0x14, 0xD4,
0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3,
0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3,
0xF2, 0x32, 0x36, 0xF6, 0xF7, 0x37, 0xF5, 0x35, 0x34, 0xF4,
0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A,
0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29,
0xEB, 0x2B, 0x2A, 0xEA, 0xEE, 0x2E, 0x2F, 0xEF, 0x2D, 0xED,
0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26,
0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60,
0x61, 0xA1, 0x63, 0xA3, 0xA2, 0x62, 0x66, 0xA6, 0xA7, 0x67,
0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F,
0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68,
0x78, 0xB8, 0xB9, 0x79, 0xBB, 0x7B, 0x7A, 0xBA, 0xBE, 0x7E,
0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5,
0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71,
0x70, 0xB0, 0x50, 0x90, 0x91, 0x51, 0x93, 0x53, 0x52, 0x92,
0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C,
0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B,
0x99, 0x59, 0x58, 0x98, 0x88, 0x48, 0x49, 0x89, 0x4B, 0x8B,
0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42,
0x43, 0x83, 0x41, 0x81, 0x80, 0x40
} ; 
ModBus网络是一个工业通信系统,由带智能终端的可编程序控制器和计算机通过公用线路或局部专用线路连接而成。其系统结构既包括硬件、亦包括软件。它可应用于各种数据采集和过程监控。下表1是ModBus的功能码定义。
表1 ModBus功能码
01 READ COIL STATUS
02 READ INPUT STATUS
03 READ HOLDING REGISTER
04 READ INPUT REGISTER
05 WRITE SINGLE COIL
06 WRITE SINGLE REGISTER
15 WRITE MULTIPLE COIL
16 WRITE MULTIPLE REGISTER
ModBus网络只是一个主机,所有通信都由他发出。网络可支持247个之多的远程从属控制器,但实际所支持的从机数要由所用通信设备决定。采用这个系统,各PC可以和中心主机交换信息而不影响各PC执行本身的控制任务。
(1)ModBus的传输方式
在ModBus系统中有2种传输模式可选择。这2种传输模式与从机PC通信的能力是同等的。选择时应视所用ModBus主机而定,每个ModBus系统只能使用一种模式,不允许2种模式混用。一种模式是ASCII(美国信息交换码),另一种模式是RTU(远程终端设备)这两种模式的定义见表3
表3 ASCII和RTU传输模式的特性

ASCII可打印字符便于故障检测,而且对于用高级语言(如Fortan)编程的主计算机及主PC很适宜。RTU则适用于机器语言编程的计算机和PC主机。
用RTU模式传输的数据是8位二进制字符。如欲转换为ASCII模式,则每个RTU字符首先应分为高位和低位两部分,这两部分各含4位,然后转换成十六进制等量值。用以构成报文的ASCII字符都是十六进制字符。ASCII模式使用的字符虽是RTU模式的两倍,但ASCII数据的译玛和处理更为容易一些,此外,用RTU模式时报文字符必须以连续数据流的形式传送,用ASCII模式,字符之间可产生长达1s的间隔,以适应速度较快的机器。
(2)ModBus的数据校验方式
CRC-16(循环冗余错误校验)
CRC-16错误校验程序如下:报文(此处只涉及数据位,不指起始位、停止位和任选的奇偶校验位)被看作是一个连续的二进制,其最高有效位(MSB)首选发送。报文先与X↑16相乘(左移16位),然后看X↑16+X↑15+X↑2+1除,X↑16+X↑15+X↑2+1可以表示为二进制数11000000000000101。整数商位忽略不记,16位余数加入该报文(MSB先发送),成为2个CRC校验字节。余数中的1全部初始化,以免所有的零成为一条报文被接收。经上述处理而含有CRC字节的报文,若无错误,到接收设备后再被同一多项式(X↑16+X↑15+X↑2+1)除,会得到一个零余数(接收设备核验这个CRC字节,并将其与被传送的CRC比较)。全部运算以2为模(无进位)。
习惯于成串发送数据的设备会首选送出字符的最右位(LSB-最低有效位)。而在生成CRC情况下,发送首位应是被除数的最高有效位MSB。由于在运算中不用进位,为便于操作起见,计算CRC时设MSB在最右位。生成多项式的位序也必须反过来,以保持一致。多项式的MSB略去不记,因其只对商有影响而不影响余数。
生成CRC-16校验字节的步骤如下:
①装如一个16位寄存器,所有数位均为1。
②该16位寄存器的高位字节与开始8位字节进行“异或”运算。运算结果放入这个16位寄存器。
③把这个16寄存器向右移一位。
④若向右(标记位)移出的数位是1,则生成多项式1010000000000001和这个寄存器进行“异或”运算;若向右移出的数位是0,则返回③。
⑤重复③和④,直至移出8位。
⑥另外8位与该十六位寄存器进行“异或”运算。
⑦重复③~⑥,直至该报文所有字节均与16位寄存器进行“异或”运算,并移位8次。
⑧这个16位寄存器的内容即2字节CRC错误校验,被加到报文的最高有效位。
另外,在某些非ModBus通信协议中也经常使用CRC16作为校验手段,而且产生了一些CRC16的变种,他们是使用CRC16多项式X↑16+X↑15+X↑2+1,单首次装入的16位寄存器为0000;使用CRC16的反序X↑16+X↑14+X↑1+1,首次装入寄存器值为0000或FFFFH。
LRC(纵向冗余错误校验)
LRC错误校验用于ASCII模式。这个错误校验是一个8位二进制数,可作为2个ASCII十六进制字节传送。把十六进制字符转换成二进制,加上无循环进位的二进制字符和二进制补码结果生成LRC错误校验(参见图)。这个LRC在接收设备进行核验,并与被传送的LRC进行比较,冒号(:)、回车符号(CR)、换行字符(LF)和置入的其他任何非ASCII十六进制字符在运算时忽略不计。
  

老古开发网版权所有 2006年9月 asp.Net V2.0 设计:老古,
2007-11-21 19:05:17 页面缓存:30分钟 执行时间:78毫秒
(408073913)

出0入0汤圆

发表于 2007-11-21 19:09:06 | 显示全部楼层
对啊,trinove 有没有MODBUS的文本? 再开个贴学习一下也好嘛 :)
(408073541)

出0入0汤圆

发表于 2007-11-21 19:15:18 | 显示全部楼层
MODBUS一般用四个功能就可以了:读位,写位,读字,写字;所以程序比较简单,主要是多机通信很方便,
(408065741)

出0入8汤圆

发表于 2007-11-21 21:25:18 | 显示全部楼层
我的疑问:

为什么要支持MODBUS,有什么意义?

一个充电器而已有必要如此复杂,本来很简单的东西需要问题如此复杂化吗?
1、充电器有需要多机通讯的必要吗?
2、只是做一个充电器,有必要去支持组态软件吗?是否这样labview、USB、Lin Bus、CAN Bus、Ethernet、1394这些我们都要去支持?


东西好不好、值不值钱无所谓,“实用”才是最重要的。


我们真的有必要做的充电器像现在网上卖的开发板一样,大而全、华而不实吗?像打了水的猪肉?
(408052443)

出0入0汤圆

发表于 2007-11-22 01:06:56 | 显示全部楼层
支持用modbus等现有协议
(408025537)

出20入4汤圆

发表于 2007-11-22 08:35:22 | 显示全部楼层
MODBUS协议
点击此处打开ourdev_182319.pdf(文件大小:172K)
用03 04命令就可以了
组态王:北京亚控科技的工业监视软件,有2小时的试用版
(408022340)

出0入0汤圆

发表于 2007-11-22 09:28:39 | 显示全部楼层
应当使用通用协议,以更好的利用资源
(408022162)

出0入0汤圆

发表于 2007-11-22 09:31:37 | 显示全部楼层
俺建议采用stk500兼容协议

这些工作量最小
(408015950)

出0入0汤圆

发表于 2007-11-22 11:15:09 | 显示全部楼层
哇,大家讨论了这么多啦
呵呵, MODBUS 的标准协议 john78  已经传上去了,

有几点说明的,
1  MODBUS经过这么28年的摔打,历史证明还是不错的。
2  我为什么提出MODBUS,原因是 村长的协议和MODBUS差的不多,而且也是用CRC16的。
3  MODBUS实际使用的时候,并不需要全面的支持其协议的全部内容,向我们这个充电器,支持 0x03/0x10 两条指令就足够了
4  GRANT 担心 MODBUS 太复杂,确实原始协议很复杂,实际简化了也就没什么了。
5  MODBUS 便于大家理解,事实上很多公司都在用这个协议,也就是说,通过对那些设备/软件某种设置,我们的充电器可以和很多东西连接起来。而且不用修改我们的软件、硬件。
6  MODBUS 非常适用于多机通讯,我们充电器不需要,但却是值得推广到网站以后项目中去的。算是打个基础,软件部分可以进行复用。

我只是提个建议,

至于那个STK500的协议,我觉得就不用了吧
(408015427)

出0入0汤圆

发表于 2007-11-22 11:23:52 | 显示全部楼层
为什么不用stk500呢
atmel几乎所有的工具都是用这个协议,现成代码到处都是


MODBUS 过于复杂,简化后又把精髓丢了还不如不用
(408012499)

出20入4汤圆

发表于 2007-11-22 12:12:40 | 显示全部楼层
那就不用讨论了,谁做谁定,谁想用什么协议谁修改.
(408011128)

出0入0汤圆

发表于 2007-11-22 12:35:31 | 显示全部楼层
首先,我说明一下为什么一般不考虑STK500的协议。STK500的协议是ATMEL公司用于自身的开发设备的协议,确实是在ATMEL内普遍适用,然而在ATMEL之外并没有使用的先例。
STK500是开发设备,而不是最终使用的产品,是否经得起干扰、破坏等影响,我们无法进行有效的验证。该协议没有在我已知的任何最终产品或者工业设备上作为通讯协议使用,更无法帮助我们判断该协议的耐用性。
在Atmel之外,没有人使用这个协议,还可能是另一种含义,Atmel对于该协议有某种权利,这样的话,我们就会遇到不必要的麻烦。

其次,Modbus简化了,为什么会说是丢了精髓呢?
我不是很明白,Modbus最多支持256条指令,已知的通用指令约20-30条,保留的指令空间有100多,给用户自定义的空间也有10-20条,本身就有灵活性在里面。我们选择性的支持其中的两条,并不违背Modbus的协议要求。
Modbus的灵活还表现在,既可以用以操作数据存储,也可以直接传输指令。(这个需要自己定义)
Modbus的精髓是什么?  
个人以为: 主从方式(一般为一主多从,可以做多主多从)、多机地址(最大255个地址)、支持数据地址空间0xFFFF、支持多种数据格式、可以直接发送指令、带有CRC16校验。
上述特点,使得MODBUS能够适用于很多场合,Modbus不需要认证、付费,并且是允许修改、添加的。

MODBUS足够灵活,可以使用在不同的物理通讯协议上,232、485、422等工业上常见的通讯线路上,也就是说适合于工厂总线的。
至于USB、Lin Bus、CAN Bus、Ethernet、1394,等总线都有自己的完整的协议,为了能够使用,需要相对完整的实现协议,并且需要特定的硬件设计。


作为一个充电器,确实不需要复杂的通讯协议,村长的协议和简化的MODBUS基本上差不多工作量的,而且设计的思路上差异不大,最终效果也不会有什么区别的。所以不论选择哪个协议,都不是问题。

只是没想到,我提了个头,却给大家带来这么多争议。
用过MODBUS和没有用过MODBUS的人都不会少,我熟悉MODBUS也是因为我和工业设备打交道,对于一直和民用设备打交道的,MODBUS不知道也不足为奇。
民用的协议,很多都是专用的,因为都是单独使用,一般不考虑互联接口的问题。工业设备则不然,工厂里现在越来越多的总线,你若搞自己的协议,你的产品就会少很多市场。

不同的背景,有不同的思维,所以我们对于某个东西的认知肯定是会不一样的。所谓火花,也就是不同之间摩擦产生的。

希望这个火花不会引起大火,呵呵!
(408008880)

出0入0汤圆

发表于 2007-11-22 13:12:59 | 显示全部楼层
Modbus 一般应用于 485 通信协议。

工业中一般我们使用 Modbus 中的 RTU 模式。

但是在我们这个充电器中和 PC 通讯中使用自己定的协议应该也是个不错的选择。



我给个建议,使用两种软件模式,一种以村长为主,使用自己定的协议。

另外一种以阿力为主,使用Modbus,通过硬件的一个预留的拨码开关选择。



虽然我觉得使用Modbus的话可以让程序简单,通用的格式。但是对于一些新人来说定协议也是非常重要的一件事情。

所以我觉得两种都可以留下。对村长来说,兼容两种软件协议,上位机程序也不是很难写。下位机通过宏定义分两种模式进行条件编译。

毕竟这么多人参与,定一个协议不过是一天的工作量,多做几种没有什么难度。
(407978808)

出0入0汤圆

发表于 2007-11-22 21:34:11 | 显示全部楼层
1.【8楼】 john78

十分抱歉的说,您的这个回帖的质量的确不高,LZ是这么设计是“自大”还是“自信”,通过短短一个贴能够判断吗?大家讨论问题最好还是讨论问题,不要太随意跑到人格判断上比较好,不要让别人除了跟你吵架就只能“无语”,可否?本版有些讨论推荐看一下,比如有感讨论与合作的技巧(之一)

*这个充电器如果使用modbus,指令03、04是不足够的,因为上位机需要把设定信息反写回充电器。

2.trinove,我想别担心起大火,只要大家能够就事论事,而不是跑题人格判断上去。还是老思路:首先,大家可以畅所欲言,也不要随便认为别人的想法或者观点有天大的问题,讨论的基础是相互尊重,至少是人格上的尊重;第二点,责任有主次,当核心成员决定了怎么做,不同意见必须搁置,而不是没完没了的讨论。大家讨论的目标是要“说服”,而不是“压倒”,对不对?(当然,也不是妥协,容纳所有意见,我不太支持通过宏编译指令同时支持两种协议,因为如果modbus能做成,第一个协议就没有什么意义了)

学习了村长的协议v0.1和【13楼】mljda 提供的modbus协议。我觉得这两者其实不算冲突了,准确的说,我觉得他们不在一个协议层,modbus相当于传输层的功能,只定义了最基本的通讯协议,而aleyn提供的协议是表示层的,比如他有Device Detect、Get config、Set config这样有语义的指令,己便是使用了modbus,这些命令的定义还是需要的。

底层的差异最主要在于网络支持,modbus提供了寻址和广播功能,并且在基于RS232的线路上实现了多机通讯(希望我没有理解错),这点也不是完全没有意义的。我想我们做充电器,不要局限于在房间角落充两节数码相机或者剃须刀电池这种目标嘛,随便想一下,如果我们可以通过RS232把两个以上充电器串联起来,用一个上位机控制,是否没有意义?或者再设想大一点,如果我们的成果用在一辆以镍氢驱动的环保汽车上,充电模块通过modbus和其他车载系统联网,是否没有意义呢?

当然,最终的决定,我们唯aleyn马首是瞻 :) 大家要理解核心成员的压力,做不做长机,差别还是不小的,一般参与者跟贴讨论,随便聊聊,转头消失仨月,没人会注意到,但是如果aleyn听了哪位的意见,需要帮忙的时候找不到人,所有人都会说:aleyn认领了通讯协议,但无法如期完成。如果是你,你不冤吗?呵呵
(407973896)

出0入0汤圆

发表于 2007-11-22 22:56:03 | 显示全部楼层
很同意楼上拉,呵呵。

我觉得分配完任务后大家尽量个挥其责吧。可以范围小点的情况下面大家先讨论讨论,比如约几个人在qq群上面先讨论下,减少大家的意见不同。
(407926514)

出0入0汤圆

 楼主| 发表于 2007-11-23 12:05:45 | 显示全部楼层
参考了一下Modbus协议,然后把数据结构方面做了一点点修正,今天主要是加入了设备搜索的命令解释.
请版主帮忙更新到楼主位 (v0.2).





简化版面,内容更新到楼主位。(由Grant按楼主要求修改)
(407925977)

出0入0汤圆

发表于 2007-11-23 12:14:42 | 显示全部楼层
首先,我认为只要一个协议就够了
其次,我只是用惯了MODBUS,推荐一下
再次,村长的协议本身和MODBUS的效率、功能差异不大,要比较的话,是不会有结果的。
最后,村长的选择就是最终的决定。对于这个选择,我不需要保留什么意见,同意就是100%同意,支持就是100%支持。

呵呵!

顺便说一下,我自己的系统也是既有MODBUS也有自定义协议的,自定义协议在某些特殊使用情况下,反而比较合适。
(407920354)

出0入0汤圆

发表于 2007-11-23 13:48:25 | 显示全部楼层
干脆用smbus协议算了,基本上是 智能电池的标准
(407920159)

出0入0汤圆

发表于 2007-11-23 13:51:40 | 显示全部楼层
点击此处打开ourdev_182550.pdf(文件大小:103K)
(407920111)

出0入0汤圆

发表于 2007-11-23 13:52:28 | 显示全部楼层
建议按照国际标准做,不要自立山头
(407920029)

出0入0汤圆

发表于 2007-11-23 13:53:50 | 显示全部楼层
Copyright&Oacute; 1996, 1997, 1998, Benchmarq Microelectronics Inc., Duracell Inc.,
Energizer Power Systems, Intel Corporation, Linear Technology Corporation,
Maxim Integrated Products, Mitsubishi Electric Corporation,
National Semiconductor Corporation, Toshiba Battery Co.,
Varta Batterie AG, All rights reserved.


看看有多少家大公司
(407885718)

出0入8汤圆

发表于 2007-11-23 23:25:41 | 显示全部楼层
我的观点:
保持现有的先做,有意见的各自保留。代码的源码(无论上位机还是下位机)都是公开的,软件协议是软件的问题,硬件无需改动,有自己需求的可以自己去更改。什么MODBUS啊、SMBUS啊,如确实大家讨论有必要支持的也可以之后通过后续的固件版本升级再追加。东西都还没出来就上纲上线的,没必要,还是务实一定实在。
(407826030)

出0入0汤圆

发表于 2007-11-24 16:00:29 | 显示全部楼层
支持 Grant
(407576803)

出0入0汤圆

发表于 2007-11-27 13:14:16 | 显示全部楼层
出现这样的讨论根本在与项目的设计者.项目的设计者在做此设计的时候根本就没有考虑到这些.所以项目设计书上没有这方面的要求.另一方面看也可能是出于大家做的方便.个人还是倾向与modbus,协议比较规范,也比较通用.估计以后修改起来也比较方便.村长的协议有局限性.
(407574412)

出0入0汤圆

发表于 2007-11-27 13:54:07 | 显示全部楼层
modbus协议使用的比较多,也比较成熟
我没参加活动,不过建议使用现成的使用量比较多的协议,没必要自己再定协议。
(407547735)

出0入8汤圆

发表于 2007-11-27 21:18:44 | 显示全部楼层
也许36楼的说的也对:出现这样的讨论根本在与项目的设计者。


下面的内容算是我为自己的辩解吧:
我知道很多参与这个活动的人,他们从事着不同的行业,尽管很多的行业可以叫电子,甚至有些还不是电子这个行业。看上去每一个参加活动人都希望将自己最熟悉、最有兴趣的东西加到这个Charger中去。可问题是活动做的是充电器,它就是充电器,仅仅只是一个充电器,它不是万金油!它的主要任务只是为了充电,除去充电的功能其它所有的一起不过是为了辅助充电的一种手段。


我实在不明白支持MODBUS有什么好处,在我看来MODBUS是一个会话层协议,对于它运行的物理层、链路层可以是RS232,也可以是RS485,甚至还可以是ZigBee、MiWi、USB、CAN、Lin Bus,有什么不可能吗?可问题只是个充电器有这个必要非要支持MODBUS吗?本来提供一个RS232的接口只是为了提供PC监控电池数据的一种通讯渠道,我不明白本来是一个很简单的东西大家为什么要把它想得那么复杂、看得那么高深?难道它就真的需要这么复杂高深才能体现它是一个智能的充电器吗?


况且好像现成MODBUS协议也没有规定什么类型设备是充电器吧,做来做去,上下位机不也还是要自己做吗?难道充电器支持了MODBUS,就能像PC上USB的HID类设备,我只要符合规定协议,某些仪器设备就能支持充电器,我们可以不用写上位机?去支持一个复杂些协议,为什么不可以简化一些支持一个简单点协议?MODBUS就算通用,可大家有没有考虑过它实际通用在什么场合?对充电器它通用吗?说起来也许SMBUS可能比MODBUS在电池领域更通用一定。


对于村长目前受到的置疑,我非常理解,毕竟我也不是一次两次这样曾被指出过。我还是那句话:走自己的路。既然选定做核心成员,你可以有权决定你负责的一切,只要大家没有对你的工作提出否定。我的原则:不要最好的,只选最合用的!


如果还有一定要支持MODBUS、SMBUS的参与者,请自行参考34楼回复。
(407541286)

出0入0汤圆

发表于 2007-11-27 23:06:13 | 显示全部楼层
听核心成员的。
(407497755)

出0入0汤圆

发表于 2007-11-28 11:11:44 | 显示全部楼层
我不是要指责谁或者是批评谁,我只是说 问题和出现问题的原因.有问题不怕,就怕有问题互相扯皮.我认为现在只要决策者出来说:"我决定用什么协议!有问题我负责!"这就够了.太多的争论也没什么意义.我觉得:如果一个团队做不到决策者敢拍板,成员做不到服从.这个团队什么也做不成.
(407486798)

出0入0汤圆

发表于 2007-11-28 14:14:21 | 显示全部楼层
村长用自定协议就用了。以后源码是公开的,需要MODBUS或SMBUS的,自己改程序就是了。
这个项目主要是对开源和组织形势的探索,对项目管理的贡献要大于技术。
(407485274)

出0入0汤圆

 楼主| 发表于 2007-11-28 14:39:45 | 显示全部楼层
我来定了下结论好了。

首先,规格书上有“上下位机通讯协议”这项要求,但没有规定用什么协议,所以,我决定,用自定议的协议,这样的话,也避免版权问题。

第二,目前这个自定义的协议,是基於应用层的,至於物理层用什么,那是另一回事了。

第三,这个项目的主要负责人是Cocal和Grant,所以,用什么方式和方法是负责人决定,我们服从命令。

第四,在上位机方面,我会尽力将协议部分独立,这样的话,以合要改协议或者是自适应协议,都可以做到。

第五,已经是决定了的东西,就不会再改变了,这样会浪费时间和精力的,请大家支持。
(407483482)

出0入0汤圆

发表于 2007-11-28 15:09:37 | 显示全部楼层
支持村长
(407477995)

出0入0汤圆

发表于 2007-11-28 16:41:04 | 显示全部楼层
支持村长,顶一下!
(407470227)

出0入0汤圆

发表于 2007-11-28 18:50:32 | 显示全部楼层
好,有魄力。全面支持!
(407461385)

出0入0汤圆

发表于 2007-11-28 21:17:54 | 显示全部楼层
我也支持村长 :)
(407460141)

出0入8汤圆

发表于 2007-11-28 21:38:38 | 显示全部楼层
这就对了,以后我也不用一上来就要表面态度,令我多难为情。

村长板上钉钉的事,我肯定支持!
(407456964)

出0入0汤圆

 楼主| 发表于 2007-11-28 22:31:35 | 显示全部楼层
版本更新,目前为 v0.3
请版主帮忙更新一下到楼主位.


以下内容由Grant增加:
为优化版面,方便阅读,原协议内容移至顶楼。
(407196248)

出0入0汤圆

发表于 2007-12-1 22:56:51 | 显示全部楼层
我也支持村长
,要支持其它协议可日后加上
(406936914)

出0入0汤圆

 楼主| 发表于 2007-12-4 22:59:05 | 显示全部楼层
版本更新,目前为 v0.4

更新内容:
1)加入放电设置,快充设置.
2)加入电压上限,温度上限.
3)重新排版.



以下内容由Grant增加:

为优化版面,方便阅读,协议内容移至顶楼更新。
(406936694)

出0入0汤圆

发表于 2007-12-4 23:02:45 | 显示全部楼层
顶一下村长,原理图告一段落,和你研究协议拉。嘿嘿!

赞一下村长的热情!
(406934304)

出0入0汤圆

发表于 2007-12-4 23:42:35 | 显示全部楼层
我提两个小建议,和村长商量一下:

1: 对你的 C3 设置,我想是不是需要先增加一下状态查询.相当于分别为读和写操作
   我想是不是通过 " C2 ": 作为状态查询," 其中 "C2" 是举个例子 " 作用为从下位机中读出已被设置的项.

2: 对于参数设置是不是需要考虑一下大类: 电池种类.
   因为我个人认为每一种电池可能里面的参数选项是不一样的.


对于里面的具体参数是和电池软件算法有关,因此在具体软件流程图定下前我就不发表意见了.
(406895452)

出0入0汤圆

 楼主| 发表于 2007-12-5 10:30:07 | 显示全部楼层
to 【52楼】 lvhaian 安哥

1).主类别已经有读状态专用的命令(2D),而且,和C3相对应的命令D2,也可以做到.
所以,你的考虑我已经包含在内了,呵呵.

2).电池种类这东西,是针对上位机来说的,对协议就没这个必要了.
因为上位机可以跟据用户所选择的"电池种类"策略而载入不同的参数设置.
假如下位机需要储存几种常用的"电池种类"策略来供用户选择的话,倒是可以增加"电池种类"这一大类.
(406892589)

出0入0汤圆

发表于 2007-12-5 11:17:50 | 显示全部楼层
To: 【53楼】 aleyn 煮茶村长

(1)我看的太粗心了,现在看到读指令了。呵呵!
(2)恩,行。你觉得没有问题当然比较好。

     我当时顾虑的是比如读出电池数据,画出电池充电曲线,可以显示出你显示的是什么电池。
     可能认为协议中没有这个电池种类的字节的话上位机没有办法进行智能曲线分析。


     我举个例子看看给你看看,不知道我的看法对不对。
     比如我在下位机充电的时候正在对一节理电池充电 和 只对两节镍氢电池同事充电 这两种情况下面。

     对于我没有手动上位机的策略选择,在只插上充电器的通讯线后就没有办法自动分辨种类拉。其实正如你写的那样已经在下位机中存储过电池种类这一选项(下位机没有这个选项就必然电池要爆炸了),但是你在界面中的电池种类不是你实际充电的种类,那么分析的数据就全部错了,你觉得呢?
(406890841)

出0入0汤圆

 楼主| 发表于 2007-12-5 11:46:58 | 显示全部楼层
to 【54楼】 lvhaian 安哥

对於你的第二点,我也不大懂,估计要等硬件出来后才会有一个感性认知的过程.
所以,我先按你的要求,协议上加上"电池种类"这一项,这一项我安排在小类(D2,C3)里面,作为一项配置来处理.
(406418233)

出0入0汤圆

 楼主| 发表于 2007-12-10 23:03:46 | 显示全部楼层
版本更新,目前版本为 v0.5

更新内容:
1)加入涓流设置,充不满设置
2)应lvhaian 安哥要求,加入电池种类
3)加入液晶设置,脉冲设置,其它设置


以下内容由Grant增加:
优化版面,方便阅读,内容移至顶楼。
(406385199)

出0入0汤圆

发表于 2007-12-11 08:14:20 | 显示全部楼层
村长,很不好意思,我对于这个协议认为有些不妥.
协议本身不需要这么多操作,单纯读写就能解决很多问题,目前对于下位机的读写缺乏地址,而只是对某个功能进行设置.
理解上好看,操作起来容易混乱.

建议使用一张连续的表,按地址进行定义,直接对地址进行读写操作.适应性强,数据表中增减任何定义的内容,不影响协议的操作.

可以使用数据包的头和尾标志,但是数据包内不需要进行转意.
原因很简单,我们收发一个数据包,都是整体处理的,数据包内字符与字符间的时间间隔是很短的,而数据包和数据包之间的间隔是非常长的.这里我们应该学习一下MODBUS的数据包判定的方法,假设发送一个字节需要的时间为t,则在接受到一个字节后超过2.5t之后,就可以判定数据包已经结束,数据包的头尾标志起到辅助判定的作用,CRC16起到校验内部数据的作用。以此方式可以很方便的进行数据包的处理,适应各种长度的数据包,并对于错误的发送以及受到干扰的信息可以很快地予以排除。

村长现在的协议考虑了太多协议以外的数据定义,导致协议开始变得庞大复杂以及难以操作。

举个例子吧,比如电池类型、充电模式还有液晶显示等等内容,都是对于数据表的定义,而不是协议的定义,把这部分内容加到协议中的话,其实是在无形的增加自己的负担以及限制自己的灵活。还有液晶的显示是收到固件中的应用程序控制的,是否接受电脑的控制是另一回事,而且这部分应用程序是开放设计的,必须要考虑到大家不同的需求。
增减参数就需要改变协议,这点并不合理。

目前村长的协议其复杂程度和灵活性已经开始劣于MODBUS了,希望村长再接再厉,把协议更加完善。
(406368048)

出0入0汤圆

发表于 2007-12-11 13:00:11 | 显示全部楼层
同上:
一个设置一个包,太烦了。
特定的字节为特定的信息最好弄了。
要不解码好占资源的。
(406358314)

出0入0汤圆

 楼主| 发表于 2007-12-11 15:42:25 | 显示全部楼层
TO 【57楼】 trinove 阿力
CC 【58楼】 mljda 一起长大

1)建议使用一张连续的表,按地址进行定义,直接对地址进行读写操作.适应性强,数据表中增减任何定义的内容,不影响协议的操作

--> 这是一个个人考虑问题的角度的问题。

第一种方法:假如,上位机要把所有的配置一起发给下位机的时候,这时,用一张连续的表绝对是一个比较好的方法,特别是配置
多的时候。但,这又有另一个问题,如果,上位机只是仅仅改动一处配置的话,这时,也还是同样也这张连续的大表的话,就显示
太过累赘了。

第二种方法:分配成各个小的配置包,就象现在这个样子。那么,效率跟第一种方法是相反。要传送所有的配置的时候,需要把各
个小配置都一并发送。但它的优点是,如果只是仅仅改动一处配置的话,它就只需要发送相当小的数据就可以了。

这两种方法取决於是哪种用法比较多,是经常一次性发送所有的配置,还是经常改动一处或者几处配置而已。
但不管是第一种方法还是第二种方法,最终存取到存储器的,都是一样的。


2)这里我们应该学习一下MODBUS的数据包判定的方法,假设发送一个字节需要的时间为t,则在接受到一个字节后超过2.5t之后,
就可以判定数据包已经结束

-->这需要使用到计时器了,在目前计时器资源比较紧张的情况下,还需要再三考虑一下是否可行。
目前这个协议是跟据数据内容来判断包的起始和结束的,而不是通过时间来判定的。
这样的话,也能最大限度避免占用计时器,也可以让几个包连续不停的收发。
而且,在发送端发送后接收地址后,会有一定的时间让下位机做过地址判断,如果用MODBUS的方法的话,不知会不会引起误判。


3)比如电池类型、充电模式还有液晶显示等等内容,都是对于数据表的定义,而不是协议的定义,把这部分内容加到协议中的话,
其实是在无形的增加自己的负担以及限制自己的灵活

-->电池类型这一项是跟据【52楼】和【54楼】 lvhaian 安哥 的建议加进去的。
充电模式还有液晶显示这两项,是可加可不加的,当时是我看到下位机有这样的功能而加进去的,方便用户从上位机去调整,
如果大家觉得这两项不妥的话,可以去掉。


4)增减参数就需要改变协议
-->如果协议定义得好一些的话,这点是可以尽量避免的。这方便需要大家一起来
(406333067)

出0入0汤圆

发表于 2007-12-11 22:43:12 | 显示全部楼层
To 村长

使用一张连续的数据表,并不表示每个数据包都要操作整张表呀!
可以一个一个字操作、也可以多个字操作,根据MODBUS的话,还可以一个位一个位的操作的。

数据表的长度可以很长的,通讯的时候是指定地址进行操作的,需要操作多少个字节也是在数据包中进行指定的。
根据地址进行操作,具有后期的灵活性,可以通过改变数据表的长度、定义以实现不同的功能设置,而不需要对协议进行任何改动。

使用通讯超时的判断,并不需要为此而另设一个定时器出来,完全就是在同一个定时器内完成的操作,只不过使用一个变量来做计数器罢了。所以不存在硬件负担的问题。
MODBUS中,主机发出查询指令,等待从机响应是有设定的最大时间的,超出最大时间就认为数据包丢失或下位机丢失,会重新发送。而这个最大等待时间我一般设置为3-5秒,超出没有回答,就会接着发送。AVR我之前做个的MODBUS,响应时间一般都在10ms以内,这个值包括来回的数据传输时间以及下位机的处理时间。
所以误判基本上是不可能的。

如果想把参数都在现在就全部考虑到协议中去的话,太不现实了,我们大家都是依照自己的想法在设定参数的需求,也就是说我们现在能够定下来的不过是一些基本参数,对于以后充电中到底还会需要用到多少参数,谁也说不清。
充电方法有很多种,自然带来了充电的参数也会有很多不同。
我设想使用数据表,进行地址指向的数据通讯,除了基本参数进行规定名称内容,然后空下很大一块数据表的空间,划分为若干个数据块,之后大家在写各自独特的充电应用程序模块的时候,在程序头标明使用的是哪个数据块,各个数据什么含义。这样我们就可以融合多个应用程序模块共存在一起运行(前提是使用不同的数据块),而且大家可以任意发挥自己的才干,可以自定义自己需要的参数进行设置。
(406297580)

出0入0汤圆

 楼主| 发表于 2007-12-12 08:34:39 | 显示全部楼层
to 【60楼】 trinove 阿力

-->使用一张连续的数据表,并不表示每个数据包都要操作整张表呀!
-->可以一个一个字操作、也可以多个字操作,根据MODBUS的话,还可以一个位一个位的操作的。

这一段能不能详细的示例一下,我没搞明白这一块的意思,假如能行,那么协议就能做一些改善了.
(406288870)

出0入0汤圆

发表于 2007-12-12 10:59:49 | 显示全部楼层
呵呵,如果改的话现在的东西都要抛弃的。

我觉得既然做了别那么大改动了。

我认为阿力说的和村长方法都是可以的。
(406283204)

出0入0汤圆

发表于 2007-12-12 12:34:15 | 显示全部楼层
在发送 读写指令 之后 加上 目标的数据地址,
对于写指令再加上写入数据的数量,以及写入数据的内容。
对于读指令需要加上需要读出数据的数量

详细的还是请参考MODBUS的协议,只要看其中 03和16两条指令的解释就行


两种方法当然都是可以运行的,没问题,问题在于以后的扩展以及部分参数的复用等工作。

没有足够的余量和灵活性,对于以后的扩展将是很累的活。
(406278419)

出0入0汤圆

 楼主| 发表于 2007-12-12 13:54:00 | 显示全部楼层
【63楼】 trinove 阿力

-->在发送 读写指令 之后 加上 目标的数据地址,
-->对于写指令再加上写入数据的数量,以及写入数据的内容。
-->对于读指令需要加上需要读出数据的数量

我明白了,这种方法我做过,我把这两种方法都做进协议里头吧,这样的话,就可以两种方法都可以共用了。
因为这一种方法的话,只需要加入一个配置命令就可以了。

至於下位机,可以选择只支持第一种,或只支持第二种,或两种都支持,只是需要先在设备搜索应答的时候,
做出相应的回应就可以了。
(406012583)

出0入0汤圆

发表于 2007-12-15 15:44:36 | 显示全部楼层
如果设置失败,从机应答是否如下:

目的设备地址
应答设备地址,即本身地址

主类别[1E]Raise Error--------
明细类别[C3]

04-0E共11个字节是系统保留区。
此区为以后的扩展使用,目前版本请
保持此区数据都为[FF]。
参数组字节数,没有任何附带参数,所以填[00]

没有设备忙的主类别啊!
如果下位机正在充电,这时候上位机要更改充电相关设置,应该返回什么啊!
(406010401)

出0入0汤圆

 楼主| 发表于 2007-12-15 16:20:58 | 显示全部楼层
呵呵,我今天剛好也看到這個問題,已經修正了,在v0.6的時候改過來。
(406010225)

出0入0汤圆

发表于 2007-12-15 16:23:54 | 显示全部楼层
发送缓存构建的数据包;
_headCreate(usart.head,HIS_ADDRESS,PC_ADDRESS,DEVICE_DETECT,NODEFINE,0);/* 主机收索 */
sendPACKbufEncodeCRC16(&usart.buf[0],16);
响应包都用flash存储
void sendPACKpgmEncodeCRC16(const prog_uchar *prg,unsigned char num);

/* 发送版本信息 */
#define _ASKVersNameInfo(Daddr)\
        _putchar(PTC_F_BEGIN);\
        _headCreate(usart.head,Daddr,THIS_ADDRESS,RESPONDER,DEVICE_DETECT,VNI_CHAR_LEN);\
        sendEncodeCRC16(sendPgmEncodeCRC16(VernName,sendBufEncodeCRC16(&usart.buf[0],16,0)));\
        _putchar(PTC_F_END);
/* 发送设置包 */
void sendEncodeCRC16(CRC16 crc16);
CRC16 sendBufEncodeCRC16(unsigned char *buf,unsigned char num,CRC16 crc16);

#define _putCharge(head,Daddr,Saddr,Mct,Sct,Dc,set)\
                _putchar(PTC_F_BEGIN);\
                _headCreate(head,Daddr,Saddr,Mct,Sct,Dc);\
                sendEncodeCRC16(sendBufEncodeCRC16(set,Dc,sendBufEncodeCRC16(&head.DA,16,0)));\
                _putchar(PTC_F_END)
(405767650)

出0入0汤圆

 楼主| 发表于 2007-12-18 11:46:49 | 显示全部楼层
版本更新,目前版本为 v0.6

1)修正从机应答时无应答状态
2)加入获取参数设置
3)加入连续表的方式
4)在设备搜索指令中加入协议支持方式

Battery Charger Software Protocol v0.6.pdf(文件大小:1.61M)



以下内容由Grant增加:
为优化版面,方便阅读,帖子内容移至顶楼。
(405761564)

出0入0汤圆

发表于 2007-12-18 13:28:15 | 显示全部楼层
顶一个!!!!!!!!
(402377925)

出0入0汤圆

发表于 2008-1-26 17:22:14 | 显示全部楼层
粗一看我还认为是从哪个大公司搞来的通讯协议呢,已经很不错了。ModeBus协议确实不错,本人前几天刚下来看了几页。不过要完全按照ModeBus协议的规定来做还是不容易的,工作量也会不小。我个人对于非产品项目没有必要完全按照某种现存的协议来做,不过可以借鉴其中的一些思想。具体到这里的上下位机通讯协议来说,我们可以在上下机之间发送消息的时候,借鉴ModeBus协议的消息格式,这样做增加的工作量很小,同时我们可以比较自由的按自己的想法来做事。
(402364296)

出0入0汤圆

发表于 2008-1-26 21:09:23 | 显示全部楼层
说个大家可能不愿意的意见,我想问一下搞这个的都是中国人吗?如果不是的话,那么当我下面的话没说。
    是我们自己做的东西为什么非要做些英文的放在前面?自己都看不起自己的语言?还是感觉英文写在前面特有水平?
说句实话,现在在外面看到这种情况特别反感,好多东西明明就是国产的,非要做一大堆英文在外面,有的更好干脆找不到中文!这种感觉我想有很多人都在骂,但是为什么都只是说人家,而不能从自己开始改变这种情况?另外这个项目是个开源项目又不是受利益驱动,为什么不以这个为开头?
    我并不反对在这些资料里面加入英文(或者其他语言),但总要体现原始设计者语言吧?至少我认为这个开源项目里面所有的文档均以中文放在第一位,并且在英文里面也要注明以中文为准!
    本来感觉不错,可惜看到文档后就没有心情继续看下去了。肯定是有好多人说我这太偏激。只是想说一句话吧。我想很多人知道有句话说的是:如果自己都看不起自己就别指望别人能看得起自己,在这里这句话同样适用吧?我们自己都看不起自己的文化,还想让别人看得起?我认为从这点小事情也能够看出来一些问题吧?别想的太高了,也别想去做那些不现实的东西。例如有些人说过抵制日货,其实真的能吗?这些东西在一个思想上,不是在口头上说的。
    再说一个问题,就这个项目不是说准备以后整理出来吗?如果整理了,肯定会被在网络上传播,过段时间再看吧,或者我们就听别人说,看有多少人相信这是我们这里的人开发的?你做的越好越不相信你,如果你你们开发的为什么资料全是英文的?(从这上面感觉明显是原始资料是英文的,中文不过是翻译过来的)
    我尊重原始设计人员的努力,不过希望大家不要把在公司里面形成的习惯放到这里了,让我们尊重一下自己的文化吧,毕竟现在这种情况太少了,在公司里面设计你没办法,你说了不算,但这是个开源项目,应该不会有人强制吧?不希望多少时间后连设计人员的努力都被人否认了。
(402277856)

出0入0汤圆

发表于 2008-1-27 21:10:03 | 显示全部楼层
to : 【71楼】 ssyniuej
protocol 就是这样写的,全中文的通信协议也许只有在“中文系”才有吧。
不要把MCU和自己的文化联系在一起,这2者没关系的。
与港澳台不同,当今国内的意识形态完全来自西方,我想着点你不得不承认吧。
中国本土文化是不能占据意识形态的主导地位的。所以在国内“尊重一下自己的文化吧”是与意识形态相矛盾的。
This is a terrific project, please focus your attention on technical issues.
(401860418)

出0入0汤圆

发表于 2008-2-1 17:07:21 | 显示全部楼层
顶一下72楼的.个人认为71楼还是保留意见.
(401435587)

出0入0汤圆

发表于 2008-2-6 15:07:52 | 显示全部楼层
写的太好了(我是初学),让人一看就会用。
(401433184)

出0入0汤圆

发表于 2008-2-6 15:47:55 | 显示全部楼层
漂亮!
(372384317)

出0入0汤圆

发表于 2009-1-7 20:55:42 | 显示全部楼层
mark
(372247392)

出0入0汤圆

发表于 2009-1-9 10:57:47 | 显示全部楼层
支持57楼说法,最近我们公司就面临通讯协议修订问题,旧协议是根据功能制定的,每次添加一个新功能就要修改协议,通用性较差,我就力推Modbus协议,建个数据表,每个地址映射一些功能,这样很灵活,
(329549663)

出0入0汤圆

发表于 2010-5-18 15:26:36 | 显示全部楼层
好强悍
(301614705)

出0入0汤圆

发表于 2011-4-6 23:09:14 | 显示全部楼层
mark
(301608906)

出0入0汤圆

发表于 2011-4-7 00:45:53 | 显示全部楼层
真有才!!
(293001713)

出0入0汤圆

发表于 2011-7-15 15:39:06 | 显示全部楼层
mark
(292937727)

出0入0汤圆

发表于 2011-7-16 09:25:32 | 显示全部楼层
挺好的,学习了。最近也做一个需要的自定义协议的小项目。

有个问题想请教村长:是不是当上位机发送的指令信息是变长的时候,只能以最长的指令长度为标准,其它短指令补齐呀?
(292934528)

出0入4汤圆

发表于 2011-7-16 10:18:51 | 显示全部楼层
看完协议后,我觉得应该用MODBUS,没想到大家早就说应该用MODBUS了,呵呵,MODBUS只要定义寄存器就可以了,村长的命令写的太多了,辛苦啊,

MODBUS是开放了,简单,有很多软件支持,代码支持,村长的协议理解太麻烦啦
(274394959)

出0入0汤圆

发表于 2012-2-16 00:11:40 | 显示全部楼层
mark
(274360335)

出0入0汤圆

发表于 2012-2-16 09:48:44 | 显示全部楼层
mark!!!
(274359719)

出0入0汤圆

发表于 2012-2-16 09:59:00 | 显示全部楼层
哇 这个充电器牛逼!!!!!!!!!!!!!1
(274347130)

出0入0汤圆

发表于 2012-2-16 13:28:49 | 显示全部楼层
modbus 协议 自定协议
(151017837)

出0入0汤圆

发表于 2016-1-13 23:37:02 | 显示全部楼层
不错,稍作修改应该可以在其他地方应用
(150967075)

出0入0汤圆

发表于 2016-1-14 13:43:04 | 显示全部楼层
收藏,顶一个
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子论坛 ( 公安交互式论坛备案:44190002001997 粤ICP备09047143号-1 )

GMT+8, 2020-10-26 21:00

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表