OSI 7 Layer explained

Layer 1: Physical Layer

The physical layer defines the electrical and physical specifications of the data connection. It defines the relationship between a device and a physical transmission medium (for example, an electrical cable, an optical fiber cable, or a radio frequency link). This includes the layout of pins, voltages, line impedance, cable specifications, signal timing and similar characteristics for connected devices and frequency (5 GHz or 2.4 GHz etc.) for wireless devices. It is responsible for transmission and reception of unstructured raw data in a physical medium. Bit rate control is done at the physical layer. It may define transmission mode as simplex, half duplex, and full duplex. It defines the network topology as bus, mesh, or ring being some of the most common.
The physical layer of Parallel SCSI operates in this layer, as do the physical layers of Ethernet and other local-area networks, such as token ring, FDDI, ITU-T G.hn, and IEEE 802.11 (Wi-Fi), as well as personal area networks such as Bluetooth and IEEE 802.15.4.
The physical layer is the layer of low-level networking equipment, such as some hubs, cabling, and repeaters. The physical layer is never concerned with protocols or other such higher-layer items. Examples of hardware in this layer are network adapters, repeaters, network hubs, modems, and fiber media converters.

물리 계층은 데이터의 연결에 대한 전기적인, 물리적인 스펙을 이야기 한다. 장치 간의 물리적인 중간 매체(예를 들어, 전기 케이블, 광섬유 케이블, 혹은 라디오 주파수 등)를 정의한다. 여기에는 핀의 배치도, 사용되는 전압, 선의 저항값, 케이블의 스펙, 전송 신호의 타이밍, 무선 장치에서의 전송 주파수 등 비슷한 스펙들을 포함하고 있다. 물리적인 장치를 통해서 구조화 되지 않은 raw 데이터를 보내고 받는 것에 관련된 책임을 가지고 있다. bit rate는 물리 계층에서 이루어 진다. 여기에는 데이터 전송이 simplex인지 half duplex인지 full duplex인지도 정의되어 있다. network구조의 경우 bus, mesh, 나 ring 등 가장 일반적인 것들도 정의하고 있다. 병렬 SCSI의 물리적 계층은 이 계층에서 작동하며 이는 이더넷 및 기타 로컬 영역 네트워크의 토큰 링, FDDI, ITU-T G.hn 및 IEEE 802.11 (Wi-Fi)이나 개인영역 네트워크의 Bluetooth 및 IEEE 802.15.4와 동일한 역할이다.
물리 계층은 일부 허브, 케이블 링 및 중계기와 같은 하위 수준 네트워킹 장비의 계층이다. 물리 계층은 프로토콜 또는 기타 상위 계층 항목과 관련이 없다. 이 계층의 하드웨어의 예로는 네트워크 어댑터, 중계기, 네트워크 허브, 모뎀 및 광섬유 미디어 변환기가 있다.


Layer 2: Data Link Layer

The data link layer provides node-to-node data transfer—a link between two directly connected nodes. It detects and possibly corrects errors that may occur in the physical layer. It defines the protocol to establish and terminate a connection between two physically connected devices. It also defines the protocol for flow control between them.
IEEE 802 divides the data link layer into two sublayers:[5]
Media access control (MAC) layer – responsible for controlling how devices in a network gain access to a medium and permission to transmit data.
Logical link control (LLC) layer – responsible for identifying and encapsulating network layer protocols, and controls error checking and frame synchronization.
The MAC and LLC layers of IEEE 802 networks such as 802.3 Ethernet, 802.11 Wi-Fi, and 802.15.4 ZigBee operate at the data link layer.
The Point-to-Point Protocol (PPP) is a data link layer protocol that can operate over several different physical layers, such as synchronous and asynchronous serial lines.
The ITU-T G.hn standard, which provides high-speed local area networking over existing wires (power lines, phone lines and coaxial cables), includes a complete data link layer that provides both error correction and flow control by means of a selective-repeat sliding-window protocol.

데이터 링크 레이어는 node 와 node간의 데이터 전송(연결된 두개의 node)을 담당한다. 물리 계층에서의 데이터 전송간의 error를 감지하고 가능하면 error를 바로잡는다. 두 연결된 장치간의 연결의 확립과 종결과 관련된 프로토콜을 정의한다. flow control도 정의한다.  IEEE 802는 데이터 링크를 더 세부적인 서브 레이어들로 나눈다.
Media access control(MAC)
Logical link control(LLC)

