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

Introduction: The CAN bus

Introduction: The CAN bus

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 버스는 broadcast 타입의 bus 입니다. 이 말은 모든 node들은 모든 통신 내용을 "들을" 수 있다는 이야기 입니다. 단지 하나의 node에만 message를 보내는 방법은 없습니다; 모든 node들은 언제나 모든 통신내용을 듣습니다. 하지만 CAN 하드웨어는 내부에서 filtering을 제공하며, 각 node에서는 관련이 있는 message 에만 반응합니다.

The bus uses Non-Return To Zero (NRZ) with bit-stuffing. The modules are connected to the bus in a wired-and fashion: if just one node is driving the bus to a logical 0, then the whole bus is in that state regardless of the number of nodes transmitting a logical 1.
bus는 NRZ 과 bit-stuffing을 사용한다. 이 말은 항상 의미가 있는 bit들의 조합을 사용하며 에러를 감지하기 위하여 특정 위치에(규칙으로) bit를 삽입한다는 의미이다. module들은 bus에 wired-AND 방식으로 연결되어 있다. 만약 하나의 node가 bus를 0상태로 변경하려고 하면, 모든 bus가 그 상태(0)이 된다 몇개의 node들이 1을 만들어내는것에 상관 없이. 

The CAN standard defines four different message types. The messages uses a clever scheme of bit-wise arbitration to control access to the bus, and each message is tagged with a priority.
CAN의 표준에서는 4가지 다른 message의 타입을 정의합니다. 이 message들은 영리한 방법으로 bit-wise arbitration 을 사용하여 bus로의 접근을 제어 하며, 각 message들은 우선순위가 있습니다.

The CAN standard also defines an elaborate scheme for error handling and confinement which is described in more detail in Section 9, “CAN Error Handling” (Pg 23).
또한 CAN표준은 오류처리 와 제한을 위한 정교한 계획을 정의합니다. 자세한 내용은 9장 "CAN 오류 처리"에서 확인할 수 있습니다.

Bit timing and clock synchronization is discussed in Page 8 of this Tutorial. Here’s a bit timing calculator you can use to calculate the CAN bus parameters and register settings.
비트 타이밍 및 클럭 동기화는이 자습서 8 페이지에서 설명합니다. 다음은 CAN 버스 매개 변수와 레지스터 설정을 계산하는 데 사용할 수있는 약간의 타이밍 계산기입니다.

CAN may be implemented using different physical layers (Pg 5), some of which are described here, and there are also a fair number of connector types (Pg 7) in use. We also provide a number of oscilloscope pictures (Pg 6) for those interested in the details of a message.
CAN은 서로 다른 물리 계층 (Pg 5)을 사용하여 구현 될 수 있으며, 그 중 일부는 여기에 설명되어 있으며 사용중인 커넥터 유형 (Pg 7)의 수가 상당히 있습니다. 또한 메시지의 세부 사항에 관심이있는 사람들을 위해 여러 오실로스코프 사진 (페이지 6)을 제공합니다.



Non-Return To Zero (NRZ) (Link)
기록 · 재생에 있어서의 하나의 모드로, 기록된 데이터의 각 아이템 다음에 신호가 반드시 제로로 복귀하지 않는 것. 따라서 중성(휴지：休止) 위치는 없다. 디짓 1은 하나의 진폭 레벨이고, 또 디짓 0은 다른 진폭 레벨(극성은 동극성일 때도 역극성일 때도 있다)로 표현된다. 제로 복귀 모드에 비해 기록 속도를 빨리 할 수 있다.
[네이버 지식백과] 비 복귀 기록 [non-return to zero, 非復歸記錄] (전자용어사전, 1995. 3. 1., 성안당)
bit-stuffing(Link)
전송된 데이터열에 여분의 비트를 삽입하는 것. 비트 스터핑은 특수한 비트열이 확실히 원하는 위치에만 나타나도록 하기 위해 사용한다.
wired-AND(Link)
bit-wise arbitration
confinement
bus(Link)
In computer architecture, a bus[1] (a contraction of the Latin omnibus) is a communication system that transfers data between components inside a computer, or between computers. This expression covers all related hardware components (wire, optical fiber, etc.) and software, including communication protocols

Serial 통신 비교(UART vs SPI vs I2C)

참조 Link

