史上最全的kinetis资料

只看该作者 · 2015-7-4 14:29

我陆续分享一下我的一些kinetis技术资料

只看该作者 · 2015-7-4 14:38

k10智能车设计

只看该作者 · 2015-7-5 21:06

偏爱番茄酱发表于 2015-7-4 14:38
k10智能车设计

这个智能车能应用于电子竞赛吗

只看该作者 · 2015-7-6 12:10

K60硬件入门

只看该作者 · 2015-7-6 12:22

Kinetis K系列SPI接口设计注意事项

只看该作者 · 2015-7-6 12:22

SPI与UART、I2C常被称为单片机开发三大基本通信模块（几乎是个MCU，都少不了这三个通信外设），足以说明这三个通信模块被使用的频率有多高了，呵呵。而这三个通信模块优劣势不同，应用场合也不太一样，SPI一般用在需要短距离高速通信应用，比如高速ADC、SD卡接口、WIFI接口（大部分使用更快的SDIO接口）等等，毕竟动辄几十M的波特率还是另外两个通信接口拍马也赶不上的，而且SPI的时序、接口和结构都比较简单（一个Timer，一个shifter就可以构造一个SPI），所以其还是非常受广大单片机开发者的欢迎的。

只看该作者 · 2015-7-6 12:23

说到这里，我得提一提Kinetis K系列的DSPI了，最开始以为DSPI只是比传统的SPI多了几个FIFO罢了，后来无论在自己测试时还是客户实际使用过程中还是发现有些需要注意的地方的，本篇博客我只提其中一点，即K系列的DSPI的外部接口。以Kinetis K10为例，其DSPI接口如下：

只看该作者 · 2015-7-6 12:24

从上图中可以看到其与传统SPI接口还是有些不同的，具体需要注意的几点我简单highlight出来仅供参考：

1. 我们可以看到熟悉的片选PCS和时钟SCK管脚，却看不到MISO和MOSI这两个管脚了，取而代之的是SIN和SOUT，从其方向扇出可以看到SIN只能做输入而SOUT只能做输出；

2. K10的DSPI可以配置成Master或者Slave模式（主从切换），也就是说当DSPI做主时，SIN->MISO，SOUT->MOSI，做从机时SIN->MOSI，SOUT->MISO，这点在硬件设计时需要尤为注意；

3. DSPI的几个SPI模块最多可以支持6个片选PCS[0:5]，具体使用哪个片选，除了需要使能相应的管脚复用功能的话，在其每次发送时可以配置选择哪个PCS(通过寄存器选择)，也就是说DSPI做主时，一个SPI模块最多可以挂6个从机；

4. 当把DSPI做slave从机时，只有PCS0才能作为片选信号，这与做主时不一样，这点也需要特别注意；

5. SIN和SOUT的单方向属性带来一个问题，即如果是两个单片机做SPI通信，而且两者需要做在线做主从切换，但是hardware上SIN和SOUT却已经fixed了，那该怎么办呢？放心飞思卡尔帮我们想好了，其专门留了两个管脚可以实现SIN和SOUT切换，即通过管脚复用寄存器来配置复用选项来实现MISO和MOSI的切换，如下图PTE1和PTE3这两个管脚。

只看该作者 · 2015-7-9 16:19

串口波特率计算中使用四舍五入算法提高精度

只看该作者 · 2015-7-9 16:19

异步通信SCI/UART大概是我们最最最常用的外设，现在的单片机开发者几乎习惯了各种函数封装库（无论是官方的还是第三方的，这一点，其中利弊一直众说纷纭，定论不一，虽然简化了上手难度，但是过度的封装也的确弱化了开发者对底层的认识，个人觉着对硬件开发者来说长期来看不是一件好事），说到这我突然联想到一个值得思考的问题（思维有点发散哈，呵呵），现在受国内大环境的影响，一个产品的开发周期越来越被压缩（这点在深圳北京等一线城市尤为明显，因为时间就是市场就是利润已成为导向，这个的确也是有道理的），这个对一家企业来说至关重要，但是对研发工程师来说却不是好现象，急躁紧凑的开发周期带来的隐患是对平台和产品技术细节的把握和理解不深入，不利于个人能力水平的提高，开发者往往最开始的想法是先等产品研发出来之后再往回深入学习理解开发平台，但是事实却是，一个产品研发完了会有另一个项目进来（或者被产品的后期问题分散掉大部分精力），因此总是被动的学习，这点俺作为芯片原厂技术还是深有体会的，大多数的用户对一款芯片资源的利用不到50%（或者说很多芯片比较有特色的可以大幅提高开发效率的的资源都没有来得及被使用），存在着较大的资源浪费。

