MCU 제조사의 IDE 와 EB Tresos Studio 간의 관계

안녕하세요. 이해하신 내용이 맞습니다.저도 아쉬운 부분인데 사실STM CubeIDE나 TI의 CCS 등의툴을 써보면 무료인데다 인터넷에 자료도 많고 쓰기도 편한데다가역할만 놓고보면 MCAL이랑완전 똑같아서 그런 툴들을 활용 못하는게 아쉽습니다. 근데 어쨋든 이해하신대로오토사기반으로 개발 할 때는 그런 툴을 통한 CODE generation 작업은 하지않습니다 대사 Eb tresos와 다른 bsw 툴로 code gen 작업을 하게되고 Ide 툴로는 빌드만하게 됩니다. 그리고 빌드조차도 ide에서 제공하는 툴이 아니라, 기능안전 인증 이슈 등의 이유로 별도의 유료 컴파일러를 사서 빌드하기도합니다.이 경우에는 MCU 제조사가 제공하는 IDE는 아예 사용안하는거죠 대표적인 예를들면 인피니언 aurix의 경우 인피니언에서 제공하는 aurix studio라는 ide에 stm cube ide와 비슷한 기능이 모두제공되는데.해당 ide의 코드제레이션 기능도 사용하지않고. 빌드 할 때 컴파일러도 태스킹 컴파일러라는 유료 컴파일러를 사서 사용하는게 대부분입니다.

부트로더도 업데이트를 하나요?

이 부분도 실무적으로 중요한 부분인데프로젝트마다 사정이 달라서 강의에 담지 못한 내용인데요.보통은 부트로더도 업데이트 할 수 있도록 환경을 구성하긴합니다.대표적인 방법은 부트로더를 2개로 분리해서 개발하는겁니다.하나는 부트로더를 다운로드 받기 위한 부트로더.또 다른 하나는 강의에서 다뤘던 제어sw 다운로드를 위한 부트르더.이렇게 구성하면 제어sw 다운로드 하듯이 부트로더를 리프로그래밍해서 업데이트가 가능합니다

AUTOSAR compliance

안녕하세요. 질문 주신 부분은 저 또한 일을 하면서 항상 궁금했던 부분인데요. 결론만 먼저 말씀드리면 죄송하지만 솔직히 저도 잘 모르겠습니다 ㅠㅠ실제로 일을 하다보면 모든 것을 swc 러너블로 만들어서 사용하기에는 알맞지 않은 경우가 제법 많습니다. (답변 쓰면서 떠오르는 전형적인 예시 : bsw서비스 api는 rte port를 통해서 호출하는게 규칙인데. 그냥 일반 함수처럼 곧바로 api 직접호출)그래서 실제로 오토사가 제시하는 정석적인 방법을 사용하지않고 개발하는 경우가 제법 많이 있습니다. 그러면 저도 이렇게 해도되는건가? 하는 의문을 갖게되는데 그래도 sw동작 효율을 따지면 오토사 룰을 어기는게 낫다고 판단되면 그렇게 많이 해왔습니다. 그리고 이렇게 개발했을때 oem에서 그 정도 레벨까지 따져서 묻고, 확인하는 경우는 제 경험상 없었기 때문에 별 문제는 없었습니다. 결국 고객입장에서 오토사는 최소한의 품질보증(?)을 위한 수단일뿐 오토사 그 자체가 최종목표가 아니기 때문에, 결론적으로는 제품 동작만 잘된다면 오토사 룰을 어기더라도 큰 문제는 없지않을까 싶습니다. 애초에 sw 내부를 그 정도까지 oem에서 일일이 체크하는 경우를 못봤습니다.그렇지만 전세계의 모든 케이스를 제가 다 알고있는건 아니기에 100% 문제없다고 장담드릴수는 없겠습니다..

디버거와 디버깅

안녕하세요.. 질문의 의도를 제가 정확하게 이해를 못했습니다.IDE 에서 브레이크포인트 찍거나, 변수값 확인하거나,변수값 변경하거나, SW를 MCU에 다운로드 하거나 하는 그런 기능이 디버깅 기능이고.이런 기능을 사용 하려면 결국 사용자의 PC와 MCU 간에 서로 소통을 해야되니까중간에 디버거라는 하드웨어가 필요한 것입니다.

adc

안녕하세요. 어떤 것과 헷갈리신건지 모르겠지만일반적으로 MCU 가 제공하는 기능중에 ADC 라고 하면아날로그 to 디지털의 약자로 발생된 전압(아날로그 신호)를 측정해서 측정 값으로 바꿔주는 기능을 의미합니다.혹시 말씀하신 것은 DAC가 아닌지요?

BSW 개발자의 역할

