嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载导读本文以 F´F Prime飞行软件框架中的事件日志Event Log机制为核心以TestLog测试组件的 Component Dictionary 文档TestLog.md为主线完整还原了XML 定义事件 → 自动代码生成 → 事件发送与接收 → 字典文档生成的完整链路。读完本文你将掌握如何在 F´ 组件 XMLAi.xml中声明带参数的事件、理解事件 ID 的十六进制编码规则、使用自动生成的log_ACTIVITY_LO_*发送 API以及如何实现接收端的事件反序列化与日志端口对接。一、什么是 Component DictionaryTestLog.md 的定位在 F´ 框架中Component Dictionary组件字典是每个组件面向集成、测试与地面系统GDS的说明书。它以 Markdown 表格的形式集中罗列组件对外暴露的命令Commands、遥测通道Telemetry Channels与事件Events是自动化工具链、GDS 配置和人工联调时共同依赖的权威数据源。TestLog.md 正是Autocoders/Python/test/event_string测试组件生成的字典文档。该文档由自动化工具从组件的 XML 定义派生而来其事件列表部分记录了TestLog组件声明的全部事件及其参数签名Event NameIDDescriptionArg NameArg TypeArg SizeDescriptionSomeEvent100 (0x64)A test eventarg1I32The I32 command argumentarg2Fw::LogStringArg15The F32 command argumentarg3U8The U8 command argument这张表信息密度很高事件名为SomeEventID 为十进制的100、同时给出十六进制形式0x64事件带有三个参数——arg1I32、arg2Fw::LogStringArg即日志专用字符串类型容量 15 字符、arg3U8。后续章节将逐一揭示这些字段从何而来、如何被代码消费。二、事件从哪来XML 中的事件声明字典文档不是手写的而是由组件的 XML 描述AI XML驱动自动生成的。TestLog组件的完整定义位于 TestComponentAi.xml其中与SomeEvent相关的声明如下component nameTestLog kindpassive namespaceSomewhere events !-- A test event -- event id100 nameSomeEvent severityACTIVITY_LO format_string My Event %d [%s] %d commentA test event/comment args arg namearg1 typeI32 commentThe I32 command argument/comment /arg arg namearg2 typestring size15 commentThe F32 command argument/comment /arg arg namearg3 typeU8 commentThe U8 command argument/comment /arg /args /event /events ... /component逐字段对照字典表格可以完整还原文档中各列的技术含义id100事件的唯一编号在字典中同时呈现为十进制100与十六进制0x64。ID 在同一组件内必须唯一是接收端与 GDS 识别事件的依据。nameSomeEvent事件名称字典中的 Event Name 列即取自这里。severityACTIVITY_LO事件严重级别。F´ 预定义的级别包括ACTIVITY_LO低活动级、ACTIVITY_HI、WARNING_LO、WARNING_HI、FATAL、COMMAND、DIAGNOSTIC等直接决定事件在Fw::LogSeverity中的取值。format_stringMy Event %d [%s] %d事件的格式化字符串类似printf风格。三个占位符%d、%s、%d与三个参数一一对应供地面系统、文本日志Text Log通道渲染人类可读的事件文本。arg namearg1 typeI32/arg namearg3 typeU8整型参数直接映射为 C 基础类型。arg namearg2 typestring size15字符串参数。size指定容量上限自动代码生成时会将其映射为Fw::LogStringArg这正是字典中 Arg Type 列出现Fw::LogStringArg、Arg Size 列为15的原因。组件还导入了三个与日志链路密切相关的端口类型见 TestComponentAi.xmlFw/Log/LogPortAi.xml事件日志端口、Fw/Log/LogTextPortAi.xml文本日志端口、Fw/Time/TimePortAi.xml时间戳端口。在ports段中它们分别以LogroleLogEvent、LogTextroleLogTextEvent、TimeroleTimeGet三个输出端口的形式被实例化——事件在发出时自动携带时间戳并通过这两个日志端口分发。三、ID 与十六进制编码的生成规则字典中100 (0x64)的双进制呈现并非手工填写而是由 Markdown 字典模板程序化生成。查看模板 MdEventsTablePage.tmpl可以看到 ID 的完整计算逻辑#for $id, $eventname, $severity, $format_string, $throttle, $comment in $events: ... #if len($id) 1: #set $id $id[0] #if x in $id: #set $id int($id, 16) $base_id #else #set $id int($id) $base_id #end if #set $hexid hex($id) #end if从模板可以推断出几条关键规则支持十进制与十六进制两种书写方式如果 XML 中 ID 字符串含有字符x按十六进制解析否则按十进制解析。支持基址偏移base_id模板将解析出的 ID 加上组件级基址base_id得到最终 ID这是 F´ 框架级与组件级事件编号冲突规避的通用手段。十六进制自动派生最终 ID 通过 Python 的hex()生成0x64形式与十进制一并写入表格方便调试时按位识别事件族。模板同时遍历$args为每个事件输出参数行——首行写事件名与 ID后续每一行以| | | |前缀续写参数信息这正是 TestLog.md 表格中事件行 三个参数行排布的直接来源。同目录下的events/EventBody.tmplEventBody.tmpl则负责生成供 GDS 使用的 Python 事件描述模块其中同样携带ID、SEVERITY、FORMAT_STRING与ARGUMENTS元数据印证了字典与 GDS 数据共享同一份 XML 源头。四、自动生成的发送 APIlog_ACTIVITY_LO_SomeEvent事件定义好之后Autocoder 会为组件基类生成事件发送成员函数命名规则为log_SEVERITY_EventName。在 TestLogImpl.cpp 中可以直观看到它的用法void TestLogImpl::sendEvent(I32 arg1, Fw::LogStringArg arg2, U8 arg3) { printf(Sending event args %d, %s, %d\n, arg1, arg2.toChar(), arg3); this-log_ACTIVITY_LO_SomeEvent(arg1, arg2, arg3); }要点解析函数签名与 XML 参数严格对应arg1I32、arg2Fw::LogStringArg、arg3U8三个实参按声明顺序传入顺序与字典表格完全一致。组件实现类的继承关系TestLogImpl继承自Somewhere::TestLogComponentBase见 TestLogImpl.hpplog_ACTIVITY_LO_SomeEvent即定义在该自动生成的基类中实现类只需直接调用。命名空间Somewhere也来自 XML 的namespace属性说明命名空间、组件名共同决定了生成代码的 C 符号。参数类型映射规则XML 中的I32→I32、U8→U8、string size15→Fw::LogStringArg。其中字符串类型Fw::LogStringArg定义在 LogString.hpp其STRING_SIZE FW_LOG_STRING_MAX_SIZE内部使用定长char m_buf[...]存储toChar()返回 C 风格字符串指针——这就是字典 Arg Size 15 对应的实际容量语义。事件发送后基类会通过组件的Log输出端口类型Fw::Log与LogText输出端口类型Fw::LogText把事件分发出去并借助Time端口roleTimeGet为事件打上时间戳。因此任何事件在接收端都会携带事件 ID、时间戳、严重级别与序列化后的参数缓冲区。五、接收端视角事件的反序列化与参数顺序事件最终由日志消费方通过输入端口接收。TestLogRecvImpl.cpp 展示了接收处理的典型范式void TestLogRecvImpl::logRecvPort_handler(NATIVE_INT_TYPE portNum, FwEventIdType id, Fw::Time timeTag, const Fw::LogSeverity severity, Fw::LogBuffer args) { printf(Received log %d, Time (%d,%d:%d) severity %d\n, id, timeTag.getTimeBase(), timeTag.getSeconds(), timeTag.getUSeconds(), severity.e); I32 arg1; Fw::LogStringArg arg2; U8 arg3; // deserialize them in reverse order args.deserialize(arg3); args.deserialize(arg2); args.deserialize(arg1); printf(Args: %d \%s\ %d\n, arg1, arg2.toChar(), arg3); }这里有三个极易踩坑的关键点参数以逆序反序列化Fw::LogBuffer中参数的序列化顺序与发送 API 的实参顺序相反后进先出。因此接收端必须依次先deserialize(arg3)、再deserialize(arg2)、最后deserialize(arg1)才能还原原始顺序。代码注释 deserialize them in reverse order 明确点出了这一约定。事件元数据随参数一同送达FwEventIdType id对应字典中的事件 ID100/0x64Fw::Time timeTag是发送端TimeGet端口注入的时间戳Fw::LogSeverity对应 XML 中声明的ACTIVITY_LO。接收端可据此在日志系统中分流、过滤或渲染不同严重级别的事件。字符串参数以Fw::LogStringArg落位反序列化目标必须是定长字符串类型Fw::LogStringArg与发送端/字典中的类型完全一致随后用toChar()输出。六、测试与构建集成字典背后的工程闭环event_string不仅是演示代码更是一个可编译、可测试的 Autocoder 回归用例。从 CMakeLists.txt 可以看到其工程组织SOURCE_FILES同时包含两个 XMLTestComponentAi.xml、TestPortAi.xml与手写的 C 实现TestLogImpl.cpp、TestLogRecvImpl.cpp、main.cppXML 会经由 Autocoder 生成TestComponentAc基类代码后参与编译。MOD_DEPS声明依赖Autocoders/Python/test/log_tester与Autocoders/Python/test/time_tester——前者提供了LogTextImpl文本日志接收基类TestLogRecvImpl.hpp 中TestLogRecvImpl即继承自LogTextImpl后者提供时间模拟能力。单元测试入口 main.cpp 实例化了Somewhere::TestLogGTestBase测试基类表明 Autocoder 同时为组件生成了 GTest 测试骨架可对事件发送行为做自动化断言。也就是说从 XML 事件声明出发一条流水线同时产出C 组件基类含log_ACTIVITY_LO_SomeEvent、GTest 测试基类TestLogGTestBase、GDS 事件描述模块EventBody.tmpl产物以及本文章反复引用的 Markdown 组件字典MdEventsTablePage.tmpl产物。TestLog.md 正是这条流水线的最终可读产物之一它把事件 ID、参数类型、参数容量等运行时关键信息以表格形式固化下来成为跨角色组件开发者、集成者、测试者、GDS 操作员沟通的统一语言。七、实践要点小结声明事件在组件 Ai.xml 的events段使用event id name severity format_string声明参数用args/arg描述字符串参数务必给出size容量。生成产物重新运行 Autocoder或重新构建 CMake 工程后自动获得log_SEVERITY_EventName发送 API、GTest 基类与 Markdown 字典字典中的 Arg Type 列如Fw::LogStringArg即参数类型的最终 C 形态。发送事件在实现类中直接调用生成的发送函数实参顺序与 XML 声明顺序一致。接收事件在日志接收端按逆序对Fw::LogBuffer反序列化并通过FwEventIdType、Fw::Time、Fw::LogSeverity获得事件身份、时间戳与严重级别。核对字典事件 ID 的十进制/十六进制双表示、参数列表均可作为集成调试与 GDS 建链的核对依据确保 XML、生成代码与字典三方一致。赞分享嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载相关推荐Activepieces 收到 Webhook 被拒绝报 413 Request Too Long 怎么调整负载上限Activepieces 收到 Webhook 被拒绝报 413 Request Too Long 怎么调整负载上限 Activepieces 的 Webho嵌入式系统编程F´ 事件节流Event Throttle机制剖析从 XML 定义、自动生成代码到组件字典与测试验证F´ 事件节流Event Throttle机制剖析从 XML 定义、自动生成代码到组件字典与测试验证 本文以仓库中 event_throttle 测试组件嵌入式系统编程Envoy StringMatcher五种字符串匹配模式与 Lua 自定义匹配器的配置与实现解析Envoy StringMatcher五种字符串匹配模式与 Lua 自定义匹配器的配置与实现解析 本文基于 Envoy 官方文档 string_matcher嵌入式系统编程上一篇3大核心功能重构Wallpaper Engine资源处理RePKG给开发者的效率提升指南下一篇LeagueAkari重新定义英雄联盟体验的智能辅助工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 F´ 事件日志（Event Log）机制深度解析：从 XML 定义、自动代码生成到 Component Dictionary
嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载导读本文以 F´F Prime飞行软件框架中的事件日志Event Log机制为核心以TestLog测试组件的 Component Dictionary 文档TestLog.md为主线完整还原了XML 定义事件 → 自动代码生成 → 事件发送与接收 → 字典文档生成的完整链路。读完本文你将掌握如何在 F´ 组件 XMLAi.xml中声明带参数的事件、理解事件 ID 的十六进制编码规则、使用自动生成的log_ACTIVITY_LO_*发送 API以及如何实现接收端的事件反序列化与日志端口对接。一、什么是 Component DictionaryTestLog.md 的定位在 F´ 框架中Component Dictionary组件字典是每个组件面向集成、测试与地面系统GDS的说明书。它以 Markdown 表格的形式集中罗列组件对外暴露的命令Commands、遥测通道Telemetry Channels与事件Events是自动化工具链、GDS 配置和人工联调时共同依赖的权威数据源。TestLog.md 正是Autocoders/Python/test/event_string测试组件生成的字典文档。该文档由自动化工具从组件的 XML 定义派生而来其事件列表部分记录了TestLog组件声明的全部事件及其参数签名Event NameIDDescriptionArg NameArg TypeArg SizeDescriptionSomeEvent100 (0x64)A test eventarg1I32The I32 command argumentarg2Fw::LogStringArg15The F32 command argumentarg3U8The U8 command argument这张表信息密度很高事件名为SomeEventID 为十进制的100、同时给出十六进制形式0x64事件带有三个参数——arg1I32、arg2Fw::LogStringArg即日志专用字符串类型容量 15 字符、arg3U8。后续章节将逐一揭示这些字段从何而来、如何被代码消费。二、事件从哪来XML 中的事件声明字典文档不是手写的而是由组件的 XML 描述AI XML驱动自动生成的。TestLog组件的完整定义位于 TestComponentAi.xml其中与SomeEvent相关的声明如下component nameTestLog kindpassive namespaceSomewhere events !-- A test event -- event id100 nameSomeEvent severityACTIVITY_LO format_string My Event %d [%s] %d commentA test event/comment args arg namearg1 typeI32 commentThe I32 command argument/comment /arg arg namearg2 typestring size15 commentThe F32 command argument/comment /arg arg namearg3 typeU8 commentThe U8 command argument/comment /arg /args /event /events ... /component逐字段对照字典表格可以完整还原文档中各列的技术含义id100事件的唯一编号在字典中同时呈现为十进制100与十六进制0x64。ID 在同一组件内必须唯一是接收端与 GDS 识别事件的依据。nameSomeEvent事件名称字典中的 Event Name 列即取自这里。severityACTIVITY_LO事件严重级别。F´ 预定义的级别包括ACTIVITY_LO低活动级、ACTIVITY_HI、WARNING_LO、WARNING_HI、FATAL、COMMAND、DIAGNOSTIC等直接决定事件在Fw::LogSeverity中的取值。format_stringMy Event %d [%s] %d事件的格式化字符串类似printf风格。三个占位符%d、%s、%d与三个参数一一对应供地面系统、文本日志Text Log通道渲染人类可读的事件文本。arg namearg1 typeI32/arg namearg3 typeU8整型参数直接映射为 C 基础类型。arg namearg2 typestring size15字符串参数。size指定容量上限自动代码生成时会将其映射为Fw::LogStringArg这正是字典中 Arg Type 列出现Fw::LogStringArg、Arg Size 列为15的原因。组件还导入了三个与日志链路密切相关的端口类型见 TestComponentAi.xmlFw/Log/LogPortAi.xml事件日志端口、Fw/Log/LogTextPortAi.xml文本日志端口、Fw/Time/TimePortAi.xml时间戳端口。在ports段中它们分别以LogroleLogEvent、LogTextroleLogTextEvent、TimeroleTimeGet三个输出端口的形式被实例化——事件在发出时自动携带时间戳并通过这两个日志端口分发。三、ID 与十六进制编码的生成规则字典中100 (0x64)的双进制呈现并非手工填写而是由 Markdown 字典模板程序化生成。查看模板 MdEventsTablePage.tmpl可以看到 ID 的完整计算逻辑#for $id, $eventname, $severity, $format_string, $throttle, $comment in $events: ... #if len($id) 1: #set $id $id[0] #if x in $id: #set $id int($id, 16) $base_id #else #set $id int($id) $base_id #end if #set $hexid hex($id) #end if从模板可以推断出几条关键规则支持十进制与十六进制两种书写方式如果 XML 中 ID 字符串含有字符x按十六进制解析否则按十进制解析。支持基址偏移base_id模板将解析出的 ID 加上组件级基址base_id得到最终 ID这是 F´ 框架级与组件级事件编号冲突规避的通用手段。十六进制自动派生最终 ID 通过 Python 的hex()生成0x64形式与十进制一并写入表格方便调试时按位识别事件族。模板同时遍历$args为每个事件输出参数行——首行写事件名与 ID后续每一行以| | | |前缀续写参数信息这正是 TestLog.md 表格中事件行 三个参数行排布的直接来源。同目录下的events/EventBody.tmplEventBody.tmpl则负责生成供 GDS 使用的 Python 事件描述模块其中同样携带ID、SEVERITY、FORMAT_STRING与ARGUMENTS元数据印证了字典与 GDS 数据共享同一份 XML 源头。四、自动生成的发送 APIlog_ACTIVITY_LO_SomeEvent事件定义好之后Autocoder 会为组件基类生成事件发送成员函数命名规则为log_SEVERITY_EventName。在 TestLogImpl.cpp 中可以直观看到它的用法void TestLogImpl::sendEvent(I32 arg1, Fw::LogStringArg arg2, U8 arg3) { printf(Sending event args %d, %s, %d\n, arg1, arg2.toChar(), arg3); this-log_ACTIVITY_LO_SomeEvent(arg1, arg2, arg3); }要点解析函数签名与 XML 参数严格对应arg1I32、arg2Fw::LogStringArg、arg3U8三个实参按声明顺序传入顺序与字典表格完全一致。组件实现类的继承关系TestLogImpl继承自Somewhere::TestLogComponentBase见 TestLogImpl.hpplog_ACTIVITY_LO_SomeEvent即定义在该自动生成的基类中实现类只需直接调用。命名空间Somewhere也来自 XML 的namespace属性说明命名空间、组件名共同决定了生成代码的 C 符号。参数类型映射规则XML 中的I32→I32、U8→U8、string size15→Fw::LogStringArg。其中字符串类型Fw::LogStringArg定义在 LogString.hpp其STRING_SIZE FW_LOG_STRING_MAX_SIZE内部使用定长char m_buf[...]存储toChar()返回 C 风格字符串指针——这就是字典 Arg Size 15 对应的实际容量语义。事件发送后基类会通过组件的Log输出端口类型Fw::Log与LogText输出端口类型Fw::LogText把事件分发出去并借助Time端口roleTimeGet为事件打上时间戳。因此任何事件在接收端都会携带事件 ID、时间戳、严重级别与序列化后的参数缓冲区。五、接收端视角事件的反序列化与参数顺序事件最终由日志消费方通过输入端口接收。TestLogRecvImpl.cpp 展示了接收处理的典型范式void TestLogRecvImpl::logRecvPort_handler(NATIVE_INT_TYPE portNum, FwEventIdType id, Fw::Time timeTag, const Fw::LogSeverity severity, Fw::LogBuffer args) { printf(Received log %d, Time (%d,%d:%d) severity %d\n, id, timeTag.getTimeBase(), timeTag.getSeconds(), timeTag.getUSeconds(), severity.e); I32 arg1; Fw::LogStringArg arg2; U8 arg3; // deserialize them in reverse order args.deserialize(arg3); args.deserialize(arg2); args.deserialize(arg1); printf(Args: %d \%s\ %d\n, arg1, arg2.toChar(), arg3); }这里有三个极易踩坑的关键点参数以逆序反序列化Fw::LogBuffer中参数的序列化顺序与发送 API 的实参顺序相反后进先出。因此接收端必须依次先deserialize(arg3)、再deserialize(arg2)、最后deserialize(arg1)才能还原原始顺序。代码注释 deserialize them in reverse order 明确点出了这一约定。事件元数据随参数一同送达FwEventIdType id对应字典中的事件 ID100/0x64Fw::Time timeTag是发送端TimeGet端口注入的时间戳Fw::LogSeverity对应 XML 中声明的ACTIVITY_LO。接收端可据此在日志系统中分流、过滤或渲染不同严重级别的事件。字符串参数以Fw::LogStringArg落位反序列化目标必须是定长字符串类型Fw::LogStringArg与发送端/字典中的类型完全一致随后用toChar()输出。六、测试与构建集成字典背后的工程闭环event_string不仅是演示代码更是一个可编译、可测试的 Autocoder 回归用例。从 CMakeLists.txt 可以看到其工程组织SOURCE_FILES同时包含两个 XMLTestComponentAi.xml、TestPortAi.xml与手写的 C 实现TestLogImpl.cpp、TestLogRecvImpl.cpp、main.cppXML 会经由 Autocoder 生成TestComponentAc基类代码后参与编译。MOD_DEPS声明依赖Autocoders/Python/test/log_tester与Autocoders/Python/test/time_tester——前者提供了LogTextImpl文本日志接收基类TestLogRecvImpl.hpp 中TestLogRecvImpl即继承自LogTextImpl后者提供时间模拟能力。单元测试入口 main.cpp 实例化了Somewhere::TestLogGTestBase测试基类表明 Autocoder 同时为组件生成了 GTest 测试骨架可对事件发送行为做自动化断言。也就是说从 XML 事件声明出发一条流水线同时产出C 组件基类含log_ACTIVITY_LO_SomeEvent、GTest 测试基类TestLogGTestBase、GDS 事件描述模块EventBody.tmpl产物以及本文章反复引用的 Markdown 组件字典MdEventsTablePage.tmpl产物。TestLog.md 正是这条流水线的最终可读产物之一它把事件 ID、参数类型、参数容量等运行时关键信息以表格形式固化下来成为跨角色组件开发者、集成者、测试者、GDS 操作员沟通的统一语言。七、实践要点小结声明事件在组件 Ai.xml 的events段使用event id name severity format_string声明参数用args/arg描述字符串参数务必给出size容量。生成产物重新运行 Autocoder或重新构建 CMake 工程后自动获得log_SEVERITY_EventName发送 API、GTest 基类与 Markdown 字典字典中的 Arg Type 列如Fw::LogStringArg即参数类型的最终 C 形态。发送事件在实现类中直接调用生成的发送函数实参顺序与 XML 声明顺序一致。接收事件在日志接收端按逆序对Fw::LogBuffer反序列化并通过FwEventIdType、Fw::Time、Fw::LogSeverity获得事件身份、时间戳与严重级别。核对字典事件 ID 的十进制/十六进制双表示、参数列表均可作为集成调试与 GDS 建链的核对依据确保 XML、生成代码与字典三方一致。赞分享嵌入式系统编程【免费下载链接】fprimeF´ - A flight software and embedded systems framework项目地址https://gitcode.com/gh_mirrors/fp/fprime点击查看免费下载相关推荐Activepieces 收到 Webhook 被拒绝报 413 Request Too Long 怎么调整负载上限Activepieces 收到 Webhook 被拒绝报 413 Request Too Long 怎么调整负载上限 Activepieces 的 Webho嵌入式系统编程F´ 事件节流Event Throttle机制剖析从 XML 定义、自动生成代码到组件字典与测试验证F´ 事件节流Event Throttle机制剖析从 XML 定义、自动生成代码到组件字典与测试验证 本文以仓库中 event_throttle 测试组件嵌入式系统编程Envoy StringMatcher五种字符串匹配模式与 Lua 自定义匹配器的配置与实现解析Envoy StringMatcher五种字符串匹配模式与 Lua 自定义匹配器的配置与实现解析 本文基于 Envoy 官方文档 string_matcher嵌入式系统编程上一篇3大核心功能重构Wallpaper Engine资源处理RePKG给开发者的效率提升指南下一篇LeagueAkari重新定义英雄联盟体验的智能辅助工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考