Huawei_LiteOS在STM32系列处理器上的移植-Huawei_LiteOS_workshop

华为LiteOS操作系统基础知识入门与内核移植LiteOS操作系统是华为在2015年发布的一个轻量级的面向物联网的操作系统，同时也是华为物联网1+2+1物联网解决方案的组成部分，此操作系统具备零配置，自发现，自组网的特点，让LiteOS的终端物联能够自动接入支持的网络，使得硬件开发变得更加简单，对于开发者来说也有很强的便利性。

本文章将对LiteOS操作系统基本结构及应用场景进行简单介绍，最后介绍如何移植LiteOS内核。

1. LiteOS内核结构简介HUWEI LiteOS内核结构如图所示，其内核主体可分为硬件抽象层，基础内核和扩展内核，其中基础内核中的极小内核是LiteOS操作系统能够裁剪的最小单位，包括任务管理、内存管理、中断管理、异常管理和系统时钟等功能，可裁剪部分则包括信号量、互斥锁、队列管理、事件管理、软件定时器等。

而除了基础内核，Huawei LiteOS 还提供了扩展内核，包括C++支持、动态加载、低功耗以及维测模块。

低功耗通过支持Tickless机制、run-stop休眠唤醒，可以大大降低系统功耗。

维测部分包含了获取CPU占用率、支持串口执行Shell命令等功能。

除此之外，LiteOS也具有云端协同的能力，集成了全套IOT 协议，LwM2M、CoAP、mbedtls、LwIP等。

2. 应用场景举例基于其可裁剪型强，对MCU环境适配性强等优势，LiteOS在多个领域都得到了广泛应用在家居领域，华为推出了华为HiLink智能家居解决方案，该方案结构图如图所示从图中看，该方案主要由HiLink SDK，智能设备，HiLink智能路由，云平台，手机APP及互联协议组成；整体的运作流程是，生态伙伴产品硬件内部已经安装了HiLink SDK及LiteOS内核，基于内核含有的通信协议（Zigbee,NBioT）等，与HiLink智能路由产生联系，生态伙伴产品通过智能路由组网与APP和家庭云互传信息，以达到智能家居的效果。

第６期２０２０年１２月机电元件ＥＬＥＣＴＲＯＭＥＣＨＡＮＩＣＡＬＣＯＭＰＯＮＥＮＴＳＶｏｌ ４０Ｎｏ ６Ｄｅｃ ２０２０收稿日期：２０２０－１０－２０基于ＳＴＭ３２单片机的ｕＣ／ＯＳ－ＩＩ操作系统移植张中前（贵州航天电器股份有限公司，贵州贵阳，５５０００９） 摘要：网络技术和信息技术的发展，嵌入式系统应用越来越普及，嵌入式设备的应用也越来越多。

ｕＣ／ＯＳ－ＩＩ广泛应用于路由器、飞行器及工业控制等。

ｕＣ／ＯＳ－ＩＩ操作系统执行效率高，占用存储空间少，具有实时性及可扩展性等优点，在小型嵌入式设备中具有广泛应用。

本文介绍了基于ＡＲＭＣＯＲＴＥＸＭ３系列单片机上的ｕＣ／ＯＳ－ＩＩ移植，对电子控制组件的设计具有参考作用。

关键词：实时操作系统；ｕＣ／ＯＳ－ＩＩ；内存管理；任务管理；ＳＴＭ３２；移植Ｄｏｉ：１０．３９６９／ｊ．ｉｓｓｎ．１０００－６１３３．２０２０．０６．０１５中图分类号：ＴＮ７８４ 文献标识码：Ａ 文章编号：１０００－６１３３（２０２０）０６－００５７－０５１　引言操作系统是裸机的第一层软件，操作系统直接运行在硬件上，上层软件通过提供应用程序接口（ＡＰＩ函数），实现对底层硬件的访问，同时，通过操作系统实现对多个上层应用软件（任务）管理，实现对硬件ＣＰＵ管理、存储管理、Ｉ／Ｏ接口管理及文件管理，如图１所示。

图１　操作系统功能组成示意图 ＳＴＭ３２系列单片机以其优良的价格，大容量的ＦＬＡＳＨ及ＲＡＭ存储空间，极易用于较为复杂的控制系统；在ＳＴＭ３２单片机上进行ｕＣ／ＯＳ－ＩＩ实时操作系统的移植，提高了产品的设计灵活性，实现较为复杂的系统功能；通过将开源的ｕＣ／ＯＳ－ＩＩ移植在ＳＴＭ３２单片机上，以其较为低廉的硬件成本获得较高的使用性能，具有良好的应用前景。

２　ｕＣ／ＯＳ－ＩＩ操作系统２．１　ｕＣ／ＯＳ－ＩＩ操作系统的基本特征ｕＣ／ＯＳ－ＩＩ是一个完整的、可移植、可固化、可剪裁的基于优先级调度的抢占式实时多任务操作系统；它能够在外界事件或数据产生时，能够接收图２　ｕＣ／ＯＳ－ＩＩ文件结构示意图并以足够快的速度响应，其处理的结果又能够在规定的时间内输出，并控制所有实时任务协调、一致运行。

