SAP RAP架构解析：CDS、Behavior与OData契约驱动原理-北京尧图网络

简介本资源是一份面向ABAP开发者与SAP Fiori应用工程师的RAPABAP RESTful Application Programming技术入门与进阶教程聚焦SAP S/4HANA环境下基于ABAP的现代化Fiori应用开发实践。内容系统覆盖RAP核心概念、CDS视图建模、行为定义与实现、服务暴露、Fiori Elements集成及安全与性能优化要点并融入Test-Driven Development、Core Data Services等高阶主题兼顾理论讲解与工程落地。资源为单个PDF文件大小18.31MB结构完整、图文结合便于离线研读与项目参考。目前已有367人学习下载适合具备基础ABAP知识和Fiori开发经验的中高级开发者快速掌握RAP开发范式提升企业级SAP应用构建能力。1. RAP Fiori为什么写个“列表页”要拆成 7 层抽象、5 类文件、3 种行为定义你刚在 SAP Web IDE 里点下“生成 List Report”本以为几秒就能跑起来——结果弹出 12 个待创建的文件CDS View、Projection View、Behavior Definition、Service Definition、Service Binding、Metadata Extension、UI Annotation… 还没写一行业务逻辑光建模就卡了半小时。更玄学的是改完 CDS 字段前端不刷新加了个UI.lineItem列表却空着调试时发现数据从数据库出来是好的到 UI 层突然变 null——整个链路像黑匣子连断点都插不到关键位置。这不是配置失误而是 RAPABAP RESTful Programming Model刻意设计的「分层契约」在起作用它把传统 ABAP 中揉在一起的「数据定义」「业务规则」「服务暴露」「UI 绑定」彻底解耦每层只认上一层的契约接口不关心下一层怎么实现。Fiori 不再是“套个壳”而是被这套契约驱动的终端表现。搞不清这 7 层怎么咬合你就永远在猜——为什么改了 CDS 却不生效为什么 Behavior Handler 里打了断点却进不去为什么 OData 响应里字段名和 CDS 定义对不上这份教程的价值正在于把这套被 SAP 官方文档称为“面向业务对象的编程范式”的机制一层层剥开给你看不是教你怎么点按钮而是告诉你每个文件生成时ABAP 运行时底层到底做了什么、契约如何传递、错误为何发生在那一层。2. RAP 架构本质CDS 是源头Behavior 是灵魂OData 是出口RAP 的核心不是语法糖而是一套以业务对象为中心的契约驱动架构。它强制开发者用声明式方式定义“这个对象是什么”CDS、“它能做什么”Behavior、“外界怎么用它”Service三者通过编译期校验与运行时代理严格绑定。这种设计直接源于 S/4HANA 对“可组合性”和“云原生演进”的硬性要求——单体 ABAP 程序无法支撑微服务化部署、多租户隔离、前后端分离等场景。RAP 把过去靠开发经验隐含的规则变成编译器可检查、工具链可生成、运行时可拦截的显式契约。2.1 CDS View不只是视图而是业务对象的“元数据契约”CDSCore Data Services在 RAP 中已超越传统数据库视图。它既是数据源定义也是业务语义载体。关键在于ObjectModel注解族——它们不是装饰而是向 ABAP 运行时注册的元数据契约AbapCatalog.sqlViewName: ZI_SALESORDER AccessControl.authorizationCheck: #NOT_REQUIRED EndUserText.label: Sales Order Header ObjectModel.semanticKey: [salesorder] ObjectModel.writeActivePersistence: zsalesorder_h define view ZI_SalesOrder as select from zsalesorder_h { key salesorder, ObjectModel.readOnly: true EndUserText.label: Created By createdby, ObjectModel.virtualElement: true ObjectModel.virtualElementCalculatedBy: ZCL_SALESORDER_CALCGET_STATUS status }ObjectModel.semanticKey告诉 RAP“这个视图代表一个业务对象主键是salesorder”后续所有 Behavior 定义必须基于此主键ObjectModel.writeActivePersistence指定持久化实体RAP 自动生成 INSERT/UPDATE/DELETE 的默认实现ObjectModel.virtualElementCalculatedBy声明虚拟字段由 ABAP 类计算运行时 RAP 会自动调用该方法且该字段不参与数据库查询只在读取后注入。提示CDS 编译后生成的DDIC结构如ZI_SALESORDER会被 RAP 运行时直接映射为 OData 实体类型。字段名、数据类型、长度全部继承自 CDS不是你在 Service Binding 里手动配的——这是新手最常翻车的点以为改 Service Binding 就能改字段实际必须回 CDS 改。2.2 Behavior Definition业务规则的“执行契约”而非逻辑容器Behavior Definition.behdef是 RAP 最反直觉的一环。它不写代码只声明“这个对象支持哪些操作”以及“操作受什么约束”。真正的代码在 Behavior Implementation.bdef对应的.abap类中但运行时调用路径由 Behavior Definition 严格控制// ZI_SALESORDER.behdef projection on ZI_SalesOrder { // 主键字段必须显式列出否则无法识别业务对象实例 use projection ZI_SalesOrder; // 声明支持的操作 create; update; delete; // 字段级约束createdby 只读status 仅可由特定方法修改 field ( read, write ) salesorder, createdby; field ( read, write ) status Semantics.statusDefinition: true; // 操作级验证更新前检查状态流转合法性 validation validate_status_change on save { field salesorder; } }field (read, write)并非权限控制而是运行时字段可访问性契约若未声明write即使你在 Behavior Handler 里写了modify逻辑RAP 运行时也会在解析请求时直接报错Field not modifiablevalidation ... on save声明了一个验证钩子RAP 在save操作前自动调用对应 Behavior Implementation 中的validate_status_change方法关键机制Behavior Definition 编译后生成BDEF对象ABAP 运行时通过cl_abap_behavior_handler动态代理所有 CRUD 操作。你写的 Behavior Handler 类只是“被调用方”调用时机、参数封装、事务边界全由 RAP 运行时按契约决定。2.3 Service Definition BindingOData 的“契约翻译器”不是简单路由RAP 的 Service 不是传统 Gateway 的SEGW项目。Service Definition.srvd是纯声明式契约定义“暴露哪些实体、支持哪些操作”Service Binding.srvbind才是将契约映射到具体实现的粘合层// ZI_SALESORDER_SRV.srvd service definition ZI_SALESORDER_SRV { define service { expose ZI_SalesOrder as SalesOrder; } }// ZI_SALESORDER_SRV.srvbind service binding definition ZI_SALESORDER_SRV_0001 { bind entity ZI_SalesOrder to ZI_SalesOrder; }expose ZI_SalesOrder as SalesOrder表示将 CDS 视图ZI_SalesOrder暴露为 OData 实体集SalesOrderbind entity ... to ...表示该实体集的数据源绑定到ZI_SalesOrder即 CDS 视图但注意此处的ZI_SalesOrder是 Behavior Projection View如ZI_SALESORDER_CDS不是原始 CDSRAP 要求 Service Binding 必须绑定到带有 Behavior 的 Projection View否则无法启用事务能力底层机制Service Binding 编译后生成SRVBIND对象ABAP 运行时通过cl_rest_service_handler将 HTTP 请求如POST /sap/opu/odata/sap/ZI_SALESORDER_SRV_0001/SalesOrder解析为cl_abap_behavior_handler的标准方法调用如create_entity。URL 路径、HTTP 方法、OData 查询选项$filter,$expand全部由 RAP 运行时按 OData V4 协议自动转换开发者无需手写 URL 映射。3. Fiori Elements 如何“读懂”RAPUI Annotation 是唯一桥梁Fiori Elements 不是通用框架而是专为 RAP 生成的 OData 服务设计的声明式渲染引擎。它不解析 CDS 或 Behavior只消费 OData 元数据$metadata和 UI AnnotationUI.*。这意味着RAP 开发者写的每一个UI.lineItem、UI.identification都会被编译进 OData 元数据Fiori Elements 在加载时解析这些注解动态生成控件、布局、导航逻辑。没有 AnnotationFiori Elements 就是“瞎子”。3.1 Metadata Extension让 Annotation 脱离 CDS实现 UI 与数据模型解耦RAP 强制要求 UI Annotation 不能写在 CDS 里除极少数基础注解必须通过独立的Metadata Extension.xml文件注入。这是为了解耦CDS 定义业务语义Metadata Extension 定义 UI 表现二者可由不同角色维护!-- ZI_SALESORDER_EXT.xml -- edmx:Edmx xmlns:edmxhttp://schemas.microsoft.com/ado/2007/06/edmx Version4.0 edmx:Reference Urihttps://example.com/sap/opu/odata4/sap/zui5_testv4/default/sap/zui5_testv4/0001/ xmlnshttp://docs.oasis-open.org/odata/ns/edm edmx:Include Namespacezui5_testv4.v0001 Aliasv0001/ /edmx:Reference edmx:DataServices Schema xmlnshttp://docs.oasis-open.org/odata/ns/edm Namespacezui5_testv4.v0001 Annotations Targetv0001.SalesOrderType Annotation TermUI.LineItem Collection Record TypeUI.DataField PropertyValue PropertyValue Pathsalesorder/ /Record Record TypeUI.DataField PropertyValue PropertyValue Pathcreatedby/ /Record /Collection /Annotation /Annotations /Schema /edmx:DataServices /edmx:EdmxTargetv0001.SalesOrderType指向 OData 元数据中的实体类型由 CDS 生成而非 CDS 名称Annotation TermUI.LineItem告诉 Fiori Elements“这个实体的列表页第一列显示salesorder第二列显示createdby”关键机制Metadata Extension 部署后ABAP 运行时将其与 OData 服务绑定通过SICF节点配置当客户端请求$metadata时RAP 运行时自动将 Extension 中的 Annotation 合并进响应 XML。Fiori Elements 加载元数据后根据UI.LineItem自动渲染Table控件UI.Identification渲染ObjectPage标题栏——你没写一行 JavaScript却完成了 UI 结构定义。3.2 Projection ViewFiori Elements 的“数据适配层”解决 CDS 与 UI 的语义鸿沟原始 CDS 视图如ZI_SalesOrder往往包含技术字段client,createdat、冗余关联join多表、或不符合 UI 需求的聚合如count(*)。Projection View.projview就是为 Fiori Elements 量身定制的“轻量级数据投影”// ZI_SALESORDER_PROJ.projview projection on ZI_SalesOrder { salesorder, createdby, UI.lineItem: [{ position: 10 }] UI.identification: [{ position: 1 }] status }它继承ZI_SalesOrder的所有字段和注解但可筛选、重排序、添加 UI 相关注解核心价值Projection View 是 Service Binding 的绑定目标也是 Metadata Extension 的Target来源。Fiori Elements 实际消费的是 Projection View 暴露的 OData 实体而非原始 CDS。这意味着你可以为同一 CDS 创建多个 Projection View分别服务于 List Report、Object Page、Analytical List Page 等不同 Fiori 模板而 CDS 逻辑完全复用避坑重点Projection View 必须显式声明UI.*注解否则 Fiori Elements 无法识别字段用途。很多开发者以为 CDS 里写了UI.lineItem就够了实际必须在 Projection View 里重写——因为 CDS 的注解不会透传到 OData 元数据。3.3 Fiori Elements 模板的“零代码”原理元数据驱动渲染Fiori Elements 的 List Report 模板sap.fiori.elements.templates.ListReport在启动时只做三件事请求/$metadata解析出实体类型、字段、UI.LineItem注解根据UI.LineItem中的Path值如salesorder自动生成Column控件并绑定items{/SalesOrder}根据UI.Identification中的Path和position在 Object Page 标题栏渲染对应字段。// OData $metadata 片段简化 EntityType NameSalesOrderType Property Namesalesorder TypeEdm.String Nullablefalse / Property Namecreatedby TypeEdm.String / Property Namestatus TypeEdm.String / Annotation TermUI.LineItem Collection Record TypeUI.DataField PropertyValue PropertyValue Pathsalesorder/ /Record Record TypeUI.DataField PropertyValue PropertyValue Pathcreatedby/ /Record /Collection /Annotation /EntityType这就是为什么你改了 CDS 字段名Fiori 页面立刻报错Property xxx not foundFiori Elements 直接依赖$metadata中的字段名而$metadata由 CDS 编译生成血泪经验不要试图在 Fiori Elements 的manifest.json里手动配置columns那是 Freestyle 模式才用的。RAP Fiori Elements 的正确姿势是所有 UI 结构由 CDS/Projection/Metadata Extension 三层 Annotation 决定manifest.json 只负责指定模板类型和 OData 服务 URL。4. RAP 开发避坑指南90% 的“不生效”问题都发生在这 5 个环节RAP 的分层契约设计带来强一致性但也放大了配置错误的影响范围。一个注解写错、一个绑定漏掉、一个编译顺序不对都可能导致“前端空白”“字段不显示”“保存失败无提示”等玄学问题。以下是某开发者在模拟项目 X 中踩过的典型坑按发生频率排序4.1 现象CDS 视图已激活但 Service Binding 激活时报错 “Entity ZI_SalesOrder not found in service definition”原因Service Definition 中expose ZI_SalesOrder as SalesOrder的ZI_SalesOrder必须是已激活的 CDS View 名称且该 CDS View 必须已成功编译生成 DDIC 结构ZI_SALESORDER。常见错误是CDS 文件名是ZI_SalesOrder.cds但 View 名称写成了ZI_SALESORDER大小写不一致或 CDS 中define view后跟了错误的名称解决在 ABAP Development Tools (ADT) 中右键 CDS 文件 → “Open With” → “Data Preview”若能查出数据说明 CDS 编译成功再检查 Service Definition 中expose后的名称是否与 CDS 中define view后的名称完全一致包括大小写。4.2 现象Fiori List Report 页面加载后表格为空Network 面板显示 OData 请求返回 200 但value数组为空原因Projection View 未正确绑定到 Service Binding或 Projection View 本身未激活。Service Binding 的bind entity必须指向带有 Behavior 的 Projection View如ZI_SALESORDER_PROJ而非原始 CDSZI_SalesOrder。若绑定错误RAP 运行时会返回空数据集解决检查 Service Binding 文件确认bind entity ZI_SalesOrder to ZI_SALESORDER_PROJ;中的ZI_SALESORDER_PROJ已激活在 ADT 中打开该 Projection View确认其上方有绿色对勾表示已激活若无右键 → “Activate”。4.3 现象给字段加了UI.lineItem但 List Report 中该字段不显示在表格列中原因UI.lineItem注解必须写在Projection View中而非原始 CDS。CDS 中的UI.*注解不会透传到 OData 元数据只有 Projection View 和 Metadata Extension 中的注解才会被合并进$metadata解决打开 Projection View.projview文件在对应字段前添加UI.lineItem: [{ position: 10 }]确保该 Projection View 已激活清除浏览器缓存重新加载$metadataURL如/sap/opu/odata4/sap/ZI_SALESORDER_SRV_0001/$metadata搜索字段名确认Annotation TermUI.LineItem存在且Path正确。4.4 现象Behavior Handler 类中写了create方法但前端点击“新建”按钮后无反应Network 面板无 POST 请求原因Behavior Definition 中未声明create;操作或 Service Definition 未expose该实体。RAP 运行时只对 Behavior Definition 中明确声明的操作生成 OData 端点。若未声明create则POST /SalesOrder路径根本不存在前端会静默失败解决检查 Behavior Definition.behdef文件确认首行有create;检查 Service Definition.srvd中expose的实体名与 Behavior Definition 的projection on名称一致在浏览器中直接访问https://host/sap/opu/odata4/sap/ZI_SALESORDER_SRV_0001/$metadata搜索Create确认Action元素存在。4.5 现象修改 CDS 字段后Fiori 页面报错 “Property xxx not found”但 CDS 已重新激活原因CDS 修改后Projection View、Behavior Definition、Service Definition、Service Binding、Metadata Extension 全部需要重新激活。RAP 的编译依赖链是CDS → Projection View → Behavior Definition → Service Binding → Metadata Extension。任一环节未激活都会导致元数据不一致解决在 ADT 的 Project Explorer 中按依赖顺序右键激活先 CDS再 Projection View再 Behavior Definition再 Service Definition再 Service Binding最后 Metadata Extension。激活时注意 ADT 底部状态栏若出现黄色警告如 “Dependency not activated”必须按提示顺序激活。5. RAP 的“行为驱动”本质为什么Behavior Saver比INSERT INTO更安全传统 ABAP 开发中INSERT INTO zsalesorder_h是数据落库的终点而在 RAP 中INSERT只是触发Behavior Saver的起点。RAP 运行时将所有数据变更操作CREATE/UPDATE/DELETE统一收口到cl_abap_behavior_saver的save方法再由开发者实现的Behavior Saver Local Class.abap接管。这不是语法糖而是为了解决企业级应用中三个致命问题事务边界模糊、业务规则分散、审计追溯困难。5.1 Behavior Saver事务的“唯一入口”强制业务规则集中化在ZI_SALESORDER_SAVBehavior Saver Local Class中你必须实现save方法CLASS zcl_salesorder_saver DEFINITION PUBLIC INHERITING FROM cl_abap_behavior_saver. PUBLIC SECTION. METHODS save REDEFINITION. ENDCLASS. CLASS zcl_salesorder_saver IMPLEMENTATION. METHOD save. 1. 处理 CREATE 操作 IF create~is_not_initial( ). LOOP AT create~salesorder ASSIGNING FIELD-SYMBOL(so). 执行业务逻辑生成订单号、校验库存、发送通知... zcl_salesorder_logiccreate_order( so ). ENDLOOP. ENDIF. 2. 处理 UPDATE 操作 IF update~is_not_initial( ). LOOP AT update~salesorder ASSIGNING FIELD-SYMBOL(so_upd). zcl_salesorder_logicupdate_order( so_upd ). ENDLOOP. ENDIF. 3. RAP 运行时自动执行数据库写入基于 ObjectModel.writeActivePersistence 开发者无需写 INSERT/UPDATE/DELETE只需专注业务逻辑 ENDMETHOD. ENDCLASS.create~is_not_initial( )是 RAP 自动生成的内表包含所有待创建的实例数据字段结构与 CDS 视图一致zcl_salesorder_logiccreate_order( )是你封装的纯业务逻辑类与数据库操作解耦关键机制save方法在一个数据库 LUWLogical Unit of Work中执行RAP 运行时保证若save方法抛出异常所有变更自动回滚若成功所有INSERT/UPDATE/DELETE由 RAP 自动生成并提交。你不再需要CALL FUNCTION BAPI_TRANSACTION_COMMIT也不用担心ROLLBACK WORK漏写。5.2 Behavior Handler操作的“前置守门员”拦截非法状态流转Behavior Handler.abap负责create、update、delete等操作的前置校验与预处理它在save之前执行且可中断流程CLASS zcl_salesorder_handler DEFINITION PUBLIC INHERITING FROM cl_abap_behavior_handler. PUBLIC SECTION. METHODS create REDEFINITION. METHODS update REDEFINITION. METHODS validate_status_change REDEFINITION. 对应 Behavior Definition 中的 validation ENDCLASS. CLASS zcl_salesorder_handler IMPLEMENTATION. METHOD create. LOOP AT create~salesorder ASSIGNING FIELD-SYMBOL(so). 检查创建人必须有销售组织权限 IF NOT zcl_auth_checkhas_sales_org( so-createdby ). 抛出 RAP 标准异常前端显示友好提示 raise exception type cx_abap_behavior_invalid_value exporting textid /bobf/cx_frwinvalid_value message No sales organization authorization. ENDIF. ENDLOOP. ENDMETHOD. METHOD validate_status_change. LOOP AT validate_status_change~salesorder ASSIGNING FIELD-SYMBOL(so_val). 检查状态只能从 DRAFT → CONFIRMED禁止跳过 IF so_val-old_status DRAFT AND so_val-new_status CONFIRMED. raise exception type cx_abap_behavior_invalid_value exporting textid /bobf/cx_frwinvalid_value message Status change not allowed. ENDIF. ENDLOOP. ENDMETHOD. ENDCLASS.create方法中抛出异常会阻止save执行前端收到400 Bad Request及错误消息validate_status_change是 Behavior Definition 中validation声明的钩子RAP 运行时在save前自动调用确保状态流转符合业务规则设计取舍RAP 强制将校验逻辑放在 Handler 而非 Saver是因为 Handler 可以快速失败不触达数据库而 Saver 是事务最终执行点。这种分离让性能敏感的校验如权限检查不拖慢主流程。5.3 RAP 的“后悔药”为什么Behavior Saver是审计日志的黄金位置企业系统必须记录“谁在何时因何原因修改了什么”。传统方案是在每个MODIFY前手动写INSERT INTO zaudit_log极易遗漏。RAP 的Behavior Saver天然成为审计日志的统一入口METHOD save. 1. 记录所有变更前的状态通过 old_data 参数 IF update~is_not_initial( ). zcl_audit_loggerlog_update( iv_user sy-uname iv_timestamp sy-datum sy-uzeit it_old_data update~old_data it_new_data update~salesorder ). ENDIF. 2. 执行业务逻辑zcl_salesorder_logicupdate_order 3. RAP 自动写库 ENDMETHOD.update~old_data是 RAP 运行时自动提供的内表包含更新前的完整快照update~salesorder是更新后的数据因为所有更新必经save所以在此处写日志100% 覆盖无遗漏风险血泪教训某公司在迁移旧系统时因审计日志分散在 200 个MODIFY语句中漏掉了 3 个关键更新点导致合规审查失败。迁移到 RAP 后审计日志逻辑收敛到 1 个Behavior Saver维护成本下降 90%。6. 从契约到现实为什么 RAP 要求“先定义再实现”而不是“先编码再配置”RAP 的学习曲线陡峭根源在于它颠覆了 ABAP 开发者的惯性思维过去是“写个报表程序再配个 ALV”现在是“先画 CDS 视图再定 Behavior再绑 Service最后加 Annotation”。这种“先定义契约再填充实现”的范式不是为了增加复杂度而是为了解决 S/4HANA 时代三个不可回避的工程现实工程挑战传统 ABAP 方案RAP 方案为什么 RAP 更优多前端适配为 WebGUI、Fiori、Mobile 分别开发不同程序逻辑重复同一套 CDS Behavior生成 WebAPI、OData、RESTful JSON 多种服务CDS 是单一事实源UI 与数据解耦前端换皮不改后端合规审计业务规则散落在 100 个FORM和METHOD中难以全局扫描所有规则集中在 Behavior Definition声明和 Behavior Handler校验中审计人员只需检查.behdef和.abap文件覆盖率 100%云环境部署SELECT * FROM ztable语句在 HANA 上性能差需手动优化CDS 视图自动转为 HANA SQLScriptAnalytics.dataCategory: #CUBE直接启用 OLAP加速开发者专注语义性能优化由平台自动完成这种范式转变的代价是初期要忍受“建 10 个文件才能跑通 Hello World”的挫败感。但当你在模拟项目 X 中第一次用 RAP 开发一个带审批流的采购申请应用时你会意识到那个在Behavior Definition中声明的action approve在Behavior Handler中实现的approve方法在Metadata Extension中标注的UI.lineItem: [{ action: approve }]共同构成了一条从 UI 按钮点击、到后端业务逻辑、再到数据库提交的端到端可追踪契约链。任何环节出问题你都能精准定位到是契约定义错了CDS 字段名拼错还是契约执行错了Handler 中少写了权限检查而不是在几百行MODULE pool里大海捞针。从那以后我每次启动新 RAP 项目都强制走一遍“契约四问”这个业务对象的主键在 CDS 里声明了吗ObjectModel.semanticKey它支持的操作在 Behavior Definition 里列全了吗create; update; delete;Service Binding 绑定的是 Projection View 而不是原始 CDS 吗所有 UI 字段都在 Projection View 或 Metadata Extension 中加了UI.*吗这四步走完90% 的“页面空白”“字段不显示”“操作无响应”问题就消失了。剩下的才是真正的业务逻辑攻坚。希望帮到你。本文还有配套的精品资源点击获取

SAP RAP架构解析：CDS、Behavior与OData契约驱动原理

相关推荐

ROW_COUNT与FOUND_ROWS辨析及MySQL分页替换

RAP Fiori开发核心：CDS+Behavior+Projection三位一体架构

安卓教师辅助系统开发：考勤、互动与资源管理实践

更多资讯

LC选频网络与谐振回路：Q值、通频带及阻抗匹配解析

工控机无网不用愁：三步搞定网络共享，附共享与网桥对比

AI工程体系构建：Python/Rust/TS/Julia多语言协同实践

LeetCode 27题：双指针法原地移除数组元素

STM32入门必看：Proteus 8.6安装汉化与仿真全攻略

Node.js私厨服务小程序开发实战与架构设计

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？