国产精品久久久aaaa,日日干夜夜操天天插,亚洲乱熟女香蕉一区二区三区少妇,99精品国产高清一区二区三区,国产成人精品一区二区色戒,久久久国产精品成人免费,亚洲精品毛片久久久久,99久久婷婷国产综合精品电影,国产一区二区三区任你鲁

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

ECU從休眠到網(wǎng)絡(luò)喚醒時間怎么測?

冬至配餃子 ? 來源:開心果 Need Car ? 作者:開心果 Need Car ? 2022-08-29 17:28 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

Q1:ECU從休眠到網(wǎng)絡(luò)喚醒時間怎么測?

答:對于CAN網(wǎng)絡(luò),ECU從休眠到網(wǎng)絡(luò)喚醒時間的測試方法如下:

t0時刻,使用仿真設(shè)備(CANoe/PCan/ZLG等)發(fā)送一幀或者連續(xù)多幀有效的網(wǎng)絡(luò)管理報文;

t0~t1期間,由于ECU休眠(主芯片斷電,不考慮低功耗情況),Controller關(guān)閉,ECU不能接收仿真設(shè)備發(fā)送的報文,所以,此期間仿真設(shè)備發(fā)送的報文,ECU無法應(yīng)答而出現(xiàn)錯誤幀(No Ack);

t1時刻,ECU主芯片供電,程序運行,Controller恢復(fù)正常工作模式(Transceiver也處于正常工作模式),可以接收報文;

t2時刻,識別到有效喚醒源(有效網(wǎng)絡(luò)管理報文),通信打開,ECU外發(fā)第一幀報文。如果節(jié)點的網(wǎng)絡(luò)類型是Passive Mode,第一幀外發(fā)報文是應(yīng)用報文;如果節(jié)點的網(wǎng)絡(luò)類型非Passive Mode,第一幀外發(fā)報文是網(wǎng)絡(luò)管理報文。

所以,ECU從休眠到喚醒的啟->止時間 =t0 ->t2,測試時計算此時間差值(t2-t0)是否滿足需求。注意,t0時刻是指第一幀錯誤幀時刻。

上述時序如下所示:

pYYBAGMMhleAfjoEAAB87OmbMfs649.png

提示:仿真設(shè)備為什么發(fā)送多幀網(wǎng)絡(luò)管理報文?如果Transceiver沒有PN(Partial Network)功能,不能識別網(wǎng)絡(luò)管理報文,第一幀網(wǎng)絡(luò)管理報文只是激活SBC,完成主芯片的供電任務(wù),而沒有被ECU有效接收,則需要第二幀網(wǎng)絡(luò)管理報文喚醒節(jié)點網(wǎng)絡(luò)。

Q2:節(jié)點被動喚醒進(jìn)入RMS狀態(tài),RMB需要置位嗎?

:不需要。節(jié)點被動喚醒(收到其他節(jié)點的網(wǎng)絡(luò)管理報文),由BSM(Bus Sleep Mode)進(jìn)入RMS(Repeat Message State),此時CBV(Control Bit Vector)值 =初始值,而CBV的初始值為0x00,如下所示:

pYYBAGMMhn2AfNHqAAA8MwcWdzA729.png

如果在NOS(Normal Operation State)/RSS(Ready Sleep State )主動請求進(jìn)入RMS,即:主動調(diào)用CanNm_RepeatMessageRequest()接口RMB(Repeat Message Bit)置位,即:RMB = 1

CanNm_RepeatMessageRequest()接口不能在RMS、PBM、BSM狀態(tài)下主動調(diào)用,如下所示:

pYYBAGMMhp2ADDnOAAByQenePxE631.png

這意味著,節(jié)點被動喚醒的時候,網(wǎng)絡(luò)狀態(tài)由BSM進(jìn)入RMS,所以RMB = 0