March 2012Doc ID 018976 Rev 21/52AN3422Application noteMigration of microcontroller applicationsfrom STM32F1 to STM32L1 series1 IntroductionFor designers of STM32 microcontroller applications, it is important to be able to easily replace one microcontroller type by another one in the same product family. Migrating an application to a different microcontroller is often needed, when product requirements grow, putting extra demands on memory size, or increasing the number of I/Os. On the other hand, cost reduction objectives may force you to switch to smaller components and shrink the PCB area.This application note is written to help you and analyze the steps you need to migrate from an existing STM32F1 devices based design to STM32L1 devices. It groups together all the most important information and lists the vital aspects that you need to address.To migrate your application from STM32F1 series to STM32L1 series, you have to analyze the hardware migration, the peripheral migration and the firmware migration.To benefit fully from the information in this application note, the user should be familiar with the STM32 microcontroller family. Y ou can refer to the following documents that are available from .●The STM32F1 family reference manuals (RM0008 and RM0041), the STM32F1 datasheets, and the STM32F1 Flash programming manuals (PM0075, PM0063 and PM0068).●The STM32L1 family reference manual (RM0038), the STM32L1 datasheets, and the STM32F1 Flash and EEPROM programming manual (PM0062).For an overview of the whole STM32 series and a comparison of the different features of each STM32 product series, please refer to AN3364 Migration and compatibility guidelines for STM32 microcontroller applications .Contents AN3422Contents1Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2STM32L1 family overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3Hardware migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Peripheral migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1STM32 product cross-compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3Memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4RCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.5DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.6Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.7GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.8EXTI source selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.9FLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.10ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.11PWR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.12RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Firmware migration using the library . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1Migration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2RCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3FLASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.1Output mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.2Input mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.3Analog mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.4Alternate function mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.5EXTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7PWR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2/52Doc ID 018976 Rev 2AN3422Contents5.8Backup data registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Doc ID 018976 Rev 23/52List of tables AN3422 List of tablesTable 1.STM32L1 peripherals compatibility analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table 2.STM32F1 series and STM32L1 series pinout differences . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Table 3.STM32 peripheral compatibility analysis F1 versus L1 series . . . . . . . . . . . . . . . . . . . . . . 13 Table 4.IP bus mapping differences between STM32F1 and STM32L1 series. . . . . . . . . . . . . . . . 15 Table 5.RCC differences between STM32F1 and STM32L1 series . . . . . . . . . . . . . . . . . . . . . . . . 17 Table 6.Performance versus VCORE ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 7.Example of migrating system clock configuration code from F1 to L1 . . . . . . . . . . . . . . . . 22 Table 8.RCC registers used for peripheral access configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Table 9.DMA request differences between STM32F1 series and STM32L1 series . . . . . . . . . . . . 24 Table 10.Interrupt vector differences between STM32F1 series and STM32L1 series. . . . . . . . . . . 26 Table 11.GPIO differences between STM32F1 series and STM32L1 series . . . . . . . . . . . . . . . . . . 29 Table 12.FLASH differences between STM32F1 series and STM32L1 series . . . . . . . . . . . . . . . . . 31 Table 13.ADC differences between STM32F1 series and STM32L1 series . . . . . . . . . . . . . . . . . . . 32 Table 14.PWR differences between STM32F1 series and STM32L1 series. . . . . . . . . . . . . . . . . . . 34 Table 15.STM32F10x and STM32L1xx FLASH driver API correspondence. . . . . . . . . . . . . . . . . . . 39 Table 16.STM32F10x and STM32L1xx PWR driver API correspondence . . . . . . . . . . . . . . . . . . . . 48 Table 17.Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4/52Doc ID 018976 Rev 2AN3422List of figures List of figuresFigure patible board design: LQFP144 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Figure patible board design: LQFP100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Figure patible board design: LQFP64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Figure patible board design: LQFP48 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Doc ID 018976 Rev 25/52STM32L1 family overview AN34226/52Doc ID 018976 Rev 22 STM32L1 family overviewThe STM32L1 platform forms a strong foundation with a broad and growing portfolio. With new products addressing new applications, the complete STM32L product series now comprises three series, STM32L1 Medium-density, STM32L1 Medium-density+ and STM32L1 High-density, all dedicated to ultra low power and low voltage applications.●STM32L1: Designed for ultra-low-power applications that are energy-aware and seek to achieve the absolute lowest power consumption. The L1 series maintains compatibility with the F1 series.–Medium-density devices are STM32L151xx and STM32L152xx microcontrollers where the Flash memory density ranges between 64 and 128 Kbyte–Medium-density+ devices are STM32L151xx, STM32L152xx and STM32L162xx microcontrollers where the Flash memory density is 256 Kbyte–High-density devices are STM32L151xx, STM32L152xx and STM32L162xx microcontrollers where the Flash memory density is 384 KbyteThe ultralow power STM32L1 Medium-density, STM32L1 Medium-density+ and STM32L1 High-density are fully pin-to-pin, software and feature compatible.Table 1.STM32L1 peripherals compatibility analysisPeripheralMedium-density Medium-density+High-density Compatibility CommentsSPI Y es Y es Y es No I2S in L1 Medium-density series WWDG Y es Y es Y es Same features IWDG Y es Y es Y es Same features DBGMCU Y es Y es Y es Same features CRC Y es Y es Y es Same features EXTIY esY es Y es Same features USB FS Device Y es Y es Y es Same features DMA Y es Y es Y es Same features TIM Y es Y es Y es Same features SDIO No No Y es Same features FSMC No No Y es Same features PWR Y es Y es Y es Same features RCC Y es Y es Y es Same featuresUSARTY esY esY esSame features (UART4/5 are available only on High-density)AN3422STM32L1 family overviewDoc ID 018976 Rev 27/52I2C Y es Y es Y es Same features DAC Y es Y es Y es Same features ADC Y es Y es Y es Same features RTC Y es Y es Y es Same features FLASH Y es Y es Y es Same features GPIO Y es Y es Y es Same features LCD glass Y es Y es Y es Same features COMP Y es Y es Y es Same features SYSCFG Y es Y es Y es Same features AES Y es Y es Y es Same features OPAMPY esY esY esSame featuresTable 1.STM32L1 peripherals compatibility analysis (continued)Peripheral Medium-density Medium-density+High-density Compatibility CommentsHardware migration AN34228/52Doc ID 018976 Rev 23 Hardware migrationThe ultralow power STM32L and general-purpose STM32F1xxx families are pin-to-pincompatible. All peripherals shares the same pins in the two families, but there are some minor differences between packages.In fact, the STM32L1 series maintains a close compatibility with the whole STM32F1 series. All power and functional pins are pin-to-pin compatible. The transition from the STM32F1 series to the STM32L1 series is simple as only a few pins are impacted (impacted pins are in bold in the table below).The figures below show examples of board designs that are compatible with both the F1 andthe L1 series.Table 2.STM32F1 series and STM32L1 series pinout differencesSTM32F1 seriesSTM32L1 seriesQFP48 QFP64 QFP100 QFP144Pinout QFP48 QFP64 QFP100 QFP144Pinout 551223PD0 - OSC_IN 551223PH0 - OSC_IN 661324PD1 - OSC_OUT 661324PH1 - O SC_OUT 1166VBAT1166VLCD --73106NC --73106PH2AN3422Hardware migration Figure patible board design: LQFP144Doc ID 018976 Rev 29/52Hardware migration AN342210/52Doc ID 018976 Rev 2AN3422Hardware migrationDoc ID 018976 Rev 211/52Peripheral migration AN342212/52Doc ID 018976 Rev 24 Peripheral migrationAs shown in T able 3 on page 13, there are three categories of peripherals. The commonperipherals are supported with the dedicated firmware library without any modification, except if the peripheral instance is no longer present, you can change the instance and of course all the related features (clock configuration, pin configuration, interrupt/DMA request).The modified peripherals such as: FLASH, ADC, RCC, PWR, GPIO and RTC are different from the F1 series ones and should be updated to take advantage of the enhancements and the new features in L1 series.All these modified peripherals in the L1 series are enhanced to obtain lower powerconsumption, with features designed to meet new market requirements and to fix some limitations present in the F1 series.4.1 STM32 product cross-compatibilityThe STM32 series embeds a set of peripherals which can be classed in three categories:●The first category is for the peripherals which are by definition common to all products.Those peripherals are identical, so they have the same structure, registers and control bits. There is no need to perform any firmware change to keep the same functionality at the application level after migration. All the features and behavior remain the same.●The second category is for the peripherals which are shared by all products but have only minor differences (in general to support new features), so migration from one product to another is very easy and does not need any significant new development effort.●The third category is for peripherals which have been considerably changed from one product to another (new architecture, new features...). For this category of peripherals, migration will require new development at application level.Table 3 gives a general overview of this classification.AN3422Peripheral migrationDoc ID 018976 Rev 213/52Table 3.STM32 peripheral compatibility analysis F1 versus L1 seriesPeripheralF1 seriesL1 seriesCompatibilityCommentsPinoutSW compatibility SPI Y es Y es No I2S in L1 Medium-density series L1 vs. F1: limitation fix Identical Full compatibility WWDG Y es Y es Same features NA Full compatibility IWDG Y es Y es Same features NA Full compatibility DBGMCU Y es Y es Same features NA Full compatibility CRC Y es Y es Same features NA Full compatibility EXTI Y es Y es Same features Identical Full compatibility USB FS Device Y es Y es Same features Identical Full compatibility DMA Y es Y es Same features NA Full compatibility TIM Y es Y es Same featuresIdentical Full compatibility SDIOY esY esSame features (No SDIO in L1 Medium-density and Medium-density+ series)IdenticalFull compatibilityFSMC Y es Y esSame features but only SRAM/NOR memories are supported (No FSMC in L1 Medium-density and Medium-density+ series)Identical Full compatibilityPWR Y es Y es+Enhancement NA Full compatibility for the same feature RCC Y es Y es+EnhancementNAPartial compatibility USART Y es Y es+Limitation fix / One SampleBit method / Oversampling by 8Identical Full compatibility I2C Y es Y es+Limitation fixIdentical Full compatibility DAC Y es Y es+DMA underrun interrupt Identical Full compatibility ADC Y es Y es++New peripheral Identical Partial compatibility RTC Y es Y es++New peripheral Identical for the same feature Not compatible FLASH Y es Y es++New peripheral NA Not compatible GPIO Y es Y es++New peripheral Identical Not compatible CANY esNANANANAPeripheral migration AN342214/52Doc ID 018976 Rev 24.2 System architectureThe STM32L MCU family, based on the Cortex-M3 core, extends ST’s ultra-low-powerportfolio in performance, features, memory size and package pin count. It combines very high performance and ultra-low power consumption, through the use of an optimizedarchitecture and ST’s proprietary ultra-low leakage process, that is also used in the STM8L family. The STM32L family offers three different product lines (STM32L Medium-density, STM32L Medium-density+ and STM32L High-density).4.3 Memory mappingThe peripheral address mapping has been changed in the L1 series vs. F1 series, the mainchange concerns the GPIOs which have been moved from the APB bus to the AHB bus to allow them to operate at maximum speed.The tables below provide the peripheral address mapping correspondence between L1 and F1 series.CEC Y es NA NA NA NA Ethernet Y es NA NA NA NA LCD glass NA Y es NA NA NA COMP NA Y es NA NA NA SYSCFG NA Y es NA NA NA AES NA Y es NA NA NA OPAMPNAY esNANANATable 3.STM32 peripheral compatibility analysis F1 versus L1 series (continued)Peripheral F1 series L1 seriesCompatibilityCommentsPinoutSW compatibility Color key:= New feature or new architecture (Y es++)= Same feature, but specification change or enhancement (Y es+)= Feature not available (NA)AN3422Peripheral migrationDoc ID 018976 Rev 215/52Table 4.IP bus mapping differences between STM32F1 and STM32L1 seriesPeripheralSTM32L1 seriesSTM32F1 seriesBusBase address Bus Base address FSMC AHB0xA0000000AHB 0xA0000000AES 0x50060000NANA DMA20x40026400AHB 0x40020400DMA10x400260000x40020000Flash Interface0x40023C000x40022000RCC 0x400238000x40021000CRC 0x400230000x40023000GPIOG 0x40021C00APB20x40012000GPIOF 0x400218000x40011C00GPIOH 0x40021400NA NA GPIOE 0x40021000APB20x40011800GPIOD 0x40020C000x40011400GPIOC 0x400208000x40011000GPIOB 0x400204000x40010C00GPIOA 0x400200000x40010800USART1APB20x40013800APB20x40013800SP10x400130000x40013000SDIO 0x40012C00AHB 0x40018000ADC10x40012400APB20x40012400TIM110x400110000x40015400TIM100x40010C000x40015000TIM90x400108000x40014C00EXTI 0x400104000x40010400SYSCFG0x40010000NA NAPeripheral migrationAN342216/52Doc ID 018976 Rev 2OP AMP APB10x40007C5C NA NA COMP+RI 0x40007C00NANA DAC 0x40007400APB10x40007400PWR0x400070000x40007000USB device FS SRAM0x400060000x40006000USB device FS0x40005C000x40005C00I2C20x400058000x40005800I2C10x400054000x40005400UART50x400050000x40005000UART40x40004C000x40004C00USART30x400048000x40004800USART20x400044000x40004400SPI30x40003C000x40003C00SPI20x400038000x40003800IWDG 0x400030000x40003000WWDG 0x40002C000x40002C00RTC 0x40002800 (inc. BKP registers)0x40002800LCD 0x40002400NANA TIM70x40001400APB10x40001400TIM60x400010000x40001000TIM50x40000C000x40000C00TIM40x400008000x40000800TIM30x400004000x40000400TIM20x400000000x40000000USB OTG FS NA NA AHB0x50000000ETHERNET MACNA NA 0x40028000ADC2NA NA APB20x40012800ADC3NA NA 0x40013C00TIM8NA NA 0x40013400TIM1NA NA0x40012C00Table 4.IP bus mapping differences between STM32F1 and STM32L1 seriesPeripheralSTM32L1 seriesSTM32F1 seriesBusBase address Bus Base addressAN3422Peripheral migrationDoc ID 018976 Rev 217/524.4 RCCThe main differences related to the RCC (Reset and Clock Controller) in the STM32L1 series vs. STM32F1 series are presented in the table below.CAN2NA NA APB10x40006800CAN1NA NA 0x40006400TIM14NA NA 0x40002000TIM13NA NA 0x40001C00TIM12NA NA 0x40001800TIM5NA NA 0x40000C00BKP registersNA NA 0x40006C00AFIONANAAPB20x40010000Table 4.IP bus mapping differences between STM32F1 and STM32L1 seriesPeripheralSTM32L1 seriesSTM32F1 seriesBusBase addressBusBase address Color key:= Same feature, but base address change = Feature not available (NA)Table 5.RCC differences between STM32F1 and STM32L1 seriesRCC main featuresSTM32F1 seriesSTM32L1 series CommentsMSI NAMulti Speed RC factory-trimmed (64 kHz /128 kHz / 256 kHz / 512 kHz / 1.02 MHz / 2.05 MHz / 4.1 MHz)–Enable/disable RCC_CR[MSION]–Status flag RCC_CR[MSIRDY]HSI 8 MHz RC factory-trimmed 16 MHz RC factory-trimmedNo change to SW configuration:–Enable/disable RCC_CR[HSION]–Status flag RCC_CR[HSIRDY]LSI 40 KHz RC 37 KHz RCNo change to SW configuration:–Enable/disable RCC_CSR[LSION]–Status flagRCC_CSR[LSIRDY]Peripheral migration AN342218/52Doc ID 018976 Rev 2HSE3 - 25 MHzDepending on the product line used1 - 24 MHz No change to SW configuration:–Enable/disable RCC_CR[HSEON]–Status flagRCC_CR[HSERDY]LSE 32.768 kHz 32.768 kHzLSE configuration/status bits are now in RCC_CSR register.–Enable/disable RCC_CSR[LSEON]–Status flagRCC_CSR[LSERDY]In L1 series the LSEON and LSERDY bits occupy bits RCC_CSR[9:8] respectively instead of bit RCC_BDCR[1:0] in F1 series.PLL–Connectivity line: main PLL + 2 PLLs for I2S, Ethernet and OTG FS clock –Other product lines: main PLL–Main PLL for system There is no change to PLL enable/disableRCC_CR[PLLON] and status flag RCC_CR[PLLRDY].However, PLL configuration (clock source selection,multiplication/division factors) are different. In L1 series dedicated bitsRCC_CFGR[PLLDIV] are used to configure the PLL divider parameters and the PLL multiplication factors aredifferent. The PLL sources are only HSI and HSE.System clock sourceHSI, HSE or PLL MSI, HSI, HSE or PLLNo change to SW configuration:–Selection bits RCC_CFGR[SW]–Status flag RCC_CFGR[SWS]However there is one more source, MSI, and the selection bit meanings are different.System clock frequencyup to 72 MHz depending on theproduct line used8 MHz after reset using HSI32 MHz2 MHz after reset using MSIFor STM32L1 Flash wait states should be adapted according to the system frequency, the product voltage range V CORE and the supply voltage range VDD.AHBfrequencyup to 72 MHz up to 32 MHzNo change to SW configuration:configuration bits RCC_CFGR[HPRE]Table 5.RCC differences between STM32F1 and STM32L1 series (continued)RCC main featuresSTM32F1 seriesSTM32L1 seriesCommentsAN3422Peripheral migrationDoc ID 018976 Rev 219/52APB1 frequency up to 36 MHz up to 32 MHzNo change to SW configuration:configuration bits RCC_CFGR[PPRE1].APB2 frequencyup to 72 MHz up to 32 MHzNo change to SW configuration:configuration bits RCC_CFGR[PPRE2].RTC clock sourceLSI, LSE or HSE/128LSI, LSE or HSE clock divided by 2, 4, 8 or 16RTC clock source configuration is done through the same bits (RTCSE[1:0] and RTCEN) but they are located in a different register.In L1 series the RTCSEL[1:0] bits occupy bitsRCC_CSR[17:16] instead of bits RCC_BDCR[9:8] in F1 series.In L1 series the RTCEN bit occupies bit RCC_CSR[22]instead of bit RCC_BDCR[15] in F1 series.However, in L1 series when HSE is selected as RTC clock source, additional bits are used in CR register, RCC_CR[RTCPRE], to select the division factor to be applied to HSE clock.MCO clock source–MCO pin (P A8)–Connectivity Line: HSI, HSE, PLL/2, SYSCLK, PLL2, PLL3 or XT1–Other product lines: HSI, HSE, PLL/2 or SYSCLK–MCO pin (P A8): SYSCLK, HSI, HSE, PLLCLK, MSI, LSE or LSIWith configurable prescaler, 1, 2, 4, 8 or 16 for each output.MCO configuration in L1 series is different from F1:–For MCO, the prescaler is configured through bitsRCC_CFGR[MCOPRE] and the selection of the clock to output through bits RCC_CFGR[MCOSEL]Table 5.RCC differences between STM32F1 and STM32L1 series (continued)RCC main features STM32F1 seriesSTM32L1 seriesCommentsPeripheral migration AN342220/52Doc ID 018976 Rev 2In addition to the differences described in the table above, the following additional adaptation steps may be needed for the migration:1.Performance versus V CORE ranges: The maximum system clock frequency and FLASH CORE and also on V DD . Thefollowing table gives the different clock source frequencies depending on the product voltage range.2.System clock configuration: when moving from F1 series to L1 series only a fewsettings need to be updated in the system clock configuration code; mainly the Flash settings (configure the right wait states for the system frequency, prefetchInternaloscillatormeasurement/ calibration–LSI connected to TIM5 CH4IC: can measure LSI w/respect to HSI/HSE clock–LSI connected to TIM10 CH1 IC: can measure LSI w/ respect to HSI/HSE clock–LSE connected to TIM10 CH1 IC: can measure LSE w/ respect to HSI/HSE clock –HSE connected to TIM11 CH1 IC: can measure HSE w/ respect to LSE/HSI clock–MSI connected to TIM11 CH1 IC: can measure MSI range w/ respect to HSI/HSE clockThere is no configuration to perform in RCC registers.Interrupt–CSS (linked to NMI IRQ)–LSIRDY , LSERDY , HSIRDY , HSERDY , PLLRDY ,PLL2RDY and PLL3RDY (linked to RCC global IRQ)–CSS (linked to IRQ)–LSIRDY , LSERDY , MSIRDY , HSIRDY ,HSERDY and PLLRDY (linked to RCC global IRQ)No change to SW configuration: interrupt enable, disable and pending bits clear are done in RCC_CIR register.Table 5.RCC differences between STM32F1 and STM32L1 series (continued)RCC main featuresSTM32F1 seriesSTM32L1 seriesCommentsTable 6.Performance versus V CORE rangesCPU performancePower performanceV CORE range Typical Value (V)Max frequency(MHz)V DD range1 WS0 WS High Low 1 1.83216 2.0 - 3.6Medium Medium 2 1.5168 1.65 - 3.6LowHigh31.242enable/disable, 64-bit access enable/disable...) or/and the PLL parametersconfiguration:a) If the HSE or HSI is used directly as system clock source, in this case only theFlash parameters should be modified.b) If PLL (clocked by HSE or HSI) is used as system clock source, in this case theFlash parameters and PLL configuration need to be updated.Table7 below provides an example of porting a system clock configuration from F1 to L1series:–STM32F105/7 Connectivity Line running at maximum performance: system clock at 72 MHz (PLL, clocked by the HSE, used as system clock source), Flash with 2wait states and Flash prefetch queue enabled.–L1 series running at maximum performance: system clock at 32 MHz (PLL,clocked by the HSE, used as system clock source), Flash with 1 wait state, Flashprefetch and 64-bit access enabled.As shown in the table below, only the Flash settings and PLL parameters (code in BoldItalic) need to be rewritten to run on L1 series. However, HSE, AHB prescaler and systemclock source configuration are left unchanged, and APB prescalers are adapted to themaximum APB frequency in the L1 series.Note:1The source code presented in the table below is intentionally simplified (time-out in wait loop removed) and is based on the assumption that the RCC and Flash registers are at theirreset values.2For STM32L1xx you can use the clock configuration tool,STM32L1xx_Clock_Configuration.xls, to generate a customized system_stm32l1xx.c filecontaining a system clock configuration routine, depending on your applicationrequirements. For more information, refer to AN3309 “Clock configuration tool forSTM32L1xx microcontrollers”Doc ID 018976 Rev 221/52Table 7.Example of migrating system clock configuration code from F1 to L1STM32F105/7 running at 72 MHz (PLL as clock source) with 2 wait states STM32L1xx running at 22 MHz (PLL as clock source)with 1 wait state/* Enable HSE ----------------------------*/ RCC->CR |= ((uint32_t)RCC_CR_HSEON);/* Wait till HSE is ready */while((RCC->CR & RCC_CR_HSERDY) == 0){}/* Flash configuration -------------------*//* Prefetch ON, Flash 2 wait states */FLASH->ACR |= FLASH_ACR_PRFTBE |FLASH_ACR_LATENCY_2;/* AHB and APB prescaler configuration --*//* HCLK = SYSCLK */RCC->CFGR |= RCC_CFGR_HPRE_DIV1;/* PCLK2 = HCLK */RCC->CFGR |= RCC_CFGR_PPRE2_DIV1;/* PCLK1 = HCLK */RCC->CFGR |= RCC_CFGR_PPRE1_DIV2;/* PLL configuration -------------------*//* PLL2CLK = (HSE / 5) * 8 = 40 MHzPREDIV1CLK = PLL2 / 5 = 8 MHz */RCC->CFGR2 |= RCC_CFGR2_PREDIV2_DIV5 |RCC_CFGR2_PLL2MUL8 |RCC_CFGR2_PREDIV1SRC_PLL2 |RCC_CFGR2_PREDIV1_DIV5;/* Enable PLL2 */RCC->CR |= RCC_CR_PLL2ON;/* Wait till PLL2 is ready */while((RCC->CR & RCC_CR_PLL2RDY) == 0){}/* PLLCLK = PREDIV1 * 9 = 72 MHz */RCC->CFGR |= RCC_CFGR_PLLXTPRE_PREDIV1 |RCC_CFGR_PLLSRC_PREDIV1 |RCC_CFGR_PLLMULL9;/* Enable the main PLL */RCC->CR |= RCC_CR_PLLON;/* Wait till the main PLL is ready */while((RCC->CR & RCC_CR_PLLRDY) == 0){}/* Main PLL used as system clock source --*/RCC->CFGR |= RCC_CFGR_SW_PLL;/* Wait till the main PLL is used as systemclock source */while ((RCC->CFGR & RCC_CFGR_SWS) !=RCC_CFGR_SWS_PLL){}/* Enable HSE ----------------------------*/RCC->CR |= ((uint32_t)RCC_CR_HSEON);/* Wait till HSE is ready */while((RCC->CR & RCC_CR_HSERDY) == 0){}/* Flash configuration -------------------*//* Flash prefetch and 64-bit access ON, Flash 1 wait state */FLASH->ACR |= FLASH_ACR_ACC64;FLASH->ACR |= FLASH_ACR_PRFTEN;FLASH->ACR |= FLASH_ACR_LATENCY;/* Power enable */RCC->APB1ENR |= RCC_APB1ENR_PWREN;/* Select the Voltage Range 1 (1.8 V) */PWR->CR = PWR_CR_VOS_0;/* Wait Until the Voltage Regulator is ready */while((PWR->CSR & PWR_CSR_VOSF) != RESET){}/* AHB and APB prescaler configuration --*//* HCLK = SYSCLK */RCC->CFGR |= RCC_CFGR_HPRE_DIV1;/* PCLK2 = HCLK / 1*/RCC->CFGR |= RCC_CFGR_PPRE2_DIV1;/* PCLK1 = HCLK / 1*/RCC->CFGR |= RCC_CFGR_PPRE1_DIV1;/* PLL configuration ---------------------*//* PLLCLK = (HSE * PLL_MUL) / PLL_DIV= (8 MHz * 12) / 3= 32MHz */RCC->CFGR = RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMUL12 | RCC_CFGR_PLLDIV3;/* Enable the main PLL */RCC->CR |= RCC_CR_PLLON;/* Wait till the main PLL is ready */while((RCC->CR & RCC_CR_PLLRDY) == 0){}/* Main PLL used as system clock source --*/RCC->CFGR |= RCC_CFGR_SW_PLL;/* Wait till the main PLL is used as systemclock source */while ((RCC->CFGR & RCC_CFGR_SWS ) !=RCC_CFGR_SWS_PLL);{}22/52Doc ID 018976 Rev 2。

