伍肆參

[Python] 自動判斷並選定最優 GPU : Intel GPU(Arc A350m) , nVidia GeForce RTX 4060 or CPU

noreply@blogger.com (Unknown) — Thu, 8 Jan 2026 14:41:00 +0800

手上 Notebook A 是 Intel Arc 350m , Notebook B 卻是 RTX 4060, 又有無 GPU 的Notebook ...
.....嗯嗯... 啥都有~ 就是沒有 AMD GPU :p
由於常會更換機器使用，需要一個能自動判定/選擇最佳GPU 的 Python Function
網路上找許久都不見有人提供相似功能
在此紀錄一下，期待日後介面統一的到來

另，期待能人志士添加 AMD GPU判定辦法
暫時使用 DirectML方式偵測 AMD GPU, 功能尚未確認過
AMD使用 DirectML方式需先安裝：

pip install torch-directml

非AMD用戶不建議服用，極大可能會造成身體不適，氣血失調，驚奇不順斷：

torch-directml 0.2.5.dev240914 requires torch==2.4.1, but you have torch 2.8.0 which is incompatible.
torch-directml 0.2.5.dev240914 requires torchvision==0.19.1, but you have torchvision 0.23.0 which is incompatible.

--
Intel GPU 需要先安裝 Intel Extension for PyTorch (IPEX)

*** 注意：已確認: 目前不支援 Python 3.13以上版本！即使 3.12也僅止是測試用，官方建議使用 3.8~3.11版 !!!

python -m pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/xpu

python -m pip install intel_extension_for_pytorch --extra-index-url https://pytorch-extension.intel.com/release-whl/stable/xpu/us/

驗證(after reboot)：

python -c "import torch; import intel_extension_for_pytorch as ipex; print(ipex.__version__)"

"import intel_extension_for_pytorch as ipex" 時，可能會遇到錯誤：

ERROR! Intel® Extension for PyTorch* needs to work with PyTorch 2.8.*, but PyTorch 2.9.1+cpu is found. Please switch to the matching version and run again.

或：
torchaudio 2.9.1 requires torch==2.9.1, but you have torch 2.8.0 which is incompatible.
torchvision 0.24.1 requires torch==2.9.1, but you have torch 2.8.0 which is incompatible.

> pip install torch==2.8 torchaudio==2.8 torchvision==0.23.0

或是：

OSError: [WinError 126] The specified module could not be found.
Error loading "C:\.....\intel_extension_for_pytorch\bin\esimd_kernels.dll" or one of its dependencies.

Ref: https://github.com/intel/intel-extension-for-pytorch/issues/804#issuecomment-2840629788 (IE Only)

python -m pip install torch==2.8.0+xpu torchaudio torchvision --index-url https://download.pytorch.org/whl/xpu
python -m pip install intel-extension-for-pytorch==2.8.10+xpu --index-url https://pytorch-extension.intel.com/release-whl/stable/xpu/us/

And, Install Latest supported redistributable version by MS , and reboot

* nVidia 安裝就是舒服，直接無腦裝 torch 即可，沒有一堆囉嗦蛋酥：

pip install torch

CODE:


import torch
import sys

HAS_IPEX = False
HAS_DML = False

# 嘗試導入 Intel Extension for PyTorch
# Try to import Intel Extension for PyTorch
try:
    import intel_extension_for_pytorch as ipex
    HAS_IPEX = True
except ImportError:
    HAS_IPEX = False

# 嘗試導入 PyTorch DirectML (用於 AMD GPU 支援)
try:
    import torch_directml
    HAS_DML = True
except ImportError:
    HAS_DML = False

def get_best_device():
    """
    自動檢測並返回最佳可用設備 (Auto-detect and return best available device).
    優先級 Priority:
    1. NVIDIA GPU (CUDA)
    2. Intel GPU (XPU)
    3. AMD GPU (DirectML)
    4. CPU
    """
    
    # 1. 檢查 NVIDIA CUDA
    if torch.cuda.is_available():
        print(f"[設備] 偵測到 NVIDIA GPU: {torch.cuda.get_device_name(0)}")
        return torch.device("cuda")
    
    # 2. 檢查 Intel XPU (Arc / Iris Xe)
    # PyTorch 2.4+ 可能直接支援 torch.xpu，但通常需要 IPEX
    if HAS_IPEX and hasattr(torch, 'xpu') and torch.xpu.is_available():
        print(f"[設備] 偵測到 Intel GPU (XPU): {torch.xpu.get_device_name(0)}")
        return torch.device("xpu")
    
    # 用於舊版 IPEX 的備用方案
    if HAS_IPEX and hasattr(ipex, 'xpu') and ipex.xpu.is_available():
         print(f"[設備] 偵測到 Intel GPU (XPU via IPEX)")
         return torch.device("xpu")
    # 3. 檢查 AMD GPU (DirectML)
    if HAS_DML and torch_directml.is_available():
        # DirectML 設備 ID 通常為 0
        dml_device = torch_directml.device()
        print(f"[設備] 偵測到 AMD/DirectML GPU: {torch_directml.device_name(0)}")
        return dml_device
    # 4. 降級至 CPU
    print("[設備] 未偵測到 GPU。使用 CPU。")
    return torch.device("cpu")

