MCU에서 watchdog 타이머는 주로 fail-over 목적으로 사용됩니다. 뭔가 이유를 알 수 없는, 혹은 도저히 대응 불가능한 오류가 발생했을 때 꺼낼 수 있는 최후의 수단으로 시스템을 리셋시키는 용도입니다. watchdog = 경비견 이란 이름이 붙은 이유죠. 

컴퓨터로 프로그램들 사용하다 보면 [응답없음]이라 뜨면서 프로그램이 아무런 반응도 하지 않는 경우를 가끔 볼 수 있는데요, 임베디드 환경에서 이런 상황에 빠져 아무런 응답도 하지 않고 전기만 먹고 있으면 안되겠죠. 기본적으로 모든 가능한 경우를 따져가며 프로그램을 작성하고, 갖가지 상황에서 복구할 수 있는 수단을 마련해 두는데, watchdog timer는 이러한 복구 수단 중 최후의 보루로 주로 쓰입니다.

MCU 마다 다양한 형식의 watchdog timer가 있을 수 있는데요, myCortex 시리즈에서 쓰인 LM3S 칩셋의 watchdog timer는 아주 심플한 구성입니다.
watchdog 전용 타이머 카운터가 1개 있습니다. 이 카운터는 down counter이고, auto-reload 기능이 있습니다. 기본적인 설정을 마치고 watchdog 카운터를 활성화 시키면 auto-reload 레지스터에서 카운터로 읽어오고, 그때부터 1씩 감소시켜 나갑니다. 그러다가 0이 되면~ 인터럽트가 뜨고, 카운터는 다시 auto-reload 레지스터의 값을 읽어오고 카운팅을 계속해 나갑니다. 여기까지는 일반 타이머/카운터랑 동일합니다. LM3S의 watchdog 카운터가 일반 타이머와 다른 차이점은 한번 underflow interrupt가 발생한 다음 다음 underflow interrupt가 발생하기 전 까지 먼저 발생한 interrupt 가 clear 되지 않는다면 뒤도돌아보지 않고 시스템을 리셋시켜버린다는 점입니다.
한번 경고 날리고 그다음엔 바로 아웃~


myCortex 시리즈에서 사용하는 예를 살펴보겠습니다.
SysCtlPeripheralEnable(SYSCTL_PERIPH_WDOG0); WatchdogReloadSet(WATCHDOG0_BASE, WATCHDOG_TIMEOUT_SEC / 2 * SysCtlClockGet()); WatchdogResetEnable(WATCHDOG0_BASE); WatchdogEnable(WATCHDOG0_BASE); 위 코드는 watchdog timer를 초기화하는 코드입니다. (WATCHDOG_TIMEOUT_SEC / 2) 만큼 시간이 경과한 후 watchdog interrupt가 발생합니다. 위에서 설명한 바와 같이 두번 연속 인터럽트가 발생하면 리셋됩니다. 즉 WATCHDOG_TIMEOUT_SEC 만큼 시간이 경과하면 리셋이 발생하겠죠. 이처럼 리셋이 발생하지 않도록 하기 위해서는 틈틈이 "나 살아있소~"라고 알려줘야 합니다. 즉 두번째 인터럽트가 발생하기 전에 먼저 발생한 인터럽트를 클리어 해 주면 됩니다.
WatchdogIntClear(WATCHDOG0_BASE); 위 코드가 인터럽트 클리어 해 주는 코드입니다. 이런 코드를 watchdog timer를 kick 해준다 라고 표현하는데요, 꼭 개를 발로 차서 깨운다는 것 같기도 하고;;;
꼭 인터럽트가 뜬 상황에서만 클리어 할  수 있는 것은 아닙니다. 첫번째 인터럽트가 안떴더라도 그냥 클리어 하는 코드를 호출하더라도 아무 일 없이 그냥 지나갑니다. 그러니 시간주기 따지지 말고 틈틈이 한번씩 호출해 주면 됩니다.