STM32移植到GD32（以32的工程为模板简单三步完成移植）移植STM32工程到GD32平台是一项相对简单的任务，因为两者的硬件架构和内核类似。

在进行移植时，我们只需要对一些寄存器和外设的名称进行适当的更改即可完成移植。

以下是一个简单的三步骤指南，来帮助您完成STM32工程到GD32平台的移植。

第一步：更改寄存器和外设名称在STM32工程中，我们需要对寄存器和外设的名称进行更改，以适应GD32平台。

GD32平台使用了类似的寄存器和外设，但它们的名称可能有所不同。

您需要查阅GD32的参考手册，找到对应的寄存器和外设名称，并在STM32代码中进行相应的更改。

例如，在STM32中，GPIO外设的寄存器名称可能为GPIOA、GPIOB等，但在GD32中，GPIO外设的寄存器名称可能为GPIO0、GPIO1等。

您需要查找GD32的参考手册，找到正确的寄存器名称，并将其替换为相应的STM32代码中的寄存器名称。

第二步：调整时钟和中断配置在STM32和GD32平台上，时钟和中断配置可能略有不同。

在进行移植时，您需要检查和调整代码中的时钟和中断配置，以适应GD32平台的要求。

例如，在STM32中，我们可能使用RCC_PLLConfig函数来配置PLL，但在GD32中，我们可能需要使用零延迟锁相环（ZZPLL）来配置PLL。