def print_system_info():
    print(f"Python Version: {sys.version}")
    print(f"PyTorch Version: {torch.__version__}")
    print(f"Intel Extension (IPEX) 已安裝: {'是' if HAS_IPEX else '否'}")
    print(f"PyTorch DirectML (AMD) 已安裝: {'是' if HAS_DML else '否'}")
    
    if torch.cuda.is_available():
        print(f"CUDA 可用: 是, 版本: {torch.version.cuda}")
        print(f"GPU 名稱: {torch.cuda.get_device_name(0)}")
    else:
        print("CUDA 可用: 否")
    if HAS_IPEX:
        try:
            # 註: IPEX 版本檢查方式可能有所不同
            print(f"IPEX 版本: {ipex.__version__}")
        except:
            pass
        if hasattr(torch, 'xpu') and torch.xpu.is_available():
             print(f"XPU 可用: 是")
             print(f"XPU 名稱: {torch.xpu.get_device_name(0)}")
             
    if HAS_DML and torch_directml.is_available():
        print(f"DirectML 可用: 是")
        print(f"DirectML 設備: {torch_directml.device_name(0)}")

if __name__ == "__main__":
    print("=== Hardware Detection Info ===")
    print_system_info()
    print("\n=== Selecting Device ===")
    device = get_best_device()
    print(f"Selected Device: {device}")
    # Example Usage in Training
    # model = MyModel().to(device)
    # data = data.to(device)

* Intel Arc GPU :


Python Version: 3.12.3 | packaged by conda-forge | (main, Apr 15 2024, 18:20:11) [MSC v.1938 64 bit (AMD64)]
PyTorch Version: 2.8.0+xpu
Intel Extension (IPEX) 已安裝: 是
PyTorch DirectML (AMD) 已安裝: 否
CUDA 可用: 否
IPEX 版本: 2.8.10+xpu
XPU 可用: 是
XPU 名稱: Intel(R) Arc(TM) A350M Graphic

* nVidia RTX4060 GPU :


=== Hardware Detection Info ===
Python Version: 3.10.16 | packaged by Anaconda, Inc. | (main, Dec 11 2024, 16:19:12) [MSC v.1929 64 bit (AMD64)]
PyTorch Version: 2.1.2+cu121
Intel Extension (IPEX) 已安裝: 否
PyTorch DirectML (AMD) 已安裝: 否
CUDA 可用: 是, 版本: 12.1
GPU 名稱: NVIDIA GeForce RTX 4060 Laptop GPU

=== Selecting Device ===
[設備] 偵測到 NVIDIA GPU: NVIDIA GeForce RTX 4060 Laptop GPU
Selected Device: cuda

CAN Mask & Filter of MCP 2515 calculate

noreply@blogger.com (Unknown) — Wed, 2 Apr 2025 11:34:00 +0800

由於 CAN Bus 的 Receiver ID - MCP-2515 具有 2個Mask & 6個Filter

我們可以善加利用，過濾掉許多不需要的 Message，大大減少 MCP的負擔

但是，市面上討論 Mask & Filter 的文章超級少，這邊做個紀錄

◎ 首先，先理解 Mask & Filter 的功能 :

1. MCP-2515 有兩個 Mask + 六個Filter ，但是依據文件說明，並非一個 Mask配三個Filter！

而是：

* Mask0 配 Filter0 & Filter1 僅有兩個，使用 Buffer0

* Mask1 配 Filter2 ~ Filter5 共有四個，使用 Buffer1

由於 ext flag 是分開的，若有使用 ext的需求，甚至是混合使用的需求的，可以一個mask使用ext=1，另一個使用 ext=0；

ID使用量大的用Mask1，使用量小的用Mask0

2. Mask & Filter 計算式：

當 CAN Bus 收到一 Frame Message, #ID & Mask & Filter 間的關係計算式：

