高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
前言
在 Windows 系統中,並沒有像 Linux 中 SocketCAN 那樣統一的網路介面 API。 因此,每一家 CAN 廠商都必須自行提供 API 讓使用者開發 CAN 應用程式。 這代表不同廠商的 CAN 裝置都有各自專有的控制方式。 因此,提供一個清晰、高效且易於使用的函式庫至關重要, 它能大幅降低使用者的開發負擔與成本。
SDC API
SDC API 是一個簡單、高效、易用、整合度高且通用性強的函式庫。 它支援所有 SDC 系列產品,包括數位 I/O 與 CAN。 本文件將聚焦於 CAN 控制功能。
SUNCAN API 的優勢
裝置去識別化與 CAN 動態列舉
多數第三方 CAN 產品需要使用硬體識別碼來指定要控制的裝置。 SUNCAN 則透過去識別化與動態列舉來產生 CAN 索引, 使用者無需查詢任何裝置 ID。 列舉完成後,系統會直接提供所有可用的 CAN 索引, 並附帶指出每個索引對應的裝置。
extern "C" SDCIO_API INT Enumerate_can_info(PCAN_BASIC_INFO_LIST CanBasicInfoListPtr);
typedef struct _CAN_BASIC_INFO {
INT CanIndex;
UCHAR Model;
INT PciNumber;
INT Version;
} CAN_BASIC_INFO, *PCAN_BASIC_INFO;
CAN 2.0 與 CAN FD 傳輸/接收功能整合
多數第三方 CAN2.0 與 CAN FD 產品並未整合 Tx 與 Rx 功能。 SUNCAN 在 API 中新增了「CAN 類型」(CAN2.0 / CAN FD)參數, 讓使用者能透過同一組函式傳輸與接收 CAN2.0 與 CAN FD 訊框。 這大幅提升了程式碼的簡潔度與可讀性。
extern "C" SDCIO_API INT Can_write_data(INT CanIndex, UINT CanType, UINT Id,
UCHAR *Data, UINT DataLen,
UINT MessageTypeFlags, INT Timeout);
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
簡單設定 CAN FD 調變速率與資料速率
部分 CAN FD 產品需要手動設定複雜的位元定時參數來調整仲裁速率與資料速率, 例如仲裁速率 1Mbps / 資料速率 8Mbps。
"f_clock_mhz=80,nom_brp=10,nom_tseg1=5,nom_tseg2=2,nom_sjw=2,
data_brp=1,data_tseg1=7,data_tseg2=2,data_sjw=1"
使用者必須自行計算位元定時才能得到所需的速率設定。 SUNIX 了解大多數最終使用者並不熟悉這類複雜的計算, 這也會增加軟體開發者的負擔。 因此,SUNIX 已經替您預先計算好必要的數值, 使用者僅需輸入想要的仲裁速率與資料速率即可。
extern "C" SDCIO_API INT Can_set_bitrate_fd(INT CanIndex, UCHAR ArbitBitrate, UCHAR DataBitrate);
extern "C" SDCIO_API INT Can_set_bitrate_with_samplepoint_fd(INT CanIndex,
UCHAR ArbitBitrate, UCHAR DataBitrate, UINT ArbitSamplePoint, UINT DataSamplePoint);
CAN FD 硬體濾波器 (32 組可接受 ID)
多數第三方 CAN 產品需要使用者自行計算硬體濾波遮罩。 SUNIX 提供最多 32 組可直接設定的可接受 ID, 讓使用者無需進行複雜計算。
typedef struct _ID_MESSAGEFILTER_LIST {
INT IdFilterAmount;
ID_MESSAGEFILTER IdMessageFilter[32];
} ID_MESSAGEFILTER_LIST, *PID_MESSAGEFILTER_LIST;
軟體控制 CAN 終端電阻
SUNCAN 支援透過軟體控制 CAN 終端電阻, 不需要再透過實體跳線或開關來切換。
extern "C" SDCIO_API INT Can_set_termination(INT CanIndex, UCHAR Termination);
注意:部分 SUNIX CAN FD 產品仍採用硬體跳線切換終端電阻, 在此情況下軟體控制將不會生效。
兩種接收方式 – 輪詢 (Polling) 與回呼 (Callback)
在系統 I/O 通訊中,常見的方式有輪詢與事件驅動回呼,各有優缺點。 多數第三方 CAN 產品僅提供輪詢方式, 而 SUNCAN API 同時支援兩種機制, 讓使用者可依不同需求與環境自由選擇。
輪詢 (Polling)
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
回呼函式 (Callback)
typedef void(*CanReadDataCallbackFunc)(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
extern "C" SDCIO_API INT Can_set_read_data_callback(INT CanIndex, CanReadDataCallbackFunc Callback);
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
前言
在 Windows 系統中,並沒有像 Linux 中 SocketCAN 那樣統一的網路介面 API。 因此,每一家 CAN 廠商都必須自行提供 API 讓使用者開發 CAN 應用程式。 這代表不同廠商的 CAN 裝置都有各自專有的控制方式。 因此,提供一個清晰、高效且易於使用的函式庫至關重要, 它能大幅降低使用者的開發負擔與成本。
SDC API
SDC API 是一個簡單、高效、易用、整合度高且通用性強的函式庫。 它支援所有 SDC 系列產品,包括數位 I/O 與 CAN。 本文件將聚焦於 CAN 控制功能。
SUNCAN API 的優勢
裝置去識別化與 CAN 動態列舉
多數第三方 CAN 產品需要使用硬體識別碼來指定要控制的裝置。 SUNCAN 則透過去識別化與動態列舉來產生 CAN 索引, 使用者無需查詢任何裝置 ID。 列舉完成後,系統會直接提供所有可用的 CAN 索引, 並附帶指出每個索引對應的裝置。
extern "C" SDCIO_API INT Enumerate_can_info(PCAN_BASIC_INFO_LIST CanBasicInfoListPtr);
typedef struct _CAN_BASIC_INFO {
INT CanIndex;
UCHAR Model;
INT PciNumber;
INT Version;
} CAN_BASIC_INFO, *PCAN_BASIC_INFO;
CAN 2.0 與 CAN FD 傳輸/接收功能整合
多數第三方 CAN2.0 與 CAN FD 產品並未整合 Tx 與 Rx 功能。 SUNCAN 在 API 中新增了「CAN 類型」(CAN2.0 / CAN FD)參數, 讓使用者能透過同一組函式傳輸與接收 CAN2.0 與 CAN FD 訊框。 這大幅提升了程式碼的簡潔度與可讀性。
extern "C" SDCIO_API INT Can_write_data(INT CanIndex, UINT CanType, UINT Id,
UCHAR *Data, UINT DataLen,
UINT MessageTypeFlags, INT Timeout);
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
簡單設定 CAN FD 調變速率與資料速率
部分 CAN FD 產品需要手動設定複雜的位元定時參數來調整仲裁速率與資料速率, 例如仲裁速率 1Mbps / 資料速率 8Mbps。
"f_clock_mhz=80,nom_brp=10,nom_tseg1=5,nom_tseg2=2,nom_sjw=2,
data_brp=1,data_tseg1=7,data_tseg2=2,data_sjw=1"
使用者必須自行計算位元定時才能得到所需的速率設定。 SUNIX 了解大多數最終使用者並不熟悉這類複雜的計算, 這也會增加軟體開發者的負擔。 因此,SUNIX 已經替您預先計算好必要的數值, 使用者僅需輸入想要的仲裁速率與資料速率即可。
extern "C" SDCIO_API INT Can_set_bitrate_fd(INT CanIndex, UCHAR ArbitBitrate, UCHAR DataBitrate);
extern "C" SDCIO_API INT Can_set_bitrate_with_samplepoint_fd(INT CanIndex,
UCHAR ArbitBitrate, UCHAR DataBitrate, UINT ArbitSamplePoint, UINT DataSamplePoint);
CAN FD 硬體濾波器 (32 組可接受 ID)
多數第三方 CAN 產品需要使用者自行計算硬體濾波遮罩。 SUNIX 提供最多 32 組可直接設定的可接受 ID, 讓使用者無需進行複雜計算。
typedef struct _ID_MESSAGEFILTER_LIST {
INT IdFilterAmount;
ID_MESSAGEFILTER IdMessageFilter[32];
} ID_MESSAGEFILTER_LIST, *PID_MESSAGEFILTER_LIST;
軟體控制 CAN 終端電阻
SUNCAN 支援透過軟體控制 CAN 終端電阻, 不需要再透過實體跳線或開關來切換。
extern "C" SDCIO_API INT Can_set_termination(INT CanIndex, UCHAR Termination);
注意:部分 SUNIX CAN FD 產品仍採用硬體跳線切換終端電阻, 在此情況下軟體控制將不會生效。
兩種接收方式 – 輪詢 (Polling) 與回呼 (Callback)
在系統 I/O 通訊中,常見的方式有輪詢與事件驅動回呼,各有優缺點。 多數第三方 CAN 產品僅提供輪詢方式, 而 SUNCAN API 同時支援兩種機制, 讓使用者可依不同需求與環境自由選擇。
輪詢 (Polling)
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
回呼函式 (Callback)
typedef void(*CanReadDataCallbackFunc)(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
extern "C" SDCIO_API INT Can_set_read_data_callback(INT CanIndex, CanReadDataCallbackFunc Callback);
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
前言
在 Windows 系統中,並沒有像 Linux 中 SocketCAN 那樣統一的網路介面 API。 因此,每一家 CAN 廠商都必須自行提供 API 讓使用者開發 CAN 應用程式。 這代表不同廠商的 CAN 裝置都有各自專有的控制方式。 因此,提供一個清晰、高效且易於使用的函式庫至關重要, 它能大幅降低使用者的開發負擔與成本。
SDC API
SDC API 是一個簡單、高效、易用、整合度高且通用性強的函式庫。 它支援所有 SDC 系列產品,包括數位 I/O 與 CAN。 本文件將聚焦於 CAN 控制功能。
SUNCAN API 的優勢
裝置去識別化與 CAN 動態列舉
多數第三方 CAN 產品需要使用硬體識別碼來指定要控制的裝置。 SUNCAN 則透過去識別化與動態列舉來產生 CAN 索引, 使用者無需查詢任何裝置 ID。 列舉完成後,系統會直接提供所有可用的 CAN 索引, 並附帶指出每個索引對應的裝置。
extern "C" SDCIO_API INT Enumerate_can_info(PCAN_BASIC_INFO_LIST CanBasicInfoListPtr);
typedef struct _CAN_BASIC_INFO {
INT CanIndex;
UCHAR Model;
INT PciNumber;
INT Version;
} CAN_BASIC_INFO, *PCAN_BASIC_INFO;
CAN 2.0 與 CAN FD 傳輸/接收功能整合
多數第三方 CAN2.0 與 CAN FD 產品並未整合 Tx 與 Rx 功能。 SUNCAN 在 API 中新增了「CAN 類型」(CAN2.0 / CAN FD)參數, 讓使用者能透過同一組函式傳輸與接收 CAN2.0 與 CAN FD 訊框。 這大幅提升了程式碼的簡潔度與可讀性。
extern "C" SDCIO_API INT Can_write_data(INT CanIndex, UINT CanType, UINT Id,
UCHAR *Data, UINT DataLen,
UINT MessageTypeFlags, INT Timeout);
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
簡單設定 CAN FD 調變速率與資料速率
部分 CAN FD 產品需要手動設定複雜的位元定時參數來調整仲裁速率與資料速率, 例如仲裁速率 1Mbps / 資料速率 8Mbps。
"f_clock_mhz=80,nom_brp=10,nom_tseg1=5,nom_tseg2=2,nom_sjw=2,
data_brp=1,data_tseg1=7,data_tseg2=2,data_sjw=1"
使用者必須自行計算位元定時才能得到所需的速率設定。 SUNIX 了解大多數最終使用者並不熟悉這類複雜的計算, 這也會增加軟體開發者的負擔。 因此,SUNIX 已經替您預先計算好必要的數值, 使用者僅需輸入想要的仲裁速率與資料速率即可。
extern "C" SDCIO_API INT Can_set_bitrate_fd(INT CanIndex, UCHAR ArbitBitrate, UCHAR DataBitrate);
extern "C" SDCIO_API INT Can_set_bitrate_with_samplepoint_fd(INT CanIndex,
UCHAR ArbitBitrate, UCHAR DataBitrate, UINT ArbitSamplePoint, UINT DataSamplePoint);
CAN FD 硬體濾波器 (32 組可接受 ID)
多數第三方 CAN 產品需要使用者自行計算硬體濾波遮罩。 SUNIX 提供最多 32 組可直接設定的可接受 ID, 讓使用者無需進行複雜計算。
typedef struct _ID_MESSAGEFILTER_LIST {
INT IdFilterAmount;
ID_MESSAGEFILTER IdMessageFilter[32];
} ID_MESSAGEFILTER_LIST, *PID_MESSAGEFILTER_LIST;
軟體控制 CAN 終端電阻
SUNCAN 支援透過軟體控制 CAN 終端電阻, 不需要再透過實體跳線或開關來切換。
extern "C" SDCIO_API INT Can_set_termination(INT CanIndex, UCHAR Termination);
注意:部分 SUNIX CAN FD 產品仍採用硬體跳線切換終端電阻, 在此情況下軟體控制將不會生效。
兩種接收方式 – 輪詢 (Polling) 與回呼 (Callback)
在系統 I/O 通訊中,常見的方式有輪詢與事件驅動回呼,各有優缺點。 多數第三方 CAN 產品僅提供輪詢方式, 而 SUNCAN API 同時支援兩種機制, 讓使用者可依不同需求與環境自由選擇。
輪詢 (Polling)
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
回呼函式 (Callback)
typedef void(*CanReadDataCallbackFunc)(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
extern "C" SDCIO_API INT Can_set_read_data_callback(INT CanIndex, CanReadDataCallbackFunc Callback);
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
高效能、低門檻 – 使用 SUNCAN API 解鎖 CAN極限
前言
在 Windows 系統中,並沒有像 Linux 中 SocketCAN 那樣統一的網路介面 API。 因此,每一家 CAN 廠商都必須自行提供 API 讓使用者開發 CAN 應用程式。 這代表不同廠商的 CAN 裝置都有各自專有的控制方式。 因此,提供一個清晰、高效且易於使用的函式庫至關重要, 它能大幅降低使用者的開發負擔與成本。
SDC API
SDC API 是一個簡單、高效、易用、整合度高且通用性強的函式庫。 它支援所有 SDC 系列產品,包括數位 I/O 與 CAN。 本文件將聚焦於 CAN 控制功能。
SUNCAN API 的優勢
裝置去識別化與 CAN 動態列舉
多數第三方 CAN 產品需要使用硬體識別碼來指定要控制的裝置。 SUNCAN 則透過去識別化與動態列舉來產生 CAN 索引, 使用者無需查詢任何裝置 ID。 列舉完成後,系統會直接提供所有可用的 CAN 索引, 並附帶指出每個索引對應的裝置。
extern "C" SDCIO_API INT Enumerate_can_info(PCAN_BASIC_INFO_LIST CanBasicInfoListPtr);
typedef struct _CAN_BASIC_INFO {
INT CanIndex;
UCHAR Model;
INT PciNumber;
INT Version;
} CAN_BASIC_INFO, *PCAN_BASIC_INFO;
CAN 2.0 與 CAN FD 傳輸/接收功能整合
多數第三方 CAN2.0 與 CAN FD 產品並未整合 Tx 與 Rx 功能。 SUNCAN 在 API 中新增了「CAN 類型」(CAN2.0 / CAN FD)參數, 讓使用者能透過同一組函式傳輸與接收 CAN2.0 與 CAN FD 訊框。 這大幅提升了程式碼的簡潔度與可讀性。
extern "C" SDCIO_API INT Can_write_data(INT CanIndex, UINT CanType, UINT Id,
UCHAR *Data, UINT DataLen,
UINT MessageTypeFlags, INT Timeout);
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
簡單設定 CAN FD 調變速率與資料速率
部分 CAN FD 產品需要手動設定複雜的位元定時參數來調整仲裁速率與資料速率, 例如仲裁速率 1Mbps / 資料速率 8Mbps。
"f_clock_mhz=80,nom_brp=10,nom_tseg1=5,nom_tseg2=2,nom_sjw=2,
data_brp=1,data_tseg1=7,data_tseg2=2,data_sjw=1"
使用者必須自行計算位元定時才能得到所需的速率設定。 SUNIX 了解大多數最終使用者並不熟悉這類複雜的計算, 這也會增加軟體開發者的負擔。 因此,SUNIX 已經替您預先計算好必要的數值, 使用者僅需輸入想要的仲裁速率與資料速率即可。
extern "C" SDCIO_API INT Can_set_bitrate_fd(INT CanIndex, UCHAR ArbitBitrate, UCHAR DataBitrate);
extern "C" SDCIO_API INT Can_set_bitrate_with_samplepoint_fd(INT CanIndex,
UCHAR ArbitBitrate, UCHAR DataBitrate, UINT ArbitSamplePoint, UINT DataSamplePoint);
CAN FD 硬體濾波器 (32 組可接受 ID)
多數第三方 CAN 產品需要使用者自行計算硬體濾波遮罩。 SUNIX 提供最多 32 組可直接設定的可接受 ID, 讓使用者無需進行複雜計算。
typedef struct _ID_MESSAGEFILTER_LIST {
INT IdFilterAmount;
ID_MESSAGEFILTER IdMessageFilter[32];
} ID_MESSAGEFILTER_LIST, *PID_MESSAGEFILTER_LIST;
軟體控制 CAN 終端電阻
SUNCAN 支援透過軟體控制 CAN 終端電阻, 不需要再透過實體跳線或開關來切換。
extern "C" SDCIO_API INT Can_set_termination(INT CanIndex, UCHAR Termination);
注意:部分 SUNIX CAN FD 產品仍採用硬體跳線切換終端電阻, 在此情況下軟體控制將不會生效。
兩種接收方式 – 輪詢 (Polling) 與回呼 (Callback)
在系統 I/O 通訊中,常見的方式有輪詢與事件驅動回呼,各有優缺點。 多數第三方 CAN 產品僅提供輪詢方式, 而 SUNCAN API 同時支援兩種機制, 讓使用者可依不同需求與環境自由選擇。
輪詢 (Polling)
extern "C" SDCIO_API INT Can_read_data(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
回呼函式 (Callback)
typedef void(*CanReadDataCallbackFunc)(INT CanIndex, PCAN_READ_DATA_LIST CanReadDataListPtr);
extern "C" SDCIO_API INT Can_set_read_data_callback(INT CanIndex, CanReadDataCallbackFunc Callback);