您需要查找GD32的参考手册，找到正确的时钟配置函数，并将其替换为相应的STM32代码中的时钟配置函数。

同样地，在移植中，您还需要检查和调整代码中的中断配置，以确保它们与GD32平台兼容。

第三步：验证和调试完成以上两个步骤后，您可以编译和烧录移植后的代码到GD32开发板上进行验证和调试。

您可能需要对一些功能进行逐个测试，以确保它们在GD32平台上正常工作。

在调试过程中，您可能会遇到一些问题和错误。

这是正常现象，您需要逐一解决这些问题，直到移植后的代码在GD32平台上完全正常运行。

总结这是一个简单的三步指南，帮助您将STM32工程移植到GD32平台。

FreeRTOS移植到STM32F103步骤与注意事项转载2017年05月29日 11:16:361496原文地址：前言：由于之前听过太多人抱怨移植FreeRTOS到STM32有各种各样的问题，小灯经过一年多对FreeRTOS的研究并在公司产品中应用，多少有些心得，接下来就由小灯以最新版的FreeRTOS为例一步一步移植到STM32F103上，并提醒大家某些需要注意的事项。

本文档为非正式技术文档，故排版会有些凌乱，希望大家能提供宝贵意见以供小灯参考改进。

下面先以IAR移植为例，说明移植过程中的诸多注意事项，最后再以MDK移植时不再重复说明，所以还是建议大家先花些时间看IAR的移植过程，哪怕你不使用IAR，最好也注意下那一大堆注意事项！一、从官网下载最新版的FreeRTOS源码下面的网址是官方最新源码的下载地址：projects/freertos/files/latest/downloadsource=files目前官方提供的最新版本是， FreeRTOS源码在解压目录下的路径为FreeRTOS组织为了抢用户也是拼了命的，不信你打开Demo文件夹看看，里面提供了FreeRTOS在各种单片机上已经移植好的工程，如果建工程时遇到什么问题，可以参考下这些Demo。

