Thursday, November 9, 2017

LabVIEW下UTF8编码格式的转换

        延续前面的一个话题(公众号LabVIEW-Jobs下回复TTS或百度,直接返回上期话题),上期谈到的文字转语音,是同时支持中英文的。对于英文来说,比较简单,直接输入英文字符串就可以了,但是对于中文的输入,就涉及到编码的转换。需要将中文转换为UTF8编码格式,然后再输入到URL中,才能被识别。


        LabVIEW没有在程序框图面板直接提供这个函数,但是实际上在老版本的LabVIEW的Email发送函数里面已经内置了。在网络应用方面,经常遇到编码问题的。所以今天是搬运工,直接搬运出这个函数。在安装目录下C:\Program Files\National Instruments\LabVIEW 2013\vi.lib\Utility\SMTP,打开smtpeml.llb,看到了熟悉的身影了。

        再打开这个VI就可以看到我们想要的函数了text to UTF-8,拷贝出来就可以直接使用了。

        不明白的是,NI始终没有将这个基础函数放置在函数面板,论坛上一直都有这个话题的讨论。LabVIEW更新了这么多版本,至今都没有开放出来。但是毕竟还是出自官方,所以这个函数的可靠性应该是没有问题的。另外,从UTF8编码反向转换为字符的函数,NI老版本也一样提供了。

        除此外,坊间也有很多其他方法来实现这个功能。在其他语系里面,也算是一个基础函数了。

        延续上次的话题,需要将中文先转化为UTF8编码,然后分解为16进制并添加%作为转义字符才能完美地被识别。参考下面的截图:

Reference
转载自微信公众号:LabVIW-Jobs (This post is forward from Wechat account: LabVIEW-Jobs)

有疑问可以联系support@itestgroup.com
Any question or feedback, please contact with support@itestgroup.com

Sunday, November 5, 2017

TTS:LabVIEW下调用百度TTS API实现文字转语音

        大概2年前吧,接到客户的一个需求:测试结束后能不能把测试结果用语音播报出来?一些人机配合的地方,也加上语音提示。当然了,这完全是没有问题的,不就是播放一些音频文件嘛,LabVIEW自带就支持wav文件的直接播放。然后就是怎么制作这些语音文件呢?总不能自己录吧,那太土了!现在各大手机导航平台不都支持各种语音风格么,当时就找到了百度语音。使用百度语音TTS来制作这些语音文件。当然,当初只是在线生成了几个固定的语音文件。强迫症患者表示,一定要实现自动在线转换。今天就是这个主题。


        第一步,首先的注册一个百度开发者账号,这个是免费的。http://yuyin.baidu.com/tts,百度目前提供三大语音服务(识别,合成,唤醒),而TTS就是我们这次所要用的语音合成服务。创建一个应用,会自动生成三个参数:App ID, API Key以及Secret Key。这是几个非常关键的参数,后续会用到。

        第二步,获取Access Token,这个就需要用到第一步获取的两个参数。具体参考百度官方教程:http://yuyin.baidu.com/docs/tts/135。 摘录如下:

        使用语音识别及合成REST API 需要获取 Access Token。Access Token 是用户身份验证和授权的凭证,语音识别采用的是Client Credentials授权方式,即采用应用公钥(Api Key)、密钥获取Access Token,适用于任何带server类型应用,通过此授权方式获取Access Token仅可访问平台授权类的接口,使用Client Credentials获取Access Token需要应用在其服务端发送请求(推荐用POST方法)到百度OAuth2.0授权服务的" https://openapi.baidu.com/oauth/2.0/token "地址上,并带上以下参数:

  • grant_type:必须参数,固定为"client_credentials";

  • client_id:必须参数,应用的 API Key;

  • client_secret:必须参数,应用的 Secret Key;

        响应数据包如下所示,其中 "access_token" 字段即为请求 REST API 所需的令牌, 默认情况下,Access Token 有效期为一个月,开发者需要对 Access Token的有效性进行判断,如果Access Token过期可以重新获取。百度目前的有效期是一个月,但是失效后可以自由的再生成一个新的Token,所以在写程序的时候通常就是先判断Token是否有效,如果失效就重新生成一个,这个刷新的过程目前好像没有限制。


        第三步,生成语音文件。具体参数详见官方说明http://yuyin.baidu.com/docs/tts/136。通过HTTP协议下的POST或GET模式均可以完成。LabVIEW代码也非常简洁:一个VI即可。


        通过百度语音工具包,可以让语音播报功能跟语音导航一样丰富多彩。有几点说明:中文需转化为UTF-8编码,每次转换的长度不能超过1024字符,也就是512个中文,服务完全依赖百度的免费政策,不能保证永久有效,文中方式需网络支持,目前百度SDK也支持离线转换。


       完整代码如下图



        公开本次测试的密钥,不想注册百度开发者的用户也可以直接使用。