( #ID & Mask ) ?= ( Filter & Mask )

當等式成立時，後端MCU方能順利收到該條 Message !

◎ 再來，嘗試依據我們需要收到的 Message ID 反推需要設定的 Mask & Filter :

1. 當需求 ID 僅一個的時候：

Mask = 0x7ff(ext=0, 11 bits) -or- Mask = 0x1FFFFFFF(ext=1,29 bits)

Filter = #ID

2. 當需求 ID 僅兩個的時候：

我們只需要知道兩個 ID之間沒有變動的 bits, 作為 Mask 即可

期望收到 CAN #ID1 & #ID2 :
( ( #ID1 | #ID2 ) & Mask ) ?= ( Filter & Mask )
Mask := NOT ( ID1 xor ID2 )
Filter := ID1 -or- Filter := ID2

3. 當需求 ID 超過兩個的時候：

目標：找出各ID間重複出現 0 & 1 的 bits 作為Mask

重複出現 1 的 bit

Mask1 := ( #ID1 and #ID2 and #ID3 and ... )

重複出現 0 的 bit

Mask0 := not ( #ID1 or #ID2 or #ID3 or ... )

重複出現 0 & 1 的 bits

MASK := Mask1 or Mask0 := ( #ID1 and #ID2 and #ID3 and ... ) or ( not ( #ID1 or #ID2 or #ID3 or ... ) )
FILTER := #IDx and MASK

[Cheat code] Age of Mythology + The Titans

noreply@blogger.com (Unknown) — Sun, 16 Mar 2025 11:14:00 +0800

◎ 資源類
JUNK FOOD NIGHT	增加 1000 食物
TROJAN HORSE FOR SALE	增加 1000 木材
ATM OF EREBUS	增加 1000 黃金
MOUNT OLYMPUS	最大化 Favor 值
ENGINEERED GRAIN	提升農田產出/瞬間讓群居動物肥壯
FEAR THE FORAGE	行走的金牛莓叢
◎ 單位與建築類
WUV WOO	召喚飛行的紫色河馬
GOATUNHEIM	將所有單位變成山羊
I WANT TEH MONKEYS!!!1!	生成 100 隻猴子
BARKBARKBARKBARKBARK	生成特殊寵物狗(Basket the dog)
TINES OF POWER	生成一個“叉子小子”單位
O CANADA	快速熊
L33T SUPA H4X0R	所有建築物立即完成
◎ 地圖與視野類
SET ASCENDANT	揭露整張地圖
LAY OF THE LAND	開啟地圖但保留迷霧
UNCERTAINTY AND DOUBT	隱藏所有玩家的地圖視野
RED TIDE	遊戲中的水變為紅色
LETS GO! NOW!	加快(2個空白?)
IN DARKEST NIGHT	白天/黑夜
◎ 神力與特殊效果類
DIVINE INTERVENTION	可以重複使用已使用的神力
WRATH OF THE GODS	獲得強大的神力（例如雷電風暴、地震等）
PANDORAS BOX	隨機生成一個神力或效果
BAWK BAWK BOOM	降下爆炸雞的神力
CONSIDER THE INTERNET	立刻增加 10% Favor
ISIS HEAR MY PLEA	免費建造所有神廟
◎ 關卡
THRILL OF VICTORY	立即獲勝
CHANNEL SURFING	跳到下一關
◎ Titan 專屬
TITANOMACHY	召喚一個強大的泰坦單位
MR. MONDAY	給泰坦 AI 提供 1000% 增益
TITANS BE GONE	快速移除所有泰坦單位
ATLANTEAN NO MORE	讓亞特蘭提斯單位轉換為其他文明單位
ZENOS PARADOX	讓所有單位移動速度變得非常緩慢
DECONSTRUCTIVE CRITICISM	摧毀所有敵方建築物
ATLANTIS REBORN	召喚英雄單位 Amanra
RESET BUTTON	將所有單位還原到他們的出生地點或起始位置
TINFOIL HAT	所有人戴帽

[NXP][S32K14x 功能安全特性] EIM/ERM 功能驗證

noreply@blogger.com (Unknown) — Thu, 22 Aug 2024 17:01:00 +0800

NXP S32K14x 作為一車規級的晶片，晶片本身是支援功能安全相關的特性，晶片的功能安全等級是ASIL-B等級。

從以下功能安全手冊的描述可以看到S32K14x 晶片的FLASH/SRAM 是支援硬體ECC校驗機制，支援 SEC/DED 演算法修正1bit 錯誤及多bit 錯誤檢出機制。

S32K14x 有4K FlexRAM 位在 1400_0000h ~ 1400_0FFFh

S32K11x 僅有 2K FlexRAM 位在 1400_0000h ~ 1400_07FFh

以及 1K SRAM 位於 1FFF_FC00h ~ 1FFF_FFFFh

ECC 功能如果軟體要驗證的話，正常情況下是不會觸發bit 錯誤異常的，正常情況這個異常是很難觸發的，軟體如果要驗證這個功能需要怎麼觸發驗證呢，EIM是個錯誤注入模組可以對數據線及ECC碼進行注入錯誤驗證，確保ECC功能的安全可靠，以下是EIM模組的框體，從框圖能夠看出EIM 模組可以控制對應的bit 讀取的資料發生位元反轉。

從如下框圖也可以看出來CPU 透過LMEM（Local Memory Controller）單元存取RAM 資源中間是途經EIM模組，從而EIM 完成對應的路徑的注錯驗證診斷RAM ECC 功能。

EIM 能夠注入錯誤，注入的錯誤如何被檢出報告，S32K內部還有個ERM模組這個模組能檢出SRAM 是否發生了ECC 錯誤及ECC錯誤的類型，並具有中斷信號輸出通知到CORE 的能力， ERM 的介紹如下：

EIM 單bit 錯誤注入驗證

我們使用SDK 的配置接口，使能配置EIM/ERM 透過EIM 注入1bit 錯誤，然後讀取ERM 狀態寄存器判斷注入錯誤狀態是否成功是否按照預期的檢測出ECC錯誤，對應的測試代碼如下：

eim config:

/**
* @page misra_violations MISRA-C:2012 violations
*
* @section [global]
* Violates MISRA 2012 Advisory Rule 8.7, External variable could be made static.
* The external variables will be used in other source files in application code.
*
*/

/* Channel configurations */
const eim_user_channel_config_t eim_InitConfig0[EIM_CHANNEL_COUNT0] =
{
/* Channel configuration 0 */
{
.channel = 0U,
.checkBitMask = 0U,
.dataMask = 1U,
.enable = true
}
};

erm config:

/* Interrupt configurations */

/* Interrupt configuration 0 */
const erm_interrupt_config_t erm_Interrupt0 =
{
.enableSingleCorrection = true,
.enableNonCorrectable = true
};

/* ERM configurations */

/* ERM configuration 0 */
const erm_user_config_t erm_InitConfig0[ERM_CHANNEL_COUNT0] =
{
/* Channel configuration 0 */
{
.channel = 0U,
.interruptCfg = &erm_Interrupt0
}
};

測試程式碼：

#include <stdio.h>
#include <rtthread.h>
#include <rtdevice.h>
#include <board.h>

int eim_correct(void)
{
uint32_t test;
uint32_t addr;
erm_ecc_event_t retValue = ERM_EVENT_NONE;

/* Initialize address used to test */
*(uint32_t *)0x1FFFFFF0U = 0U;

/* Hardware initialization */
/* Initial for ERM module */
ERM_DRV_Init(INST_ERM_CONFIG_1, ERM_CHANNEL_COUNT0, erm_InitConfig0);
/* Initial for EIM module */
EIM_DRV_Init(INST_EIM_CONFIG_1, EIM_CHANNEL_COUNT0, eim_InitConfig0);

/* Read any address on RAM */
/* Enable read region Ram (0x1FFF8000 - 0x20006FFF) when debug equal Flash */
test = *(uint32_t *)0x1FFFFFF0U;
(void)test;

/* Deinit EIM module */
EIM_DRV_Deinit(INST_EIM_CONFIG_1);

/* Check error and get address which EIM injection error */
retValue = ERM_DRV_GetErrorDetail(INST_ERM_CONFIG_1, 0U, &addr);

rt_kprintf("erm status %s error addr is 0x%08x\n",\
retValue == ERM_EVENT_NONE ? "ERM_EVENT_NONE" :\
(retValue == ERM_EVENT_SINGLE_BIT ? "ERM_EVENT_SINGLE_BIT" :\
(retValue == ERM_EVENT_NON_CORRECTABLE ? "ERM_EVENT_NON_CORRECTABLE" : "ERM_EVENT_NONE")),\
addr);

return 0;
}
MSH_CMD_EXPORT_ALIAS(eim_correct, eim1 ,eim correct test);

執行上述測試程式碼，輸入eim1 測試指令，ERM 模組已經按照預期的偵測到 Single bit 錯誤。

ERM 單bit 錯誤中斷驗證

在上述程式碼的基礎上追加ERM 中斷啟用，查看中斷函數能否被正常執行，對應程式碼修改如下：

輸入測試命令,中斷處理函數內部已經捕獲但位元錯誤並清除掉該錯誤標誌。

如果看的仔細會發現中斷的形式EPM報出來的位址和直接查詢狀態時對應的位址時不同的，中斷的方式我們用來triger 讀取的是0x1FFFFFF0U 的測試位址，為什麼中斷報出來的是0x1fff00f0,這是因為觸發中斷的時候回去讀取中斷向量表，我們的中斷向量表是在SRAM裡，我們debug 查下0x1fff00f0儲存的是不是對應的中斷函數。透過下圖可知道確實是中斷向量，所以EPM 記錄的是最後一次觸發的一場位址。

EIM 多bit 錯誤注入驗證

驗證完了單bit ECC異常，我們修改EIM 的配置往ECC區域注入多bit 錯誤看看是否也會跟上面一樣觸發中斷。

修改EIM 配置：

const eim_user_channel_config_t eim_InitConfig1[EIM_CHANNEL_COUNT1] =
{
/* Channel configuration 0 */
{
.channel = 0U,
.checkBitMask = 3U,
.dataMask = 0U,
.enable = true
}
};

新增如下測試指令eim2：

/*!
\brief The ERM_ISR funcion invert state Led
*- Clear event when have notify interrupt
*/
void erm_doublebit_isr(void)
{
uint32_t addr;
erm_ecc_event_t retValue = ERM_EVENT_NONE;

/* Deinit EIM module */
EIM_DRV_Deinit(INST_EIM_CONFIG_1);

/* Check error and get address which EIM injection error */
retValue = ERM_DRV_GetErrorDetail(INST_ERM_CONFIG_1, 0U, &addr);

rt_kprintf("erm isr status %s error addr is 0x%08x\n",\
retValue == ERM_EVENT_NONE ? "ERM_EVENT_NONE" :\
(retValue == ERM_EVENT_SINGLE_BIT ? "ERM_EVENT_SINGLE_BIT" :\
(retValue == ERM_EVENT_NON_CORRECTABLE ? "ERM_EVENT_NON_CORRECTABLE" : "ERM_EVENT_NONE")),\
addr);
/* The interrupt notification will be cleared.*/
ERM_DRV_ClearEvent(INST_ERM_CONFIG_1, 0U, ERM_EVENT_NON_CORRECTABLE);
}

int eim_double_bit(void)
{
uint32_t test;
uint32_t addr;
erm_ecc_event_t retValue = ERM_EVENT_NONE;

/* Initialize address used to test */
*(uint32_t *)0x1FFFFFF0U = 0U;

/* Install IRQ Handlers for ERM and SysTick */
INT_SYS_InstallHandler(ERM_double_fault_IRQn, erm_doublebit_isr, (isr_t *)0);
/* Enable ERM IRQ */
INT_SYS_EnableIRQ(ERM_double_fault_IRQn);

/* Hardware initialization */
/* Initial for ERM module */
ERM_DRV_Init(INST_ERM_CONFIG_1, ERM_CHANNEL_COUNT0, erm_InitConfig0);
/* Initial for EIM module */
EIM_DRV_Init(INST_EIM_CONFIG_1, EIM_CHANNEL_COUNT1, eim_InitConfig1);

/* Read any address on RAM */
/* Enable read region Ram (0x1FFF8000 - 0x20006FFF) when debug equal Flash */
test = *(uint32_t *)0x1FFFFFF0U;
(void)test;

/* Deinit EIM module */
EIM_DRV_Deinit(INST_EIM_CONFIG_1);

/* Check error and get address which EIM injection error */
retValue = ERM_DRV_GetErrorDetail(INST_ERM_CONFIG_1, 0U, &addr);

rt_kprintf("erm status %s error addr is 0x%08x\n",\
retValue == ERM_EVENT_NONE ? "ERM_EVENT_NONE" :\
(retValue == ERM_EVENT_SINGLE_BIT ? "ERM_EVENT_SINGLE_BIT" :\
(retValue == ERM_EVENT_NON_CORRECTABLE ? "ERM_EVENT_NON_CORRECTABLE" : "ERM_EVENT_NONE")),\
addr);

return 0;
}
MSH_CMD_EXPORT_ALIAS(eim_double_bit, eim2 ,eim uncorrect test);

輸入eim2 指令驗證：

從上面的log 可知，已經按照預期的觸發了不可糾正ECC錯誤，對應的地址和上面的單bit異常的地址是相同的原因是中斷向量表的地址相同。

*** ref : https://www.nxpic.org.cn/module/forum/thread-802634-1-1.html ***

[NXP][S32K144] CAN UJA1169 SBC chip Hard Reset Circuit Connection

noreply@blogger.com (Unknown) — Mon, 29 Apr 2024 11:26:00 +0800

手上有塊 NXP S32K144 EVB，
結果，被用到 原本可以正常 CAN通訊的 被用到 CAN直接無訊號輸出。
想著要針對 SBC的UJA1169 做硬體 Reset, 網路上僅找到 對 S32K118 Reset的文章
找不到針對 144的相關說明


144跟 118一樣，需要對 UJA1169 做以下動作，才能順利完成硬體Reset:
1. UJA1169 RST 腳位低電平
2. CAN_H 接 VBAT
3. CAN_L 接 GND
4. 保持上電至少 td(MTPNV) 時間 ，約 0.9 ~ 1.1s 。


自己翻閱電路圖才發現 144跟118有許多地方不同
* 首先， 144的CAN接線 已經針對電阻部分 接上兩個 Jumper, 直接拔掉即可；不需要像 118依樣 需要動到烙鐵 解焊!
* 再來， 144已經針對 Reset腳，拉出了個 TP點，直接拉出GND訊號，碰觸該TP點一秒即可
* 最後， 118 CAN接口的 Pin 3是接VBATT電源，但 144的 CAN J13 pin3卻是空接 

最後決定直接拉 CAN 自己的 第4 pin GND來接 Pin2
偷用LIN pin2的VBATT接地來用接CAN Pin1
再借用 J3第13腳的GND來接TP24 RST 

最後接線如圖

常用 CAN bus 相關名詞英文縮寫

noreply@blogger.com (Unknown) — Wed, 21 Feb 2024 08:55:00 +0800

常見CAN bus相關縮寫

方便查詢

縮寫	英文全稱	中文含意
CAN	Control Area Network	CAN總線
DoCAN	Diagnostic Communication over CAN	基於CAN的診斷通訊
ECU	Electronic Control Unit	電子控制單元
SF	Singal Frame	單禎
FF	First Frame	首禎
CF	Consecutive Frame	後續禎
FC	Flow Control	流控制禎
FS	Flow Status	流量控制狀態
FF_DL	First Frame Data Length	首禎數據長度
FMI	Failure Mode Indicator	失效模式指示
OBD	On-Board Diagnostics	車載診斷系統
OSI	Open System Interconnection	開放型系統互聯
PCI	Protocol Control Information	控制信息協議
SN	Sequence Number	序號
SPN	Suspect Parameter Number	可疑參數序號
UDS	Unified Diagnostic Service	統一診斷服務
SID	Service ID	服務識別碼
RSID	Response Service ID	服務識別碼回覆
WWH-OBD	World-Wide Harmonized OBD	全球統一重型發動機的車載診斷系統
NW	Network	網路層
NWL	Network Layer	網路層
Mtype	Message Type	信息類型
STmin	Separation Time Minimum	最小的間隔時間
CTS	continue to send	繼續發送
BS	Block Size	塊(Block)的大小
DL	Data Length	數據長度

縮寫	英文全稱
Mtype	Message Type
N_AE	Network Address Extension
N_AI	Address Information
N_Ar	Network Layer Timing Parameter Ar
N_As	Network Layer Timing Parameter As
N_Br	Network Layer Timing Parameter Br
N_Bs	Network Layer Timing Parameter Bs
N_ChangeParameter	Network Layer Service Name
N_Cr	Network Layer Timing Parameter Cr
N_Cs	Network Layer Timing Parameter Cs
r	receiver
s	sender
N_Data	Network Data
N_PCI	Network Protocol Control Information
N_PCItype	Network Protocol Control Information Type
N_PDU	Network Protocol Data Unit
N_SA	Network Source Address
N_SDU	Network Service Data Unit
N_TA	Network Target Address
N_TAtype	Network Target Address Type
N_USData	Network Layer Unacknowledged Segmented Data Transfer Service Name
NWL	NetWork Layer
request	resuest service primitive
indication	indication service primitive
SN	Sequence Number
STmin	Separation Time Min.

CAN Bus 工作原理 - 資料連結層

noreply@blogger.com (Unknown) — Tue, 20 Feb 2024 10:57:00 +0800

前面提到 CAN bus物理層的工作原理
現在來聊聊Layer 2的工作



借用一下 Wiki圖片，看不到圖片的，請另開新頁，上 Wiki瀏覽：

* 參考 [訊框] 後 [基本訊框格式] 圖示

首先， 當 CAN bus上 無通訊時，CAN bus處於 1(隱性)狀態。
當 有人需要開始傳送資料時，會將 CAN bus電壓拉開，處於 0（顯性）狀態；
此時 同bus上的其他人，將會知道有人要傳送資料，而處於靜默狀態。
若不幸的，有兩個以上設備，在同一時間點，均想要傳送資料，同一時間將 SOF(Start Of Frame)提升至 0（顯性）狀態 ... 

* SOF
1 bit Start Of Frame


	a. 緊接於 SOF後面的，即是 Message ID ！ 
		 - 之前有提到 不能有人共用相同 Message ID，所以，此處 ID肯定會不相同，則...
	b. 於 Message ID 送出 1(隱性)狀態 bit 的設備，於送出 1(隱性)狀態 bit後，
		 - 必須監聽此時的 CAN bus是否真實處於 1(隱性)狀態:
		i. 若是，則 繼續發送
		ii. 若否，則 CAN bus上，肯定有其他設備也正在發送資料，且 Message ID較自己優先；則 自己閉嘴，不再繼續發送資料。

當 設備發送完 Message ID後，此時 碰撞機制及仲裁機制，均已完成(除RTR外) !!

* RTR
1 bit Remote transmission request
當 有節點需要別人提供資料，則 送出 "別人的 Message ID" ！ 並加上 RTR！
此時 是 要求 "別人傳送資料" ！ 而不是自己要送出資料！
但是，當 相同 Message ID的擁有人，恰好也正在送資料？
此時 即借鑑上述仲裁機制：
	1. RTR = 0；資料訊框中為顯性
	2. RTR = 1；遠端訊框中位隱性
提出 RTR需求的人，自然會閉嘴!!


* IDE
1 bit 拓展訊框格式
IDE=0，表示此Frame為 Base frame format(基本訊框格式)， Message ID僅為前方 11 bits
IDE=1，表示此Frame為 Extended frame format(拓展訊框格式)， Message ID高達 29 bits
IDE=1具有兩段 Message ID，除了上述格式完全相同外，後面新增添了另一段 Message ID；
(應該是後來發現僅 11 bits的 Message ID不夠使用了 才如此修改添加的？)
IDE=1 的 拓展訊框格式 暫時不多解釋 


*R0
1 bit 預留位
實際被 CAN FD拿來表示為 CAN FD格式


* DLC(Data Length Code)
顧名思義，即為後方緊接著的 資料欄位 長度
占用 4 bits，可以表達數字 0~15；但 礙於規定，於 IDE=0(Base frame format)下，最大值僅能設定為 =8
於 Base Frame Format下，設定 值 8-15 均會被解釋為 =8


* Data 
可以是 0 bytes, 最多僅能使用 8 bytes (IDE=0, Base frame format)
(據說是怕占用到其他設備通訊太久時間，才定這麼短的?)


* CRC & CRC定界符
CRC 15 bits
CRC定界符 1 bit
該Bus上的所有設備，均須計算 CRC； 
由傳送此Frame的人傳送該CRC資料
其他設備做CRC檢驗！
Sender固定對CRC定界符送出 =1 訊號！
除了自己以外的其他設備 檢測到，Frame中CRC與自己計算出的CRC值：
	a. 相符，則 幫忙填寫 CRC定界符 為 =0
    b. 不相符，則 什麼都不用做!!
只要有一個其他設備將 CRC定界符 設定為 =0，則 CRC定界符即為 =0
此時表示 CRC正確！ 或者說 至少有一人收到正確的 CRC值
此時， Frame CRC check也完成 並被回報給Sender知曉
省去了 遭遇碰撞後重傳時間，也省去了詢問/等待CRC等錯誤回報時間 


* EOF
7 bits End of Frame
固定為 =1
表示 該Frame結束


* IF
3 Bits+ 訊框間內容(?)
至少 三個連續的1 組成(不確定是否包含 EOF的1，抑或EOF外再添加?)
其後的第一個 =0 bit 將會被視為 下一個 Frame的開始(SOF) 


此處還要另外說明一下 位填充 機制
如果 你是直接使用 示波器下去做檢視
偶爾會出現Frame中多1 bit的狀況
這不是雜訊!!!這不是雜訊!!!這不是雜訊!!!
而是位填充機制：
所以， sender在 相同極性的五個連續bit後 插入一個相反的極性的bit訊號 
CAN bus上 出現 連續6個相同bits，會被視為錯誤
此亦為錯誤檢測機制的一部分
若是自行撰寫 RAW Data轉換的人，解碼時 請記得優先將此bit拿掉 才是真正的Frame Data !!!


也由於這種仲裁機制，這就意味著 Message ID較小的frame有著較高的傳送優先權
所以，在設計/設定Message ID的時候，比較重要 攸關性命 需要及時反映的設備，務必使用較小ID
相反的，不重要的東西， 就給他丟到最後面幾個ID讓他慢慢被碰撞吧... 
不會有人希望見到自己的安全氣囊，比別人家的，慢個半秒鐘才做動吧!?

CAN Bus 工作原理 - 物理層

noreply@blogger.com (Unknown) — Tue, 30 Jan 2024 15:53:00 +0800

作為 車用通訊 車用匯流排標準 的 
控制器區域網路 (Controller Area Network，簡稱CAN或者CAN bus) 

首先，先了解硬體架構： 
CAN Bus通訊 僅使用兩條電線相連，一條高電壓，名曰 CAN+(CAN High)；
另一條是低電壓，名曰 CAN-(CAN Low)
通常使用 5V電壓，所有設備皆拉兩條 CAN+/-出來，跟別人的CAN+/- 接在一起，
中間並需接上120Ω的電阻，俗稱 終端電阻。
自己的CAN+線 接別人的CAN+線，CAN-接別人的CAN-。
CAN Bus無所謂的 Master/Host，不需要找特定主機 逐一訊問(俗稱Polling)。
只要自己開機完 通訊準備完畢，就可以開始發送訊號。

每條CAN bus上，最少需要兩個設備在線！ 
因為 通訊中有個ACK訊號，需要別台機器幫忙發送確認。
同時作為他台機器確認收到正確完整封包的指示。
通訊期間，一般不會如同其他Bus般 : 
稱呼高低電壓為 0/1(因為CAN+與CAN-恰好電壓是相反的)，
而是稱 顯性及隱性 (理由下面說明)
平時無通訊期間，CAN bus上皆為 隱性（1)訊號！
隱性（1) 訊號時， CAN+為低電壓； CAN-為高電壓。
顯性（0）訊號時， CAN+為高電壓； CAN-為低電壓。
CAN bus晶片，僅以CAN+及CAN-之間的電壓差，作為0或1的判定標準；
俗稱： 差分訊號。

例如： 
雖然 CAN+有高達 2.8V電壓，但 CAN-此時也有2.4V訊號；
此時CAN chip仍判定Bus上訊號為 隱性（1) 訊號
§ 依據 ISO 11898-2規範 ： 
 
Vdiff>=1.5V 視為 顯性（0）；

Vdiff<=0.5V 視為 隱性（1)。
 
理解工作原理 才能順利記憶 
關於 CAN Bus背後的工作原理：

問：
 
一條 5V的電線，與一條 0V電線，中間 串接一 120Ω的終端電阻；
斷電後，若不持續外加電壓，此時兩條線的電壓會是多少？ 



是的，這就是 CAN bus的動作原理
當 CAN+電壓向上提升至 5V, CAN-向下降至0V後；只要後續不在繼續施加電壓，
這兩條線 就會藉著 120Ω的終端電阻 
迅速降/升至兩條電線 趨近於相同電壓 (差分電壓 ≈ 0V)。
此時 就是前面說的 隱性（1) 訊號 狀態！ 
當 沒有人需要送資料時，CAN bus也是保持在這狀態下。故稱呼為 隱性。

相反，當有人需要傳送資料時，就會將電壓拉開；亦就是 顯性（0）訊號。
...

再來，這樣的機制，該如何解決： 
『"同時間"有兩個以上設備 皆想要送出資料』 的 碰撞 狀況！

當設備發出訊號時，他們發送訊號時，同時間仍會持續監聽Bus上的通訊狀況
當 有兩個以上設備同時發出訊號時，只要 發送 隱性（1) 訊號的設備，
發現 Bus上 仍然保持在 顯性（0）訊號 上！ 他就能知道，有其他設備 也同時正在發送訊號！
此時的他 就進入 shut up模式，等別人順利發送完訊號再說！
如此簡單的機制，就輕鬆解決的碰撞的問題！


