하드웨어 이해하기

insoo2m의 이미지

안녕하세요. 제가 월간 프로그램세계 9월호 거의 마지막 부분에 보니깐 기고글 쓰시는 분이 말씀 하시기를 서적을 참고해 응용프로그램 짜는 소스만 배울게 아니라 앞으로의 프로그램 개발을 위해 짬나는 대로 시스템 내부, 운영체제 작동방식, 리눅스의 커널소스등을 공부하면 응용프로그램을 설계하고 코딩할때 많은 도움이 될 거라고 하더군요...

하드웨어의 특성을 정확히 모르고서 만든다면 최적의 상태를 만들 수 있는 프로그램을 못 만든다는 얘기인데요. 예를 들어 말하기를 cpu가 하나짜리와 두개짜리가 있는데 cpu가 하나일때는 하나씩 쓰레드를 실행하지만 프로그램을 듀얼 cpu를 쓰는 시스템에 최적으로 만들고 사용하면 쓰레드를 동시에 두개씩 실행할 수 있다 식으로 설명을 하시더라고요. (내용은 이해 했는데 글쓰기가 부족하네요. 죄송)

아무튼 이러한 특성을 알면 듀얼 시스템에서 좀더 나은 프로그램을 만들 수있겠죠. 하드웨어 쪽으로 공부하셨던 분들 중에 어떻게 공부를 하셨는지 (참고 서적, 나는 어디 어디 부분부터 했다, 몰랐는데 이렇게 하니깐 알았다, 등등) 자기만의 경험담을 자세하게 쭈악~~ 들려주셨으면 합니다.

insoo2m의 이미지

하드웨어 이해하기 란 제목으로

글을 게시판 "인수김" 입니다.

사실 글과 제목이 같은 것을 가르켰는데요...

제 글을 확인하시는 운영자님께서 너무 길어서

이렇게 줄이셨나봐요

그리고 많은 글들 남겨 주셔서 도움이 됩니다.

8051 책 많은데 말들 들어보니 가볍게 볼 부분이 아니네요

직접 보드 만들고 회로 똑같이 만들어서 해봐야 겠어요

hi~

익명 사용자의 이미지

그럼 고수님들 저도 질문 하나 해보겠습니다! 현재 저는 SI 업계에서 UNIX 프로그래밍을 하고 있습니다. 네트워크 프로그래밍과 일반 비즈니스 프로그래밍을 함께 하고 있습니다. 그리고 제가 이런 질문을 드리는 이유는 전공을 바꿔 이직을 할려고 생각하고 있기 때문입니다. 물에 빠진사람 건져주는셈치고 답변좀 해주셨으면 합니다. 질문 내용은 도대체 하드웨어(혹은 하드웨어 프로그래밍)를 공부할려면 도대체 어디서 부터 봐야 할까요? 이게 정말 궁금합니다. 저는 컴퓨터공학을 전공했지만 하드웨어는 영 꽝이라서요..... 기본적으로 현재 제가 가지고 있는 지식을 얘기드리면, 간단하게 소프트웨어쪽으로는 스티븐스님의 Unix 프로그래밍 책 3권 정도는 대부분 이해를 하고 있느 수준입니다. 그리고 어셈블리는 옛날 학부시절에 좀 하긴 했지만 현재는 MOV AX, 0x00과 몇개의 플래그와 레지스터 정도 밖에 생각이 안나는 것 같고요. 하지만 하드웨어 지식은 I=V/R 정도 밖에 모르는 수준인데 과연 어디서 부터 공부를 해야 할까요? 어떤 분들은 8051부터 시작하라고 충고하기도 하던데.... 고수님들의 진심어린 충고와 조언좀 부탁드리겠습니다.
아 마지막으로 기본 전자공학과 회로이론 지식은 어느정도를 공부해야 할지도 궁금하네요...
부탁드립니다. 고수님들....

익명 사용자의 이미지

전 위의 글을 쓴 사람입니다! 제 아는 분들도 이곳을 방문하는 관계로 실명을 공개치 못한데 대해서는 죄송하게 생각합니다. 그리고 아래에 몇분들이 답글을 주셔서 참 고맙습니다.아직까지 갈피를 못잡겠는데요, 특히 어디서부터 시작을 할지 감을 못잡겠네요..... "8051 기초 + 알파" 같은 책으로 바로 시작해도 될까요? 그리고 한편으론 내가 잘생각하고 있는건지 하는 걱정도 드네요... 좀더 조언들을 해주시면 안될까요?
그럼 다들 즐거운 하루 되세요!

라키시스의 이미지

아, 그리고,
선택하신 책으로 일단 51을 마스터(!) 하시고,
테스트 보드로 실험도 많이 해 보십시오.
실험하실 때 시리얼포트로 통신하는 부분은 반/드/시/ 해 보시기 바랍니다.
디버깅을 위해서 반드시 필요한 것입니다.

익명 사용자의 이미지

학생때 시리얼 통신 일주일동안 안되서
이렇게도 해보고 저렇게도 해보다가
길길이 날뛴 기억이 있어요.
날뛰고 난 다음날 저절로 되더군요. T_T

라키시스의 이미지

좋은 선택입니다.
8051 에서 동작하는 간단한 realtime os 비슷한거(사실 os 라고 할정도로 거창한것 말고, 작업 스케쥴링 같은거 정도만 해도 좋습니다.) 하나 만들어 보시기를 권합니다.
그리고 (그러실 리는 없겠지만) 8051에 너무 얽매이지 마십시오.
51은 변태(?) 프로세서입니다. ^^;;;
아랫분이 말씀하신 AVR 도 그럭저럭 많이 쓰이는 프로세서이며, 괜찮은 녀석입니다. 스펙 한번 읽어 보시길 권합니다.
ARM 같은 경우는 솔직히, 좀 크고 비싸지만,
요새 하도 쓰는데가 많더군요. 한번쯤 스펙 읽어 보시면 도움이 되리라 생각합니다.

또 다른 분께서 말씀하신대로 '소프트웨어쟁이' 들은 정말, 스코프로 디버깅하거나 필요한 회로를 (간단한것) 설계한다거나 하기는 힘들수밖에 없습니다. 그렇지만, 회로에 대해 '아는' 프로그래머는 프로젝트에서 하드웨어를 하는 사람들을 '리드' 할 수가 있습니다. 매우 중요한 사실이며, 실제 프로젝트 수행시 '내맘대로(^^;;)' 할 수 있게 됩니다. 회로에 대한 공부도 게을리하지 않으시길 권해드립니다.

익명 사용자의 이미지

good choice!

8051은 실제 필드에서 *가장* 많이 사용하는 디바이스입니다. 공부하시는데 자료가 많으니 편하실꺼에요. ^-^

익명 사용자의 이미지

전 반대방향으로 이직을 했는데요...