只看该作者 · 2015-7-9 16:20

上文提到串口提到封装库，现在我们做串口初始化时关于波特率的配置往往不去关心，只是传递一个波特率参数，封装库里会根据输入的波特率换算成底层寄存器级别的配置，而我们知道对异步通信来说波特率的计算精度是比较重要的（这点不同于同步通信，异步通信没有外部时钟来同步），那在波特率换算成寄存器配置的过程中怎样保证这个精度呢，下面以飞思卡尔Kinetis E系列为例，下图为KE系列波特率计算公式，SBR为寄存器的配置，UART Module Clock为UART的输入时钟源，因此正常来说SBR=input clock/16/Baud Rate。

只看该作者 · 2015-7-9 16:21

但是因为无论是输入时钟还是波特率参数，这几个变量的值都是整数，而整数间的除法如果有余数是都会被舍弃而不管是余多少的（不存在四舍五入），而在算波特率时如果舍弃的多的话会影响算到最后的寄存器配置值进而影响通信的精度，所以我们需要引入C语言中整数除法的四舍五入算法，即(b+a/2)/a，它是整数间除法四舍五入的公式（具体怎么得出公式的，你只需要随便给b和a赋几个值算一下就明白了），通过使用这种方法得出的实际UART初始化配置函数API如下，其中busClkHz为UART模块的输入时钟源，bitRate为波特率参数，可以看到((busClkHz>>4) + (bitRate>>1))/bitRate=(inputclock/16 + BaudRate/2)/BaudRate。

只看该作者 · 2015-7-9 16:21

这个简单的整数除法的四舍五入算法虽然很简单却挺实用的，不只是在波特率计算中会用到，在一些其他领域中也会用到。

只看该作者 · 2015-7-9 16:22

Kinetis芯片Reset管脚出现方波的原因及解决办法

只看该作者 · 2015-7-9 16:22

相信很多Kinetis用户在最开始使用该芯片的时候都会发现，当我们把一片新的空的Kinetis MCU焊接到PCB板上之后用示波器表笔测量其复位管脚会看到一个比较稳定的方波输出（或者三角波，三角波主要是由于外部的阻容复位电路造成的，电容充放电形成的效果，实际上还是方波），大多数的用户误以为是芯片出了问题，实则不然，下面我们就来聊聊出现这种现象的原因和解决办法。

只看该作者 · 2015-7-9 16:23

先说说为什么会出现这种情况，首先与大多数MCU一样Kinetis的Reset脚也是低电平有效，且正常运行时是上拉输入状态（对外显性即高电平），但是有一点不同的是Kinetis的复位管脚在MCU复位状态时会对外输出一个低电平（有一个输出状态窗口），待MCU退出复位状态后Reset恢复成上拉输入状态，这个低电平输出的设计初衷主要是为了用这个低脉冲去同步外部其他的芯片或者系统（即把Kinetis的Reset与其他系统的Reset连在一块，可以保证Kinetis复位时把其他系统也一块复位了，保证整个系统同步），可以说这个设计初衷是好的，但是实际市场反馈来说，很少有客户需要这么做，咳咳，典型的出力不讨好。

