이어서 작성합니다.
 
11. switch 내부의 인수는 enum 으로!
switch (열거형변수){case 열거형값: 실행할코드; break;}
 
가독성이 높아집니다.
   case 0: -: 이러면 0 이 뭘 뜻하는지 또 살펴봐야지요.
 
11번을 마스터 하면 초보에서 레벨업하시는 겁니다.
 
12. 전역변수는 되도록 struct 안에
  -무조건 전역은 struct 안에 성질별로 그룹을 지으세요.
   전역변수의 100만개의 저주에서 탈출 가능합니다.
   int g_tmp; -> 이게 뭐하는 변수지? 글로벌변수이긴한데..
   int g_conv; -> 이게 뭐하는 변수지? 글로벌변수이긴한데..
   char g_terminal_increase;  -> 이게 뭐하는 변수지? 글로벌변수이긴한데..
 
   struct g_st_comm{
      int tmp; // 그냥 임시 변수지롱~~~
      int conv;
      char terminal_increase;
    } ;
  struct g_st_comm g_ST_COMM;
  g_ST_COMM.tmp; -> 뭔지는 모르겠지만 통신관련 글로벌 변수인거 같네. g_st_comm 구조체 가볼까?
  
13. 변수가 많으면 struct 안에 또 struct 로 변수 지정
   - 좀더 구조화 됩니다.
   struct st_comm{
      int tmp; // 그냥 임시 변수 메롱~~~
      int conv;
     strcut st_tmp {
      char terminal_increase;
      int tmp;
} tmp;
    } ;
   - 소속이 생기는 거죠. 엄마 아빠 난 누구의 자식이다! 덜 헷갈립니다. 이름 앞에 성이 붙는 것처럼.
 
14.  작은 함수 이름은 동사 다음에 명사 - 어느 방법이던 한쪽 방향으로 일관적으로
   int GetStatus(void);
   int Get_Status(void);
   int get_status(void);
 
15.  큰 그룹  함수 이름은 소속 뒤에 동사 명사
   void CommGetStatus(void);
   void CommInit(void);
   void CommSetVariable(void);
 
16. 쉬어가는 페이지 
   - 내 프로그램은 절대 보안을 위하여 외국인에게 해석될 수 없다! 세종대왕 만세!
   - 내 프로그램은 절대 국내용이다. 글로벌화 될 수 없다!
      어느 외국인이 내 코드를 수정하고자 하는가! 나는 결연히 반대한다.
    void ChoGiHwa(void); // 초기화함수
    int tae_i_ble: // 테이블
    char Imsisayong; // 임시사용
 
17. 뭔가 내용이  길어지면 함수로 
     안되면 { } 라도.
     기능을 주석으로 구분하지 마시고 함수로 만들던가 아니면 
 
  // 무슨 무슨 기능 
  {
    func1():
    func2():
   }
 
    func3():
    func4():
 
 // 5,6함수 호출해서 둘이서 뭔가 불꽃 튀기는 동작을 하거든요. 그래서 친구라서 보기 쉬우라고 한번 
 //  묶어주었어요.  이 둘사이에 절대 뭔가 끼워 넣으시면 큰일나요. 요거는 제발 분리하지 마세요~~~
  // 
   {
     func5():
     func6():
   }
      
18. crtl-s 는 나도 모르게 (이건 무의식의 세계)
 
19. 작명이 살길 영어공부 열심히. 자신만의 일관된 원칙
    do_chunchunhi(); // 천천히 동작 T.T slow 가 생각안나도 제발 이러시면.
    g_u8_comm_init_status: // 흠... 글로벌변수에 8비트 변수고 통신 초기화 상태 변수이군. 하하하
   
20. 레벨이 다른 두사람끼리 짝프로그래밍.
   - 레벨이 같거나 직급이 같으면 서로 멱살잡음. 개성은 소중하니깐요. ㅎㅎ
   - 해결안되는 버그가 있으면 짝 프로그래밍이 효과적입니다.
     후배는  설명하며코딩하고, 선배는 자세히 듣고.. (난 뒤 손가락에 회초리를 찰삭!)

 

 

안녕하세요.

