esp32基于Arduino框架的freertos使用——定时器xTimerCreate
开发平台：vscode+platformIO 框架：arduino 开发板：esp32-wroom-32
API参考文档：https://www.freertos.org/a00106.html
定时器：xTimerCreate() 创建一个新的软件计时器实例并返回一个可以引用计时器的句柄
开启定时器：xTimerStart() 创建实例之后需要启用。
如果立刻激活，则不用阻塞10个tick，直接返回pdPASS，如果任务队列已满，没有立刻激活，则在此处阻塞10个tick等待激活。10个tick后如果任务激活，则返回pdPASS，若没有激活，则返回pdFAIL。（当然这个只是我自己通俗的理解）
真实详细可以去韦东山老师的网站：http://rtos.100ask.net/freeRTOS%E6%95%99%E7%A8%8B/index.html
这里需要注意定时回调函数传参需要指定为void *Parameter，否则会报错。回调函数可以使用简单的IO操作，可以进行运算。不应该使用阻塞函数。
下面这么写就会报错，这两个函数只是同名的函数。
在其他地方可以使用xTimerIsTimerActive()方法去判断某个定时器是否启用
自己的心得：
使用定时器的初衷是可以实现一些复杂的定时任务，但是实际上使用xTimerStart得到的实例只能处理一些简单的任务，IO，数据的运算，当我尝试在定时器中刷新IIC屏幕时，干脆整个回调函数直接就不执行了。而使用Ticker库的方法同样可以使用定时器，但是限制上没有这么多。
定时任务的规则其实是按照绝对时间来启用任务的，但是如果回调函数运行时长超时，也会一直运行到正常结束。这样子程序是稳定了，但是会不会按照意愿进行就不能保证了。
举个例子：如下图所示：定时任务50ms执行一次，但是任务执行20ms。这是非常复合预期的结果。事实上就是每50ms运行一次。如果任务执行时间为80ms。则在50ms时任务就会变为就绪状态。80ms任务执行完成，则会直接再次执行任务。
这么看来，其实多任务时，单纯的使用定时器，很有可能造成一些不可估量的后果。如果存在两个任务都定时为50ms，但是运行时间都是30ms。则会出现两个任务每30ms交替运行一次。一次循环就是60ms。和预期的50ms出现了不符。如果再极端一点，任务执行时间为100ms，则一次循环就是200ms，若任务优先级不一样，则时间一直会被高优先级的任务独占，低优先级的无法运行。
定时任务不会被另一个定时任务打断，运行时间过长可能会导致运行不按照预期进行。一些简单的任务直接使用Ticker库其实蛮不错的。起码比xTimerCrate来说容量更大。
