Buck型拓扑变换器
Buck型变换器的拓扑构造如图所示，Buck型变换器也称降压型电源拓扑。在开关管S导通时，二极管VD负极电压高于正极反偏截止，此时电流经由电感L向电容和负载供电，同时电感L中储存了能量。在开关管S关断时，电感L中储存的能量不能立即开释，产生的感应电流利过负载、二极管VD形成续流利路，连续给负载供电。该二极管也因此称为续流二极管。在降压型电源拓扑中，当驱动开关管的PWM占空比为D时，输出与输入知足的关系为:
Boost型拓扑变换器
Boost变换器基本拓扑构造如图所示。Boost变换器也称为升压型电源拓扑。当开关管S导通时，二极管正极电压低于负极电压反偏关断，电源和电感形成通路，电感L流过电流储存能量，此时负载由电容供应能量。当开关管S断开时，此时二极管正引导通，电源和电感L储存的能量同时向电容、负载供电。在升压型变换器中，当驱动开关管的掌握旗子暗记占空比为D时，输出与输入知足关系为:
Buck-Boost型拓扑变换器
Buck-Boost变换器基本拓扑构造如图所示，Buck-Boost变换器也称为升降压型开关电源拓扑，。在开关管S导通时，二极管负极电压高于正极电压反偏截止，电源和电感形成通路，电感L储存能量。当开关管S关断时，二极管正引导通，电感电流不会立即开释与负载、二极管形成续流利路。但是，此时负载电压与输入电压极性相反。在Buck-Boost变换器中，当驱动开关管的掌握旗子暗记的占空比为D时，输出与输入知足的关系为:
2）隔离式DC-DC拓扑先容
正激式拓扑变换器
正激式变换器基本拓扑构造如图所示。将变压器放在降压型变换器的开关管和二极管之间就可以得到正激式的拓扑构造，变压器的原边和副边的隔离就使输入和输出隔离。正激时变换器因电路设计大略、经济便捷，在50W~400W的场合运用很广。但是由于变压器上所有线圈电流在开关管关断的时候，全部断开，为了担保变压器的磁芯不发生磁饱和征象，附加绕组W3的加入起到磁芯复位的功能。
当开关管S导通时，电源电压加到低级绕组W1上，根据N1、N2同名真个关系，此时低级绕组能量通报到次级绕组W2，VD1导通，电感L，电容C共同得到低级输入的能量。当开关管S关断时，W1中剩余能量通过赞助绕组W3返回到电源的输入，VD1截止，次级的电感L、 二极管VD2、负载形成续流利路。
在正激式变换器中特殊把稳开关S关断到下个周期开关S导通的韶光内要使磁芯剩余的能量得到开释，否则在后续的韶光内，该剩余的能量值不断的增加，末了达到磁芯所能承受的极限值而饱和。
反激式拓扑变换器
反激式变换器基本拓扑构造如图所示。在Buck-Boost型变换器中将高频变压器放在电感的位置就有了反激式的电路。反激式变换器设计非常随意马虎，价格低廉，常常用在多路输出的小功率开关电源场合。
当开关管S导通时，电源电压加在低级绕组W1两端，根据N1、N2同名真个关系，绕组W2的高电位不才端，二极管VD1此时不导通。当开关S关断时， 绕组W2的高电位在上端，二极管VD1正引导通，负载得到能量。
推挽式拓扑变换器
推挽式变换器其拓扑构造如图所示。原边开关管S1、S2交替导通，变压器磁芯中的能量能够正常的储存和开释，从而将能量从原边向副边通报。
当开关S1导通，S2关断时，副边绕组二极管VD1导通，负载得到能量。当S2导通，S1关断时，副边二级管VD2导通，负载仍能得到能量。当开关管S1，S2都关断时，电感L通过二极管VD1、VD2和负载形成通路，根据并联分流，负载电流只有一半通过每个二极管，但此时开关管承受的电压均为。，所以为了担保开关管的电压应力不会过大，推挽式变换器用在低压大电流的场合具有一定的上风。
半桥拓扑变换器
半桥变换器其拓扑构造如图所示。一条桥臂由两个电容组成，另一条桥臂由两个功率开关管组成。在电路正常事情时，原边绕组在掌握旗子暗记全体周期均有电流，磁芯的利用率得到提高。以是半桥变换器用在高电压、大功率的情形下比较有上风。
电容C1和C2容值、型号同等，则每个电容上的电压为。当开关S1导通S2关断时，二极管VD1导通，VD2截止，此时N21绕组向负载通报能量。当开关S1关断，S2导通时，二极管VD2导通，VD截止，此时N22绕组能向负载通报能量，即副边绕组N21和N22交替开释能量。
全桥拓扑变换器
全桥变换器其拓扑构造如图所示。四个开关管组成H桥电路，变压器原变绕组接在桥式电路的负载位置。当开关S1和S4导通，S2和S3关断时，低级绕组的高电位在上端。当开关S2和S3导通，S1和S4关断时，低级绕组的高电位不才端。因此，在一个周期内初绕组流过的电流方向相反，变压器不存在磁芯饱和问题，这也使得全桥变换器的效率和功率密度可以做的很高。全桥变换器的次级绕组带有一个中央抽头，输出采取全波整流的办法，因此适宜运用在大功率的条件下。
各种型拓扑比较如下表所示：
隔离式DC-DC拓扑电路的比较
查看原文：https://www.dianyuan.com/eestar/article-8316.html
MCUXpresso IDE下添加新路径下源文件进工程编译的方法
大家好，我是痞子衡，是正经搞技能的痞子。本日痞子衡给大家先容的是MCUXpresso IDE下添加新路径下源文件进工程编译的方法。
接着上篇文章 《MCUXpresso IDE下SDK工程导入与workspace管理机制》 接着聊，痞子衡说过不建议从零开始创建新工程项目，最好便是导入一个SDK里的现成项目（只管即便跟你终极需求附近，紧张是须要的SDK根本驱动都要包含），然后在这个项目根本上修正本钱身想要的终极工程。
如果你是一个习气于IAR或者MDK这种非Eclipse式集成开拓环境的用户，你可能会对MCUXpresso IDE下管理工程（紧张是在工程里增加源文件）的办法感到不适应。本文痞子衡将为你指明MCUXpresso IDE下增加源文件让你不适应的地方。
一、准备测试环境
上篇文章 《MCUXpresso IDE下SDK工程导入与workspace管理机制》 里我们导入了RT500的一个hello world项目进workspace空间，让我们将这个项目拷贝到如下自定义的路径，然后在MCUXpresso IDE下利用 Import project(s) from file system 办法并且不勾选 Copy projects into workspace 选项去打开自定义路径下的hello world工程。
为大略起见，我们再创建三组源文件：sw_delay1.c/h、sw_delay2.c/.h、sw_delay3.c/.h，我们会用这三组源文件来测试三种不同路径类型下添加源文件进工程的情形。
////////////////sw_delayx.c////////////////#include "sw_delayx.h"void sw_delayx(uint32_t n){ while (n != 0U) { n--; }}////////////////sw_delayx.h////////////////#include <stdint.h>#if defined(__cplusplus)extern "C" {#endifvoid sw_delayx(uint32_t n);#if defined(__cplusplus)}#endif
二、已有路径下添加源文件进工程
第一种测试情形最大略，我们直接把sw_delay1.c/h文件放到\mcux_test\evkmimxrt595_hello_world\source\路径下，跟主函数源文件hello_world.c放在一起。当我们将新源文件放到已有路径下时，在MCUXpresso IDE工程里新文件就急速显示在了界面左上角的workspace里（可以理解为直接被添加进工程了），根本不用你手动添加（这是跟IAR/MDK比较第一个不同的地方，也是你可能不适应的地方），这时候我们可以在主函数文件里直接引用和调用sw_delay1.c/h里的内容，不须要再额外做任何工程设置。
自动刷新工程路径下源文件进工程是Eclipse型IDE的特色，这个特色实在挺好，只有一种情形下不太方便，那便是多个不同源文件中均有相同函数定义（可能是测试目的，或者刻意保留不同版本函数实现），这种情形下在工程编译时会报错，须要在IDE里主动右击你不想添加进工程的源文件，在Properties框里勾选上 Exclude resource from build。
三、新路径下添加源文件进工程
3.1 在工程文件所在路径下
现在我们换一种情形，还是在当前工程路径\mcux_test\evkmimxrt595_hello_world下，但是新建一个名为sw_delay2的文件夹，并且将sw_delay2.c/h文件放到\mcux_test\evkmimxrt595_hello_world\sw_delay2\路径下。由于有了新路径，此时还须要在工程Properties选项的MCU C Compiler / Includes里（最好在MCU Assembler / General 里也同样设置）将该新路径添加进去。
此时新文件夹sw_delay2及个中源文件彷佛同样被自动更新到了工程workspace中，我们试试在主函数源文件中调用sw_delay2()，并编译工程。很遗憾，工程编译报错，提示undefined reference to `sw_delay2'，便是找不到sw_delay2()函数，这是为什么？
这里要先容第二个让你不适应的地方，那便是工程文件所在路径下的新建文件夹看起来被自动更新显示到工程workspace中了，但实在个中源文件并没有真正被添加进工程，还须要你手动做一次路径添加，在工程Properties选项的C/C++ General的Paths and Symbols下做如下操作。做完之后，你可以在workspace里看到此时sw_delay2文件夹被提到了Debug上面显示（在SDK工程里，Debug和doc文件夹一样平常显示在最下面，这两个并没有被真正添加进工程源文件路径，凡是显示在它们后面的文件夹都是没有被真正加入工程的），现在工程可以正常编译了。
3.2 非工程文件所在路径下
末了先容一种最繁芜的情形，这次不在工程路径\mcux_test\evkmimxrt595_hello_world下做文章，我们在\mcux_test\路径下新建一个名为sw_delay3的文件夹，并且将sw_delay3.c/h文件放到\mcux_test\sw_delay3\路径下。由于这个新路径跟工程路径不干系，因此工程workspace没有自动显示它，此时当然须要我们手动来添加这个文件夹进工程。右击工程选择 New / Folder，利用Folder选项里Advanced下面的 Link to alternate location 功能将sw_delay3文件夹及其源文件添加进工程。
此时工程workspace中已经显示了sw_delay3文件夹，但是显示在最下面（Debug和doc之后），这时候我们可以当sw_delay3文件夹刚刚被放到\mcux_test\evkmimxrt595_hello_world\下面一样，按3.1节里的方法走一遍，MCU C Compiler / Includes和C/C++ General - Paths and Symbols下都分别再设置一下。
这里有第三个让你不适应的地方，非工程文件所在路径下的源文件夹在被逼迫链到工程里时，其Include路径直接转变成了当前工程路径/${ProjName}/下，并不须要像IAR/MDK那样利用 ../ 去回退探求详细的相对路径。
至此，MCUXpresso IDE下添加新路径下源文件进工程编译的方法痞子衡便先容完毕了，掌声在哪里~~~
查看原文：https://www.dianyuan.com/eestar/article-8340.html
OTFAD加密启动失落败？先去检讨系统时钟配置
大家好，我是痞子衡，是正经搞技能的痞子。本日痞子衡给大家分享的是系统时钟配置不当会导致i.MXRT1xxx系列下OTFAD加密启动失落败问题。
我们知道，i.MXRT1xxx家族早期型号（RT1050/RT0160/RT1020）的硬件解密外设名字叫BEE，这个外设紧张是合营FlexSPI外设去实现外接串行NOR Flash在线解密XIP实行用的。而到了最近的i.MXRT1xxx新型号（RT1010/RT1170）上，BEE外设被更换成了OTFAD外设，功能不变，解密效率得到了很大提升，但客户在使能OTFAD加密启动时常常碰着App无法正常运行问题，这实在跟OTFAD自身的一个时钟小限定有关（这个限定在BEE上不存在），本日痞子衡就来好好聊一聊OTFAD的这个小限定：
一、问题描述
我们以i.MXRT1010为例，从恩智浦官网下载一个SDK包（痞子衡下的是v2.9.1），随便选择个中一个例程，就以最大略的 \SDK\boards\evkmimxrt1010\demo_apps\led_blinky 为例吧。编译这个 led_blinky 工程（选择 flexspi_nor_debug build，即XIP工程），得到可实行文件（实际bin文件大小为10KB旁边），利用 NXP-MCUBootUtility 工具将可实行文件(led_blinky.out)下载进MIMXRT1010-EVK开拓板中（下载时启动模式为2'b01，启动时切换到2'b10），可以看到板载绿色LED小灯（D25）会闪，例程是可以正常事情的。
现在让我们考试测验使能OTFAD加密，回到芯片下载模式依然借助 NXP-MCUBootUtility 工具，将工具 Secure boot type 选项切换为 OTFAD Encrypted Image Boot，其他设置均默认（此时加密范围是 0x60001000 - 0x60001fff，仅加密IVT等启动头，不含app），再次下载可实行文件(led_blinky.out)，换到芯片启动模式复位板子，例程依旧是正常事情的，看起来OTFAD加密启动彷佛没有问题。
让我们再进一步，将加密范围设置为0x60002000 - 0x60004fff，这时加密区域覆盖到了全体app，重新按上述流程操作一遍，创造例程没能正常事情，这时候OTFAD加密启动出了问题，难道app区域不能被加密？那OTFAD加密还有啥意义？
app区域当然可以被加密，随着痞子衡再做一次实验，在 led_blinky.c 文件的 main() 函数中，我们将时钟配置函数 BOARD_BootClockRUN() 直接注释掉或者在链接文件里将其全部搞成 __ramfunc（即在芯片内部RAM里实行这部分时钟配置代码），这个例程仅是利用SysTick定时翻转GPIO，因此时钟配置代码去掉不影响正常运行，重新编译工程再按上面流程操作一遍，这时候例程又能正常事情了，解释加密后的app是能被OTFAD正常解密实行的。
现在的问题变成了为何OTFAD加密启动时，BOARD_BootClockRUN() 函数不能在Flash里实行，这便是问题所在。
二、缘故原由剖析
关于上述问题的缘故原由，痞子衡先直接给答案，这是OTFAD外设本身的时钟小限定，当OTFAD被使能时，如果被加密的app代码是XIP实行，app里做系统时钟配置时要始终担保Core时钟高于FlexSPI外设时钟。如果Core时钟低于FlexSPI时钟，此时Core去访问加密Flash区域，OTFAD无法正常解密，会导致指令错乱，发生系统故障。
我们合营上面的i.MXRT1010系统时钟树来负责剖析下OTFAD这个时钟限定问题。芯片上电总是从BootROM实行，BootROM会先将Core配置到396MHz，将FlexSPI时钟根据用户放置在Flash偏移0x400处的FDCB里的设定配到30MHz - 200MHz不等，再读取Flash偏移0地址处OTFAD DEK KeyBlob数据使能OTFAD，然后读取IVT等头信息去跳转到App。很显然只加密IVT部分根本不受OTFAD限定的影响，这部分解析是在BootROM里完成的，BootROM里时钟配置符合OTFAD时钟限定哀求。
// BootROM里对Core时钟配置CCM_ANALOG->PFD_528[PFD3_FRAC] = 24, PLL2 PFD3输出 (528MHz 18) / 24 = 396MHzCCM->CBCMR[PRE_PERIPH_CLK_SEL] = 2, 时钟来自PLL2 PFD3CCM->CBCDR[PERIPH_CLK_SEL] = 0， 内核时钟来自CCM->CBCMR[PRE_PERIPH_CLK_SEL]CCM->CBCDR[AHB_PODF] = 0， 内核时钟不分频// BootROM里对FlexSPI时钟配置CCM_ANALOG->PFD_480[PFD0_FRAC] = x, PLL3 PFD0输出 (480MHz 18) / xCCM->CSCMR1[FLEXSPI_CLK_SEL] = 3, 时钟来自PLL3 PFD0CCM->CSCMR1[FLEXSPI_CLK_SRC] = 0， FlexSPI时钟来自CCM->CSCMR1[FLEXSPI_CLK_SEL]CCM->CSCMR1[FLEXSPI_PODF] = y， FlexSPI时钟做(y+1)分频
当BootROM跳转到了App之后，我们再来看看App里对时钟是怎么配置的，便是BOARD_BootClockRUN()函数，可以看到这个函数里将内核频率从BootROM设置的396MHz切换到外部OSC 24MHz。无论此时用户FDCB里对FlexSPI时钟是多少配置，至少也会大于30MHz，那么此时24MHz内核频率一定会低于FlexSPI时钟频率，此时只要发生内核对Flash加密区域的访问（时钟配置代码就在Flash里实行），就触发了OTFAD时钟限定问题，App就会跑飞。
三、办理方案
知道了缘故原由，办理方案就大略了，在App时钟配置里，不要按照平凡套路去先将内核时钟源切换到外部OSC再切到PLL，而是直接切到PLL上。比如i.MXRT1010内部有个PLL6（也叫Audio PLL），固定500MHz，恰好是App要的终极内核频率，我们在BOARD_BootClockRUN()里将Audio(Enet) PLL初始化设置代码提到前面，删掉原来的切换OSC设置代码即可。
void BOARD_BootClockRUN(void){ // 此处略去... / Set Oscillator ready counter value. / CCM->CCR = (CCM->CCR & (~CCM_CCR_OSCNT_MASK)) | CCM_CCR_OSCNT(127);- / Setting PeriphClk2Mux and PeriphMux to provide stable clock before PLLs are initialed /- CLOCK_SetMux(kCLOCK_PeriphClk2Mux, 1); / Set PERIPH_CLK2 MUX to OSC /- CLOCK_SetMux(kCLOCK_PeriphMux, 1); / Set PERIPH_CLK MUX to PERIPH_CLK2 / // 此处略去... / Set IPG_PODF. / CLOCK_SetDiv(kCLOCK_IpgDiv, 3);+ / Init Enet PLL. /+ CLOCK_InitEnetPll(&enetPllConfig_BOARD_BootClockRUN);+ / Set preperiph clock source. /+ CLOCK_SetMux(kCLOCK_PrePeriphMux, 3); // 此处略去... / Enable Audio PLL output. / CCM_ANALOG->PLL_AUDIO |= CCM_ANALOG_PLL_AUDIO_ENABLE_MASK;- / Init Enet PLL. /- CLOCK_InitEnetPll(&enetPllConfig_BOARD_BootClockRUN);- / Set preperiph clock source. /- CLOCK_SetMux(kCLOCK_PrePeriphMux, 3); // 此处略去... / Set SystemCoreClock variable. / SystemCoreClock = BOARD_BOOTCLOCKRUN_CORE_CLOCK;}
末了再提一下，这个OTFAD时钟限定问题在i.MXRT1170上同样存在，办理思路与上面类似，痞子衡就不再赘述了。
至此，系统时钟配置不当会导致i.MXRT1xxx系列下OTFAD加密启动失落败问题痞子衡便先容完毕了，掌声在哪里~~~
查看原文：https://www.dianyuan.com/eestar/article-8335.html
反激拓扑3—CCM模式与DCM模式的边界条件
上期推送对反激电路的事情模式和大略事理打算进行了先容反激拓扑2—反激电路事情事理剖析，文中提到反激电路事情模式分为CCM、CRM和DCM，那么CCM和DCM模式的边界条件是什么？很明显，便是上文中说的CRM即临界模式，我们在同一个图中绘制出三个模式下的励磁电流波形进行剖析。
从图中，可知：
①CCM模式下，励磁电流的均匀电流存在一个直流分量，其均匀电流Im＞Im_peak/2，t1+t2+t3=T，t1=ton，t2+t3=toff；
②DCM模式下，励磁电感在每个周期内都可以被完备去磁，其均匀电流Im＜Im_peak/2，t1+t2+t3=T，t1=ton，t2=toff，t3韶光段内，反激变压器的原副边均无电流；
③CRM边界模式下，励磁电感充磁和去磁能量恰好相等，其均匀电流Im=Im_peak/2，t1+t2+t3=T，t1=ton，t2+t3=toff；
反激变压器低级侧的电流波形如图所示
变压器次级电流波形如图所示
根据电感伏秒平衡定律：
带入上式简化得：
这个便是CCM和DCM的边界条件，个中f为反激电源的开关频率，D为占空比，N为原副边的匝数比，Lm为励磁电感，R为等效负载电阻。有如下结论：CCM模式下：
DCM模式下：
查看原文：https://www.dianyuan.com/eestar/article-8437.html
更多精彩内容，尽在电子星球 APP（https://www.eestar.com/）
六篇技能文章，让你秒懂电容的脾气秉性
七篇DIY技能文章献给你，让你脑洞全开
五篇文章帮你开启DSP的学习思路
汇总篇：关于PID知识，重点在此