사업으로 인해 2019년 상반기에 많이 바쁘기만 하여서 쓸만한 내용을 공유해야 되는데 그냥 미루고 있었네요.
어떤분이 제글을 기다린다고 쪽지도 주시고 해서 다시 한번 힘을 내보고자 합니다.
 
나름 제가 생각하는 저의 강점은 아래라고 생각하고 있습니다.
 
20년동안 검증된 결과이니 그냥 믿으셔도 될거 같습니다. ㅎㅎ
 
1. 남보다 2-3배 빨리
 
2. 남보다 2-3배 에러 없이
 
3. 코딩 실수로 인한 엄청난 결과(?) 압박감 속에 다운로드 횟수 조차 제약된,
   한방에 모든 기능이 성공해야 되는 상황 속에 긴장 코딩.
  ( 한번의 실수로 모든게 끝나는 인공위성 또는 인사사고 발생 가능성이 있는 장비에 
    비할 바는 아닙니다만 그래도 조금은 열악한 환경)
 
 
마침 이번에 인턴 사원이 들어와서 이야기했던 부분을 공유합니다.
코딩 하는 순서를 한번만 봐도 실력을 검증할 수 있는 하나의 방법이기도 합니다.
 
이유를 설명하려면 너무 길어져서 스스로 이해해 보시려고 하면 좋을거 같습니다.
해당 방법은 스타일과 습관이니 그렇다고 너무 집착 안해셔도 됩니다.
의도만 아시면 되요.
 
1. if 니 for 문 작성시 { 를 열면 자동으로 } 닫고 시작해라.
  요즘 코드 툴이 좋아서 이런거는 자동으로 해주는데 , notepad++ 를 쓰시거나 
  자동 코드 생성툴이 아니신 분들은 버릇을 들이셔야 합니다.
   왜 이게 좋은지는 다들 아실테니 설명하지 않겠습니다. 
 
  좋은 예)
    if(1) {
     }
  쓰고 다음에 안에 내용을 적는다.
    if(1) {
      func();
     }
 
 나쁜 예)
    if(1) {
     func():
  쓰고 다음에 } 를 한다.
    if(1) {
      func();
     }
 
 
2. 1번과 유사한건데 open 하면 바로 아래에서 close 함수를 바로 호출하고 그 중간에 코딩해라.
   fopen();
   쓰고
   바로 아래에
   fopen();
   fclose();
   호출 한뒤
   fopen();
   fread();
   fclose();
   같이 중간에 필요한 코드를 끼워 넣으라 .입니다.
   이 역시 나중에 디버깅 시간을 획기적으로 줄여줍니다.
    new , delete 마찬가지 입니다.
   그냥 습관화.
   
 
 
