智能卡(Smart Card)是一种内嵌有微芯片的塑料卡,通常与信用卡大小相同。这种卡配备了 CPU、RAM 和 I/O,能够自行处理数量较多的数据而不会干扰到主机 CPU 的工作。此外,智能卡还可以过滤错误的数据,以减轻主机 CPU 的负担。它适应于端口数目较多且通信速度需求较快的场合。 智能卡的标准主要包括 ISO7816 系列。这些标准详细规定了智能卡的物理特性、触点尺寸和位置、电信号和传输协议等关键方面。例如,ISO7816-1 规定了带触点集成电路卡的物理特性,如触点的电阻、机械强度、热耗、电磁场、静电等;ISO7816-2 则规定了 ID-1 型 IC 卡上每个触点的尺寸、位置和任务分配。 类别 除了 PSAM(销售点安全模块)和 ESAM(嵌入式安全模块)之外,智能卡还包括其他多种类型。根据应用领域和功能,智能卡主要可以划分为以下几种: 金融卡:也称为银行卡,包括信用卡和现金卡两种。信用卡可以在消费支付时按预先设定额度透支资金,而现金卡则作为电子钱包或电子存折,但不能透支。 非金融卡:也称为非银行卡,涉及范围十分广泛,实际包含金融卡之外的所有领域,诸如电信、旅游、教育和公交等等。 交通卡:这种卡主要应用于公共交通领域,如地铁、公交等。 政府应用卡:如社保卡等,现在应用较广泛。 另外,根据镶嵌芯片的不同,智能卡还可以分为存储器卡、逻辑加密卡和 CPU 卡。存储器卡功能简单,没有(或很少有)安全保护逻辑,但价格低廉,开发使用简便,存储容量增长迅猛,因此多用于某些内部信息无需保密或不允许加密的场合。逻辑加密卡有一定的安全保证,多用于有一定安全要求的场合。而 CPU 卡则具有很高的数据处理和计算能力以及较大的存储容量,同时采取了多层次的安全措施,因此应用的灵活性、适应性较强,已成为一卡多用及对数据安全保密性特别敏感场合的最佳选择。 形态 标准卡、SIM卡、双列直插(ESAM)等 通信接口 ISO7816-3 标准的智能卡接口是需要外部提供时钟(也有内部时钟的)和采用单线半双工串行通信的接口。 加密算法 通常广泛支持 3DES 算法,也有内嵌国密 SM1 算法的(如电力上用的 ESAM 芯片、CPU 卡等)。 功能 信息存储(内置EEPROM)、秘钥管理、权限认证等。 驱动电路 可以直接使用带有智能卡模式的 USART 通信,USART_CK 接 CLK,USART_TX(智能卡模式收发在内部通过SW_RX连接)接 IO。 如果要适应更多卡,比如不同的电压,或为电路提供更多的安全保障(短路等),通常会选择专用的接口芯片装在卡与 MCU 之间,比如使用 ST8024,更具体的可以研究一下 8024 的手册看...
2019年4月
嵌入式、物联网技术交流分享TortoiseGit 合并过程
将本地的修改 Commit 后,push 到服务器时提示失败。这是可能是因为本地的版本落后于远程版本,服务器上的版本已经被别人抢先一步更新了。这个时候就要做一下合并操作了。所谓的合并可以是合并同一分支(比如上述往 master 分支)的不同版本,也可以是合并不同分支(比如要将 dev 分支合并到 master 分支),查看同一个文件不同版本间的差异并选择两者中的一种或发现新的问题作出新的改动,最后再 commit、push 的过程。 先 Pull,由于我们已经知道本地与服务器两个版本是不同的,所以已经预料到会有问题。 Pull 的时候会自动合并,由于 git 访问不了公司加了密的文件,所以文本文件被当成了二进制文件,自动合并不起作用,只能手动合并。不过即使能正常自动合并,也可能合并出错,毕竟机器还不能完全理解人的意图。 本地文件的图标也会发生变化,感叹号的文件就是有冲突的文件: 点击窗口或菜单中的 Resolve,开始解决冲突的过程。 弹出来冲突文件列表: 由于我使用了 Beyond Compare 做第三方比较/合并工具,所以双击文件就打开了 BC: 同时自动生成了三个文件(应该是 git 生成的,而不是 bc,用内置合并工具时也会生成这几个文件): 编辑器打开冲突文件 .gitignore,可以看到自动合并的痕迹: <<<<<<< HEAD 与 ======= 之间的内容是本地主分支上的内容,>>>>>>> c7877cc893ca1171b829ac7f48187a97befacfdd 是 远程主分支上最新版本 c7877 的内容。两个内容一样,都是相对于上一版本增加的内容。 BC 上面三列分别是 BASE、LOCAL、REMOTE,分别表示上一个版本(感觉可能是共同的祖先),本地版本,远程版本,这三个内容是只读的,改不了。下面的窗口是合并操作的输出,并不是工作区冲突的那个文件的实际内容。 把所有冲突解决掉,commit 然后 push 到服务器。 取消合并: 在 commit 前可以取消合并操作,以使工作区的文件退回到本地最新版本的状态。...
白光 T12 烙铁头
T12 烙铁头也叫 T12 发热芯、T12 焊咀,是日本白光公司(Hakko)推出的 FX-951 拆消静电电焊台标配的烙铁头型号名称。T12 烙铁头属复合型焊咀,是发热芯、温度传感器、烙铁头三个部件的复合体。 T12 烙铁头的特点是:传感器充分前置,对温度变化敏感度高;发热芯部件安装在小体积的烙铁头内部,热量损失极小。 热电偶是一种感温元件。它直接测量温度,并把温度信号转换成热电动势信号, 通过电气仪表转换成被测介质的温度。热电偶测温的基本原理是两种不同成份的材质导体组成闭合回路,当两端存在温度梯度时,回路中就会有电流通过,此时两端之间就存在电动势——热电动势,这就是所谓的塞贝克效应(Seebeck effect)。两种不同成份的均质导体为热电极,温度较高的一端为工作端,温度较低的一端为自由端。 T12 内部可视为发热丝串联了热电偶,通电时加热,断电时测温。所以一般 T12 都是使用 PWM 控制,高电平驱动 MOS 加热,低电平时 MOS 断开运放放大热电偶电动势测得温度,后反馈调节 PWM 占空比实现恒温。运放放大的是热端的电动势,对应的温度是烙铁头的温度 + 室温,所以要减去室温才是真正烙铁头的温度,这一过程就是所谓的冷端补偿。T12 用的是 K 型热电偶。(据说接近 N 型,后续验证一下看看。) K 型热电偶是目前用量最大的廉金属热电偶,其用量为其他热电偶的总和。K 型热电偶丝直径一般为 1.2mm~4.0mm。正极(KP)的名义化学成分为:Ni : Cr = 90 : 10(镍铬合金),负极(KN)的名义化学成分为:Ni : Si = 97 : 3(镍硅合金),其使用温度为 -200℃ ~ 1300℃。K 型热电偶具有线性度好,热电动势较大,灵敏度高,稳定性和均匀性较好,抗氧化性能强,价格便宜等优点,能用于氧化性惰性气氛中广泛为用户所采用。K 型热电偶不能直接在高温下用于硫,还原性或还原,氧化交替的气氛中和真空中,也不推荐用于弱氧化气氛。 圈子里的名词: 白菜白光:用廉价的控制电路 + 二手白光焊嘴 DIY 的烙铁,更高档的还有牛肉白光、鲍鱼白...
Cortex-M3 HardFault_Handler 调试心得
这几天在 MDK 下调试 STM32 在进入 HardFault_Handler 异常中端原因的问题上花费了不少周折 简单来说应该采取下面的查找思路: 1、进入 HardFault_Handler 后根据 LR 确定异常发生处所使用的栈指针是 MSP 还是 PSP 2、查看 PSP(假设是 PSP)的值,在 RAM 中找到 PSP 所指的区域 3、地址按从低到高的顺序分别存放了 R0,R1,R2,R3,R12,LR,PC,XPSR 的顺序找出 PC 的值 4、根据 PC 的值找到异常程序的位置 5、分析异常程序位置的 FLASH 及 RAM 访问相关方面是否有异常值,一般是 RAM 被异常修改导致从此处取到了错误的访问地址引起的。 在 HardFault_Handler 打断点,在 Call Stack + Locals 窗口查看调用顺序,在某个入口点右键执行 Show Caller Code 跳到响应程序的位置再仔细查看出错原因...
STM32F1 库函数的宏定义
1、USE_STDPERIPH_DRIVER 宏定义 要在编译器中预定义这个宏: 而且在编译器中仅仅定义这一个宏就可以了。STM32F10X_HD 这类的宏在编译器中选好 MCU 型号后就自动确定下来对应的宏了。 2、HSE_VALUE 宏定义 HSE_VALUE 需要根据实际使用的晶体频率修改,RCC_GetClocksFreq 中会用它来算出系统时钟。因为 USART_Init、I2S_Init、I2C_Init 用到了 RCC_GetClocksFreq,所以如果不修改 HSE_VALUE 为实际情况下的值会出现串口波特率错误等问题。不要直接修改 stm32f10x.h 中的定义,而要在 stm32f10x_conf.h 中重新定义 HSE_VALUE: #undef HSE_VALUE #define HSE_VALUE ((uint32_t)xxx...
STM32 CAN 总线通信
CAN 是控制器局域网络 (Controller Area Network, CAN) 的简称,是由以研发和生产汽车电子产品著称的德国 BOSCH(没错,就是那个卖电动工具的博世)公司开发的,并最终成为国际标准(ISO 11898),是国际上应用最广泛的现场总线之一。 在北美和西欧,CAN 总线协议已经成为汽车计算机控制系统和嵌入式工业控制局域网的标准总线,并且拥有以 CAN 为底层协议专为大型货车和重工机械车辆设计的 J1939 协议。 CAN 采用多主工作方式,节点之间不分主从,但节点之间有优先级之分,通信方式灵活,可实现点对点、一点对多点及广播方式传输数据,无需调度。CAN 采用的是非破坏性总线仲裁技术,按优先级发送,可以大大节省总线冲突仲裁时间,在重负荷下表现出良好的性能。CAN 采用短帧结构传输,每帧有效字节为 8 个,传输时间短,受干扰的概率低。而且每帧信息都有 CRC 校验和其它检错措施,保证数据出错率极低。当节点严重错误时,具有自动关闭功能,使总线上其它节点不受影响,所以 CAN 是所有总线中最为可靠的。CAN 总线可采用双绞线、同轴电缆或光纤作为传输介质。它的直接通信距离最远可达 10km,通信速率最高达 1M bps(通信距离为 40m 时),总线上可挂设备数主要取决于总线驱动电路,最多可达 110 个。但 CAN 不能用于防爆区。 CAN网拓扑结构 CAN 是半双工的。收发数据要分时进行。不管 CAN 网络上挂多少设备,在同一时刻只能有 1 个发送数据。如果有多个需要同时发送则只有优先级别高的先发送,其它等待。控制器有收发两个接口,但是收发器的两个接口变成了 High 和 Low。CAN 总线式两线制的。在这点上可以与 Uart 控制器与 RS-485 收发器来类比。 CAN 协议目前有 2.0A 和 2.0B。CAN 2.0A 是 CAN 协议的 PART A 部分,此部分定义了 11bit 的标识区 。 CAN 2.0B 是 CAN 协议的扩展部分,也叫 PART B,定义了 29bit 的标识区,设计上与 CAN2.0A 兼容。通常支持 2.0B 协议的芯片同时也支持 2.0A。 STM32 单片机的 CAN 控制器接口有收、发两个口,互联型有两个 CAN 控制器。两个 CAN 都分别拥有自己的发送邮箱和接收 FIFO,但是他们共用 28 个滤波器。通过 CAN_FMR 寄存器的设置,可以设置滤波器的分配方式。 STM32 的过滤器组最多有 28 个(互联型),但是 STM32F103ZET6 只有 14个(增强型),每个过滤器组由 2 个 32 为寄存器,CAN_FxR1 和 CAN_FxR2 组成。过滤器有两种工作模式:屏蔽位模式和标识符列表模式。工作在屏蔽位模式时 CAN_FxR2 为 1 的位指示了接收到的标识位必须与 CAN_FxR1 相对应的位的 0 或 1 完全一致才能通过过滤器。如果 CAN_FxR2 全为 0 也就意味着不进行任何过滤。工作在标识符列表模式时 CAN_FxR1 和 CAN_FxR2 互不相干,CAN_FxR2 也是一个像 CAN_FxR1 的寄存器,当接收到的标识符与 CAN_FxR1 或 CAN_FxR2 完全匹配时才能通过过滤器。 STM32 提供了两种测试模式,环回模式和静默模式。环回测试模式不需要短接外部的两个脚,它是在内部环回的...
WAV 文件格式简介
WAV 为微软公司(Microsoft)开发的一种音频文件格式,它符合 RIFF(Resource Interchange File Format)文件规范,用于保存 Windows 平台的音频信息资源,被 Windows 平台及其应用程序所广泛支持,该格式也支持 MSADPCM,CCITT A LAW 等多种压缩运算法,支持多种音频数字,取样频率和声道,标准格式化的 WAV 文件和 CD 格式一样,也是 44.1K 的取样频率,16 位量化数字,因此在声音文件质量和 CD 相差无几。WAV 格式的音乐通常使用三个参数来表示声音,量化位数,取样频率和声道数。 WAV 文件采用的是 RIFF 格式结构。至少是由 3 个块构成,分别是 RIFF、fmt 和 data。所有基于压缩编码的 WAV 文件必须含有 fact 块。此外所有其它块都是可选的。块 fmt、Data 及 fact 均为 RIFF 块的子块。WAV 文件的文件格式类型标识符为 WAVE。 构成 RIFF 文件的基本单位称之为块(chunk)。每个 RIFF 文档是由若干个块构成。每个块(chunk)由块标识、块长度及数据等三部分所组成。块标识保存的是由 4 个 ASCII 码字符组成的块名字。如不满 4 个字符则在右边以空格充填。块长度字段占 4 个字节,保存的是当前块数据的长度,不包括块标识和块长度字段。所以一个块的实际长度为块长度字段内的数值加 8。RIFF 格式规定,只有 RIFF 及 LIST 块可以含有子块,其它的块不允许包含子块。一个 RIFF 格式文档本身就是一个块。其前 4 个字节为文档标识 RIFF,同时也是 RIFF 的块标识,标明该文档是一个有效的 RIFF 文档;第二部分为文件的数据长度,占 4 个字节,其数值为文件长度 -8;第三部分为 RIFF 块数据,前 4 个字节为文件格式类型标识,如:WAVE、AVI 等,后面其它部分为 RIFF 块的子块。 //WAV的数值均为小端模式 typedef struct WavRiff { char id[4]; //"RIFF" uint32_t size; //块长度,从下一个字段(format)首地址开始到文件末尾的总字节数,该字段的数值加 8 为文件的总长度 char format[4]; //文件格式类型:"WAVE" } wav_riff_t; typedef struct WavFmt { char id[4]; //格式子块标识"fmt " uint32_t size; //格式子块长度,其数值不确定,取决于编码格式,可以是 16、 18 、20、40 等,从下个字段到格式子块结束的字节数 uint16_t format; //编码格式代码,常见的 WAV 文件使用 PCM 脉冲编码调制格式,PCM = 1 uint16_t channels; //通道数,单声道为1,双声道为2 uint32_t sample_rate; //采样频率,单位Hz uint32_t data_rate; //数据传输率 声道数×采样频率×每样本的数据位数/8,播放软件利用此值可以估计缓冲区的大小 uint16_t block_align; //块对齐字节数 = 声道数×位数/8,播放软件需要一次处理多个该值大小的字节数据,用该数值调整缓冲区 uint16_t bps; //bits per sample采样位数,存储每个采样值所用的二进制数位数。常见的位数有 4、8、12、16、24、32 } wav_fmt_t; typedef struct WavData { char id[4]; //"data" uint32_t size; //data size,从下个字段到格式子块结束的字节数 } wav_data_t; typedef struct WavHeader { wav_riff_t riff; wav_fmt_t fmt; wav_data_t data; } wav_header_t; 常见的压缩编码格式: 格式代码 格式名称 fmt 块长度 fact 块 1(0x0001) PCM/非压缩格式 16 2(0x0002 Microsoft ADPCM 18 √ 3(0x0003) IEEE float 18 √ 6(0x0006) ITU G.711 a-law 18 √ 7(0x0007) ITU G.711 μ-law 18 √ 49(0x0031) GSM 6.10 20 √ 64(0x0040) ITU G.721 ADPCM √ 65,534(0xFFFE) 见子格式块中的编码格式 40 当 WAV 文件采用非 PCM 编码时,使用的是扩展格式块,它是在基本格式块 fmt 之后扩充了一个的数据结构。该结构的前两字节为长度字段,指出后面区域的长度。紧接其后的区域称之为扩展区,含有扩充的格式信息,其长度取决于压缩编码类型。当某种编码格式(如 ITU G.711 a-law)使扩展区的长度为 0 时,长度字段还必须保留,只是长度字段的数值为 0。因此,扩展格式块长度的最小值为基本格式块的长度 16 加 ...