OS Kernel
kkamagui(까마귀, 한승훈)
2004. 11. 3. 14:46
2004. 11. 3. 14:46
음... 오늘 ARM 문서를 보면서 여러개의 레지스터의 값을 메모리로 저장하고, 메모리
에서 읽어오고 하는 문서를 봤는데... 역시 책으로만 보니 별로 잘 모르겠다. ㅡ_ㅡ;;
일단 명령을 실행하고 메모리를 보면 금방 알꺼 같은데.. 그러기 위해서는 눈으로
멀 표시하게 하는게 최고 우선인거 같다.
당장 붙어있는 놈이라고는 LED하고 시리얼 정돈데... LED로 보는건 좀 어의없는거
같고 그렇다면 역시 시리얼쪽을....... +ㅁ+
흠... 일단 UART쪽 프로그래밍을 쬐금 해서 write만 구현해 놓고 PC에서 확인하는
쪽으로 진행을 해야겠다.
LCD가 없으니 쫌 답답하군... ㅡ_ㅡ;;;
kkamagui(까마귀, 한승훈)
2004. 11. 3. 14:46
2004. 11. 3. 14:46
아아.. 참 길고도 험한 여정이었다. ㅡ_ㅠ
Cache 땜시롱 한번 헤매고, EDMA 땜시롱 한번 헤매고, AD535 ADC 땜시롱 또 헤매
고... 음메, 왜 일케 빡신겨...
사실 Sampling 처리에 문제가 조금 있었는데, 내가 녹음한 MP3 파일은 44khz Stero
형식인데, C6711의 AD535는 Mono에 8khz다.
따라서 변환이 필요한데, 머 마땅히 어디서 손쉽게(??) 긁어올 수 있는 곳은 안보이고,
고민하던중 또 나의 얍삽이가 고개를 들었다. (어찌나 고마운지.. ㅋㅋ)
"음... 8khz는 44khz의 약 1/5 쯤이니까 버퍼를 5개씩 뛰어가면서 0xFFFE로 AND한
다음 그걸 담아서 EDMA로 전송하게 하면... +ㅁ+/~~"
지금 생각해보니, 정말 하드코어(??) 얍삽인데.. ㅡ_ㅡ;;; 여튼 급하니까 일단 구현을
했었다.
MP3 Codec이 한번 디코딩을 하면 4068(?? 확실치 않음)byte 정도의 데이터가 나왔
는데, 이걸 내가 만든 얍삽이로 play를 하게되면 아래와 같이 된다.
정상적인 44khz Stero를 쓸때 :
4068 / ( 44 * 1024 * 2 ) = 0.0451초
하드코어 얍삽이 + 8khz Mono를 쓸때 :
4068 / ( 2 * 5 ) / ( 8 * 1024 ) = 0.0497초
따라서 소리가 약간 늘어지고 거칠게 들리긴 하는데, 나름대로
괜
찮
다
고 생각한다. ㅡ_ㅡ;;;; (절대 타협하는건 아니고, 진짜 들을만 하다 +ㅁ+/~)
근데 허무한건, 난 아무것도 아직 한게 없다는 것이다.
기껏해야 EDMA랑 MCBSP랑을 연결해서 출력을 하게 했는데 걍 소리 나오고.. ㅡ_ㅡ;
C5510 할때는 실수 연산하는 함수까지 내가 만들어서 Clock을 줄일려고 난리쳤는데...
FPU의 힘을 강하게 느끼는 계기가 되었다.
없는놈이 있는 놈을 이기려면, 같은 조건가지고는 영 어렵겠군.
여튼 1차 완료~ @0@/~
kkamagui(까마귀, 한승훈)
2004. 11. 2. 14:53
2004. 11. 2. 14:53
음냐.. ㅡ_ㅡ;;; MP3 디코딩된 버퍼를 EDMA를 통해 MCBSP로 AD535에 쏘고 있는데,
(얼래.. 말이 좀 희한하게 됬네. 단어의 나열같은...) 이놈이 잘 가다가 갑자기 MCBSP
에서 XRDY가 뜨지 않는다.
으음... 사인 버퍼를 넣으면 잘 출력되는데, MP3 디코딩된 버퍼를 넣으면 갑자기 어느
순간에 멈춘다.
AD535랑은 따로 제어 MCBSP를 쓰는건 아니고, 하나의 MCBSP로 음성 송수신,
AD535제어를 다 하고 있기 때문에...
아무래도 제어 문자가 있는거 같다. 음냥.. 어쩌징.. ㅡ_ㅡ;;;
낼 일단 AD535문서를 한번 뒤져볼 필요가 있겠다.
쿨럭..;; 머가 이래 빡신지.. 쩝쩝..
kkamagui(까마귀, 한승훈)
2004. 11. 2. 14:52
2004. 11. 2. 14:52
쿨럭.. ㅡ_ㅡ;;;; 오늘 AD535에 대한 문서를 줄줄이 뽑아서 읽어보던중... DSP -> AD535로 가는 Voice Data 중 0bit가 특별한 의미를 갖는다는걸 알았다.
0bit가 1로 설정되면 다음 16bit data는 Codec Register 설정에 대한 데이터를 의미하는 것이었었더랬었던 것이다.(?? ㅡ_ㅡ;;; 상당히 문법이 의심스러운... 갑자기 회사 사람이 이야기 해준 Hello,World 누가 길게 찍나가 생각나네.. ㅋㅋ)
쿨럭..;;
그렇다면 AD535는 0xFFFE로 AND 연산을 해준다음 데이터를 쏴야~ 제대로 소리가나온다는.. 쿨럭..;;;
여튼 그래서 AND를 해주고 데이터를 송신하니 별 이상없이 소리가 나긴 나는거 같다.
거참 어렵구만.. ㅡ_ㅡ;;;
kkamagui(까마귀, 한승훈)
2004. 11. 2. 14:47
2004. 11. 2. 14:47
쿨럭.. ㅡ_ㅡ;;;; 오늘 AD535에 대한 문서를 줄줄이 뽑아서 읽어보던중... DSP -> AD535로 가는 Voice Data 중 0bit가 특별한 의미를 갖는다는걸 알았다.
0bit가 1로 설정되면 다음 16bit data는 Codec Register 설정에 대한 데이터를 의미하는 것이었었더랬었던 것이다.(?? ㅡ_ㅡ;;; 상당히 문법이 의심스러운... 갑자기 회사 사람이 이야기 해준 Hello,World 누가 길게 찍나가 생각나네.. ㅋㅋ)
쿨럭..;;
그렇다면 AD535는 0xFFFE로 AND 연산을 해준다음 데이터를 쏴야~ 제대로 소리가나온다는.. 쿨럭..;;;
여튼 그래서 AND를 해주고 데이터를 송신하니 별 이상없이 소리가 나긴 나는거 같다.
거참 어렵구만.. ㅡ_ㅡ;;;
kkamagui(까마귀, 한승훈)
2004. 11. 1. 14:54
2004. 11. 1. 14:54
컥.. 이런이런.. 한참을 헤맨끝에 문득 떠오른 생각...
"음... 혹시 빌드 옵션에서 본 call 방식때문에 그런가.. ㅡ_ㅡ;;;"
빌드 옵션에 들어가보니 near call/near data인가??? 머 이걸로 되어있었다.
MP3코드가 좀 길다보니 near call은 안되는 것도 몇개 있겠다 싶어서 far call/data로
수정하고 링크했더니 링크가 되공.. ㅡ_ㅡ;;;
머 이제 보드에 MP3 데이터를 올려야 하니, 내가만든 C55용 툴을 개조해서 C67용으
로 수정하고 메모리에 올려서 테스트 하는데,
얼래... 계속 MP3 Frame이 잘못됬다는 에러가 나네.. ㅡ_ㅡ;;;
산넘어 산이라고, 것참 만만한게 아니구만 쩝쩝.
죽어라 삽질끝에, 디버깅하다가 데이터가 이상해지는 걸 발견... 함수에서 넘겨받은
파라메터의 값이 실행도중에 바뀌는 것이다. 역 어셈해봐도 딱히 이거다 짐작가는건
없고... 근데 웃기는건 그 함수에서 다른 함수로 파라메터를 넘겨주면 넘겨받은 함수
의 파라메터는 변하지 않은 정상적인 값으로 나옴.
음냥, 결국 C67의 디버그는 못믿겠다는 결론에 봉착하고 메모리를 살피던 도중, 올라
간 메모리가 먼가 이상함을 발견했다.
자세히 들여다 보니, 헉... C55는 데이터를 Word 단위로 받기때문에 C67도 그런줄
알고 Word 단위로 데이터를 만들어서 CCS로 로딩했더니, 이게 실은 Dword로 읽어
들여 상위를 모두 0x0000으로 체웠던것이다.
그러니 프레임 에러가 날 수 밖에.. ㅡ_ㅡ;;;
툴 수정후에 다시 로딩해서 실행하니, 프레임 에러는 없음.
으으... 토하겠다 ㅡㅠㅡ;;;;
머가 이렇노..
kkamagui(까마귀, 한승훈)
2004. 10. 31. 14:56
2004. 10. 31. 14:56
Boot Code를 분석하던 중에 LDR과 MOV의 명령을 보게 되었다.
ARM 문서를 보니 둘다 레지스터에 값을 넣는거던데.. ㅡ_ㅡ;;;
이래 저래 서로 명령어를 스위칭해가면서 테스트 했는데 실패...
웹상에서 아는 분께 물었더니,
LDR ==> 메모리에서 레지스터로 값을 넣음.
MOV ==> 레지스터 또는 Immediate를 레지스터로 넣음.
이었던 것이다.
음냥.. 근데 여기서 이상한걸 발견할 수가 있는데, LDR과 MOV 모두 12bit Address
bit를 가지고 있다.
근데, LED 포트는 0x90040000로 표기되는 32bit인데 어떻게 LDR r0, =0x90040000
를 통해 레지스터에 32bit 값을 넣을 수 있는 것일가??
arm-linux-gcc로 일단 컴파일 링크를 거친다음 arm-linux-objdump로 역어셈블해본
결과 위의 코드는 아래와 같이 되어있었다.
80c8: e59f0068 ldr r0, [pc, #68] ; 8138 <LedFlashing+0x1c>
.....
8138: 90040000 andls r0, r4, lr
컥... 결국 메모리에 0x90040000를 어딘가에 써넣고, LDR 명령에는 해당 OFFSET의
메모리 Address만 넣어둔 것이었다 @0@/~~
쿠.. 쿨럭..;;
저.. 저런식인가.. ㅡ_ㅡ;;;
kkamagui(까마귀, 한승훈)
2004. 10. 30. 14:57
2004. 10. 30. 14:57
으으.. ㅡ_ㅡ;;; 왜일케 복잡한지... 믿었던 문서에 약간 미비한점도 있고...
여튼 이래 저래 하다보니 결국 크로스 컴파일러를 만들었다.
근데, 이놈도 마찬가지로 링크할때 바로 binary로 링크가 안되고 ELF로 링크가
되었다. binary를 사용하게 포멧을 binary로 줬더니 ARM링크할때는 ELF말고는
안된다는 에라 메시지가 나온다.
힘들게 컴파일 했더니만, 결국 GNUARM과 같은 결과가 나왔다.
일케되면 GNUARM을 걍 설치하고 PATH만 잡아주는거랑 같은결관데.. ㅡ0ㅠ/~
완전 생쇼를 했군... ㅡ_ㅡ;;;
머 그래도 제대로 설치 됬으니, 그것 하나는 다행인거 같고...
부트로더 같은거 만들려면... 순수 Binary가 필요한데 멀로 만드나...
ObjCopy라는게 있긴하던데, 이걸로 만드는감...
일단 낼 또 한번 뺑이를 쳐봐야 겠군.
오.. 글고 신기한건, 어셈 파일 형식인데 .S라는 확장자를 가지고 내부적으로는 C파일
전처리기 + 어셈코드 인거 같다.
어셈코드안에 #include 가 있는걸 보니...
으음.. 일케되면 걍 쓰면 된다는 결론이 나오네...
좋구로.. ㅋㅋㅋ
아.. 야심하군. 자야긋다.
홧팅 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 10. 29. 14:58
2004. 10. 29. 14:58
쿠오~ 오늘
KESL 사이트를 뒤지다가
Cygwin에서 소스를 다 받아서 크로스 컴파일러를 만드는 문서를 구했다.
문서에 보니깐 테스트까지 해봤다고 해서, 속는 셈 치고 해봤더니
얼래.. ㅡ_ㅡ;;
gcc와 glibc가 만들어지는거 까지 확인했다.
대
박
이
군
!!!
이것만 되면 또 열심히 삽질하면서 플래쉬 굽고 리셋하고를 반복하겠군.
아아.. x86 커널 만들면서 다시는 안하겠다고 다짐했는데.. ㅡ_ㅡ;;;
시간이 좀 지나니 또 관심이 가는것이... 으으.. ㅡ_ㅠ...
일단 어셈코드부터 익숙해져야 겠다.
다 알 필요는 없지만 부트 코드랑 어셈 함수 정도는 만들 수 있어야 나중에 편해지니
까 고정도까지만 해둬야징...
여튼 좋구나아아아아~~~
쿠하하핫 @0@/~
kkamagui(까마귀, 한승훈)
2004. 10. 28. 14:59
2004. 10. 28. 14:59
음메... Cygwin과 GNUARM의 조합으로 구축해 보려던 환경은 오늘 실패로 끝났다.
으으... 설정파일 같은걸 시도하다가 결국 실패하여 파일을 한 폴더에 몰아넣는
'하드코어' 테크닉을 구사하여 머 실행까지는 시켰는데... ㅡ_ㅡ;;;
문제가 3가지 정도 있었다.
1. library 파일을 못찾는다.
2. include 파일을 못찾는다.
3. elf 파일 포멧 말고는 못만든다. (난 Binary 파일하고 coff 파일이 필요한데.. ㅡ_ㅡ)
쿠.. 쿨럭..;;;
걍 리눅스 깔아서 거기서 쓸까나.. ㅡ_ㅡ;;;;
kkamagui(까마귀, 한승훈)
2004. 10. 27. 15:00
2004. 10. 27. 15:00
요즘 또 ARM쪽에 문서를 보기 시작했는데, 이놈이 참 재밌는 구조를 하고 있다.
특히 IRQ위에 상위 Fast IRQ인가 하는게 더 있던데...(명칭 불확실) IRQ보다 우선순위
가 높아서 IRQ가 발생한 시점에도 Fast IRQ가 선점가능하다.
그리고 운영 모드도 여러 모드가 있어서 상당히 세분화 되있는듯한 느낌을 받았는데,
인상적인건 각 모드마다 banked register라는게 있어서 모드가 변경될때 이 레지스터
들은 이전 모드에서 사용하는 레지스터가 아니라는 것이다. @0@/~
오우~ 얼마나 헷갈리는 이야기인가.. ㅡ_ㅡ;;;
머 여튼 뺑이 쳐보면 알겠지.. ㅋㅋ
글고 어셈 명령이 좀 특이하던데, 어셈명령하나로 여러개의 레지스터에 줄줄이 넣고
빼고 할 수 있는거 같넹.
스택에 줄줄이 넣고 빼던데 이걸 사용하면 걍 스택에 넣는걸로 해서 Task Switching
을 구현할 수 있을꺼 같다.
쿠핫핫핫핫~
뺑이다 뺑이 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 10. 27. 14:59
2004. 10. 27. 14:59
kkamagui(까마귀, 한승훈)
2004. 10. 26. 15:01
2004. 10. 26. 15:01
컥..;;; 소스를 열심히 갖다 붓고 컴파일 에라를 잡은다음 링크를 거는 순간...
또 억장이 무너지는.. ㅡ_ㅠ;;;
살포시 떠오르는 빨간색의 링크 에라는 정체를 알 수 없는 문제를 ㅡ_ㅡ;;;;
머 오브젝트 파일에 특정 헥사값을 적고 빨간색으로 메모리 블럭이 머 어쩌구 이런
에라던데... ㅡ_ㅡ;;;;
참으로 당황스럽군.
Endian도 똑같고 각 변수 키워드들의 메모리 크기 같은것도 거의 차이가 없어서
금방될 줄 알았는데......
우우... 먼일일까나...
DSP는 역시 만만하게 볼 께 아닌거 같다.
ㅠ_ㅠ/~~ 크윽...
kkamagui(까마귀, 한승훈)
2004. 10. 23. 15:03
2004. 10. 23. 15:03
오늘 하루종일 삽질한 결과가 드뎌 나왔다.
EDMA하고 MCBSP를 오만 삽질끝에 드뎌 연결한것이다. @0@/~~
사인파가 삘삘 거리면서 스피커로 나오고 있다. ㅡ_ㅡ;;;;;
얼마나 해멨는지.. 말도 몬한다. ㅡ0ㅠ...
분명 XEVT0로 신호가 와서 EDMA가 사인파 데이터를 AD535쪽으로 퍼줘야 함에도 불
구하고, 전혀 소리가 안나는 것이다.
그리고 웃긴건, 간혹가다가 Transfer가 되고 그러고 난 뒤에는 AD535 초기화 실패..
잇단 코드 붕괴(??) ㅡㅠㅡ;;;;;
당체 먼일인지...
처음에는 EDMA쪽 설정이 잘못된줄 알고 죽어라 설정을 바꿨으나 똑같은 결과..
그나마 Transfer 갯수를 줄이면, 코드 붕괴(??)가 덜됨.. ㅡ_ㅡ;;;
일단 EDMA의 오동작으로 내맘대로 정하고 잠깐 쉬다가 다시 생각해보니 말도 안됨.
그리 해메다가 구석에 짱 박혀있는 책을 발견하고 뒤짐. 음냥.. 별 내용 없음 ㅡㅠㅡ;;;
또 한참을 삽질하고 MCBSP의 XINT를 강제로 Enable도 시켜보고 별 삽질 다했으나
결과는 나의 장렬한 전사. >ㅁ</~~
낡은 책을 한참을 뒤지던 끝에 대략 다음과 같은 간단한 문구 발견
"This is same as send to AD535 Dummy Data..."
쿨럭.. 번쩍이며 내 뒷골을 때리는 생각과 동시에 눈에 들어오는 코드...
EDMA를 Enable하고 났으니 이제 본격적으로 XEVT0를 발생시키기 위한 Trigger가
필요했던 것이다.
아아아아아아앍~~~ @0@/~~
그래서 걍 더미 데이터를 딱 나리자 마자 걍 소리남.. ㅡ_ㅡ;;;;
우이 씨...
왜이리 멍청한걸까?? ㅡㅠㅡ;;;;
자.. 그람 좀 쉬어볼까나... ㅋㅋㅋ
kkamagui(까마귀, 한승훈)
2004. 10. 21. 15:03
2004. 10. 21. 15:03
C6711 Chip의 Cache는 상당히 복잡한 구조를 가지고 있는거 같다.
L1, L2 Cache 간의 coherence는 snoop 커맨드로 지들이 알아서 동기화를 하는거 같
다.
L2, external 간의 coherence는 지들이 알아서 하는게 아니라 내 책임이란다. ㅡ_ㅡ;;
쿨럭.. 그래서 다음과 같은 상황에서는 앞서 아래와 같이 먼저 하라고 권고한다.
periperal -> external ram dma transfer 후 CPU가 buffer를 읽어야 할때
-> L2 write back Invalidate
CPU가 buffer를 조작 후 external ram -> periperal로 Transfer 할때
-> L2 write back
글고 CPU와 EDMA간에 external memory를 통한 array transfer를 할 시, array는
-> cache line 크기의 배수
-> cache line 경계에 정렬
되어야 한댄다. ㅡ_ㅡ;;;
이제야 지난번에 내가 EDMA로 external memory -> external memory로 transfer
를 했을때, 안됬는지 이유를 대강(??)알겠다.
쿨럭..;; 복합적인 이유였군.. @ㅠ@/~~
kkamagui(까마귀, 한승훈)
2004. 10. 16. 15:04
2004. 10. 16. 15:04
으으... 요즘 MP3처리때문에 여러 책들을 뒤지고 있다. 머 뒤지기만 할 뿐 크게 깨닫지
를 못하고 있어 상당한 에라지만... 언젠가는 도가 터질날이 있겠지...
우웅... kkamaugi 커널 만들때도 일케 빡시지는 않았는데...
그때는 OS에 대해 잘 몰라서 그걸 이해하는데 빡셨을뿐, Audio 처리는 알고리즘에
이해도 힘들고 구현은 더 빡신.. ㅡ_ㅡ;;;;
으으.. 여튼 큰일이다. 큰일 쩝쩝..
머 열심히 하는 수 밖에...
홧팅 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 10. 13. 15:05
2004. 10. 13. 15:05
커억... 지난번에 DSP 보드는 Big Endian에 Word Addressing을 지원하는 칩이었는
데, 이번놈은 상당히 재밌다. 그냥 PC같은 Little Endian에 Byte Addressing을 지원
하고, 더 충격적인것은 long이 8byte라는 것이다. ㅡㅠㅡ;;; 쿨럭..
같은 dsp인데 일케 다를수가... 가장 충격적인것은....
이놈이 달고있는 ADC가 8khz짜리라는 것이고, 11khz까지 된다고는 되어있으나,
지금 보드 문서를 뒤지고 있는데, Clock Generator를 건드릴 방법이 없다는...
컥.. 이놈은 전화기쪽하고 관계된 일을 하는 놈인가?? ㅡ0ㅜ/~~
완전 음질이 전화기 음질, 그리고 잭은 스테레오 잭이지만, 출력 아웃풋은 모노인거
같은데, 모노를 그냥 스테레오 잭에 실어서 날리는거 같다.
아아~ 몬산다 몬살아... 소스도 손봐야 되고, Sample rate도 변환을 해줘야 할꺼 같다.
험난한 길이군.. ㅡ0ㅠ/~~
kkamagui(까마귀, 한승훈)
2004. 10. 10. 15:06
2004. 10. 10. 15:06
컥... 이런 이런... 같은 TI에서 나온 DSP인데... Endian이 모델마다 틀리게 설정되서
나오는 낭패를.. ㅡ_ㅡ;;; 얼마전까지 하던 DSP는 Big Endian이었는데, 이제는 Little
Endian으로.. ㅡㅠㅡ;;;; 크음.. 일단 걍 어디 하드웨어적인 셋팅으로 다시 Big Endian
으로 수정할 수 있는가 확인을 해봐야겠다. 소스를 수정할려니 좀 귀찮아야지 >_<
여튼 희한하군 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 10. 5. 15:07
2004. 10. 5. 15:07
으으... 오늘도 안돌아가는 꼴통을 붙잡고 MP3관련 문서들을 죽어라 보고 있다. 그러나 오늘도 역시 처참한 패배.. ㅡ0ㅠ/~~ 당췌 잘 몰겄구만... 머 자꾸 여러문서를 뒤지다보니 깨닫는건 있지만...
그래도 아직 멀었다는 생각이 든다. 음성처리이론쪽으로 책을 한권 봐야 할듯도 하고... 혹시나 모를 다른 디코더 소스들도 뒤져서 어케 처리하는가 확인을 한번 해봐야 겠다.
정말 참.. 어렵구나.. 쩝쩝..
그래도 홧팅 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 10. 3. 15:09
2004. 10. 3. 15:09
크윽.. 얼마전까지만해도 실수 연산 속도만 높이면 해결될꺼라고 생각했던 문제가, 오늘 적용해보니 문제 해결에는 크게 도움이 되지 못했다. 약간의 속도 향상은 있었지만, 워낙 Floating Point Unit을 가지고 있는 놈들에 비해서 실수 연산 속도가 차이가 나니까 커버가 영 어려웠다.
으음.. 방법이 없을까나... 선배가 웹을 뒤지던 중에 fixed Point DSP를 이용해서 Real Time MP3 Player를 구현했다는 중국인( 추측.. ㅡ0ㅡ;; ) 의 석사 논문을 구했는데, 이게 아주 예술이다. Decoding 하는데 사용하는 알고리즘을 수학적 기법을 용해서 좀더 나은 알고리즘으로 구현했다는거 같던데, 그걸 어셈코드로 작성을 했다고 나와있공.. ㅡ_ㅡ;;;;
난 수학적으로 풀어낼 능력도, 어셈코드를 작성할 능력도 아직 안되는데...
더욱 큰 문제는 소스가 없다는 것이다. 크헉.. 몬산다... ㅡ0ㅠ/~~
아아.. 어찌하란 말이냐아아아아...
정말 아찔하지 않을 수 없다.
에궁.. 갈길이 멀구나... 멀어.. ㅡ0ㅠ/~~
kkamagui(까마귀, 한승훈)
2004. 10. 3. 15:08
2004. 10. 3. 15:08
몇주째 계속 진행하고 있는 MP3의 디코딩이 역시 쉽지 않다. 오늘 시내에 갈일이 있어 교보문고에서 혹시나하며 책을 뒤지고 있었는데, MPEG에 대한 자료를 몇개 구할 수 있었다.
몇권을 뒤져본 결과 한권의 쓸만한 책을 찾았는데, MP3에 대한 간략한 설명만해놓아서, 크게 도움이 되지 않았다.
인터넷에서 자료를 찾을려고 했었는데, 내가 왜 책 생각을 못했을까...
이 기회에 책을 한권 사볼까나??
kkamagui(까마귀, 한승훈)
2004. 9. 25. 15:09
2004. 9. 25. 15:09
음.. 요즘 아는 선배가 내가 MP3 Decoder를 하는 사이 MP3 Encoder를 하게 되어서 같은 분야를 얼마동안 하게 되었다. 흠... 근데... 내가 Decoder할때 그렇게 찾아도 나오지 않던 자료들이... 선배는 쏙쏙 잘도 뽑아내는것이 아닌가?? @0@/~~
컥.. 이 무슨일인가.. 혹시나 내가 안가본 사이트인지 확인하니...
다 들렸던 곳이다.. ㅡ0ㅡ;;;;;;;;
머징... 근데 난 왜 자료를 못찾았을까나... 나의 검색능력은... 빵점이었던 것이다.
쿠.. 쿨럭;;;;;; ㅡ_ㅡ;;;;;;
근데 참 선배들도 대단하지... 어케 그 많은 문서중에 그런걸 찾아냈을까나...
역시.. 내공.. 200%군.. ㅋㅋㅋ
난 Decoder 소스도 x86껄 찾아서 포팅한다고 쌩쑈를 했는데... 소스도 보니까 있공...
컥.. >_<.... 머.. 그래도 포팅하면서.. DSP칩에 대해 먼가 좀 알긴했지만...
삽질했다는 것 만큼은 변함이 없네. 음냥...
네트워크의 시대
지금 우리에게 가장 중요한건 원하는 자료를 얼마나 빨리 찾아내는것이 아닐까하는 생각이 든다.
여튼 홧팅이다. @0@/~~~
kkamagui(까마귀, 한승훈)
2004. 9. 20. 15:11
2004. 9. 20. 15:11
어제 드뎌 Assembly를 함 해보겠다고 assembly function을 만들어 Call을 했는데, 머 복잡한 루틴은 아니고, 그냥 간단히 word를 dword로 변환시켜 리턴하는 그런함수였다.
이걸 루프에서 주기적으로 call해서 clock을 측정해 보려는 용도였는데, 얼래...
굉장히 clock이 적게 나왔다. ㅡ_ㅡ;;;;
Sum 한 결과도 이상하고 그래서 따라가보니, 얼래.. for문의 Exit를 비교하는 부분이 이상했다. 분명 종료조건이 들어가있는 레지스터는 AC1인데, 비교하는건 T0와 비교하지 않는가?? ㅡ0ㅡ/~~
커헉... 내가 만든 Assembly function을 Call하지 않으면 멀쩡하고... 쩝쩝...초반부터 기선 제압을 당하는거 같다.
어디 두고보자 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 9. 19. 15:13
2004. 9. 19. 15:13
앗쌀~~ 오늘 Assembly에 대해서 나와있는 책을 구했다.
ㅎㅎㅎ 이제 열심히 삽질하는 길만 남았군. @0@/~~
에궁.. 역시 세상에 쉬운일은 없는거 같다.
쿨럭..;;; ㅡ0ㅠ/~~
kkamagui(까마귀, 한승훈)
2004. 9. 16. 15:14
2004. 9. 16. 15:14
으읏... 젠장... 머리를 싸매고 문서를 뒤지고 쌩 쑈를 하면서 고민한 결과, 이미 되어있는 intrinsic 함수보다 더 빨리 하는 방법은 역시 Assembly로 승부하는수 밖에는 없는거 같다.
일단 머, MP3 Decoder는 실수 버퍼를 정수 버퍼로 교체하여 속도를 높이는 쪽으로 잠정적 결론이 났고, 앞으로의 작업을 위해 Assembly를 피해갈 수 없는 상황에 봉착해있다.
크윽... Assembly는 x86에서 커널 만들 때 말고는 안쓰리라 결심을 했건만... 안그래도 Assembly는 완전 쌩짜 수준인데... DSP꺼까지 봐야하다니... ㅡ0ㅠ/~~
절망이 아닐 수 없군....
쿨럭...;;;
kkamagui(까마귀, 한승훈)
2004. 9. 14. 15:15
2004. 9. 14. 15:15
오늘 DSP의 실수 처리 문제로 고민하다, 아는 사람의 회사에 인도 사람이 DSP를 하고 있다는 이야기를 들었다. 그사람은 DSP의 inline Assembly가 전문이란다. ㅡ0ㅡ...
홍냐... 당췌 DSP를 얼마나 해야 inline Assembly의 대가가될 수 있는 것인지...
난 겨우 x86소스를 포팅하는데도 진땀을 빼고있는데 말이다.
인도가 소프트웨어가 발달했다는 말을 들었는데, 머 이렇게나마 몸으로 느끼게 되네...
나도 외국인 친구나 사귀어 볼까나.. ㅡ_ㅡ;;;
DSP를 하는 인도 사람으로.. ㅋㅋㅋ
여튼 방심하지말고 열심히 해야겠다 @0@/~~
kkamagui(까마귀, 한승훈)
2004. 9. 11. 15:15
2004. 9. 11. 15:15
쿨럭.. 오늘 DSP의 실수연산이 정수연산보다 느리길래 단순히 실수 연산이 굉장히 느리다고 생각하고 있었다. 그런데... 오늘 같은 실수 연산을 ARM쪽에서 수행한 결과...
30배 정도 ARM이 클럭을 더 먹었다. @0@/~~ 쿨럭.. 이게 무슨일인지...
물론 ARM쪽에 하드웨어 가속 같은건 하나도 사용하고 있지 않았기때문에 정확한 테스트가 안되었을지는 모르겠지만 굉장한 클럭 소모였다.
음냥 그렇다면 DSP쪽에서의 실수연산은 나름대로 최적화된 Built in 함수를 이용해서 수행하고 있으니, 속도의 향상을 꾀할려면 얍삽 코드를 삽입하여 계산하는 수 밖에 없다는 것인데... 참으로 막막하다...
이를 어찌해야 좋을까나?? ㅡ0ㅠ/~~~
kkamagui(까마귀, 한승훈)
2004. 9. 9. 15:16
2004. 9. 9. 15:16
DSP 실수연산이 이렇게 클럭을 많이 잡아먹는줄 몰랐다.
DWORD 포인터의 덧셈연산이 9클럭을 잡아먹는데, 실수 걍 덧셈은 141클럭인가를 잡아먹는다.
이게 무슨일인가??
DSP는 실수연산용 칩이라고 알고있었던 나에게는 상당한 충격이 아닐 수 없다.
이실장님과 고민한끝에 일단 실수 연산을 클럭이 적게드는 정수연산으로 변환시키자는 방안이 나왔는데, 고민한 결과 다음과같이 나왔다.
첫번째는 소수점을 다 버리더라도 실수를 정수로 캐스팅한다음에 정수연산을 하는 방법이다. 이 방법은 1.9를 1로 만들어버리기 때문에 크게 좋은방법은 아닌듯 하다.
둘째는 내가 고정소수점 연산의 형식을 강제로 추출해서 가수는 가수끼리 지수는 지수끼리 더하는 방법이다. 이방법 역시 굉장히 빡시고 쉽게 되리라고 생각하지 않는다.
셋째는 가장 간단하고 쉬운 방법인데, 연산하는 실수 테이블 자체를 * 1000같은걸 해서 정수 테이블로 수정하고 나머지 연산들도 정수연산으로 바꾸는 것이다. 사실 MP3 디코더 역시 실수를 다시 정수로 변환하는 과정이 마지막에 있기때문에, 이방법을 이
용하면 마지막 과정은 / 1000 으로 간단히 해결할 수 있으므로 괜찮은 방법인거 같다.
일단 시도해 보도록하자.
홧팅이다 @0@/~~