3. 역시 1번과 유사 (이 순서로 코딩)
   func( 하면 다음에 바로 닫고 시작
   func();
   fucc(a,b,c);
 
4. 곱하기 나누기 보다는 더하기 빼기로 더하기 빼기 보다는 더하기로 변환.
   b = a/2;
  보다는 b = a>>1;
  
  if( a -b > 1) 보다는 if( a > 1+ b )
  - 보통 a 는 b 보다 크다고 가정하고 코딩합니다만 세상일은 내 맘대로 돌아가지가 않지요.
    이런 경우입니다.
    unsigned int a,b;
    a = 2;  b= 3;
    if( a -b > 1) 와 if( a > 1 + b) 결과가 다릅니다. 로직상으로 같아 보이는데 말이죠.
 
 
5. if 문안에서 == 비교시 상수는 왼쪽
   
 if( i == 0  )보다는    if( 0 == i  )
 - 하지만 가독성 측면에서 왼쪽을 선호합니다만 초보는 오른쪽이 컴파일 실수를 줄입니다.
   == 을 = 로 쓰는 실수를 많이하거든요.
 
6. if 문안에서 == 비교시 변수는 항상 타입 캐스팅
 int i =1 ;
 float j = 1;
 if( i == j) 보다는   if( (int)i == (int)j)
  - 일반적으로 문제가 없긴한데 오래된(?) 일부 컴파일러는 이상 동작을 보이기도 합니다.
 
 
7. if 문 반드시 else 첨부 또는 바로위 변수 초기화
   
  if(xxx) {
    a = 0;
  } // else 절대 빼지 말것
  else  {
    a = 1;
  }
 
  또는 
  a = 1;
  if(xxx) {
    a = 0;
  } 
  
 
8. if 보다는 switch
  if(xxx) {
    func1():
  }
  else if(xxx) {
    func2():
  }
  else if(xxx) {
    func3():
  } // else 빼지 말것 설사 아무것도 안해도
  else {
  func4():
 }
 보다는 
  switch(xxx) {
    case 0:
      func1();
       break;
    case 1:
      func2();
       break;
    case 3:
      func2();
       break;
   default: //  default  내에 함수 안써도 무조건 같이 사용. 다음에 쓸일이 생김
      func1();
       break;
  }
 
 
9. switch 내에 코딩이 길어질대는 무조건 함수로 정리하여 한눈에 switch 마지막이 보일 수 있도록 정리
  
    switch(xxx) {
    case 0:
      // 이부분이 길어져서 한페이지 넘어가면 곤란함.
      // 가독성 저하
      // 함수로 변환하여 처리 요
       break;
    case 1:
      func2();
       break;
    case 3:
      func2();
       break;
   default: //  default  내에 함수 안써도 무조건 같이 사용. 다음에 쓸일이 생김
      func1();
       break;
  }
 
   
10. 한 파일을 너무 크게 만들지 말것
    method.c 로 너무 길어지만
    귀찮아도 method2.c 로 파일 자체를 분리
   단, 기능 자체는 성질이 다른 것으로 정확하게 분리 필요.
    같은 기능 함수모음을 2개 파일로 분류할 필요는 없음.
 
11. 소스 파일이 많아지면 디렉토리 관리 필요
    ./group1
    ./group2
    ./lcd
    ./file
    ./data
    main.c
    
단순하게 생각나는 데로만 정리하였습니다.
 
도움이 되셨으면 합니다.
데이터 시트 구글 번역기로 보시는 분
  - 남들보다 30분-1시간 일찍 출근하셔서 수능영단어 관련 책사서 하루에 100개씩 외우기
  - 퇴근 후 집에서 수능 독해집사서 일정 점수 나올때까지 풀어보기
  - 약 1-3년이면 구글번역기 안봐도 됩니다.
 
그런거 하기 싫다는 분
 - 단언컨데 개발자로서 절대 성장 불가합니다. 평생 제자리라고 확신합니다.
 - 미국 유학가서 나는 영어 안 배워란 비슷한 마음가짐입니다.
 
저는 중국어 과외도 잠시 받았습니다.
중국 데이터 시트를 구글 번역기 돌리는 참담함을 저는 참지 못하겠더군요.
구글에서 자료 찾으면 이제 영어보다 중국어가 더 많이 나옵니다. 앞으로 더 그럴겁니다.
 
대선배님들은 일본어 트랜지스터지 구독하면서 일본어 배워가며 기술을 습득했습니다.
배움에는 나의 한계나 끝이 없습니다.

 

한명이 프로그램하는데 느려서 한명을 더 투입하면 왜 2배로 안빨라지고
게다가 더 느려질까? 에 대한 과학적 고찰에 대한 책입니다.
 

 
 
개발자 1명에서 2명으로 늘이는데 왜 더 잘안되지라고 고민하시는 분들은 필독해보세요.
개발 문화가 바탕이 되어야 원하시는 결과가 나옵니다.
 
반드시 읽어보시길. 
1975년도판이니 인류가 이 고민을 한지 43년이 흘렀습니다.
 
[맨먼스의 미신]
 

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

안타까운 이력서를 볼 때가 많이 있습니다.
기본적인 내용만 고쳐도 면접보자고 연락옵니다.
 
1. 희망 연봉을 너무 적게 적는다.
   - 자신감 없음. 
 
2. 희망 연봉을 너무 많이 적는다.
   - 심사위원보다 보다 많음. 내가 그렇게 받고 싶다.
 
3. 포트폴리오가 없다.
   - 졸작이라도 뭔가 적어야 됨.
 
4. 뻔한 자기소개서
   - 어려서부터 엄하신 아버님과 온화화신 어머님 밑에서......
     (그래서 어쩌라고 우리 아버지도 엄하시고 우리 어머님도 온화하심)     
   - 회사에 필요한데 나는 다름 사람들과 이런점이 다르다...류로 기술
   - 결론은 앞에. 꼼꼼히 다 읽어볼 시간 없음.
 
5. 찌라시처럼 대량 살포한 흔적이 난다
   - 최소한 1-2줄은 고쳐서 제출해야 되지 않겠습니까
 
6. 뭐든 맡겨만 주시는 대로 다 열심히 하겠습니다.
   - 로보트는 탈락. 회사는 사람을 뽑습니다.
   - 하고 싶은 거 속이고 들어오면 결국 실망하고 나갑니다.
안녕하세요.
 
기본적인 Task 함수 구성법에 대하서
제가 사용하는 방법을 공유합니다.
 
많이들 사용하는 방법이라 새로울 것 없지만 모르시는 분들은 많은 도움이 되실겁니다.
 
LED를 500ms 로 껏다 켰다로 프로젝트를 많이 시작하시는데 다들 뻔하게 짭니다.
예제로 책에 그렇게 나와 있거든요.
 
[뉴비들]
while(1) {
led_on();
delay(500);
led_off();
delay(500);
}
 
근데 거기에서 하나만 더 들어가도 복잡해지면 코드가 산으로 가기 시작하죠.
여기서 부터는 책에 안나오죠.
 
처음 구조가 무서운게 책에 예제를 보고 짜기만 하면 , 그 다음 구현은 계속 그 구조에 얽매여 구현이 됩니다.
 
LED1 를 500ms 로 껏다 켯다 LED2는 250 ms 로 껏다켯다하기.
 
[뉴비들]
while(1) {
led1_on();
led2_on();
delay(250);
led2_off();
delay(250);
led1_off();
led2_on();
delay(250);
led2_off();
delay(250);
}
 
외부에서 보기에는 동작은 똑바로 합니다.
하지만 구현해야할 현실문제는 이거보다 수백배 복잡하죠.
 
LED1 를 500ms 로 껏다 켯다 LED2는 300 ms 로 껏다켯다하기
이거는 위와 같은 방식으로 구현은 되지만 정말 이상한 코드가 생성이 됩니다.
메인은 계속 복잡해지죠.
 
그럼 어쩌라고. 다 방법이 있습니다.
 
1. 문제를 단순화하자.
  1)  LED1 은 500ms 간격 on off /  LED2 은 300ms 간격 on off
  2)  LED1,2 은 초기 끄고 100ms 마다 확인한 뒤 특정 조건시 특정 LED off 도달
 
