ESP8266与MCU通信

前段时间学习了ESP8266的AT指令集,现在通过AT指令初始化ESP8266+串口通信的方式,完成WLAN下的信息交换,比如手机、PC、其他MCU与STC89 C51的通信等等。其中踩了不少的坑,特此记录一下。ESP8266小模块系列常见的就下面几种:ESP-01S比ESP-01多了两颗小料并增强了天线的强度,其他的是一样的,完全通用!

前段时间学习了ESP8266的AT指令集,现在通过AT指令初始化ESP8266+串口通信的方式,完成WLAN下的信息交换,比如手机、PC、其他MCU与STC89 C51的通信等等。其中踩了不少的坑,特此记录一下。ESP8266小模块系列常见的就下面几种:ESP-01S比ESP-01多了两颗小料并增强了天线的强度,其他的是一样的,完全通用!
本篇文章主要是三个部分,刷入官方原厂固件,进入透传模式,常用的AT指令集。有时候控制端不需要MCU反馈信息,那么就可以使用透传模式进行控制。USB转ESP8266通常再买回来的时候就已经刷入了官方固件,但是如果自己要重新刷入就需要USB转TTL,所以最好一次买两个USB-TTL,一个焊接好作为烧录器,另一个日常使用是比较方便的。

纠错码(error correcting code),在传输过程中发生错误后能在收端自行发现或纠正的码。
仅用来发现错误的码一般常称为检错码。
为使一种码具有检错或纠错能力,须对原码字增加多余的码元,以扩大码字之间的差别 ,即把原码字按某种规则变成有一定剩余度(见信源编码)的码字,并使每个码字的码之间有一定的关系。关系的建立称为编码。码字到达收端后,可以根据编码规则是否满足以判定有无错误。当不能满足时,按一定规则确定错误所在位置并予以纠正。纠错并恢复原码字的过程称为译码。检错码与其他手段结合使用,可以纠错。

Android的SDK提供了MediaPlayer、SoundPool和AudioTrack 三套音频播放的 API。其中AudioTrack适合低延迟的播放,是更加底层的API,提供了非常强大的控制能力,适合流媒体的播放等场景,由于其属于底层API,需要结合解码器来使用。
OpenSL ES全称为Open Sound Library for Embedded Systems,即嵌入式音频加速标准。OpenSL ES是无授权费、跨平台、针对嵌入式系统精心优化的硬件音频加速API。它为嵌入式移动多媒体设备上的本地应用程序开发者提供了标准化、高性能、低响应时间的音频功能实现方法,同时还实现了软/硬件音频性能的直接跨平台部署。本次要介绍的就是AudioTrack与OpenSL ES。
本节是C51单片机系列学习的最后一节,本节的重点是I2C总线通信,数模转换与模数转换。I2C与串口通信一样,在MCU通信里占据非常大的一部分。基本上算是通过C51系列单片机学完了的一些基本操作与概念,回顾这段时间的学习,收获最大部分还是学会看原理图、GPIO、定时器、中断资源、串口通信、I2C总线、AD/DA(PWM)、还有各种芯片模块等内容,后面会通过STC 89C51做一些小型项目,或者继续学习STM32吧~
这是51单片机学习的中篇,其中主要涉及的内容是串口通信、矩阵键盘、LED点阵屏、DS1302实时时钟、蜂鸣器等。其中最重要的其实就是串口通信了,串口通信是指仅用一根接收线和一根发送线就能将数据以位进行传输的一种通信方式。尽管串行通讯的比按字节传输的并行通信慢,但是串口可以在仅仅使用两根线的情况下就能实现数据的传输,后面要用到串口通信的场景也会比较多。
PopWindow 是开发中常用的一种组件,网上对于 PopWindow 的定位方法也众说纷纭,经过看过网上的很多博客,自己也动手尝试了一番,终于对 PopWindow 有了自己的认知,特此记录一下。其实主要是 PopWindow 大小的测量,以及通过相对定位确定 PopWindow 的弹出位置,这样如果遇到了使用场景直接用已有代码即可。
接着上一篇《FFmpeg API(上)》中的示例代码,其中代码很多方法调用并没有详细注释,现在特意注释一下,顺便对着这张图熟悉熟悉FFmpeg处理音视频的基本流程。需要理解的几个重要的结构体 AVFormatContext 、AVCodecContext 、AVPacket 与 AVFrame,这同样也是上篇文章中的示例程序里用的特别多的几个结构体。

上面的示例程序基本上演示了 FFmpeg 的一些常用 API,现在就对这些函数进行一个大致解读。

AVFormatContext 是API层直接接触到的结构体,它会进行格式的封装与解封装,它的数据部分由底层提供,底层使用了 AVIOContext,这个 AVIOContext 实际上就是为普通的I/O增加了一层Buffer缓冲区,再往底层就是URLContext,也就是到达了协议层,协议层的具体实现有很多,包括rtmp、http、hls、file等,这就是libavformat的内部封装了。

对于开发者来说,这一层我们能接触到的最顶层的结构体就是 AVCodecContext,该结构体包含的就是与实际的编解码有关的部分。首先,AVCodecContext 是包含在一个 AVStream里面的,即描述了这路流的编码格式是什么,其中存放了具体的编码格式信息,根据Codec的信息可以打开编码器或者解码器,然后利用该编码器或者解码器进行 AVPacket 与 AVFrame 之间的转换(实际上就是解码或者编码的过程),这是 FFmpeg 中最重要的一部分。
主要是介绍从文件/文件夹操作之后的一些函数。
在编译FFmpeg的时候,其中开启或者关闭了很多选项,生成 config.mk 与 config.h。config.mk实际上就是makefile文件需要包含进去的子模块,从而编译出正确的库;而config.h是作用在运行阶段,这一阶段将确定需要注册哪些容器以及编解码格式到FFmpeg框架中。所以该函数的内部实现会先调用 avcodec_register_all 来注册所有config.h 里面开放的编解码器,然后会注册所有的Muxer和Demuxer(也就是封装格式),最后注册所有的Protocol(即协议层的东西)。
函数 avformat_open_input 会根据所提供的文件路径判断文件的格式,其实就是通过这一步来决定使用的到底是哪一个 Demuxer。举例来说,如果是 flv,那么 Demuxer 就会使用对应的 ff_flv_demuxer,所以对应的关键生命周期的方法 read_header、read_packet、read_seek、read_close 都会使用该 flv的 Demuxer 中函数指针指定的函数。read_header 函数会将 AVStream 结构体构造好,以便后续的步骤继续使用 AVStream 作为输入参数。