別人如何知道 收到 的訊息 是完整，正確且有效的？
◎ CRC
首先，要讓別人知道 他由CAN Bus上 收到的訊息，
是否是正確有效的，那 我就必須要在我送出的封包中 加上CRC訊息。
CRC 簡單的說 就是我將前面發送的訊息做運算後，填入CRC欄位；
收到訊息的人，運用相同的計算方法去計算CRC值；如果跟我送出的CRC不相同，
那就表示這通訊中間有被干擾。(我送出0他收到的卻是1,或是相反。)
此時，CRC驗證不成功的人，就電電不出聲(因為有可能整條Bus上 只有他一個人收到錯誤訊息)

那 我又要如何能知道，『我完整發送完的訊息』，已經被別人「正確收到」呢？
◎ ACK機制
在整個封包發送機制過程中，發送訊息的人 在送完CRC後，
會送出一個 顯性（0）訊號，然後 接著發送一個 隱性（1) 訊號
確認完 上述CRC正確的設備，會在此時 將該 隱性（1) 訊號 
更改為 顯性（0）訊號！ 一般稱這一個訊號叫 ACK確認槽！
一方面表示 他已經收到，另一方面表示 他收到的封包是正確有效的！
發送端 發現自己送出的這一個 隱性（1) ACK訊號，被別人更改為 顯性（0）訊號！ 
那 他就明白 已經有人收到此訊息，並驗證成功！ 此條訊息發送完畢！ 
在再送出一個 顯性（0）訊號 ，通知別人收到此ACK訊息後，這段訊息傳送工作就算結束！ 
然後 就進入 全員靜默狀態...  整條Bus均為 顯性（0）訊號，至少持續 7個bits長度 ... 
...然後 等待下一個設備發出訊號...