不过小灯现在着重于自己动手移植FreeRTOS，考虑到原子哥@正点原子的用户比较多，绝大多数习惯了使用MDK来开发STM32，因此小灯分别以IAR和MDK两种使用比较广泛的开发环境来移植FreeRTOS。

说到IAR和MDK，不得不提的是小灯自从用了IAR之后就果断放弃了MDK，相信很多人有这个经历，哈哈！在开始移植FreeRTOS之前，先介绍下FreeRTOS的源码：FreeRTOS的源码比较少，源文件也远没有UCOS多，不过麻雀虽小五脏俱全，FreeRTOS 的短小精悍也是最令小灯着迷的，虽然缺少了很多组成部分，例如GUI、网络协议栈、文件系统等，不过这些统统都不是问题，因为完全可以移植第三方的组件！一不小心牛逼又吹大了，哈哈！回归正题，FreeRTOS的源码核心部分是和，其余的几个文件功能都是可选的，例如软件定时器、队列、协程等等，小灯就不介绍了，有兴趣的话可以到官网上看介绍。

基于STM32的μCOS_II移植实例（非常详细的移植过程）基于STM32的μC/OS_II移植实例目录第一章μC/OS_II移植准备工作 (2)1.1 硬件平台 (2)1.2 软件平台 (2)第二章μC/OS_II移植步骤 (3)2.1 文件结构 (3)2.2 μC/OS_II文件移植 (4)2.3 MDK中导入μC/OS_II文件 (4)2.4 需要修改的代码 (7)第三章μC/OS_II多任务以及任务间通信的实现 (9)3.1 μC/OS_II任务的创建 (9)3.2 事件标志组的创建 (11)第四章μC/OS_II移植测试 (13)4.1 μC/OS_II多任务的测试 (13)4.2 任务间通信的测试 (14)第一章μC/OS_II移植准备工作以武陵源车载系统终端为背景，探讨基于STM32的μC/OS嵌入式系统移植方法。

武陵源车载终端的基本功能是GPS数据的接收、站点和弯道的识别、超速报警、GPRS数据上传等。

本文重点是把μC/OS移植到程序中来，其次把各个基本功能模块化并划分为几个主任务，以便实现嵌入式系统的操作。

1.1 硬件平台硬件平台是ARM公司基于ARMv7架构的Cortex-M3系列处理器STM32F103T8。

此处理器执行Thumb-2指令的32位哈佛微体系结构和系统外设,包括Nested Vec-tored Interrupt Controller和Arbiter总线。

它整合了多种技术，减少内存的使用，极小的RISC内核有着低功耗和高性能的特点。

新的单线调试技术，避免使用多引脚进行JTAG调试，并全面支持RealView编译器和RealView调试产品。

GPS模块为Fastrax IT500，它是一款能适用于非常苛刻的应用场合，有着高性能的导航，即使在GPS卫星可见度较恶劣的环境下也能实现稳定定位。

IT500有着领先的冷启动灵敏度（-148dBm）和领先的导航灵敏度（-165dBm），定位率可以根据客户的要求设置到最高10Hz，非常适合高动态的应用。

STM32系列MCU不同型号的移植步骤解析移植STM32系列MCU的步骤可以分为以下几个方面：硬件准备、开发环境配置、移植BSP（板级支持包）、移植外设驱动、移植应用程序和调试验证。

一、硬件准备1.选择目标STM32MCU型号，并且获取相应的芯片手册和参考资料。

2.根据芯片手册，了解芯片的引脚定义、功能分配、时钟源和复位方式等。

