Zephyr Ticker 介绍

在Zephyr bluetooth controller中，每一个procedure 要想拿到Radio去收发数据，必须要闯过两道关卡：ULL层的Ticker和LLL层的Prepare, 本文主要介绍Ticker的部分。

Ticker 负责仲裁Link Layer中各个procedure对RF资源的申请，用定义好的Rule来保证这些procedure都能被童叟无欺的执行到。
但实际上这个module是个完全独立的module，跟蓝牙的行为没有什么关系，也可以拿来做他用。
在Ticker里有三大角色：

• Node：是Ticker的调度单元，里面的关键信息是到期时间（ticks_to_expire）及申请占用RF的时间(ticks_slot)。

• User：是Node的用户，总共有4个，从字面意思看是跟优先级相关，但实际上没有优先级的概念。

  #define TICKER_USER_ID_LLL       MAYFLY_CALL_ID_0 
  #define TICKER_USER_ID_ULL_HIGH  MAYFLY_CALL_ID_1 
  #define TICKER_USER_ID_ULL_LOW   MAYFLY_CALL_ID_2  
  #define TICKER_USER_ID_THREAD    MAYFLY_CALL_ID_PROGRAM

• User Operation：User希望要做的操作。

  #define TICKER_USER_OP_TYPE_NONE         0
  #define TICKER_USER_OP_TYPE_IDLE_GET     1
  #define TICKER_USER_OP_TYPE_SLOT_GET     2
  #define TICKER_USER_OP_TYPE_PRIORITY_SET 3
  #define TICKER_USER_OP_TYPE_START        4
  #define TICKER_USER_OP_TYPE_UPDATE       5
  #define TICKER_USER_OP_TYPE_YIELD_ABS    6
  #define TICKER_USER_OP_TYPE_STOP         7
  #define TICKER_USER_OP_TYPE_STOP_ABS     8

这三者的关系，我们用下面的图形来举例：

• 带箭头的蓝色横线是一个时间线，展现已经处于scheduled状态的所有节点的先后关系，这些节点等着他们的expiry时间到后，就可以执行他们的expiry callback函数，完成一个轮回。
• ticks_current是所有还未到期的节点的一绝对参考时间，第一个节点的expiry时间expiry1是相对于ticks_current，后面每个节点的expiry时间都是相对于前一个节点的expiry时间。
• 地标所指处为当前时间，可见当前的节点都还未过期。
• 蓝色Node #4 为待插入的节点，看起来他的slot有跟节点 #2 冲突。虽然#4 的ticks_slot有跟#2 的expiry时间冲突，但还是会插入成功。在#4 的expiry时间到期的时候才会做冲突处理，确定#2和#4 到底谁优先。

在理解Ticker所有时间相关的变量的时候，一定要注意该时间是绝对时间还是相对时间，如果是相对时间，是相对于谁，只要搞清楚这个，基本上能理解整个流程。

• 所有Node放在一个大数组里，由两个指针ticker_id_head 和insert_head来管理他们之间的关系。
  • ticker_id_head 把所有可以被scheduled的Node（橘色）都串起来，这个list可以叫做scheduled list，第一个节点的expiry时间会送到RTC timer里，timer到期后就开始执行这个节点的callback。
  • insert_head把所有待定的要进入sheduled list的节点（蓝色）串起来。这些节点会被 ticker_job_list_insert() 逐个插入到scheduled list，交由thread_id_head统领。

两个关键函数 相互配合完成调度

• ticker_job() 的目的是把所有希望得到调度的节点都欢送到Scheduled list里，它的操作对象有三个：
  • 用ticker_job_list_manage() 处理所有User的所有的OP中的Update 和 Stop 操作.
  • 用ticker_job_worker_bh() 处理Scheduled list中所有的过期节点，这些节点可能还需要再进入Scheduled list中, ticker_work()不会判定已经expiry 的节点是否要再次进入Scheduled list中，是交由该函数处理，从函数名也能初见端倪，bh表示bottom half，就是后半部分，是ticker_worker的后半部分。
  • 用ticker_job_list_insert()函数处理所有User的所有的operation中的START操作以及 Insert_head中的节点，这些节点是由前两步的操作带入的。
  • 如果ticker_id_head有变，就重新把新的expiry时间设置到RTC。

flowchart TD
    A[start] -->B(ticker_job_list_manage)
    B --> C{flag_elapsed}
    C -->|Yes| D[ticker_job_worker_bh]
    D --> E[ticker_job_list_insert]
    C --> |No| E
    E --> F{ticker_id_head changes?}
    F --> |Yes| G[ticker_job_compare_update]
    F --> |No| H
    G --> H[Schedule job_worker]
    H --> I[End]

• ticker_worker() 目的是执行ticker_id_head 指向的节点的expiry callback，至于该Node要不要再次进入scheduled List，这里不管。在Node 插入schedule List的时候并不会针对ticks_slot做冲突检测，这样的话必须在这个函数里执行的时候做冲突检测，会影响执行效能。
  

  graph TD
  A[Start] --> B(Calculate ticks_elapsed)
  B --> C{NextNode?}
  C -->|Yes| D{Expiry?}
  C -->|No| Job
  D -->|Yes| State{state == 0}
  D -->|No| Job
  State -->|Yes| Collide[ticker_resolve_collision]
  State -->|No| C
  Collide -->IsWin[Win?]
  IsWin -->|Yes| Callback[timeout_callback]
  IsWin -->|No| Skip_check[Skip?]
  Skip_check -->|Yes|C
  Skip_check -->|No|SetAsShallowExpiry
  SetAsShallowExpiry -->Callback
  Callback --> Job
  Job[Schedule a ticker_job]
  Job --> End
  End[End]

  
  为了解决在执行callback的时候才做冲突出来带来的效率问题，有了另外一个版本（
  CONFIG_BT_TICKER_LOW_LAT）的ticker_job_list_insert() 函数，该)函数会将insert_head里所有的节点尝试加入ticker_id_head，在加入的过程中，会有一些冲突处理机制如下图：
• 特别注意Node #5 是没有slot的，它不占用RF，即使它的expiry时间被 #7 overlap到，但它跟#7并不冲突。

ticker_job_enqueue() 中的冲突处理：

Ticker中各个Compile option的作用：

• CONFIG_BT_TICKER_EXT：多了一个 ticks_slot_window，Adv对expiry的时间不需要严格精确，那么就把它的expiry时间前后稍微挪动下，如果能避免冲突，那它就能得到更早的执行。
• CONFIG_BT_TICKER_SLOT_AGNOSTIC：每个node都没有ticks_slot，完全把ticker拿来当timer来用，可以用一个RTC的HW timer来模拟多个SW timer；
• CONFIG_BT_TICKER_LOW_LAT：在Node进入schedule list时做collision 处理，而不是在expiry的时候。

几个问题：

1. 假如某种原因，ticker_worker() 被耽误了，导致一次timeout，有好几个node的callback都被执行到了，那这些callback都要吃RF，他们之间的冲突又是怎么解决？
2. Shallow Expiry时，Node 无论如何都要expiry，冲突时在那里解决的？