기초를 탄탄히

일반 기계식 키보드에서는 오른쪽 ctrl의 왼쪽 버튼(마우스 모양에 파일 모양버튼)을 누르면 vi에디터로 작성할 때 자동완성 목록이 나타난다.

애플 키보드를 이용한다면 control + p를 누르면 나타난다.

.vimrc에는 set wmnu를 추가해주면 된다.

1. 헤더 파일을 추가한다

#include <errno.h>

2. printf로 error의 원인을 메세지로 띄운다.

printf("Error: %s\n", strerror(errno));

혹은

perror("File Open Error");

이렇게 코딩을 해 놓으면 나중에 에러가 발생했을 때, File Open Error: (파일오픈에러의 이유)가 나타난다.

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

리눅스 서버 로그인 할 때 위와같은 메세지가 뜨는 경우

SSH 접속을 하는데 위와 같은 메세지가 뜬다면

ssh-keygen -R [아이피] 를 해서 새로운 keygen을 받고 다시 원래대로 ssh 접속을 해주면 된다. 보통 원래의 서버에 접속을 하면 서로간에 인증 과정을 거치는데 그 서버가 OS를 새로 깔거나 하면 이런 증상이 발생한다.

만약 위의 명령어로도 해결이 되지 않는다면...

1. yum -y install ssh

2. yum install openssh-server

3. vi etc/ssh/sshd_config에서 #port22라고 돼있는 부분 주석 해제

버추얼 박스 셋팅

<PINA, PORTA, DDRA>

Data Direction Register 는 입/출력을 바꿔주는 Register이다. DDR의 각 비트에 해당되는 PIN과 PORT에 영향을 끼친다. 0일 땐 input모드, 1일 땐 output 모드로 사용된다.

PORT는 DDR이 output 모드일 때 사용되는 Register이다. 

PIN은 DDR이 input 모드일 때 사용되는 Register이다.

의도한 결과: 1010 1010(0xAA)과 0101 0101(0x55)이 약간의 시간을 두고 교대로 왔다갔다 하면서 켜지게 하고 싶다.

실제 보드에 올린 결과: 1010 1010(AA) 형태로만 불이 들어왔다. 깜빡임이 없었다.

이유: DDRA = ~DDRA; 에서 반복문이 걸리기 때문에 DDRA = 0xAA; 코드가 다시 실행되고, 즉 0101 0101로 바뀌고 나서 delay가 없으므로 순식간에 다시 1010 1010 코드가 실행돼서 이런 결과가 생겼다.

즉 의도한 결과를 얻기 위한 코드를 다시 작성을 해보면 다음과 같다.

DDRA = 0xAA; 코드를 while문 위로 올렸다. 그랬더니 의도한 결과대로 정상 작동하는 것을 확인할 수 있었다.

<LED를 켜기 위한 코드>

본 글은 Atmega128L, Osc 12Mhz 보드에서 실험하였다.

준비물: 

LED가 연결된 port 확인! (portA, portB, portC....),

각 port에 해당되는 Data Direction Register(DDR) 확인!

DDR의 각 비트는 입/출력 방향을 결정하는 비트이며, 각 비트의 입/출력은 해당되는 port의 각 pin의 입/출력을 결정짓는다.

특정 핀에 해당하는 DDR 레지스터 값이 1이면 출력 용도로 사용 할 핀임을 의미하며, 반대로 0이면 입력 용도로 사용 할 핀임을 의미한다.

Atmega 128L에서 PORTA의 주소는 

PORTA에서 $1B($3B)라고 hex값으로 주소가 나와있는데 괄호 밖의 주소는 Atmega103 호환모드로 사용할 때의 주소라서 괄호 안의 주소를 사용하기로 한다. 즉, 0x3B를 사용한다.

_delay_ms함수를 사용하기 위해 #include <util/delay.h> 헤더파일을 추가했으며, 나머지는 레지스터 주소를 직접 건드리는 방식으로 코드를 사용했다.

