ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

F´框架 Ref 部署中的 SendBuffApp 数据缓冲发送组件:从 FPP 建模到系统级验证

F´框架 Ref 部署中的 SendBuffApp 数据缓冲发送组件:从 FPP 建模到系统级验证 嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fpri/fprime点击查看免费下载导读本文以 F´F Prime飞行软件框架 Ref 参考部署中的Ref::SendBuffApp组件设计文档sdd.md为核心完整讲解该演示组件的职责、建模定义、命令/遥测/参数接口、数据发送与错误注入的实现原理并结合仓库源码给出其在Ref拓扑中的真实连接关系与验证方式。读完本文你将掌握 F´ 组件 SDD 的阅读方法、FPP 模型到 C 实现的对应关系以及如何利用该组件演示数据缓冲传递、校验和错误注入、FATAL/ASSERT 故障注入等飞行软件调试技巧。1. 组件定位与设计需求Ref::SendBuffApp是 F´ 框架 Ref 参考部署Ref/中用于演示数据缓冲data buffer发送的组件。按照其 SDD 第 1 节的说明它的职责是向Ref::RecvBuffApp发送数据缓冲两者成对出现构成一条完整的缓冲收发、校验和验证的演示链路Ref::SendBuffApp发送方周期性构造数据缓冲并送出Ref::RecvBuffApp接收方接收缓冲、计算校验和并报告结果。SDD 第 2 节给出了该组件的两条系统级需求需求编号描述验证方法ISF-RBF-001Ref::SendBuffApp组件应能发送缓冲System testISF-RBF-002Ref::SendBuffApp组件应提供错误注入能力System test其中错误注入是飞行软件调试中的关键能力——它允许在链路中人为制造坏包用于验证接收端RecvBuffApp的校验和检测逻辑以及地面系统的故障上报能力。2. 组件建模SendBuffApp.fppF´ 从 3.0 开始使用 FPPF´ Prime Parser语言描述组件。Ref::SendBuffApp的完整建模定义位于 Ref/SendBuffApp/SendBuffApp.fpp组件类型声明为module Ref { queued component SendBuff { ... } }它被建模为queued component队列组件与 passive 组件不同queued 组件自带消息队列命令等异步消息会入队后由内部处理循环分发无需外部线程周期驱动相比之下同链路的RecvBuff在 Ref/RecvBuffApp/RecvBuffApp.fpp 中被建模为 passive component。2.1 状态枚举与端口组件定义了发送状态枚举enum ActiveState { SEND_IDLE SEND_ACTIVE }通用端口部分 The rate group scheduler input sync input port SchedIn: Svc.Sched The data buffer output output port Data: Drv.DataBufferSchedIn同步调度输入端口由速率组Rate Group周期触发DataDrv::DataBuffer类型的数据缓冲输出端口是整条演示链路的出口。此外还声明了 F´ 组件的全套特殊端口命令接收/注册/响应CmdDisp/CmdReg/CmdStatus、事件与文本事件Log/LogText、时间获取Time、遥测Tlm、参数读写ParamGet/ParamSet。这些端口在 F´ 中属于标准模式由 FPP 自动代码生成器Autocoder在编译期展开。2.2 命令定义组件共定义 4 条命令对应 SDD 需求中发送缓冲与错误注入两大能力命令Opcode参数作用SB_START_PKTS0无启动数据包发送SB_INJECT_PKT_ERROR1无在下一个数据包中注入错误SB_GEN_FATAL2arg1~arg3: U32产生一条 FATAL 级事件EVRSB_GEN_ASSERT3arg1~arg6: U32触发一次 ASSERT 断言失败其中SB_GEN_FATAL与SB_GEN_ASSERT专用于演示 F´ 的故障处理机制FATAL 事件会沿FatalAnnounce - fatalHandler链路触发 FatalHandler 复位动作而 ASSERT 则直接调用FW_ASSERT触发断言处理器。这两条命令是验证地面故障注入与 F´ 故障保护Fault Protection机制的便捷工具。2.3 事件、遥测与参数事件EVR定义event FirstPacketSent($id: U32) severity activity high id 0 format First packet ID {} received event PacketErrorInserted($id: U32) severity warning high id 1 format Inserted error in packet ID {} event BuffSendParameterUpdated($id: U32) severity activity low id 2 event SendBuffFatal(arg1, arg2, arg3: U32) severity fatal id 3遥测通道Telemetry通道类型含义PacketsSentU64已发送数据包总数NumErrorsInjectedU32已注入错误次数update on changeParameter3U8参数 3 回读update on changeParameter4F32参数 4 回读update on changeSendStateActiveState当前发送状态SEND_IDLE / SEND_ACTIVE参数定义演示用测试参数param parameter3: U8 default 12 id 0 set opcode 10 save opcode 11 param parameter4: F32 default 13.14 id 1 set opcode 12 save opcode 13两个参数均带独立的 set/save 命令 opcodeset opcode用于地面设置参数值save opcode用于将当前值持久化到参数数据库由 Svc.PrmDb 管理属于 F´ 标准参数服务模式。3. 实现原理SendBuffComponentImpl组件实现位于 Ref/SendBuffApp/SendBuffComponentImpl.hpp 与 Ref/SendBuffApp/SendBuffComponentImpl.cpp。类SendBuffImpl继承自动生成的基类SendBuffComponentBase内部维护如下状态U32 m_invocations; // 调度器调用次数 U32 m_buffsSent; // 已发送缓冲数 U32 m_errorsInjected; // 已注入错误数 bool m_injectError; // 下一包注入错误标志 bool m_sendPackets; // 是否处于发送状态 U32 m_currPacketId; // 当前包 ID bool m_firstPacketSent; Drv::DataBuffer m_testBuff; // 待发送缓冲 SendBuff_ActiveState m_state;3.1 调度处理SchedIn_handler核心发送逻辑在SchedIn_handlerSendBuffComponentImpl.cpp中每次由速率组调度触发先排空队列while (MSG_DISPATCH_OK stat) { stat this-doDispatch(); }循环处理组件队列中积压的异步消息并断言处理无错误若m_sendPackets为真则若是首个数据包发出FirstPacketSent事件并写入NumErrorsInjected遥测重置缓冲m_testBuff.resetSer()串行化当前包 IDm_currPacketId更新PacketsSent遥测构造 24 字节测试数据testData[24]初始化为0xFF计算校验和对 24 字节逐字节求和得到csum若m_injectError为真清零testData[5]、递增错误计数并发出PacketErrorInserted事件——这正好制造一个校验和不匹配的坏包依次串行化数据与校验和最后通过输出端口发送this-Data_out(0, this-m_testBuff);更新调用计数与SendState遥测。3.2 命令处理四条命令处理器与 FPP 定义一一对应SB_START_PKTS_cmdHandler置m_sendPackets true、状态切为SEND_ACTIVE响应Fw::CmdResponse::OKSB_INJECT_PKT_ERROR_cmdHandler置m_injectError true下一个调度周期即注入错误SB_GEN_FATAL_cmdHandler调用log_FATAL_SendBuffFatal(arg1, arg2, arg3)产生 FATAL 事件SB_GEN_ASSERT_cmdHandler直接FW_ASSERT(0, arg1, ..., arg6)触发断言失败SendBuffComponentImpl.cpp可用于验证 F´ 的断言处理器Svc.AssertFatalAdapter与 FatalHandler 复位链路。3.3 参数更新parameterUpdated(FwPrmIdType id)在参数变化时被回调发出BuffSendParameterUpdated事件并将新值写回对应遥测通道Parameter3/Parameter4未识别的参数 ID 会触发断言。3.4 组件装配Ref/SendBuffApp/SendBuff.hpp 将实现类封装为对外类型namespace Ref { typedef SendBuffImpl SendBuff; }构建脚本 Ref/SendBuffApp/CMakeLists.txt 将 FPP 模型与实现源文件注册进 F´ 模块体系set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/SendBuffApp.fpp ${CMAKE_CURRENT_LIST_DIR}/SendBuffComponentImpl.cpp ) register_fprime_module()编译时由 Autocoder 根据SendBuffApp.fpp自动生成SendBuffComponentAc.*组件基类、命令/事件/遥测/参数骨架代码。4. 组件框图SDD 第 3.1.1 节给出了组件的 SysML 块定义图BDD清晰地标注了该组件全部对外端口及方向从图中可以看出左侧命令相关端口CmdDisp/CmdReg/CmdStatus与事件端口Log/LogText上侧参数读写端口ParamGet/ParamSet右侧核心数据通路——同步调度输入SchedIn外部触发与数据缓冲输出Data背离组件下侧遥测端口Tlm与时间获取端口Time。5. 在 Ref 拓扑中的真实连接组件实例在 Ref/Top/instances.fpp 中定义instance sendBuffComp: Ref.SendBuff base id 0x2600 \ queue size Default.QUEUE_SIZE对应基地址0x2600采用 Ref 默认队列深度QUEUE_SIZE 10。与之配对的接收端为instance recvBuffComp: Ref.RecvBuff base id 0x4700在 Ref/Top/topology.fpp 中sendBuffComp被接入两条关键链路速率组调度每周期驱动发送rateGroup2Comp.RateGroupMemberOut[1] - sendBuffComp.SchedIn缓冲数据通路经 BlockDriver 回环到接收端connections Ref { sendBuffComp.Data - blockDrv.BufferIn blockDrv.BufferOut - recvBuffComp.Data }即完整演示链路为rateGroup2Comp →(SchedIn)→ sendBuffComp →(Data)→ blockDrv.BufferIn ↓ (BufferOut) recvBuffComp.DataDrv.BlockDriverDrv/BlockDriver/BlockDriver.fpp在这里扮演通信驱动角色其BufferIn_handler只是简单透传BlockDriverImpl.cpp 中this-BufferOut_out(0, buffer);将SendBuff送出的缓冲原样转交给RecvBuff。6. 接收端闭环验证RecvBuffAppRef::RecvBuffApp的 SDDRef/RecvBuffApp/docs/sdd.md给出配套需求需求编号描述验证方法ISF-SBF-001Ref::RecvBuffApp组件应能接收缓冲System testISF-SBF-002Ref::RecvBuffApp组件应能检测接收缓冲中的错误System test其接收处理逻辑在 Ref/RecvBuffApp/RecvBuffComponentImpl.cpp 中重置反序列化游标依次读出包 ID、24 字节测试数据与校验和首个数据包触发FirstPacketReceived事件独立重算校验和逐字节求和与收到的csum比较不一致时递增错误计数、发出PacketChecksumError事件、将PacketRecvStatus置为PACKET_STATE_ERRORS更新Sensor1/Sensor2/PktState遥测。由此发送端的SB_INJECT_PKT_ERROR注入的坏包会在此被检出形成发送注入 → 接收检测 → 事件/遥测上报的完整验证闭环正是 SDD 两条系统级需求的落地体现。接收端还定义了PacketStat结构体遥测与带红/黄告警限值-3/-2/-1 与 3/2/1的Parameter2通道用于演示 F´ 的遥测告警分级能力。7. 使用与验证方式7.1 构建与运行在 Ref 部署目录按 F´ 标准流程构建并运行参考 docs/INSTALL.md 的安装说明# 在 Ref 目录下配置并构建 cd Ref fprime-util generate fprime-util build fprime-util run # 运行 Ref 部署系统启动后rateGroup2Comp会周期性驱动sendBuffComp发送数据包可在地面系统如 F´ GDS中观察PacketsSent遥测持续递增并收到FirstPacketSent事件。7.2 地面命令演练通过 GDS 命令发送面板依次执行ref.SendBuff.SB_START_PKTS开始周期发送SendState遥测变为SEND_ACTIVEref.SendBuff.SB_INJECT_PKT_ERROR注入一个坏包随后可观察到接收端RecvBuff的PacketChecksumError事件与PktState遥测进入PACKET_STATE_ERRORS状态ref.SendBuff.SB_GEN_FATAL(1,2,3)产生 FATAL 事件触发FatalAnnounce - fatalHandler故障保护链路ref.SendBuff.SB_GEN_ASSERT(1,2,3,4,5,6)触发断言失败用于验证断言处理与系统复位行为。7.3 参数与遥测检查使用parameter3默认 12与parameter4默认 13.14的 set/save 命令修改参数可在BuffSendParameterUpdated事件与Parameter3/Parameter4遥测回读中确认更新生效关注NumErrorsInjectedupdate on change遥测可与接收端错误计数对照验证端到端错误注入计数一致。7.4 需求验证结论Ref::SendBuffApp的两条需求可通过系统测试验证ISF-RBF-001发送缓冲由SB_START_PKTS命令开启周期发送PacketsSent遥测递增、接收端收到数据包即证明发送功能正常ISF-RBF-002错误注入由SB_INJECT_PKT_ERROR命令注入坏包接收端PacketChecksumError事件与PACKET_STATE_ERRORS状态即证明错误注入与检测链路有效。8. 小结Ref::SendBuffApp是理解 F´ 组件化开发流程的理想范例一份 SendBuffApp.fpp 模型文件统一定义了命令、事件、遥测与参数Autocoder 自动生成骨架开发者只需在SendBuffImpl中填充调度处理与命令处理逻辑。结合配套的RecvBuffApp接收端与BlockDriver透传驱动它完整演示了 F´ 中速率组调度 → 数据缓冲发送 → 校验和检测 → 事件/遥测上报 → 错误注入验证的端到端数据通路并提供了 FATAL/ASSERT 两类故障注入手段是学习 F´ 数据流与故障处理机制的绝佳参考实现。赞分享嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fpri/fprime点击查看免费下载相关推荐F´ 框架 Ref::SendBuffApp 组件详解基于 FPP 的数据缓冲发送与错误注入演示F´ 框架 Ref::SendBuffApp 组件详解基于 FPP 的数据缓冲发送与错误注入演示 Ref::SendBuffApp 是 F´Flight S嵌入式系统编程F´ 框架 Ref 部署演示组件剖析SendBuffApp 缓冲区发送与错误注入机制F´ 框架 Ref 部署演示组件剖析SendBuffApp 缓冲区发送与错误注入机制 Ref::SendBuffApp 是 F´F Prime飞行软件框架嵌入式系统编程F´ 框架 Ref 部署中的 RecvBuffApp 数据缓冲接收组件详解F´ 框架 Ref 部署中的 RecvBuffApp 数据缓冲接收组件详解 Ref::RecvBuffApp 是 F´F Prime飞行软件与嵌入式系统框架嵌入式系统编程上一篇ML为C开发者量身定制的机器学习库下一篇Audacity AI音频效果完全指南从新手到专家的智能音频处理创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表