2023年8月28日 星期一

J1850 J1939 K-Line (ISO 9141) LINBUS CANBUS FlexRay MOST BroadR-Reach

Reference Difference Between LIN, CAN, MOST, FlexRay, Communication Protocols
Reference Serial Communications Protocols - CAN and LIN
Reference Bus Systems – CAN/FD, FlexRay, Ethernet, LIN, MOST, K-Line in use

LIN : Local Interconnect Network
CAN: Controller Area Network
MOST: Media Oriented System Transport

01. Application

  • The LIN protocol is used in a low-level communication system. It may be used to make a connection between sensors and controllers. For example: In the body of the vehicle.
  • CAN is used in soft real-time systems. For example: In engines, power trains, chassis, battery management systems, etc.
  • FlexRay is used in a hard real-time system. For example: In power trains, chassis.
  • MOST are used in media-related applications and control in automotive. For example: In multimedia, telematics, etc.

02. Architecture

  • LIN has a single master and typically 2 to 10 slaves.
  • CAN has a multi-master and typically 10 to 40 nodes.
  • FlexRay has a multi-master and up to 64 nodes.
  • MOST also have multi-master and up to 64 nodes.

03. Bus Access

  • LIN has polling bus access
  • CAN has CSMA/CA bus access
  • FlexRay has TDMA/FTDMA bus access
  • MOST have TDM CSMA/CS bus access

04. Topology

  • LIN has a bus topology
  • CAN also have bus topology
  • FlexRay has BUS/Star topology
  • MOST have a ring/star topology

05. Message Transmission

  • In LIN, message transmission is synchronous.
  • In CAN, message transmission is asynchronous.
  • In FlexRay, message transmission is synchronous and asynchronous.
  • In MOST also, message transmission is synchronous and asynchronous.

06. Data Rate

  • In LIN, the data rate is 20 Kbps.
  • In CAN, the data rate is 1 Mbps.
  • In CAN FD, the data rate is upto 15 Mbps.
  • In FlexRay, the data rate is 10 Mbps.
  • In MOST, the data rate is 24 Mbps.
  • In BroadR-Reach, the data rate is 100 Mbps.

07. Data Bytes Per Second

  • In LIN, the data bytes per second is 0 to 8.
  • In CAN, the data bytes per second is 0 to 8.
  • In FlexRay, the data bytes per second is 0 to 254.
  • In MOST, the data bytes per second is 0 to 60.

08. Physical Layer

  • An electrical single wire is used in the LIN protocol.
  • The electrical dual wire is used in CAN protocol.
  • Dual wire – optical or electrical wire is used in FlexRay.
  • The optical fiber cable is used in MOST.

Serial Communications Protocols - CAN and LIN

 Mark Harris 
|  Created: August 16, 2021  |  Updated: June 25, 2023
Serial Communications Protocols - CAN and LIN

Table of Contents

In this article, we will be looking at the popular CAN and LIN protocols together. This article is part of the series Serial Communication Protocols. We hope this resource will prove invaluable on the next occasion when you find yourself implementing a serial communication bus as part of your design. We aim to help you choose the best option for your circumstances.

CAN Bus

CAN stands for Controller Area Network and is a communication protocol used by various electronic devices. CAN is often used to provide communications between devices in vehicles, like engine management systems, active suspension, ABS, gear shift control, lighting control, air conditioning, airbags, central locking system, and other systems found in a vehicle.

CAN is a high integrity serial data communication bus ideal for real-time applications. The bus can operate at data rates of up to 1 Mbps and has excellent error detection and correction capabilities. CAN was developed by Bosh with its primary application being for automotive applications, but it is now also in many industrial automation and control applications.

CAN is a multi-master, message-based protocol. This means that all the CAN devices can transmit data, and several CAN devices can request the use of the bus simultaneously. CAN network has no addressing system and instead uses a prioritized message system. All the messages are divided into a range of priorities.

SPICE: Certainty for All Decisions

Design, validate, and verify the most advanced schematics.

There are several versions of CAN bus in use today, which include:

  • CAN 2.0A – Uses an 11-bit Message Identifier
  • CAN 2.0B - Uses a 29-bit Message Identifier
  • CAN FD - Uses a Flexible Data Rate