Serial 통신 이해를 위해 Internet 상의 좋은 자료를 찾았고, 이해를 위해 번역 및 내용 추가 하였습니다.

---

이 페이지에서는 UART, SPI, I2C 를 테이블 형식으로 비교 합니다.
여러 항목들을 비교할 예정 입니다.

항목	UART	SPI	I2C
전체 이름	Universal Asyncronous Receiver/Transmitter	Serial Peripheral Interface	Inter-Integrated Circuit
Interface Diagram
핀	TxD: Transmit Data RxD: Receive Data	SCLK: Serial Clock MOSI: Master Output, Slave Input MISO: Master Input, Slave Output SS: Slave Select	SDA: Serial Data SCL: Serial Clock
Data Rate 데이터 전송 속도	비동기(asynchronous) 통신이기 때문에 공유하는 Clock 이 없어서 통신하는 양쪽 기기의 속도를 동일하게 맞춰 주어야 한다. 동일하지 않아도 통신이 되는 경우가 있지만 의도하지 않은 데이터가 들어갈 경우가 있다.  Maximum 통신 속도는 Model 에 따라 다르며, 일반적으로 115,200bps 이다.	SPI에서 최대 데이터 속도는 정해져 있지 않다. 보통 10Mbps 에서 20Mbps 사이 이다.	I2C는 100Kbps, 400Kbps, 3.4Mbps 를 주로 사용하며 10Kbps 나 1Mbps를 사용하는 경우도 있다.
Distance 거리	5미터 이하	가장 길다.	길다.
Type of communication 통신의 종류	비동기 통신을 하는 기기가 같은 clock을 공유하지 않는다는 의미로, 통신하는 두 기기가 동일한 속도를 맞춰야 한다. 편리한 점은 속도만 맞추면 어떤 기기와도 통신이 가능하다는 점	동기 같은 clock을 사용하여 통신을 한다는 의미로, 개발 단계에서 연결이 되어야 한다.	동기
Number of masters	Master가 없다. 각자 주고(Tx), 받는(Rx) 다.	Master 는 하나이며 변하지 않는다.	Master가 하나 이상이 될 수 있다.
Clock	공유하는 Clock이 없다. 각 기기는 각자의 Clock을 사용하며 통신 시에는 동일한 데이터 전송 속도를 설정하여 송수신 해야 한다.	Master와 Slave들은 동일한 Clock을 사용한다.	Master들과 Slave들은 동일한 클럭을 사용한다.
Hardware Complexity	가장 복잡하지 않다.	복잡하지 않다.	복잡하다.
Protocol	Data는 8bit로 보내며 앞에 Start bit와 뒤에 Stop bit를 붙인다.	통일된 Protocol이 있지 않다. 그래서 해당 기기의 datasheet를 참조해야 한다. 예를 들어 microcontroller와 EEPROM의 통신을 한다면 EEPROM 의 datasheet를 봐야 한다.	Start bit와 Stop bit를 사용하며 데이터는 8bit를 전송한다. 8bit를 보내고 나면 (slave가?) ack를 사용하여 데이터가 잘 받아졌는지를 확인한다. 아래 그림에 표시 되어있다.
Software addressing	1:1 통신만을 하기 때문에 addressing은 필요 없다.	Master에는 slave 개수만큼 slave select 라인이 있기 때문에 해당 line을 통해서 slave를 선택한다.	다수의 master와 다수의 slave가 존재하고, 각 master는 모든 slave에 접근할 수 있다. 27개의 slave까지 지원이 되며 master는 고유 주소값을 통해 접근한다.
장점	하드웨어가 간단해서 거의 모든 장치에서 UART를 지원하기 때문에 (9개의 핀이 연결되거나, USB가 있는 장치라면) 편리하다. RS232 라고도 불린다. RS232는 protocol의 이름이며 UART는 그것을 가능하게 해 주는 송수신기를 의미하기 때문이다.	간단한 프로토콜이기 때문에 구현하는데 어렵지 않다. Full duplex(전체 동시 송수신, 전이중) 통신을 지원한다. 나뉘어진 slave select 라인이 있기 때문에 같은 종류의 칩들이 회로에 사용될 수 있다. SPI는 push-pull을 사용하기 때문에 높은 데이터 전송률을 가지며 긴 거리도 가능하다. SPI는 I2C와 비교하면 적은 파워를 사용한다.	Open collector(?) 디자인이기 때문에 slew rate(출력 전압의 최대 변화율, 모양이 이상해 지는 것)가 제한적이다. 한 개 이상의 master가 가능하다. 선이 두 개 필요하다. Addressing 하는 방법이 간단해서 SPI 같이 여러 라인이 필요하지 않다. Open collector bus concept를 가지고 있어 bus의 voltage 가 유연(다른  voltage level 가능)하다. Flow control을 사용한다. (ack를 말하는 듯) Mixed speed 가 가능하다(Link)
단점	1:1 통신만 지원한다. 동일한 속도를 맞추고 시작해야 한다. 그렇지 않으면 데이터가 깨질 것이다. Voltage level 이 동일해야 한다.	Slave가 많아지면 각 slave별 라인이 필요하기 때문에 hardware 구성이 복잡해진다. 만약 slave가 추가 된다면 선을 새로 연결해야 하며 addressing을 위해 software의 디자인이 변경되어야 한다. Master와 slave가 고정되어 있기 때문에 I2C에서 하는 것처럼 역할 변경을 할 수 없다. Flow control을 할 수 없다. Voltage level 이 동일해야 한다.	Master와 slave가 많아지면 복잡성이 증가한다. I2C 는 half duplex(반이중) 이다. 이 말은 하나의 선 SDA를 통해서 Data가 양 방향으로 갈 수 있지만 한번에는 하나의 데이터만 간다는 뜻이다. UART는 항상 한 방향으로만 가는데 반해 반 이중은 동시는 아니지만 양 방향이 가능하다.
참조	RS232 Interface>> UART는 회로를 의미하는 단어로, 일반적으로 EIA RS-232, RS-422, RS-485와 같은 통신 표준과 함께 사용한다.	SPI Interface>>	I2C Interface>>