API Key: HxPBVGrRw2w20kmXljrPW6rj

Secret Key: FkmLKunqnBTZY8w2t5sGFKXHvKBgu1YX

Access Token:24.6bf26153cd4a81e4e1c79d6da89d6add.2592000.1512442552.282335-5203061(目前有效期还有一个月,过期后需要根据上述第二步自己重新生成。)


需要VI代码的可以联系support@itestgroup.com

If need the demo code of this post, please contact support@itestgroup.com


Sunday, October 29, 2017

【WORD】LabVIEW如何读取Word文档

Title: How to read the MS Word documents by LabVIEW

        前不久,有一个测试软件所产生的测试报告全部是PDF格式。嗯,这已经不是第一次遇到PDF格式的测试报告了。客户紧急需要统计测试报告的数据,做一个数据分布图出来。而且还是下班后收到的请求,这事儿搞的有点大,至少有几百个PDF文件的数据要统计吧,如果纯人工抄录,然后再统计,这活可不容易啊――纯体力活啊。

        通常的话,无论是数据库还是Excel,文本txt或者Word格式的文档,都是可以通过软件写个脚本来实现自动化的,但是对于PDF来讲,还是有点困难的。PDF格式既是一种通用格式,但是又不具备可编辑性。短时间内完成这个脚本还是不容易的。目测了这个PDF格式的内容,有表格有图片有文字有数字,还是比较丰富的。而对于数据统计有意义的就是文字与数字。所以确定了方向:PDF先转化成Word,然后Word再转化为text,最后读取数据统计分析。


        PDF转Word,网络上有很多工具与服务,也收集了很多工具,有收费的也有免费的。这次选择了国产办公软件金山WPS,免费,而且支持批量转化,速度与质量都不错。

        

图1、就是这个工具,来自WPS,好歹也出自名门

图2、支持多文件一次性导入,操作方便,转换速度也不错,值得推荐

        几百个文件,几分钟就转换成一个个独立的同名Word文档,剩下的任务就是用LabVIEW来读取Word文档的内容了。


        整体上来讲,是使用了Microsoft ActiveX API函数。这里有一点惊喜的是,电脑没有安装微软的Office套件,只安装了金山WPS套件,还以为没有这些API函数,结果是WPS也兼容了MS的API,不需要安装MS的Office套件也能找到这些函数。(此处存疑,电脑确实没有安装MS Office,以前也没有安装过MS Office,但是API确实是可以用的。)


        

        使用LabVIEW的automation open打开MS的Word应用的引用,这里就是一个惊喜:并没有安装MS家的Office套件,只安装了WPS套件,居然也是完全兼容的。

        使用Documents属性节点访问文件,然后再通过Open方法节点打开指定的文件,这里有很多参数可选,比如编码、格式、密码等等,根据具体需要来设置。对于目前这个简单的文档,只需要设定好文件路径即可。

        通过文件属性节点访问内容Content (MSDN的描述:Returns a Range object that represents the main document story),当然当你用鼠标下拉后会发现,这里可以访问的东西很多很多哦,比如密码、打印设置、标题、表格、读写权限。。。多达几十项。我们这里只需要读取文本,就选择了Content属性节点。

        通过Range属性节点去访问文本text,就可以得到全部的文本内容。当然,这里也有很多其他节点可以尝试,可以读取到其他内容与参数。MSDN的描述:The Text property returns the plain, unformatted text of the range. When you set this property, the existing text in the range is replaced.

        在代码的最后面,就是对读取的文本进行了一些简单的处理,再进一步就可以导出到Excel里面做数据统计分析了。


        有几点说明:PDF转Word不是万能的,因为PDF本身是一种非常广泛的万能格式,不是所有的PDF都可以转化成有用的Word格式。另外,如果Word格式过于复杂,在使用API读取的时候需要格外小心,以免数据读取错误或丢失。


        延伸两点:LabVIEW也是可以生成丰富多彩的PDF格式报告的;也可以生成丰富多彩的Word/Excel格式报告的,也就是使用报告生成工具包RGT。


        API参考资料:https://msdn.microsoft.com/en-us/VBA/Word-VBA/articles/document-object-word


       有疑问可以联系support@itestgroup.com

       Any question for this post, please contact support@itestgroup.com