In a CAN bus, a transmitting device sends a message to all the CAN nodes, and each node decides how to react to the received message. Also, the nodes determine each message’s priority if several messages are sent at the same time.

The simplified message flowchart
The simplified message flowchart

There are three different speed types for CAN buses, which are:

  • Low Speed - 125 kbps data rate and 500 meters maximum bus length
  • High Speed (or Hi-Speed) - 1 Mbps data rate and 40 meters maximum bus length
  • Flexible Data Rate - 15 Mbps data rate and 10 meters maximum bus length

CAN bus uses differential transmission lines and therefore does not require a ground connection. 120 Ω termination resistors are used at each end of the differential lines, as shown in the circuit diagram below.

Simple CAN wiring example with 120 Ω termination resistors at the ends
Simple CAN wiring example with 120 Ω termination resistors at the ends

A differential pair transmission line is much more robust and immune from environmental interference and noise. This is because the two signal wires are kept very close to each other, so when the electromagnetic interference affects one transmission line, it will equally affect the other. Because there is no reference ground in a differential pair, the CAN bus voltage is measured from the difference between the paired differential transmission lines.

Easy, Powerful, Modern

The world’s most trusted PCB design system.

Electromagnetic disturbance affecting both differential pair wires
Electromagnetic disturbance affecting both differential pair wires

In the CAN differential transmission lines, the dominant logic level is low or 0, while the recessive logic level is high or 1.

Below is a complete CAN protocol frame for a standard 11-bit message:

CAN data message frame
CAN data message frame

The message begins with the Start Frame, which indicates the start of the message. Usually, the CAN bus will be in an idle state (1), so to identify the beginning of the message, the dominant 0 signal is sent, which wins over recessive 1.

This is followed by the Arbitration Field, which indicates the priority of the data. The transmitters identify a message priority when they start to send a message. If multiple transmitters send a message simultaneously, they detect this when they detect they are sending recessive logic level 1 but the actual Arbitration Field bit on the bus is a dominant level 0. This tells the affected transmitter to delay transmitting, as it is not the highest priority. This continues until only one transmitter is left to send its message. Once this message has been sent, the other lower priority transmitters restart the process. This repeats until all the messages have been sent in the order of priority, as shown below:

CAN message priority competition
CAN message priority competition

The next bit is the Remote Transmission Request. This bit shows what the format of the message frame will be. It can be a Data Frame, which is used when the transmitter sends information and is indicated by being set to the dominant logical 0. Alternatively, it can be a Remote Frame, where the transmitter requests information and is denoted by being set to the recessive logical 1.

Easy, Powerful, Modern

The world’s most trusted PCB design system.

The next bit is the ID extension. If the ID extension is set to the dominant logical 0, then the Arbitration field will be a standard 11 bits in length, which is sufficient for 2048 different identifications. If this bit is set to the recessive level 1, then the Arbitration field will be extended 29 bits in length, which is sufficient for 536870912 different identifications. The additional 18 bits of the Arbitration field following the ID extension bit.

The next bit is reserved, and it usually is set to a dominant logic level 0 but setting to the recessive logic level 1 will have no effect.

The next four bits are the Data Length Code bits, which show how many bits will be in the data field. The data length can vary from 1 to 8 bytes, equating to between 8 to 64 bits.

The next 15 bits are the CRC (Cyclic Redundancy Check) field used for error detection.

The next bit is the CRC Delimiter, which must be set to the recessive logic 1.

The next bit is the Acknowledgement Slot Bit. The transmitter sets this to the recessive logic level 1. If the message is received successfully, the receiver indicates this by overriding this bit and assigning it to the dominant logic level 0.

The next bit is the Acknowledgement Delimiter, which must be set to a recessive logic 1.

The last seven bits are the End of Frame indication, which identifies that the message has ended.

The standard OBD2 automobile connector includes the CAN Bus differential pair pins for use for diagnosis or software control purposes:

OBD2 connection with two dedicated CAN pins
OBD2 connection with two dedicated CAN pins
https://components101.com/connectors/obd2

LIN Bus

LIN stands for Local Interconnect Network and is an electronic communication protocol primarily used in vehicles similar to CAN. The LIN protocol’s need arose because buses using the CAN protocol become too expensive when every device in a car is needed to communicate via the bus. Because of that, European car manufacturers began to use a different serial communications system, which led to compatibility problems.