Layer 3: Network Layer

서로 다른 네트워크에 접속하는 레이어

Layer 4: Transport Layer

데이터 전송간의 데이터가 제대로된 길이로 갔는지 확인할 수 있는 것
네트워크 간에 로스가 될 수 있으니

Layer 5: Session Layer
특정한 세션을 구축하는지의 문제, 로그인을 한 상태를 구분하는 것 등

Layer 6: Presentation Layer
데이터의 표현 방식에 대한 것으로 암호화가 된 것과 안된것을 구분하는 것 등

Layer 7: Application Layer
실제 필요한 데이터를 사용하는 것

영양제에 대한 고찰 - 기사 "영양제 섞어 먹으면 안 되는 이유"

기사 "영양제 섞어 먹으면 안 되는 이유(Link)" 는 과도한 영양제의 섭취는 건강에 좋지 않다고 설명해 줍니다.

모든 영양분은 적당한 양이 필요하다는건 알고 있는데 어떻게 먹으면 좋을지 고민해 봤습니다.

영양제를 먹을 때는 아래 3가지 영양제 종류를 잘 걸러서 생각을 해야 합니다.

1. 많이 먹어도 몸에서 알아서 걸러주는 것

2. 많이 먹으면 몸을 해 하는 것 - 바로 알 수 있는 것

3. 많이 먹으면 몸을 해 하는 것 - 바로 알 수 없어 몸이 망가지는 것

특히 3번에 해당하는 종류를 하나라도 알게되면 기록해 놓고 잊지 않아야 하겠습니다.

저같은 경우 

비타민C 를 1번에 1000mg, 하루 1~3번 먹고 있으며

오메가3 를 1번에 1000mg, 하루 1번 먹고 있습니다.

이 기사에서는 

아래 5가지 우려를 나타냈습니다.
각 항목에 대해 검색을 하였고, 우려 아래에 표시 했습니다.
결론은 가장 아래에 있습니다.

1. 단순히 몸에 좋다는 생각에 비타민이나 철분 같은 일부 항산화제를 과도하게 섭취하면 건강을 해칠 수 있다. 몸속의 산화 작용을 방해하여 장기적으로 부정적인 결과가 나타날 수 있다.

-> 비타민C는 수용성 이므로 몸에서 받아들이지 못하면 배출 됩니다. 위에 무리를 주지 않기 위해서 식후에 먹어야 하며, 수용성이기 때문에 충분한 물과 마시면 문제가 없습니다. 충분하다는 기준은 사람마다 다를 수 있지만 요로 결석 등의 문제가 발견되지 않는다면 현재 먹고있는 방법이 맞다고 생각하면 됩니다. 하루에 영양제로서 먹을 때 허용되는 양은 나이마다 다를 수 있지만 여러 자료를 가지고 기준을 생각해 보려고 한다.

1) 일본 후생성: 하루24 ~ 1000mg Link

2) 마요 클리닉: 성인 기본 90mg, 최대 2000mg Link

3) 중앙일보, 다양한 표준, 이왕재 교수: 많을수록 좋으며(혈관을 깨끗하게) 6000mg Link

-> 오메가3

1) 헬스라인: 200~4000mg 이 건강에 도움 주는 것으로 확인 Link

2) 미국 국립 보건원: 남자 1600mg, 여자 1100mg Link

2. "식이 보충제에는 여러 성분이 함유된 경우가 많아 소비자들이 같은 종류의 성분을 든 보충제를 동시에 섭취할 수 있는데 이것이 건강에 어떠한 영향을 미치는지에 대해서는 거의 평가된 바가 없다"

-> 여러 성분이 든 것은 먹지 않으므로 문제 없다고 판단.

3. 일부 식이 보충제의 경우 약리적 용량과 영양적 용량 모두에 대한 임상 시험 결과 암 발생 위험이 증가하는 것으로 나타났다.

-> 먹고 있는 비타민C와 오메가3만 생각하면 되므로 문제 없다.

4. 칼슘 보충제는 일부 약물의 체내 흡수를 저해할 수 있고

-> 칼슘 보충제는 먹지 않는다.

5. 항응혈제를 복용하는 사람이 오메가-3 지방산을 섭취하면 출혈 위험이 높아지는 것으로 드러났다.