I2C

• I2C 의 Slave 주소는 해당 Chip의 Datasheet에 Idx의 구성에 따라 여러가지로 될 수 있다는 것이 명시되어 있다. 여러 Chip이 같은 Bus를 통해서 연결될 수 있기 때문이다. 그래서 실제 IDx 의 회로 구성을 확인하여 주소값을 확인해야 한다.
• Slave I2C의 속도는 해당 Chip의 Register Setting 에 의해 변경될 수 있다. Clock 과 Data의 최대 속도를 확인하고 그 이상으로 셋팅하지 않아야 한다.
• I2C 에서 1Byte 단위로 데이터를 송신하기 때문에 9번째 bit를 보면 ACK 여부를 확인할 수 있다. Start와 Stop 신호를 제외하면 모두 이 1byte(8bit) 단위로 송신이 되며 보통 Slave Address(1byte), Register Address(1~2 Byte), Value(1Byte) 로 한 셋트를 송신하지만 인접한 Address 의 경우에는 연속으로 쓸 수 있다. 이를 Burst Write 혹은 Sequential Write 라고 부른다.
• I2C 를 여러 Chip 끼리 연결하려고 하면(같은 Bus) 신호의 Level 을 맞춰 주어야 한다. 보통 1.8V, 3.3V, 5V 등 이 있으며 이를 맞춰주기 위해서는 Level Shifter 가 회로에 구성되어 있어야 하면 그렇지 않으면 통신이 정상적으로 이루어 지지 않는다.
• I2C 를 이해할 때는 몇 V 로 동작하는지, Start Condition은 SDA 가 default 1인 상태에서 0으로 갈 때 신호가 시작되고, SDA, SCL 모두 default 1인 상태에서 0으로 갈 때가 동작을 진행한 상태이므로 우선순위가 높다 그래서 ACK 신호가 low(SCL high, SDA low) 인 것이다. Start 와 Stop(SDA가 0으로 먼저 떨어지고 SCL high 가 된 상태) 를 제외하면 총 9bit를 사용하는데 8bit 가 하나의 1byte 이므로 이를 보내기 위해서 사용되며 나머지 1bit 가 반대쪽의(write 시 slave 에서 잘 받았다고 보내는 신호) ACK 이다. Mater에서 read 시에는 데이터를 slave 쪽에서 보내는 데 이 때 데이터를 전부 보내고 나면 NACK 를 보내 더이상 보낼 데이터가 없다는 것을 알려준다.

I2C ACK(Link)