PORTA에 값을 입력하면 LED가 켜지는 줄 알았지만 PORT0을 1로 설정을 안 했는데도 모든 LED가 다 켜져서 PORT0과 PORT7만 1로 설정을 하고 나머지를 모두 0으로 해보았다. 그런데도 모든 불빛이 다 들어와서 DDR 레지스터의 값을 LED0번과 LED7번만 켜지게 바꿨더니 원하는대로 동작이 되었다. PORTA는 영향을 안 미치는 줄 알았는데 while문에서 PORTA의값을 틸트(~) 시켰는데 LED가 on/off되는 것을 보면 좀 더 공부해봐야 알 것 같다. (LED가 DDR 셋팅으로만 불이 켜지는 이유가 회로도를 몰랐기 때문인데 현재 보드의 LED는 Vcc에

연결돼 있어서 PORTA의 initial value가 0이므로 ground와 비슷한 효과를 내서 LED가 켜지는 것이다. 만약 LED가 ground에 연결돼 있었다면 PORTA에 값을 넣었을 때 데이터시트

처럼 정상 작동하는 것을 확인할 수 있을 것 같다.)

새로 작성한 LED 0번과 LED 7번을 켜는 코드는 다음과 같다.

char(1바이트) 4개 = 4바이트

int(4바이트) 1개 = 4바이트

= 총 8바이트

구조체 사이즈도 8바이트가 나왔다!

위의 코드와 아래 코드의 사이즈에서 왜 차이가 나는 것일까?

이유는 패딩비트가 추가되었기 때문이다. 몇몇 컴파일러는 구조체의 필드를 메모리에 위치시킬 때 중간에 빈 공간없이 이어서 할당하는 경우도 있지만, 대부분의 컴파일러는 성능향상을 위해 CPU가 접근하기 쉬운 위치에 필드를 배치한다. 그러다보니 중간에 빈 공간이 들어가게 되는데 이것을 패딩비트라고 부른다.

32bit CPU는 메모리에서 값을 읽어올 때 한 번에 32bit씩(4Byte)를 읽어온다. 그런데 레지스터가 읽는 블록의 경계에 걸쳐 멤버 변수가 생긴다면 메모리를 읽을 때 두 개의 블록을 읽는 문제가 발생한다.

예를 들면, 구조체 안에서 char a, int b 이런 식으로 4Byte 단위로 생성을 안 했을 때 문제가 발생한다. 만약 구조체 멤버 b변수에 접근하려고 하면 어떻게 될까? 

구조체의 시작 주소에서 32bit를 읽어와도 멤버 b의 비트에 모두 접근 할 수 없다. 그래서 두 번 메모리를 읽어서 첫 번째 읽은 값에서 뒤의 24bit(char 8bit를 뺀 부분)와 두 번째 읽은 값에서 앞의 8bit를 합쳐서 멤버 b의 값을 구할 수 있다. 하지만!!!!! 한 번에 할 수 있는 일을 두 번에 걸쳐서 하는 것이기 때문에 성능저하가 발생한다.

그래서 대부분의 컴파일러는 CPU가 접근하기 쉬운 메모리 위치에 필드를 배치시켜서 패딩비트가 자동으로 들어가게 된다.

즉, char a, int b라고 선언한 부분에서는 멤버 변수 a와 b사이에는 3byte의 패딩 비트가 들어간 것이다. 이렇게 하면 메모리를 3바이트나 낭비하게 되지만 각 멤버에 접근할 때 한 번씩만 메모리를 읽으면 되기 때문에 성능저하가 발생하지 않는다.

하지만! #pragma pack(1) 이란 전처리어를 사용하면, 구조체 사이즈가 달라진다!

size=12는 pragma pack을 사용하기 전의 구조체 사이즈이고, size=9는 pragma pack을 사용했을 때의 구조체 사이즈이다.

char(1Byte) + short(2Byte) + short(2Byte) + int(4Byte) = 9Byte

하지만 pragma pack을 사용하기 전에는 char + short + padding bit = 4Byte,

short + padding bit = 4Byte,

int = 4Byte.... 그래서 12바이트가 나온 것이다.

요즘은 안 쓰인다고 하지만 예전에 메모리가 귀하던 시절에는 메모리를 조금이라도 아끼기 위해서 사용되었다고 한다.

이렇게 비트필드 구조체를 작성하고 sizeof로 크기를 찍어보면 1바이트가 나온다.

이렇게 비트필드 구조체를 작성하고 sizeof로 크기를 찍어보면 2바이트가 나온다. (2,2,2,2)로 작성하면 1바이트가 나온다.

char를 사용하면 최소 1바이트 부터 값이 찍히지만 int를 사용하면 4바이트부터 값이 찍힌다.

비트필드를 사용할 때는 변수명을 안 적을 수도 있는데 만약 char :0; 이라고 적으면 현재 워드(char, int)의 미사용 비트를 모두 버린다. 혹은 char :1;이런 식으로 변수명을 안 적어도 비트를 버리는 역할만 한다.