Kinetisマイクロコントローラ・ナレッジ・ベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Kinetis Microcontrollers Knowledge Base

ディスカッション

ソート順:
    类似前段时间我写的两篇关于知识产权保护芯片加密的文章,这次再说说产品量产时常需要考虑的另一个问题——烧写序列号。     在产品批量生产的时候,很多客户会有这样的需求,即将每个芯片烧写一个唯一的ID号(Serial Number),以方便对产品进行跟踪和管理或者满足对芯片进行绑定ID号加密的需要。而为了提高整个批量生产过程的效率,选择一个好的烧写工具则至关重要。对飞思卡尔的Kinetis系列来说,可用的烧写方案包括P&E官方的Cyclone MAX(支持在线烧写和脱机烧写,当然价格较贵)和J-Link(仅支持在线烧写,需要仿真器+上位机配合)等,本篇就以最近比较火的Freescale M0+ Kinetis L系列为例详细介绍一下J-Link+J-Flash批量烧写串号的方案(说到此,不得不感叹J-Link的强大,高速的下载和调试,丰富的IDE支持和调试组件和强有力的调试功能,不是土豪人家是金啊,怎一个强大了得): 开发平台:Kinetis L系列KL15Z128 烧写工具:J-Link + J-Flash(v4.76f) (1) 这里不单独对J-Flash多作介绍,可以参考我之前的一篇文章《教你用J-Flash ARM工具单独烧写程序到Kinetis》,至于包括J-Flash在内的软件包可以直接到SEGGER官网下载http://www.segger.com/jlink-software.html,建议下载最新版的,支持的芯片系列较全,相应的组件功能也更强大; (2) 打开J-Flash(路径为Start->All Programs->SEGGER->J-Link ARM V4.76f->J-Flash),在最新版本中会直接弹出选择已有工程选项卡,根据需要在路径"安装路径\SEGGER\JLinkARM_V476f\Samples\JFlash\ProjectFiles\Freescale”下选择自己的目标芯片(我这里选择MKL15Z128xxx4.jflash),选择如下图: (3) 点击“start J-Flash”进入工程管理界面,然后点击File->Open data file,找到需要下载的bin文件或者S19文件,将其加载到jflash工程里面,加载之后的界面如下图: (4) 万事具备,接下来就开始进行烧写序列号的设置。点击“Options->Project Settings->Production”,选中“Program Serial Number”,设置如下: (5) 点击“OK”,设置完毕(只设置一次即可),然后连接目标芯片“Target->Connect”,连接成功,点击“Auto”,系统会自动将设置好的序列号添加到s19文件相应的地址然后启动下载,同时也会在Jflash的工程目录(之前加载的sample prject的目录)下生成一个“<JFlashProjectName>_Serial.txt”,内容如下图,其中“12345679”为下次要写入的数据,系统自动为其加1了(由“Increment”决定): (6) 我们回读烧写到片子中的数据(Target->Read Back->Entire chip),然后跳转到“0x2000”地址,可以看到序列号(12345678的十六进制)已经写入,如下图: 注意事项: (1) 在烧写的时候,必须点击“Auto”下载,这样才会生成“<JFlashProjectName>_Serial.txt”文件,且会把序列号自动添加到s19文件然后烧进去,直接点击“Program”或者“Program&Verify”等烧写功能只会烧写原始S19文件,不会添加序列号; (2) J-Flash烧写序列号最多支持4个字节,高于四个字节的数据J-Flash会将前四个字节取反再烧进去,所以实际上起作用的还是4个字节,不过单纯作为序列号的话肯定是足够了,4个字节32个比特位,IPv4的地址也就这些吧,呵呵,想不到会有什么产品会超过这个范围,那样的话Freescale超越当年的Motorola也不是问题了啊,哈哈; (3) 关于烧写地址的问题,理论上只要在目标芯片的Code Flash地址范围内并且不与原始运行代码地址重叠即可,因为J-Flash烧写的原理是先添加数据到原始bin或者S19文件相应的位置然后整个文件一块烧写进去,所以写序列号的时候不需要额外的再擦写扇区一次也就是不会破坏同在一个扇区的原始数据,不过当然如果flash空间足够大的话不建议将序列号烧写地址挨着原始代码太近,建议将序列号写到Flash的最后,规避风险; (4) 实际上采用J-Flash也可以烧写多余4个字节的数据,不过这需要手动添加编辑txt文件,这里就不多说了,可以参考附件中文档。