->항응혈제를 복용하지 않음

결론

현재 먹고 있는 비타민 C와 오메가3의 양은 적당하다.

앞으로 어떤 영양분을 섭취하는 기준을 잘 알기 위해서는 최소 섭취량, 최적 섭취량, 나이대에 맞는 섭취량 + 내 건강상태, 식이습관 을 생각하고 정리해야 하겠다.

후기1
최적 섭취량, 권장 섭취량: Link
비타민C의 하루 권장 섭취량은 75mg 이며 최적 섭취량은 1000mg~3000mg 이다.

Git Hub 사용법 - 첫 코드 업로드

• Git Hub 사용법
• Git Hub 가입하기
• Git Hub 저장소(Remote 저장소) 만들기

• 로컬 저장소 만들기


• git 설치하기
• git 다운받기

• git 설치프로그램 실행

• 로컬 저장소 만들기
• 사용자 등록

• 로컬 저장소 만들기

• 로컬저장소 코드 파일 생성, 코드 수정 -> Github에 등록
• 코드 파일 생성 및 Github에 등록

• 코드 수정 및 Github에 등록

1. 
   

• 기타 정보
• Gitbub 주소: Link

CAN Physical Layers

The CAN Bus

The CAN bus uses Non-Return To Zero (NRZ) with bit-stuffing. There are two different signaling states: dominant (logically 0) and recessive (logically 1). These correspond to certain electrical levels which depend on the physical layer used (there are several.) The modules are connected to the bus in a wired-and fashion: if just one node is driving the bus to the dominant state, then the whole bus is in that state regardless of the number of nodes transmitting a recessive state.

Different Physical Layers

A physical layer defines the electrical levels and signaling scheme on the bus, the cable impedance and similar things.

There are several different physical layers:

• The most common type is the one defined by the CAN standard, part ISO 11898-2, and it’s a two-wire balanced signaling scheme. It is also sometimes known as “high-speed CAN”.
• Another part of the same ISO standard, ISO 11898-3, defines another two-wire balanced signaling scheme for lower bus speeds. It is fault tolerant, so the signaling can continue even if one bus wire is cut or shorted to ground or Vbat. It is sometimes known as “low-speed CAN”.
• SAE J2411 defines a single-wire (plus ground, of course) physical layer. It’s used chiefly in cars – e.g. GM-LAN.
• Several proprietary physical layers do exist.
• Modifications of RS485 was used in the Old Ages when CAN drivers didn’t exist.
• Go to Page 6 to view a number of oscilloscope pictures for those interested in the details of a message.

Different physical layers can not, as a rule, interoperate. Some combinations may work, or seem to work, under good conditions. For example, using both “high-speed” and “low-speed” transceivers on the same bus can work.. sometimes.

A great many CAN transceiver chips are manufactured by Philips; alternative vendors include Bosch, Infineon, Siliconix and Unitrode.

A very common type is the 82C250 transceiver which implements the physical layer defined by ISO 11898. The 82C251 is an improved version.

A common transceiver for “low-speed CAN” is TJA1054 from Philips.

Maximum Bus Speed

The maximum speed of a CAN bus, according to the standard, is 1 Mbit/second. Some CAN controllers will nevertheless handle higher speeds than 1Mbit/s and may be considered for special applications.

Low-speed CAN (ISO 11898-3, see above) can go up to 125 kbit/s.

Single-wire CAN can go up to around 50 kbit/s in its standard mode and, using a special high-speed mode used e.g. for ECU programming, up to around 100 kbit/s.

Minimum Bus Speed

Be aware that some bus transceivers will not allow you to go below a certain bit rate. For example, using 82C250 or 82C251 you can go down to 10 kbit/s without problems, but if you use the TJA1050 instead you can’t go below around 50 kbit/s. Check the data sheet.

Maximum Cable Length

At a speed of 1 Mbit/s, a maximum cable length of about 40 meters (130 ft.) can be used. This is because the arbitration scheme requires that the wave front of the signal can propagate to the most remote node and back again before the bit is sampled. In other words, the cable length is restricted by the speed of light. A proposal to increase the speed of light has been considered but was turned down because of its inter-galactic consequences.

Other maximum cable lengths are (these values are approximate) –

• 100 meters (330 ft) at 500 kbit/s
• 200 meters (650 ft) at 250 kbit/s
• 500 meters (1600 ft) at 125 kbit/s
• 6 kilometers (20000 ft) at 10 kbit/s

