
Linux阻塞和非阻塞IO实验 阻塞和非阻塞IO是Linux驱动开发里面很常见的两种设备访问模式,在编写驱动的时候一定要考虑到阻塞和非阻塞。本章我们就来学习一下阻塞和非阻塞IO,以及如何在驱动程序中处理阻塞与非阻塞,如何在驱动程序使用等待队列和poll机制。 32.1 阻塞和非阻塞IO 32.1.1 阻塞和非阻塞简介 这里的“IO”并不是我们学习单片机的时候所说的“GPIO”(也就是引脚)。这里的IO指的是Input/Output,也就是输入/输出,是应用程序对驱动设备的输入/输出操作。当应用程序对设备驱动进行操作的时候,如果不能获取到设备资源,那么阻塞式IO就会将应用程序对应的线程挂起,直到设备资源可以获取为止。对于非阻塞IO,应用程序对应的线程不会挂起,它要么一直轮询等待,直到设备资源可以使用,要么就直接放弃。阻塞式IO如图32.1.1.1所示: ![]() 图32.1.1.1 阻塞IO访问示意图。 图32.1.1.1中应用程序调用read函数从设备中读取数据,当设备不可用或数据未准备好的时候就会进入到休眠态。等设备可用的时候就会从休眠态唤醒,然后从设备中读取数据返回给应用程序。非阻塞IO如图32.1.2所示: ![]() 图32.1.1.2 非阻塞IO访问示意图 从图32.1.1.2可以看出,应用程序使用非阻塞访问方式从设备读取数据,当设备不可用或数据未准备好的时候会立即向内核返回一个错误码,表示数据读取失败。应用程序会再次重新读取数据,这样一直往复循环,直到数据读取成功。 应用程序可以使用如下所示示例代码来实现阻塞访问:
从示例代码32.1.1.1可以看出,对于设备驱动文件的默认读取方式就是阻塞式的,所以我们前面所有的例程测试APP都是采用阻塞IO。 如果应用程序要采用非阻塞的方式来访问驱动设备文件,可以使用如下所示代码:
以非阻塞方式打开设备,这样从设备中读取数据的时候就是非阻塞方式的了。 32.1.2 等待队列 1、等待队列头 阻塞访问最大的好处就是当设备文件不可操作的时候进程可以进入休眠态,这样可以将CPU资源让出来。但是,当设备文件可以操作的时候就必须唤醒进程,一般在中断函数里面完成唤醒工作。Linux内核提供了等待队列(wait queue)来实现阻塞进程的唤醒工作,如果我们要在驱动中使用等待队列,必须创建并初始化一个等待队列头,等待队列头使用结构体wait_queue_head表示,wait_queue_head结构体定义在文件include/linux/wait.h中,结构体内容如下所示:
有些资料里面用wait_queue_head_t表示等待队列头,从38行可以看出,wait_queue_head_t是wait_queue_head的别名,这么做的目的是为了兼容老版本代码。最新版本的系统都用wait_queue_head表示等待队列头,如果你的代码要考虑移植到老版本linux内核中,那么最好使用wait_queue_head_t表示等待队列头。 定义好等待队列头以后需要初始化,使用init_waitqueue_head函数初始化等待队列头,函数原型如下: void init_waitqueue_head(struct wait_queue_head *wq_head) 参数wq_head就是要初始化的等待队列头。 也可以使用宏DECLARE_WAIT_QUEUE_HEAD来一次性完成等待队列头的定义的初始化。 2、等待队列项 等待队列头就是一个等待队列的头部,每个访问设备的进程都是一个队列项,当设备不可用的时候就要将这些进程对应的队列项添加到等待队列里面。在以前的linux版本中使用结构体wait_queue_t表示等待队列项,在5.4版本的linux内核中已经删除了wait_queue_t,取而代之的是wait_queue_entry结构体(其实只是换了个名字,结构体内的成员变量还是一样的),wait_queue_entry结构体内容如下:
使用宏DECLARE_WAITQUEUE定义并初始化一个等待队列项,宏的内容如下: DECLARE_WAITQUEUE(name, tsk) name就是等待队列项的名字,tsk表示这个等待队列项属于哪个任务(进程),一般设置为current,在Linux内核中current相当于一个全局变量,表示当前进程。因此宏DECLARE_WAITQUEUE就是给当前正在运行的进程创建并初始化了一个等待队列项。 3、将队列项添加/移除等待队列头 当设备不可访问的时候就需要将进程对应的等待队列项添加到前面创建的等待队列头中,只有添加到等待队列头中以后进程才能进入休眠态。当设备可以访问以后再将进程对应的等待队列项从等待队列头中移除即可,等待队列项添加API函数如下: void add_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry) 函数参数和返回值含义如下: wq_head:等待队列项要加入的等待队列头。 wq_entry:要加入的等待队列项。 返回值:无。 等待队列项移除API函数如下: void remove_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry) 函数参数和返回值含义如下: wq_head:要删除的等待队列项所处的等待队列头。 wq_entry:要删除的等待队列项。 返回值:无。 4、等待唤醒 当设备可以使用的时候就要唤醒进入休眠态的进程,唤醒可以使用如下两个函数: void wake_up(struct wait_queue_head *wq_head) void wake_up_interruptible(struct wait_queue_head *wq_head) 参数wq_head就是要唤醒的等待队列头,这两个函数会将这个等待队列头中的所有进程都唤醒。wake_up函数可以唤醒处于TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE状态的进程,而wake_up_interruptible函数只能唤醒处于TASK_INTERRUPTIBLE状态的进程。 5、等待事件 除了主动唤醒以外,也可以设置等待队列等待某个事件,当这个事件满足以后就自动唤醒等待队列中的进程,和等待事件有关的API函数如表32.1.2.1所示: ![]() 32.1.3 轮询 如果用户应用程序以非阻塞的方式访问设备,设备驱动程序就要提供非阻塞的处理方式,也就是轮询。poll、epoll和select可以用于处理轮询,应用程序通过select、epoll或poll函数来查询设备是否可以操作,如果可以操作的话就从设备读取或者向设备写入数据。当应用程序调用select、epoll或poll函数的时候设备驱动程序中的poll函数就会执行,因此需要在设备驱动程序中编写poll函数。我们先来看一下应用程序中使用的select、poll和epoll这三个函数。 1、select函数 select函数原型如下: int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) 函数参数和返回值含义如下: nfds:所要监视的这三类文件描述集合中,最大文件描述符加1。 readfds、writefds和exceptfds:这三个指针指向描述符集合,这三个参数指明了关心哪些描述符、需要满足哪些条件等等,这三个参数都是fd_set类型的,fd_set类型变量的每一个位都代表了一个文件描述符。readfds用于监视指定描述符集的读变化,也就是监视这些文件是否可以读取,只要这些集合里面有一个文件可以读取那么seclect就会返回一个大于0的值表示文件可以读取。如果没有文件可以读取,那么就会根据timeout参数来判断是否超时。可以将readfs设置为NULL,表示不关心任何文件的读变化。writefds和readfs类似,只是writefs用于监视这些文件是否可以进行写操作。exceptfds用于监视这些文件的异常。 比如我们现在要从一个设备文件中读取数据,那么就可以定义一个fd_set变量,这个变量要传递给参数readfds。当我们定义好一个fd_set变量以后可以使用如下所示几个宏进行操作: void FD_ZERO(fd_set *set) void FD_SET(int fd, fd_set *set) void FD_CLR(int fd, fd_set *set) int FD_ISSET(int fd, fd_set set) FD_ZERO用于将fd_set变量的所有位都清零,FD_SET用于将fd_set变量的某个位置1,也就是向fd_set添加一个文件描述符,参数fd就是要加入的文件描述符。FD_CLR用户将fd_set变量的某个位清零,也就是将一个文件描述符从fd_set中删除,参数fd就是要删除的文件描述符。FD_ISSET用于测试一个文件是否属于某个集合,参数fd就是要判断的文件描述符。 timeout:超时时间,当我们调用select函数等待某些文件描述符可以设置超时时间,超时时间使用结构体timeval表示,结构体定义如下所示: struct timeval { long tv_sec; / 秒 / long tv_usec; / 微妙 */ }; 当timeout为NULL的时候就表示无限期的等待。 返回值:0,表示的话就表示超时发生,但是没有任何文件描述符可以进行操作;-1,发生错误;其他值,可以进行操作的文件描述符个数。 使用select函数对某个设备驱动文件进行读非阻塞访问的操作示例如下所示:
2、poll函数 在单个线程中,select函数能够监视的文件描述符数量有最大的限制,一般为1024,可以修改内核将监视的文件描述符数量改大,但是这样会降低效率!这个时候就可以使用poll函数,poll函数本质上和select没有太大的差别,但是poll函数没有最大文件描述符限制,Linux应用程序中poll函数原型如下所示: int poll(struct pollfd *fds, nfds_t nfds, int timeout) 函数参数和返回值含义如下: fds:要监视的文件描述符集合以及要监视的事件,为一个数组,数组元素都是结构体pollfd类型的,pollfd结构体如下所示:
fd是要监视的文件描述符,如果fd无效的话那么events监视事件也就无效,并且revents返回0。events是要监视的事件,可监视的事件类型如下所示: POLLIN 有数据可以读取。 POLLPRI 有紧急的数据需要读取。 POLLOUT 可以写数据。 POLLERR 指定的文件描述符发生错误。 POLLHUP 指定的文件描述符挂起。 POLLNVAL 无效的请求。 POLLRDNORM 等同于POLLIN revents是返回参数,也就是返回的事件,由Linux内核设置具体的返回事件。 nfds:poll函数要监视的文件描述符数量。 timeout:超时时间,单位为ms。 返回值:返回revents域中不为0的pollfd结构体个数,也就是发生事件或错误的文件描述符数量;0,超时;-1,发生错误,并且设置errno为错误类型。 使用poll函数对某个设备驱动文件进行读非阻塞访问的操作示例如下所示:
3、epoll函数 传统的selcet和poll函数都会随着所监听的fd数量的增加,出现效率低下的问题,而且poll函数每次必须遍历所有的描述符来检查就绪的描述符,这个过程很浪费时间。为此,epoll应运而生,epoll就是为处理大并发而准备的,一般常常在网络编程中使用epoll函数。应用程序需要先使用epoll_create函数创建一个epoll句柄,epoll_create函数原型如下: int epoll_create(int size) 函数参数和返回值含义如下: size:从Linux2.6.8开始此参数已经没有意义了,随便填写一个大于0的值就可以。 返回值:epoll句柄,如果为-1的话表示创建失败。 epoll句柄创建成功以后使用epoll_ctl函数向其中添加要监视的文件描述符以及监视的事件,epoll_ctl函数原型如下所示:
函数参数和返回值含义如下: epfd:要操作的epoll句柄,也就是使用epoll_create函数创建的epoll句柄。 op:表示要对epfd(epoll句柄)进行的操作,可以设置为: EPOLL_CTL_ADD 向epfd添加文件参数fd表示的描述符。 EPOLL_CTL_MOD 修改参数fd的event事件。 EPOLL_CTL_DEL 从epfd中删除fd描述符。 fd:要监视的文件描述符。 event:要监视的事件类型,为epoll_event结构体类型指针,epoll_event结构体类型如下所示:
结构体epoll_event的events成员变量表示要监视的事件,可选的事件如下所示: EPOLLIN 有数据可以读取。 EPOLLOUT 可以写数据。 EPOLLPRI 有紧急的数据需要读取。 EPOLLERR 指定的文件描述符发生错误。 EPOLLHUP 指定的文件描述符挂起。 EPOLLET 设置epoll为边沿触发,默认触发模式为水平触发。 EPOLLONESHOT 一次性的监视,当监视完成以后还需要再次监视某个fd,那么就需要将fd重新添加到epoll里面。 上面这些事件可以进行“或”操作,也就是说可以设置监视多个事件。 返回值:0,成功;-1,失败,并且设置errno的值为相应的错误码。 一切都设置好以后应用程序就可以通过epoll_wait函数来等待事件的发生,类似select函数。epoll_wait函数原型如下所示:
函数参数和返回值含义如下: epfd:要等待的epoll。 events:指向epoll_event结构体的数组,当有事件发生的时候Linux内核会填写events,调用者可以根据events判断发生了哪些事件。 maxevents:events数组大小,必须大于0。 timeout:超时时间,单位为ms。 返回值:0,超时;-1,错误;其他值,准备就绪的文件描述符数量。 epoll更多的是用在大规模的并发服务器上,因为在这种场合下select和poll并不适合。当设计到的文件描述符(fd)比较少的时候就适合用selcet和poll,本章我们就使用sellect和poll这两个函数。 32.1.4 Linux驱动下的poll操作函数 当应用程序调用select或poll函数来对驱动程序进行非阻塞访问的时候,驱动程序file_operations操作集中的poll函数就会执行。所以驱动程序的编写者需要提供对应的poll函数,poll函数原型如下所示: unsigned int (*poll) (struct file *filp, struct poll_table_struct *wait) 函数参数和返回值含义如下: filp:要打开的设备文件(文件描述符)。 wait:结构体poll_table_struct类型指针,由应用程序传递进来的。一般将此参数传递给poll_wait函数。 返回值:向应用程序返回设备或者资源状态,可以返回的资源状态如下: POLLIN 有数据可以读取。 POLLPRI 有紧急的数据需要读取。 POLLOUT 可以写数据。 POLLERR 指定的文件描述符发生错误。 POLLHUP 指定的文件描述符挂起。 POLLNVAL 无效的请求。 POLLRDNORM 等同于POLLIN,普通数据可读 我们需要在驱动程序的poll函数中调用poll_wait函数,poll_wait函数不会引起阻塞,只是将应用程序添加到poll_table中,poll_wait函数原型如下: void poll_wait(struct file * filp, wait_queue_head_t * wait_address, poll_table *p) 参数wait_address是要添加到poll_table中的等待队列头,参数p就是poll_table,就是file_operations中poll函数的wait参数。 32.2 阻塞IO实验 在上一章Linux中断实验中,我们直接在应用程序中通过read函数不断的读取按键状态,当按键有效的时候就打印出按键值。这种方法有个缺点,那就是keyirqApp这个测试应用程序拥有很高的CPU占用率,大家可以在开发板中加载上一章的驱动程序模块keyirq.ko,然后以后台运行模式打开keyirqApp这个测试软件,命令如下: ./keyirqApp /dev/keyirq & 测试驱动是否正常工作,如果驱动工作正常的话输入“top”命令查看keyirqApp这个应用程序的CPU使用率,结果如图32.2.1所示: ![]() 图32.2.1 CPU使用率 从图32.2.1可以看出,keyirqApp这个应用程序的CPU使用率竟然高达50%,这仅仅是一个读取按键值的应用程序,这么高的CPU使用率显然是有问题的!原因就在于我们是直接在while循环中通过read函数读取按键值,因此keyirqApp这个软件会一直运行,一直读取按键值,CPU使用率肯定就会很高。最好的方法就是在没有有效的按键事件发生的时候,keyirqApp这个应用程序应该处于休眠状态,当有按键事件发生以后keyirqApp这个应用程序才运行,打印出按键值,这样就会降低CPU使用率,本小节我们就使用阻塞IO来实现此能。 32.2.1 硬件原理图分析 本章实验硬件原理图参考29.2小节即可。 32.2.2 实验程序编写 1、驱动程序编写 本实验对应的例程路径为:开发板光盘-> 2、Linux驱动例程-> 14_blockio。 本章实验我们在上一章的“13_irq”实验的基础上完成,主要是对其添加阻塞访问相关的代码。新建名为“14_blockio”的文件夹,然后在14_blockio文件夹里面创建vscode工程,工作区命名为“blockio”。将“13_irq”实验中的keyirq.c复制到14_blockio文件夹中,并重命名为blockio.c。接下来我们就修改blockio.c这个文件,在其中添加阻塞相关的代码,完成以后的blockio.c内容如下所示(因为是在上一章实验的keyirq.c文件的基础上修改的,为了减少篇幅,下面的代码有省略):
第42~54行,我们删除了设备结构体struct key_dev中的自旋锁变量,本章驱动代码我们不用自旋锁,而改成第52行的原子变量来实现对相应变量的保护操作。第53行添加了一个等待队列头r_wait,因为在Linux驱动中处理阻塞IO需要用到等待队列,而等待队列会使进程进入休眠状态,所以不能使用自旋锁! 第150~169行,定时器定时处理函数key_timer_function,对按键状态进行判断,如果是按下动作或是松开动作则会使用wake_up_interruptible函数唤醒等待队列,并且将status变量设置为KEY_PRESS或KEY_RELEASE;这样在key_read函数中阻塞的进程就会解除阻塞继续进行下面的操作。 第191~208行,key_read函数,在这个函数中我们会判断按键是否有按下或松开动作发生时,如果没有则调用wait_event_interruptible把它加入等待队列当中,进行阻塞。如果等待队列被唤醒并且条件“KEY_KEEP != atomic_read(&status)”成立,则解除阻塞,继续下面的操作,也就是读取按键状态数据将其发送给应用程序。因为采用了wait_event_interruptible函数,因此进入休眠态的进程可以被信号打断。在该函数中我们读取status原子变量必须要使用atomic_read函数进行操作。 第252行,在驱动入口函数中我们会调用init_waitqueue_head初始化等待队列头;第255行使用原子操作atomic_set设置按键的初始状态status为KEY_KEEP。 使用等待队列实现阻塞访问重点注意两点: ①、将任务或者进程加入到等待队列头, ②、在合适的点唤醒等待队列,一般是中断处理函数里面。 2、编写测试APP 本节实验的测试APP直接使用13_irq实验目录下的keyirqApp.c测试程序,将keyirqApp.c复制到本实验目录14_blockio中,不需要修改任何内容。 32.2.3 运行测试 1、编译驱动程序和测试APP ①、编译驱动程序 编写Makefile文件,本章实验的Makefile文件和第四十章实验基本一样,只是将obj-m变量的值改为blockio.o,Makefile内容如下所示:
第4行,设置obj-m变量的值为blockio.o。 输入如下命令编译出驱动模块文件: make -j32 编译成功以后就会生成一个名为“blockio.ko”的驱动模块文件。 ②、编译测试APP 输入如下命令编译测试blockioApp.c这个测试程序: arm-none-linux-gnueabihf-gcc blockioApp.c -o blockioApp 编译成功以后就会生成blcokioApp这个应用程序。 2、运行测试 将上一小节编译出来blockio.ko和blockioApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载blockio.ko驱动模块: depmod //第一次加载驱动的时候需要运行此命令 modprobe blockio.ko //加载驱动 驱动加载成功以后使用如下命令打开blockioApp这个测试APP,并且以后台模式运行: ./blockioApp /dev/key & 按下开发板上的KEY0按键,结果如图32.2.3.1所示: ![]() 图32.2.3.1 测试APP运行测试 当按下KEY0按键以后blockioApp这个测试APP就会打印出按键状态。输入“top”命令,查看blockioAPP这个应用APP的CPU使用率,如图32.2.3.2所示: ![]() 图32.2.3.2 应用程序CPU使用率 从图32.2.3.2可以看出,当我们在按键驱动程序里面加入阻塞访问以后,blockioApp这个应用程序的CPU使用率从图32.2.1中的48%降低到了0%。大家注意,这里的0%并不是说blockioApp这个应用程序不使用CPU了,只是因为使用率太小了,CPU使用率可能为0.00001%,但是图32.2.3.2是没有小数点显示的,因此就显示成了0%。 我们可以使用“kill”命令关闭后台运行的应用程序,比如我们关闭掉blockioApp这个后台运行的应用程序。首先输出“Ctrl+C”关闭top命令界面,进入到命令行模式。然后使用“ps”命令查看一下blockioApp这个应用程序的PID,如图32.2.3.3所示: ![]() 图32.2.3.3 当前系统所有进程的ID 从图图32.2.3.3可以看出,blockioApp这个应用程序的PID为338,使用“kill -9 PID”即可“杀死”指定PID的进程,比如我们现在要“杀死”PID为338的blockioApp应用程序,可是使用如下命令: kill -9 338 输入上述命令以后终端显示如图32.2.3.4所示: ![]() 图32.2.3.4 kill命令输出结果 从图32.2.3.4可以看出,“./blockioApp /dev/key”这个应用程序已经被“杀掉”了,在此输入“ps”命令查看当前系统运行的进程,会发现blockioApp已经不见了。这个就是使用kill命令“杀掉”指定进程的方法。 32.3 非阻塞IO实验 32.3.1 硬件原理图分析 本章实验硬件原理图参考29.2小节即可。 32.3.2 实验程序编写 1、驱动程序编写 本实验对应的例程路径为:开发板光盘1、程序源码2、Linux驱动例程15_noblockio。 本章实验我们在32.2小节中的“14_blockio”实验的基础上完成,上一小节实验我们已经在驱动中添加了阻塞IO的代码,本小节我们继续完善驱动,加入非阻塞IO驱动代码。新建名为“15_noblockio”的文件夹,然后在15_noblockio文件夹里面创建vscode工程,工作区命名为“noblockio”。将“14_blockio”实验中的blockio.c复制到15_noblockio文件夹中,并重命名为noblockio.c。接下来我们就修改noblockio.c这个文件,在其中添加非阻塞相关的代码,完成以后的noblockio.c内容如下所示(因为是在上一小节实验的blockio.c文件的基础上修改的,为了减少篇幅,下面的代码有省略):
第28行,使用include将内核源码目录include/linux/poll.h头文件包含进来。 第193~214行,key_read函数中判断是否为非阻塞式读取访问,如果是的话就判断按键状态是否有效,也就是判断是否产生了按下或松开这样的动作,如果没有的话就返回-EAGAIN。 第245255行,key_poll函数就是file_operations驱动操作集中的poll函数,当应用程序调用select或者poll函数的时候key_poll函数就会执行。第249行调用poll_wait函数将等待队列头添加到poll_table中,第251252行判断按键是否有效,如果按键有效的话就向应用程序返回POLLIN这个事件,表示有数据可以读取。 第264行,设置file_operations的poll成员变量为key_poll。 2、编写测试APP 新建名为noblockioApp.c测试APP文件,然后在其中输入如下所示内容:
第53~77行,在本测试程序中我们使用select函数来实现非阻塞访问,在for循环中使用select函数不断的轮询,检查驱动程序是否有数据可以读取,如果可以读取的话就调用read函数读取按键数据。大家也可以试试使用poll函数来实现! 32.3.3 运行测试 1、编译驱动程序和测试APP ①、编译驱动程序 编写Makefile文件,本章实验的Makefile文件和第四十章实验基本一样,只是将obj-m变量的值改为noblockio.o,Makefile内容如下所示:
第4行,设置obj-m变量的值为noblockio.o。 输入如下命令编译出驱动模块文件: make -j32 编译成功以后就会生成一个名为“noblockio.ko”的驱动模块文件。 ②、编译测试APP 输入如下命令编译测试noblockioApp.c这个测试程序: arm-none-linux-gnueabihf-gcc noblockioApp.c -o noblockioApp 编译成功以后就会生成noblcokioApp这个应用程序。 2、运行测试 将上一小节编译出来noblockio.ko和noblockioApp这两个文件拷贝到rootfs/lib/modules/5.4.31目录中,重启开发板,进入到目录lib/modules/5.4.31中,输入如下命令加载blockio.ko驱动模块: depmod //第一次加载驱动的时候需要运行此命令 modprobe noblockio.ko //加载驱动 驱动加载成功以后使用如下命令打开noblockioApp这个测试APP,并且以后台模式运行: ./noblockioApp /dev/key & 按下开发板上的KEY0按键,结果如图32.3.3.1所示: ![]() 图32.3.3.1 测试APP运行测试 当按下KEY0按键以后noblockioApp这个测试APP就会打印出按键信息。输入“top”命令,查看noblockioAPP这个应用APP的CPU使用率,如图32.3.3.2所示: 图32.3.3.2 应用程序CPU使用率 从图32.3.3.2可以看出,采用非阻塞方式读处理以后,noblockioApp的CPU占用率也低至0%,和图32.2.3.2中的blockioApp一样,这里的0%并不是说noblockioApp这个应用程序不使用CPU了,只是因为使用率太小了。 如果要“杀掉”处于后台运行模式的noblockioApp这个应用程序,可以参考32.2.3小节讲解的方法。 ———————————————— 版权声明:正点原子 |
更新STM32MP135-Openwrt镜像
基于STM32MP1和STM32MP2在嵌入式Linux平台上部署有效的安全保护机制
利用STM32MP1和STM32MP2为嵌入式Linux提供有效的安全措施:供当今决策者参考的3条宝贵经验
STM32MP1 WiFi连接
【STM32MP157】从ST官方例程中分析RPMsg-TTY/SDB核间通信的使用方法
【STM32MPU 安全启动】 TF-A BL2 TrustedBoot原理学习
《STM32MPU安全启动》学**结
《STM32MPU安全启动》学习笔记之optee 如何加载CORTEX-M核和使能校验
《STM32MPU安全启动》学习笔记之TF-A BL2校验optee和uboot的流程以及如何使能
《STM32MPU 安全启动》课程学习心得+开启一扇通往嵌入式系统安全领域深处的大门。