작성한 펌웨어가 10초동안 반응이 없다면 강제로 리셋되도록 만들고 싶다면 WATCHDOG_TIMEOUT_SEC에 10을 넣어주면 됩니다. 그리고 종종 인터럽트를 클리어 해 주는 것입니다. 그러다 어딘가 문제가 생겨 무한루프에 빠졌거나 fault가 발생한 경우 등에는 더이상 인터럽트 클리어 함수가 호출될 수 없으니 10초 지난 후에 시스템 리셋!


watchdog timer는 최후의 수단입니다. 기본적으로 watchdog timer에 호소해야 하는 경우는 그리 많지 않습니다. 네트워크 통신 펌웨어를 만드는데 peer와의 hand shake가 엉망이 되었다거나 sub system이 반응이 없다거나 등 주로 외부 요인을 수반하는 아주 한정적인 케이스입니다. 자신이 만든 시스템이 이유없이 자꾸 죽는다거나 반응이 없다거나 한다면 watchdog timer를 써야겠다고 생각하기 전에 디버깅부터 먼저 해야 합니다. 이유없이 죽는 것은 없습니다. 다 이유가 있죠. 그리고 그 이유의 99.99%는 개발자 실수입니다. 컴파일러 버그, 칩 버그 같은 이유는 0.01%도 안됩니다. 이바닥에서 구르면서 터득한 진리 중 하나죠. 기계를 의심하기 전에 자기 머리를 탓해라;;;



참. watchdog timer쓸 때 주의사항 하나. JTAG 디버거로 step-by-step 디버깅 할때 watchdog timer 꺼두세요. 안그럼 마구마구 리셋되어버리겠죠.
디버깅할동안에는 자동으로 watchdog time를 정지시키는 함수가 있습니다. 위의 코드 조각 중 초기화 부분에 아래 코드 한줄만 넣어주면 됩니다.
WatchdogStallEnable(WATCHDOG0_BASE);
이렇게 하면 별도로 신경쓸 필요 없이 watchdog 타이머와 디버거를 함께 사용할 수 있습니다.

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

STM32F10x 시리즈 MCU의 PB3 핀은 기본적으로 JTDO로 사용됩니다. 필요한 경우 remap을 통하여 GPIO로 사용할 수 있습니다. JTAG 관련 5개 핀 모두 다 해당하는 말인데 콕찝어 PB3만 언급한 것은 이녀석이 SWO와도 multiplexing 되어 있기 때문입니다.
제가 격은 문제는 JTAG은 안쓰고 SWD만 쓰면서 어쩌다 보니 SWO가 활성화 되어버리면서 PB3를 제맘대로 못쓰는 일을 겪으면서 오늘 황금같은 토요일을 진창 날려버렸습니다. 아 열받어.

일단 SWO에 대한 언급은 STM32 데이터시트에 아래와 같이 언급되어 있습니다. 

저 빨간 박스 쳐 놓은 저 주석 한줄이 끝입니다 -_-;;;


asynchronous trace가 뭐냐 한참을 뒤졌네요. synchronous trace는 JTRACE 핀 5개를 이용한 것이고, asynchronous trace는 SWO 핀 하나만 사용하는 겁니다. 문제는 trace의 사용 여부는 펌웨어 코드 내부에서가 아니라 디버거 툴이 초기화 할 때 설정한다는 것입니다. 이제 코딩의 문제가 아닌 툴 셋팅의 문제로 돌아섰습니다.

IDE의 별별곳을 다 찔러봐도 SWO 끄는 옵션은 안보이더군요. 그러다 문득 화면 좌측 상단에 전에 안보이던(였던것 같은) 녹색 아이콘이 보였습니다. 마우스 커서를 올려보니 SWO가 ON 되어 있답니다. 누굴 약올리나...난 끄고 싶다고~

풍선도움말에 보니 PC Sampling-based profiling에 SWO가 쓰인다고 하네요. 불현듯 머리속을 치고 지나가는 며칠전 일. function 수행에 걸리는 시간을 좀 더 스마트하게 측정해 보고자 J-link에서 profiler를 써볼려고 몇군데 찔러봤던 일이 기억났습니다. 그때 내린 결론은 왜인지는 모르겠지만 일단 안된다였는데, 그때 profiler를 켜두곤 그냥 그대로 내버려 둔 것입니다. 아놔... 그래서 냉큼 껐습니다. 어디서 끄냐구요? 이거도 참 잘 숨겨놨더군요. 메인메뉴 J-Link->Function Profiler를 실행하면 뜨는 창에 Enable/Disable 버튼이 있습니다. 이걸 disable로 해놓으니 SWO 아이콘에서 녹색이 사라지는군요.