LIN was created by five automakers: BMW, Volkswagen Group, Audi, Volvo Cars, and Mercedes-Benz, with the help of Volcano Automotive Group and Motorola.

The LIN communication network is a master-slave arrangement. Typically, the LIN bus consists of 16 nodes (1 master and 15 slaves). All the LIN bus messages are initiated by the single master. At the same time, only one slave may respond at any time to a message chosen using an identifier sent by the master.

Data is transferred between the devices connected to the LIN bus using fixed form messages of variable length. The master device transmits a break signal followed by synchronization and identifier fields to initiate data transfer. The slave devices can reply by sending a data frame that contains either 2, 4, or 8 bytes of data plus 3 bytes of control information.

LIN may be used as a sub-bus connected to a CAN bus. The CAN bus sends a signal to one of its nodes, which can itself be a LIN master. When the LIN physical layer transmitter receives the message, it converts it at a logic level to the LIN protocol using the CAN battery voltage level (typically 12 V). The LIN transmitter also includes a current-limited wave-shaping driver, which reduces electromagnetic emissions.

LIN and CAN bus integration
LIN and CAN bus integration

The LIN slave receivers then convert the high battery level voltage data from the LIN bus into lower voltage level logic signals that can be sent to a microcontroller.

LIN operates as a serial broadcasting system using a one-wire bus with a ground reference. Typical LIN bus speeds are relatively low compared to CAN or other serial communication protocols (<20 kbps). However, the cost of implementing the LIN bus is significantly reduced, making it ideal for mass production. It is mostly used for less critical non-safety functions. LIN is often used for controlling windows, air conditioning, wipers, etc. The maximum length of a LIN bus is 40 meters.

On the LIN bus, signals can be either dominant (logic level low or 0) or recessive (logic level high or 1).

The LIN protocol uses message frame structures that follow one of six frame types as listed below:

  • Unconditional Frame – this is the message frame that all the subscribers (slaves) receive (assuming no errors were detected)
  • Event-Triggered Frame - this message frame increases the responsiveness of the LIN cluster (LIN cluster - one LIN data bus) without using excessive bus bandwidth
  • Sporadic Frame - this message frame is transmitted when required to prevent a collision with other messages
  • Diagnostic Frame - this message frame carries diagnostic or configuration data and always contain eight bits
  • User-defined Frame - this message frame can carry any type of information
  • Reserved Frame – this message frame is reserved for confirming LIN networks and should not be used in LIN 2.0
LIN bus data frame example
LIN bus data frame example

LIN buses have become very popular in the last decade because of their standard protocol, simplicity, and low cost, with more than 600 million LIN nodes fitted in automobiles in 2020.

LIN is now also being used in applications in non-automotive industries such as home appliances and industrial automation.

Summary

This article has looked at some features of the popular CAN and LIN protocols and discussed some of their advantages and implementation details. In the other articles in this series, we will look at some of the alternate serial communication protocols available.

If you want to know more, why not browse our product page for a more in-depth feature description or call an expert at Altium.

2023年8月23日 星期三

Information Security: SE Root CA, Authentication vs Attestation by ChatGPT

"SE Root CA"中的 SE 是什麼?

在 "SE Root CA" 中,"SE" 通常代表 "Secure Element",它是指 "安全元件"。安全元件是一種專門設計用於處理和存儲敏感數據的硬體或軟體模組,旨在提供高度的安全性和保護,以防止未授權的存取和攻擊。

"SE Root CA" 可能指的是 "Secure Element Root Certification Authority",即安全元件根憑證授權機構。這表示該機構負責發布和管理與安全元件相關的憑證,這些憑證可用於驗證和確保安全元件的身份以及其參與的安全運作。

安全元件通常被應用於許多領域,包括智能卡、手機SIM卡、智能鑰匙、物聯網(IoT)設備等,以確保這些系統處理的敏感數據得到適當的保護。


比較 Authentication 和 Attestation

"Authentication" 和 "Attestation" 是兩個在資訊安全和身份驗證領域中常見的術語,
它們雖然有些相似,但指涉的概念和用途有所不同。