2. 기능을 함수 단위로 분리하자.
   1) 100ms 딜레이 
   2) LED1 on,off
   3) LED2 on,off
  
3. task 상태를 정의하자. 어짜피 외부 표출은 4가지 이다. 이 상태를 define 으로 정한다.
   1) led 모두 off
   2) led1 on , led2 off
   3) led2 on , led1 off
   4) led1 off , led2 off
 
 
복잡하고 필요없다고 생각할 수 있는 부분이 많으나, 수정이 편합니다.
시간 간격을 바꾸려면 define 문만 바꾸면 됩니다.
 
세세한 오류보다는 전체적인 구조 및 흐름을 이해해보려고 하세요.
그냥 머리속에서 나오늘 걸 짜다보니 별로 구조가 좋지는 못하는데
더 잘짜려면 임의의 LED 개수 대응까지 포함하면 될거 같습니다.
 
부족하지만 그래도 도움은 되실 겁니다.
그냥 영감만 얻으시길.
 
참고)
아래코드는 상상코딩으로 컴파일 여부는 장담못합니다.
깊게 생각 안하고 짠 코드라 그대로 적용 여부는 권장하지 않습니다.
단순 이해용입니다. 제대로 돌아갈런가 모르겠네요.
 
[아재들]
그냥 종이에 한번 끄적여 보고.

 

일단 main 부터 먼저 구현합니다.

아재들은 main 난잡한 걸 매우 싫어합니다.
 

 

TASK 상태를 정의

오타) #define TASK_LED_WAITING     4

 