簡單說完...
CAN Bus 背後原理 就是這麼簡單
平時Bus上 均無人主動送出電壓訊號，故 CAN_H與 CAN_L 兩線，會逐漸趨向相同電壓 → 隱性（1）訊號
當有人需要送出資料時，先將CAN_H及CAN_L電壓拉開，通知其他人已經開始傳送資料 → 顯性（0）訊號
當送出 1 bit的 顯性（0）訊號 作為起始位(SOF) 後， 就啟動了仲裁位(ID)的仲裁機制（稍後詳聊）：

1. 當 兩個以上 ECU同時傳輸ID位資料時，先送出 bit 1(隱性) 的 ECU 將失去話語權
2. 由於電器特性，只要Bus上 有一人將 CAN_H及CAN_L 電壓拉開，
形成顯性（0）訊號，則 CAN Bus上 將僅會出現顯性（0）訊號，而不會出現隱性（1）訊號
3. 承上，送出訊號 1(隱性) 的 ECU，只需要回頭檢查 CAN Bus上：
當前訊號是否不是隱性（1）訊號；就知道自己仲裁失敗，應該閉嘴

Wiki這邊有個很好的例子：
參考 #資料傳輸 下面的表格
同一條 CAN Bus上，有 Node 15 & Node 16 兩個設備，在同一個時間點 要傳送資料出去；則 
... 依上所述，前半部 資料相同部分，雙方持續傳送資料；... 直至 "先送出1的人閉嘴" 

由於能傳送 8 bytes，所以 一道訊息，最多能傳送 (8 bytes * 8 bits) = 64 種 現場設備狀態，或是控制訊號
但是，一台設備 需要傳送/接收的訊息，通常不只上百種
所以，同一台設備 是極有可能同時背負著許多不同的 Message ID，用來表示許多不同的設備狀態或是動作要求 
實際運用上，(除UDS外)也多定義 一台設備，配備多條不同Message ID的訊息來傳送資料 或接收控制訊號
由於Message ID同時兼顧了碰撞仲裁機制，所以 同一條Bus上，
不允許出現有 不同設備使用相同Message ID的狀況發生

伍肆參

[Python] 自動判斷 並選定 最優 GPU : Intel GPU(Arc A350m) , nVidia GeForce RTX 4060 or CPU