Authentication(身份驗證):
身份驗證是確定一個實體(通常是用戶或設備)是否為其聲稱的身份的過程。它的目的是確保只有合法的用戶或設備能夠訪問特定的系統、應用程序或資源。常見的身份驗證方式包括使用密碼、生物特徵(如指紋、面部識別)、硬體令牌(如安全密鑰卡)等。身份驗證通常涉及用戶提供識別信息並進行驗證,以確定其是否有權限訪問所需的資源。

Attestation(證明):
證明是指確認某個實體的屬性或狀態的過程。在資訊安全中,特別是在可信計算和安全設備領域,證明指的是對設備的特性或狀態進行驗證,以確保其具有預期的安全性。例如,當一個設備宣稱自己是一個受信任的平台時,證明可以用來驗證它是否符合特定的安全標準,並且沒有被破壞或受到惡意攻擊。

總的來說,
"Authentication" 著重於確認用戶或設備的身份,以確保其有權限訪問某個資源。
"Attestation" 則著重於確認設備的特性、狀態或安全性,以確保其具有預期的可信度。
這兩個概念在確保系統和資源的安全性方面都起著重要作用。

Information Security 資訊安全

REF https://isp.nuu.edu.tw/p/405-1074-1269,c82.php
REF https://medium.com/hannah-lin/%E5%BE%9E%E9%9B%B6%E9%96%8B%E5%A7%8B%E5%AD%B8%E8%B3%87%E5%AE%89-%E4%BB%80%E9%BA%BC%E6%98%AF%E8%B3%87%E8%A8%8A%E5%AE%89%E5%85%A8-75a7a208e8db


CIA Triad
*機密性 Confidentiality
資訊不得未經授權取得
Tool: 加密
Attack:

*完整性 Integrity
資訊完整不失真
Tool: HASH (CRC32/MD5/SHA/...)
Attack:

*可用性 Availability
經授權者可取得資訊
*可歸責性 (Accountability):確保實體之行為可唯一追溯到該實體的特性。
>鑑別性 (Authenticity):確保一主體或資源之識別就是其所聲明者的特性。鑑別性適用於如使用者、程序、系統與資訊等實體。
>不可否認性 (Non-repudiation):對一已發生之行動或事件的證明,使該行動或事件往後不能被否認的能力。




2023年8月20日 星期日

Linux module programming

Source module_platform_driver 與 module_init_module_platform_driver module_init_嵌入式小胖的博客-CSDN博客

module_platform_driver 與 module_init


版權聲明:本文為CSDN博主「嵌入式小胖」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處連結及本聲明。
原文連結:https://blog.csdn.net/m0_37765662/article/details/106490792

在linux內核源碼中,我們經常看到module_platform_driver 與 module_init這兩個宏定義,有時候在這個驅動中用module_platform_driver,有時候用module_init,那這兩個宏定義之間有什麼差異嗎? 還是說可以隨便用呢? 這就需要我們旭跟蹤代碼,來看看這兩個宏定義到底什麼東西?

首先,介紹下
module_initmodule_init對於做驅動的人應該不陌生,linux內核是一個巨集內核,巨集內核就是驅動和內核打包在一起的。 由於驅動是作為內核模組掛載在內核上的,而內核對於模組的介面就是module_initmodule_exit,所以你要載入一個內核模組的時候,必須使用module_init來進行,而卸載一個內核模組的時候,必須使用module_exit來進行。 例如:

 

module_init(xxxx_init); 載入xxxx模組

 

module_exit(xxxx_exit); 卸載xxxx模組

 

那是不是就有一個疑問了,既然是所有模組都是通過這兩個函數來進行載入和卸載的,那應該所有驅動都用module_init函數啊,為什麼還會有module_platform_driver 這不是多此一舉嗎? 醒醒吧,少年,Linux社區那麼多大神在更新,會出現這種錯誤嗎?

 

那麼我們先看看module_platform_driver的宏定義是個啥?

 

#define module_platform_driver(__platform_driver) \

            module_driver(__platform_driver, platform_driver_register, \

                                    platform_driver_unregister)

#define module_driver(__driver, __register, __unregister, ...) \

static int __init __driver##_init(void) \