記事全体を表示
ROM Bootloader KL43 chip with Kinetis Bootloader residing in the on on-chip read-only memory (ROM), can interface with USB, I2C, SPI, and LPUART peripherals in slave mode and respond to the commands sent by a master (or host) communicating on one of those ports. When KL43 chip with a blank flash, the Kinetis bootloader will execute automatically. Once the flash is programmed, the value of the FOPT field at Flash address0x40D will determine if the device boots the ROM bootloader or the user application in flash. The FTFA_FOPT [BOOTSRC_SEL] will select if boot from customer application (Flash) or boot from ROM bootloader. For example:       When Flash address 0x40D value is 0xFF, boot source is ROM bootloader;       When Flash address 0x40D value is 0x3D, boot source is Flash (Customer application). There with hardware pin(/BOOTCFG0) to control if boot from user application or ROM bootloader with FTFA_FOPT[BOOTPIN_OPT] bit . When FTFA_FOPT[BOOTPIN_OPT]  = 0, it forces boot from ROM if /BOOTCFG0 pin set to 0. blhost utility application The blhost utility is an example host program used to interface with devices running the Kinetis bootloader. The blhost application is released as part of Kinetis bootloader release package available on www.freescale.com/KBOOT . The blhost application default located at C:\Freescale\FSL_Kinetis_Bootloader_1_1_0\bin\win folder. About how to use blhost application, please check KBLHOSTUG document for more detailed info. Call Rom Bootloader from customer application In general, if customer application was programmed, the boot option should be change to Boot from Flash. If customer want to call the ROM bootloader during the application running, customer can refer below example. Set a signal for application code to call the ROM bootloader, such as press a button. In this demo, we use FRDM-KL43Z board SW3 (PTC3) to call the ROM bootloader. //Initalize PTEC3 as GPIO button PORT_Init (PORTC, PORT_MODULE_BUTTON_MODE, PIN_3, 0, NULL); GPIO_Init (GPIOC, GPIO_PIN_INPUT, PIN_3); The bootloader entry point for customer application to call the ROM bootloader.  //prototype of the entry point definition void run_bootloader(void * arg); //Variables uint32_t runBootloaderAddress; void (*runBootloader)(void * arg);   // Read the function address from the ROM API tree. runBootloaderAddress = **(uint32_t **)(0x1c00001c); runBootloader = (void (*)(void * arg))runBootloaderAddress; in <main.c> routine to call the ROM bootloader:   while (1)   {     if ((GPIOC_PDIR & (1 << 3)) == 0)     {       // Start the bootloader. runBootloader(NULL);     }   } Press SW3 button of FRDM-KL43Z board will call ROM bootloader.  Customer could continue to debug the code until the ROM bootloader be called. If customer debug into the runBootloader(NULL) function, there will stop at fixed address: 0x1C00_00C0. In fact, during call the ROM bootloader function , there will setting some parameters and then reset the KL43. When KL43 back from reset, it will boot from ROM bootloader. That reset will cause debugger disconnect with the KL43 product. More detailed info, please check attached demo code. BTW: The demo project is [frdm_led_test] inside of KL43 baremetal sample code, which could be downloaded from here.
記事全体を表示
Este proyecto está siendo desarrollado por alumnos del Tecnológico de Monterrey Campus Guadalajara, el cual está orientado para servir como un tipo de terapia para personas discapacitadas. El proyecto en sí consiste en el control de un vehículo de juguete por medio de pulsaciones que serán realizadas con pelotas anti-estrés, de esta forma la persona podrá realizar un ejercicio de fortalecimiento en sus extremidades superiores de una forma más entretenida y menos tediosa que las clásicas terapias. Es importante mencionar que para poder realizar este proyecto es necesario el uso de dos tarjetas Freedom KL25Z de Freescale®, dos módulos Bluetooth®, dos servomotores de rotación continua y dos sensores de presión, los cuales serán incorporados dentro de las pelotas anti-estrés. El vehículo de juguete estará compuesto por los servomotores, que servirán como llantas; un módulo Bluetooth®, el cual recibirá las señales del otro módulo; y una de las tarjetas Freedom KL25Z. Por otro lado una de las tarjetas Freedom KL25Z estará conectada con los sensores integrados en las pelotas anti-estrés y a un módulo cuya función es mandar la información capturada por los sensores al vehículo de juguete. La mecánica del proyecto depende de la pelota que sea presionada, pues si se presiona solamente una pelota, el vehículo avanzará, por otro lado si se presiona la otra pelota, el vehículo girará sobre su propio eje. Este proyecto tiene como fin la implementación de conocimiento prácticos y teóricos en busca de una aportación en beneficio de la sociedad. También es relevante comentar que las visiones a futuro de este proyecto es que pueda ser implementado como una especie de control para una silla de ruedas, con el fin de facilitar la movilidad y aumentar la comodidad al momento de usar este tipo de vehículo. Original Attachment has been moved to: Codigo-tarjetas-freedom.zip
記事全体を表示
中文版本:     在KL25的官方Demo 源代码中只有I2C驱动的PE代码而没有I2C驱动的baremental代码,对于不习惯用PE生成代码的用户直接上手有难度,于是考虑将K60的 I2C baremental 驱动代码中移植到KL25上,以供大家参考。但在移植过程中遇到了两个比较典型的问题,所以这里分享出来,希望能帮助遇到同样问题的用户迅速定位并解决问题。 测试硬件:TWR-K60D100M开发板  K60+MMA8451(MMA8451为三轴加速传感器,与K60通过I2C总线连接。K60作为master,MMA8451作为slave)                 FRDM-KL25Z开发板       KL25+MMA8451 开发环境:IAR 6.6 1.问题描述: 配置I2Cx_F寄存器MULT位不为0时,Repeat start信号无法产生 问题提出: K60示例代码(如附件1)中I2C demo的功能是通过I2C接口读取板载的加速度传感器MMA8451的数据,并且I2C数据控制采用查询ACK标志位的方式,在TWR-K60D100M开发板上运行该Demo一切正常。使用几乎相同的I2C驱动代码,在FRDM-KL25Z开发板上执行发现:程序总是停在如下Function 1的红色字体行i2c_wait(I2C0_B),进入这个函数内部,它实际上是停在while((p->S & I2C_S_IICIF_MASK)==0),一直等待传输完成的中断标志IICIF置位。 Function 1. u8 hal_dev_mma8451_read_reg(u8 addr) {     u8 result;     i2c_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_WRITE);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_write_byte(I2C0_B, addr);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_repeated_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_READ);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_set_rx_mode(I2C0_B);     i2c_give_nack(I2C0_B);     result = i2c_read_byte(I2C0_B);     i2c_wait(I2C0_B);     i2c_stop(I2C0_B);     result = i2c_read_byte(I2C0_B);     pause();     return result; } Function 2. void i2c_wait(I2C_MemMapPtr p) {     while((p->S & I2C_S_IICIF_MASK)==0)  ; // wait flag     p->S |= I2C_S_IICIF_MASK;    // clear flag } 原因分析:      初步判断可能是上一步数据的传输 i2c_write_byte()没有完成,导致IICIF未能被置位。于是通过示波器去捕捉这个过程,发现在执行 i2c_repeated_start(I2C0_B)时,KL25并没有产生一个 Repeat start信号。经过一番谷哥和度娘,终于在Kinetis L的Errata中找到了答案:Repeat start cannot be generated if the I2Cx_F[MULT] field is set to a non-zero value. 这也就意味着,当 I2Cx_F[MULT]位被设置为非0值时,I2C Master不能产生一个Repeat start信号。而在应用程序的I2C初始化I2C_init()代码中, 我恰好设置I2Cx_F[MULT]=01,这正好是符合了Errata描述的错误产生的条件。 解决方案:      I2C的C1寄存器中MULT位是I2C SCL时钟的倍乘因子,用于控制I2C的波特率。为解决上面的问题,FSL官方提供了两种workaround的办法: 1)如果repeat start必须产生时,配置 I2Cx_F[MULT]为0; 2)在置位 I2Cx_F register (I2Cx_C1[RSTA]=1)的Repeat START产生位之前临时设置 I2Cx_F [MULT],然后再在repeated start信号产生后恢复I2Cx_F [MULT]位的设置。 按照第一种方法,我修改程序中I2Cx_F[MULT]的设置从01到00,然后程序在FRDM-KL25Z 开发板上运行正常,能正常读取板载的加速度传感器MMA8451的数据。 2.问题描述: I2C单字节读取时序问题 问题提出: 在上面的Function 1中, KL25读取MMA8451的基本过程是:发送要访问的从机地址及对从机的写命令->发送要访问的从机的寄存器地址->发送Repeat Start信号到从机->发送要访问的从机地址及读命令->读取从机返回的数据,如下Figure1 MMA8451的单周期读时序图所示,其过程和上面代码的描述一致。但是有一点值得注意的是Figure 1中红色方框部分,按照Figure 1的表述,Master是在从Slave从机读取DATA[7:0]之后返回NAK信号的,用于指示本数据是Master要接收的最后一个DATA,最后发送stop signal终止数据的传送。按照这个思路得到的KL25的程序代码如下Section 2,它首先去读取从机返回的数据 i2c_read_byte(I2C0_B),然后发送NACK信号到从机i2c_give_nack(I2C0_B)。然而从KL25实际的物理时序的角度看,这个顺序是错误的,正确的应该是如下Section 1,应该在读取从机返回的数据 i2c_read_byte(I2C0_B)之前,首先发送NACK信号到从机i2c_give_nack(I2C0_B)。 Section 1.   i2c_set_rx_mode(I2C0_B);   i2c_give_nack(I2C0_B);----line1   result = i2c_read_byte(I2C0_B);----line2   i2c_wait(I2C0_B);----line3   i2c_stop(I2C0_B);----line4   result = i2c_read_byte(I2C0_B);----line5 Section 2.   i2c_set_rx_mode(I2C0_B);   result = i2c_read_byte(I2C0_B);-   i2c_wait(I2C0_B);   i2c_give_nack(I2C0_B);-   i2c_stop(I2C0_B); 原因: 主机发送的NACK信号只有在下一个数据接收之后才会被push到总线上,KL25的RM手册中的描述为the No acknowledge signal is sent to the bus after the following receiving data byte (if FACK is cleared)。 具体分析: 按照两个时序分别做了一个测试,并用示波器捕捉了相应的波形:执行Section 1的代码得到的波形如下Figure 2所示,NACK(1)信号刚好在第9个pluse脉冲上升沿被push总线上,然后在Stop信号后总线处于idle状态(SCL和SDA均为高)。执行Section 2的代码得到的波形如下Figure 3所示,ACK(0)信号在第9个pluse脉冲上升沿被push总线上,说明后面还有数据要传输,一直处于等待MMA8451数据的再次传送中,这明显违背了读取单字节数据的原本意图。总之,KL的I2C应用中Section 1的代码操作顺序是正确的,实际的物理时序和 Figure 1的示意图时序是不一样的,这点需要特别注意。 Figure 1. MMA8451's 单周期读时序示意图 Figuire 2. Section 1 代码对应的时序 Figure 3. Section 2 代码对应的时序 为方便大家验证这些问题,我这里在附件中一并上传了K60的I2C的示例代码,KL25的示例代码,以及Kinetis L关于I2C的Errata。 —————————————————————————————————————————————————————————————————————— English Version:      Recently, I migrate the K60’s I2C demo code to the KL25, but found it can't works when the same demo code runs on FRDM-KL25Z board while it runs well on the K60 board. After a painful struggling, I finally get the cause, so here I make a record, wish it could be helpful when other users happen to meet same problem. Repeat start can't be generated when configure I2Cx_F[MULT] to non-zero      The K60’s demo( the attached 1) is to communicate with the onboard accelerometer MMA8451 by I2C, and in the demo it finish a data transmission by quering I2C’s flag bit. With almost same code, it always stops at below Function 1's red line i2c_wait(I2C0_B), also this function's defination is shown as below Function 2, it stops at while((p->S & I2C_S_IICIF_MASK)==0) to wait IICIF flag. Function 1. u8 hal_dev_mma8451_read_reg(u8 addr) {     u8 result;     i2c_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_WRITE);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_write_byte(I2C0_B, addr);    i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_repeated_start(I2C0_B);     i2c_write_byte(I2C0_B, I2C_ADDR_MMA8451 | I2C_READ);     i2c_wait(I2C0_B);     i2c_get_ack(I2C0_B);     i2c_set_rx_mode(I2C0_B);     i2c_give_nack(I2C0_B);     result = i2c_read_byte(I2C0_B);     i2c_wait(I2C0_B);     i2c_stop(I2C0_B);     result = i2c_read_byte(I2C0_B);     pause();     return result; } Function 2. void i2c_wait(I2C_MemMapPtr p) {     while((p->S & I2C_S_IICIF_MASK)==0)  ; // wait flag     p->S |= I2C_S_IICIF_MASK;    // clear flag }      Then what's the matter? when I capture the I2C's wave form, found it didn't generate a Repeat start signal when excute i2c_repeated_start(I2C0_B);  After a struggle, In the Kinetis L's Errata do I find the answer: Repeat start cannot be generated if the I2Cx_F[MULT] field is set to a non-zero value. That means there is a bug in KL's design, if the I2Cx_F[MULT] field is set to a non-zero value, the I2C master can't generate a Repeat start signal. Coincidentally, in the I2C_init function I happen to set theI2Cx_F[MULT]=01, so it just meets the I2C's Errata.      Considering the MULT bits define the multiplier factor mul. and  used along with the SCL divider to generate the I2C baud rate. In the Errata, FSL gives two possible workarounds: 1) Configure I2Cx_F[MULT] to zero if a repeat start has to be generated. 2) Temporarily set I2Cx_F [MULT] to zero immediately before setting the Repeat START bit in the I2C C1 register (I2Cx_C1[RSTA]=1) and restore the I2Cx_F [MULT] field to the original value after the repeated start has occurred. To verify it easily, I revise the I2Cx_F[MULT] from 01 to 00. After that the same code runs well on FRDM-KL25Z board.    2. The Timing Sequence Of I2C's single byte Reading      In the above Function 1, there are a MMA8451 data read section like below after  Write Device Address->Write Register Address->Repeat Start->Write Device Address, and these steps is same as MMA8451's single byte read Timing Sequence requirment which is shown as below Figure 1. But referring to Figure 1, it looks like Section2 we should first excute below line2 to read the data, and then line1 give a nack  to suggest it's the last data, at last excute line4 to send a I2C stop signal. But unfortunately the idea is wrong, because in the phasical timing sequence the No acknowledge signal is sent to the bus after the following receiving data byte (if FACK is cleared) ,which means we need to give NACK signal before a read. And the captured wave form is like below Figure 2, you can find the NACK in the Ninth pluse, while the captured wave form is like below Figure 3 if excute Section 2 code instesd of Section 1 code, you can find the ACK in the Ninth pluse. it means the master will read another data, but the original intention is to read only one byte, so the I2C bus blocks. In a word, the section 1 code is right, the physical timing is different from the Figure 1's sketch map. Section 1.     i2c_set_rx_mode(I2C0_B);     i2c_give_nack(I2C0_B);----line1     result = i2c_read_byte(I2C0_B);----line2     i2c_wait(I2C0_B);----line3     i2c_stop(I2C0_B);----line4     result = i2c_read_byte(I2C0_B);----line5 Section 2.    i2c_set_rx_mode(I2C0_B);    result = i2c_read_byte(I2C0_B);-    i2c_wait(I2C0_B);    i2c_give_nack(I2C0_B);-    i2c_stop(I2C0_B); Figure 1. MMA8451's single byte read Timing sketch map Figuire 2. Section 1 code's Timing Figure 3. Section 2 code's Timing
記事全体を表示
The AOI and Crossbar modules are inregrated in DSC, Kinetics KV and i.mxrt families, user can use them to generate complicated trigger signal for the on-chip peripherals. The DOC discusses the AOI function, crossbar fuction based on KV58. It gives the example, the example demos how to implement AND operation of two signals via crossbar switch A and B and AOI modules. The two logic signals are connected to the pads of KV58, and routed to AOI inputs via Crossbar switch B, the AOI sub-module0 implements the AND operation of the two signals, and output the AND output signal Event0  to pad of KV58 via crossbar switch A. Connect input pads and output pad of KV58 to oscilloscope, from the waveform of the three signals on scope, we can see that the AND logic  is implemented.
記事全体を表示
Project USB: Connecting USB to CAN with K20   In this project, the internal CAN Controller of the K20 is used to monitor the CAN bus. The connection to the PC is realized by the internal USB Controller. The USB stack is implemented as HID device especially for the K20.   The software runs on a self made hardware board. The connection to CAN is visualized with a Qt program, running on every Win7 PC.   Result: K20_CAN2USB.zip Original Attachment has been moved to: K20_CAN2USB.zip
記事全体を表示
This is an example for the Kinetis KE02Z devices, showing how to program the EEPROM with initial values when the flash is programmed.  The example works on the FRDM-KE02Z40M board, and was written with Kinetis Design Studio (KDS) v3.0.0.  The example also uses Processor Expert (PEx) to configure the UART and erase/program the EEPROM.  The EEPROM programming works with the P&E Micro Multilink Universal debugger, as well as the P&E Micro OpenSDA debugger app for the FRDM-KE02Z40M board. To program the EEPROM with initial values, the application declares constants for the EEPROM locations, and initializes these in the source code in eeprom.c. Compiler pragmas/attributes are used to force the linker to place these constants in EEPROM, using the m_eeprom memory section defined in the linker command file \Project_Settings\Linker_Files\ProcessorExpert.ld.  The P&E Micro flash programming algorithms initialize the EEPROM in 4Byte words. Therefore, any initialized EEPROM locations should be in aligned 4Byte words. This example initializes the first 4Bytes in the EEPROM as 0, 64, 128, 192. The example uses a terminal program to display EEPROM information.  It connects to the OpenSDA COM port on the FRDM-KE02Z40M board using UART1 from the KE02Z. The terminal settings are:   Baud Rate: 38,400   Data: 8bit   Parity: None   Stop: 1bit   Flow Control: None The example prints 5 bytes of EEPROM to the terminal after reset: the 4 initialized bytes, plus the following EEPROM byte which was not initialized. Then the example increments the first byte, and decrements the second byte, and writes the new values back to EEPROM.  The other 3 bytes are not changed. Then the application prints the new EEPROM values of all 5 bytes.  Everytime the MCU is reset, it will print the existing EEPROM data and then the changed data.  Below is the example output from the terminal after initially programming the KE02Z, and then doing a single reset: Terminal output:   KE02Z EEPROM example   EEPROM values after reset = 0 64 128 192 255   EEPROM values after updating = 1 63 128 192 255   KE02Z EEPROM example   EEPROM values after reset = 1 63 128 192 255   EEPROM values after updating = 2 62 128 192 255
記事全体を表示
  MCU Bootloader2.0.0 enables quick and easy programming of Kinetis MCUs through the entire product life cycle, including application development, final product manufacturing, and beyond. It supports many kinds of peripherals, include UART, I2C, SPI, USB, CAN and so on. Among these peripherals, UART is most common used. In reference manual, it only says that feature can be turned on or off by using #define statement in bootloader_config.h. In fact, you can use UART0 by default. But if you want to use other UART port, change TERM_PORT_NUM to other value is useless. If you traced this value, you’ll find it is not used at all, nor the TERMINAL_BAUD. Here we use FRDM-KV31F512 as the example. We want to download image by UART2. First, we should modify peripherals_pinmux.h. #define BL_ENABLE_PINMUX_UART2 (BL_CONFIG_SCUART)     //line 38   //! UART pinmux configurations #define UART2_RX_PORT_BASE PORTE #define UART2_RX_GPIO_BASE PTE #define UART2_RX_GPIO_PIN_NUM 17               // PIN 16 in the PTB group #define UART2_RX_FUNC_ALT_MODE kPORT_MuxAlt3   // ALT mode for UART0 RX #define UART2_RX_GPIO_ALT_MODE kPORT_MuxAsGpio // ALT mode for GPIO functionality #define UART2_RX_GPIO_IRQn PORTE_IRQn #define UART2_RX_GPIO_IRQHandler PORTE_IRQHandler #define UART2_TX_PORT_BASE PORTE #define UART2_TX_GPIO_PIN_NUM 16             // PIN 17 in the PTB group #define UART2_TX_FUNC_ALT_MODE kPORT_MuxAlt3 // ALT mode for UART0 TX   The original define is UART0, here we change it to UART2. It is strongly recommended to do so. Otherwise you’ll find that UART can’t work at all. Another comment here is PTE16 and PTE17 is conflict with SPI. You must disable SPI or change SPI function to other pins.   Next we must modify peripherals_KV31F512.h. const peripheral_descriptor_t g_peripherals[] = { #if BL_CONFIG_SCUART    // UART0    {.typeMask = kPeripheralType_UART,      .instance = 2, // change this value from 0 to 2      .pinmuxConfig = uart_pinmux_config,      .controlInterface = &g_scuartControlInterface,      .byteInterface = &g_scuartByteInterface,      .packetInterface = &g_framingPacketInterface },   Although there is a baud rate definition TERMINAL_BAUD, but it is never used too. MCU bootloader2.0.0 use auto baud rate detection. When power on, bootloader will go to autobaud detection mode. KinetisFlashTool sends ‘0x ’ every second. Bootloader check this byte and calculate baud rate.   After getting this value, bootloader will change to normal communication mode. Baud rate will not change until reset. If blhost is used, subsequent blhost invocations must specify the same baud rate as was used for the initial invocation unless the bootloader is reset. If the baud rate is not specified using the -p COMx, <baudrate> option, the UART baud rate will be set to 57600. Since Kinetis MCU UART module don’t have auto frequency detect function, the bootloader detects frequcny by software. It uses GPIO interrupt and timer to measure frequency. But in bootloader, there is only code for UART0, there isn’t code for other UART port. We must add the code. In hardware_init_KV31F512.c, modify the function get_uart_clock()   uint32_t get_uart_clock(uint32_t instance) {    switch (instance)    {        case 0:        case 1:            // UART0 and UART1 always use the system clock            return SystemCoreClock;        case 2:            return get_bus_clock();        default:            return 0;    } }   KV31 has 4 UART, include three UART modules and one low-power UART. They have different clock source. UART0 and UART1 use System clock while UART2 and LPUART0 use Bus clock. Thus, we finished the work. UART2 can work as the download port now.
記事全体を表示
Introduction Even with the prevalence of universal asynchronous receiver/transmitter (UART) peripherals on microcontrollers (MCUs), bit banged UART algorithms are still used.  The reasons for this vary from application to application.  Sometimes it is simply because more UARTs are needed than the selected device provides.  Maybe application or layout restrictions require certain pins to be used for the UART functions but the device does not route UART pins to the required package pins.  Maybe the application requires a non-standard or proprietary UART scheme. Whatever the reason, there are applications where a bit banged UART is used and is typically a pure software implementation (a timer is used and the MCU core controls a GPIO pin directly).  A better alternative may be to use Flextimer (FTM) or Timer/PWM Module (TPM) to take advantage of the features of these peripherals and possibly offload the CPU.  This document will explain and provide a sample application of how to emulate a UART using the FTM or TPM peripheral.  A Kinetis SDK example (for the TWR-K22F120M and FRDM-K22F platforms) and a baremetal legacy code example (for the FRDM-KL26Z) are provided here. UART protocol Before creating an application to emulate a UART, the UART protocol and encoding must be understood. The UART protocol is an asynchronous protocol that typically includes a start bit, payload (of 7-10 data bits), and a stop bit but does allow for many variations on the number of stop bits and what/how to transfer the data.  For this document and application example, the focus will be UART transmission that follows 1 start bit, 8 data bits, 1 stop bit, no parity, and no flow control.  The data will be transmitted least significant bit (LSB) first.  The following image is a block diagram of this transmission. However, this doesn't specify what the transmission looks like electrically. The figure below shows a screenshot of an oscilloscope capture of a UART transmission.  The data transmitted is 0x55 or a "U" in the ASCII representation. Notice that the transmission line is initially a logic high, and then transitions low to signal the start of the transmission.  The transmission line must stay low for one bit width for the receiver to detect it.  Then there are 8 data bits, followed by 1 stop bit.  In the case shown above, the data bits are 0x55 or 0b0101_0101.  Remember that the transmissions are sent LSB first, so the screenshot shows 1-0-1-0-1-0-1-0.  The last transition high marks the beginning of the stop bit and the line remains in that state until the start of the next transmission.  The receiver, being asynchronous, does not require any type of identifying transition to mark the end of the stop bit. FTM/TPM configuration The first question many may ask when beginning a project like this is "How do I configure the FTM/TPM when emulating a UART".  The answer to this depends on the aspect of this problem you are trying to solve.  Transmitting and receiving characters require two different configurations.  Transmission requires a configuration that manipulates the output pin at specific points in time.  Receiving characters requires a configuration that samples the receive pin and measures the time between pin transitions.  The FTM and TPM have the modes listed in the following table: The FTM and TPM have four different modes that manipulate an output:  Output compare (no pulse), Output compare (with pulse), Edge-aligned PWM, and Center-aligned PWM.  Neither PWM mode is ideal for the requirements of the application.  This is because the PWM modes are designed to produce a continuous waveform and are always going to return to the initialized state once during the cycle of the waveform.  However, the UART protocol may have continuous 1's or 0's in the data without pin transitions between them. The output compare mode (high-true or low-true pulse modes) is designed to only manipulate the pin once, and only produces pulses that are one FTM/TPM clock cycle in duration.  So this is obviously not desirable for the application.  The output compare mode (Set/Clear/Toggle on match) is promising.  This mode manipulates the output pin every cycle.  There are three different options:  clear output on match, set output on match, and toggle output on match.  Neither "clear output on match" nor "set output on match" are ideal as either would require configuration changes during the transmission of a character.  The "toggle output on match", however, can be used and is the selected configuration mode for this sample application. To receive characters, there is only one mode that is intuitive:  "the input capture mode".  This mode records the timer count value on an edge transition of the selected input pin.  Similar to the output compare mode chosen for the transmit functionality, the input capture mode has three sub-modes:  capture on rising edge, capture of falling edge, and capture on either edge.  It is clear from the descriptions that capture on either edge should be selected. Transmit encoding The selection of the FTM/TPM mode is moderately intuitive, but using this mode to emulate a UART transmission is not.  There are two issues that make this a little tricky. 1) The output pin is initialized low. However, the UART protocol needs the pin to begin in a logical high state. 2) The pin transitions on every cycle provided the channel value is less than the value of the MOD register. Due to continuous strings of 1's or 0's, it is necessary to have periods where the pin does not transition. Both of these points have workarounds. Output pin initialization For the first issue, the channel interrupt is first enabled and the channel value register is loaded with a value much less than the value in the MOD register.  Then in the channel interrupt service routine, the pin is sampled to ensure that it is in the logic high state and the channel interrupt is disabled (and will not be re-enabled throughout the life of the application).  The code for this interrupt service routine is as follows. Output pin control For the second issue, a method of not transitioning the pin value while allowing the timer to continue counting normally is necessary.  The Output Compare mode uses the channel value register to determine when the pin transition occurs.  If a value greater than MOD is written to the channel value register, the channel value will never match the count register and thus, a pin transition will never occur.  So, when a series of continuous 1's or 0's need to be transmitted, a value greater than the value in the MOD register can be written to the channel value register to keep the output pin in its current state. However, when a value greater than MOD is written to the channel value register, no channel match will occur (which means channel interrupts will not occur).  So the timer overflow interrupt must be used to continue writing values.  This requires the updates to be output pin to be planned ahead of time and makes the transmission algorithm a little tricky.  The following diagram displays when which values should be written to the channel value register at which points in time to generate the appropriate pulses. Writing a function to translate a number into the appropriate series of MOD/2 and MOD+1 values can be a little tricky. To do this, we must first notice that MOD/2 needs to be written when changes on the transmission pin are need and MOD+1 needs to be written when pin transmissions are not desired.   So, what logical function can we use to determine when a change has happened?  XOR is the correct answer.  So what two values need to be XOR'd together?  One value is obviously the value that we want to send.  But what is the second value?  It turns out that the second value is a shifted version of the value that we want to send.  Specifically, the second value is the desired value to send shifted to the left by one.  (You can think of it as sort of a "future" value of the desired value).  The following pictures show how to determine the queue to use for the transmission. Receive decoding The receive functionality has an advantage over the transmit functions in that it is possible to use DMA for the reception of characters.  This is because the receive function takes advantage of the input capture functionality of the FTM / TPM and therefore can use the channel match interrupt.  The example application provided with this document implements a DMA method and a non-DMA method for reception. First, the non-DMA method will be discussed. Before discussing the specifics of gathering the input pulse widths, some details of the receive pin need to be discussed. Detecting the start bit The receive pin needs to be able to determine when the start of the packet transmission begins.  To do this, the receive pin is configured as an FTM / TPM pin. At the same time, the GPIO interrupt functionality is configured on the same pin for a falling edge interrupt.  The GPIO interrupt capabilities are enabled in any digital mode, so the GPIO interrupt will still be able to be routed to the Nested Vector Interrupt Controller (NVIC).  The pin interrupt is used to start the FTM / TPM clock when a new character reception begins. In the GPIO interrupt for this pin, the FTM / TPM counter register is reset and the clock to the FTM / TPM is turned on.  The code for the GPIO interrupt service routine is shown below.  Receiving characters without DMA Now, when receiving characters and not using DMA, the first thing to understand is that the Interrupt Service Routine (ISR) will be used and it will mainly be used to record the captured count values.  The interrupt service routine also tracks the current receive character length and resets the counter register.  This is so that the values in the receive queue reflect the time since the last pin transition.  The interrupt function for the non-DMA application is shown below. Notice that the first two actions in the ISR are resetting the count register, and clearing the channel event interrupt flag.  Then the channel value is stored in the receive pulse width array (this is simply an array that holds the receive pulse widths of the current character being received).  Next, recvQueueLength, the variable which holds the current length of the character being received, is updated to reflect the latest character length.  The next step is to determine if the full character has been received.  This is determined by comparing recvQueueLength to the RECV_QUEUE_THRESH, which is the threshold as determined by multiplying the number of expected bits by the expected bit width plus another bit width (for the start bit).  If the recvQueueLength is greater than the RECV_QUEUE_THRESH, then a semaphore is set, recvdChar, to indicate that a full character has been received.  The FTM / TPM clock is turned off, and the pin interrupt functionality of the receive pin is enabled.  The final step in the interrupt routine is to increment the receive queue index, recvQueueIndex.  This variable points to the current entry in the receive queue array. Using DMA to receive characters When using DMA, the receive FTM / TPM interrupt is much different. The interrupt routine simply needs to clear the channel interrupt flag, stop the FTM / TPM timer, disable the DMA channel, and set the received character semaphore.  The character is then decoded outside of the interrupt routine.  The interrupt function when using DMA is shown below: Decoding the received pulse widths Once the array of pulse widths has been populated, the received character needs to be translated into a single number.  This varies slightly when using DMA and when not using DMA. However, the basic principle is the same.  The number of bits in a single entry is determined by dividing by the expected bit width and this is translated into a temporary array that contains 1's and 0's, and then that is used to shift in the appropriate number of 1's and 0's into the returned char variable.  A temporary array is needed because the values are shifted into the UART LSB first, so the bit must be physically flipped from the first entry to the last.  There is no logical operation that will do this automatically. The algorithm to perform this translation is shown below.  In this algorithm, note that recvPulseWidth is the array that contains the raw count value of the pulse width.  The array tempRxChar holds the decoded character in reverse order and rxChar is a char variable that holds the received character. Conclusion This document provides an overview of the UART protocol and describes a method for creating a software UART using the timing features of the FTM or TPM peripheral.  This method allows for accurate timing and while not relying entirely on the CPU and the latency associated with the interrupt and the GPIO pins.  The receive function is open to further optimization by using DMA, which can provide further unloading of the CPU.
記事全体を表示
The attached zip file contains software that accompanies the document UART Emulation Using the FTM or TPM.  It contains two sample applications:  one that uses the TPM, and one that uses the FTM. The TPM example targets the FRDM-KL26Z development board and is written in baremetal code.  The FTM example targets the TWR-K22F120M and FRDM-K22F and is written using the Kinetis SDK 1.0 release.  Installation instructions are contained within the zip package. Unzip the package to an empty folder and then copy the appropriate folders to the the appropriate locations on your PC per the instructions located in the zip file. 
記事全体を表示
在KE系列MCU中提供了多种寄存器用于实现GPIO的控制:    -PDOR寄存器,用于写入或读取IO的输出状态    -PSOR寄存器,用于置位IO口    -PCOR寄存器,用于清零IO口    -PTOR寄存器,用于翻转IO口    -PDIR寄存器,用于读取IO口的输入状态 当我们想要将PTA0置1时,有多种方法可以选择:    1. 直接操作寄存器,PDOR或PSOR都可以实现:          GPIOA->PDOR |= 0x0001;          GPIOA->PSOR |= 0x0001;          直接操作寄存器的效率更高,但可读性较差。    2. 使用官方的库函数操作       GPIO_PinSet(GPIOA, GPIO_PTA0);       库函数的可读性很好,但显得有些啰嗦,字符较多。 通过KE的BME来实现GPIO的操作能够很好的解决上面的问题,只用将附件中的头文件gpio_bitdef.h包含到工程里,再调用里边的宏定义就可以了。 对PTA0置位和清零可以使用下面的语句: POUTA0 = -1; POUTA0 = 0; 读取PTA0的输入状态则可以使用: tmp = PINA0; 上面的语句是不是看上去简洁了很多呢。 实际上上面GPIO的读写指令,是通过BME的BFI(位域插入)和BFX(位域提取)指令来实现的。 -其中ADDR是存储空间内的地址,我们最终操作的还是GPIO的寄存器,因此在两个指令中分别取GPIOA的PDOR寄存器地址和PDIR寄存器地址。 -bit则表示需要插入或提取位域的起始位置,由于这里是PTA0,PTA0位于寄存器的最低位,因此这里填入了0。 -width则表示需要插入或提取位域的宽度,我们只对单个管脚进行操作,也就是单个位进行操作,宽度自然就是1了。 需要注意的是,BFI(位域插入)指令在插入时,是将对应位插入到目的地址。因此,如果直接为POUTxx赋值为1的话,有可能出现错误。 POUTA0 = 0x01;//正确 POUTA1 = 0x02;//正确 POUTA2 = 0x04;//正确 POUTA1 = 0x01;//错误 为了避免这种情况,我们可以在IO口需要置位时,直接将POUTxx赋值为-1,即0xFFFF FFFF,这样保证了每一位的值都为1。 #define BME_BFI(ADDR,bit,width)        (*(volatile uint32_t *)((((uint32_t)ADDR&0xFFFF))   \                                   | (5 <<28)  \                                   | ((bit)<<23) | ((width-1))<<19)) #define BME_BFX(ADDR,bit,width)        (*(volatile uint32_t *)(((uint32_t)ADDR&0xFFFF)    \                                   | (5 <<28)  \                                   | ((bit)<<23) | ((width-1))<<19))  #define POUTA0 BME_BFI(&GPIOA->PDOR,0,1) #define PINA0 BME_BFX(&GPIOA->PDIR,0,1) ‍‍‍‍‍‍‍‍‍‍
記事全体を表示
浙江地区去年下半年开始到现在,在一些电机控制客户中推广KE02,主要是低功率风机,BLDC,交流异步电机等。 总结了一些KE02在做电机控制方面的不足。 增加一点: (1) KE02 FTM PWM输出与NMI Pin 复用,上电容易烧管子
記事全体を表示
http://dorkbotpdx.org/blog/paul/teensy_audio_library_gets_spdif_support Digital optical audio output from kinetis based teensy 3.1
記事全体を表示
New 32-bit MCUs designed to transform consumer and industrial applications currently using legacy 8- and 16-bit architectures SAN ANTONIO, Jun 19, 2012 (BUSINESS WIRE) -- Freescale Semiconductor FSL +0.80% is now offering alpha samples of its Kinetis L series, the industry's first microcontrollers (MCUs) built on the  ARM(R) Cortex(TM)-M0+ processor. Kinetis L series devices are on display this week at the Freescale        Technology Forum (FTF) Americas and were demonstrated during the event's opening keynote address. As machine-to-machine communication expands and network connectivity  becomes ubiquitous, many of today's standalone, entry-level applications will require more intelligence and functionality. With the Kinetis  L series , Freescale provides the ideal opportunity for users of legacy 8- and 16-bit architectures to migrate to 32-bit platforms and bring additional intelligence to everyday devices without increasing power  consumption and cost or sacrificing space. Applications, such as small  appliances, gaming accessories, portable medical systems, audio systems, smart meters, lighting and power control, can now leverage 32-bit capabilities and the scalability needed to expand future product lines -- all at 8- and 16-bit price and power consumption levels. "In our view, 8- and 16-bit development has reached the end of the road. Those architectures simply can't keep up as the Internet of Things gains traction," said Geoff Lees, vice president and general manager of Freescale's Industrial & Multi-Market MCU business. "Kinetis L series MCUs are ideal for the new wave of connected applications, combining the required energy efficiency, low price, development ease and small  footprint with the enhanced performance, peripherals, enablement and scalability of the Kinetis 32-bit portfolio." Extreme energy efficiency The ARM Cortex-M0+ processor consumes approximately one-third of the energy of any 8- or 16-bit processor available today, while delivering  between two to 40 times more performance. The Kinetis L series supplements the energy efficiency of the core with the latest in  low-power MCU platform design, operating modes and energy-saving peripherals. The result is an MCU that consumes just 50 uA/MHz* in very-low-power run (VLPR) mode and can rapidly wake from a reduced power state, process data and return to sleep, extending application battery life. These advantages are demonstrated in the FTF demo, which compares the energy-efficiency characteristics of the Kinetis L series against solutions from Freescale competitors in a CoreMark benchmark analysis.        The Kinetis L series is also part of the Freescale Energy-Efficient Solutions program. Kinetis L series energy-saving peripherals do more with less power by maintaining functionality even when the MCU is in deep sleep modes. In traditional MCUs, the main clock and processor core must be activated to perform even trivial tasks such as sending or receiving data, capturing or generating waveforms or sampling analog signals. Kinetis L series peripherals are able to perform these functions without involving the core or main system, drastically reducing power consumption and improving battery life. Built using Freescale's innovative, award-winning flash memory technology, the Kinetis L series offers the industry's lowest-power flash memory implementation. This improves upon the conventional silicon-based charge storage approach by creating nano-scale silicon islands to store charge instead of using continuous film, improving the flash memory's immunity to typical sources of data loss. "The Internet of Things needs very low-cost, low-power processors that        can deliver good performance," said Tom R. Halfhill, a senior analyst        with The Linley Group and senior editor of Microprocessor Report. "As  the first 32-bit microcontrollers to use ARM's Cortex-M0+ processor core, Freescale's Kinetis L-series MCUs will bring the energy efficiency and prices typically associated with 8- and 16-bit MCUs to a broad range of consumer and industrial applications." Development simplicity The Kinetis L series addresses the ease-of-use requirement critical for entry-level developers through innovations including: -- The Freescale Freedom development platform, a small, low-power, cost-efficient evaluation and development system for quick application prototyping and demonstration. It combines an industry-standard form factor with a rich set of third-party expansion board options. An integrated USB debug interface offers an easy-to-use mass-storage device mode flash programmer, a virtual serial port and classic programming and run-control capabilities. -- Processor Expert software, a GUI-based, device-aware software generation tool that eliminates the need to write peripheral start-up code or device drivers. Helps developers easily migrate from 8- and 16-bit to 32-bit solutions by simplifying the software architecture and  dramatically reducing application development time. --  The Kinetis MCU Solution Advisor, a web-based application with an interactive MCU product selector that helps identify the best-suited MCU by applying dynamic filters based on operating characteristics, packaging options, memory configuration and peripheral hardware library. Integration and scalability Each Kinetis L series family includes scalable flash memory options, pin-counts and analog, communication, timing and control peripherals, providing easy migration paths for end product line expansion. Features common to the Kinetis L series families include: --         48 MHz ARM Cortex-M0+ core --         High-speed 12/16-bit analog-to-digital converters --         12-bit digital-to-analog converters --         High-speed analog comparators --         Low-power touch sensing with wake-up on touch from reduced power states --         Powerful timers for a broad range of applications including motor control The first three Kinetis L series families: --         Kinetis L0 family -- the entry point into the Kinetis L series. Includes eight to 32 KB of flash memory and ultra-small 4mm x 4mm QFN packages. Pin-compatible with the Freescale 8-bit S08P family. Software- and tool-compatible with all other Kinetis L series families. --         Kinetis L1 family -- with 32 to 256 KB of flash memory and  additional communications and analog peripheral options. Compatible with the Kinetis K10 family. --         Kinetis L2 family -- adds USB 2.0 full-speed host/device/OTG. Compatible with the Kinetis K20 family. The Kinetis L series is pin- and software-compatible with the Kinetis  K series (built on the ARM Cortex-M4 processor), providing a migration path to DSP performance and advanced feature integration. Availability and pricing Kinetis L series alpha samples are available now, with broad market sample and tool availability planned for Q3. Pricing starts at a suggested resale price of 49 cents (USD) in 10,000-unit quantities. The Freescale Freedom development platform is planned for Q3 availability at  a suggested resale price of $12.95 (USD). For more information about Kinetis L series MCUs, visit   www.freescale.com/Kinetis/Lseries    . *Typical current at 25C, 3V supply, for Very Low Power Run at 4MHz core  frequency, 1MHz bus frequency running code from flash with all peripherals off. About the Freescale Technology Forum Created to drive innovation and collaboration, the Freescale Technology Forum (FTF) has become one of the developer events of the year for the embedded systems industry. The Forum has drawn more than 48,000 attendees at FTF events worldwide since its inception in 2005. Our annual flagship event, FTF Americas, takes place June 18-21, 2012, in San Antonio, Texas. About Freescale Semiconductor Freescale Semiconductor  FSL +0.80% is a global leader in embedded processing solutions, providing industry leading products that are advancing the automotive, consumer, industrial and networking markets. From microprocessors and microcontrollers to sensors, analog integrated  circuits and connectivity -- our technologies are the foundation for the innovations that make our world greener, safer, healthier and more connected. Some of our key applications and end-markets include automotive safety, hybrid and all-electric vehicles, next generation wireless infrastructure, smart energy management, portable medical  devices, consumer appliances and smart mobile devices. The company is  based in Austin, Texas, and has design, research and development,        manufacturing and sales operations around the world.   www.freescale.com Freescale, the Freescale logo, Energy Efficient Solutions logo, Kinetis  and Processor Expert are trademarks of Freescale Semiconductor, Inc.,  Reg. U.S. Pat. & Tm. Off. ARM is the registered trademark of ARM  Limited. Cortex is the trademark of ARM Limited. All other product or  service names are the property of their respective owners. (C) 2012   Freescale Semiconductor, Inc. Photos/Multimedia Gallery Available:   http://www.businesswire.com/cgi-bin/mmg.cgi?eid=50313420&lang=en SOURCE: Freescale Semiconductor
記事全体を表示
FINALISTAS Después de un profundo análisis de todos los proyectos, nuestros jueces realizaron la difícil selección de los finalistas del Kinetis L MCU Challenge México entre los que el público elegirá al ganador; gracias a la excelente respuesta decidimos nombrar 16 finalistas.  Ellos son: Project Name Contestan Name Description Video Sistema de monitoreo de la contaminación acústica #MonitoreoAcustico Lucio Canche Diseño de una placa para monitoreo de niveles de ruido utilizando un sensor de sonido. Permite el estudio detallado de los patrones de propagación del sonido. Movimiento de un carro controlado #CarroPelotasAntiestres Emilio Jiménez Auto de juguete controlado por medio de pulsaciones realizadas con 2 pelotas anti-estrés, el presionar una pelota hará que el vehículo avance hacia adelante y la otra hará que gire sobre su propio eje. Viking lever #VikingLever Ma. Fernanda Gutierrez Consiste en un sistema de una palanca con contrapeso; tendrá en la punta una pelota con una led que indicará cuando el usuario tiene que golpearla. Controlador para el suministro de agua de una vivienda #ControladorAgua Rogelio Rosales El objetivo es el ahorro de agua. En un tinaco se colocan 2 sensores, uno a nivel alto y el otro a nivel bajo de agua. Dependiendo del nivel del agua los sensores mandan la señal a la bomba para que se encienda o apague. Rehab glove #RehabGlove Alexis Castañón Guante que posee sensores de flexión en las articulaciones de los dedos y de fuerza en las yemas, con el fin de enviar instrucciones a algún aparato, mientras el usuario realiza ejercicios como cerrar el puño o tocar las yemas de los dedos con el pulgar. Tablet braile para invidentes #TabletBraille Andres Gafford Tableta para leer ebooks braile con botones para cambiar de página, apagar y encender, que sean fáciles de percatar por un invidente; así como botones interactivos que desplieguen opciones del menú. Tapete interactivo para discapacitados #TapeteInteractivo Angel Campoy Este tapete interactivo, contribuye al desarrollo motriz. El teclado cuenta con cuatro botones, los cuales tienen un led que se enciende indicando al paciente que debe presionar el boton. Si activo el boton indicado,se enciende un LED verde o rojo si se equivocó. Neck remote control wheel chair #NeckControl Francisco Javier Pérez Corona Silla de ruedas controlada moviendo el cuello a la izquierda o derecha, presionando un botón con la cabeza, que a su vez haga avanzar o girar. Control de sensores infrarrojos para silla de ruedas #SensoresSilla Jesús Lizárraga Silla de ruedas diseñado para personas con parálisis cerebral. El usuario debe colocar las dos manos al ifgual que los codos por encima de los espacios indicados, los sensores se activarán haciendo que la silla avance o gire hacia el lado en que la persona posicionó la mano. N-drid uleta #NdridRuleta Jorge Rodriguez Rodriguez Juego de ruleta de leds de 4 colores, el usuario acumulará puntos cada vez que logre presionar el botón del color en donde parará la ruleta. KMA #KMA Luis Castellanos Prototipo para silla de ruedas que será controlada con un dispositivo de fácil manejo,  comunicado a la silla por bluethooth. Sensilla #Sensilla Miguel Rogel Silla móvil manipulada por sensores y con esto lograr desplazarse de una manera más accesible a sus capacidades. Pest control using Freescale #PestControl Pablo Yerena Este proyecto consiste en el control de plagas de manera ecológica, con la implementación de un aparato electrónico que emite frecuencias ultrasónicas evitando que animales e insectos invadan espacios físicos. Tren de colores musical #TrenColores Ricardo Villaseñor Juguete donde se utiliza un sensor óptico para la lectura de pequeños cubos de colores, donde cada color es una nota musical. Al colocar el lector sobre el cubo de color se emitirá la nota correspondiente. Morse deaf-mute communication system #MorseDeafMute Roberto Vite Ruiz Dispositivo de escritura basado en el código morse. Se muestra un código morse para cada letra del alfabeto permitiendo a una persona sorda o muda darse a entender de manera escrita.       Casco acelerómetro #CascoAcelerometro José Ramón Rodriguez Dispositivo  para silla de ruedas que  permite al paciente transportarse autónomamente mediante una especie de casco que detecte la dirección deseada, además de que sea una manera recreativa de trasladarse Podrás participar calificando cada proyecto a través de redes sociales y la herramienta RankTab; la votación se abrirá el día del evento a partir de las 9:00am, espera las instrucciones a través de la Comunidad Freescale,  Facebook y durante el evento. A todos los finalistas los esperamos el 07 de Diciembre a las 8:00hrs en el Centro de Congresos del Tecnológico de Monterrey Campus Guadalajara, donde se develará el misterio y conoceremos al ganador del viaje al Freescale Technology Forum (FTF) en Dallas, Texas del 08 al 11 de Abril del 2014. Para solicitar mayor información, favor de enviar un correo a cristina.garcia@mclgx.comA
記事全体を表示
Hi Team :      We are working on KSDK project recently . I would like to share an experience to migrate a project to a new device that is not listed in KSDK . I hope that helpful . Best regards, David
記事全体を表示
    Curve22519 is a Montgomery elliptic-curve. Such as Apple HomeKit, most of network and IoT software use it in Diffie-Hellman algorithm for key exchanging.     On the Security Kinets MCU chip,if we use just the software algorithm (base on mbedTLS), Curve25519 will spend 180ms for calculation of the shared security.     It is faster than other 256bit elliptic-curve with software algorithm, Because of the shared security calculation will take more than 1200ms with a Weierstrass’s BP256R1curve when use software algorithm.     With LTC ECC HW acceleration, it take only 16ms to calculate the shared security on 256bit elliptic-curve. Whatever you do, the speed of hardware acceleration always faster than the software algorithm.     Now that we should also want to use the LTC to accelerate the Curve22519. The LTC, however, only supported Weierstrass form curve, but Curve22519 is a Montgomery curve…     Although, we can't use LTC in Curve22519 directly, we can use it by mapping it to a Weierstrass form to use it.  As below, we gave parameters of these curves, transform formulas, example code and test result to show how and why to do it. 1. Curve parameter:    Cuvre22519 in Montgomery form:    Y^2 = X^3 + A*X^2 + X    Fp = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffed    A= 486662    Gx = 9    Gy = 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9    Order of G point  =  0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed      Cuvre22519 in Weierstrass form :    Y^2 = X^3 + a*X + b    Fp = 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffed    a  =  0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa984914a144L    b  =  0x7b425ed097b425ed097b425ed097b425ed097b425ed097b4260b5e9c7710c864L    Gx = 0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaad245a    Gy = 0x20ae19a1b8a086b4e01edd2c7748d14c923d4d7e6d7c61b229e9c5a27eced3d9    Order of G point  =  0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed    2. Calculation formula:   x_w –  x-coordinate value in  Weierstrass form   y_w –  y-coordinate value in  Weierstrass form   x_m - x-coordinate value in  Montgomory form   y_m -  we don’t care y-coordinate value in  Weierstrass mode   a_m – a coefficient of Montgomery equation (   Y^2 = X^3 + a_m * X^2 + X)   a_w – a coefficient of Weierstrass equation (   Y^2 = X^3 + a*X + b )   b_w – a coefficient of Weierstrass equation (   Y^2 = X^3 + a*X + b )     a)  x_w = (x_m + a_m/3)  %  p     b)  y_w ^2 = x_w ^ 3 + a_w*x_w + b_w c)   x_m = (x_w - a_m/3) % p You could reference these document as below: https://en.wikipedia.org/wiki/Curve25519 https://en.wikipedia.org/wiki/Montgomery_curve 3. example code: // public and private at Montgomery end #define M255_d      "0x7178DAC11D42AA5F39B10A62A8584DB0C8864564ADC9DF84EC0B13D9AEC220F8" #define M255_Qx     "0x3BA5048381744348D84E754B9944ABE080B37F7D4158DCE60CD79F66B98AB89E" // public and private at Weierstrass end #define WTS255_d    "0x09CC5CCF43C656C1309EE5A3491D5A8361607CEEB0C9B2B31A575E0FEF2B8835" #define WTS255_Qx   "0x3F4BDE110EE7AF71EF428D1018D188E35BAFB019F34F84E6465C5194B363DC2D" #define WTS255_Qy   "0x7540577CE6F920354E2A9D38CE88847D7447E66FA4D188AC75CB63C17210B718" #define WTS255_Qx_TO_M255_Qx     "0x14A13366643D04C74497E2656E26DE38B105056F48A4DA3B9BB1A6EA08B6B7DC" #define AM_INV3                  "0x2aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaad2451" int ecdh_wts_curve_end( ) {     unsigned int ticks;     int ret = 0;     size_t blen = 0, blen_peer = 0;     ecdh_context ecdh;     ecdh_context ecdh_peer;   // to_wts255     ecdh_context ecdh_peer_m255;     mpi R;     mpi_init(&R);     ecdh_init( &ecdh);     ecdh_init( &ecdh_peer);     ecdh_init( &ecdh_peer_m255);     MPI_CHK(ecp_use_known_dp( &ecdh.grp, ECP_DP_WTS25519 ));     MPI_CHK(ecp_use_known_dp( &ecdh_peer.grp, ECP_DP_WTS25519 ));     MPI_CHK(ecp_use_known_dp( &ecdh_peer_m255.grp, ECP_DP_M255 ));     blen = set_hash_buff(/*TEST_ECP_GRP_ID*/ECP_DP_WTS25519, &secret_buf, ecp_name);     if(blen == 0) {         ret = -1;         goto cleanup;     }     mpi_read_string(&ecdh.d, 16,  WTS255_d);     mpi_read_string(&ecdh.Q.X, 16,  WTS255_Qx);     mpi_read_string(&ecdh.Q.Y, 16,  WTS255_Qy);     mpi_lset(&ecdh.Q.Z, 1);     mpi_read_string(&ecdh_peer_m255.d, 16, M255_d);     mpi_read_string(&ecdh_peer_m255.Q.X, 16, M255_Qx);     mpi_init(&ecdh_peer_m255.Q.Y);     mpi_lset(&ecdh_peer_m255.Q.Z, 1);     // map M255 point to WTS255 point     my_timer_start();     mpi_read_string(&R, 16, AM_INV3);         mpi_add_mpi(&ecdh_peer.Q.X, &ecdh_peer_m255.Q.X, &R);     mpi_mod_mpi(&ecdh_peer.Q.X, &ecdh_peer.Q.X, &ecdh_peer_m255.grp.P);        mpi_lset(&R, 3);     mpi_exp_mod (&ecdh_peer_m255.Q.Y , &ecdh_peer.Q.X, &R, &ecdh_peer_m255.grp.P, NULL);     mpi_mul_mpi(&R, &ecdh_peer.grp.A, &ecdh_peer.Q.X);     mpi_mod_mpi(&R, &R, &ecdh_peer.grp.P);          mpi_add_mpi(&ecdh_peer_m255.Q.Y, &ecdh_peer_m255.Q.Y, &R);     mpi_add_mpi(&ecdh_peer_m255.Q.Y, &ecdh_peer_m255.Q.Y, &ecdh_peer.grp.B);     mpi_mod_mpi(&ecdh_peer_m255.Q.Y, &ecdh_peer_m255.Q.Y, &ecdh_peer.grp.P);     mpi_mod_sqrt(&ecdh_peer.Q.Y, &ecdh_peer_m255.Q.Y, &ecdh_peer_m255.grp.P);     // z = 1     mpi_lset(&ecdh_peer.Q.Z, 1);     MPI_CHK(ecp_copy(&ecdh.Qp,  &ecdh_peer.Q));     MPI_CHK(ecdh_calc_secret_wts2mont( &ecdh, &blen, secret_buf, blen, myrand, NULL));     mpi_read_string(&R, 16, AM_INV3);         mpi_sub_mpi(&ecdh_peer_m255.Q.X, &ecdh.Q.X, &R);     mpi_mod_mpi(&ecdh_peer_m255.Q.X, &ecdh_peer_m255.Q.X, &ecdh_peer_m255.grp.P);     ticks = my_timer_stop();     // print out message     polarssl_printf("Weierstrass curve shared secutiy:\n");     mpi_printf_string( &ecdh.z, 16);     polarssl_printf("%s ecdh peer to peer: %lu ticks, %d ms (%d) \n", ecp_name , ticks, ticks / (CLOCK_SYS_GetPitFreq(0) / 1000),CLOCK_SYS_GetPitFreq(0) );     cleanup:     if( ret !=0 )         polarssl_printf( "%s test Unexpected error, return code = %08X\n", ecp_name, ret );     mpi_free(&R);     ecdh_free( &ecdh);     ecdh_free( &ecdh_peer);     ecdh_free( &ecdh_peer_m255);         return( 0 );    } int ecdh_mont_curve_end( ) {     int verbose = 1;     unsigned int ticks;     int ret = 0;     size_t blen = 0, blen_peer = 0;     ecdh_context ecdh;     ecp_point Q_peer;          // peer public point     ecdh_init( &ecdh);     ecp_point_init( &Q_peer);     MPI_CHK(ecp_use_known_dp( &ecdh.grp, ECP_DP_M255 ));     blen_peer = set_hash_buff(ECP_DP_M255, &secret_buf_peer, ecp_name);     if(blen_peer == 0) {         ret = -1;         goto cleanup;     }     mpi_read_string(&ecdh.d, 16,  M255_d);     mpi_read_string(&ecdh.Q.X, 16,  M255_Qx);     mpi_init(&ecdh.Q.Y);   // don't care Y, only init it     mpi_lset(&ecdh.Q.Z, 1);     mpi_read_string(&Q_peer.X, 16, WTS255_Qx_TO_M255_Qx);     mpi_init(&Q_peer.Y);     mpi_lset(&Q_peer.Z, 1);        MPI_CHK(ecp_copy(&ecdh.Qp,  &Q_peer));     my_timer_start();     MPI_CHK(ecdh_calc_secret( &ecdh, &blen_peer, secret_buf_peer, blen_peer, myrand, NULL));     ticks = my_timer_stop();     polarssl_printf("%s ecdh peer to peer: %lu ticks, %d ms (%d) \n", ecp_name , ticks, ticks / (CLOCK_SYS_GetPitFreq(0) / 1000),CLOCK_SYS_GetPitFreq(0) );     polarssl_printf("Montogemory curve shared secutiy:\n");     mpi_printf_string( &ecdh.z, 16);     polarssl_printf( "passed\n" );     cleanup:     if( ret !=0 && verbose != 0 )         polarssl_printf( "%s test Unexpected error, return code = %08X\n", ecp_name, ret );     ecdh_free( &ecdh);     ecp_point_free( &Q_peer);     if( verbose != 0 )         polarssl_printf( "\n" );         return( 0 );    } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 4. Test result: Test result of curv25519 in  Weierstrass form with LTC:     2. Test result of curve25519 in Montgomery form with software algorithm:      We could see that the shared security both in Weierstrass form with LTC and Montgomery form are “0x1454BDCD6A94D6336AA5A76F3CB40BBE12B65A2CDC9DA6B478948906638896D1”. But the calculation speed with LTC was ten times faster than other one.
