CPU 내부에 매모리를 따로 두고
자기 공간 매핑된 하드웨어들이 그 공간을 갱신하는 건가요?
아니면 메모리 공간처럼 보일뿐 사용자의 접근 순간 읽기를 위한 잡스러운 과정들이 발생하고 그 과정동안 걸리는 시간 고스란히 붙잡고 있는 건가요?
갑자기 이게 궁금한게 PCH 기능중에 iotrap이란게 있더라고요.
특정 IO port에 대한 읽기 쓰기 시도가 있을때 인터럽트를 발생시켜 주는 기능인것 같은데
CPU에서 도는 소프트웨어의 읽기 시도 혹은 쓰기 시도에만 반응하는 건지...
아니면 혹시 io port를 읽었을때의 기대값(?) 이 변하는 순간을 잡아넬수 있는건지가 궁금해서요.
메모리 공간처럼 보일뿐 사용자의 접근 순간 읽기를 위한 잡스러운 과정들이 발생하고 그 과정동안 걸리는 시간 고스란히 붙잡고 있는 건가요? <--- IO Port에 read/write하는 것은 In / Out 이라고 부릅니다.
인아웃 하는 동안은 붙잡고 있다...는 아래와 같이 설명을.
예를 들어서, 하드웨어 포트가 쓸 수 있는 상황이 될때까지 sleep interval을 주면서 대기 타다가 써지면 루프를 빠져나오는 방식을 많이 쓰는데,
하드웨어 포트가 쓸 수 있는 상황이 오지 않으면 무한대기 타는 경우도 있으므로 IO Port 프로그래밍은 시간차 설계를 잘~ 해야합니다.
씨피유 레지스터 만지는 프로그램을 함 보시면 이해가 더 잘될겁니다^^
거기 하드웨어 모니터링을 위해서 LPC를 통해서 임베디드 컨트롤러에서 자료 받아오는 과정이 있습니다..
그거 만들때는 되게 하는것만 신경쓰는라 시간도 안 찍어 보고 대기해야 하는 건 그냥 전부 폴링으로 대기 하도록 만들었는데
이번에 다시 정리하면서 확인해 보니까 16bit 짜리 CPU 온도 가져오는에 5ms 걸리더라고요.
이걸 인터럽트로 바꾸면서
혹시라도 중간에 공간을 두고 장치아 CPU가 서로 손님처럼 쓰고 지우는 것 이였다면 장치가 준비 완려 플레그 비트를 꼽는걸 인식하고 인터럽트를 발생시킬수 있겠다 싶었는데 그건 안되겠네요.. 타이머로 대기 시키는걸로 해야 겠네요 쩝...
레지스터 쓰기, 읽기 요정도만 검색해 보시면 한방에 이해하실 수 있을겁니다^^
근데, x86인 경우에는 몰라도, 임베디드의 경우에는 대부분의 레지스터 주소를 #define 싹다 해놔서 읽고 쓰기가 쉬웠던 기억이...
아, OS가 올라간 상태에서는 모든 레지스터가 읽혀지는것은 아니고 안읽히는 것도있고 드라이버를 따로 올려서 읽고/써야 하는 경우도 있어요~
이 임베디드 컨트롤러가 내부 매모리를 그대로 ioport에 노출하지 않고 IO port에 커맨트, 데이터 레지스터로 접근하는 구조라..
커맨트 레지스트에 읽기 할 주소 넣고 기다리면 EC가 데이터 레지스트 값 갱신해 주고 완료 플레그 뛰워주는 그런식인데..
완료 플레그 기다리는 그 시간이 엄청난것 같더라고요..
음 일단 OS 상에서 쓰는건 아니라서 스택 쌓여 있는것 고려 할 필요 없이 작업하고 있습니다..
레지스터 주소는 글쌔요.. 재조사에서 데이터 시트는 안 풀었는데 리눅스용 드라이버 소스는 풀었더라고요.
전 다른 기능은 안쓰고 딱 전압 온도만 받을거라서 필요한 부분은 다 긇어 왔는데
이 리눅스 드라이버도 전부 폴링으로 구성되어 있어서 인터럽트로 만드는 부분에서는 참고가 안되네요 쩝.