임베디드 프로그래밍이 전기 공학 또는 소프트웨어 개발에 더 가깝습니까? [닫은]

마이크로 컨트롤러에 임베디드 C를 작성하는 작업에 접근하고 있습니다. 처음에는 소프트웨어 스택에서 프로그래밍을 포함시키는 것이 너무 낮다고 생각했지만 잘못 생각하고 있습니다.

일반적으로 나는 전기 엔지니어라고 생각하지 않기 때문에 임베디드 코드를 작성할 기회를 잃었을 것입니다. 이것은 나쁜 가정입니까? 임베디드 시스템을위한 흥미롭고 유용한 소프트웨어를 작성할 수 있습니까? 아니면 소프트웨어 스택에서 너무 낮게 떨어졌을 때 스스로 쫓아 낼 수 있습니까?

나는 컴퓨터 과학을 위해 학교에 갔으며 컴파일러 작성, 동시 알고리즘에 대한 생각, 데이터 구조 설계 및 프레임 워크 개발을 정말 좋아했습니다. 그러나 저는 현재 웹 개발자로 고용되어 있으며 방금 설명한 흥미로운 내용을 소리 지르지 않습니다. (현재이 확인란은 왼쪽에 4 픽셀이어야하고이 날짜의 형식이 잘못되었습니다.)와 같은 문제를 처리합니다.

모두의 의견에 감사드립니다. 나는 스스로 결정을 내려야한다는 것을 안다. 임베디드 프로그래머라는 것이 무엇을 의미하는지, 그리고 내가 흥미 롭다고 생각하는 것에 맞는지 설명하고 싶다.

임베디드 시스템을 잘 사용하려면 EE처럼 생각해야합니다. 이는 일반적으로 다양한 주변 장치 (UART, SPI, I2C 또는 USB와 같은 직렬 버스), 8 비트 및 16 비트 타이머, 클록 생성기, ADC 및 DAC와 인터페이스하기위한 코드를 작성하는 경우입니다. 마이크로 컨트롤러를위한 "데이터 시트"는 종종 모든 레지스터의 모든 비트를 설명 할 때 수백 페이지로 나옵니다. 오실로스코프 또는 로직 분석기로 보드를 프로브 할 수 있도록 회로도를 읽을 수 있습니다.

다른 때는 소프트웨어를 작성하는 것뿐입니다. 그러나 엄격한 제약 하에서 : 종종 공식적인 OS 나 다른 프레임 워크가없고, 단지 몇 KB의 RAM과 64 KB의 프로그램 메모리가있을 수 있습니다. (이러한 제한은 더 작은 8 비트 또는 16 비트 마이크로에서 프로그래밍한다고 가정합니다. 32 비트 프로세서에서 임베디드 Linux로 작업하는 경우 동일한 메모리 제한은 없지만 여전히 사용자 정의를 처리해야합니다. Linux 배포판에서 드라이버를 제공하지 않는 주변 장치 하드웨어)