If optocouplers are used to provide galvanic isolation, the maximum bus length is decreased accordingly. Hint: use fast optocouplers, and look at the delay through the device, not at the specified maximum bit rate.

Bus Termination

An ISO 11898 CAN bus must be terminated. This is done using a resistor of 120 Ohms in each end of the bus. The termination serves two purposes:

1. Remove the signal reflections at the end of the bus.
2. Ensure the bus gets correct DC levels.

An ISO 11898 CAN bus must always be terminated regardless of its speed. I’ll repeat this: an ISO 11898 CAN bus must always be terminated regardless of its speed. For laboratory work just one terminator might be enough. If your CAN bus works even though you haven’t put any terminators on it, you are just lucky.

Note that other physical layers, such as “low-speed CAN”, single-wire CAN, and others, may or may not require termination. But your vanilla high-speed ISO 11898 CAN bus will always require at least one terminator.

Learn more about CANbus termination in this article.

The Cable

The ISO 11898 prescribes that the cable impedance be nominally 120 Ohms, but an impedance in the interval of [108..132] Ohms is permitted.

There are not many cables in the market today that fulfill this requirement. There is a good chance that the allowed impedance interval will be broadened in the future.

ISO 11898 is defined for a twisted pair cable, shielded or unshielded. Work is in progress on the single-wire standard SAE J2411.

CAN connectors

There is no standard at all for CAN bus connectors! Usually, each Higher Layer Protocol(!) defines one or a few preferred connector types. Common types include

• 9-pin DSUB, proposed by CiA.
• 5-pin Mini-C and/or Micro-C, used by DeviceNet and SDS.
• 6-pin Deutch connector, proposed by CANHUG for mobile hydraulics.
• Go to Page 7 to view a few different connector layouts.

CAN Messages, Part III

Basic CAN vs. Full CAN

The terms “Basic CAN” and “Full CAN” originate from the childhood of CAN. Once upon a time there was the Intel 82526 CAN controller which provided a DPRAM-style interface to the programmer. Then came along Philips with the 82C200 which used a FIFO- (queue-) oriented programming model and limited filtering abilities. To distinguish between the two programming models, people for some reason termed the Intel way as “Full CAN” and the Philips way as “Basic CAN”. Today, most CAN controllers allow for both programming models, so there is no reason to use the terms “Full CAN” and “Basic CAN” – in fact, these terms can cause confusion and should be avoided.

Of course, a “Full CAN” controller can communicate with a “Basic CAN” controller and vice versa. There are no compatibility problems.

Bus Arbitration And Message Priority

The message arbitration (the process in which two or more CAN controllers agree on who is to use the bus) is of great importance for the really available bandwidth for data transmission.

Any CAN controller may start a transmission when it has detected an idle bus. This may result in two or more controllers starting a message (almost) at the same time. The conflict is resolved in the following way. The transmitting nodes monitor the bus while they are sending. If a node detects a dominant level when it is sending a recessive level itself, it will immediately quit the arbitration process and become a receiver instead. The arbitration is performed over the whole Arbitration Field and when that field has been sent, exactly one transmitter is left on the bus. This node continues the transmission as if nothing had happened. The other potential transmitters will try to retransmit their messages when the bus becomes available next time. No time is lost in the arbitration process.

An important condition for this bit-wise arbitration to succeed is that no two nodes may transmit the same Arbitration Field. There is one exception to this rule: if the message contains no data, then any node may transmit that message.

Since the bus is wired-and and a Dominant bit is logically 0, it follows that the message with the numerically lowest Arbitration Field will win the arbitration.

Q: What happens if a node is alone on the bus and tries to transmit?
A: The node will, of course, win the arbitration and happily proceeds with the message transmission. But when the time comes for acknowledging… no node will send a dominant bit during the ACK slot, so the transmitter will sense an ACK error, send an error flag, increase its transmit error counter by 8 and start a retransmission. This will happen 16 times; then the transmitter will go error passive. By a special rule in the error confinement algorithm, the transmit error counter is not further increased if the node is error passive and the error is an ACK error. So the node will continue to transmit forever, at least until someone acknowledges the message.

Message Addressing And Identification

It is worth noting once again that there is no explicit address in the CAN messages. Each CAN controller will pick up all traffic on the bus, and using a combination of hardware filters and software, determine if the message is “interesting” or not.

