영화 <기생충>에 나와 반짝 인기를 얻었던 감자칩.

보닐라 감자칩.

호기심에 사먹어 봤지만 기름맛 뿐이다.

🍖🍖 (2/5점)

 

감자칩은 역시...

포카칩이다.

' > 먹을것' 카테고리의 다른 글

남해 굴국밥  (0) 2020.10.24
샘표 시골식 된장국  (0) 2020.10.01
보닐라 감자칩  (0) 2020.09.30
인생에일  (0) 2020.09.22
리스토란테 냉동피자  (0) 2020.09.11
농심 김치 큰사발  (0) 2020.08.16

1. 일반 규정

1.1 C 언어 버전

규정

  1. 모든 프로그램은 ISO C 표준인 C99 버전을 준수하도록 작성해야 한다.
  2. C++ 컴파일러를 이용할 때에도 선택한 ISO C 버전의 표준에 맞게 컴파일러 옵션을 설정해 주어야 한다.
  3. #pragma 같은 확장 키워드와 인라인 어셈블리어는 되도록 적게 사용하여야 하며, 하드웨어에 직접적으로 연결되는 소수의 장치 드라이버 모듈로 사용이 국한되어야 한다.
  4. 전처리기 지시자 #define은 키워드의 이름을 바꾸는 데 사용되어서는 안 된다.

예시

#define begin  {	// Don’t do something like this...
#define end    } 	// ... nor this.
...
	for (int row = 0; row < MAX_ROWS; row++)
	begin
	...
	end         	// Let C be C, not some language you once loved.

이유

이 표준의 나머지 규칙을 명확하게 정의하려면 먼저 기본 프로그래밍 언어 사양에 동의하는 것이 중요합니다.

시행

이러한 규칙은 컴파일러 설정 및 코드 검토를 통해 시행됩니다.

 

'Digital Developer > Embedded C Coding Standard' 카테고리의 다른 글

[ECCS] 캐스트  (0) 2020.10.01
[ECCS] 괄호  (0) 2020.10.01
[ECCS] 중괄호  (0) 2020.09.30
[ECCS] 코드 길이  (0) 2020.09.30
[ECCS] C 언어 버전  (0) 2020.09.30
[ECCS] Embedded C Coding Standard  (0) 2020.09.20

실시간 동작을 보장하는 방법

시스템이 의도한 대로 작동하도록 보장하는 가장 쉬운 방법 중 하나는 요구사항을 충족하면서도 가능한 단순함을 유지하는 것입니다. 이것은 단순하게 할 수 있는 일을 복잡하게 처리하고 싶은 충동에 저항하는 것을 의미합니다. 토스터기로 빵 한 조각을 굽기 위한 것이라면, 그 위에 디스플레이 장치를 달거나 여러분에게 날씨 정보를 알려주도록 만들지는 마세요. 단지 빵을 굽기위해 적절한 시간동안 전열선을 켜도록 하세요. 이 간단한 작업은 수 년 동안 코드나 프로그래밍 가능한 장치 없이도 잘 수행되어 왔습니다.

 

프로그래머로서 문제에 마주치게 되면 우리는 바로 MCU의 소스 코드를 수정하려는 경향이 있습니다. 그러나 제품의 일부 기능(특히 전기 기계 구성품이 있는 제품의 경우)은 코드 없이도 잘 처리됩니다. 자동차 유리창을 움직이는 데에는 폴링 루프를 처리하고, 드라이버를 통한 모터를 조작하거나 언제 모터 동작을 멈춰야할지 피드백 받을 수 있는 센서를 감지하는 MCU가 필요하지 않습니다. 이 작업은 실제로 몇 개의 기계식 스위치와 다이오드로 처리할 수 있습니다. 창문이 걸려 움직이지 않는 에러 상황을 피드백 해주어야 하는 시스템의 경우 더 복잡한 솔루션을 사용할 수 밖에 없습니다. 그러나 엔지니어로서의 목표는 항상 동일해야 합니다. 즉, 복잡한 것을 추가하지 말고 문제를 최대한 간단하게 해결하라, 입니다.

 