Sunday, September 24, 2017

PCA9540之应用(2-channel I2C multiplexer)

        这是一款来自NXP的很老的芯片了,现在都升级为PCA9640了。是一颗很容易理解的二选一开关,在很多场合都可以应用到这种简易的IIC开关,便于系统的扩展。之所以把这么一颗简单的IIC开关拿出来,只是因为前段时间犯了一个错误导致花费了一些时间,故而记录一下。

        

器件地址

这是器件地址,很好理解,按照上篇讲到的7位地址则为0x70,即111(MSB),000(LSB)。而且这个地址全部是全固定地址,硬件无法改变,从另外一个角度来讲,一个Master下只能接一个这种开关,无法扩展多个。


控制寄存器


很明确,这里就是后三位用于开关的通道选择,由于本器件只有两个通道,所以3bit已经足以达到目的。


状态表

也很清晰,0x00是上电默认状态,此时任何一个通道都没有选通;0x04则选通的为通道0;0x05则选通的为通道1. 其中D3至D7位无需考虑,有用的只有低3位。


写寄存器

        这是写操作,请注意的是这里。这里是直接写控制寄存器,并没有常规理解上的寄存器地址。也就是说,在发送完器件地址,收到响应后直接发送控制寄存器值即可,无需先发送地址。如果一定要说地址偏移量,也可以说成是0.也即offset设置为0.因为此类IIC器件的功能非常简单,并没有太多的内容需要操作,所以并没有分区分块的操作。


读寄存器

        这是读操作。从上图可以看出,也是非常简单,只需要将R/W位改为1即可,也是没有所谓的地址的。

        当初所犯之错误就在这里,想当然的将读写地址设置为0x00。这样在写的时候还好,没有实际影响,但是在读的时候实际是有一个"地址" 的动作,这样实际写入的就是0x00,也就是说将此前已经实际写入的寄存器值(0x04或0x05)又覆盖掉了,覆盖成0x00,故而一个通道都没有打开。


--------
Any feedback, please contact @ support@itestgroup.com

Saturday, September 2, 2017

【iTestGroup】IIC总线地址之解惑

在实际项目中,经常会遇到客户对器件地址有不同的定义,刚开始总是非常困惑,不清楚7位地址与8位地址之间到底怎么转换,有些甚至还有10位地址。经过一段时间的摸索,也总算是弄明白了,记录一下。


7位地址:

在7位寻址过程中,从机地址在启动信号后的第一个字节开始传输,该字节的前7位为从机地址,第8位为读写位,其中0表示写,1表示读。
slave-address-fig1.png
图1:7位寻址。I2C总线规范规定,标准模式I2C,从机地址为7位长,其次是读/写位。
任何I2C设备都必须遵循这个标准,大部分的从机地址即为这7bit地址,不包含读写位,读写位会根据不同的函数自动添加进去。这就是我们最常见的7位器件地址。

8位地址:
一些厂商在提供从机地址的时候说的是包含了读写位的8bit地址,比如他说写地址为0x92,读地址为0x93,如下图所示
slave-address-fig2.png
图2: 8位寻址
这种情况下,只需要将这个地址的前7bit提取出来,比如为0x49。所以这里很关键的一点是:7位地址的编码规则是xxx:xxxx的分隔形式。从8位地址转换到7位地址时,舍弃掉读写位,也就是最后一位后,按照xxx:xxxx的格式再次编码即可。
还有一种方式可以判断厂商提供的地址是7bit模式地址还是8bit地址模式的地址,7bit地址模式下,地址的取值范围在0x07到0x78之间,若超过了这个范围,那么这个地址可能就是8bit地址。
slave-address-fig3.png
图3:有效的7bit地址范围

