Thread 中讨论的其他器件: WL1835
您好!
我尝试了解 WiLink 8时间同步应如何与 BeagleBoneBlack 上的 StreamUnlimited Multiroom Cape 配合使用。
查看中的补丁
git.ti.com/.../commit
id=4a10364537b4798fde51afc7f28026d58a017e71&dt=2
并与 Build-utilites WiLink 8代码配合使用
逻辑似乎如下所示:
通过写入/sys/kernel/debug/ieee80211/phy0/wlcore/wl18xx/time_sync、时间同步间隔设置为 n 毫秒、从而在步骤1中触发 GPIO 输出。
1。每 n 毫秒、GPIO 引脚66 (连接到 WL1835 SYNC 引脚的 GPIO2_2)就会由 wlcore_trigger_time_sync 发出脉冲信号、告知 WL1835MOD 固件发送事件。 脉冲 GPIO 的时间记录在 WL->TIME_SYNC.GPIO_KTIME 中
一段时间后、WL1835MOD 中断和中断服务例程最终会调用 wl18xx_process_mailbox_events、其中包含 AP 64位 TSF 时间的 time_sync_event_ID 事件。
这反过来又调用 wlcore_event_time_sync ()、它记录事件、包括64位 clock_high 和 clock_low 、并调度另一个 GPIO 触发计时器。
4.由此产生的有趣数据是接入点 TSF 与 GPIO 触发器内核时间之间的差异。 但是、这只有在捕获的 TSF 时间与 GPIO 触发器的时刻(或处于不确定的时间段)相同时才有用。
我的问题是:
在项目1和2之间、发生了什么以及需要多长时间? WiLink 芯片是否等待下一个信标、然后触发 TIME_SYNC_EVENT_ID 中断? 如果是、如何计算间隔时间周期。 或者、WiLink 可能会立即触发 TIME_SYNC_EVENT_ID 中断、发送接入点 TSF 的芯片当前想法(这需要它跟踪 TSF 自_LAST_信标以来的时间。
虽然64位 TSF 被记录并且 GPIO 信号的内核时间被存储在 WL->TIME_SYNC.GPIO_KTIME 中、但是补丁代码对这些数字没有任何作用。 这是不是留给执行者的练习?
3.该贴片随后被撤回。 为什么?
4.我看到了其他用于实现内核文件/sys/kernel/debug/ieee80211/phy0/wlcore/wl18xx/time_sync_zone_addr 的补丁、这些补丁将 MAC 地址发送到 WL1835MOD。 是否也需要这样做才能使时间同步发挥作用?
希望您能提供帮助
谢谢。