하드웨어만으로 문제를 해결할 수 있는 경우라면, MCU 소스 코드를 분석하기 전에 먼저 해당 팀과 함께 하드웨어 문제의 가능성을 검토하십시오. 센서 상태에 대한 폴링을 수행하는 데 간단한 while 루프를 사용하여 문제를 처리할 수 있는 경우라면, 센서 상태를 폴링하기만 하면 됩니다. ISR(Interrupt Service Routine) 코딩을 시작할 필요가 없을 수 있습니다. MCU 기능을 단일 목적으로 사용한다면, 모든 기능을 갖춘 RTOS를 이용할 시 방해가 되는 경우가 많으니 RTOS를 사용하지 마십시오!

 

실시간 시스템 유형

실시간 동작을 구현하는 방법에는 여러 가지가 있습니다. 다음 섹션에서는 다양한 유형의 실시간 시스템에 대해 설명합니다. 또한 다음 시스템의 조합을 하위 시스템으로 함께 사용할 수도 있습니다. 이러한 서로 다른 서브시스템은 제품 레벨, 보드 레벨 또는 심지어 칩 레벨에서도 발생할 수 있습니다(이 접근방식은 16장 멀티프로세서 및 멀티 코어 시스템에서 다룹니다).

 

하드웨어

원래 실시간 시스템 하드웨어는 여전히 매우 엄격한 허용 오차 및 빠른 타이밍 요구 사항을 충족합니다. 이러한 하드웨어는 개별적인 디지털 논리회로 소자나 아날로그 소자 또는 프로그램 가능한 논리 소자 또는 ASIC으로 구현 할 수 있습니다. PLD(Programmable Logic Devices), CPLD(Complex Programmable Logic Devices), FPGA(Field Programmable Gate Arrays)는 프로그래밍 가능한 논리 장치 부분의 하드웨어 멤버입니다. 하드웨어 기반 실시간 시스템은 아날로그 필터, 폐쇄 루프 제어 및 간단한 상태 시스템에서부터 복잡한 비디오 코덱에 이르기까지 모든 것을 포함합니다. 절전을 염두에 두고 구현하면, ASIC을 이용하는 것이 MCU 기반 솔루션보다 더 적은 전력을 소비하도록 만들 수 있습니다. 병렬 처리라는 착각을 일으키는 싱글코어 MCU와는 달리 일반적으로 하드웨어는 병렬 처리와 (아주 단순하게 말해서)즉각적인 처리를 수행할 수 있는 장점이 있습니다.

 

실시간 하드웨어 개발의 단점은 일반적으로 다음과 같습니다.

  • 프로그래밍 불가능한 하드웨어 부품의 경직성.

  • 소프트웨어 또는 펌웨어 전문가보다 하드웨어 전문가가 많지 않다.

  • 전체 기능을 갖춘 프로그램 가능한 하드웨어 장치(예: 대형 FPGA)의 비용.

  • 주문 제작인 ASIC를 개발하는 데 드는 높은 비용.

베어메탈(Baremetal) 펌웨어

베어메탈 펌웨어는 기존 커널/스케줄러를 바탕으로 하지 않은 펌웨어입니다. 일부 엔지니어는 이 개념에서 한 걸음 더 나아가 진정한 베어메탈 펌웨어는 기존의 라이브러리(부품 업체가 제공하는 하드웨어 추상화 라이브러리 HAL)까지도 사용하지 않는 것이라 주장하며, 이러한 관점에도 몇 가지 장점이 있습니다. 베어메탈 구현 방식은 사용자 코드가 하드웨어의 모든 측면을 완전히 제어할 수 있다는 장점이 있습니다. 메인 루프 코드 실행이 중단되는 유일한 이유는 인터럽트가 작동되는 경우 뿐입니다. 이 경우 CPU를 제어할 수 있는 유일한 방법은 기존 ISR이 완료되거나 우선 순위가 더 높은 다른 인터럽트가 발생하는 것입니다.

 