위에서 많은 분들이 답변을 해 주셨는데 다 맞는 말씀 같고요.
가장 구하기 쉬운 하드웨어를 이용해서 공부를 하는 것도 좋습니다. 물론 자신의 PC죠. 플로피를 이용해서 도스를 띄우고 도스에서 어셈블리를 이용해서 연습을 해 보는 것도 재미있죠. 가장 다루기 쉽고 자료도 구하기 쉬운 부분이 씨리얼 포트와 패러렐 포트이니 이런 포트를 통해서 LED에 불도 켰다가 껐다가 하다보면 많은 공부가 되죠.
이게 어느정도 익숙해지면 rom writer와 마이컴등을 구해서 빵보드 위에서 점퍼와이어로 자신만의 논리회로를 구성해 보시구요.

이것도 돈이 많이 든다고 생각이 되시면 애플 에뮬레이터 같은 걸 구해서 그 위에서 어셈블리로 모니터 프로그램 같은 걸 구현하는 연습을 해 보는 것도 좋을듯... 6502는 Load/Store 구조이니 8080쪽의 MOV구조에 익숙해진 분이라면 색다른 경험이 될 듯하고요.

이렇게 하면 돈도 별로 안 들면서 하드웨어에 대해서 많은 걸 배울 수 있죠.

그 이후는 얼마나 빨리 하드웨어 스펙을 읽고 자신의 것으로 만드느냐에 따라서 실력이 나타나게 되더라고요.

소프트웨어가 여러 분야로 나뉘듯 하드웨어도 많은 분야로 나뉘는데, 크게 아날로그와 디지털 둘로 나뉘죠. 아날로그를 하시려면 V=IR쪽도 많이 알아야 하고 오실로스코프도 좀 볼 줄 알아야 하지만 디지털은 그런 것보다는 소자의 기본특성과 게이트들의 성질, 그리고는 논리연산에 대해서 좀 알고 있으면 되는 것 같아요.

그런데 왜 그쪽으로 가시게요? 저는 이쪽이 더 미래가 밝다고 생각하고 주변사람의 만류에도 불구하고 5년간의 경력을 모두 포기하고 떨치고 나왔는데.... 하드웨어를 하면서 주변 세상이 모두 네트워크쪽으로 가고 있는 걸 보고, 내가 점점 구세대가 되어간다는 느낌을 지울 수 없더라고요.

익명 사용자의 이미지

저는 정말 임베디드가 좋습니다.
매우 작은 규모라면 저의 능력을 펼칠수 있어 좋고
중규모라면 여러사람들과 재미있게 일을 할 수 있어 좋고
대규모라면 저의 능력이 배가 될 기회를 잡을 수 있어서 좋습니다.

대규모(휴대폰)라면 활용할 만한 반야는 너무 많습니다.
휴대폰 정말 대규모 인원이 개발합니다. 장난감 같아도 장난 아닙니다.
리얼타임OS, 웨브라우저, 자바가상머신, 임베디드 TCP/IP,
그외에 소프트웨어 공학, 업무관리등등...
그래서 저는 임베디드 업계에 남기로 했습니다.

익명 사용자의 이미지

전 8051보다는 ATMEL사의 AVR을 권하고 싶네요.
속도도 빠르고, 무엇보다 에뮬레이터가 강력하거든요.
rs232와의 연결, fsk 모뎀과 rf 모뎀 제어,
TWI(two-wired serial interface - I2C)등을 해봤는데...
하다보면..data memory 1 byte때문에 목숨걸기도 하고 ^^;;...
bit 연산에 대해 좀 알게 되더군요.
특히 ATmega128을 이용한 제품을 써보세요...

익명 사용자의 이미지

저두 지식이 부족하여,......, '참고' 정도로 읽어 주세요.
어떤 사람의 이야기를 적어보겠습니다.
전형적인 데이터베이스 응용프로그램만을 개발하시던 분이 있었습니다.
한 10년정도? 대형 프로젝트말고, 중소업체용을 개발하시던 분이었습니다. 규모야 한사람이 수행할 정도의 일이니, 미루어 짐작이 가능하실듯 합니다.
대학전공도 물리학이었구요. 하드웨어? 그건 전자상가에서 업체 운영할때 조립하던 경험과 땜질을 잘하시는 정도였구요.
그 분이 약 3년전에 하드웨어 분야로 전직을 하셨습니다. 자동문을 개발하는 회사였는데요. 자동문의 모터콘트롤(전자제어하는 쪽에서는 아주 크리티컬한 예제라고 합니다. 마치 소프트웨어에서 DB사용하는 정도로 기본이 되기도 하는 분야면서 심도있게 하면 어려운 것이라는 ......) 및 이를 제어하는 시스템으로 원칩컴퓨터 기반에서 개발을 수행하게 되었습니다. 원칩(마이컴등으로 인식해도 될듯합니다만)에서 자동문 비상제어, 리모콘 시그널을 입력받아서 처리, 다수개의 자동문을 원격제어하는 게이트웨이 역할등을 수행하는 프로그램을 개발하게 되었지요. 물론 회로설계 부분과 부수적으로 필요한 칩들의 선정 등 아키텍쳐 설계는 전자쪽일을 수십년한 분이 맡아서 수행했다고 합니다. 일부는 산학협동으로 모대학 대학원생에게 의뢰하고요.
여기서 주 관심사는 그분이 맡은 분야입니다. 아무래도 소프트웨어 했던 분이라 땜질하고 오실로스코프로 디버깅하는 작업은 익숙해지기 어려웠나 봅니다. 그래서 그분은 원칩내에 제어시스템 프로그램을 수행하게 되었습니다. 원칩컴퓨터의 특성상 메모리를 계산해가면서 코딩을 수행해야 했겠지요. 개발은 보통 PC에서 수행했고(MDS장비가 없었습니다--;) PC에서 C언어로 개발하게 되는데, 원칩에 따라서 C언어 라이브러리등이 기존 C언어에 비해 다소 차이가 있기도 합니다. 컴파일러도 당근 차이가 있지요. printf() 같은 함수는 거의 써서는 안되고요(메모리땜시, 단 1KB도 엄청난 메모리라서 아껴야합니다). 해당 컴퓨터의 어셈블리언어와 혼합된 프로그램을 만들게 됩니다.
기존에 사용했던 C컴파일러 라이브러리 중 운영체제가 제공했던것들은(write, malloc등) 거의 사용이 불가합니다. 왜냐면 원칩에는 운영체제가 없기 때문이지요. 다른 이유는 메모리 문제입니다. write라는 시스템 호출조차도 엄청난 메모리(--;)를 차지하기 때문에 링크를 할 수 없습니다.(큰 아픔이지요) 즉, 운영체제 비슷한 루틴조차도 만들어서 넣어야 합니다. 마치 10~15년 전에 도스에서 TSR같은 걸 만들듯 또는 포트를 직접제어해서 IO디바이스 드라이버를 만들듯이 말입니다. 크로스컴파일해서 PC용 에뮬레이터라도 있으면, 돌려보고 디버깅도 해볼수 있습니다만, 제반 하드웨어가 특성이 있을 경우는 이나마도 불가합니다. 따라서 크로스컴파일 한 바이너리프로그램을 보드의 쓰기가능롬으로 다운로드하고 하드웨어를 리셋하여 해당 프로그램을 돌려보고 하드웨어 곳곳에 잭으로 연결하여 오실로스코프 등에서 디버깅 하거나, PC로 데이터를 업로드하게 해서(RS-232등으로 연결, 터미널 프로그램등으로) 디버깅을 해보고 다시 코딩해서 ... 이 작업을 반복적으로 수행하게 되지요.
기존 범용운영체제에서 프로그램을 개발했던 분이라면, 기존 운영체제의 고마움을 실감하게 되고, 감사하게되지요.
왜냐하면, 이러한 시스템개발에서 그나마 소프트웨어쟁이(?)가 할 수 있는 일은 제어프로그램인데, 이 제어프로그램은 운영체제를 아주 아주 간소화해서 특수목적용(이정도가 어울리는 듯, 운영체제란 말은 부적당) 제어프로그램을 개발하는 것이기 때문입니다. 전형적인 소프트웨어프로그래머가 할 수 있는 일은 한가지 정도 더 있습니다. 시스템 개발을 완료하고, 이를 모니터링하는 프로그램을 만들 수 있겠습니다. 즉, 하드웨어 장치로 부터 RS-232등으로 신호를 입력받아 이를 PC등의 컴퓨터에서 통계, 분석, 감사등을 수행하는 용도의 프로그램 개발이랄까요?