3.准备开发板，确保与目标MCU兼容，并且可以通过JTAG/SWD等工具进行调试。

二、开发环境配置1. 安装相应版本的开发工具，例如 STM32CubeIDE、Keil MDK 或者IAR等。

2.根据MCU型号，选择相应的启动文件、链接脚本和编译器等配置参数。

3. 配置调试工具，如 ST-LINK、J-Link 或者 BlackMagicProbe等。

三、移植BSP（板级支持包）1.了解目标开发板的硬件资源，包括GPIO、串口、定时器等外设的定义和使用方式。

2.根据目标MCU和开发板的硬件资源，编写对应的BSP配置文件，包括复位、时钟初始化、外设配置等。

3.配置并编译BSP驱动程序，确保能够正确初始化和控制硬件资源。

四、移植外设驱动1. 根据需要，选择对应的外设驱动库，例如 STM32Cube HAL 或者自行编写驱动程序。

2.根据目标MCU的硬件资源和外设的技术要求，编写对应的外设驱动程序。

3.配置并编译外设驱动程序，确保能够正确初始化和控制外设。

五、移植应用程序1.根据具体应用需求，编写应用程序的主代码，包括初始化、逻辑处理和外设控制等。

2.根据硬件资源和外设驱动的要求，调用BSP和外设驱动函数来初始化和控制相关的硬件资源和外设。

3.配置并编译应用程序代码，生成可执行文件。

六、调试验证2.使用调试工具来烧录应用程序代码到目标MCU，并且启动调试模式。

3.通过调试工具，观察应用程序的执行情况、外设的状态和数据传输等，进行验证和调试。

在移植的过程中，需要仔细阅读芯片手册、参考资料和开发工具的文档，根据具体情况做出相应的配置和调整。

STM32 无操作系统移植STemWIN(IAR编译器)本教程针对没有FSMC的单片机移植讲解题外话：很多人有疑问，关于UCGUI和STemwin以及emwin的区别，这里大致说一下，一个关键词：SEGGER。

SEGGER是德国的一个知名公司，而emwin(embed win)就是SEGGER公司的一款产品，为此SEGGER公司为UCOS定制的叫做UCGUI。

而ST(意法半导体)公司也定制了自己的GUI叫做STemwin。

其实都是SEGGER公司的产品。

(如果你是ST的MCU采用STemwin是不收费的哦)。

废话：1、要移植STemwin必须要有STemwin这个库，想要获取的方法很简单，ST官方网站(自己有兴趣可以找找)、或者Keil安装目录下面也有，路径是：Keil/ARM/SEGGER/emwin就是了，不过keil下面的版本不是最新的。

我的百度网盘分享了可以下载，/s/13VGi2、需要有开发板一块液晶屏(当然也可以用它自带的仿真工具在电脑进行仿真，好像还需要VC之类的软件，笔者没有深究)，液晶屏的尺寸没有限制。

硬件的工作准备好。

笔者液晶屏采用240*320。

3、完整的液晶底层驱动，它包括(液晶初始化函数、设置x、y坐标画点函数、读取像素x、Y坐标的颜色的函数、设置X、y矩形框进行填充函数)就这些。

废话真多，下面进入正题1、KEIL或者IAR建立完整的stm32的工程，笔者采用IAR，如下图：2、打开下载的STemwin你会看到这样的文件，说明：Config这个是液晶配置文件，OS是带操作系统的(笔者没有移植OS)，software文件夹下面试一些上位机软件，在使用STemwin的过程中有用，inc是库文件的头文件，DOC这个文件是一些说明文档。

3、打开lib问价夹，发现好多库文件，这就要根据你自己的实际情况选择了，笔者采用IAR而STM32是属于M3内核所以选择了STemwin522_CM3_IAR，如下：4、将这些文件添加进你的工程，inc文件夹下的全部添加，Config只需要添加一些，lib只需要添加一个，demo也添加进来，添加好的文件如下：添加了哪些地方有头文件需要包含以下，这个不用我多说，5、添加好之后，自己编译一下，有错误就更改，直至没有错误为止，6、更改配置文件，打开GUIConf.c文件配置，如下图：7、配置GUIConf.h文件，这里面试一些开关，选择emwin支持的功能，可以全部打开，如下：8配置这个文件，这个文件是关键文件了配置如下：尺寸配置：void LCD_X_Config(void)这个函数配置如下，说明，这里笔者创建自己的LCD型号(如上图)，如果不是，你可以选择LCD驱动型号，这个要看STemwin的数据手册了，并且参数需要对应修改，如下图(看注释)：如果选择了自己的驱动就需要把四个接口函数填上，(笔者没有选择这种方式)9、初始化函数添加进去，(添加你自己的TFT初始化函数)如下图：因为笔者没有采用选择LCD驱动的方式，所以需要修改下面的函数了，如果选择那种方式就不用了。

海思芯片里面移植算法
海思芯片的算法移植过程主要包括以下步骤：
1. 准备算法代码：首先，需要确保拥有算法的源代码，并且该代码是为海思芯片平台优化的。

2. 配置开发环境：在开始移植之前，需要配置适合海思芯片的开发环境。

这包括安装必要的工具链、编译器和调试器等。

3. 算法预处理：在将算法代码移植到海思芯片之前，可能需要进行一些预处理工作。

这可能包括修改算法代码以适应硬件平台，优化算法性能等。

4. 移植算法代码：将预处理后的算法代码移植到海思芯片上。

这可能包括将代码编译成可在海思芯片上运行的二进制文件，以及将该文件部署到目标硬件上。

5. 测试和验证：在算法代码成功移植到海思芯片之后，需要进行测试和验证以确保其正确性和性能。

这可能包括运行一系列测试用例来检查算法的输出是否正确，以及测量算法在海思芯片上的运行时间等。

6. 优化和调整：根据测试和验证的结果，可能需要对算法代码进行进一步的优化和调整，以提高其在海思芯片上的性能。

总之，海思芯片的算法移植过程需要一定的技术知识和经验，以确保移植的顺利进行并获得最佳的性能结果。

开源LittleVGL移植到stm32f103vet6中在st7789的1.14⼨屏幕上显。

