'ARM'에 해당되는 글 32건

9.APB 버스트동작 :: AMBA의 이해 시리즈 - 2009/02/14 13:11

Figure 1-2은 APB 의 Burst of Write 타이밍을 보여 줍니다. Figure 1-1, Figure 1-2의 각 Burst Read 와 Burst Write 모두 Single Transaction 과 비교하여 많이 다른점은 없습니다. 다만, IDLE 상태 구간이 필요 없슴으로 인하여 Burst 모드의 경우 성능상으로 조금 더 우월하다는 정도일 것입니다. Figure 1-2 Burst of write transfers Figure 1-3은 APB 의 Back to Back 타이밍을 보여 줍니다. 임의의 주변장치(APB 슬레이브)을 대상으로 읽고, 쓰는 동작이 반복적으로 발생하는 상황을 Back

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/89 관련글 쓰기
Name
Password
Homepage
Secret

8.APB 읽기동작 :: AMBA의 이해 시리즈 - 2009/02/14 13:07

 

Figure 1-2의 타이밍도를 보면 T2에서 HREADY 신호가 'NEGATE' 되어 있어서 T3 이후에 데이타를 APB 버스를 통하여 읽어낸후 비로소 'ASSERT' 되고 있음을 우리는 알 수 있습니다. 또한 T3 시기에는 APB PRDATA 버스상의 데이타가 같은 시간에 HRDATA버스에도 나타남으로써 AHB, APB 공히 한 동작으로 처리됨을 또한 확인 할 수가 있습니다. 그동안 APB 의 제어 신호중 주목 할 만한 것이 하나 있었는데 그것은 바로 PENABLE 신호입니다. 이에 대하여는 교재 5-11쪽 5.5.2 APB slave description 편에서 잘 설명하여 놓고 있습니다. For a write transfer the data can be latched at the following points: ? on either rising edge of PCLK, when PSEL is HIGH ? on the rising edge of PENABLE, when PSEL is HIGH. 이로써 버스 쓰기(WRITE) 동작시 PENABLE 신호는 데이타가 해당 장치에 기록 되도록 하는 latch 신호로서 사용됨을 우리는 쉽게 알 수 있습니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/88 관련글 쓰기
Name
Password
Homepage
Secret

7.APB 쓰기동작 :: AMBA의 이해 시리즈 - 2009/02/14 13:03

금번의 칼럼은 'AMBA의 이해'의 후속편으로 기획 제작 됩니다. APB(Advanced Peripheral Bus) 에 대해서 다룹니다. 비교적 짧은 시리즈로서 2~3편 정도의 분량이 될 것입니다. Figure 1-1 The APB in a typical AMBA system 고속의 메모리 그리고 DMA 장치로 인터페이스 되는 AHB에 비해서 APB는 비교적 저속의 주변장치들로 인터페이스 및 사용되는 것을 Figure 1-1은 보여 줍니다. Figure 1-2 State diagram 또한 Figure 1-2은 APB 의 기본 버스 동작의 구성을 보여 줍니다. 이 내용은 앞으로 나오게 될 그림들과 함께 보았을때 비로소 이해가 빠를 수 있습니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/87 관련글 쓰기
Name
Password
Homepage
Secret

6.AHB SPLIT TRANSFER :: AMBA의 이해 시리즈 - 2009/02/14 12:58

 SPLIT TRANSFER 특정 I/O 장치에 현재 진행되고 있는 버스 사이클의 오류가 아님에도 불구 해당 장치의 특별한 사정으로 현재의 버스 진행을 임시로 중단 한 이후 나중에 재개할 것이 필요해 지는 경우. 당 I/O 장치는 이 사실을 각각 HRESP('SPLIT'), HREADY('LOW')로서 현재의 마스터와 ARBITER에게 알린다. 해당 응답 신호를 수신한 현재의 버스 마스터는 대표적인 Two clock 사이클인 SPLIT 응답신호를 수신하고 이에 다음 버스 사이클에서 dummy 'IDLE' 사이클을 만들어 내며, 한편 버스 아비터는 현재의 버스 마스터로부터 버스 점유권을 곧이어 다음 사이클에서 수거해 간다. 더불어 현재 대기하고 있는 다른 버스 마스터들을 대상으로 우선순위 배정을 통해 최우선순위 마스터에게 버스 점유권을 허가 한다. 이때, 이전의 마스터는 버스 동작 진행 당시의 어드레스와 제어관련 신호들을 유보된 추후의

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/86 관련글 쓰기
Name
Password
Homepage
Secret