* 두서없이 말씀드려 죄송합니다.
* 제 나름대로 정리하면
- 운영체제 비스무리한 것을 만들수 있으면 좋고, 운영체제 수준까지는 안가더라도 개념을 가지고 있으면 좋다.
- 인터럽트, IO방식(memory mapped, programmed, dma)에 대해 알고 있어야 한다. 당근 프로그램도 할수 있어야 한다.
- 고수준 디버깅 수행은 현실적으로 불가능하므로 메모리 덤프에 능할 수록 좋다(당연히 어셈블리 능력이 요구된다)
- 기초적인 자료구조를 아주 효율적으로 만들수 있어야한다. queue, stack등, 링크드리스트는 사용하기 힘들다(메모리, 속도땜시)
- 혹시라도 부자 하드웨어개발에서는 C++등과 같은 도구와 다양한 실시간 운영체제 상에서 작업을 수행할 수도 있다. 이 경우는 아주 행복하다. 그래도 메모리 아끼는 전략은 필수적이다.
- PDA등의 시스템을 위한 프로그램 개발도구를(공개버전도 많아요^^) 사용해서 연습할 수도 있다.(그러나, 이미 업종이 상당히 굳어지겠네요.)
- 소프트웨어 로직으로 구현이 어려운것은( 예. 타이머의 어떤 기능이 필요한데?)등은 불가능할경우 하드웨어로 만들어 달라고 한다.

-----------------------
끝입니다요.

익명 사용자의 이미지

답글쓴사람인데요.
- 님께서 고수준 통신에는 능하신것 같습니다.
OSI 7레이어 참조모델로 봤을때, Transport레이어 수준에서 주로 작업하신것 같은데요, 하드웨어 통신에서는 당근 데이터링크 수준(IP도 아닌, 이더넷카드 제어수준?)이랍니다. 심지어 데이터 전송시 깨지는(오류, 체크섬)것을 검사하는 루틴 및 몇몇개의 세세한 것이 필요할 수 있습니다.허나, 통신프로그램 개념을 가지고 계신다는것은 보탬이 되리라고 저도 희망합니다.
- 제작된 하드웨어를 여러개 연동하거나, 이를 원격제어하는 쪽으로 택하신다면(그런 업종 찾기도 만만치 않죠?) 보다 전공(?)을 살릴수 있을 것으로 보입니다요.

라키시스의 이미지

전 고수는 절대 아닙니다만,
Digital Systems - Principles and applications / Tocci / Prentice hall
Computer System Architecture / Mano / Prentice hall
정도를 완전히 이해하실 수 있는 수준이면 기초는 충분하다고 생각합니다.

그에 더해서 간단한 컨트롤러 하나를 선정해서 스펙을 읽어보시고,
프로그램을 만들어 보시면 되리라 생각합니다.

8051도 괜찮구요, (솔직히 51 계열은, 좀 골때리는(!) 구석이 있어서 처음
하면서 개념잡기는 약간.. 뭐합니다만, 실제 field 에서 많이 쓰는 컨트롤러니까
선택해서 살펴볼만한 가치는 충분합니다.)

작은 사양의 RISC CPU 를 하나 섭렵해 보시는 것도 괜찮습니다.

어셈블리가 어렵다고들 하시는데, 프로세서가 간단하면 어셈블리도 간단합니다.
단지, 전체적인 프로그램의 구조를 생각하면서 프로그래밍 하기가 어렵기 때문에
어셈블리가 어렵다고 하는것입니다. 51 같은 컨트롤러들의 어셈블리는
명령셋도 몇개 안되고, 해 보시면 금방 익히실 수 있습니다.