記事全体を表示
Basic explanation of the ADC module. Explicación básica del modulo de ADC.
記事全体を表示
I have included the files needed to mass erase the flash of the MCU and re-program another binary.   The procedure is shown in the folder " FRDM-KW31_FAT_added_2019" Summarizing you... 1) update the debugger with bootloader mode (press reset and plug in usb cable) drag and drop .sda file on MSD bootloader. 2) unplug and re-plug USB. program the flashloader_loader_mkv31f512.bin by dragging and dropping the binary on to the virtual mass storage device FRDM-KV31 which appear when you plug the USB cable from the FRDM-KV31 to the PC.  3) Open a CMD prompt window and navigate to the folder the files were unzipped to. 4) Determine the COM port by using the device manager 5) from the CMD prompt run the batch file      Erase_KMS_program_bubble.bat COMX
記事全体を表示
1. Freedom开发板: 飞思卡尔Freedom开发平台是一套低成本的用于性能评估和软件开发的工具,自带板载调试器,用户可以直接通过自己的PC机快速搭建开发环境并进行测试和评估芯片简单的外设资源。一般来说,同一个系列功能互相兼容的芯片会推出一款Freedom开发板来评估,具体分类如下: Freedom开发板 可以覆盖的芯片型号 开发板代码包 FRDM-KL02Z Kinetis KL02 MCUs KL02_SC FRDM-KL03Z Kinetis KL03 MCUs Kinetis SDK for KL03 FRDM-KL05Z Kinetis KL04 and Kinetis KL05 MCUs KL05_SC FRDM-KL25Z Kinetis KL14, Kinetis KL15, Kinetis KL24 and Kinetis KL25 MCUs KL25_SC FRDM-KL26Z Kinetis KL16 and Kinetis KL26 MCUs KL26_SC FRDM-KL43Z Kinetis KL17, Kinetis KL27, Kinetis KL33 and Kinetis KL43 MCUs FRDM-KL43_SC FRDM-KL46Z Kinetis KL36 and Kinetis KL46 MCUs KL46_SC FRDM-KE02Z Kinetis KE02_20M MCUs KEXX_DRIVERS_V1.2.1_DEVD FRDM-KE02Z40M Kinetis KE02_40M MCUs KEXX_DRIVERS_V1.2.1_DEVD FRDM-KE04Z Kinetis KE04 MCUs KEXX_DRIVERS_V1.2.1_DEVD FRDM-KE06Z Kinetis KE06 MCUs KEXX_DRIVERS_V1.2.1_DEVD 2. TWR开发板: 飞思卡尔塔式系统开发板为可扩展性比较强的评估板,板载资源比较丰富且通过构建塔式系统可以灵活的添加和裁剪外设资源,用户可以通过与相应外设塔式板结合使用进行更高级和复杂的功能测试或验证。 Tower开发板 可以覆盖的芯片型号 Header 3 TWR-KL25Z48M Kinetis KL14, Kinetis KL15, Kinetis KL24 and Kinetis KL25 MCUs KL25_SC TWR-KL43Z48M Kinetis KL17, Kinetis KL27, Kinetis KL33 and Kinetis KL43 MCUs TWR-KL43Z48_SC TWR-KL46Z48M Kinetis KL16, Kinetis KL26, Kinetis KL36 and Kinetis KL46 MCUs KL46_SC TWR-KM34Z50M Kinetis KM3x MCUs KMSWDRV TWR-KV10Z32 Kinetis KV1x TWR-KV10Z32_SC 3. 第三方开发板 (1) MAPS四色板套件 (2) YL-KL26Z 开发板
記事全体を表示