나는 EE와 CS에 배경이 있으므로 동전의 양면을 즐길 수 있습니다. 또한 웹 프로그래밍 (대부분 PHP)과 데스크톱 앱 (C # 및 Delphi)도 수행하지만 임베디드 프로젝트 작업을 항상 즐겼습니다.

@tcrosley의 대답은 훌륭합니다. 전기 기술자 일 필요는 없지만 기본 사항을 아는 것이 도움이됩니다.

"소프트웨어 스택에서 너무 낮다"는 것을 두려워 할 필요는 없다고 생각합니다. 임베디드 엔지니어로서 매우 흥미로운 많은 문제를 해결해야했습니다. 당신은 당신이 즐겼던 일의 목록을 언급합니다 :

• 동시 알고리즘-비동기 하드웨어 레벨 인터럽트를 처리하는 것은 OS 스레드 모델을 사용하는 것만 큼 많은 흥미로운 과제를 안고 있습니다.

• 데이터 구조 설계-확인 컴팩트하고 효율적인 액세스를위한 디자인.

• 프레임 워크 개발-확인. 베어 본 시스템에서는 미니 OS를 설계 할 수 있습니다.

• 컴파일러 작성 – 어쩌면 그렇지는 않지만 컴파일러의 어셈블리 생성 단계와 유사한 저수준 코드 최적화를 수행 할 수 있습니다.

UI를 코딩하는 것보다 임베디드 시스템에서 일하는 것을 골랐습니다. 머신이 프로그래밍 된 방식으로 움직이기 시작하는 것을 처음 본 것을 잊지 못할 것입니다. 픽셀을 푸는 것보다 훨씬 만족 스럽습니다.

임베디드 프로그래머로서 저의 임무는 맞춤형 하드웨어가 작동하도록하는 것입니다. 일반적으로 개발 보드 또는 이전 버전의 하드웨어에서 많은 소프트웨어를 개발했습니다. 새 보드가 들어 오면 내 임무는 소프트웨어를 보드에 놓고 모든 것이 제대로 작동하는지 보여주는 것입니다.

거의 항상 어떤 종류의 문제가 있기 때문에 디버깅 기술이 필수적입니다. 외부 주변 장치가 작동하지 않으면 칩 불량, 칩 연결 불량, 버그 코드 또는 온칩 주변 장치의 잘못된 사용입니까? 말할 수있는 유일한 방법은 광범위한 디버깅입니다. 이는 오실로스코프, 네트워크 분석기, 로직 분석기 및 대상 디버거에 익숙하다는 것을 의미합니다. 디버깅 프로세스는 거의 과학적입니다. 나는 가설을 개발하고, 내 가설에 대한 증거를 제공 할 실험을 설계하고, 테스트합니다.

인턴 또는 새로운 임베디드 엔지니어를 평가할 때이 기술이 가장 중요합니다. 모든 소프트웨어에는 문제가 있지만 일단 실제 세계와의 인터페이스를 시작하면 이러한 문제가 기하 급수적으로 증가합니다. 내 직업의 본질은 개념과 현실 사이의 긴 일련의 문제를 해결하는 것입니다.

내 경험상 "전자 엔지니어"모자가 아닌 "소프트웨어 개발자"모자를 사용하여 임베디드 시스템 소프트웨어 개발에 더 나은 결과를 얻습니다. (TDD 및 CI와 같은 연습은 하드웨어 엔지니어링에서 덜 일반적입니다)

반면에 임베디드 시스템을 개발 한 경험이 더 나은 시스템이라고 생각합니다. 보다 다재다능한 소프트웨어 개발자.

나는 약 8 년 전에 비슷한 상황에 처해있었습니다. 당시에는 응용 프로그램 및 서버 환경에서 7 년 동안 소프트웨어를 개발했습니다. ZX 스펙트럼에서 10 대 시절 Z80 어셈블러에서 글을 쓰기 전에 하드웨어에 대한 저수준을 다루는 저의 유일한 경험입니다.

확실히 도전이었습니다. 나는 어셈블러에서 칩셋을 다루는 것이 매우 즐겁다는 것을 알았고 나는 확실히 하드웨어에 대해 많은 것을 배웠다. 저의 역할 중 상당 부분은 소프트웨어를 사용하여 하드웨어를 테스트하는 것이 었습니다. 따라서 프로그래밍에 대처하고 소프트웨어 버그가 실제로 하드웨어 버그임을 인식하는 법을 배웁니다. 실제로 소프트웨어 및 하드웨어 담당자가 버그가 하드웨어인지 소프트웨어인지 식별하려면 상당한 시간이 걸릴 수 있습니다.

전달하지 못한 한 가지 측면은 장치 드라이버 작업이었습니다. 나는 이것을 정말로 이해하지 못했습니다. 이것은 저 자신과 회사 이사가 왜 그런지 이해하지 못한 것입니다. 방금 받아 들여진 사실이되었습니다.

안구 경과 납땜 이온에 익숙해지는 것이 필수적입니다. 하드웨어 담당자가 숫자 26을 말할 때 항상 0x26이 유용하다는 것을 기억하십시오. 하드웨어 엔지니어가 소프트웨어를 다루는 것이 매우 도움이된다는 것을 알고 있지만 소프트웨어와 관련이없는 하드웨어 프로젝트를 케이블이라고합니다.

나는 4 년 동안 그 역할을했으며 정말 환상적인 기회를 위해 밀려 났기 때문에 떠났다.

모든 것과 마찬가지로 균형 잡힌 접근 방식이 필요합니다. 나는 일상 업무에서 임베디드 시스템으로 작업하는 것을 좋아합니다. 그들은 전기 공학을 더 잘합니다. 물리적 컴퓨팅과 자동화는 매우 흥미 롭습니다. 반면에, 클라우드 컴퓨팅으로 웹 앱을 구축하고 땜질하는 것은 훌륭합니다.

올바르게 수행하면 소프트웨어 쪽에서 더 똑똑하고 더 나은 방법을 찾을 것입니다. 하드웨어 측면에서 리소스를 염두에두고 효율적으로 사용할 수 있습니다.

저는 전기 엔지니어가 아니지만 소량의 임베디드 소프트웨어 개발을 수행했습니다. 내가 찾은 가장 큰 문제는 수학에 훨씬 더 기본적인 배경 지식이 있으므로 복잡한 일련의 고급 수학 알고리즘을 많은 도움없이 코드로 쉽게 분해하는 방법을 모른다는 것입니다.

신호로 놀고, 입력에서 값을 읽고, 데이터를 출력에 제출하고, 모든 종류의 물건에 대해 필요한 모든 것들에 대해, 나는 매일 매일하는 일과 개념적으로 조금 다른 것을 발견했습니다. 구식 소프트웨어 개발자. 실제로 소프트웨어를 작성하는 것입니다. 하드웨어를 직접 엉망으로 만드는 지식이 없기 때문에 문제가 발생하는 실제 소프트웨어를 넘어서야 할 때입니다. 일반적으로 코드를 디버깅하거나 테스트하려고 할 때 발생합니다. 정말 훌륭한 툴 체인을 가지고 있다면 디버깅 및 시뮬레이션 환경을 통합하여 대부분의 어려움을 겪을 수 있지만, 모두 도움이되는 경우에도 기본으로 돌아가서 코드를 테스트해야 할 때가 있습니다. 어떤 종류의 분석기와 현실은 대부분의 임베디드 플랫폼이

이러한 관점에서 볼 때, 작업이 간단하고 실제 하드웨어 특정 요구 사항이 최소 인 경우 전기 엔지니어가 임베디드 프로그래밍에 필수적이라고 생각하지 않습니다. 그 외에도, EE가되는 것은 임베디드 환경에서 작업 할 때, 특히 문제가있는 곳을 알아 내기 위해 실제 과학이 필요한 경우에 훨씬 더 쉬운 삶을 만들어 줄 것이라고 생각합니다.

비즈니스 수준의 임베디드 프로그래밍을 수행하지는 않았지만 학사 학위는 대부분 임베디드 시스템에 관한 것으로서 몇 년 간의 실제 경험이 있습니다. 우리는 Atmel AVR에서 C를 사용하고 VHDL을 사용하여 Texas Instruments 칩을 만졌으며 ARM에 대한 이론적 인 내용을 다루었습니다.

우리가 가진 것에서 그것은 대략 50-60 %의 프로그래밍 (C), 20 %의 계획 / 디자인 (UML)이었고 나머지는 물리적 전자 장치 (납땜, 측정, 배선, 케이블 제작 등)였습니다. 또한 매우 흥미롭고 재미 있으며, 임베디드 시스템 분야에서도 경력을 쌓기를 바랍니다. 아아, 임베디드 시스템 시장이 매우 작기 때문에 오래된 Java EE에 의존해야했습니다.

그러나 나는 산만하다. 위의 비율은 교사가 자체 기업을 보유하고 있으며 가능한 한 현실적으로 만들려고 노력할 것이기 때문에 실제 작업과 매우 유사하다고 말합니다. 프로젝트 중간에 요구 사항이 무작위로 180도 회전했습니다.

스택도. 임베디드 프로그래밍을 알면 아시아의 실제 플랜트에서 제조 할 수있는 자체 하드웨어 제품을 직접 제작 한 후 사내 또는 회사에서 조립할 수 있습니다. 매우 흥미 롭습니다! 또한 이동 제어식 하우스 라이트, 커피 머신 타이머가 자동으로 아침 조를 준비하는 등 가정에서 도움이되는 많은 장치를 만들 수 있습니다. 정말 흥미로운 것들!