정작 어렵고 골치아픈건 회로상의 노이즈나, 회로 설계상의 잘못을 잡는 것인데,
이건 제가 그정도의 고수가 아니기 때문에 뭐라고 말씀은 드리지 못하겠습니다만, 회로 안정의 문제는 '경험' 과 '시행착오'가 매우 큰 변수로 작용 하기 때문에
'많이 해 보는것이 장땡이다' 라고 말씀드리겠습니다 :(

익명 사용자의 이미지

하드웨어 이해하는데 가장 빠른 방법은 보드 하나 라도 자기손으로 만들어 보는 것 아닐까요?
80188 정도 라도.

Paladin의 이미지

진짜 경험담을 말슴해드리지요.

물리적 특성을 계측하는 인터페이스 카드를 다루었었죠. 이 인터페이스 카드는 검침기를 물질에 꼿으면 아날로그 전류을 받아 그것을 디지털로 숫자화합니다. 그리고 그 숫자를 특정 레지스터에 저장을 하죠.

이 카드를 PC에 꼿아서 해당 숫자를 읽어 들이는게 관심사인데, 간단합니다. 그냥 port를 읽어 들이면 됩니다. 그리고 해당 하드웨어로 명령어를 보낼려면 명령어를 관장하는 레지스트에다가 write를 하면되죠. 값에 따른 행동은 하드웨어 메뉴얼에 잘 설명이 되어 있죠.

이런 경험담은 표준 PCI 카드에도 적용될 수 있습니다. PCI 카드도 뭐 특별히 잘난 점은 없습니다. 이것도 보면 데이터 레지스터, 명령어 레지스터를 가지고 있지요. 옛날의 MS-DOS같은 경우는 모든게 실메모리 주소를 직접 다루기에 프로그램 짜는게 어떻게 보면 아주 쉽습니다. 그러나 요즘 윈도우나 리눅스의 경우에는 실메모리주소를 다루지는 않고, 또한 저런 접근은 커널 모드에서 해야하기에 여러 가지를 거쳐야하죠.

그 여러가지가 문제인데, 윈도우의 경우에는 DDK를 통해 접근하는 방법을 알수 있습니다. 관심을 좀 집중하면 다루는게 그다지 어렵지는 않습니다.

PCI의 경우 각 카드마다 VendorID와 DeviceID라는 고유 인식 번호(부팅할때 보여지죠, 잘 기억했다가 써먹야야 함)가 있습니다. 일단 그걸 알아내고, 그다음 초기화하고,...기타등등한 후 해당 포트에 Read/Write 해야하죠. Data 레지스트에 막 Read/Write만한다고 카드가 작동하는건 아니고, 데이타에 Write하고나면, 명령어 레지스터에 가서 명령어에 대한 Write(이때는 Setting이라고 해야겠죠)를 해야 데이타 레지스터에 대해 뭔가 처리를 하죠.

어떻게 하면 어떻게 처리된다라는건 PCI 하드웨어 메뉴얼에 다 있습니다.

한때 네트웍 카드의 하드웨어 메뉴얼을 보았엇는데 졸라 복잡하더군요.

인텔 본사에 가서 잘 뒤져 보면, 인텔에서 만드는 네트웍 카드에 대한 하드웨어 메뉴얼을 다운로드 받을 수 있는데 관심이 있으면 받아서 한번 보세요. 어렵기는 하지만 문서가 거의 예술입니다. 하드웨어에 대해 정말 잘 설명을 해두었습니다.

9th Paladin

익명 사용자의 이미지

아직 하드웨어를 공부하기엔 이르다고 봅니다.
물론 하드웨어를 공부해서 얻는 이점도 있지만
소프트웨어 만큼 간단한게 아니라서
공부하려면 많은 삽질이 필요하지 않을까요?
삽질을 피하기위해,....
지금은 소프트웨어에 치중하시고,
나중에 하드웨어가 좀더 간단해지고
공부해지기 편하게 되면, 배우는게 어떨까요?
저는 그렇게 하려고 소프트웨어부터
공부하고 있습니다. 물론 하드웨어를 몰라서
막히기도 합니다만.. 아직 절박할정도는
아니네요.

익명 사용자의 이미지

소프트웨어의 복잡도는 하드웨어와 비교할 수 없이 크다고 알고 있습니다.
물론 하드웨어도 논리레벨이 아니라 소자단위로 들어가면 학문적인 깊이가 있겠지만 소프트웨어가 간단하다는 말이 오해의 소지가 있어서 답글달아봤습니다.

익명 사용자의 이미지

하드웨어 시스템은 더 복잡 해 지면 복잡 해 지지 더 단순 해 지지는 않는 다
고 생각 됩니다.

익명 사용자의 이미지

저는 프로그래머의 발걸음을 이제 막 걷고 있는 초보-_-; 입니다만 .. 언젠가 읽었던 [Zen of Optimazer : 어셈블리 최적화 테크닉]이라는 책이 기억나서 글을 올려봅니다.

그 책이 808x부터 80386,486,펜티엄 어셈블리까지 다루고 있는데 어셈블리 최적화라는 것은 확실히 기계의 내부를 잘 알지 않으면 어려운거고, 그리고 컴파일러가 아무리 잘 컴파일 해봐야 뛰어난 어셈블리 프로그래머가 최적화 한 것보다 더 잘 최적화 할 수는 없는거죠. ( 거기 루틴들 보면 정말 어이없을정도로 최적화 되어있습니다만 )

.. 뭐 하지만, 최근에는 CPU의 자원도 넘쳐나고 메모리도 풍족한 편이죠 ( 모바일프로그래밍은 예외입니다만 ) . 그리고, 좋은 OS가 많죠. 그래서 제 생각입니다만 , 그냥 교양으로 어셈을 배워두신다거나 하드웨어의 개략적인 특성을 아시는 것은 좋지만요 . 그것보다 자신이 프로그램이 작동하는 플랫폼을 잘 이해하는게 좋지 않을까 생각합니다.

윈도우 프로그래머라면 윈도우 API와 윈도우의 특성 이라던가 그정도만 하셔도 충분하지 않을까 합니다. 다만 저같은 경우는 옛날에 끄적대어서 잠깐 배웠던 Z80 어셈블리와 그당시에 열심히 배운 MSX하드웨어 특성같은거 그런게 간간히 도움이 될때가 많더군요.

ihavnoid의 이미지

마이크로프로세서 구조, 전자회로, 컴파일러 등등....
이런것들에 대해서 모두 공부할 수 있으면 좋겠지만.....

그렇지 않으면 운영체제에 대해서 공부해 보시는 것이 좋을 듯 합니다.
학생이시라면 학교 전산계열 학과에 운영체제 강의가 있을테고....
아니시라면 운영체제에 관한 좋은 책들이 많으니... 그것들을 좀 공부해 보시는 것이...

특히 Tanenbaum 교수의 Modern Operating Systems 강추입니다.
요즘도 침대 머리밑에 놓고 가끔씩 봅니다...
컴퓨터 소프트웨어 작동의 큰 그림이 보이더군요.....

하드웨어의 큰 그림을 보실 수 있으시다면 좋겠지만....
시간이 부족하시면 OS를 확실히 공부하시는 것이 좋을 것 같습니다....

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

익명 사용자의 이미지

다르다와 틀리다도 구별 못하시는 분들이 많군요.

익명 사용자의 이미지

저도 8051한다음 프로그램 했을때.. 전과 조금 틀리게 느껴졌죠...
C를 해도... 메모리를 생각해가며 하고.. ㅡ.ㅡa
여튼... 작동하는게 대충 머리에 그려지니까 조금더 실제적으로 프로그램이 짜지는듯 하더라구요...

익명 사용자의 이미지

하드웨어에대한 개념이 하나도 없었는데..
8051 하니깐 개념이 잡히더군요.
그전엔 인터럽트 백터 테이블이
있다는거만 알았지 뭔지는 정확히 몰랐죠.
아무튼 아무거나 cpu하나잡고 공부해보세요.
단 386은 넘 복잡해서
처음엔 힘들지 않을까 하네요.

lovehis의 이미지

새소리 키트
->
LED 깜빡이...
라디어 키트
과학상자....
->
M. Morris Mano 의 Digital Logic and Computer Design
->
기초 전자회로 실험
->
ORCAD, PCAD, CAD-STAR
->
8051 보드 설계, 8522 PIO....
->
기타 CPU프로그래밍.... 잡다한거....
->
188
->
Linux Device driver....

뭐.. 어릴때부터... 대충 이런 순서로 했습니다...
--
늘...

익명 사용자의 이미지

병렬형 프로그래밍 쪽을 보시는 것은 어떠하실까요? ^^;;;

익명 사용자의 이미지

아시다시피 듀얼 CPU에 듀얼 CPU지원 OS깔렸다고 멀쩡한 프로그램이 갑자기 듀얼로 돌아가는것은 절대 아닙니다. 아무런 차이 없습니다.

프로그램 10개 돌릴떼 5개, 5개씩 나누어 돌리는것이 아닙니다. 프로그램 하나가 아주 특별하게 듀얼에 맞게 컴파일 되어야 하는데 제가 내공이 부족하여 아직은 그런것은 포트란 밖에 못봤습니다.

듀얼에 맞게 코딩한다... 이런것은 하드웨어 레벨에서 알아서 작업을 나눠주는 방식이어야하지 개발자에게 첨단기술이니 배워...라고 하면 안된다고 생각합니다.

옛날에 세가 새턴이라고 듀얼 CPU달린 게임기가 있었죠. 버파2를 익식하면서 당시 제가 존경하는 PD분께서 우리는 이 기계의 성능을 어아직 10%밖에 쓰지 못했다...라고 했다가 나중에 엄청 비난을 받았던 걸로 아는데, 그때 느낀점은 좋은 기계는 대충해도 좋은 성능이 나오고 바쁜기계는 열심히 해도 그런 성능이 나오지 못한다는 것입니다.

최적의 상태를 사람이 맞추면 안됩니다. 컴파일러가 만들어 주는게 맞습니다. 왜냐하면 파이프라인이나 지연분기, 분기 예측까지 같은 코드라도 반도체 레벨에서 설계가 다르면 성능도 달라집니다. AMD와 INTEL이 다르고 P3와 P4가 다릅니다.

요즘 386급이상에서 사용하는 컴파일러가 만들어 내는 수준의 명령어는 학교 실습 시간에 쓰는 8088셈과는 수준이 다릅니다. x86이 아닌것 같은 듣도 보도 못한 황당한 명령어 조합을 생성해 냅니다. (디버그 모드와 릴리즈모드에서 생성되는 어셈이 완전히 다릅니다) 바로 CPU에 최적화된 코드입니다.

최근의 컴퓨터 기술은 작은데서 승부를 거는게 아니라 하드웨어 전체 성능을 올림으로써 소프트웨어에 들어가는 노력을 줄이는 쪽입니다.
기본 하드웨어도 최대한 쉽게 만들고, 소프트웨어도 인프터리터급 과부하 언어를 쓰더라도 버그가 적게 생기고 생산성이 높이는 방향으로 나아가고 있습니다.

사실 저도 이런 것에 대단히 관심히 많고, 어셈 겁나 좋아합니다만 남의 나라는 잘 모르겠습니만 한국에서는 그런 일을 할일은 별로 없죠. 다만 성능이 떨어지는 임베디드 계열에서 작업을 하게 된다면 활용할수는 있습니다.

관심이 있으시다면 ARM이나 인텔의 64비트 아이태니엄을 공부해 보시기를 권합니다. ARM은 아직도 개발자가 개입할 여지가 상당히 남아있는 프로세서입니다. 인텔 아이태니엄은 마케팅에서 아직도 일부 죽을 쑤고 있기는 합니다만 그래도 설계는 정말 잘된 프로세서입니다. 노력합니다!

ps> 1등이다.

익명 사용자의 이미지

겨우 28.6Mhz 짜리 히타치 SH2 씨피유 2개 쓴 거 갖고 성능을 아직 10%밖에 못썼다는 쌩구라를 치다니...정말 엄청 비난을 받을 만 하네요. 하하하. 임베디드 하는 분이라면 잘 알겠지만 그 씨피유는 DSP랑 메모리 컨트롤러 같은 걸 내장한 일종의 SoC형 리스크 프로세서인데, 씨피유 자체 성능만 놓고 보면 i386이랑 성능을 다툴 정도예요. 한마디로 DSP 빼면 꽝이란 얘기죠.

김용욱_의 이미지

원래 게임 업체의 마케팅쪽에는 과장된 부분들이 있기 마련이지요. 쉔무2까지의 분양을 SS에 개발하고 있었던걸 보면 아예 새턴쪽에 상당히 신경을 쓸려고 했던것은 사실이겠지요. 버파3와 쉔무가 모두 DC로 나와서 욕을 덤탱이로 먹은 것이지요. 아마도 새턴쪽에 내었다면 욕을 먹지는 않았을거에요. :-)
--
Lit.
동명이인이신 분이 계셔서 닉으로 합니다.

