동일한 작업을 수행하는 다른 방법이 있을 때 임베디드 시스템의 일부 특정 장치(예: 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와 웹 UI를 작동하는 서로 다른 데몬이 있을 수 있습니다. 전면 패널 LED. GPIO 드라이버는 세분화된 액세스 제어를 가질 수 있지만 대부분의 드라이버는 전부 아니면 전무 접근 방식을 취합니다. 옵션 2를 사용하면 어떤 사용자가 어떤 시설에 액세스할 수 있는지 세부적으로 결정할 수 있습니다.
옵션 2의 단점은 더 복잡하고 일반적으로 커널에 코드가 필요하다는 것입니다.