審核編輯:劉清

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • CAN總線
    +關(guān)注

    關(guān)注

    145

    文章

    2043

    瀏覽量

    135212
  • ecu
    ecu
    +關(guān)注

    關(guān)注

    14

    文章

    982

    瀏覽量

    57266
  • RMS
    RMS
    +關(guān)注

    關(guān)注

    2

    文章

    158

    瀏覽量

    37714
  • 芯片供電
    +關(guān)注

    關(guān)注

    1

    文章

    3

    瀏覽量

    1765
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    北斗網(wǎng)絡(luò)時間服務(wù)器:“精準(zhǔn)心跳”自主可控的技術(shù)實踐

    北斗網(wǎng)絡(luò)時間服務(wù)器早已不再是一個簡單的“時鐘盒子”。它正如同為數(shù)字世界注入“精準(zhǔn)心跳”的起搏器,支撐著智慧航道的數(shù)據(jù)邏輯正確,電網(wǎng)故障的毫秒級定位,再到金融交易的合法
    的頭像 發(fā)表于 02-27 10:50 ?50次閱讀
    北斗<b class='flag-5'>網(wǎng)絡(luò)</b><b class='flag-5'>時間</b>服務(wù)器:<b class='flag-5'>從</b>“精準(zhǔn)心跳”<b class='flag-5'>到</b>自主可控的技術(shù)實踐

    北斗時間服務(wù)器:“單點對時”網(wǎng)絡(luò)協(xié)同”的跨越

    在現(xiàn)代社會的精密運轉(zhuǎn)中,時間同步如同“隱形指揮家”。特高壓電流的相位校準(zhǔn),5G基站的信號切換,再到跨境金融交易的序列確認(rèn),每一個動作都依賴于一個精準(zhǔn)且自主可控的時間基準(zhǔn)。隨著北斗衛(wèi)
    的頭像 發(fā)表于 02-25 14:19 ?48次閱讀
    北斗<b class='flag-5'>時間</b>服務(wù)器:<b class='flag-5'>從</b>“單點對時”<b class='flag-5'>到</b>“<b class='flag-5'>網(wǎng)絡(luò)</b>協(xié)同”的跨越

    解決RK806+RK3588休眠異常!硬件特性軟件優(yōu)化的完整方案

    在嵌入式開發(fā)中,電源管理的穩(wěn)定性直接決定了設(shè)備的可靠性。近期,RK3588 平臺搭配 RK806 電源管理芯片(PMIC)時,出現(xiàn)了二次休眠異常的問題 —— 第一次休眠喚醒正常,再次休眠
    的頭像 發(fā)表于 02-09 16:46 ?720次閱讀
    解決RK806+RK3588<b class='flag-5'>休眠</b>異常!<b class='flag-5'>從</b>硬件特性<b class='flag-5'>到</b>軟件優(yōu)化的完整方案

    揭秘TEE深度休眠喚醒“低概率報錯”:概念到解決方案的全解析

    在嵌入式與物聯(lián)網(wǎng)設(shè)備的底層技術(shù)領(lǐng)域,TEE(可信執(zhí)行環(huán)境) 是保障系統(tǒng)安全的關(guān)鍵組件之一。但在 RK3562、RK3588 等芯片的深度休眠喚醒場景中,卻出現(xiàn)了一類 “低概率卻影響致命” 的報錯問題。今天我們就從概念入手,一步步拆解問題、剖析解決方案。
    的頭像 發(fā)表于 02-09 16:37 ?125次閱讀
    揭秘TEE深度<b class='flag-5'>休眠</b><b class='flag-5'>喚醒</b>“低概率報錯”:<b class='flag-5'>從</b>概念到解決方案的全解析

    RK平臺休眠喚醒與低功耗調(diào)試全攻略:原理到WiFi功耗問題實戰(zhàn)

    在物聯(lián)網(wǎng)設(shè)備、便攜終端等場景中,低功耗是決定產(chǎn)品續(xù)航與用戶體驗的核心指標(biāo)—— 尤其是瑞芯微(RK)平臺設(shè)備,常需在性能與功耗間找到精準(zhǔn)平衡。但實際開發(fā)中,休眠喚醒異常、外設(shè)(如 WiFi)功耗居高不下等問題屢見不鮮。
    的頭像 發(fā)表于 02-05 13:44 ?922次閱讀
    RK平臺<b class='flag-5'>休眠</b><b class='flag-5'>喚醒</b>與低功耗調(diào)試全攻略:<b class='flag-5'>從</b>原理到WiFi功耗問題實戰(zhàn)

    請問休眠模式下的定時喚醒機(jī)制如何實現(xiàn)?

    休眠模式下的定時喚醒機(jī)制如何實現(xiàn)?
    發(fā)表于 12-24 07:58

    深度休眠狀態(tài)下外部所有的IO都可以喚醒MCU嗎?

    深度休眠狀態(tài)下,外部所有的IO都可以喚醒MCU嗎?
    發(fā)表于 12-04 06:00

    MCU典型的睡眠喚醒時間delay的概念

    工作,這時器件就進(jìn)入了正常工作模式。 這里我們重點分析一下這個喚醒delay的時間組成,在MCU系統(tǒng)喚醒中,如果我們對系統(tǒng)使能了在睡眠模式下的供電電壓模塊待機(jī)模式,則從待機(jī)activ
    發(fā)表于 11-25 08:03

    CW32L010進(jìn)入休眠模式后,外部中斷無法喚醒MCU,為什么?

    現(xiàn)在開發(fā)的項目需要低功耗,現(xiàn)在的工作邏輯是:無動作10s后,MCU進(jìn)入休眠模式,然后在用戶按下按鍵后,外部中斷喚醒MCU。 在10s計時滿足后,關(guān)閉定時器,重新配置PB06,用于外部中斷喚醒,然后
    發(fā)表于 11-25 07:11

    TC10管理:虹科10BASE-T1S方案高效管控ECU休眠/喚醒

    虹科Technica深耕汽車以太網(wǎng)領(lǐng)域,基于OPEN Alliance TC10標(biāo)準(zhǔn),推出10BASE-T1S網(wǎng)絡(luò)接口卡,一站式解決「低功耗、快喚醒、易測試」三大痛點,無需額外布線與復(fù)雜開發(fā),直接適配汽車場景的嚴(yán)苛需求。
    的頭像 發(fā)表于 11-12 17:40 ?669次閱讀
    TC10管理:虹科10BASE-T1S方案高效管控<b class='flag-5'>ECU</b><b class='flag-5'>休眠</b>/<b class='flag-5'>喚醒</b>

    虹科分享 | TC10管理:虹科10BASE-T1S方案高效管控ECU休眠/喚醒

    虹科10BASE-T1S接口卡TC10喚醒/休眠控制汽車以太網(wǎng)需兼顧「即時響應(yīng)」與「低功耗」——駕駛員解鎖車門、啟動引擎時,網(wǎng)絡(luò)必須毫秒級喚醒;但E
    的頭像 發(fā)表于 11-12 17:02 ?1422次閱讀
    虹科分享 | TC10管理:虹科10BASE-T1S方案高效管控<b class='flag-5'>ECU</b><b class='flag-5'>休眠</b>/<b class='flag-5'>喚醒</b>

    【道生物聯(lián)TKB-623評估板試用】——2.TKB-623評估板休眠喚醒測試

    上一節(jié)我已經(jīng)講解了兩塊TKB-623評估板之間進(jìn)行AT指令測試及互發(fā)數(shù)據(jù),本節(jié)就來使用兩塊TKB-623評估板進(jìn)行休眠喚醒測試。 原理很簡單,使用一塊TKB-623評估板作為板,進(jìn)入休眠
    發(fā)表于 10-24 19:27

    RK3128 Android 7.1 進(jìn)入深度休眠流程分析

    4. 喚醒流程當(dāng)以下任一事件發(fā)生時,系統(tǒng)深度休眠喚醒: 電源鍵按下 RTC鬧鐘觸發(fā) 其他預(yù)設(shè)的喚醒源信號 5. 調(diào)試與驗證可以通過以下方
    發(fā)表于 07-22 10:45

    RK3568 EVB開發(fā)板 深度休眠與快速醒的工作流程

    RK3568 EVB開發(fā)板關(guān)于深度休眠喚醒流程的分析
    的頭像 發(fā)表于 07-22 09:49 ?848次閱讀
    RK3568 EVB開發(fā)板 深度<b class='flag-5'>休眠</b>與快速醒的工作流程

    CYW20829在ESL場景下,event和Subevent時間長短的設(shè)置是什么?

    如何? 2.任務(wù)密集時段和任務(wù)稀疏時段能否靈活更改周期?終端與AP重新約定新的周期時常的過程需要多久?喚醒周期能否設(shè)置為10秒以上,減少終端的喚醒次數(shù)? 3.這個問題是基于休眠時間較長
    發(fā)表于 07-07 07:32