L.I.T

익명 사용자의 이미지

Anonymous wrote...
> 아시다시피 듀얼 CPU에 듀얼 CPU지원 OS깔렸다고 멀쩡한 프로그램이 갑자기 듀얼로 돌아가는것은 절대 아닙니다. 아무런 차이 없습니다.
>
> 프로그램 10개 돌릴떼 5개, 5개씩 나누어 돌리는것이 아닙니다. 프로그램 하나가 아주 특별하게 듀얼에 맞게 컴파일 되어야 하는데 제가 내공이 부족하여 아직은 그런것은 포트란 밖에 못봤습니다.
>
> 듀얼에 맞게 코딩한다... 이런것은 하드웨어 레벨에서 알아서 작업을 나눠주는 방식이어야하지 개발자에게 첨단기술이니 배워...라고 하면 안된다고 생각합니다.

듀얼에 맞게 코딩하는 걸 어려운 말로 쓰레드라고 합니다. -_-;;

>
> 옛날에 세가 새턴이라고 듀얼 CPU달린 게임기가 있었죠. 버파2를 익식하면서 당시 제가 존경하는 PD분께서 우리는 이 기계의 성능을 어아직 10%밖에 쓰지 못했다...라고 했다가 나중에 엄청 비난을 받았던 걸로 아는데, 그때 느낀점은 좋은 기계는 대충해도 좋은 성능이 나오고 바쁜기계는 열심히 해도 그런 성능이 나오지 못한다는 것입니다.
>

성능의 10%밖에 못썼으면 실제 성능은 펜티엄 4 3Ghz보다 더 빠르겠네요?
그 PD(방송국 PD인가?) 좀 허풍이 심하신 분 같습니다.

> 최적의 상태를 사람이 맞추면 안됩니다. 컴파일러가 만들어 주는게 맞습니다. 왜냐하면 파이프라인이나 지연분기, 분기 예측까지 같은 코드라도 반도체 레벨에서 설계가 다르면 성능도 달라집니다. AMD와 INTEL이 다르고 P3와 P4가 다릅니다.
>
> 요즘 386급이상에서 사용하는 컴파일러가 만들어 내는 수준의 명령어는 학교 실습 시간에 쓰는 8088셈과는 수준이 다릅니다. x86이 아닌것 같은 듣도 보도 못한 황당한 명령어 조합을 생성해 냅니다. (디버그 모드와 릴리즈모드에서 생성되는 어셈이 완전히 다릅니다) 바로 CPU에 최적화된 코드입니다.
>