5.AHB 버스 중재(BUS Arbitration) :: AMBA의 이해 시리즈 - 2009/02/14 12:54

버스 중재(BUS Arbitration) 이번 시간에는 버스 중재(BUS Arbitration) 이라는 주제로 진행을 하기로 한다. BUS Arbitration mechanism 은 특정한 시간에 단 하나의 마스터만이 당 버스를 점유하여 사용 할 수 있도록 하여 주는 것을 의미한다. 아비터(Arbiter)는 이 일을 위하여 끊임없이 여러 마스터들의 버스 요구 요청을 감시하고, 가장 우선 순위가 높은 마스터에게 해당 버스를 점유하는 것을 허락한다. 이는 AHB상에서 다음과 같이 구현된다. 마스터는 HBUSREQx 신호로서 아비터에게 버스를 요청한다. 이에 아비터는 HGRANTx 로 버스의 점유를 허가한다. 한편, 아비터는 SPLIT 전송을 재개 하길 원하는 슬레이브들의 요청도 또한 감시한다. 이와 관련 자세한 내용은 SPLIT 관련 칼럼편에서 다루어 질 것이다. 버스중재 관련 신호들인 HBUSREQx, HLOCKx, HGRANTx, HMASTER[3:0], HMASTLOCK, HSPLIT[15:0] 에 대한 자세한 설명은 교재 3-28과 3-29쪽에 나와 있다. 해당 설명을 보면서 다음의 타이밍도를 함께 봐 주시길 바란다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/85 관련글 쓰기
Name
Password
Homepage
Secret

4.AHB 슬레이브 응답의 유형 :: AMBA의 이해 시리즈 - 2009/02/14 12:49

Figure 1-1는 전형적인 어드레스 디코더의 모습을 보인다. AHB DECODER 라 불리운다. 마스터에서 발생된 어드레스를 입력 받아 타깃 슬레이브의 칩셀렉트(CS) 을 만들어 낸다.할당 가능한 최소 어드레스 공간의 크기는 1KB 가 된다. 존재 하지 않는 어드레스 공간으로의 버스 오퍼레이션이 SEQ, NONSEQ 로 진행 될 경우 디폴트 슬레이브 장치는 ERROR로 응답 해야 한다. 한편, 마찬가지로 존재하지 않는 어드레스 공간으로 IDLE, BUSY로 버스 오퍼레이션이 진행될 경우는 슬레이브 장치는 zero wait 의 OKAY로 반드시 응답하도록 설계되어야 한다.
Figure 1-2는 AHB 주요 신호들의 관계를 확인하기 위해 좋은 그림이다.본 기획 칼럼 'AMBA의 이해' 마지막편까지를 보시게 되면 이후 Figure 1-2을 모두 이해 하게 되실 것으로 생각한다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/84 관련글 쓰기
Name
Password
Homepage
Secret

3.AHB Burst operation :: AMBA의 이해 시리즈 - 2009/02/14 12:43

Figure 1-1은 일반적인 버스 오퍼레이션의 그림이다. 어드레스 A 버스 동작은 HCLK 클럭 (**1)과 (**2) 로서 정상적으로 종료 됨을 쉽게 알 수 있다. 그 이후 어드레스 B의 동작에 주목 할 필요가 Figure 1-1은 일반적인 버스 오퍼레이션의 그림이다. 어드레스 A 버스 동작은 HCLK 클럭 (**1)과 (**2) 로서 정상적으로 종료 됨을 쉽게 알 수 있다. 그 이후 어드레스 B의 동작에 주목 할 필요가

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/83 관련글 쓰기
Name
Password
Homepage
Secret

2.AHB Basic BUS operation :: AMBA의 이해 시리즈 - 2009/02/14 12:20

용어 정리를 하도록 하겠다. 교재로는 3-5쪽을 참조 바란다. 버스 동작에 슬레이브(주변장치)가 응답하는 신호는 HREADY 와 HRESP 가 있다. HREADY 가 버스사이클 동작의 완료를 나타내는 것이 라 한다면 HRESP 는 그 해당 버스 사이클의 성공 유무를 판별한다고 지난 시간의 칼럼에서 설명 한 바 있다. HRESP 는 OKAY, ERROR, RETRY/SPLIT 등의 상태를 표시 한다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/82 관련글 쓰기
Name
Password
Homepage
Secret

1.AMBA의 개요 :: AMBA의 이해 시리즈 - 2009/02/14 10:42