베어메탈 펌웨어 솔루션은 비교적 간단하면서 소수의 작업들로만 이루어 졌거나 단일 작업일 때 탁월한 선택입니다. 펌웨어에 대한 관심을 유지하고 모범적인 예제를 따른다면, ISR 간의 상호 작용이 상대적으로 적기 때문에(일부 경우에는 ISR이 부족하기 때문에) 일반적으로 확정적 성능을 측정하고 보장하기가 쉽습니다. 극한의 과부하 상태인 MCU(또는 매우 제한적인 메모리 용량을 가진MCU)인 경우 베어메탈 펌웨어가 유일한 옵션입니다.

 

베어메탈 펌웨어는 이벤트를 비동기적으로 처리하면서 점점 정교해지기 때문에 RTOS에서 제공하는 기능과 중복되기 시작합니다. 명심해야 할 중요한 고려 사항은 개발자 본인의 스레드 세이프 시스템을 이용하는 대신, RTOS를 사용하면 RTOS 공급자가 입력한 모든 테스트의 혜택을 자동으로 누릴 수 있다는 것입니다. 또한, 현재 사용 가능한 모든 RTOS는 수 년 전부터 존재해 왔으며, 숨겨진 힘이 있는 코드를 사용할 수 있는 기회를 가지게 됩니다. RTOS를 개발한 사람들은 서로 다른 응용프로그램에 강력하고 유연한 기능을 제공하기 위해 많은 시간을 들여 기능을 조정하고 추가했습니다.

 

RTOS 기반 펌웨어

MCU에서 스케줄링 커널을 실행하는 펌웨어는 RTOS 기반 펌웨어입니다. 스케줄러와 일부 RTOS 프리미티브의 도입으로, 프로세서를 Task 스스로가 사용하는 것처럼 Task를 작동할 수 있습니다(2장 ‘RTOS Task 이해’에서 자세히 설명). RTOS를 사용하면 시스템이 백그라운드에서 다른 복잡한 작업을 수행하는 동안 가장 중요한 이벤트에 계속 응답할 수 있습니다.

 

이러한 모든 Task를 실행하는 데는 몇 가지 단점이 있습니다. 데이터를 공유하는 Task 간에 상호 종속성이 발생할 수 있으며, 제대로 처리되지 않으면 Task가 예기치 않게 차단됩니다. 이 문제를 처리하기 위한 조항이 있지만, 코드에 복잡성을 가중시킵니다. 일반적으로 인터럽트가 Task Signaling을 사용하여 인터럽트를 가능한 빨리 처리하고, 가능한 한 많은 프로세스를 Task에 할당합니다. 적절히 처리된다면 이 솔루션은 복잡한 상호 작용이 존재한다는 단점에도 불구하고 복잡한 시스템의 응답성을 유지하는 데 매우 적합합니다. 그러나 잘못 처리된다면, 이러한 설계 방식은 타이밍 지터가 많아지고 시스템의 명확성이 떨어지는 결과를 초래합니다.

 

RTOS 기반 소프트웨어

MMU(메모리 관리 장치 Memory Management Unit)와 CPU(중앙 처리 장치 Central Processing Unit)를 포함해서, OS에서 실행되는 소프트웨어는 RTOS 기반 소프트웨어로 간주됩니다. 이러한 접근 방식으로 구현되는 프로그램은 매우 복잡할 수 있으며, 다양한 내외부 시스템 간의 많은 상호 작용이 필요합니다. OS를 사용할 때의 이점은 OS와 함께 제공되는 모든 기능(하드웨어와 소프트웨어 모두를 포함하는)을 사용할 수 있다는 점입니다.

 