이제 PB3 놔줬겠지 하고 다시 해보니 이건 또 왠걸 여전히 SWO로 쓰이고 있는 것입니다. 또다시 머리 뜯으며 인터넷 뒤져보길 한시간여... 슬슬 지쳐가던 참에 또다시 머리속을 치고 지나가는 생각 하나. SWO 끈 다음에 보드 전원을 완전히 끊었다가 다시 붙여보진 않았던것 같습니다. 계속 warm booting만 하면서 디버깅 하고 있었으니 왠지 예전의 SWO 설정이 남아있는게 아닐까 싶더군요. 그래서 케이블 뽑았다가 다시 연결해서 해보니, 드디어 됩니다 ㅠ_ㅠ

창밖을 보니 해는 져서 깜깜하군요. 환상 날씨 토요일은 이렇게 SWO와 함께 날아갔습니다.
혹시 STM32에서 JTAG은 안쓰고 SWD는 쓰면서 PB3를 다른 용도로 사용하시는 분이 저같은 문제 겪으실까봐 정리해 놓습니다. 정리해 놓고 보니 참 드문 케이스일듯 하군요 -_-;
다음부터는 왠만하면 SWO 핀도 살려놔야 겠습니다. 그래야 trace기능 일부라도 쓸 수 있고, 이런 문제 겪을 일도 없구요.




이 문제 해결해볼려고 검색하다 동일한 문제를 일년전부터 겪고 있는 듯한 한분을 찾았습니다.
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FBIG%20PROBLEM%20WITH%20SPI%20Interface%20in%20STM32%20completly%20disaster%20of%20ST&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1863
답을 알려줄까 생각해 봤는데, 영 귀찮기도 하고, 게시판에서 쌈박질이나 하는 사람에게 짧은 영어로 메일썼다 뭔 쌍욕을 들어먹을지 두려워서 그냥 뒀습니다;; 게시판에서 싸우지 말자구요...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즘 하나같이 배터리 전원으로 동작하는 과제들만 해온것 같습니다. 다양한 배터리들을 만져보고 있는데요... 배터리의 에이즈라불리우는 배부름 현상에 대해 몇가지 이야기 하려 합니다.


배부름 현상, 영어로는 swelling 이라 부릅니다. 배터리가 빵빵해 지는 것을 말하는데요, 리튬이온 배터리보다 리튬 폴리머 배터리에서 더 강하게 관찰됩니다. 사실 배부름 현상 자체는 리튬이온과 리튬폴리머 양쪽에서 모두 발생합니다만, 리튬이온 전지는 단단한 금속캔으로 포장되어있다보니 내부 압력이 커져도 캔이 어느정도 버텨주는 것일 뿐입니다. 반면 리튬폴리머는 알루미늄 포일 같은 재질로 포장되어있어 내부압력이 조금만 증가해도 금방 빵빵해지죠.
제 휴대폰 배터리는 리튬이온입니다. 눈으로 보일 정도는 아니지만 충전기에 들어가기를 거부하고 있습니다;;;

일단 한번 빵빵해진 배터리는 복구 불가능입니다. 성능도 많이 떨어지구요. 화제나 폭발의 위험도 증가한다고 하는데, 제가 직접 경험해 보지는 못했습니다. 배터리의 에이즈라 불리는 이유죠. 불치병입니다.
고로 예방만이 방법인데요, 인터넷에 나오는 여러가지 방법들을 정리해보자면...
- 절대 과충전/과방전 시키지 않는다.
- 외부 충격을 주지 않는다. 특히 모서리 찍힘 등
이 두가지 정도로 요약됩니다. 그런데 제 경험상 둘 다 예방책은 아니더군요. 여전히 배는 불러오는데 뭔가 다른 이유가 있을것 같았습니다. 그래서 실험을 했습니다!!