In fact, there is no notion of message addresses in CAN. Instead, the contents of the messages is identified by an identifier which is present somewhere in the message. CAN messages are said to be “contents-addressed”.

A conventional message address would be used like “Here’s a message for node X”. A contents-addressed message is like “Here’s a message containing data labeled X”. The difference between these two concepts is small but significant.

The contents of the Arbitration Field is, per the Standard, used to determine the message’s priority on the bus. All CAN controllers will also use the whole (some will use just a part) of the Arbitration Field as a key in the hardware filtration process.

The Standard does not say that the Arbitration Field must be used as a message identifier. It’s nevertheless a very common usage.

A Note On The Identifier Values

We said that 11 (CAN 2.0A) or 29 (CAN 2.0B) bits is available in the Identifier. This is not entirely correct. Due to compability with a certain old CAN controller (guess which?), identifiers must not have the 7 most significant bits set to all ones, so only the identifiers 0..2031 are left for the 11-bit identifiers, and the user of 29-bit identifiers can use 532676608 different values.

Note that all other CAN controllers accept the “illegal” identifiers, so in a modern CAN system identifiers 2032..2047 can be used without restrictions.

CAN Messages, Part II

2. The Remote Frame

Summary: “Hello everyone, can somebody please produce the data labeled X?”

요약: "모두 안녕, 누구 X라는 라벨을 가지는 데이터를 만들어줄 수 없니?"

The Remote Frame is just like the Data Frame, with two important differences:
Remote Frame은 Data Frame과 같다, 두 가지 중요한 다른점만 빼면

• it is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and
• Remote Frame이라고 명시적으로 표시되어 있다.(Arbitration field 의 RTR bit 가 recessive(1) 이다.)
• there is no Data Field.
• Data Field 가 없다.

The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234.

Remote Frame의 의도 된 목적은 해당 데이터 프레임의 전송을 요구하는 것입니다. 예를 들어, 노드 A가 중재 필드를 234로 설정 한 원격 프레임을 전송하면 올바르게 초기화 된 노드 B는 중재 필드도 234로 설정된 데이터 프레임으로 응답 할 수 있습니다.

Remote Frames can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behaviour outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead.

원격 프레임은 버스 트래픽 관리의 요청 - 응답 유형의 유형을 구현하는 데 사용할 수 있습니다. 그러나 실제로는 원격 프레임은 거의 사용되지 않습니다. CAN 표준이 여기에 설명 된 동작을 규정하지 않는다는 점도 주목할 가치가 있습니다. 대부분의 CAN 컨트롤러는 원격 프레임에 자동 응답하거나 대신 로컬 CPU에 통보하도록 프로그래밍 할 수 있습니다.

There’s one catch with the Remote Frame: the Data Length Code must be set to the length of the expected response message. Otherwise the arbitration will not work.

원격 프레임에는 하나의 캐치가 있습니다. 데이터 길이 코드는 예상 응답 메시지의 길이로 설정되어야합니다. 그렇지 않으면 중재가 작동하지 않습니다.

Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby “filling up” the empty Remote Frame. This is not the case.

때로는 원격 프레임에 응답하는 노드가 식별자가 인식되는 즉시 전송을 시작하여 빈 원격 프레임을 "채우는"것으로 주장됩니다. 그렇지 않다.

A Remote Frame (2.0A type):

3. The Error Frame

Summary: (everyone, aloud) “OH DEAR, LET’S TRY AGAIN”

요약: (모두, 크게) "오 이런, 모두 다시해보자"

Simply put, the Error Frame is a special message that violates the framing rules of a CAN message. It is transmitted when a node detects a fault and will cause all other nodes to detect a fault – so they will send Error Frames, too. The transmitter will then automatically try to retransmit the message. There is an elaborate scheme of error counters that ensures that a node can’t destroy the bus traffic by repeatedly transmitting Error Frames.

간단히 말해, 오류 프레임은 CAN 메시지의 프레이밍 규칙을 위반하는 특수 메시지입니다. 노드가 오류를 감지하면 다른 모든 노드가 오류를 감지하여 전송되므로 오류 프레임도 전송됩니다. 그러면 송신기는 자동으로 메시지를 재전송합니다. 노드가 오류 프레임을 반복적으로 전송하여 버스 트래픽을 파괴 할 수 없도록 보장하는 정교한 오류 카운터 체계가 있습니다.