하드웨어 측면에서는, 더 많은 CPU 코어를 더 높은 클럭 속도로 실행할 수 있습니다. 사용 가능한 RAM과 메모리가 수 기가바이트에 이를 수 있습니다. 주변 장치 하드웨어를 추가하는 것은 (드라이버가 있는 경우) 카드를 추가하는 것만큼 간단합니다.

 

소프트웨어 측면에서는, 네트워킹 스택, UI 개발, 파일 처리 등을 위한 오픈 소스 및 업체에서 제공하는 솔루션이 많이 있습니다. 이러한 모든 기능과 옵션 밑바탕에서는 커널이 계속해서 실행되므로 중요한 작업이 무기한으로 차단되는 일은 없습니다(하지만 이는 기존 OS에서는 발생할 수 있습니다). 이 때문에 RTOS 기반 펌웨어와 마찬가지로 결정적인 성능을 얻을 수 있습니다.

#10 ‘말'은 잘 하는데 ‘글'이 안된다

  • 10시간의 강의, 책 한 권이 된다.

  • 구글 독스, 말하면 글로 써준다.

  • 첨단 기술을 이용하는 글쓰기

  • 볼테르, 말하는 것처럼 써라.

  • 유시민, 잘 쓴 글은 말하듯 자연스런 글이다. 말에서 멀어질수록 글은 어렵고 흉하고 멋이 없어진다.

 

#09 글쓰기를 위한 독서법

  • 주체적인 독서법 - 발췌독

  • 글을 잘 읽기 위해서도 구성을 알아야 한다. 저자의 전략(구성)을 알고 읽으면 더 많은 정보를 나의 것으로 만들 수 있다.

  • 읽기는 줄여가는 과정, 쓰기는 불려가는 과정

  • 쓰기에 도움 되는 읽기
  • 어휘를 눈여겨 보면서 읽기

  • 좋은 문장 되새김질 하기

  • 구성을 생각하면서 읽기

  • 내용만 파악하는 읽기는 쓰기에 도움이 많이 되지 않는다.

  • 요약, 필사

  • 작가의 글쓰기 전략을 파악하면서 읽기 - 적극적 독서

  • 요약 : 핵심 키워드, 카피, 사례

  • 강준만 칼럼

  • 정여울, 좋은 글쓰기의 최고 비결은 좋은 독자가 되는 것.

  • 이승우, 잘 쓴 사람은 내가 아는 한 잘 읽은 사람이다.

#08 생각도 훈련하면 느는 걸까

  • 평소에 생각을 모아둔다. 쌓이면 글을 쓰게 된다.

  • 평소에 생각을 쌓아둬라.

  • 원고지 시절에는 심사숙고 하고 글을 쓰기 시작했다. 컴퓨터 시대에는 간헐적으로 생각하고 간헐적으로 쓰는 패턴으로 변화했다.

  • 글을 쓰는 것이 생각의 과정이기도 하다.

  • 고민과 생각을 구별. 가결론을 내리는 생각. 고민은 결론이 없다.

  • 생각을 만들기 위해 독서를 하는 것이고, 자신만의 생각을 메모한다.

  • 수시로 자기 생각을 메모한다. 글 한 줄이 있느냐 없느냐 중요하다.

  • 메모는 생각의 씨앗이다.

  • 프로토타입 싱킹. 생각을 눈으로 볼 수 있는 형태로 변형한 것이 메모이다.

  • 다각도, 다단계로 생각해보기

  • 생각의 도구 활용

  • <생각의 탄생>

  • 스스로 자문해 보자

  • 구향수 시인, 다독, 다작, 다상량 ⇨ 다상량

  • 위하 소설가, 허삼관 매혈기, 쉬지않고 글을 써야만 마음의 문을 열 수 있고, 자기를 발견할 수 있다.

 