{ \

            return __register(&(__driver) , ##__VA_ARGS__); \

} \

module_init(__driver##_init); \

static void __exit __driver##_exit(void) \

{ \

            __unregister(&(__driver) , ##__VA_ARGS__); \

} \

module_exit(__driver##_exit);

從代碼中看到,module_platform_driver 追根溯源,發現最終還是調用了module_init,但是,又不僅僅是調用了module_init,還調用了platform_driver_registerplatform_driver_unregister,這兩個函數的作用就是註冊和卸載平臺驅動。

 

一般某個設備或某個控制器掛載在處理器上時,肯定是通過某種總線來連接的,比喻說常見總線有SPI總線、IIC總線等等,但控制器一般是通過內部總線掛載處理器端的,對於這一類設備,linux抽象出了一個平臺總線,來包含所有的處理器總線掛載的設備。 而這類總線需要註冊到內核中去,就需要用platform_driver_register來實現,平臺總線是抽象出來的,所以所有通過總線直接連在處理器上的設備是不需要關心平臺總線怎麼運作的,因此這個平臺總線的註冊和註銷都是通用的,所以在載入總線設備驅動時,直接調用module_platform_driver 就可以將平臺驅動註冊函數和卸載函數、以及總線設備載入一次性運行完,避免了總線驅動在每次載入驅動時都需要手動註冊平臺總線。

 

其實說了這麼多,module_platform_driver就是對module_init進一步的封裝,在module_init之外添加了一些功能,對於平臺總線設備而言,直接調用module_platform_driver就可以避免在module_init函數中去註冊平臺驅動了,使得平臺設備驅動的載入變得更方便了。

 

那是不是說module_init可以與module_platform_driver就可以通用呢? 當然不是,能用module_platform_driver的地方肯定可以用module_init,但能用module_init卻不一定能用module_platform_driver,這主要看設備是不是通過平臺總線的方式掛載處理器上的。

 

函數名            非平臺總線設備        平臺總線設備

module_platform_driver        不可用            可用

module_init     可用    可用

對於平臺總線設備,可以用兩種方法來載入

 

static int __init xxxx_init(void)

{

            return platform_driver_register(&xxxx_driver);

}

 

static void __exit xxxx_exit(void)

{

            platform_driver_unregister(&xxxx_driver);

}

 

module_init(xxxx_init);

module_exit(xxxx_exit);

module_platform_driver(xxxx_driver);

這兩種方式的效果是一樣的,但明顯module_platform_driver比較簡潔。

 

但對於其他總線的設備,就不能使用module_platform_driver了,必須使用module_init,在module_init函數中再註冊一遍其他總線,例如SPI總線設備。

 

static int __init spidev_init(void)

{

            int status;

 

            /* Claim our 256 reserved device numbers.  Then register a class

             * that will key udev/mdev to add/remove /dev nodes.  Last, register

             * the driver which manages those device numbers.

             */

            BUILD_BUG_ON(N_SPI_MINORS > 256);

            status = register_chrdev(SPIDEV_MAJOR, "spi", &spidev_fops);

            if (status < 0)

                        return status;

 

            spidev_class = class_create(THIS_MODULE, "spidev");

            if (IS_ERR(spidev_class)) {

                        unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);

                        return PTR_ERR(spidev_class);

            }

 

            status = spi_register_driver(&spidev_spi_driver);

            if (status < 0) {

                        class_destroy(spidev_class);

                        unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);

            }

            return status;

}

module_init(spidev_init);

 

static void __exit spidev_exit(void)

{

            spi_unregister_driver(&spidev_spi_driver);

            class_destroy(spidev_class);

            unregister_chrdev(SPIDEV_MAJOR, spidev_spi_driver.driver.name);

}

module_exit(spidev_exit);

 

還有一種情況不能使用module_platform_driver,就是我們編寫的驅動程式要使用之前某個驅動程式的功能時,就不能使用module_platform_driver,因為如果都使用module_platform_driver,內核編譯連結時,並不知道哪個驅動程式會被連結再前面,也就不知道哪個驅動程式會先執行,如果使用自訂的驅動(使用其他驅動程式功能的程式)先執行,而其他驅動還未進行初始化,就會出現難以預料的問題,所以這種情況下就必須使用late_initcall

————————————————