10位地址:
I2C总线的10bit寻址和7bit寻址是兼容的,这样就可以在同一个总线上同时使用7bit地址和10bit地址模式的设备,在进行10bit地址传输时,第一字节是一个特殊的保留地址来指示当前传输的是10bit地址。
slave-address-fig4.png
图4:10bit地址寻址
在使用10bit地址模式的时候,分两个字节依次传入数据即可。

Reference:
  1. http://www.usbxyz.com/archives/202
  2. IIC-BUS Specification and User Manual (http://www.nxp.com/documents/user_manual/UM10204.pdf)




Saturday, June 10, 2017

【iTestGroup】MLX91206 series Offline Auto-Programming Machine

一、验证烧录 (Verification of Programming)


1. 验证的主要依据: 客户手动烧录手册 Programmierung_Melexis.docx),我们根据烧录器PTC-04以及MLX91206芯片的理解与分析,分析的主要依据有烧录器以及芯片的官方说明书,数据手册等文档。

 Basis of Verification: Programming Manual from customer(Programmierung_Melexis.docx), according to understanding and analysis of the PTC-04 programmer and MLX91206 chip datasheet, mainly based on the analysis of the programmer and the chip's official manual, application and other documents.

2. 验证的主要方法:对比手动烧录以及自动烧录所产生的数据,回读的数据,下面将截图以详细说明。

 Method of Verification: Compare the data produced by manual programming with the data from auto-programming, and the following screenshot will be described in detail.


手动烧录过程:Manual Programming Process


3.1  Read EEPROM to Image: 顾名思义就是把芯片内容读取到Image,从另一个角度讲就是芯片出厂是有一个预置数据的。

Read the content of EEPROM from the chip to Image, mean read the default setting and content of the chip.

3.2  Copy Image to Temp:把Image的数据复制到Temp,其实这一步是为下一步做准备的。

Copy the image data to a temp area.

3.3  根据客户手册(Programmierung_Melexis.docx),到这里我们需要修改两个参数 (RoughGain以及FineGain),从下面的截图可以看出,芯片默认的值分别为4 & 651,不满足客户要求,需要修改为3 & 789,而且这里实际操作会发现,只有Temp那一列是可以编辑修改的,而Image是不能编辑修改的,这就是为什么需要3.2步的复制操作。

According to the programming manual from customer, here need modify 2 parameters, (RoughGain and FineGain), per the below screenshot, the default value is 4&651, not same as the customer requirements. Need change to 3&789. And here only Temp area are enable to modify, but the Image is disable.

3.4  Program EEPROM with Temp:就是将我们刚刚修改好的参数,包括芯片默认的其他参数全部烧录进芯片的EEPROM区域。

Programming the modified parameters into the EPROM of chip.

3.5  Read EEPROM + Verify:也就是将刚刚烧录的内容跟Temp进行比较。至此,完成了所有的烧录操作。

Read the values which was written by step 3.4 from the EEPROM and also compare with Temp.



自动烧录过程:Auto-Programming Process


整个过程跟手动模式是一样的,唯一的差别就在于将这些需要手动点击鼠标以及输入数据的地方,通过调用API函数,由软件自动完成。

The whole process is same as the manual programming, the only difference is to use the software to call the API function, and instead of the click and type actions manually. 

验证的原理:就是将自动烧录完成后的芯片,在手动烧录界面只做最后一步或者只做第一步,也就是读取芯片EEPROM的内容到Image,通过手动烧录软件界面就可以看到数据了。

Principle of Verification: Use the manual programming method to check the actual data from EPROM chip which was already programming by Auto-programming.

 

结论:Conclusion

通过比较,我们发现自动烧录与手动烧录都能实现两个要求修改的参数RoughGainFineGain的一致性。

显然,仔细比较的话,也能发现除了RoughGainFineGain高度一致外,其他参数并不完全一致。为了比较差异,我们又做了如下比较,我们用手动方式烧录不同的芯片,然后回读比较,发现即使手动烧录,芯片个体之间的数据也并不完全一致。然后自动烧录的不同芯片个体之间也同样不完全一致。