The Error Frame consists of an Error Flag, which is 6 bits of the same value (thus violating the bit-stuffing rule) and an Error Delimiter, which is 8 recessive bits. The Error Delimiter provides some space in which the other nodes on the bus can send their Error Flags when they detect the first Error Flag.

오류 프레임은 6 비트의 동일한 값 (따라서 비트 스터핑 규칙 위반) 인 오류 플래그와 8 개의 리세 시브 비트 인 오류 구분 기호로 구성됩니다. 오류 구분 기호는 버스의 다른 노드가 첫 번째 오류 플래그를 감지 할 때 오류 플래그를 보낼 수있는 공간을 제공합니다.

Here’s the Error Frame:

4. The Overload Frame

Summary: “I’m a very busy little 82526, could you please wait for a moment?”
요약: "난 정말 바쁜 82526(지금은 폐기된 controller), 잠깐 기다려 줄 수 있겠니?"

The Overload Frame is mentioned here just for completeness. It is very similar to the Error Frame with regard to the format and it is transmitted by a node that becomes too busy. The Overload Frame is not used very often, as today’s CAN controllers are clever enough not to use it. In fact, the only controller that will generate Overload Frames is the now obsolete 82526.

오버로드 프레임은 여기에 완전성을 위해 언급되었습니다. 형식과 관련하여 오류 프레임과 매우 유사하며 너무 바쁜 노드에서 전송합니다. 오버로드 프레임은 오늘날 사용되는 CAN 컨트롤러가 사용하기에 충분히 영리하기 때문에 자주 사용되지 않습니다. 실제로 오버로드 프레임을 생성하는 컨트롤러는 현재 폐기 된 82526입니다.

Standard vs. Extended CAN

Originally, the CAN standard defined the length of the Identifier in the Arbitration Field to eleven (11) bits. Later on, customer demand forced an extension of the standard. The new format is often called Extended CAN and allows no less than twenty-nine (29) bits in the Identifier. To differentiate between the two frame types, a reserved bit in the Control Field was used.

본래, CAN 표준은 중재 필드의 식별자 길이를 11 비트로 정의했습니다. 나중에 고객 요구가 표준의 확장을 요구했습니다. 새로운 형식은 확장 CAN (Extended CAN)이라고도하며 식별자에 29 비트 이상 허용합니다. 두 프레임 유형을 구별하기 위해 제어 필드의 예약 된 비트가 사용되었습니다.

The standards are formally called

• 2.0A, with 11-bit Identifiers only,
• 2.0B, extended version with the full 29-bit Identifiers (or the 11-bit, you can mix them.) A 2.0B node can be
  • “2.0B active”, i.e. it can transmit and receive extended frames, or
  • “2.0B passive”, i.e. it will silently discard received extended frames (but see below.)
• 1.x refers to the original specification and its revisions.

New CAN controllers today are usually of the 2.0B type. A 1.x or 2.0A type controller will get very upset if it receives messages with 29 arbitration bits. A 2.0B passive type controller will tolerate them, acknowledge them if they are correct and then – discard them; a 2.0B active type controller can both transmit and receive them.

오늘날 새로운 CAN 컨트롤러는 일반적으로 2.0B 유형입니다. 1.x 또는 2.0A 유형 제어기는 29 개의 조정 비트가있는 메시지를 수신하면 매우 혼란 스럽습니다. 2.0B 패시브 타입 컨트롤러는이를 허용하고, 올바른지 확인한 후 폐기합니다. 2.0B 능동형 컨트롤러는 이들을 송수신 할 수 있습니다.

Controllers implementing 2.0B and 2.0A (and 1.x) are compatible – and may be used on the same bus – as long as the controllers implementing 2.0B refrain from sending extended frames!

2.0B 및 2.0A (및 1.x)를 구현하는 컨트롤러는 2.0B를 구현하는 컨트롤러가 확장 된 프레임을 보내지 않는 한 호환 가능하며 동일한 버스에서 사용할 수 있습니다!

Sometimes people advocate that standard CAN is “better” than Extended CAN because there is more overhead in the Extended CAN messages. This is not necessarily true. If you use the Arbitration Field for transmitting data, then Extended CAN may actually have a lower overhead than Standard CAN has.

