동일한 작업을 수행하는 다른 방법이 있을 때 GPIO와 같은 일부 특정 장치용 임베디드 시스템에 장치 드라이버를 작성하는 것의 이점을 완전히 이해할 수 없다고 생각합니다.
sysfs 및 장치 트리를 통해 GPIO에 액세스할 수 있습니다.
- 새 장치 트리 오버레이를 작성하고 활성화합니다.
- /sys/class/gpio로 이동하세요.
- 필요한 핀을 내보내고 사용을 시작하세요(간단한 셸 호출을 통해 또는 c/C++ 앱 내부에서).
자신만의 드라이버를 작성해 보세요.
- 실제 기능을 코딩합니다.
- 사용자 공간의 노드(예: /dev/tty)에 드라이버를 노출합니다.
- 드라이버에 액세스하기 위한 다른 c/C++ 코드를 작성합니다(간단한 쉘 호출을 통해서도 액세스할 수 있음).
- 새로운 기능이 필요한 경우 먼저 드라이버를 변경한 다음 코드를 변경하세요. (왜?)
/dev/mem을 직접 사용하십시오.
- mman.h를 포함하고 /dev/mem 개체를 사용하여 GPIO 상태를 설정하거나 가져옵니다.
그래서,
- 1 -> 더 이상 사용되지 않으며 속도가 느려질 예정입니다. (좋아요, 빠른 프로토타이핑에 절대적으로 도움이 됩니다)
- 2 -> 1보다 어떻게 빠른가요? 첫 번째는 또 다른 GPIO 드라이버이기도 합니다. 그렇죠?
- 3 -> 가장 좋고 가장 빠른 방법이 아닌가요?
위에서 몇 가지 질문을 했지만 가장 큰 질문은 다음과 같습니다. 왜 세 번째 해결책을 바로 사용하면 안 되나요?
답변1
옵션 2의 장점은 한 곳에서 요청의 유효성을 검사할 수 있다는 것입니다. 식기세척기의 경우 물을 켜기 전에 문 센서가 문이 닫혀 있는지 확인할 수 있습니다. 물론 사람들에게 물을 틀기 전에 문 상태를 확인하라고 말할 수 있지만, 모두가 그렇게 할까요?
옵션 1과 3의 잠재적인 단점은 권한입니다. 이는 내장된 장치가 얼마나 정교한지에 따라 다르지만 서로 다른 작업을 수행하는 서로 다른 사용자 ID를 갖고 싶을 수도 있습니다. 예를 들어 홈 라우터에는 웹 UI를 수행하는 http 서버를 실행하는 서로 다른 UID와 전면 패널 LED를 작동하는 서로 다른 데몬이 있을 수 있습니다. gpio 드라이버가 세분화된 액세스 제어를 갖는 것이 가능하지만 대부분은 전부 아니면 전무 접근 방식을 사용합니다. 옵션 2를 사용하면 어떤 사용자가 어떤 시설에 세부적인 수준으로 액세스할 수 있는지 결정할 수 있습니다.
옵션 2의 단점은 더 복잡하고 일반적으로 커널에 코드가 필요하다는 것입니다.