MFC嵌入CEF3 90.6.0：VS2010桥接DLL与JS双向通信-北京尧图网络

简介面向使用 VS2010 开发桌面程序的 C 开发者这份资源围绕 CEF3 90.6.0 嵌入 MFC 窗口并实现 JavaScript 与 C 互调展开适合需要为传统 MFC 应用补充现代 Web 渲染能力、研究浏览器内核集成与消息循环协同的读者。压缩包共 629 个文件约 457.22MB包含 h/cpp 源码与工程文件、lib/dll 链接与运行库、pak 资源包、obj/tlog/pdb 等编译中间产物以及 sln、vcxproj、rc 等 Visual Studio 工程配置基本覆盖从编译到运行的依赖结构。已有 1558 人学习下载说明该主题在 MFC 与 CEF3 结合场景中具有一定参考需求。资源可用于对照梳理 CEF3 在 VS2010 下的工程组织方式、子进程与库文件部署、MFC 窗口尺寸与绘制消息同步以及 JS 调用 C 的接口注册思路帮助读者减少环境搭建与依赖排查成本。1. 项目定位给一个 2010 年的 MFC 外壳装上 Chromium 90 内核接手过一个设备上位机的改造界面是十几年前的 MFC 对话框控件全靠 CWnd 手绘串口通信、授权校验、本地数据库这些老代码一行都不能动但客户要求界面换成 Web 前端来写。能选的方案不多整包重写风险太大剩下的路就是在 MFC 窗口里挂一个浏览器。这个项目走的是后者——用 VS2010 建 MFC 工程把 CEF3 90.6.0 的 Chromium 内核以子窗口方式嵌进去页面里的 JS 走消息路由调回 C 业务层C 侧再主动把设备状态推回页面。这套组合适合两类人手里有存量 MFC 代码、又必须给界面做 Web 化改造的 C 开发以及需要在老编译环境里接入现代浏览器内核的维护者。它的难点不在 API而在 VS2010 的编译器和 CEF 90 之间隔了十几年的语言标准所以下面按「工程骨架 → 窗口嵌入 → JS 通道 → 避坑 → 二次开发」的顺序推进。2. 环境与工程骨架VS2010 和 CEF 90 的编译器代差怎么填平先把事实说清楚CEF 90.6.0 对应 Chromium 90 这条线它的 C wrapperlibcef_dll/wrapper那几个头文件要求编译器至少吃下 C14而 VS2010 只覆盖了部分 C11 特性连变参模板、nullptr之外的很多东西都不完整。把这些头文件直接拖进 VS2010 工程第一屏就会给你几十个语法错误改都改不完。所以「VS2010 CEF3 90」这个组合能成立靠的是分层隔离而不是强行编译把 CEF 的初始化、窗口创建、JS 路由全部封进一个独立的桥接 DLL用新版本编译器产出VS2010 的 MFC 工程只调用 DLL 导出的纯 C 接口一个 CEF 头文件都不 include。这样 MFC 侧完全没有语言标准包袱CEF 侧也能正常用现代语法。2.1 二进制包里哪些文件必须跟 exe 放一起CEF 的二进制发行包解压后大致是这么几块cef_binary_90.6.0/ ├── Release/ │ ├── libcef.dll # 内核本体几十 MB │ ├── chrome_elf.dll # 崩溃处理与加载器 │ ├── libcef.lib # 导入库链接用 │ ├── cef.pak # 内核资源 │ ├── cef_100_percent.pak │ ├── cef_200_percent.pak │ ├── icudtl.dat # 国际化数据 │ ├── resources/ # 内置页面资源 │ └── locales/ # 语言包 ├── include/ │ ├── capi/ # 纯 C 接口这里最稳定 │ └── ... ├── libcef_dll/ │ └── wrapper/ # C 封装层源码 └── cmake/运行时真正需要跟 exe 同目录的是libcef.dll、chrome_elf.dll、三个 pak、icudtl.dat、resources/和locales/。locales/里几十个语言包可以只保留zh-CN.pak和en-US.pak其余删掉能省十几 MB。libcef.lib只在链接期用发布时可以不带。提示路径里带中文或者空格出现过加载失败我一般把整个运行目录的路径保持成纯 ASCII能省掉一轮排查。2.2 用新编译器产出一个只暴露纯 C 接口的桥接 DLL这一步是整个工程的关键。新开一个 DLL 工程把include/和libcef_dll/wrapper加进编译链接libcef.lib然后在里面实现所有 CEF 相关的逻辑。对外只留一个头文件// host_bridge.h —— VS2010 侧唯一需要 include 的头没有任何 CEF 类型 #pragma once #ifdef HOST_BRIDGE_EXPORTS #define HB_API __declspec(dllexport) #else #define HB_API __declspec(dllimport) #endif // 消息回调msg_id 用于区分业务类型json_utf8 是 UTF-8 编码的负载 typedef void (__stdcall *HB_QUERY_CB)(int msg_id, const char* json_utf8, void* user); extern C { // locale 传 zh-CN返回 false 说明初始化失败多半是资源文件缺失 HB_API bool HB_Init(const char* locale); // parent 是 MFC 给的占位控件句柄浏览器会被建成它的子窗口 HB_API bool HB_CreateBrowser(HWND parent, int x, int y, int w, int h, const char* url); // 父窗口尺寸变化时调用内部会同步 CEF 子窗口大小 HB_API void HB_Resize(HWND parent, int w, int h); // 从 C 主动执行一段 JSscript 必须是 UTF-8 HB_API void HB_ExecuteJs(const char* script_utf8); // 注册 JS 调上来的回调user 原样透传 HB_API void HB_SetQueryCallback(HB_QUERY_CB cb, void* user); HB_API void HB_DoMessageLoopWork(); HB_API void HB_Shutdown(); }为什么要绕这一层而不是直接把 C wrapper 的类导出因为CefRefPtr是模板跨 DLL 边界传模板实例会牵扯到堆的归属、STL 版本、异常与 RTTI 设置两套编译器产出的东西在这些点上几乎必然不一致。导出纯 C 的指针和const char*等于把 ABI 风险压到最低。头文件里全部用 UTF-8 的char*而不是TCHAR*也是刻意的VS2010 工程不管是多字节还是 Unicode 字符集转一次 UTF-8 都比转wchar_t可控CEF 内部对 UTF-8 的支持也最完整。2.3 VS2010 工程的四个设置项MFC 工程这边要改的地方不多但每一项漏了都会出问题设置项位置值字符集配置属性 → 常规使用 Unicode 字符集附加包含目录C/C → 常规桥接 DLL 的 include 路径附加依赖项链接器 → 输入host_bridge.lib调试工作目录调试 → 工作目录放libcef.dll的那个目录字符集这一项要单独说。CEF 的cef_string_t在 Windows 上默认走宽字符如果 VS2010 工程停在多字节字符集CString到char*的转换会在中文路径和中文参数上出乱码而且这种乱码只在特定机器上复现非常折磨人。统一成 Unicode 之后CStringW到 UTF-8 的转换写一次就够了。调试工作目录也很关键。VS2010 默认的工作目录是工程目录不是输出目录libcef.dll放在Release/下而工作目录指错表现就是HB_Init返回 false 然后弹个看不懂的框。3. 窗口嵌入CefInitialize 之后Chromium 怎么变成一个 MFC 子窗口桥接 DLL 里的第一件事是初始化。CEF 是多进程架构主进程负责窗口和消息循环渲染、GPU、网络各自跑在子进程里这些子进程的入口其实是同一个 exe。所以初始化函数的第一步不是配置而是判断我这次启动到底是主进程还是子进程。3.1 CefSettings单线程消息循环是这里的默认答案bool HB_Init(const char* locale) { CefMainArgs main_args(::GetModuleHandle(NULL)); CefRefPtrCHostApp app(new CHostApp()); // 关键主进程调用返回 -1子进程调用返回 0 并应立刻退出 int exit_code CefExecuteProcess(main_args, app.get(), nullptr); if (exit_code 0) { ::ExitProcess(exit_code); } CefSettings settings; settings.no_sandbox true; // 老环境里沙箱常和安全软件打架 settings.multi_threaded_message_loop false; // 由 MFC 主循环驱动见 3.3 settings.log_severity LOGSEVERITY_WARNING; CefString(settings.locale).FromASCII(locale); CefString(settings.log_file).FromASCII(cef_debug.log); return CefInitialize(main_args, settings, app.get(), nullptr); }几个参数值得逐个解释。no_sandbox在嵌入式场景几乎是必开CEF 的沙箱依赖一套子进程权限降级机制跟很多国产安全软件、老版本系统补丁冲突表现是浏览器进程起来就挂日志里一行 Failed to launch 都看不到。multi_threaded_message_loop false是把消息循环的控制权交回给 MFCCEF 内部会起一个独立的 UI 线程主线程需要定期调CefDoMessageLoopWork把任务泵出去设成 true 则 CEF 自己管理线程MFC 侧不用管但调试时断点会乱跳我一般不用。log_file指定日志文件名排障时把log_severity调到LOGSEVERITY_INFO能看到资源加载、子进程启动、页面导航的完整过程比盲猜强得多。CHostApp这个类同时继承CefApp和CefRenderProcessHandler因为渲染进程侧要注入 JS 对象这个后面第 4 章会用到。CefExecuteProcess必须在CefInitialize之前调而且在主进程里也要调一次——很多人以为只有子进程才走这里结果子进程反复拉起自己任务管理器里几分钟就堆出上百个进程。3.2 CreateBrowser 的 parent 句柄、位置和窗口样式浏览器创建需要一个CefClient的实现至少挂上CefLifeSpanHandler用来拿浏览器实例的句柄class CHostClient : public CefClient, public CefLifeSpanHandler { public: CefRefPtrCefBrowser browser_; HWND child_wnd_ nullptr; CefRefPtrCefLifeSpanHandler GetLifeSpanHandler() override { return this; } void OnAfterCreated(CefRefPtrCefBrowser browser) override { browser_ browser; // CEF 自己建了一个子窗口挂在 parent 下句柄要留着做 Resize child_wnd_ browser-GetHost()-GetWindowHandle(); } void OnBeforeClose(CefRefPtrCefBrowser browser) override { browser_ nullptr; child_wnd_ nullptr; } private: IMPLEMENT_REFCOUNTING(CHostClient); };IMPLEMENT_REFCOUNTING是 CEF 的引用计数宏少了它编译能过但运行时会崩在AddRef上。创建调用本身很直白bool HB_CreateBrowser(HWND parent, int x, int y, int w, int h, const char* url) { CefWindowInfo info; // SetAsChild 让 CEF 创建 WS_CHILD 子窗口位置相对 parent 客户区 info.SetAsChild(parent, x, y, x w, y h); CefBrowserSettings bsettings; bsettings.javascript STATE_ENABLED; bsettings.local_storage STATE_ENABLED; CefRefPtrCHostClient client(new CHostClient()); g_client client; return CefBrowserHost::CreateBrowser(info, client, CefString(url), bsettings, nullptr, nullptr) ! 0; }SetAsChild的四个参数是左上右下不是宽高我第一次写的时候传了宽高窗口只显示了四分之一。CefBrowserSettings里javascript默认是启用的显式写一遍是为了防止有人从别处拷了关闭 JS 的配置过来。MFC 侧的调用就很薄了在对话框的OnInitDialog里BOOL CDeviceDlg::OnInitDialog() { CDialogEx::OnInitDialog(); CRect rc; m_wndPlaceholder.GetWindowRect(rc); // m_wndPlaceholder 是个静态控件占位 ScreenToClient(rc); m_wndPlaceholder.ShowWindow(SW_HIDE); // 占位控件只用来算坐标 HB_CreateBrowser(GetSafeHwnd(), rc.left, rc.top, rc.Width(), rc.Height(), http://127.0.0.1:8080/index.html); return TRUE; }用静态控件当占位是个顺手做法在资源编辑器里摆好位置和大小运行时算出客户区坐标再把控件藏掉。以后要挪位置改资源文件就行不用改代码里的魔数。3.3 消息泵把 CefDoMessageLoopWork 挂进 MFC 的 Run这是整个集成里最容易翻车的地方。multi_threaded_message_loop false时CEF 的任务队列要靠主线程定期泵泵得不勤页面就卡泵得太勤 CPU 就满。MFC 默认的CWinApp::Run是个阻塞式的GetMessage循环没有可以插钩子的地方所以只能整个重写int CDeviceApp::Run() { MSG msg; BOOL running TRUE; while (running) { while (::PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message WM_QUIT) { running FALSE; break; } ::TranslateMessage(msg); ::DispatchMessage(msg); } // 把 CEF 的任务队列泵一次内部就是 CefDoMessageLoopWork() HB_DoMessageLoopWork(); // 等 5ms 或有新消息到达就醒别用裸 Sleep(0) 空转 ::MsgWaitForMultipleObjects(0, NULL, FALSE, 5, QS_ALLINPUT); } return (int)msg.wParam; }MsgWaitForMultipleObjects这几个参数第一个 0 表示不等待任何句柄第二个NULL对应空数组第三个FALSE表示不要求全部触发第四个 5 是超时毫秒数第五个QS_ALLINPUT表示有任意输入消息就唤醒。这行等价于最多睡 5 毫秒有消息立刻起来兼顾了 CPU 占用和响应速度。重写Run的副作用要提前知道MFC 的OnIdle不会再被自动调用工具栏按钮的启用状态、状态栏的实时刷新都会失灵。补法是每轮循环手动调一次OnIdle(0)或者干脆把这些 UI 更新挪到WM_TIMER里。还有一个坑是关窗顺序。用户点关闭后如果直接CefShutdown()而浏览器还没走完OnBeforeClose会崩在析构里。稳妥点的做法是在主窗口OnDestroy里先发一个WM_CLOSE给 CEF 子窗口等OnBeforeClose触发后置个标志再调HB_Shutdown()。4. JS 与 C 的双向通道CefMessageRouter 的两端都要写到这一步页面能显示了但页面里的按钮点了没反应。CEF 的 JS 调用 C 有几种做法CefV8Handler自定义函数、window.cefQuery消息路由、以及基于CefProcessMessage的手工消息。工程里用的是CefMessageRouter因为它是异步的、自带回调、还能跨进程比自建 IPC 省事。关键在于这个 router 分两端浏览器进程一侧是CefMessageRouterBrowserSide渲染进程一侧是CefMessageRouterRendererSide两边都要创建并注册少一边就是cefQuery is not a function。4.1 浏览器进程CefMessageRouterBrowserSide 与 OnQuery 回调先实现 handler把 JS 上来的请求接住class CQueryHandler : public CefMessageRouterBrowserSide::Handler { public: CQueryHandler(HB_QUERY_CB cb, void* user) : cb_(cb), user_(user) {} bool OnQuery(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, int64 query_id, const CefString request, bool persistent, CefRefPtrCallback callback) override { // request 是 JS 侧 cefQuery 传上来的原始字符串约定为 JSON CefString req request; std::string utf8 req.ToString(); if (cb_) { cb_(0, utf8.c_str(), user_); // 转交给 MFC 侧的业务回调 } callback-Success({\code\:0,\msg\:\ok\}); return true; // true 表示本 handler 接管false 则继续往后找 } private: HB_QUERY_CB cb_; void* user_; };OnQuery的返回值语义要留意返回true表示这个 query 归你处理router 不再往下传返回false会找下一个注册的 handler全都没接就自动回一个失败。callback-Success和callback-Failure各自只能调一次重复调用会触发断言。persistent参数标记这是不是一个长期订阅JS 侧第三个参数传 true订阅式查询要在OnQueryCanceled里清理。router 的创建和挂载CefMessageRouterConfig config; config.js_query_function cefQuery; // 页面里调用的函数名 config.js_cancel_function cefQueryCancel; // 取消订阅的函数名 g_router CefMessageRouterBrowserSide::Create(config); g_router-AddHandler(new CQueryHandler(cb, user), true); // true 首参优先最后一步是把消息转发进去这一步漏了前面全白写bool CHostClient::OnProcessMessageReceived(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, CefProcessId source_process, CefRefPtrCefProcessMessage message) { return g_router-OnProcessMessageReceived(browser, frame, source_process, message); }OnProcessMessageReceived是CefClient的虚函数要在GetClientHandler之类的地方确保CefClient自身被返回。同时OnBeforeBrowse和OnRenderViewReady也要转发给 router前者用来在页面跳转时清掉挂起的 query后者用来在渲染进程重启后重建状态。4.2 渲染进程OnContextCreated 里注册 window.bridge渲染进程侧的代码跑在子进程里入口同样是CHostAppclass CHostApp : public CefApp, public CefRenderProcessHandler { public: CefRefPtrCefRenderProcessHandler GetRenderProcessHandler() override { return this; } void OnContextCreated(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, CefRefPtrCefV8Context context) override { // 每个渲染进程一份第一次进上下文时创建 if (!renderer_router_) { CefMessageRouterConfig config; config.js_query_function cefQuery; config.js_cancel_function cefQueryCancel; renderer_router_ CefMessageRouterRendererSide::Create(config); } renderer_router_-OnContextCreated(browser, frame, context); } void OnContextReleased(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, CefRefPtrCefV8Context context) override { if (renderer_router_) { renderer_router_-OnContextReleased(browser, frame, context); } } private: CefRefPtrCefMessageRouterRendererSide renderer_router_; IMPLEMENT_REFCOUNTING(CHostApp); };OnContextCreated在每次页面创建 JS 上下文时触发OnContextReleased在页面卸载时触发成对调用才能把 V8 里挂的东西清干净否则反复刷新页面会缓慢泄漏。页面侧的调用长这样// 前端封装一层避免业务代码到处写 cefQuery function invokeNative(action, payload) { return new Promise((resolve, reject) { if (!window.cefQuery) { reject(new Error(native bridge not ready)); return; } window.cefQuery({ request: JSON.stringify({ action: action, data: payload }), onSuccess: function (resp) { resolve(JSON.parse(resp)); // resp 是 C 回的 JSON 字符串 }, onFailure: function (code, msg) { reject(new Error(code : msg)); } }); }); } document.getElementById(btnRead).onclick async () { const r await invokeNative(readSerial, { port: COM3 }); console.log(port value:, r.value); };这一段里最有价值的是那层 Promise 封装cefQuery是回调式的业务代码里到处写onSuccess会失控包成 Promise 之后跟fetch的用法一致前端同事接手不用额外学习。4.3 反向调用ExecuteJavaScript 该放在哪个时机C 主动推数据给页面走的是ExecuteJavaScriptvoid HB_ExecuteJs(const char* script_utf8) { if (!g_client || !g_client-browser_) return; CefRefPtrCefFrame frame g_client-browser_-GetMainFrame(); if (!frame) return; // 第二个参数是脚本所属的 URL用于错误定位0 表示不关心执行结果 frame-ExecuteJavaScript(CefString(script_utf8), frame-GetURL(), 0); }时机是这里唯一的坑。页面还在加载、OnLoadEnd没触发的时候调脚本会被直接丢弃没有任何报错表现就是设备状态推上去没反应。我一般加一个page_ready_标志在OnLoadEnd里置位HB_ExecuteJs判断标志没置就把脚本压到一个队列里等加载完统一刷出去。另一个必须注意的点ExecuteJavaScript只能在 CEF 的 UI 线程调用。串口线程、定时器线程直接调会崩在GetMainFrame里。标准做法是CefPostTask(TID_UI, base::Bind(...))把调用投递到 UI 线程再执行。5. 避坑清单白屏、子进程递归、cefQuery undefined 的现场处置这些问题都是实际调试过程中遇到过的按「现象 → 原因 → 解决」记下来省得下次重新踩。5.1 启动期问题现象程序启动后窗口一片白日志里只有几行 Failed to load resourceHB_Init返回 true。原因cef.pak、icudtl.dat或locales/没有跟 exe 放在同一目录CEF 找不到资源会静默降级成一个空白页面初始化本身不算失败。解决把第 2.1 节列的那批文件全部拷到 exe 旁边locales/至少保留zh-CN.pak。用 Process Monitor 看libcef.dll旁边的文件访问路径一次就能定位。现象进程管理器里同一个 exe 出现几十个实例越跑越多机器卡死。原因CefExecuteProcess的返回值没判断或者没在CefInitialize之前调。子进程起来后继续往下初始化又创建了自己的子进程形成递归。解决确保CefExecuteProcess是HB_Init的第一条语句返回值 0时直接ExitProcess。主进程里也必须调这一句它返回 -1 才代表是主进程。现象HB_Init返回 false但没有任何有用的报错。原因多半是libcef.dll与libcef.lib版本不一致或者 Debug/Release 的运行库设置串了/MT与/MD混用。解决确认 DLL 和导入库来自同一个二进制包桥接 DLL 和 MFC 主程序的运行库设置保持一致统一用/MD或/MDd。5.2 交互期问题现象控制台一行window.cefQuery is not a function页面其他功能正常。原因只创建了CefMessageRouterBrowserSide没在渲染进程里创建CefMessageRouterRendererSide或者OnContextCreated里忘了调router-OnContextCreated。解决对照第 4.2 节检查三处——CHostApp是否实现了CefRenderProcessHandler、GetRenderProcessHandler是否返回了 this、OnContextCreated是否把上下文交给了 router。三处缺一处都不行。现象浏览器窗口嵌进去了但拖动主窗口或最大化时CEF 内容不跟随露出一块灰底。原因CEF 的子窗口不响应 MFC 的布局OnSize里只改了占位控件的尺寸没去动 CEF 的窗口。解决在父窗口的OnSize里调HB_Resize内部先browser-GetHost()-WasResized()再::MoveWindow(child_wnd_, 0, 0, w, h, TRUE)调整子窗口。现象页面滚动很卡或者点击按钮要等一秒才有反应。原因消息泵频率太低。MsgWaitForMultipleObjects的超时时间给到 50ms 甚至 100msCEF 的渲染任务排不上队。解决超时压到 5ms 以内同时排查主线程里有没有Sleep或同步 IO 阻塞CEF 的 UI 线程和主线程是同一个任何阻塞都会直接体现成界面卡顿。6. 二次开发把桥接层收成一个 Facade再用三条自测守住回归改造这个项目最该做的一件事是把HB_*那组 C 接口再往上收一层做成 MFC 侧能直接用的 C Facade。原因是现在每次加一个业务动作都要在 DLL 里改OnQuery的字符串解析、在 MFC 侧改回调、在前端改action名字三处对不上就返工。我一般会定义一张消息协议表固定成「action 名 → 参数结构 → 返回结构」Facade 只做字符串拼装和分发// 只依赖 host_bridge.hMFC 侧完全不用知道 CEF 的存在 class CBridgeFacade { public: using Handler std::functionstd::string(const std::string payload); void Register(const std::string action, Handler h) { m_handlers[action] std::move(h); } // 绑定给 HB_SetQueryCallback 的静态回调 static void __stdcall OnNativeQuery(int msg_id, const char* json, void* user) { auto* self static_castCBridgeFacade*(user); self-Dispatch(json); } private: void Dispatch(const char* json) { // 极简解析{action:readSerial,data:{...}} std::string s(json); std::string action ExtractField(s, action); auto it m_handlers.find(action); if (it m_handlers.end()) return; std::string result it-second(s); // 结果回推给页面走 JS 全局回调 std::string js window.onNativePush( result ); HB_ExecuteJs(js.c_str()); } std::mapstd::string, Handler m_handlers; };注册起来就一行m_facade.Register(readSerial, [this](const std::string payload) { CString value m_serial.ReadOnce(); // 老代码原样调用 return {\value\:\ ToUtf8(value) \}; });这样一来加一个业务动作就变成了纯粹的 MFC 侧工作前端只需要知道action名字桥接 DLL 一行都不用改。验证方面我固定跑三条自测项做法通过标准通道连通性页面加载后按钮触发一次ping前端 1 秒内收到{code:0}反向推送定时器每秒向页面推一个计数页面数字稳定递增不跳变关闭清理连续开关窗口 20 次进程数回到基线无残留子进程最后一条最容易挂。曾经有个版本关窗后子进程不退出任务管理器里越积越多查了半天是OnBeforeClose里的标志没置位CefShutdown就一直等。从那以后我每次改完桥接层都强制把这三条走一遍再交版本特别是进程数那一条——它不明显但会在客户机器上连续开机一周后集中爆发。希望帮到你。本文还有配套的精品资源点击获取

MFC嵌入CEF3 90.6.0：VS2010桥接DLL与JS双向通信

相关推荐

一枚回形针的自我修养：从设计原理到制造工艺全拆解

MIPI D-PHY与CSI-2摄像头调试：从电气波形到V4L2驱动实战

从并行总线到HSS核：SerDes链路预算与上板调试

更多资讯

QT for webassembly

C++仿C#实现事件处理

HarmonyOS 开发

C++ 机器学习 dlib 实践

C++ 有向图拓扑排序算法

PIC18F57K42与MAX14431的SPI隔离方案设计与实践

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

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

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

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

本月热门

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

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

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

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