듣도 보도 못한 황당한 명령어 조합의 예를 한가지만 들어주세요. x86
어셈블리를 10년 넘게 해왔지만 그런 얘기는 첨 듣네요.

익명 사용자의 이미지

혹시 조선일보 기자세요?
자기 주장은 없고 타인의 의견에 태클거는 얘기만 하는군요.
반론을 할때는 당신의 능력을 보여 줘 보세요. 짠밥으로만
남을 누르려 하지 말고요.

익명 사용자의 이미지

> 듀얼에 맞게 코딩하는 걸 어려운 말로 쓰레드라고 합니다. -_-;;

그렇다면 하나의 CPU에서 멀티 쓰레드하는 것은 뭐라고 하나요?

>듣도 보도 못한 황당한 명령어 조합의 예를 한가지만 들어주세요. x86
>어셈블리를 10년 넘게 해왔지만 그런 얘기는 첨 듣네요.

APPLE2+(85년)이래 어셈블리를 20년 가까이 만졌지만
어셈 10년 했다고 뻐기는 사람은 처음보네요.

익명 사용자의 이미지

한가지 빼먹은 게 있네요. ^^

Anonymous wrote...
> > 듀얼에 맞게 코딩하는 걸 어려운 말로 쓰레드라고 합니다. -_-;;
>
> 그렇다면 하나의 CPU에서 멀티 쓰레드하는 것은 뭐라고 하나요?

하나의 CPU에서 멀티 쓰레드하는 것도 쓰레드라고 합니다. 참고로
컴퓨터안에 CPU가 들어있는 기계를 컴퓨터라고 합니다. ^^

익명 사용자의 이미지

허허...겁먹지 마세요. 제가 뭐 대단한 얘길 한 것도 아닌데 같은
IP로 두 사람이 쓴 것처럼 위장까지 하면서 대응을 하십니까.

x86 어셈블리에 말씀하신 것처럼 황당한 명령어 조합이 한개라도
있으면 제가 사과를 하죠. 하지만 그런 황당한 조합이 없으면
님이 사과를 하셔야 할거에요. 이렇게 하면 합리적이지 않을까요?

익명 사용자의 이미지

할말이 있으면 자기 의견을 말하고 남의 글의 일부러
옮겨서 태클거는 행동은 하지마세요.

당신은 회사에서 태클거는 사람한테 감사하다던가 미안하다던가
하는 생각이 들던가요?

자칭 내공 십년이 부끄럽지 않습니까?

익명 사용자의 이미지

세가세턴은 듀얼CPU와 여러개의 범용DSP칩이 달린 기계인걸로 압니다만, 성능이 떨어졌다기보다는 (3D 성능이 플레이스테이션에 비해 떨어진건 사실입니다만), 제 생각엔 마켓팅 못했고 .. 그리고, 세가새턴의 개발환경이 플레이스테이션보다 않좋았다는게 더 큰 원인이 아닐까요.

플레이스테이션의 경우는 쓸만한 OS와 런타임라이브러리와 매뉴얼이 있다고 들었는데요, 세가새턴의 경우는 그런 툴킷의 이야기를 들어본적이 없거든요. - 나중에 말기직전에 나온 '그란디아' 같은걸 보면, 새턴의 3D가 그렇게 부족한건 아닌데 .. 역시 저정도로 뽑아낼 수 있다는건 개발사의 저력이었겠죠.

익명 사용자의 이미지

듀얼 CPU를 개발자가 직접 최적화를 시킨다는 것이
얼마나 무모한가에 관한 예로 새턴이라는 긱계를 든 것입니다.
말씀대로 듀얼 CPU의 성능을 활용할 수 있는 툴은
새턴이 없어질때까지 발표된 것이 없는 것으로 알고 있습니다.
결론적으로 듀얼 CPU를 쓸려면 개발자가 신경쓰지 않아도
알아서 처리해줄 수 있는 수준의 시스템이 아니고서야
잘못하면 오히려 약이 독이 될 수 있다는 것을 말씀드린겁니다.

ps>
PS와 SS의 마케팅 얘기는 토론의 주제를 벗어나므로 빼겠습니다.

익명 사용자의 이미지

파이프라인 : 하나의 명령을 처리를 여러 스텝으로 나누고, 여러 명령어를 각 스텝에 분리해서 실행합니다. 스텝이 잘게 나누어져 있으면 CPU의 전체 속도 올리기도 좋습니다. (예를들어 세탁이 끝난 후 탈수기를 돌릴때, 다른 세탁물을 세탁기에 넣고 돌리면 같은 시간에 더 많은 양의 일을 할 수 있죠)

스퍼스칼라 : 파이프라인을 동시에 여러개를 실행시키는 겁니다. (예를 들면 세탁기와 탈수기를 2대씩 사면 이론상 2배의 능률을 올릴수 있겠죠)

OOO(OutOfOrder) : 특정 레지스터나 메모리에 쓰기 명령이 끝나기 전에는 그와 상관있는 레지스터나 메모리를 읽어들일 수 없도록 하는 안전을 확보하는 기술입니다. 아무리 효율적인 코드가 생성되어도 실행중에 OOO걸리면 말짱 꽝이죠. (얼음을 넣기전에 팥과 과일을 넣는다면 제대로된 팥빙수가 될 수 없겠죠)

VLIW : 스퍼스칼라가 실시간으로 CPU에서 명령어를 조합하는 기술인데 반해 VLIW는 미리 컴파일러에서 명령어 묶음을 생성해 내는 기술입니다. CPU가 명령어 골라내는 뺑이를 치지 않고 자료처리에만 집중할 수 있도록 하는 기술입니다. 점점 발열로 고생하는 CPU에 회로가 한뭉치 빠지면 발열량도 원천적으로 줄어들겠죠. (중국집에서 면은 필요한 만큼 뽑아도 짜장 양념은 미리 뽑아두는 것과 같은 원리죠)

예측분기 : 분기명령을 만나면 파이프라인이 비어버립니다. 이런 일을 막기 위해 CPU는 미리 코드를 읽어들입니다. 그런데 엉뚱한쪽의 코드를 읽어들이면 파이프라인을 지우고 처음부터 다시 읽어 들여야 하죠. 엄청난 시간 손실이 발생합니다. 펜4같이 파이프라인이 20단 정도되는 CPU는 죽음입니다. 팬4가 팬3만 못하다는 얘기가 여기서 나옵니다. (나폴레옹이 부하들에게 이렇게 말했습니다. "이 산이 아닌게벼")

지연분기 : x86은 아니고 SPARC나 MIPS에서 쓰는 기술입니다. 어셈블리 수준에서 분기 명령어와 바로 앞의 명령어의 순서가 바뀝니다. 파이프라인을 효율적으로 쓰기 위한 것입니다. 대신 이런 어셈 코드를 읽거나 작성하려면 정말 머리깨지죠.

