Atmel SAM-D21 시리즈 마이크로 컨트롤러에서 많은 주변 장치는 기본 CPU 클록과 비동기식 클록을 사용하며 이러한 주변 장치에 대한 액세스는 동기화 논리를 거쳐야합니다. 클럭이 CPU 시간에 비해 느린 주변 장치에서는 실제로 약간의 지연이 발생할 수 있습니다. 예를 들어, RTC가 1024Hz 클럭을 사용하도록 구성되어 있고 (디자인 의도로 보임) CPU가 48Mhz로 실행중인 경우 “현재 시간”레지스터를 읽으면 버스 로직이 200,000 개 이상의 대기 상태 (최소한)를 삽입하게됩니다. 1024Hz 클럭의 5 사이클). CPU가 읽기 요청을 발행하고, 관련이없는 다른 코드를 실행하고, 시간을 가져 오기 위해 200,000 회 이상주기를 리턴 할 수는 있지만 실제로 시간을 더 빨리 읽을 수있는 방법은없는 것 같습니다.
동기화에 대한 이해를 통해 단일 비트 동기화 회로는 대상 클럭의 2-3 사이클만큼 신호를 지연시킵니다. 멀티 비트 수량을 동기화하는 것은 조금 어렵지만 소스 클록보다 빠른 경우 대상 클록의 5 사이클 내에서 안정적인 동작을 보장하고 그렇지 않은 경우 몇 사이클 만 더 신뢰할 수있는 다양한 접근 방식이 있습니다. Atmel SAM-D21이 수행하는 작업은 소스 클럭 도메인에서 동기화를 위해 6주기가 필요하며 동기화 지연이 필요한만큼 동기화 지연이 필요한 설계보다 선호되는 요소는 무엇입니까? 그러한 인터럽트가 불필요 할 정도로 동기화 지연이 짧습니까?
답변
그것은 저에게 일을하는 다른 방법입니다. 레지스터가 CPU 클럭 또는 클럭의 1/2 이상인 아키텍처에 익숙합니다. 따라서 레지스터를 작성하면 바로 준비됩니다. 아마도 그들은 전력 절약을 위해 이런 식으로하고 있습니까? 주변 장치 레지스터를 별도의 느린 클럭 도메인에 배치하는 경우 주 발진기 또는 CPU 클럭을 깨우고 실행할 필요는 없지만 주변 장치의 값을 계속 업데이트 할 수 있습니다.
이 경우 슈퍼 슬로우 주변 장치 블록에 레지스터를 작성하고 전체 CPU 또는 클럭 게이트에 대해 전원 아일랜드를 비활성화 한 다음, 느리게 동기화 프로그램이 만족할 때까지 읽은 다음 CPU를 중단하여 꺼내십시오 수면.
또는 6주기를 돌리고 매 쓰기를 기다리는 대신 깨우는 시간에 최대량의 명령을 넣을 수 있습니다.
왜 그렇게 많은 동기화주기를 사용하는지, 편집증이되거나 고객 중 하나의 높은 신뢰성 표준을 충족시킬 수 있습니다. 확실히 말할 수는 없지만 모든 램과 같은 요구를 가진 고객이 ecc를 가지고 설정 값 등으로 사전로드되는 것을 보았습니다.
나는 그것이 확실한 대답은 아니지만 데이터 시트를 약간 살펴본 후에 내 생각이라고 생각합니다.