综上所述，对一块已下载好可用可执行的代码的Kinetis MCU来说，其Reset管脚的电平输出在芯片上电之后应该是短暂的一个低电平脉冲（上电复位造成的）然后一直拉高表示代码执行正常。但是对于一块刚出厂的空片子或者我们通过调试工具对芯片进行了全擦除操作的话，其里面是没有任何程序的，这样芯片就会一直死在某个位置（上电其PC指针为0xFFFF_FFFF，由ARM Cortex-M启动机制可知），但有较真的博友会质疑这样应该也不会出现Reset脚方波现象，的确是这样，但是我还要考虑另一个因素，那就是芯片上电默认其内部看门狗是使能的，哈哈，这样大家就都明白了，当芯片死在某个位置一定时间后（没有程序把看门狗禁掉，也没有喂狗），看门狗就会自动把芯片复位，然后循环往复的一直介样子，即芯片复位后死在某个位置一段时间后再复位然后再死（咳咳，MCU真悲哀啊，想死都死不成，呵呵），这样就会形成Reset管脚方波的情况了。

知道原因了，其解决办法就迎刃而解了（实际上也算不上解决办法，因为本就不是问题，是一个正常现象，如果我们接上Jlink会发现Jlink的灯一直是橙色闪烁，实际上就是这个原因），我们只需要往芯片中写入一个正常的程序即可，所以出现这个问题不必惊慌而会问到“元芳你怎么看”了，我们自己看看就搞定了，呵呵。当然Reset在复位期间有这样一个输出状态的确也会造成一个隐患，就是如果我们外部加一个推挽输出的复位芯片的话需要串一个电阻，（Kinetis Reset管脚与外部看门狗/复位芯片接法）。

只看该作者 · 2015-7-16 15:35

I2C总线被挂起的原因和解决办法

只看该作者 · 2015-7-16 15:35

I2C总线是我们常用的IC之间的通信总线之一，虽然速率有一定的限制（标准的I2C速率才100kbps, Fast I2C速率为400kbps），但是有利有弊，存在即有理，其简单的两线接口（只需要时钟和数据两根线），支持多主机冲突检测和多节点挂载（节点数不受限制，只要总线电容别超过400pF）还是颇受很多人的欢迎的，所以目前市场上大多数需要配置的专用IC都留有I2C接口（有些芯片为了高速通信会使用SPI接口）用来跟主机通信，包括我们常用到的EEPROM，数字量Sensor，电源管理芯片，电量计之类的种种IC，多不胜数，而且I2C接口都是开漏的，所以大多数情况下（不排除有些设备是伪开漏）可以避免主从机IC电平匹配的问题。

不过我们在实际应用中肯定会遇到过有时I2C总线被挂起的情况（即时钟线和数据线都被强制拉到高电平），当然有些人可能用了N年都没有遇到过（尤其是对搞Linux的人，Linux底层驱动已经做的很完善了，底层驱动在遇到这种情况它会自动去解除这种挂起现象，具体方法我下面介绍），所以我们需要分析一下，到底在那种情况下会出现I2C总线挂起的现象呢，然后给出相应的解决办法：

1. 出现I2C总线挂起的原因，这里我只列出最有可能的几点：

（1）芯片不正确的上电或者复位时序；

（2）在通信过程中主机或者从机突然掉电中断了通信过程；

（3）在通信过程中出现较大的噪声干扰造成了错误的时钟或数据信号，这种情况是最常见的；

只看该作者 · 2015-7-16 15:36

2. 至于真的出现这种挂起的状态怎么办呢，实际上包括在I2C协议的参考手册上已经给出了一个标准的解决挂起的方法（经测有效），如下图。主机检测到挂起的情况时（已经读取不出正常的数据来了），主机可以这样做，即主机线先将本身的I2C功能关掉，然后将I2C接口复用成GPIO模式，然后将SDA线一直拉高，然后SCK时钟线主机用GPIO翻转的方式提供至少9个Clock时钟来唤醒从机，最后主机再重新初始化自身的I2C模块将I2C接口使能成I2C功能。这样就基本可以让I2C总线恢复到正常状态了，So Easy不是吗，呵呵。

只看该作者 · 2015-7-16 15:42

楼主继续啊，这么好的帖子不看可惜了

史上最全的kinetis资料

相关下载

相关帖子

以坛为家

欢快之小溪

技术新星奖章

社区建设奖章