신상 LiPo 배터리 5개를 실험에 투입.
1 - 처음 구입한 상태 그대로
2 - 완전 충전한 상태로
3 - 모서리 찌그러트려서 그대로
4 - 모서리 찌그러트리고 완전 충전한 상태로
5 - 완전 충전/완전 방전을 계속 반복(보호회로가 있어서 2.3V에서 cut)

충전은 TTA인증 휴대폰 충전기를 사용했습니다. 과충전은 안되도록 잘 차단되는 것은 장비로 확인했습니다. 충전전류는 약 0.5C 정도 됩니다. 이렇게 실험을 시작하고 두달이 흘렀군요. 결과는.... 그전에 한달 넘도록 배부름 현상이 안나타나길래 실험 때려칠뻔했습니다. 자, 다시 결과는...





두둥!
2번, 4번선수 배가 불러옵니다. 가장 의심했었던 5번은 쌩쌩하군요. 배부름현상의 원인은 바로 완전충전 상태로 내버려두는것. 오래동안 사용하지 않을 배터리는 적당히 힘빼놓은 상태로 보관해야 할듯 합니다.


실험에서 아쉬운 점이 몇가지 있는데요, 특히 5번 선수 방전 전류를 0.5C 정도로 했었는데, 이를 1C 정도로 끌어올렸을 경우 어떤 현상이 일어나는지, 과방전 보호회로가 없는 날쌜로 과방전 했을 때 어떤 현상이 일어나는 지는 확인하지 못했습니다. 더불어 자금과 시간 관계상 5개만 가지고 실험이 진행 된 점도 큰 문제점이죠. 다 떠나서 저가 중국산 배터리로 실험한것 자체가 신뢰도를 많이 까먹습니다^^
과학적으로 신뢰할 만한 실험 결과라고는 할 수 없지만 뭔가 심증을 가져볼 만한 결과일듯 해서 블로그에 정리해 봤습니다. 그냥 참고만 하시길 바랍니다.







 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

역시 w2atch 프로젝트 이야기입니다.

플라스틱 사출성형으로 케이스를 제작했고, 기본 바탕색을 스프레이로 올립니다. 그 위에 로고를 실크스크린으로 입힙니다. 여기에서 문제가 생겼습니다. 로고가 너무 복잡하군요.

첫번째로 들어온 로고는 총천연색입니다. 이분 실크스크린이 뭔지 모르시는 분이 분명합니다. 아...제가 로고는 실크로 올린다는 이야기를 안했었던가 잘 기억이 가물가물하군요.

여튼 이건 아님 이라고 다시 받은 로고는 3색. 근데 3가지 색상이 딱딱 맞닿아 있습니다. 이제는 실크가 뭔지 모르시는 분임이 확실해졌군요. 3*5cm 면적의 곡면 플라스틱 바디 위에 실크올리는데 각 색상별 스텐실을 정확한 위치에 올리는건 무리입니다. 고작 100개 만들어요~ 수작업이라구요. 무슨 3D 잉크젯을 생각하시는 건지...

머리아프군요. 정 안되면 스티커라도 만들어 붙여야 겠습니다. 분명 스티커는 싫다고 할듯한데 ㅠ_ㅠ

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즘 버닝중인 w2atch 과제에서 RTOS를 사용합니다. 작년에는 날코딩 했었는데, 그래도 올해는 좀 발전시켜보려는 의도입니다. uC/OS를 사용해 보려고 찔러보는 중입니다. 아마도 가장 유명한 RTOS 중 하나일 것인데 여태 한번도 써 볼 기회가 없었던 녀석이죠. 다른 분이 초기 작업을 다 해주셔서 그리 어렵지 않게 시작은 하고 있는데... 이녀석은 좀 특이하군요. 구조가 단순하긴 한데, 이해하기 쉽다는건 아닌것 같습니다. 뭐랄까요... 학교에서 다룰 만한 대상은 아닌것 같다는 느낌이랄까요? 역사라거나 이런걸 좀 찾아봐야 알겠지만 정통적인 OS 라기 보다는 필요에 의해 실무적 관점에서 구성된 것 같은 느낌입니다. 직관적이지 않아요 -_-; RTOS 공부가 목적이라면 다른걸로 찾아보는게 더 좋을것 같습니다. FreeRTOS 같은 녀석은 정말 교과서에 나오는 그대로입니다. 소스코드 보다보면 교과서 단락이 새록새록 떠오르는...;; 각각 장단점이 있겠죠^^