종종 사람들은 확장 CAN 메시지에 더 많은 오버 헤드가 있기 때문에 표준 CAN이 확장 CAN보다 "더 우수"하다고 주장합니다. 이것은 반드시 사실 일 필요는 없습니다. 중재 필드를 사용하여 데이터를 전송하는 경우 확장 CAN은 실제로 표준 CAN보다 낮은 오버 헤드를 가질 수 있습니다.

CAN Messages, Part I

참조: Link

The CAN bus is a broadcast type of bus. This means that all nodes can “hear” all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages.
CAN bus는 broadcast 타입의 bus 입니다. 이 말은 모든 node들은 모든 통신내용을 들을 수 있다는 걸 의미합니다. 특정 node만이 들을 수 있도록 message를 보내는 것은 가능하지 않습니다.

The CAN messages

CAN uses short messages – the maximum utility load is 94 bits. There is no explicit address in the messages; instead, the messages can be said to be contents-addressed, that is, their contents implicitly determines their address.
CAN은 짧은 message를 사용합니다. – 가능한 최대 길이는 94bit(11byte + 6bit) 입니다. message에는 특정 주소가 있는 것은 아니지만; 대신, message는 내용에 주소가 있다고 이야기 할 수 있습니다. 그 이야기는 내용 자체에 암암리에 주소가 있기 때문 입니다.

Message Types

There are four different message types (or “frames”) on a CAN bus:
CAN bus에는 message의 타입(혹은 frame이라고 불림)이 4가지 있습니다.

1. the Data Frame,
2. the Remote Frame,
3. the Error Frame, and
4. the Overload Frame.

1. The Data Frame

Summary: “Hello everyone, here’s some data labeled X, hope you like it!”
요약: "안녕 모두들, 여기 라벨이 X라고 붙은 data가 있어, 좋아했으면 해!"

The Data Frame is the most common message type. It comprises the following major parts (a few details are omitted for the sake of brevity):
Data frame은 가장 일반적인 message 타입입니다. 몇가지 중요한 부분으로 구성되어 있습니다.(몇몇 세부내용은 간결함을 위하여 생략되었습니다.)

• the Arbitration Field, which determines the priority of the message when two or more nodes are contending for the bus. The Arbitration Field contains:
• Arbitration Field 라고 하는 부분은 message 간의 우선순위를 결정해 줍니다. bus에 있는 내용들이 2개 이상일 때 구별해 줍니다. Arbitration Field 는 아래 내용을 포함합니다:
  
  • For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant for data frames.
  • CAN 2.0A 에서는 11bit의 구별자와 1bit, RTR bit로서 data frame에서 dominant(0)인,
  • For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR and IDE) and the RTR bit.
  • CAN 2.0B 에서는 29bit의 구별자(두 개의 recessive bit(1)를 가진, SRR, IDE))와 RTR bit
• the Data Field, which contains zero to eight bytes of data.
• Data Field 는 0~8byte 의 길이를 가진다. 
• the CRC Field, which contains a 15-bit checksum calculated on most parts of the message. This checksum is used for error detection.
• CRC field 는 15bit로 계산 된 checksum 값을 error detection 을 위해서 사용한다. 
• an Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message. The transmitter checks for the presence of the Acknowledge bit and retransmits the message if no acknowledge was detected.
• Acknowledgement Slot는 각 message의 마지막에 붙은 bit로서 transmitter가 마지막에 보냈는지 체크해서 보내지 않았으면 다시 보낸다.? 방향이 헷갈림

Note 1: It is worth noting that the presence of an Acknowledgement Bit on the bus does not mean that any of the intended addressees has received the message. The only thing we know is that one or more nodes on the bus has received it correctly.
Note 1: Acknowledgement bit는 내가 원했던 node에서 message를 받았다는 것을 나타내지는 않는다 하지만 누군가는 받았다는것을 확인할 수 있으므로 있는것이 좋다.

Note 2: The Identifier in the Arbitration Field is not, despite of its name, necessarily identifying the contents of the message.
Note 2: Identifier의 Arbitration Field(중재 필드)는 그 이름에도 불구하고 충분히 message를 구분하지 못한다.

 A CAN 2.0A (“standard CAN”) Data Frame.

 A CAN 2.0B (“extended CAN”) Data Frame.

RTR: Remote transmission request
SRR: Substitute remote request
IDE: Identifier extension bit