2301_81461100的博客

3. 使用cascade以及模型文件（本例使用的是人脸正面）对图片进行预测。1. 读取cascade模型文件。2. 对输入的图片进行灰度处理。步骤如Test，截取出人脸照片。

输入两张图片，返回比对结果： DrawMatches.Test(arrICs[3], arrICs[1]);本例基于EmguCv...

概述总体的思路是：自顶向下逐步启用mpy-cross编译，将Python程序集成到固件中自底向上逐步添加sfud组件并启用lfs合龙，创建mm32f3.flash模块，封装sfud，并由集成到固件中的Python程序调用mm32f3.flash模块。启用frozen_moduleMicroPython加载lfs使用了同之前加载fatfs不同的方式，通过向固件程序中集成Python语言编写的脚本来加载lfs文件系统。在C语言编写的MicroPython固件中加载Python语言程序的机制，就是所

原本以为放开在machine的类清单中对Signal类型的定义就能通，虽然能够通过编译，但在实测中并不能操作引脚。在代码仓库里搜索“mp_pin_p_t”，发现esp系的port中，machine_pin.c中有相关的引用。特别注意，machine_pin_type中的一个字段：“ .protocol = &pin_pin_p,”这里调用了mp_pin_p_t中的ioctl函数，它是在virpin.h中声明的，这是哪里定义的呢？但是在mm32的machine_pin_type的实现中就没有这个字段。

前文（尚未发布）提到，我目前已经启用Thonny对接KE18F/F3270上的MicroPython，但如果把main.py写成死循环（在实际开发时，必须写成死循环，否则程序执行完就不工作了），复位开发板后，由于MicroPython直接进入main.py中的死循环，调度器始终占用CPU，再没有机会进入REPL同Thonny对接了。解法只能是把SD卡取下来，改掉其中的main.py文件的死循环，再把SD卡装回去，重新启动开发板。我曾想试着利用CTRL+C打断调度器，但不起作用。

额，算了，ADC可能不是一个单独的模块。当然，预先指定通道的事情，可以让ADC()实例化函数搞一下，当实例化一个ADC采样通道时，实际上后台已经开始转换了，并且周期地将最近一次转换结果保存到一个缓冲区中，这样当启动read_u16函数时，可以直接从缓冲区中读到最近的采样结果，这样做可以保证读数时直接拿到结果，不等待，但特别费电，ADC转换器在后台一直不停地工作。从面向对象的角度，用户看到的是引脚，才不关心内部是怎么分配的引脚号，实际转换的时候，用户也看不到分配的通道号，操作的是引脚对象而已。

TPYBoard v102主控芯片采用STM32F405,M4的内核，168MHZ的最高运行速度，1024KB的Flash，192KB的。30 个通用GPIO 接口、 2个 SPI 接口、2个 CAN 接口、2个I2C 接口、 5个 USART 接口、 2个ADC接。其中对于串口控制拍照，读取静态图片的应用中，只需要用到 GND，RX，TX，VCC 这 4 个信号线。上电后，等待ToyBoard v102板载绿灯亮起，说明摄像头模块初始化完毕，按一下USR键，控制摄像头进行拍。

ESP32-CAM 是安信可发布小尺寸的摄像头模组。该模块可以作为最小系统独立工作，尺寸仅为2740.54.5mm。ESP32-CAM可广泛应用于各种物联网场合，适用于家庭智能设备、工业无线控制、无线监控、人脸识别以及其它物联网应用，是物联网应用的理想解决方案。ESP32-CAM采用DIP封装，直接插上底板即可使用，实现产品的快速生产，为客户提供高可靠性的连接方式，方便应用于各种物联网硬件终端场合。开发环境准备。