제조사 홈페이지에 가면 각종 자료와 포팅된 소스코드들을 다운로드 받을 수 있습니다. 비영리 목적으로는 무료입니다. 영리 목적으로는 라이센스 따로 받아야 해요. 그리 비싸진 않습니다. 근데 커널만 가지고 할 수 있는 일엔 한계가 있으니 FS, ETH, USB, BT등등 하나하나가 비싸다고 들었습니다. 이건 얼마씩 하는지 파악이 안되고 있네요. 여튼 지금은 커널만 사용하고 있습니다.


 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오늘 들어온 케이스입니다.
요즘 버닝중인 과제에서 쓰일 것인데요, 이더넷, 2.4GHz RF 인터페이스를 가지고 있고, IR 광통신도 단방향이지만 쬐끔 합니다.
케이스 판매 업체에서 제공하는 도면이 실물과 달라 꽤나 걱정됐었는데, 눈대중으로 맞춘것 치곤 잘 나온것 같습니다.

ps. 회사가 커지면서 이제 담배피시는 분도 합류하셨는데, 이럴땐 참 좋군요^^;


 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

아이디어가 정말 좋은것 같습니다. 실리콘 잉곳을 만드는 것처럼 seed를 매달고 위로 올라가면서 아래쪽을 경화시키는 방법입니다. 동일한 구조에서 UV laser, 2D mirror를 이용한 3D printer를 생각하고 있었는데, 이처럼 빔프로젝터를 이용해 면단위로 경화시키는 것은 생각을 못했네요. 역시 세상에는 똑독한 사람이 많아요 ^^

속도도 빠르고 기구도 소프트웨어도 아주 단순화 시킬 수 있어서 쉽게 자작할 수 있겠네요.
적당한 UV curing resin만 찾으면 다른 허들은 없을듯 합니다. 이 동영상 제작자는 몇가지 레진을 조합해서 사용한다고 하네요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

컴퓨터에서 숫자를 메모리에 저장할 때 사용되는 두가지 방식이 있습니다. Byte order에 따라 구분되는 방식이구요, 각각 Little Endian, Big Endian이라 불립니다. 이 두가지에 대한 설명은 인터넷에 많이 있습니다. 몇가지 링크를 첨부하는 것으로 설명을 대신합니다.

• http://recipes.egloos.com/4993723
• http://en.wikipedia.org/wiki/Endianness

요즘 프로세서들은 Little Endian쪽으로 많이 통일되어 가고 있습니다... 라고 말씀드리고 싶지만, Intel(AMD), ARM 계열이 거의 대부분인 현실에서 Intel과 ARM이 little endian을 사용하고 있으니 통일되어 가는 것 처럼 보이는 것일 뿐입니다;;; 참, AVR 계열도 little endian입니다. 한편 대형 서버 쪽에는 big endian도 심심찮게 보입니다. 특히 모토롤라 계열 칩셋이 big endian의 대표주자입니다.

여튼 byte order 이야기를 꺼내놓고 자세한 설명은 생략한다링크만 덜렁 걸어둔건 성의가 없겠죠? 오늘 이야기 하고자 하는 것은 이기종 시스템간 데이터 전달에서의 byte order 이슈입니다.
참고로 하나의 컴퓨터 시스템 내에서 byte order는 그다지 신경쓰지 않아도 됩니다. 컴파일러가 다 알아서 해 주니까요. 그런거 몰라도 됩니다. 

이기종 시스템... 뭔가 한자와 영어가 섞인 표현이 나오면 조금쯤 까질해 지는데...
더 까칠해 지기 전에 예를 통해 살펴보도록 하죠~