最近发现这个开源的GUI特别有意思，⽹上的资料还⽐较少，在这⾥记录⼀下我的整个开发过程⾸先使⽤的IC是f103vet6屏幕是淘宝的1.14⼨LCD，分辨率135*240第⼀步先去lvgl的github上⾯下载它的源码还有例程源码我这⾥使⽤的版本是lvgl的7.6.0，刚刚上去看居然发现⼀个⼩时前更新了v7.6.1，啊这lvgl源码：lvgl演⽰例程源码：下载好了我们先放起来，等会移植的时候要⽤的上第⼆步我们现在需要⼀个显⽰LCD的例程，这⾥我直接⽤淘宝卖家提供的显⽰代码了还挺多的啊，这⾥我就选中的的STM32F103ZET6_Software_SPI的了因为我⽤的是vet6，这款的FLASH好像是相同⼤⼩的，直接在keil⾥⾯改芯⽚都省的移植了那么我们现在有这些东西了，把第⼀个⼯程的名字改成stm32_test吧，现在这名字也太长了我们打开stm32_test的⼯程先看⼀下，就是⼀个测试LCD功能的代码，测试了⼀下GUI.c的画点画圆啥的LCD的接线⽅法最顶上的注释也给出来了，省的我们找LCD的IO⼝去⼀个个翻了，好评！下⾯那个触摸屏接线的注释我们直接忽略吧，1.14⼨的LCD不配拥有触摸编译测试可以正常使⽤，这⾥就不贴测试图了直接进⼊下⼀步我们在stm32_test⼯程的⾥⾯新建两个⽂件夹，LittleVGL和LittleVGL⽤来放lvgl从github上⾯下载来的源码吧，LittleVGL_APP⽤来放⼀下我们⾃⼰写的GUI界⾯现在这两个⽂件夹是空的，下⾯来说说在⾥⾯放啥东西我们先解压⼀下刚刚在github下载的lvgl的源码我们得到了⼀个这个点进来看看⾥⾯有啥东西看不懂不管了，继续下⼀步操作那我们就把这个解压出来的lvgl-master复制放在我们⼯程刚刚新建的LittleVGL⾥⾯给它改⼀下名字吧，就叫lvgl简单⼀点放好了就从它⾥⾯拿出点东西来⽤，我们进⼊lvgl中找到lv_conf_template.h哟，刚进来就看到你了，把它复制带出去，把名字改成lv_conf.h，这⾥⾯代码等下再说，就先放在和lvgl同级吧我们在这个⽬录下在新建⼀个⽂件夹吧，就叫lvgl_driver这个lvgl_driver肚⼦⾥⾯空空的，我们在lvgl⾥⾯再复制点东西出来放进去第⼀步先进去lvgl再进去⾥⾯的examples⾥⾯哟，这⾥居然还有⼀个arduino的代码，⽆视他我们继续进去porting找到了我们需要的代码这⾥⾯说⼀下，我红框框起来的两个是lvgl的显⽰代码，下⾯那个lv_port_indev_template.c和.h是触摸的代码因为我们这⾥⽐较卑微没有触摸，我就只复制了我框起来的两个，中间那个fs啥的不知道，也没有时间去看带⾛把这两放在lvgl_driver⾥⾯吧，让他们重新做.c和.h⽂件，重新做⽂件⾸先第⼀步把名字改了先名字改好了上⾯全部⼯作准备好了，我们开始⼲正事了，准备移植⼿术再keil5⼯程⾥⾯把他们的头⽂件先包含进来先就是上⾯图⾥⾯的三个路径，我看lvgl源码⾥⾯找头⽂件好多都是通过这⾥去找的keil⼯程⾥⾯也加⼊⼏个⽂件夹吧，整理起来好看⼀点那么我们现在也加⼊⼀下.c⽂件进来LittleVGL_Driver就拉⼀个就⾏了接下来LittleVGL拉的才多需要把lvgl / src /路径⾥⾯全部⽂件夹⾥⾯的.c⽂件导⼊进去出了⼀个lv_GPU⽂件⾥⾯的不⽤，其他都导⼊进去还挺多东西的，最后都点OK确认吧这个LittleVGL_APP就不放东西了吧，这个是放我们⾃⼰写的界⾯，现在也没有东西放别急着编译，现在编译肯定⼏千个错误，我们先选型⼀个芯⽚再写BUG对了，这个C99 Mode的钩⼀定要打上，lvgl⽤到了好了，那么现在就编译看看吧，不忍直视好了，我们找到lv_conf.h来修改⼀些参数，就是我们从lvgl搬出来那个下⾯直接说改那⾏不做太多解释了好了，下⾯没啥东西需要修改了下⾯我们修改⼀下lvgl显⽰的代码我们⾛到141的函数disp_flush，⼀路下来错误还挺多的这个代码⾥⾯我们添加⼀个画点函数，再我们的GUI.c⾥⾯有，看英⽂也能明⽩它缺少⼀个画点的显⽰当然也可以把他们全部替换成画矩形的代码，但是下⾯那个lv_disp_flush_ready的那个代码不要动它再这代码⾥还有⼀个问题，我们选择⼀种缓存的⽅式，测试的话那就选最简单的吧把另外两个注释掉我们再打开"lv_port_disp.h"⾥⾯修改⼀些东西"lv_port_disp.h"⾥⾯声明⼀下lv_port_disp_init函数那么现在再编译⼀次居然还有30个错误，看这些错误都是同⼀个问题，我去看看怎么回事嗷就是没有定义u16，可以把u16换成uint16_t，不过为了省事这⾥直接添加⼀个sys.h再次编译⼀下，成功通过不过还没结束我们这⾥要使⽤lvgl还需要给它提供⼀个1ms的⼼跳节拍可以使⽤Systick或者定时器来提供我看这⾥的⼯程样式好像是正点原⼦的，那么我们直接从正点原⼦的定时器例程⾥⾯弄⼀个TIM过来这⾥就不写啥移植TIM过程了，直接拉过来就是⽤再代码中加⼊.c，在魔术棒⾥⾯加⼊它的头⽂件路径还要在这⾥加⼊躲在tim.c的TIM3中断⾥⾯添加⼀个lv_tick_inc(1)；这⾥中断在主函数配置成了1ms等会在看看现在我们先编译⼀下还要5个警告啊，我们不⽤管他了，随便它警告吧继续下⼀步在主函数中添加⼀些代码⾸先加⼊头⽂件main中添加初始化刚刚发现⼀个有意思的情况：我在main并没有配置TIM3为1ms，也没有调⽤TIM的头⽂件，难道其实不⽤⼼跳节拍也能⽤？这个之后我研究研究，可能是我配置了没有看到？在下⾯的while循环⾥⾯加⼀个lvgl的句柄我们在while循环之前就可以放⼊我们的界⾯了，先测试⼀个⼿写的显⽰按键吧编译通过写⼊stm32⾥⾯试试写⼊的过程是⽐⼀般的例程时间久⼀些我们看看屏幕显⽰效果我裂开了，屏幕⽩光太亮了，拍照不清晰，之后调整PWM调整背光我在重新拍⼀下不知道⼩伙伴能不能看清中间有个蓝⾊的BUTTON好了过程就写到这⾥，之后抽时间把代码链接放出来下⼀个随笔也是接这篇lvgl的内容，主要是说明⼀下如何使⽤lvgl提供的demo例程就到这⾥吧。

优秀方案推荐｜华为LiteOS物联网操作系统在个人电脑时代，微软的Windows是电脑操作系统的霸主。

在智能手机时代，谷歌Android和苹果iOS抓住机会，成为手机操作系统市场的双雄。

物联网时代已经到来，Huawei LiteOS通过开源，有意与业界伙伴一起努力打造IoT领域的“Android”，做大物联网产业生态。

随着人与人的连接向人与物、物与物的连接转移，物联网市场充满了想象空间。

未来，成百上千亿的物联网终端将会联网，它们需要跑应用，做简单的计算，与其他物、边缘网关和云进行通信，而且通常运行在性能不高的MCU（微控制器）芯片上，使用电池供电。

不同行业应用中的物联网终端类型多种多样，使用异构的硬件和不同类型的连接协议。

如何满足海量终端的这些多样化需求，是物联网时代给操作系统带来的新机遇和挑战。

2015年华为发布“1+2+1”的物联网战略，Huawei LiteOS作为战略的重要组成部分，是支持物联网终端产业快速发展、使能终端设备智能化的软件开发平台。

Huawei LiteOS发布以来，支持了很多优秀产品的上市，包括华为高端智能手机、可穿戴设备、物联网芯片等，设备使用量已经超过5000万。

同时，Huawei LiteOS结合自身优秀实践经验，积极与第三方芯片、终端厂家合作，为产业发展贡献力量，共同迎接千亿连接时代的到来。

Huawei LiteOS提供统一开放的API，可广泛应用于智能家居、可穿戴设备、车联网、制造业等领域，以轻量级、低功耗、快速启动、互联互通、安全稳定等关键能力，通过开源、开放的方式，为开发者提供一站式服务，有效降低开发门槛，缩短开发周期。

差异化的竞争力物联网操作系统的设计相对于电脑、手机操作系统有着特殊的需求，包括需要有模块化、可升级的架构，内核可伸缩，功耗低，支持丰富的连接协议，支持各种硬件和芯片解决方案，具备端侧的安全能力等。

图1 Huawei LiteOS架构图针对物联网操作系统的设计挑战，Huawei LiteOS为物联网终端厂商提供一站式的完整软件开发平台，包括模块化的中间件框架，可以有效降低开发门槛，缩短产品开发周期。