上文书说，已经搭建了一个基本的能够在REPL中引用到的Pin模块。为了规避Hardfault的问题，暂时屏蔽了history的功能。勉强已经可以用起来了。本文将要打通python对底层硬件的操作，进一步完成Pin模块。本文可能会涉及到引脚表的设计问题make_new()感觉在machine_pin_obj_make_new()里检查这个参数清单没啥功能性作用。如果参数无效，则直接报错？后来在试用程序的过程发现挺有用的，当用户输入参数不正确时，会提示错误类型。

考虑到history可能涉及到的地方比较多，我试着找了找能不能通过某个用户选项把history相关的功能都关掉，未果，只好人工mask掉这一句，并且祈祷尽量别碰到使用history的场景。在“ports/mm32”目录下创建“machine_pin.c”，此文件专用于存放pin类的实现，是“modmachine.c”总类的下属。一点长远的考虑，timer的类原本是在minimal中的，它对硬件的依赖并不复杂，短时间也考虑实现出来。在“machine_pin.c”文件中编写与底层无关的框架代码，见附件。

回到ports/mimxrt/machine_pin.c文件，同machine_pin_type并列定义的还有“machine_pin_af_type”，在“pin.h”和“ports/mimxrt/boards/mimxrt_prefix.c”文件中有所涉及，关于指定引脚功能复用的，似乎也作为一个实例对象定义的，但未被注册到任何模块中，暂且放过，待看完machine_pin_type后再回来看。关于“mp_obj_type_t”的定义，具体可参见“py/obj.h”文件，此处仅对必要的字段进行解释。

这个结构体中定义了mp_module_machine 对象内部的属性清单，并建立一个类似于python中map的表，这样在micropython内核中，就可以通过QSTR字符串“Pin”，找到指向machine_pin_type结构体实体的指针，我们或可认为通过python内部的某种机制就可以通过“.”这个字符，映射到其对应的内存块。在py/objmodule.c文件中，mp_builtin_module_map被函数mp_module_get()引用，在映射表中通过模块名字查询对应实体。

介绍了_thread（多线程）的基础讲解，这次将结合UART（串口）开进行开发应用讲解。串口在日常的设计中是一个非常常见的东西，所以熟练掌握是基本知识。下面，就来介绍一下关于串口与_thread 结合的一个小程序。下面是所需要准备的东西。硬件设计：Rasspberry Pi Pico开发板（应用Micropython开发）USB转TTL开发板软连线上面显示了其连线示意图。

estack和_sstack就是系统栈，_gc_heap_start和_gc_heap_end代表了整个ocrm的空间。gc_collect()函数的实现依赖于具体的CPU架构，需要根据移植平台实现，中间涉及到获取系统栈中CPU寄存器值及监管范围的操作，不同的处理器有所区别，所以需要用户实现，但大部分通用操作已经由gc_collect_xxx()的其它函数实现了，所以用户在具体的移植中实现gc_collect()时，可调用其它gc_collect_xxx()函数完成大部分功能。

从makefile文件中可以看到, "$(BUILD)/_frozen_mpy.c"文件是通过向mpy-tool.py工具传入frozentest.mpy, 在build过程中自动生成的. 删除相关的make环节之后, 在最小移植中不需要管mpy-tool.py中的"python3"问题, 同时 也可以在移植项目的根目录下删除frozentest.py和frozentest.mpy这两个不相干的文件了.在最小移植中移除对frozentest.mpy的依赖。

在pyb目录下创建pin.c/.h文件，包含Pin类定义的主体内容暂时不用管这里包含的头文件的含义，只要照抄就行。唯一有用的一句话是最后一句，定义了“pyb_pin_type”的一个类型实例，这个类型实例将在pyb.c文件中被整合到pyb模块下面。pin.c文件中实现mpy通过C语言操作硬件的功能函数。这个文件里可以直接包含C源代码的驱动程序文件，可以像平时写C语言的单片机程序一样自由发挥。例如：这些代码同用C语言操作底层寄存器的代码没有任何区别。

根据官方描述步骤创建一个led模块为新模块创建一个源文件参考官方样例的命名规范, 这里在lpc5500移植项目的目录下创建mod_led.c。