Little endian을 사용하는 컴퓨터 A에서 시리얼 포트를 이용하여 big endian을 사용하는 컴퓨터 B로 메시지를 하나 보낸다고 했을 때 문제가 생깁니다. 무엇이 문제가 되는지 살펴보려면 좀 자세히 들여다 봐야 겠군요.
컴퓨터 A에서 32bit integer 타입의 변수 a_val에 숫자 25,000,000(16진수로 0x017D7840)을 대입하면 이 값은 메모리에 아래와 같이 저장됩니다.

이 값을 시리얼 포트로 보내는 코드를 한번 들여다 봅시다. 아마 아래와 비슷한 모양을 가지고 있을것입니다.

SerialPort_SendByte() 함수가 4번 호출되겠죠. 위의 그림을 봤을 때 호출되는 순서는 0x40, 0x78, 0x7D, 0x01 순서대로 일 것입니다. 어드레스(c)를 1씩 증가(++)시켜가면서 호출했으니깐요.
시리얼 케이블을 통해 0x40이 가장 먼저 지나갑니다. 그 다음으로 0x78, 0x7D, 0x01 순서대로 지나갑니다. 컴퓨터 B에서는 어떤 일이 벌어질까요? 비슷한 코드가 있어서 수신된 데이터를 메모리에 저장할 것입니다.

비슷하게 SerialPort_RecvByte() 함수가 4번 호출됩니다. 주소(c) 역시 1씩 증가(++)시키면서요. 고스란히 수신되는 순서대로 메모리에 저장되겠죠? 첫번째 그림의 little endian과 같은 모양으로 저장됩니다. 잠깐만, B 컴퓨터는 big endian이라고 했었는데??

네...byte order가 반대로 되어버렸습니다. Big endian을 사용하는 컴퓨터 B의 메모리에 0x40, 0x78, 0x7D, 0x01이 저장된다면 이 값은 integer로 표현될 때 0x40707D01로 인식될 것입니다. 10진수로 표현하면 1,081,113,857이 되네요.
전화통화하면서 나는 "대한민국"이라 말했는데 상대방은 "국민한대"라고 받아적고 있습니다.

byte order가 다른 이기종 시스템간 데이터를 주고받을 때에는 상대방의 byte order를 알고 있어야만 하는 걸까요? 둘 중 하나이긴 한데, 상대방 정체를 모르니 난감합니다. 그래서 규칙이 하나 만들어 졌습니다. 바로 network byte order라는 것입니다.

Network Byte Order는 시스템 내부에서가 아닌 네트워크 상에서의 바이트 순서를 정의하고 있으며, big endian을 사용합니다. 반대로 컴퓨터 시스템 내부에서 사용되는 바이트 순서는 Host Byte Order 라고 합니다. 위에서 설명했었던, CPU따라 little이냐 big이냐 달라지는 그녀석이 바로 host byte order입니다.
위에서 모토롤라 계열 칩셋이 big endian의 대표주자라고 말씀드렸습니다. 모토롤라 계열 칩셋이 전통적으로 전화선 모뎀이나 이더넷 같은 통신장비에 많이 사용되어 왔었고, 그러다보니 network byte order가 big endian으로 자리잡은 것입니다.


살펴본 바와 같이 시스템간 통신을 위해서는 network byte order로 주고받는 것이 정석입니다. 그럼 내가 사용하는 시스템이 big endian이 아닌 경우에는 send하거나 receive할 때 마다 byte order를 뒤집어 줘야 한다는 의미입니다. macro 함수로 간단하게 처리되니 걱정하지 마세요~ 기억해야 할 내용은 통신할 때에는 byte order를 신경써야 한다는 것입니다.

네트워크에서 바이트 순서를 변경해 주는 메크로 함수는 ntoh, hton 입니다. Network TO Host, Host TO Network의 머릿글자를 따서 만들어진 이름이죠. 이 메크로들은 big endian을 사용하는 시스템에서는 아무 일도 안합니다. host byte order와 network byte order가 모두 big endian이니깐요. 한편 little endian을 사용하는 시스템에서는 바이트 순서를 뒤집어줍니다.
바이트 순서를 뒤집는 것에는 데이터 타입에 따라 메크로들이 여러개 있습니다.
2 byte 크기를 가지는 변수를 위해서는 ntohs(), htons()를 씁니다. 마지막의 s는 short를 의미합니다. 4바이트짜리 변수에는 ntohl(), htonl()을 씁니다. l은 long을 의미합니다.
little endian 시스템에서의 ntohs(), ntohl() 메크로 코드는 아래와 같습니다.
간단하죠? 뭔가 거창한게 있는게 아니라 열심히 노가다 뛰는 겁니다.