초기화 함수도 만들어 주고

 

메인 TASK 를 구성합니다.

보시면 위에서 그림을 그린 5개의 TASK 가 state 변수를 보고 
해당 상태로 진입하도록 되어 있습니다.
각 case 문이 하나의 event 상태를 나타냅니다.

 

 

 

자 자그럼 아래 코드는 어떻게 구조를 잡아서 시작해야 될까요.

 
[뉴비들]
while(1) {
led_on();
delay(500);
led_off();
delay(500);
}
 
[아재들]
아니 이렇게 쉬운 예제 코드를 왜 이렇게 복잡하고 어렵께 짜지?
라고 생각할 수 있겠습니다만, 문제가 복잡해질 수록 이게 더 쉬워집니다.
 
산전수전 다 겪은 아재들은 고객이 다음에 분명 LED 를 더 복잡하게 킬 것을 요구를 예상하기 때문이죠.
예상을 잘 하고 다음 요구가 들어오면 며칠 헤메는 척 하다가
#define 정의변수 하나만 수정하고 고객의 요구사항이 너무 힘들다고 투덜거립니다.
(아 이런 영업기밀인 천기 누설을 하다니...)

 

 

조용히 손들어 봅시다.

 
하드웨어 엔지어는 PCB 에
펌웨어 엔지니어는 키보드에
 
코에서 나는 핏물
이마에서는 떨어지는 땀방울
눈에서 나는 눈물
 
로 PCB 와 키보드를 적셔 보신 분!

 

 
제가 성과급은 못드리지만 
토닥토닥 격려의 말씀을 전합니다.
[초보]
머리를 끙끙 싸매여
컴파일 오류로 코드를 썻다 지웠다를 반복하여 한달.
코딩 다하니 문서만들라네.
이런 내가 짠 코드를 내가 다시 보고 다이어그램 다시 그리는데 1주일
 
[고참]
설계 다이어그램 3일.
코딩 3일
설계 문서랑 보고서는 당연히 달라고 할 줄 알았지.
doxygen 으로 30초만에 완성. 끝
 
이번엔 조금 재미있는 이야기를 하려고합니다.
이전 편은 길게 썼더니 보기가 힘드네요.
 
말 그대로 과연 북한은 핵무기를 몇개 가지고 있는가? 인데
공학자의 관점에서 이야기해보겠습니다.

 

 
예전 게시글에서 이야기한 "논거를 가지고 이야기" 하는 것이 어떤 것인지 예를 들어보겠습니다.
 
아래 기사를 보면 분명 북한은 미국에 핵무기를 날릴 수 있는 기술이 있을 것 같습니다.
다만 재진입 기술이 없어서 제대로 도달할 가능성이 낮다고 생각되는데 일단
50%라고 가정합시다.
 
김정은씨는 부하한테 미국에게 99% 확율로 한방먹일 가능성이 얼마인지 그럼 몇 방을
미국한테 날려야하는지 물어봅니다.
 
"날래 보고 하라우"
 
과학자는 계산해보니 50% 확율로 미국에 핵무기를 떨어뜨릴 수 있다고 보고합니다.
그래서 중간 관리자가 반반이니 핵무기 2대만 있으면 된다고 보고합니다.
 
"떨어뜨릴 확율이 반반이니 예산도 절약하고 단 2대만 만들면 100% 미제를 조질 수 있습니다"
 
스위스 유학파 김정은씨가 이야기합니다.
 
"아오지 가라우"
 
이번에 과학자가 직접 보고합니다.
 
계산을 해보니 우리 탄도는 50% 확율로 미국에 떨어뜨릴 수 있습니다.
위원장님의 99% 확율로 미제놈을 조지려면 제 계산 결과는 아래와 같습니다.
 
위원장님의 요청대로 반대로 핵무기가 안 떨어질 확율은 1%이하여야 합니다.
즉 1/100 이하로 만들려면, 핵무기 한방당 1/2 확율로 안떨어짐이 연속적으로 발생하여야 하는데,
첫번째 사건과 두번째 사건은 독립적인 상황 즉, 독립상황 (independent event) 이므로
이렇게 계산할 수 있습니다.
 