FreeRTOS 在STM32上的移植V1.0 - 伟研科技FreeRTOS作为开源的轻量级实时性操作系统，不仅实现了基本的实时调度、信号量、队列和存储管理，而且在商业应用上不需要授权费。

FreeRTOS的实现主要由list.c、queue.c、croutine.c和tasks.c 4个文件组成。

list.c 是一个链表的实现，主要供给内核调度器使用；queue.c 是一个队列的实现，支持中断环境和信号量控制；croutine.c 和task.c是两种任务的组织实现。

对于croutine，各任务共享同一个堆栈，使RAM的需求进一步缩小，但也正因如此，他的使用受到相对严格的限制。

而task则是传统的实现，各任务使用各自的堆栈，支持完全的抢占式调度。

FreeRTOS的主要功能可以归结为以下几点：1) 优先级调度、相同优先级任务的轮转调度，同时可设成可剥夺内核或不可剥夺内核2) 任务可选择是否共享堆栈(co-routines & tasks)，并且没有任务数限制3) 消息队列，二值信号量，计数信号量，递归互斥体4) 时间管理5) 内存管理与UC/OSII一样，FreeRTOS在STM32的移植大致由3个文件实现，一个.h文件定义编译器相关的数据类型和中断处理的宏定义；一个.c文件实现任务的堆栈初始化、系统心跳的管理和任务切换的请求；一个.s文件实现具体的任务切换。

在本次移植中，使用的编译软件为IAR EWARM5.2。

一、各文件关键部分的实现：1、PORTMACRO.H 宏定义部分1）定义编译器相关的各种数据类型#define portCHAR char#define portFLOAT float#define portDOUBLE double#define portLONG long#define portSHORT short#define portSTACK_TYPE unsigned portLONG#define portBASE_TYPE long2）架构相关的定义Cortex-M3的堆栈增长方向为高地址向低地址增长#define portSTACK_GROWTH ( -1 )每毫秒的心跳次数#define portTICK_RATE_MS ( ( portTickType ) 1000 /configTICK_RATE_HZ )访问SRAM的字节对齐#define portBYTE_ALIGNMENT 83）定义用户主动引起内核调度的2个函数强制上下文切换，用在任务环境中调用#define portYIELD() vPortYieldFromISR()强制上下文切换，用在中断处理环境中调用#define portEND_SWITCHING_ISR( xSwitchRequired ) if( xSwitchRequired ) vPortYieldFromISR()4）定义临界区的管理函数中断允许和关闭#define portDISABLE_INTERRUPTS() vPortSetInterruptMask()#define portENABLE_INTERRUPTS() vPortClearInterruptMask()临界区进入和退出#define portENTER_CRITICAL() vPortEnterCritical() #define portEXIT_CRITICAL() vPortExitCritical()用于在中断环境的中断允许和关闭#define portSET_INTERRUPT_MASK_FROM_ISR()0;vPortSetInterruptMask()#define portCLEAR_INTERRUPT_MASK_FROM_ISR(x)vPortClearInterruptMask();(void)x2、PORT.C C接口部分1）堆栈初始化portSTACK_TYPE*pxPortInitialiseStack( portSTACK_TYPE *pxTopOfStack, pdTASK_CODE pxCode, void *pvParameters ){*pxTopOfStack = portINITIAL_XPSR; /* 程序状态寄存器*/pxTopOfStack--;*pxTopOfStack = ( portSTACK_TYPE ) pxCode; /* 任务的入口点*/pxTopOfStack--;*pxTopOfStack = 0; /* LR */pxTopOfStack -= 5; /* R12, R3, R2 and R1. */*pxTopOfStack = ( portSTACK_TYPE ) pvParameters; /* 任务的参数*/pxTopOfStack -= 8; /* R11, R10, R9, R8, R7, R6, R5 and R4. */return pxTopOfStack;}2）启动任务调度portBASE_TYPE xPortStartScheduler( void ){让任务切换中断和心跳中断位于最低的优先级，使更高优先级可以抢占mcu*(portNVIC_SYSPRI2) |= portNVIC_PENDSV_PRI;*(portNVIC_SYSPRI2) |= portNVIC_SYSTICK_PRI;设置并启动系统的心跳时钟prvSetupTimerInterrupt();初始化临界区的嵌套的个数uxCriticalNesting = 0;启动第一个任务vPortStartFirstTask();执行到vPortStartFirstTask函数，内核已经开始正常的调度return 0;}3）主动释放mcu使用权void vPortYieldFromISR( void ){触发PendSV系统服务中断，中断到来时由汇编函数xPortPendSVHandler()处理*(portNVIC_INT_CTRL) = portNVIC_PENDSVSET;}进入临界区时，首先关闭中断；当退出所以嵌套的临界区后再使能中断void vPortEnterCritical( void ){portDISABLE_INTERRUPTS();uxCriticalNesting++;}void vPortExitCritical( void ){uxCriticalNesting--;if( uxCriticalNesting == 0 ){portENABLE_INTERRUPTS();}}4）心跳时钟处理函数void xPortSysTickHandler( void ){unsigned portLONG ulDummy;如果是抢占式调度，首先看一下有没有需要调度的任务#if configUSE_PREEMPTION == 1*(portNVIC_INT_CTRL) = portNVIC_PENDSVSET;#endifulDummy = portSET_INTERRUPT_MASK_FROM_ISR(); { 通过task.c的心跳处理函数vTaskIncrementTick()，进行时钟计数和延时任务的处理vTaskIncrementTick();}portCLEAR_INTERRUPT_MASK_FROM_ISR( ulDummy ); }3、PORTASM.S 汇编处理部分1）请求切换任务xPortPendSVHandler:保存当前任务的上下文到其任务控制块mrs r0, pspldr r3, =pxCurrentTCB 获取当前任务的任务控制块指针ldr r2, [r3]stmdb r0!, {r4-r11} 保存R4-R11到该任务的堆栈str r0, [r2] 将最后的堆栈指针保存到任务控制块的pxTopOfStackstmdb sp!, {r3, r14}关闭中断mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY msr basepri, r0切换任务的上下文，pxCurrentTCB已指向新的任务bl vTaskSwitchContextmov r0, #0msr basepri, r0ldmia sp!, {r3, r14}恢复新任务的上下文到各寄存器ldr r1, [r3]ldr r0, [r1] /* The first item in pxCurrentTCB is the task top of stack. */ldmia r0!, {r4-r11} /* Pop the registers. */msr psp, r0bx r14任务切换的示意图如下：2.）中断允许和关闭的实现，通过BASEPRI屏蔽相应优先级的中断源vPortSetInterruptMask:push { r0 }mov R0,#configMAX_SYSCALL_INTERRUPT_PRIORITYmsr BASEPRI, R0pop { R0 }bx r14vPortClearInterruptMask:PUSH { r0 }MOV R0, #0MSR BASEPRI, R0POP { R0 }bx r143）直接切换任务，用于vPortStartFirstTask第一次启动任务时初始化堆栈和各寄存器vPortSVCHandler;ldr r3, =pxCurrentTCBldr r1, [r3]ldr r0, [r1]ldmia r0!, {r4-r11}msr psp, r0mov r0, #0msr basepri, r0orr r14, r14, #13bx r144）启动第一个任务的汇编实现vPortStartFirstTask通过中断向量表的定位堆栈的地址ldr r0, =0xE000ED08 向量表偏移量寄存器(VTOR)ldr r0, [r0]ldr r0, [r0]msr msp, r0 将堆栈地址保存到主堆栈指针msp中触发SVC软中断，由vPortSVCHandler()完成第一个任务的具体切换工作svc 0FreeRTOS内核调度器启动的流程如下：以上3个文件实现了FreeRTOS内核调度所需的底层接口，相关代码十分精简。