1장.AMBA의 개요 2장.AHB Basic BUS operation 3장.AHB Burst operation 4장.AHB 슬레이브 응답의 유형 5장.AHB 버스 중재(BUS Arbitration) 6장.AHB SPLIT TRANSFER 7장.APB 쓰기동작 8장.APB 읽기동작 9장.APB 버스트동작

이번에 새로 진행하려는 기획 칼럼은 디지탈 하드웨어 냄새가 물씬 풍기는 주제 입니다. ARM의 대표적인 버스 구조이죠. 바로 Advanced Microcontroller Bus Architecture (AMBA) 입니다. 총 횟수로 10편이 될지 20편이 될지 저도 모릅니다. 그냥 무작성 써 내려 갈 렵니다.간단하게 진행 방식을 설명해 드려야 할 듯해서 앞으로 본 칼럼을 보시는 분들은 다음 설명을 필독 해 주시기 바랍니다.

posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/81 관련글 쓰기
Name
Password
Homepage
Secret

부트로더 제작 11편. blob 과 MMU - 2009/02/10 23:15

응용프로그램을 플래시에 저장하기

다음의 명령을 이용하면 응용프로그램을 플래시에 저장하여 필요할때 사용할 수도 있다.

blob> flash kernel [ENTER]

해당 응용프로그램은 리눅스 커널이미지를 저장하는 플래시 영역에 마찬가지로 기록된다.

이후 부터는 보드의 blob 부팅후 자동적으로 응용프로그램이 로드(load) 되어 실행된다.


주의사항!

flash kernel 명령을 사용하게 되면 기존의 플래시 메모리에 들어 있을지도 모르는 리눅스 커널 혹은 zImage 데이타는 사라지게 되므로 이 사실을 꼭 알고 실행하는데 주의를 바란다.


blob과 MMU

현재의 blob v1.07 버젼에는 ARM920T MMU 가 비활성화 되어 있다. 특별한 이유는 없고 현재 기능 구현이 안되어 있다고 보면 된다.

이후의 과정에서 필요한 경우 MMU 기능을 적용할 것이다. 캐시(cache) 또한 마찬가지로 비활성화 되어 있다.

아는 사람은 잘 알고 있는 내용이지만 uboot 라는 부트로더도 또한 MMU와 D캐시가 비활성화 되어 있다.

따라서, uboot 상에서 MMU및 데이타 캐시를 활성화 시키려면 추가의 노력이 필요하다. 한편 명령어 캐시(I-캐시)는

활성화 되어 있다. 따라서 이로 인한 큰 불편함은 없는 것이 또한 사실이다.

한가지 더 이야기 하자면

현재의 blob 에는 어떠한 인터럽트 또한 사용되고 있지 않다. 이 사실을 추가적으로 확인하기 바란다.


금번의 칼럼을 마지막으로 제2부 부트로더 제작 편을 모두 마칠것이다.

그러면 다음 제3부 응용 장치의 활용편에서 다시 뵐 것을 약속드리며 blob에서 사용되는 uu[en|de]code 에 대해서 설명을 끝으로 본 칼럼을 마무리 한다.


uu[en|de]code

현재 blob 에서 파일을 다운로드 하는데 사용되는 uuencode 는 구글에서 찾아보면 다음과 같이 잘 설명되어 있다. http://www.terms.co.kr/Uuencode.htm

"

기본적으로 Uuencode가 하는 일은 파일이나 전자우편의 첨부물을 자체 바이너리 또는 비트 스트림 표현에서 7 비트 아스키 텍스트로 변환하는 것이다.

텍스트는 오래 전에 제작되어 바이너리 파일을 처리할 수 없는 시스템에서도 잘 처리될 수 있으며, 커다란 파일들을 좀더 쉽게 여러 부분으로 나누어 전송할 수 있다.

"

blob 에서는 uuencode 라는 유틸리티로 다운로드할 파일을 먼저 변형시킨후 이를 통신터미널을 이용해서 다운로드하고 blob 에서는 이를 다시 uudecode 하는 방법으로 uu[en|de]code가 사용되고 있다.


수고 하셨습니다.


posted by 가일(GUILE)

♡ 포스팅이 유익 하셨다면 E-mail로 가일의 임베디드 스쿨을 구독하세요->

Trackback Address :: http://www.hongikcom.com/trackback/80 관련글 쓰기
Name
Password
Homepage
Secret
< PREV |  1  |  2  |  3  |  4  |  NEXT >