嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fpri/fprime点击查看免费下载导读F´F Prime是一个面向飞行软件与嵌入式系统的开源框架。本文以仓库根目录的 CHANGELOG.md 为主线系统梳理 F´ 从 1.0 到 3.0 的关键演进脉络并重点围绕 3.0.0 版本的破坏性变更展开FPP 建模语言迁移、Topology 模块与可执行文件分离、内联枚举废止与符号重命名、CMake 选项重构、Os::TaskAPI 变更以及 2.0.0 引入的新地面链路组件族。读完本文你将掌握从旧版本 F´ 迁移到 3.x 的完整操作清单、编译期错误定位方法以及新框架各核心模块Svc::Framer、Drv::ByteStreamDriverModel、Svc::FileDownlink等的正确使用方式。版本演进总览CHANGELOG 勾勒的框架迭代主线CHANGELOG.md 记录了 F´ 从开源初始版本到 3.0.0 的完整发布历史其核心演进可归纳为四个方向构建系统现代化从 1.2 引入 CMake 原型构建系统cmake 文档到 1.3/1.4 完善fprime-util辅助脚本、支持独立项目与 Baremetal 编译再到 1.5 引入settings.ini实现框架源码与项目解耦。地面系统GDS重构1.2 将 Gse 重构并更名为 Gds1.4 加入文件上行/下行与多窗口支持1.5 提供 CLI 原型与自定义面板2.0 则彻底重构成了Svc::Framer/Svc::Deframer/Drv::ByteStreamDriverModel组合。组件能力扩充1.2 增加 UdpSender/UdpReceiver1.4 升级 MemAllocator 接口2.0 新增 TcpClient/TcpServer/Udp 驱动与 GenericHub3.0 全面切换到 FPP 建模语言与 C11。平台支持策略2.0.1 修复 VxWorks 6 编译问题并成为该平台最后的支持版本2.1.0 则是 F´ 2.x 系列的收官版本专供无法升级到 C11 或无法采用 FPP 的项目使用。其中 3.0.0 是一次具有破坏性的主版本升级官方要求用户迁移前务必阅读 v3 迁移指南。后续章节按迁移工作流逐一展开。迁移第 1 步建模语言从 XML 切换到 FPPF´ 3.0.0 最根本的架构变化是将组件、端口、拓扑的建模基线从 F´ XML 格式切换为FPPF´ Prime Parser建模语言。这一决定直接体现在仓库中大量以.fpp结尾的模型文件上例如端口与类型模型Fw/Cmd/Cmd.fpp、Fw/Tlm/Tlm.fpp、Fw/Log/Log.fpp组件模型Svc/ActiveLogger/ActiveLogger.fpp、Svc/BufferManager/BufferManager.fpp拓扑模型Ref/Top/topology.fpp、Ref/Top/instances.fpp参考部署组件Ref/PingReceiver/PingReceiver.fpp、RPI/RpiDemo/RpiDemo.fpp迁移要点如下组件层XML 建模的组件在 3.0 中仍可继续使用但官方明确表示 XML 格式不会再获得特性增强推荐逐步转换为 FPP。拓扑层关键限制如果一个拓扑希望改用 FPP 建模那么该拓扑引用的所有组件也必须以 FPP 建模反过来XML 拓扑可以同时混用 XML 组件和 FPP 组件。这意味着项目可以自底向上渐进迁移——先转换单个组件最后再切换整个拓扑。转换工具FPP 工具套件提供了fpp-from-xml命令可自动将 XML 模型转换为 FPP 模型显著降低手工改写成本。FPP 语言的完整语法与工具链说明见 FPP 用户指南。从源码结构看FPP 模型与自动生成代码形成了固定配对每个组件目录下同时存在.fpp模型与手写的ComponentImpl.cpp/.hpp实现文件如 Ref/SignalGen/SignalGen.cpp构建时由 CMake 自动调用 FPP 编译器生成ComponentBase骨架代码。迁移第 2 步Topology 模块与可执行文件解耦在旧版本 F´ 中部署Deployment的拓扑没有与可执行文件、入口点代码分离这限制了构建的灵活性。3.0.0 强制要求两者分离并引入register_fprime_deployment()宏。以仓库中的 Ref 参考部署为实例改造分两步第一步Deployment/Top/CMakeLists.txt改为模块注册将拓扑目录从可执行目标改为模块目标从SOURCE_FILES中移除入口点代码如Main.cpp把register_fprime_executable()替换为register_fprime_module()。当前仓库中 Ref/Top/CMakeLists.txt 的完整形态即迁移后的结果set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/instances.fpp ${CMAKE_CURRENT_LIST_DIR}/RefPackets.xml ${CMAKE_CURRENT_LIST_DIR}/topology.fpp ${CMAKE_CURRENT_LIST_DIR}/RefTopology.cpp ) set(MOD_DEPS Fw/Logger Svc/LinuxTime # Communication Implementations Drv/Udp Drv/TcpClient ) register_fprime_module()这里MOD_DEPS声明了拓扑模块对 F´ 核心模块的依赖本例包含日志、Linux 时间、UDP 与 TCP 客户端通信实现构建系统会据此正确排序模块编译顺序。第二步Deployment/CMakeLists.txt注册部署可执行文件在部署根目录的 Ref/CMakeLists.txt 中将入口点源文件单独列入SOURCE_FILES通过MOD_DEPS指定对拓扑模块的依赖最后调用register_fprime_deployment()add_fprime_subdirectory(${CMAKE_CURRENT_LIST_DIR}/Top/) set(SOURCE_FILES ${CMAKE_CURRENT_LIST_DIR}/Main.cpp) set(MOD_DEPS ${PROJECT_NAME}/Top) register_fprime_deployment() # 仅对部署可执行文件生效的编译选项-Wall -Wextra -Werror 等 set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11)其中set_property(... CXX_STANDARD 11)与 3.0 全面采用 C11 的决策直接对应——框架核心代码已按 C11 标准编写自定义组件也应保持相同标准。部署级的编译选项如-Wall -Wconversion等只作用于可执行目标避免框架核心代码受额外告警干扰。迁移第 3 步废止内联枚举改用标准枚举模型与符号重命名3.0.0 不再支持组件内定义的内联枚举inline enumeration项目必须将枚举提取为独立的枚举模型并作为命令、事件、遥测通道的参数类型使用。这带来了一批用户可见符号的重命名。3.1 最典型的例子命令响应枚举以 Ref 部署的 SignalGen 信号发生器组件为例命令处理器中向命令分发器回复执行结果的调用在 v2 中写作this-cmdResponse_out(opCode, cmdSeq, Fw::COMMAND_OK);v3 中必须改为this-cmdResponse_out(opCode, cmdSeq, Fw::CmdResponse::OK);当前 Ref/SignalGen/SignalGen.cpp 中的三个命令处理器SignalGen_Settings_cmdHandler、SignalGen_Toggle_cmdHandler、SignalGen_Skip_cmdHandler均已采用Fw::CmdResponse::OK的新写法。这一枚举的语义定义见 Fw/Cmd/Cmd.fppenum CmdResponse { OK 0 Command successfully executed INVALID_OPCODE 1 Invalid opcode dispatched VALIDATION_ERROR 2 Command failed validation FORMAT_ERROR 3 Command failed to deserialize EXECUTION_ERROR 4 Command had execution error BUSY 5 Component busy }可见从全局散落宏Fw::COMMAND_*到命名空间内枚举Fw::CmdResponse::*的转变本质上是 FPP 枚举模型自动生成的类型化符号取代了手工宏常量这也让参数校验与序列化代码由自动编码器统一生成。3.2 用户必须手动更新的枚举符号对照表迁移指南给出了下列必须手动更新的用户可见枚举凡是在命令、事件、遥测或参数代码中引用这些旧符号的地方都要逐一替换旧符号新符号Fw::COMMAND_OKFw::CmdResponse::OKFw::COMMAND_INVALID_OPCODEFw::CmdResponse::INVALID_OPCODEFw::COMMAND_VALIDATION_ERRORFw::CmdResponse::VALIDATION_ERRORFw::COMMAND_FORMAT_ERRORFw::CmdResponse::FORMAT_ERRORFw::COMMAND_EXECUTION_ERRORFw::CmdResponse::EXECUTION_ERRORFw::COMMAND_BUSYFw::CmdResponse::BUSYFw::PARAM_UNINITFw::ParamValid::UNINITFw::PARAM_VALIDFw::ParamValid::VALIDFw::PARAM_INVALIDFw::ParamValid::INVALIDFw::PARAM_DEFAULTFw::ParamValid::DEFAULT仓库中 Fw/Cmd/changed-symbols.txt 记录了命令响应枚举的变更对照docs/UsersGuide/dev/v3-renamed-symbols.md 则给出了完整的重命名清单。该清单涵盖的范畴远超上表例如驱动层状态Drv::POLL_OK→Drv::PollStatus::POLL_OK、Drv::RECV_OK→Drv::RecvStatus::RECV_OK、Drv::SEND_OK→Drv::SendStatus::SEND_OK日志严重级别Fw::LOG_FATAL→Fw::LogSeverity::FATAL、Fw::TEXT_LOG_WARNING_HI→Fw::LogSeverity::WARNING_HI健康检查Svc::HealthComponentBase::HealthEnabled→Fw::Enabled、HLTH_CHK_DISABLED→Fw::Enabled::DISABLED组件自定义枚举Svc::CmdSequencerComponentBase::SeqMode→Svc::CmdSequencer_SeqMode、Svc::BufferLoggerComponentBase::LogState→Svc::BufferLogger_LogState迁移策略建议由于大部分枚举被封装在自动编码层autocoded layer内用户通常只需关注命令分发、参数服务、日志过滤等直接暴露给实现代码的枚举。建议在迁移时全文搜索Fw::COMMAND_、Fw::PARAM_、Fw::LOG_、Drv::POLL_、Drv::RECV_、Drv::SEND_等旧前缀逐一核对。迁移第 4 步CMake 选项与构建流程重构3.0.0 将fprime-util generate的命令行选项与 CMake 标准变量用法对齐变更点如下CMAKE_BUILD_TYPE不再用于标识单元测试构建用户现在可以自由覆盖该变量任何根据该变量判断是否生成 UT的旧逻辑都必须移除。BUILD_TESTING成为单元测试开关置为ON/OFF控制是否构建单元测试。项目代码中需用if (BUILD_TESTING)检测测试构建在fprime-util侧则由--ut开关控制。CMAKE_INSTALL_PREFIX决定构建产物输出位置如build-artifacts目录这与标准 CMake 安装模式保持一致。2.0 起字典、二进制等构建产物统一写入部署的build_artifacts目录3.0 进一步将该目录与安装前缀挂钩。对大多数用户而言fprime-util会自动设置这些变量无需手工干预只有需要自定义构建布局例如定制安装前缀或调试构建类型时才直接设置CMAKE_INSTALL_PREFIX与CMAKE_BUILD_TYPE。同时CHANGELOG 提示了工具链安装方式的变更F´ 工具fprime-util 与 fprime-gds应统一通过pip install fprime-tools fprime-gds安装。旧参数形态fprime-util generate --ut -DFPRIME_ENABLE_FRAMEWORK_UTSOFF已被标记为废弃将在未来被fprime-util check的变体取代。迁移第 5 步Os::Task启动 API 变更FPP 拓扑会自动生成启动活动组件的样板代码但手工创建Os::Task或运行 XML 拓扑需要自行启动任务的用户必须适配Os::Task::start与ActiveComponent::start的新签名。从 Os/Task.hpp 源码可见v3 的start方法签名如下TaskStatus start( const Fw::StringBase name, taskRoutine routine, void* arg, NATIVE_UINT_TYPE priority TASK_DEFAULT, NATIVE_UINT_TYPE stackSize TASK_DEFAULT, NATIVE_UINT_TYPE cpuAffinity TASK_DEFAULT, NATIVE_UINT_TYPE identifier TASK_DEFAULT);参数顺序为名称、任务例程、参数、优先级、栈大小、CPU 亲和性、标识符全部为无符号整数且带默认值因此调用方可只传必填的三项。在 Posix 系统上内核会尽量按请求值设置若无相应权限则回退到默认的 pthreads 配置。旧版本 API 采用了(name, identifier, priority, stackSize, routine, arg, cpuAffinity)的参数顺序已被标记为DEPRECATED见 Os/Task.hpp 的DEPRECATED宏标注继续调用旧签名会直接产生编译期错误——这正是迁移中常见的编译失败来源。Drv/Ip/SocketReadTask.cpp 提供了新 API 的典型用法Os::Task::TaskStatus stat m_task.start(name, SocketReadTask::readTask, this, priority, stack, cpuAffinity); FW_ASSERT(Os::Task::TASK_OK stat, static_castNATIVE_INT_TYPE(stat));即依次传入任务名、入口函数指针、上下文参数、优先级、栈大小与 CPU 亲和性随后用断言检查启动状态。该文件同时展示了 v3 任务编程的配套模式通过m_stop标志与 socketclose()配合在循环中执行重连 → recv → 回调sendBuffer的读取流程。2.0.0 的破坏性变更地面链路重构与驱动模型统一虽然 3.0.0 是主版本升级但 2.0.0 同样引入了一批影响深远的迁移项CHANGELOG 对此有专门说明新项目直接按这些模式落地5.1 新的地面链路组件族Svc::Framer与Svc::Deframer取代旧的Svc::GroundInterface负责地面数据流的组帧/解帧。它们将组帧逻辑委托给用户实例化的帧格式类因此可以支持非 F´ 的自定义帧协议。Drv::ByteStreamDriverModel一个统一的字节流驱动模型实现该模型的驱动即可读写连续的字节流同时支持上下行通信的组合选择。三个 IPv4 驱动Drv::TcpClientTCP 客户端连接远程服务器、Drv::TcpServerTCP 服务器接受远程客户端连接、Drv::UdpUDP 通信。它们共同取代了旧的一体化Drv::SocketIpDriver并均实现Drv::ByteStreamDriverModel。这些模块在仓库中均有对应实现组帧/解帧见 Svc/Framer、Svc/Deframer 与帧协议 Svc/FramingProtocol字节流模型见 Drv/ByteStreamDriverModel/ByteStreamDriverModel.fpp驱动实现见 Drv/TcpClient、Drv/TcpServer、Drv/Udp。地面接口链重构后若仍需用 GDS 对接旧接口可执行fprime-gds --comm-checksum-type fixed。Svc::GenericHubHub 模式的基础实例化用于地面系统与飞行软件之间的消息转发实现见 Svc/GenericHub。5.2 文件下行与缓冲区管理Svc::FileDownlink支持维护一个待下行文件队列并提供触发文件下行的端口还可配置关闭特定错误避免误报。其 FPP 模型、命令/事件/遥测定义见 Svc/FileDownlink。Svc::BufferManager被重构以消除错误路径实例化时必须像 Ref 参考部署那样传入内存分配器。在 Ref/Top/RefTopology.cpp 中可见其标准装配方式创建全局Fw::MallocAllocator mallocator然后以fileUplinkBufferManager.setup(UPLINK_BUFFER_MANAGER_ID, 0, mallocator, upBuffMgrBins)形式将分配器与缓冲区桶配置传入该文件中cmdSeq.allocateBuffer(0, mallocator, CMD_SEQ_BUFFER_SIZE)与Os::MicroFsInit(microFsCfg, 0, mallocator)展示了同一分配器在其他组件的复用。5.3 其他 API 调整Os::File::open的 CREATE 模式现在正确遵守O_EXCL语义若文件已存在则报错。若需覆盖此行为在调用末尾传false。Fw::Buffer的成员函数统一改为驼峰命名例如Fw::Buffer::getsize更名为Fw::Buffer::getSizeFw/Buffer/Buffer.hpp。Fw::MemAllocator接口在 1.4 已扩展出recoverable标志表示跨复位是否可恢复内存与可被分配器改写的size变量用于返回实际分配大小见 Fw/Types/MemAllocator.hpp 的allocate(identifier, size, recoverable)签名3.0 及后续版本均延续此接口。版本选择建议与迁移路线图结合 CHANGELOG 的版本定位可给出如下决策建议新项目直接采用当前 3.x 版本与 FPP 建模无需经历迁移。无法升级 C11 或无法采用 FPP 的既有项目停留在2.1.0它是 F´ 2.x 系列的最终版本CHANGELOG 明确其为 2.x 收官版。仍在 VxWorks 6 上运行的项目注意2.0.1是最后一个支持 VxWorks 6 的版本之后的版本不再支持该平台。典型迁移顺序为先用fprime-util generate重建 CMake 配置并核对CMAKE_BUILD_TYPE/BUILD_TESTING/CMAKE_INSTALL_PREFIX三个变量 → 用fpp-from-xml转换组件与端口模型 → 按 v3-renamed-symbols.md 全面替换枚举符号 → 分离 Topology 模块与可执行文件register_fprime_moduleregister_fprime_deployment→ 修复Os::Task::start调用 → 若使用旧地面链路切换到Svc::Framer/Svc::Deframer/Drv::ByteStreamDriverModel组合。每完成一步即可构建验证一次编译期错误如旧 API 调用的DEPRECATED告警、枚举缺失是定位剩余迁移点的最直接线索。参考文档索引CHANGELOG.md本文依据的版本发布与迁移说明原始文档docs/UsersGuide/user/v3-migration-guide.mdv3.0.0 官方迁移指南docs/UsersGuide/dev/v3-renamed-symbols.mdv3 完整重命名符号清单docs/UsersGuide/cmake/Migration.md构建系统迁移说明Fw/Cmd/Cmd.fppFw::CmdResponse枚举的 FPP 定义Os/Task.hppOs::Task::start新 API 签名与旧 API 弃用标注Ref/CMakeLists.txt 与 Ref/Top/CMakeLists.txt部署与拓扑模块分离后的 CMake 标准写法Ref/SignalGen/SignalGen.cpp新枚举写法的组件实现范例Ref/Top/RefTopology.cppMemAllocator与BufferManager装配范例赞分享嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fpri/fprime点击查看免费下载相关推荐Slidev 幻灯片导入Importing Slides用 src 拆分与复用多文件演示文稿Slidev 幻灯片导入Importing Slides用 src 拆分与复用多文件演示文稿 本指南聚焦 Slidev 的「幻灯片导入」能力通过 sli嵌入式系统编程Swin Transformer在COCO数据集上的性能优化10个实用技巧Swin Transformer在COCO数据集上的性能优化10个实用技巧 Swin Transformer作为基于分层视觉Transformer的目标检测与人工智能计算机视觉深度学习如何用Go-Taskflow构建高性能并发任务编排系统从数据管道到AI工作流如何用Go Taskflow构建高性能并发任务编排系统从数据管道到AI工作流 Go Taskflow是一个基于Go语言的原生任务并行编程框架专为复杂依赖关系上一篇如何快速上手neo-tree.nvim10分钟完成安装与基础配置下一篇NetGuard多语言支持如何为您的母语贡献翻译创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考