(1/2) * (1/2) * (1/2) * .... * (1/2) 가 1/100 보다 작아지는 최대 개수로 생각하면 됩니다.
 
그래서 1/(2^N) < 1/100 을 만족하는 최소 N 을 구합니다.
2의 6승은 64 이므로 , 7이 답이겠군요.
 
"장군님, 우리 기술로 미제를 99% 조지려면 핵무기 7대를 만들어야 합니다.
 정확한 확율은 7대 만들시 99.9922% 정도 됩니다.  예산 편성 바랍니다"
 
스위스 유학파 김정은씨가 대답합니다.
"날래 진행하라우!"
 
따라서 , 현재 북한은 최소 7기 이상의 핵무기를 가지고 있다 라는게
저의 상상속의 생각입니다.
 
만약, 북한이 핵무기 보고서에 3개나 4개로 보고하면 미국은 코웃음을 칠겁니다.
거짓말 하고 있다고.
 
엔지니어는 이렇게 이야기해야합니다.
"감"을 가지고 이야기하지 말아야 합니다.
데이터로 말해야 합니다.
 
"2대만 만들면 되겠는데요" 라고 문돌이 처럼 말해서 아오지 가지 맙시다.
 
 
 
 
 
 

 

프로그램은 오래 짜왔지만 경력에 비하여 코딩 실력은 그리 뛰어나지 않다고 생각됩니다.
다만 제가 잘하는 걸 생각해보면 
나름 버그 없는 프로그램 (제가 개발한 제품들은 보통 24시간 꺼지지 않거나 하루 12시간 이상
계속적으로 사용되는 금융 데이터 처리하는 제품) 을 만들고, 
문제 발생시 디버깅 대처 능력이 매우 빠르다는 것입니다.
 
펌웨어 변경시마다 수십억 이상의 배상건이 발생할 가능성이 있는 시스템을 다루면서
극도의 긴장감과 공포속에서 나날을 보냈던 기억이 납니다. 
펌웨어 오류로 옆동네에서 회사 파산하고 개발자 도망가고 그런 모습들을 보면서 나한테도 그런일이 생길까
노심초사하던 시절이 있었습니다. 이 일도 익숙해지면 그냥 그렇더라구요. 
 
그런 와중에 살기위한 대책으로 자연스레 학습이 되었는데
버그 없는 코딩 이전에 버그 찾는 방법을 알려드립니다. 대부분 이걸 필요로 하실 겁니다.
 
펌웨어의 경우 문제가 발생하면 보통 2가지중 하나입니다.
   하드웨어냐 펌웨어냐!
   1) 펌웨어 엔지니어는 하드웨어를 의심하고 하드웨어 엔지니어는 펌웨어를 의심합니다.
   2) 답은 자신을 의심하세요. 남을 의심하는 것은 나에 대한 완벽한 논거가 확립된 뒤에야 
      의심하시면 됩니다.
 
제가 디버깅 하는 순서로 주로 현장 시스템인 경우입니다.
너무 원론적인 거라 잘 적용이 안될 수는 있지만 해결 방법은 대동소이합니다.
 
사례를 들면 좋은데 너무 전문적으로 가게 되어서 일반적인 방법론으로 풀어봅니다.
 
1. 전체를 파악한다.
   보고자가 말하는 의중을 제외하고 사실 데이터만 수집한다.
   직접 현상을 확인해본다. 책상머리에서 상상으로는 해결이 불가하다.
   참고로 보통 보고자들은 이상 발생에 대하여 과장보고하는 경우가 일반적입니다.
2. 그 중에서 확실한 것은 제외한다. 확실하다는 것은 이론과 실증을 통하여 자기 확인이 아닌
   정확한 데이터에 기반한 확실한 것을 말합니다.
   정확하게 이론과 실증입니다. 10년동안 잘 돌던 코드는 약간의 실증만 있는 코드 입니다. 
   이론으로 바탕되지 않은 코드죠. 해당 코드 부분을 잘라서 거의 모든 경우의 데이터 입력을 통한 
   시뮬레이션 후 일치를 확인하고 믿어야 합니다.