RISC : x86은 명령어가 많아서 골라쓴 ㄴ맛이 있는데 반해 RISC계열은 명령을 조합해 써야 합니다. 개발자가 볼때 직관적이 못하고 황당한 명령어 여럿 있죠. 같은 코드가 x86이 MOV AX, BX리면 sparc은 ORR r1, r2, r2라는 OR연산을 씁니다. SPARC, MIPS같은 경우에는 MOV명령이 아예 없죠.

플래그 : RISC에서는 플래그 연산을 선택적으로 실행합니다. x86에서는 SUB명령을 하면 자동으로 모든 플래그가 설정되지만, sparc는 sub명령이 플래그 설정과 비설정으로 2개가 준비되어 있습니다. MIPS정도되면 아예 플래그 레지스터가 없고 범용 레지스터를 플래그 레지스터로 씁니다.

기타등등 이유는 수도없이 많지만 별로 아는게 없어서 이만 줄입니다.

익명 사용자의 이미지

> 스퍼스칼라 : 파이프라인을 동시에 여러개를 실행시키는 겁니다. (예를 들면 세탁기와 탈수기를 2대씩 사면 이론상 2배의 능률을 올릴수 있겠죠)

2배가 아니라 4배가 아닙니까?
세탁기 이론인가 뭔가가 있었던걸로 --;;
아 세탁기를 2대를 사야 4배인감?

익명 사용자의 이미지

와...머리속에 쏙쏙 들어오는 설명 감사합니다^^;

익명 사용자의 이미지

절대 동의.

파이프라이닝만 배워보세요, 과연 사람이 직접 어셈블리를 이용해서 프로그램 최적화를 할 수 있을런지...

공부할때 보는 파이프라이닝은 정말 간단한 모델이죠, 물리의 이상기체와 같은...

dawnsea의 이미지

뭐 대개. Z80 -> 8051 -> 80196 으로 이어지는 마이컴을 학습한 후에... 뭐 요즘은 그마저도 필요없다고 해야할까요..

리눅스 커널소스 보면 더 꼴통만 아파오고 하드웨어에 대한 개념이해는 워낙 wrapper 로 범용화 추상화 되어 있어서 하드웨어 자체의 이해와는 좀 거리가 있을지도 모르겠네요..

셋탑박스 하다가 다 정리하고 이제는 만인의 SoC 로 자리잡은 스트롱암을 추천하지요.. 워낙 명령어 셋도 심플하고 스타트업 어셈만 베껴다가 거기까지만 성공하면 걍 포인터로다가 아주 심플하게 진행 될 수 있으니깐 하드웨어를 이해하시는데 도움이 될 것 같습니다. 온 국민의(?) 칩인 만큼 자료도 풍부하고 도움 주실 분도 많고 리눅스 커널 소스에 울 나라 분들의 주석도 있구 이리저리 공부하시기 편할 것임다~

커널 모듈 이상의 레벨이 아닌 어플리케이션 레벨에서 SMP를 어떻게 고려해야 하는지는 잘 모르겠네요 ^^;

관계없는 말입니다만.. 리눅스 커널 2.4 부터 보믄 smp 관련 코드가 너무 너저분히 많아서 소형 임베디드에 포팅할라고 보자면 (1 CPU) 오히려 사소한 오버헤드가 발생하지 않을까.. #ifdef 에서 많이 제거되긴 합니다만.. 그래도 각종 락에 메모리 배리어같은게 몇 클럭이라도 잡아먹을 것 같은데요.. 여하간 이런 범용 OS 들은 아무래도 범용성으로 인해서 simple 하게 만드는데에는 더 많은 삽질이 필요할 것 같습니다.

익명 사용자의 이미지

상당히 난감한 말씀이시네요.
제목은 하드웨어 이해하기 이고, 내용을 보면, 멀티프로세서(사실 2개 CPU는 멀티프로세서라고도 부르지 않습니다.적어도 4개 CPU는 되어야......) 시스템의 스케쥴링쪽을 궁금해 하시는것 같고, .......
현대의 프로그래머가 CPU 2개짜리를 효율적으로 제어할 방법은 저수준 코딩에 의존하는 것은 아니라고 보여집니다. 보통은(대부분은) 운영체제(OS)의 보탬을 받을 수 밖에는 없습니다. Win32운영체제의 경우 dual cpu인 경우에는 하나는 운영체제가 다른 하나는 사용자 응용을 위해 스케쥴링해주는 경우가 있습니다. 이때 시스템호출(하드웨어 자원요청)을 하는경우 운영체제 쓰레드와 사용자 쓰레드(그외 내부처리 이를테면 i++; 등)가 동시에 수행될 수 있겠지요.
물론 이것도 운영체제가 지원하는 것이지요.
즉, 사용자가 이 코드는 이 CPU에서 저 코드는 저 CPU에서 이렇게 지정할 수 없다는 것이지요.
이 정도까지 프로그래머가 제어하려면 말 그대로 운영체제와 같은 정도 수준의 프로그램을 작성해야 하는 어려움이 있습니다.
1) 운영체제 위에서 작업하겠다.
2) 운영체제의 보탬없이 작업하겠다.(운영체제, 또는 비슷한것조차 만들겠다)
1)과 2)는 판이하게 틀립니다.
1) 이상에서 작업하는것이 거의 대부분이라고 여겨지며, 2)의 경우도 아주 간소한 하드웨어를 제어하는 시스템에서나 해봄직하다고 여겨집니다. 일반목적의 시스템을 2)수준에서 개발한다는것은 방법론에서도 어렵고, 개발자체가 난해합니다. 2)수준의 개발이라면 비교적 단순한 시스템이 될것이고, 범용시스템은 될 수 없을 것으로 여겨집니다.
2) 수준에서 개발해서 범용시스템을 만들만한 기술력을 갖추는 것은 아주 어려운 일이지요.
그런 회사가 있기는 하지만요. M$, IBM등.

1)이상에서도 엇비슷한 접근을 해봄직할 수 있습니다만, 이를테면 Linux를 이용한 라우터개발, 파이어월개발등을 들 수 있겠지요. 이것또한 기존 리눅스가 제공하는 대부분의 핵심기능에 약소한(?) 하드웨어 의존부분의 코딩을 추가해서 제작이 되어지고 있는 현실입니다.
즉, 주 프로세서 (CPU)의 제어등 기본은 전부 기존 운영체제인 리눅스에게 맡기고, 디바이스 드라이버 수준의 프로그램을 개발하게 되는 것이지요. 물론 디바이스 드라이버도 운영체제의 일부이긴 합니다.