#07 감동은 구성에서 온다

  • 글의 설득과 감동은 구성력에서 온다.

  • 구성요소. 일기. 사실 + 느낌 + 다짐

  • 나열의 순서 속에서 전략이 들어 있다.

  • 시작 - 독자의 흥미를 낚는다. 피싱

  • 중간 - 근거, 이유 제시

  • 마무리 - 생각의 변화, 행동의 변화를 이끄는 메세지

  • 업무적 글쓰기, 정보전달 글쓰기 - 두괄식

  • 홍보글 - 특징, 장점, 사용시 이익과 혜택, 권유

  • 현상, 진단, 해법제시

  • 보고서 - 용건(개요), 추진배경(목적, 취지), 본론(현황, 문제점, 해결개선방안)

  • 노무현 정부 - 정부 보고서 형식 만듬

  • 대통령 기록관 - 참여정부 - 대통령과 함께 읽는 보고서 200여가지 보고서

  • 온라인 서점 방문, 책의 목차 보기

  • 부, 장, 절. '장' 수준의 목차를 정해본다.

  • 안토 체홉, 작가가 작품에서 실패하는 것에는 처음과 끝에 원인이 있다.

  • 안정효, 안정효의 글쓰기 만보, 글쓰기는 집짓기다.

 

지난 번 맥주 추천 글에서 '생활맥주'를 추천했었다.

내 잘못이다.

에일 맛 맥주가 아닌 진짜 에일 맥주가 있었다는 걸 몰랐다.

그 입맛 당기는 씁쓸한 맛이란... 캬~~~

적극 추천한다.

' > 먹을것' 카테고리의 다른 글

샘표 시골식 된장국  (0) 2020.10.01
보닐라 감자칩  (0) 2020.09.30
인생에일  (0) 2020.09.22
리스토란테 냉동피자  (0) 2020.09.11
농심 김치 큰사발  (0) 2020.08.16
모란역 '부산자매 돼지국밥'  (0) 2020.08.15

#06 첫문장이 어렵다면 2편

  • 개요로 시작. 스티브 잡스. "오늘은 제 삶에 대한 3가지 이야기를 들려 드리겠습니다."

  • 정의를 내린다. 글쓰기는 마라톤입니다. 왜 마라톤인가 …

  • 질문을 던진다. 글쓰기란 무엇일까요? 질문에 답하는 방식으로 전개.

  • 내가 겪은 에피소드로 시작.

  • 인용으로 시작.

  • 환기. 장하준 교수. 나쁜 사마리아인. 낚시. 

  • 지하철. 정의, 비유, 에피소드, 비교, 분류, 사건 사고, 역사

  • 메모의 중요성

  • 참전한 병사보다 티비로보는 작가가 전쟁에 대해 잘 쓴다.

  • 나를 일깨우는 글쓰기. 로제마리 마이어 델.  최초의 한 문장을 쓰고, 새로운 문장을 더 보태라.

  • 시작은 미약했으나 나중은 창대하리라. 시작은 미약할 수 밖에 없다. 무조건 시작하라. 터널의 끝은 반드시 있다.

 

타이밍 요구 사항의 범위

경험할 수 있는 타이밍 요구 사항의 범위를 설명하기 위해 아날로그-디지털 변환기(ADC)에서 판독값을 읽는 몇 가지 시스템을 살펴보겠습니다.

첫 번째 시스템은 인두기의 온도를 제어하기 위해 설정된 제어 시스템입니다(아래 그림 참조). 우리가 관심있는 부분은 MCU, ADC, 센서, 히터입니다.

MCU는 아래 세가지 역할을 합니다.

  • ADC를 통해 온도 센서 값을 읽어 옵니다.

  • 폐쇄 루프 제어 알고리즘을 실행합니다(인두기 팁의 온도를 일정하게 유지하기 위해).

  • 필요한 만큼 히터의 출력을 조정합니다.