3. 2번을 생각하면 거의 모든게 의심스러워 집니다. 왜냐하면 데이터시트도 제대로 안보고 만든게 많기 때문이죠.
   이제서야 보기 시작합니다.
4. 발생 빈도를 확인한다.
   단 한번 발생하고 안했느냐. 지금도 계속 발생하느냐. 특정 조건에만 발생하느냐(이 경우는 해피한 경우입니다)
5. 약간은 좁혀진 범위에서 의심가는 부분을 과도하게 반복시켜서 재현이 되는지 확인한다.
   여기서 과도한 반복이 어려운 경우가 제일 문제가 되긴 합니다만 세상에 방법이 없는 건 없습니다.
   3개월에 한번 발생한다면 배포한 단말기들의 프로그램을 변경(의심부분 로그만 확인)하고 
    재현될때까지 정말 3개월동안 기다린 적도 있습니다. 총 수정까지 1년이 걸렸구요.
6. 과도한 반복을 통한 재현이 되면 거의 그 부분이 확실한 겁니다.
   그럼 재현이 잘 되니 점차 함수의 범위를 좁힐 수 있습니다.
   계속 큰데서 작은데로 범위를 좁혀갑니다.
   일반적으로 여기서 실수하는데 처음부터 의심가는 부분 작은데서만 집중하면 해결이 안됩니다.
   의외로 내가 확신했던 부분에서 오류가 발생합니다.
7. 확실한 코드 부분을 찾으면 동일한 상황을 만들어서 정확히 재현시켜 봅니다.
   그러면 100% 확인이 된 겁니다.
8. 이상하게도 재현이 안된다 라는 상황이 있습니다. 그러면 5번 참조. 재현이 됩니다.
   몇달만에  한번 생기더라도 그물을 쳐놓고 몇달 기다리면 됩니다.   
   이 문제로 회사가 망하는 게 아니라면 내부적으로 그 부분을 과도하게 동작하도록 처리하고
    최대한 많은 단말기에 다운로드해서 상황을 지켜봅니다. 발생이 더 잘되면 기뻐하면 됩니다.
9. 그럼에도 나는 완벽하다면 슬슬 하드웨어를 의심해야 됩니다.
   모든 데이터를 수집하세요. 날짜별 발생 빈도, 단말기 위치, 그날의 온도 습도 까지도 등등 
   빅데이터 처럼 모을 수 있으면 찾기가 더 쉽습니다.
10. 통신문제 처럼 되었다 안되었다 하면 통신관련 소자의 클럭이나 크리스탈에 달린 커패시터 값을 확인하세요.
11. 펌웨어가 운영 중 소자 다운시 리셋을 걸어주고 초기화 과정을 다시 잘 실행하는 지 확인하세요.
12. 해당 하드웨어가 노이즈 테스트 및 정전기 테스트는 하였는지 확인하고 안했다면 테스트 해보세요.
    라이터 부싯돌로도 단말기가 죽는 수도 있습니다.
13. 보드의 여러 소자들의 최대 주파수 범위내로 동작시키고 있는지, 데이터 시트를 몽땅 다시 다 확인해보세요.
14. 역시 보드의 여러 소자들의 리셋 타이밍도 맞게 동작시키고 있는데 확인해보세요.
15. 그래도 못찾으면 펌웨어가 와치독을 제대로 사용하고 있는지 확인하세요. 
    최악의 경우 재부팅은 되어야 겠지요. 그렇게 해서 가끔씩 재부팅하는 체로 동작하게 하세요. 
   시간도 벌고 일단 살고 봐야 되니깐. 
   그 다음에 퇴사하세요. (농담입니다 ㅎㅎ)
 
    
다음번에는 죽은 하드웨어도 인공호흡으로 살리는 
"PCB 노이즈 대책 코딩 기법"에 대하여 한번 올려드리겠습니다.
이런게 이론으로 있는지는 모르겠지만 저는 효과가 있다고 봅니다.
 
하드웨어 엔지니어가 엉망이라도 우리 펌웨어 엔지니어는 살려 낼 수 있습니다.
너무 하드웨어만 탓하지 마세요. 담에는 하드웨어 엔지니어가 펌웨어 엔지니어를 살려 줄껍니다.

 

+ Recent posts