----------------
두서없이 글이 길어져서 한가지 명료한 접근을 말씀드리겠습니다.
----------------
리눅스를 좋아하신다면?
하드웨어 기본을 익히고자 하신다면?
제가 권장하는 서적은
"리눅스 디바이스드라이버" 입니다. 현시점에도 한글판과 영문판이 있을 것입니다.
이책에서는 리눅스의 디바이스 드라이버를 제작하는 관점과 커널 디바이스드라이버의 원리, 글구, 아파치 등 상위 응용에서도 채택한 플러그인 비슷한 모듈에 의한 디바이스 관리체계등을 배울 수 있습니다.
또한, 논리장치(물리장치아닌..)를 생성하고, 이를 통해 통신하는 예제가 있는데, 이 예제를 100% 이해하신다면 다른 하드웨어도 비슷한 범주로 이해하실 수 있을것이라고 여겨집니다.

유호승의 이미지

어떻게 제작하고 제작하는데 필요한 것은 무엇인가 에서부터 시작하신다면 출발점은 제대로라고 생각합니다.
그 뒤로 임베디드 소프트웨어 엔지니어 입장에서냐 하드웨어 엔지니어 입장에서냐에 따라 중점이 바뀌겠지만요...하긴 요새는 슬슬 두 영역간의 벽이 얇아지는 듯 합니다.

8051 이든 AVR 이든 DSP 든 결국 도구라는 점을 항상 잊지 마시고 데이터 시트에서 자신이 필요한 정보를 뽑으실 수 있으시다면 기본 조건을 갖추신 것입니다.

....그외에도 많은 것들이 필요하지만 가장 중요한 것은 시스템에 대한 이해도라고 생각합니다.
모터를 제어한다면(지금 제가 하는 일입니다.^^;;) 모터 제어의 수식을 완벽하게 알 필요는 없지만 대략적으로는 알아야하고 제어기를 설계하기 위한 자동제어 지식은 있어야합니다. 공부할 필요가 있을 때 공부를 시작할 수 있는 수준(어느 분야의 어느 부분을 봐야하는지 감잡는 정도)은 되셔야 한다는 것입니다.
마이크로 컨트롤러로 제어하니 디지털 제어와 관련된 쪽이 필수지요. 특히 시스템을 수식으로 만들고 그 수식을 프로그램 코드로 변환해야하니 그 부분을 잘 알아야 하지요. 이건 어느 분야에서 임베디드 소프트웨어를 제작하시든 공통입니다...아닌 분야가 있다면 온-오프 제어 정도일까요...돈이 될지 모르지만요...돈 되면 알려주십시요...;;

임베디드 소프트웨어를 만든다는 입장에서 필요한 것은 이정도이고...아예 하드웨어에서부터 시스템을 전부

설계하시려고 하신다면...PCB 보드를 설계한다..라는 부분을 해결하셔야할 것입니다.
회로 설계 제작과 관련된 OR-CAD, PADS나 PCAD 같은 소프트웨어와 기타 시스템과 관련된 MATLAB, PSIM, FEM, ANSYS 같은시뮬레이션 소프트웨어 등을 사용하실 수 있어야합니다.
그리고 만약 FPGA 같은 놈을 사용하시게 되면 역시 그와 관련된 응용 프로그램을 사용하실 수 있어야하지요.
이런 기본적인 소프트웨어를 사용하는데 불편함이 있다면 좀 힘듭니다. 안되는 것은 아니고 힘듭니다.

기타 회로이론이니 전자회로...엄청 깊게 파실 필요는 없지만 윤덕용 교수님의 홈피에 올라와 있는 테크니컬 노트의 정보 정도는 공부하시는 것이 좋습니다.

기타 다른 부분은 시중에 나와있는 좋은 책들을 초급과 중급 순으로 몇권 보시면 될 것 같군요.
요새 좋은 책들이 많습니다. 제가 공부할 때 나왔다면 정말 큰 도움이 되었을텐데 라는 생각을 하게 되는 책을 요새 종종 봅니다...아마 제 선배님들도 저와 마찬가지셨겠죠.^^;

납땜이나 측정 장비 사용 등은 부차적입니다. 일하면서 조금만 주의를 기울인다면 아주 잘 할 수는 없어도 불편함이 없을 정도의 수준이 되는 것은 그다지 어렵지 않은 단순한 스킬입니다.
어려운 것은 그런 스킬을 사용하여 시스템을 제작하는 일련의 체계적인 순서와 제작 과정에서 나타나는 문제를 해결하기 위한 시스템에 대한 이해능력입니다. 공부와 실험을 바탕으로 한 경험이 필요한 영역입니다.
......하긴 가장 중요한 것은 어느 분야에서나 마찬가지로 '근성'이지만요...'더 파이팅' 일까요...^^;

리눅스 시스템 상에서 RS232 통신하는 법을 찾으러 왔다가 답글답니다.
아무래도 서점에 한번 들려봐야겠네요.

인터넷은 '무료'로 '아주 많은' 자료를 얻을 수 있지만 시간과 '운'이 많이 필요한 듯 합니다. 그리고 정보가 조각나 있어서 전체적으로 통합해야하거나 여러 자료들을 모아서 원하는 형태로 바꾸어야하는 번거로움이 있어 기본적면서 자주 다시 보게되는 내용들은 책으로 소장하는 편입니다...물론 하드웨어 제작사의 홈페이지에 자료가 올라와 있는 경우에는 출력하지만요..

아! 마이크로 컨트롤러 공부 시작하실 때 개인적으로 추천하는 놈은 8051 보다는 AVR 입니다.
기능이 막강하여 쓰기 편하고 그만큼 좀 복잡합니다. 하지만 '아주' 복잡하지는 않습니다. AVR로 공부하시고나서 8051을 공부하시기 바랍니다. 보통 추천하는 것과는 좀 반대지만 AVR에서 지원하는 기능을 8051로 어떻게 구현해볼까 하는 쪽으로 공부하신다면 도움이 되실 겁니다. 그리고 AVR을 잘 하시게 되면 DSP나 기타 다른 마이크로 컨트롤러도 좀 더 쉽게 접근하실 수 있습니다. 8051만 보다가 AVR을 처음 접했을 때 상당히 애먹었던 기억이 납니다. AVR을 하면서 DSP를 보았을 때는 그나마 덜 충격적이었고요.

...그리고 8051이 변태(!)라는 의견에 동의합니다.
8051은 하드웨어가 왠지 억지스러운 구석 ..나름 근성있었어..정도라고 생각하는데...저만 그런가요? ^^;

anfl의 이미지

단지 software를 잘하기 위해서 h/w를 공부하는 것이라면 굳이 h/w를 직접 배우지 않아도 됩니다. 잘 정리된 컴퓨터 구조 책 한번 보고 SMP os를 공부해보시면 도움이 많이 될듯하네요.

문맥을 읽어봤을때 그렇지는 않은것 같은데 만약 h/w를 본격적으로 하실 생각이라면 software base에서 접근할때는 HDL부터 시작하는게 보다 쉽게 배우고 나중에 쓸모도 많을것 같네요. 물론 나중에는 결국 다 알아야겠지만 말입니다.


익명사용자의 이미지

5년전 글이네요. 저 위에 이직하신다는 분은 무사히 성공하셨을지...