그리고 두번째 질문도질문 자체가 좀 애매한데요.부트로더, UDS 기반의 서비스 구현을 오토사 기반의 SW로 개발할 수도 있고Non Autosar SW로 개발 할 수도 있습니다.어떤게 더 유리한 방법인지를 따져서 정할 문제이고 정해져 있는 규칙은 없습니다. 이건 부트로더,진단통신 SW 뿐만 아니라 어떤 SW 이든 마찬가지인데어떤 SW를 개발하든 꼭 오토사 기반으로 개발할 필요는 없습니다.재사용성 ,개발효율 이런걸 따져서 유리한 방법을 고르면 됩니다,, 실제로 부트로더 sw만 별도로 판매하는 업체들도 있는데그 업체들도 오토사기반으로 개발된 부트로더를 판매하기도하고, 오토사 기반이 아닌 부트로더를 판매하기도 합니다.

BSW 개발자의 역할

안녕하세요. 답이 늦어서 죄송합니다.질문 주신 내용은 답변하기가 상당히 애매한데요.. 우선 첫번째 질문에 대한 답변입니다.질문 주신 내용은 R&R 에 관한 것이라 회사마다,팀마다,프로젝트마다 정하기 나름이라명확하게 구분 지어서 답을 드릴 수가 없습니다.제가 업무 할 때도 항상 R&R을 어떻게 나눌건지 항상 이슈가 되는 부분입니다.일단 오토사의 이론적인 컨셉만을 기준으로 얘기하면BSW 영역은 Configuration만 하고 별도로 개발자가 핸드 코딩을 하지 않는게 기본적인 컨셉입니다.근데 실제로 일을 해보면BSW 개발자도 별도로 SWC와 러너블을 만들어서 나름의 로직을 구현하는 경우들이 있고.또 BSW 에서 Configuration 한 내용에 따라 SWC 러너블은 아니지만 그랑 비슷하게 속이 비어져있는 Callback 함수가 code gen되는 경우가 있는데그 callback 내부에 코드 구현을 어떻게 하냐에 따라서 BSW의 동작이 달라집니다.그래서 이런 부분은 BSW 개발자가 코딩을 하기도 합니다.그리고 SWC 러너블이 실행되려면 일단 OS가 돌아간 이후부터 돌아가는데OS가 켜지기 전에 수행되는 여러가지 고장진단 로직 이런것들을 BSW 개발자가 구현하기도 합니다.. 뭐라고 정리해서 답을 드리가가 어렵네요..

120옴 저항 관련 문의

답이 늦어 죄송합니다.솔직히 말씀드리면 캔 종단저항에 대해서 제가 모든 내용을 완벽하게 파악하지 못 했습니다. 회사에서 업무하면서 통신 에러나면 종단저항 연결했는지 확인해보라고 배운 정도(?) 입니다. ㅠㅠ일단 제가 파악한 바로는 종단저항 사용 목적이 신호왜곡 방지 목적인데, 종단저항이 없다고해서 무조건 에러가 나는건 아닌거 같습니다. 그래서 강의에서도 제가 양끝단에 120옴 저항 다는궐 권장하고 있다고 표현했던겁니다. 일단 저도 완벽하게 이해는 안되지만 캔통신 장비(예를 들어 canoe) 를 사용할 때 종단 저항이 없어도 에러가 안나는 경우가 있고, 제어기 쪽에 하나만 달아도 에러가 안나는 경우가 있는거 같습니다. 캐노의 경우 장비에 따로 종단저항이 내장되어있지않기 때문에 질문1번에 대해 답을 하자면, 저항이 하나만 있는 상태가됩니다.. ( 왠지 정확한 이유는 모르겠지만 그래도 통신이 되더라구요..) 2번질문. 실차에는 이미 통신을 할 수 있게 버스에 저항을 달아놨을겁니다. 그래서 canoe에 저항 안달아도 됩니다.

B라는 제어기가 CAN 버스에 CAN 신호를 송신하고 있다면 A제어기는 B제어기의 작업이 끝날 때까지 CAN 신호를 송신 못하나요? 작업이 완료될 때까지 기다려야 하나요?

기다리는 주체가 캔컨트롤러라면 질문하신 내용이 맞습니다. 하나의 버스에 여러 메세지를 동시에 보낼 수 없으니 캔 컨트롤러가 메세지 보내려고 했는데 다른 제어기가 이미 메세지 송신 중이라면 해당 메세지 송신 완료될때까지 기다렸다가 송신을 시도합니다.

FTB(Fault type Btye) 관련 질문!

아래 답변은 AI 자동답변인데 맞는 얘기입니다.Fault type byte는 말그대로 에러를 적당한(?) 성격으로 분류해서 가독성을 제공합니다. 예를들어 배터리고전압,산소센서고전압. 이그니션고전압 이런 고장들이 있다면 "고전압고장" 이라는 분류로 묶어서 fault type byte를 정하는 식입니다. 이렇게 사용하면 FTB만 봐도 대강 어떤성격의 고장인지 분류할 수 있어 편합니다