另外,从内容本身来看,比如LotNumber,如果是不同批次的芯片,读取不一致,也是合理的,所以理论上应该是允许不一致的。另外,还有的就是ID值,类似于SN,本来就应该是有独立性的。

After verification, the key parameters are the same as the manual programming method, such as RoughGain and FineGain. Of course, the best way is through functional verification.


iTestGroup为客户提供从工装夹具到烧录器选型以及软件设计一条龙的完整解决方案。有业务需求可联系sales@itestgroup.com,技术交流可联络support@itestgroup.com


iTestGroup】provide the one-step programming solution, include but not limit fixture design, programmer selection and software design. For business query, contact with Sales@iTestGroup.com; For the technical query, such as Melexis chip, PTC-04 API function... contact with Support@iTestGroup.com


<Above is the real case and get the authorization from end user for public release.>



Wednesday, June 7, 2017

【iTestGroup】I2C总线从设备地址冲突


I2C地址

I2C总线是最常用的总线之一。因为它占用的I/O资源少,总线结构简单。I2C总线上设备的关系是"一主多从",所以I2C协议中最重要的一个组成部分是I2C从设备地址。从设备地址有两种格式:7bit和12bit。由于实际使用中基本上不会挂载如此多的从设备,所以很多从设备的地址都采用7bit的格式。但是随着提供I2C接口的从设备种类越来越多 ,不同功能的从设备地址就会产生重叠。


地址冲突现象

主设备无法正常读写总线上设备地址产生冲突的从设备。通过逻辑分析仪分析总线时序,发现主设备每次请求从设备时,总线上就会有两个从设备应答,接下来的时序就乱套了。


地址冲突的原因

人为因素

在从设备选型时没有考虑到从设备地址,选用了两个相同地址的从设备。

非固定的从设备地址

一般从设备的地址经硬件上的配置后,基本都是固定的7bit。但是有一些从设备地址不是固定,如EEPROM存储器CAT24C04 。当读取CAT24C04的地址0xFF以下的数据时,从设备地址为0xA1,当读取0xFF以上的数据时从设备地址为0xA5。当总线上同时挂载了一个时钟芯片PCA8563时,因为PCA8563的从设备读取地址是0xA5,所以这两个器件就会产生了地址冲突。很多人都会只看到CAT24C04的地址是0xA1,而忽略了0xA5,从而造成了总线地址冲突。

不可避免的地址冲突

当工程师门根据项目的需求选型了两个从设备。两个从设备的地址都是不可配置,并且两个从设备地址相同。


解决方法

当从设备地址可配置时

对设备地址进行配置,避免设备地址相同。

当从设备地址不可配置时

使用多路复用器

NXP的I2C总线多路复用器,如PCA9540B是现在市面上最主流的产品之一。工作原理如图 1。



图 1 多路复用器工作原理


使用多路开关

NXP的I2C总线多路开关,如PCA9543A是现在市面上最主流的产品之一。工作原理如图 2。



图 2 多路开关工作原理


归为同一组的从设备地址都不相同,把存在地址冲突的从设备放到另外一组,每次只打开一个开关,主器件每个时刻只能和其中一组设备通信。这样同样可以解决地址冲突问题。

增加一条I2C总线

现在的MCU一般都提供2个以上的I2C接口,如果在从设备地址产生冲突,并且MCU资源有剩的情况下。可以通过增加一条I2C总线来解决地址冲突问题。


iTestGroup】具备众多基于IIC总线的开发经验,如基于IIC总线的TMP75温度传感器、TCS3414颜色传感器等等,在测试测量领域有着众多的应用。自主开发功能模块,能大幅降低测试设备整体成本,也有着更高的灵活性,当然稳定性也有一定的挑战。【iTestGroup】所开发的功能模块大部分为自用,如果有需求,也可以联系sales@itestgroup.com商讨。如果有相关的技术爱好,也欢迎与support@itestgroup.com沟通联络。


<本文转载自周立功微信公众号,如有侵权,请联系admin@itestgroup.com处理>