임베쟁이가 뜬금없이 network byte order 이야기를 꺼내들었습니다만 아직 원래 이야기 하려던 주제는 시작도 못했습니다;; 다음번에 숫자 데이터 타입과 사이즈, 음수 표현에 대한 이야기를 좀 한 다음에 마무리 하도록 하겠습니다~

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

향간에 이슈화 되었던 통신요금 과오납 환급.


이제 좀 한산해졌겠지 하고 들어가 봤더니 제게도 환급액이 있네요...;;
여태껏 살아오면서 한번도 이런 경우가 없었는데 뭔가 묘한 기분입니다. 이걸 기뻐해야 하나 버럭해야 하나 -_-;

LG U+에 3만원 조금 넘게 있습니다.
LG 텔레콤을 이용한건 그 옜날 PCS 시절 97년인가 98년부터 2년간 이었으니 십년도 지난 과거의 일이네요.
여튼 환급 신청 해 놨습니다.

이틀 걸린답니다.
타이어 펑크나면서 함께 펑크난 가계부에 눈꼽만큼 보탬이 될것 같습니다;;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

1117 LDO regulator 입니다. 크기 작고 출력 좋고 성능 좋고 값싸고... 두루두루 무난한 LDO여서 많이 씁니다. 보통은 3.3V나 5V 출력전압 고정형을 사용하는데, 일년에 두세번 정도는 다른 전압이 필요한 일이 생기는것 같습니다. 그럴 때 마다 데이타시트 뒤져보고 계산하길 반복하고 있으니, 이참에 정리해 버리자 하고 페이지를 열었습니다.

데이타시트에서 가져온 기본 회로도입니다. 그냥 이대로 쓰면 되죠.

V_REF = 1.25V 입니다. I_ADJ는 작으니깐 무시하면 되구요. 정상적인 regulation을 위한 minimum load current는 대략 5mA입니다. V_OUT / (R1 + R2) > 5mA 이면 되는거죠.
위 조건들 따져보면서 몇가지 쓰기편한 저항값들 넣어보면 대략 아래와 같은 테이블이 나옵니다.

쓴김에 LDO에 대해...
LDO : Low Drop-Out voltage. drop-out 전압은 (입력전압-출력전압)을 말합니다. 예를들어 7805는 drop out voltage가 2V입니다. 5V 출력을 내기 위해서는 최소한 7V 이상의 입력이 들어가야 하는거죠. 반면 1117은 drop out voltage가 1~1.3V 입니다. 그니깐 5V 출력 낼려면 6~6.3V의 입력이 가해져야 한다는 거죠. 조금 좋아졌나요? 뭐 별로 차이 안나잖아! 라고 하실 수 있습니다만...맞습니다. 1117은 무늬만 LDO입니다 ㅠ_ㅠ
LDO들 중에는 drop out voltage가 0.1V 정도 되는 녀석들도 있습니다. 물론 이런 것들은 출력 전류 얼마안되고 비싸고 등등등... 뭐 세상이 다 그렇죠 ^^

여튼 drop out voltage가 적으면 뭐가 좋으냐? linear regulator들은 좀 무식한 레귤레이터입니다. (입력전압-출력전압)*출력전류 만큼을 열 에너지로 방출하니깐요. 비효율적이죠. 뜨겁구요!! 어쨌든 같은 linear regulator이지만 drop out voltage가 작은 녀석이면 그나마 꾸미기에 따라 전력 변환 효율을 높일 수 있고 덜 뜨겁게 쓸 수 있다... 뭐 그렇습니다.
이런 단점은 있지만 쓰기 편하고 값싸고 비교적 노이즈도 적고 해서 많이 쓰이고 있습니다.


 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.