아래 그림에서 확인할 수 있습니다.

 

인두기 팁의 온도가 놀라울 정도로 빠르게 변하지는 않기 때문에 MCU는 초당 50개의 ADC 값(50Hz)만 읽으면 됩니다. 히터 조절을 담당하는 제어 알고리즘은 5Hz의 더 느린 속도로 실행됩니다.

 

ADC는 한 신호선에 ‘High’를 출력하여 변환이 완료되었으며 MCU가 ADC 값을 내부 메모리로 전송할 준비가 되었음을 나타냅니다. ADC 값을 읽는 MCU는 ADC에서 내부 메모리로 데이터를 전송하는 데 최대 20ms가 소요됩니다(아래 그림 참조). 또한 MCU는 5Hz(200ms) 간격으로 히터를 제어하기 위한 업데이트된 값을 계산하기 위해 제어 알고리즘을 실행해야 합니다. 이러한 두 가지 사례 모두(아주 빠르지는 않더라도) 실시간 요구사항의 예입니다.

 

ADC 데이터 신호를 관측할 수 있는 고대역폭 네트워크 분석기 또는 오실로스코프는 ADC를 수십 GHz 속도로 읽을 수 있습니다. ADC의 원래(raw) 데이터는 주파수 영역으로 변환되어 초당 수십 번씩 고해상도 전면 패널에 그래픽으로 표시됩니다. 이와 같은 시스템은 많은 양의 프로세싱을 수행해야 하며, 제대로 작동하려면 매우 엄격한 타이밍 요구 사항을 준수해야 합니다.

 

스펙트럼의 중간 어딘가에 폐쇄 루프 모션 컨트롤러와 같은 시스템이 있습니다. 일반적으로 빠르게 움직이는 시스템에서 안정성을 제공하기 위해 수백Hz에서 수십kHz 사이의 PID 제어 루프를 실행해야 합니다. 그렇다면, 실시간은 얼마나 빠를까요? ADC 사례만 봐도 알 수 있듯이, 그것은 상황에 따라 다릅니다.

 

오실로스코프 또는 인두기같은 이전 사례에서 타이밍 요구 사항을 충족하지 못하면 성능이 저하되거나 잘못된 데이터가 보고됩니다. 인두기의 경우 온도 조절이 제대로 동작하지 않을 수 있습니다(구성 요소가 손상될 수 있음). 테스트 장비의 경우 기한 내에 동작하지 않는다면 판독치가 잘못되어 오류가 발생할 수 있습니다. 이는 일부 사람들에게는 큰 문제가 되지 않을 수 있지만, 보고되는 데이터의 정확성에 의존하는 해당 장비 사용자에게는 매우 큰 문제가 될 수 있습니다. 표준 검증에 사용되는 실험실 장비는 제품 적합성 검사에 사용됩니다. 알 수 없는 장비 오작동으로 인해 측정값이 부정확할 경우 잘못된 값이 나타날 수 있습니다. 결과 값을 믿기 어려운 의심스러운 테스트가 다시 실행될 수 있습니다. 재검사가 너무 자주 필요해지며 신뢰할 수 없는 판독치에 의존하게 된다면, 테스트 장비를 신뢰할 수 없게 되면서 결국 매출이 감소할 수 있습니다. 이는 모두 실시간 요구 사항이 지속적으로 충족되지 않았기 때문입니다.

 

UAV의 비행 제어 또는 산업 프로세스 제어에서의 모션 제어와 같은 시스템에서는 제어 알고리즘을 적시에 실행하지 못하면 충돌과 같이 물리적으로 더 치명적인 결과를 초래할 수 있습니다. 이러한 경우, 그 결과는 잠재적으로 생명을 위협할 수 있습니다.

 

다행히도 이러한 모든 장애 시나리오를 피하기 위해 취할 수 있는 조치가 있습니다.

 

+ Recent posts