태그 보관물: 하드웨어

[RPI-PICO] 오디오 쥬크박스 만들기 2

이전글들

우선 하드웨어 구성은 아래와 같습니다.

Waveshare Pico-Audio original revision
Waveshare Pico-LCD-1.44
Raspberry Pi Pico
microSD Card Adapter
Waveshare Expander Quad

이중에서 Pico-Audio는 I2C 연결
Pico-LCD-1.44는 SPI 연결
microSD Card Adapter도 SPI 연결이구요

라즈베리파이 피코가 SPI 채널이 두개라, 잘 안겹치게 배정해서 소스코드에 기재하면 됩니다. Expander를 쓰기 때문에 하드웨어적으로는 일단 조정을 잘 안해도 되고 다만 microSD Card Adapter의 경우 핀 구조상으로 Expander에 못끼우기에 점퍼케이블을 female to female로 연결해야 하네요.

본래 Expander Dual을 썼는데 모듈을 하나 더 달아야 해서 Quad로 바꾼 것도 특기해야 합니다.

일단 기존의 샘플 코드를 분석해서 흐름을 꿰찰려고 했는데요. Pico-LCD-1.44의 네개 버튼 시연 코드를 일부 떼어내어 가져와서 메뉴를 구성하고 키값을 구해서 눌린지 확인하는 조건문 코드 안에 Pico-Audio 시연 코드에 들어있는 톤 재생 코드를 두니 버튼 누르면 재생이 되었습니다.

그러나 같은 키를 한번 더 누르면 멈추게 하는 것을 살펴봐야 했고, 이는 제작사에서 제시한 라이브러리로 가능한데요. 음질의 경우 톤으로 내는 것은 소스코드에 텍스트 정보로 톤 정보로만 저장되어 재생되는 구조라 음질이 조금 좋은 부저 정도라, MP3 정도는 되어야 하기에 그만두고 microSD Card Adapter를 구해서 연결해보았습니다. microSD 카드에 MP3를 저장해서 불러오는 용도였죠.

microSD 카드는 킹스턴 제품으로, SDHC class 10 UHS-I 지원 제품인데요. 어떤 이유로 인해 FatFS를 사용하는 모든 기존의 프로젝트에서 f_mount() 실행시 error: physical drivce does not work 같은 오류가 나면서 마운트에 실패합니다.

몇가지 이상 증상은

  • LED 점멸로 상태작동을 보여주는 기능이 작동하다가 안하다가 하는데 무조건 마운트 실패
  • BOOTSEL 연결시 PC에 30초 가량 딜레이가 발생하면서 마우스 커서 버벅임
  • 라즈베리파이 피코 내장 플래시가 2MB인데, 무려 127MB로 60배가 뻥튀기되어 보임
  • 아무런 파일도 기록이 안되던 microSD 카드에 이상한 파일과 디렉토리가 발견

인데요.

뭔가 이상해서 macOS에서도 해보니 똑같이 f_mount()에서 안돕니다.

아무래도 FatFS에서 내부적으로 쓰는 코드 중에 SPI 핀과 SD 카드 명세는 잘 해놨어도 ff.c 같은 파일에서 지정하는 매크로 상수를 튜닝해야 제가 쓰는 microSD 카드와 호환된다는 것 같았는데 위 증상을 보면 석연치 않지만, 일단은 프로젝트 저자들도 SD 카드 브랜드가 문제라고 하기도 하네요. 잘 생각해보면 브랜드마다 사양도 다르고, 특히 블락 크기 설정 같은 설정도 잘 살펴서 해야 할 것 같습니다.

그래서 우선 재껴두고 집에 있는 USB 메모리를 달아 해보려고 하는데요. 라즈베리파이 피코의 USB 단자에 USB 메모리를 장착하고, Expander Quad에 별도로 있는 USB 단자로 전원공급을 해서 해볼 생각입니다. 라즈베리파이 피코를 MSC 호스트로 두고 해보는 것이죠. TinyUSB로 비슷한 작업을 하는게 되던데 잘 살펴보고 있습니다.

일단 USB 표준부터 보고 있고 단행본 입수전에 연구논문과 학위논문을 찾아서 일반적인 해설을 한 부분을 집중해서 보려고 하네요.

FatFS가 작동하면 128kbps 44.1kHz MP3 파일을 네개 저장해서 불러와서 LCD의 키로 메뉴 선택후 I2S로 재생하는 것을 할 것입니다.

FatFS로는 일단 집에 있는 USB 메모리로 해보고, 시간이 가면 microSD 카드를 최대한 작은 용량으로 오래전 사양으로 맞추어보려고 합니다. 둘다 안되면 FatFS 소스코드를 뒤적여서 하드웨어 명세를 맞추어줘야죠.

오디오 재생은 제가 쓰는 Pico-Audio original revision이 PCM5101A를 디코더로 쓰는데요. 32비트 384kHz까지 감지한다고 되어 있고 다이나믹 레인지가 106dB입니다. 44.1kHz 128kbps MP3 재생에 지장이 없습니다. 라즈베리파이 피코 C SDK에 포함된 USB 사운드 카드 모드로 돌려보면 음질이 좋습니다.

일단 USB MSC부터 살펴보면서 공부한 것을 정리해서 올리겠습니다.

[RPI-PICO] 라즈베리파이 피코의 USB 단자를 통한 Virtual COM Port 시리얼 모니터 사용법

vscode에 Raspberry Pi Pico 확장기능이 잘 설치되어 있다는 가정 하에 진행합니다. (특히 Serial Monitor)

우선 CMakeLists.txt에 아래 코드를 추가합니다

이 코드는 USB에 stdio를 허용하고 UART에는 비허용하는 코드입니다.

그리고 C 코드의 main() 함수에 아래 코드를 추가합니다.

이렇게 해두고 컴파일해서 uf2를 라즈베리파이 피코에 심습니다.

vscode에서 시리얼 모니터를 열고 Toggle Sent Message Echoing 버튼을 누르고 Start Monitoring 버튼을 누릅니다. 그러면 라즈베리파이 피코가 USB에 연결된 상태라면 BOOTSEL이든 일반 연결 모드든 위에 printf()문으로 보낸 정보가 시리얼 모니터에 뜹니다.

처음 연결했다면 printf() 문이 이미 실행되고나서 시리얼 모니터가 켜졌을때 표시가 안될 수 있으니, Toggle Sent Message Echoing을 켜고 Start Monitoring 상태에서 USB를 뺏다 꽂으면 됩니다.

이를 잘 활용하면 함수 실행 결과를 받아와서 조건문으로 검사하고 오류가 난 것을 보여줄 수 있습니다.

[RPI-PICO] 오디오 쥬크박스 만들기 1

라즈베리파이 피코로 쥬크박스를 만들어보려고 합니다. 하드웨어 구성은 살펴볼 필요가 없이 아래처럼 조합했습니다.

라즈베리파이 피코 (RP2040)
Waveshare Pico-LCD-1.44
Waveshare Pico-Audio
Waveshare Dual GPIO Expander

이구요.

https://www.waveshare.com/wiki/Pico-LCD-1.44
https://www.waveshare.com/wiki/Pico-Audio

에서 사양과 해설이 나옵니다. 라이브러리도 제공되네요.

LCD 모듈은 SPI 연결이고 TFT-LCD라고 되어있구요. 스위치가 제공되어 메뉴에서 항목 선택시 해당 기능을 실행하게 하는게 가능합니다. 쥬크박스 메뉴 표시와 선택기로 쓸 것이구요. 라이브러리가 잘 되어 있어서 LCD 구동후 표시한 메뉴에서 스위치문으로 신호를 받아 메뉴가 구현됩니다.

오디오 모듈은 I2C 연결이구요. PCM5101A 디코더가 탑재되어 있습니다. 32비트 384kHz의 사양에 다이나믹 레인지가 106dB이네요. 오디오 모듈 상품에 스피커가 포함되어 있습니다.

둘다 전원은 따로 연결하지 않고 라즈베리파이 피코와 연결된 핀으로 받는 것 같은데 자세한 것은 생략합니다.

우선 PCM 원리를 해설하고 들어가겠습니다.

우리 주변의 소리는 아날로그입니다. 음악소리가 스피커에서 나온다든지, 천둥 소리가 들린다는 것은 아날로그 형태의 음압이 발생해서 사람의 귀로 들어가 뇌가 인식하는 것입니다.

음압을 매질이 진동한다고 보면 파형이 되어 그래프처럼 표현하는게 됩니다.

아날로그 소리는 그래프가 매끄럽게 연결된 상태로 그려지구요. 이를 디지털 기기에서 처리할때는 샘플링이라고 해서 표본값을 얻어내서 좌표에 점찍고 처리가 되는 것으로 유비가 됩니다.

우리가 수학시간에 배웠던 것처럼 그래프를 그릴때 함수값에 따라 얻어진 변화값을 구해서 그래프 용지에 찍고나서 이들을 연결하라고 하죠? 이 연결 전의 점을 얻어내는 변화값 추출이 샘플링이고, 이를 이어주는 것이 고음질로 되는 비법입니다.

진폭을 Y축으로 시간을 X축으로 두고 파형을 그렸을때 1초의 소리 신호를 Y축에 따라 높낮이가 그려지는데요. 이때의 소리 신호를 1초에 몇개의 샘플로 얻어내는지에 의해 그래프가 더 매끄럽게 되듯이 샘플링 레이트가 중요한 사양이 됩니다.

즉 1초에 44100개의 샘플이 가능하면 샘플링 레이트는 44.1kHz가 되고 48000개로 가능하면 48kHz가 되죠. 이는 디지털화되었을때 아날로그값이 손실되는 정도를 줄여주고, 음질도 향상시켜줍니다. 그래서 오디오 CD와 DVD-Audio를 구분하기도 하네요.

이와 함께 몇비트라고 할때는 양자화 단계를 의미합니다. 8비트 양자화가 되면 2의 8승인 256 단계가 가능해지구요. 16비트는 2의 16승, 32비트는 2의 32승이 됩니다. 비트는 두가지 값만 가능하니 전체 가능한 단계가 비트로 표현되면 2의 멱수가 됩니다. 이역시도 비트수가 높아지면 정밀한 파형이 되어 음질이 좋아지게 되죠.

이를 펄스로 다룬다고 해서 pulse구요.

샘플이 취해지고 양자화가 이루어지면 각 샘플에는 이진수가 주어집니다. 16비트라면 0000 0000 0000 0000에서 1111 1111 1111 1111가 가능해지는데 이게 코드(code)입니다.

즉 PCM(pulse code modulation)은 소리를 펄스화해서 코드로 바꾸는 변조라는 의미입니다.

이는 ADC(Analog to Digital Converter)로 자연상태의 소리를 디지털화하게 되구요. DAC(Digital to Analog Converter)를 쓰면 음악파일을 스피커로 출력하는 모듈에 채택이 됩니다. 둘다 가진 모듈이 있고 하나만 가진 모듈도 있는 것 같습니다.

사양적으로 32비트, 384kHz를 제공하는 경우에는 이 전체 사양을 다 만족하는 오디오 데이터라고 해도 늘 이 전체를 다 쓰는건 아니구요. 다이나믹 레인지와 필터링, 인터폴레이션, 밴드 리미트 등의 처리를 해야 되는 알고리즘의 특성상, 사양 그대로보다는 입력 데이터와 처리 알고리즘의 특성에 의해 다 쓰이는 것은 아니죠.

다이나믹 레인지는 보통 6dB 마다 1비트씩 는다고 보면 된다는데, 106dB인 경우 대충 17.6 비트네요.

필터링, 인터폴레이션, 밴드 리미트와 같은 기술은 파형으로 다루는 소리 데이터에 노이즈를 적게 하는 용도로도 쓰이고, 파형 자체를 증폭하거나 커트해야 할 필요에 의해 제정된 기술인데 이게 제작사의 기술력과 관련이 있네요.

PCM5101A 데이터시트에 나온 사양도 이로부터 이해가 됩니다.

일단 이론 공부는 대충 이렇게 해두구요. 조만간 코딩도 해서 올려보겠습니다.

제작사에 문의해보니 제가 구한 제품이 rev2.1이라던데 다시 확인해보니 오리지날 리비전으로 밝혀졌습니다.

rev2.1은 시러스로직의 CS4344를 디코더로 쓰고 오리지날 리비전은 텍사스 인스트루먼트의 PCM5101A를 쓰는데요. 이둘이 거의 같아보여도 후자가 사양이 좋습니다. CS4344는 32비트 192kHz까지 감지가 되는 기종이고 PCM5101A는 32비트 384kHz까지 감지가 되는데요. 다이나믹 레인지가 106dB이니 출력되는 음질은 비슷할 수도 있습니다. 물론 여러 변인이 존재하니까요.

리비전 문제로 인해 며칠 확인작업을 했는데, 전에 쓴 글에 문의를 다시 보낸다고 언급했으나 새로 쓴 글에서 언급을 안해두어 인상이 나빠질 듯하여 추가해둡니다.

Phoronix Test Suite으로 벤치마킹하기

리눅스에서 벤치마크를 할때 여러 프로그램으로 가능합니다. Phoronix Test Suite도 그중의 하나인데요. 이 프로그램을 쓰면 제공되는 여러 테스트들을 활용해서 Processor, System, Network, Disk, OS 등의 카테고리의 벤치마크를 할 수 있습니다.

의존성으로 php-cli, php-xml, php-gd 를 설치하라고 되어있네요.

대충 이명령어로 설치하시구요.

Phoronix Test Suite은 우선 https://github.com/phoronix-test-suite/phoronix-test-suite/releases 에서 릴리즈 파일을 받아서 설치하면 되구요. 리눅스 민트 계열은 deb 파일을 받아서 설치하면 됩니다. deb 파일이 지원되지 않는 리눅스 배포판은 tar.gz 파일을 받아서 압축을 풀고 install-sh 파일을 실행해서 설치하면 됩니다.

지원되는 테스트는

로 확인하면 됩니다.

상세한 정보는

으로 확인하구요.

아래 명령어로 일괄적으로 처리할때 필요한 셋업을 합니다.

아래 명령어로 실재 벤치마크를 실행합니다.

list-tests 로 확인한 테스트명을 입력하면 되구요.

처럼 하면 pts/osbench 테스트가 실행됩니다.

이 작동 방식 외에도 여러 옵션이나 변수 설정, Phoromatic server 사용도 가능합니다.

https://github.com/phoronix-test-suite/phoronix-test-suite/blob/master/documentation/phoronix-test-suite.md

에서 제공되는 PDF 문서를 참조하세요.

IT 기술을 배울때 채택하면 좋은 방법 – 연역과 귀납의 경험적 운용

IT 기술은 그 역사의 흐름과 기술 발전의 흐름에 맞추어 오래전의 기술도 배워야 하고 이후에 바뀐 기술도 배워야 합니다. 이는 기술 이해가 체계적이라 기존의 기술도 알아두면 이후의 기술에 대한 이해가 깊어지기 때문이구요. 기술을 실재 상황에 적용할때 기지를 더 발현하기가 좋게 되서네요.

흔히들 일상언어로 말할때 “다 안다고 자만하지 말고 겸손하게 임해”라는 말도 흡사한 전제인데요. 기초를 배웠을때 다 안다고 생각하는 경우도 있게 되고, 자만하지 않더라도, 기초를 기술하는 개념 몇개만 알고 멈출때보다 더 많이 알려고 하는 의지를 가지게 해주는 말일 것입니다.

물론 해킹이나 과학기술 계통에서 있는 고수가 하수를 대하는 특수한 방법들(흔히 맨스플레인이라고 하는 방법들)을 상기시키는 말이기도 한데, 원칙은 위에서 언급한 공부 태도를 길러주는 방법입니다. 위의 말이 이렇게도 쓰이는 것은 IT도 사람이 하는 분야라, 한 표현에 결부되어 부착된 문화라서이고, 이 이해도 기존의 기술과 이후의 기술을 잘 알아두는 태도에 의해 더 잘 이해가 될 수 있습니다.

이 체현을 위해 생각해볼만한 한가지 정보가 되는 IT 기술 공부법의 노하우를 어떻게 채택하면 좋을지 말해보겠습니다.

어떤 경우, IT도 과학이기에 체계적이기도 하고 논리적인 판단이 일정 부분 적용되는 분야가 IT라, 스키마를 잘 짜두면 판단의 체계에 의해 잘하는 인식으로 안착하기도 합니다. 연역이 가능한 부분이구요. 귀납적인 것을 추가한다면, 실시간으로 작동흐름을 살펴서 판단하는 방법도 있습니다. 그런데 이 경우에 연역이 가능한 부분과 귀납이 가능한 부분을 잘 구별해야 합니다. IT가 수학적이라 연역이 되더라도, 사용이나 경험에 의해 부가되는 분야라, 사용자의 동기나 맥락 등의 영향을 받아 같은 알고리즘도 다른 방식으로 인식될때가 있어서네요.

예를 들면 사이트 지표 측정 도구에서 실재로는 연결이 안느린데, 사이트 속도 지표 점수가 확 낮게 나오는 경우가 있습니다. 이 경우 여러 추측이 가능하지만, 제작 의도에 따라서는 지금 당장은 안느리더라도 사용자가 많아질 것을 예측해서 점검해보게 하려는 일괄적인 권고이기도 하구요. 지켜두면 좋아서 권고하는 경우가 많습니다. 하지만, 실재로는 안느린 조건에서 보면 SEO 적용에 부담이 가기도 해서 스트레스 유발 요인이 되기도 합니다. 다시 말해 제작 의도와 사용 경험이 서로 어긋나는 경우도 상당히 많다는 것이죠. 이는 원칙 하나만 알아서는 안되는 경우입니다. 때로는 제작 의도가 더 말이 되는 경우도 있으나, 둘다 맞는 경우도 있죠. 이는 연역과 귀납의 조화로운 운용이 필요한 경우입니다.

연역은 보통 논리라고 인식됩니다. 전제가 옳으면 결론이 틀릴 수가 없습니다. 이는 프로그래밍 방법론에서 특히 잘 통용되죠. 그런데 귀납적이어야 할때도 있습니다. 하나의 지식만 알고 여러 소프트웨어를 작동시키다보면 체계적이고 논리적이라고 생각했던 판단이 적용이 안될때가 있습니다. 이 경우는 IT 기술은 경험에도 의존하고 있는 체제이고, 고도화된 기술들이라 제작자가 만든대로 작동하기에 단일한 작동방법으로는 작동이 안될때가 상당히 많죠. 다시 말해 작동방법의 경우의 수를 다 알면 좋구요. 소프트웨어마다 다르다는 것을 전제해두어야 당황스러움을 줄일 수 있습니다. 여기서 작동방법의 경우의 수를 다 알아두는 것은 위에 말한 “다 안다고 자만하지 말고 겸손하게 임하는 것”에 의해 가능해집니다.

단순하지만 초심자 시절에는 혼동되는 것은 어떤 경우는 마우스 한번클릭으로 작동하고 다른 경우는 두번클릭으로 작동할때가 있고, 휠을 돌리면 스크롤되는 깊이를 조정한다든지, 맥에서는 휠을 올리면 스크롤이 내려가는 등등의 구별점도 관련 현상이구요. 대부분의 경우 이를 미리 안말해줘도 고려하는 능력들이 다 있는데, 특수한 경우 단일한 경우만 상정하는 경우도 있어서 당황하기도 하네요. 경험이 중요하구요. 어떤 경우 타과학하신 분들 중에서는 과학의 일양성에 대한 인식을 IT에다가도 적용하시고 어려운 것부터 보시기도 하는데, 활용법은 쉽게 알 수 있어도 기술적인 것이나 원리는 기초부터 배워야 합니다. (부끄러우시면 집에서 몰래 보면 됩니다 (?)) 고도화되어 기술들이 겹쳐지고 발전하면 이해도 꽤 어려워지구요. 논리나 체계도 중요한데, 문제 해결에 있어서는 경험이 중요하죠.

UEFI 펌웨어의 경우에도 BIOS 시절의 지식을 알면 시스템 고장의 원인을 알게 되는 진입로가 되는데요. 이 경우에도 기존의 지식과 새로운 지식을 융합해서 이해하려는게 중요합니다. 시스템 리저브드 파티션이나 NVRAM 등에 대한 인식이 가능했다면 잘하는 것입니다. 이에 대해서는 직접 살펴보세요. 이 기술들은 PC 고장과도 관련이 있어서 하나만 알아도 아주 기분이 확 살아나는 지식인데, 이 경우에도 정말 많은 것이 더 배움을 기다리고 있는 경우입니다.

그래서 초심자 시절에는 개념을 확실하게 잡기 위해 이미 정해진 표준 언어로 사태를 기술한 표현으로 배우되, 표현의 의미보다는 표현의 연관을 살피는게 요령입니다. 프로그래밍을 할때 IDE가 표시한 오류에 의미만을 생각하면 문제가 있는 라인으로 가봐도 문법적인 오류가 없는 경우가 있구요. 이 경우에는 오류 메시지의 표현의 의미보다는 표현이 지시하는 연합된 원리를 떠올려보려고 노력하면 좋습니다. 이것을 초심자 시절에는 어렵다고 하는 것은 실력이나 자격 문제라기보다 경험이 없어서인데, 요즘은 비전공자분들에게도 친절하게 원리를 알려주는 문헌과 인터넷 자료가 많으니 보시길요.

한 현상에 대해 잘 알려진 규칙만이 정답이 아님을 아는 것도 좋습니다. 보통 이상 현상은 잘 알려진 규칙을 비틀고 얽히게 해서 일어나니까요.

인터넷이 안된다고 하면 보통 네트워크 장치 리셋이나 라우터를 보라고 하는데 이 경우에도 경험이 많아지면 그이상도 보게 될 수 있습니다. 라우터 펌웨어가 변조되었다든지, 운영체제의 ARP 문제라든지, 네트워크 구동 소프트웨어에 유저권한이 바뀌었다든지, 파일이 리패키징된 등등의 가능성을 알려고 하는 진입점도 이 글에서 말하는 태도를 잘 알면 가능하구요. 전공이 아닌 분야더라도 문제 원인만큼은 잘 알게 되어 질문이나 수리 요청도 아주 잘하는 실력 향상으로 이어질 수 있습니다.

잘 해설받은 루트가 중요합니다. 요즘은 큰 업체에서는 자기들 사이트에 문서들을 공유하는데 이를 참고하시구요. IT적인 글은 개념을 떠올려야 하는 부분과, 써본 경험에 의해 사용과정을 떠올려보는 부분을 잘 구별할줄 알면 잘하시는 것입니다.

보통 신계급 또는 위자드리라는 칭찬도 받는 분들이 계시는데 그분들도 이글에서 말한 연역과 귀납을 잘 운용해서일 것입니다. 일단 이렇게 해설해둡니다.

아주 오래된 기술이 지원에서 해제되는 이유

전산학은 프로그램과 하드웨어 개발이 주로 이루어지는 분야입니다. 많은 경우 기술이 발전되면 성능이 개선되고 버그도 잡히는 것이 기대되죠. 때로는 버전업이 될때 오래전의 기술이 지원 해제가 되기도 합니다. 어떤 경우 그 기능 자체가 없어지고 다른 기술로 대체되기도 하구요. 하위 호환성을 위해 지속되더라도 실재 제작시에는 사용을 권장하지 않는 공지를 합니다.

이를 풀어서 설명하자면 이렇습니다.

보안이 문제인 경우
오래된 표준으로 만든 기술은 시간이 지나면 지원에서 해제됩니다. 리얼오디오나 어도비 플래시가 그 예죠. 이 경우 시장에서 완전히 사라진 기술이라, 오픈소스 개발자 같은 분들이 호환되는 기술을 개발하지 않는다면 영원히 안쓰게 될 것입니다. 이 경우 오래전에 제작된 웹페이지를 볼때 적절하게 표시가 안될 것입니다.

이 경우 기능을 그대로 두었을때 보안이 취약하게 되는 공격이 가능해질 수 있는데 기술 지원을 끊으면 사용자 컴퓨터가 악의적인 공격에 놓이게 되서 기능 자체를 단종시키는 경우네요. 이런 경우 유예 기간을 두어 점차적으로 다른 대체 기능으로 옮겨가게 합니다. 특히 기업에서 도입한 기술이 단종될때 이렇습니다.

제작사가 유지보수를 할 의지가 있더라도 성능 저하 등의 이유로 사용을 비권장하는 경우
이경우 하위 호환성을 위해 지원은 해주지만 해당 기술을 써서 제작하는 하드웨어나 소프트웨어에 해당 기술을 적용하는 것을 비권장하는 경우입니다. 이 경우 오래전에 만들어진 기능은 작동이 되지만, 때로는 오래되어 지원이 끊긴 기술임을 실행시 보여주기도 하죠.

이 경우에도 어쩔 수 없이 해당 기술을 써야 한다면 말리는게 불가능하지만, 지켜주는게 좋습니다.

프로그램을 만들때 제작사에서 제공하는 API에서 비권장하는 코드는 deprecated라고 하고, 완전하게 없애는 코드는 obsolete이라고 합니다. 이 두가지 코드는 프로그램 제작시 안쓰는 것이 좋습니다. 대체 기능을 찾아봐야죠.

기술자들의 여론이 보안에 아주 나쁘다고 해서 이 의견을 받아들인 경우
잘 아시는 ActiveX와 같은 기술이 예 같애요. ActiveX는 웹페이지에서 사용자 PC에 설정을 바꾸거나 작동을 일으키게 할 수 있는데 이게 보안이 취약해지는 이유가 됩니다. 그런데도 탁상행정으로 이 기술을 표준으로 되게 해서 기술자들이 외국 사정과 비교를 많이 해왔던 기술로, 마이크로소프트에서 IE를 단종하던 시절과 비슷한 시기에 단종했습니다.

이 경우에 이미 존재하던 ActiveX로 만든 기능에 세대 교체를 대처하려면 은행 같은 기업은 편리한데, SOHO 같은 경우 비용부담이 있게 되죠. 이 경우에도 단종을 해야 하나 말아냐 하나에 기술적인 원인 외에 사회경제적인 원인이 복합되기도 합니다.

우연하게 일어난 결함이 기술 자체를 비신뢰 대상으로 한 경우
USB 3.2 Gen 2×2에 대해 알게된적이 있는데 이게 특수한 경우인지 아니면 전면화된 경우인지는 모르지만 OS 업데이트나 개인 PC 특성에 의해 USB 포트가 작동을 안할때 이게 알려져서 논란이 되는 경우도 있습니다. 그러면 하드웨어 제작사에서도 헷갈리게 되고 이를 책임감으로 연구하지 않으면 안되고, 잘 알려지지도 않는다면 그 기술이 도태되기도 합니다. 문제가 퍼트려지면 전체 문제처럼 되죠.

이 경우 실재로는 특수한 문제인데, 기술이 도태되는 원인이 되기도 합니다.

시장 상황이 여론이 일으켜져서 단종 수순인데 업체측에서 비용을 들여가면서 연구해서 잘 된다고 하기도 애매한 경우 더 그렇죠. 연구해서 알려지게 해도 이미 시장 상황이 단종을 바라면 이역시도 우연하게 알려진 결함이 단종하게 하는 경우입니다.

이 정도로 특정적으로 해설해봅니다. 알아두시면 대처력이나 판단력도 확장되실 것입니다. 이 조건들을 잘 알면 좋네요.

암달의 법칙, 구스타프슨의 법칙, 리틀의 법칙

무어의 법칙이 프로세서 성능 향상의 주기를 논의했다면 단일 프로세서의 클락 속도 향상만으로는 발열 문제나 여러 다른 원인들이 겹쳐서 성능 향상이 불가능해졌다.

하나의 CPU 다이 안에 여러 개의 코어를 두고 처리하는 방안이 대안으로 유력하다. 그러나 이 경우에도 프로세서의 처리 속도와 타부품들의 처리 속도, 프로그램의 성능 등의 요인으로 인해 프로세서 코어를 늘린만큼 배수가 되지 않고 병목현상이 있게 된 만큼은 손실되어 성능 향상이 있게 된다.

이를 공식으로 만들어 각각의 시스템 별로 다른 상태를 반영하기 위해 암달의 법칙 공식이 개발되었다.

속도 향상  = 1 / [(1 – S)+S/P]

로 나타내고 S는 병렬화되어 처리되어 전체 작업에서 차지하는 값을 나타낸다. P는 프로세서의 개수 (또는 코어 수)다.

만약 부동 소수점 연산 시간이 전체 실행 시간의 50%를 차지하는 프로그램이 있었을때 프로세서의 연산장치를 2배로 늘리면 전체 성능 향상은 1/[(1-0.5)+0.5/2]=1.33이 되어 프로세서가 2배 빨라져도 성능 향상은 1.33배다.

프로그램의 실행을 2배 빠르게 하려면 2=1/[(1-0.5)+0.5/P]가 되고 0.5/P=0이어야 하므로 P=무한대다. 그래서 50%의 부하가 걸리는 경우 부동 소수점 연산을 위해 하드웨어에 투자하더라도 전체 성능은 2배가 안된다. (여기까지는 책의 예제)

이에 대해 1988년에 구스타프슨이 다른 유형의 법칙을 만들었는데 프로세서 수가 늘어나면 선형적으로 성능이 향상될 수 있다는 법칙이다. 이 법칙과 암달의 법칙은 시스템 성능 향상에 대한 아이디어를 제시해서 잘 알려져 있다.

암달의 법칙이 프로세서를 아무리 많이 병렬화하더라도 어느 시점이 되면 성능향상이 없는 한계가 있음을 말하는 법칙이라면 이를 비관적인 것으로 보고 효과적으로 병렬화하는 것이 가능하다는 법칙은 구스타프슨의 법칙이다.

이론상 성능 향상 비율 = P – n(P – 1)

이 공식에서 P는 프로세서의 개수, n은 병렬화되지 않은 부분의 비율이다. 이 공식으로 알 수 있는 사실은 동일한 시간에 처리 가능한 최대 처리율을 가리키고 암달의 법칙과 대비된다. 암달의 법칙은 실행 시간의 감소에 초점을 두었다면 구스타프슨의 경우 처리율에 초점을 두었다.

암달의 법칙에 의하면 프로세서 코어를 아무리 많이 늘려도 성능 향상폭은 제한적이다. 그러나 프로세서 제작 알고리즘이 고도화된 시대로 오면 성능 향상폭이 클 수 있다. 병렬화안된 부분이 전체 프로세스의 50%이고 코어가 32개 투입되면 16.5배의 데이터를 처리하게 된다.

성능 측정 공식으로 또하나 중요한 공식은 리틀의 법칙이라고 불리우는 공식이다. 본래 경영학에서 쓰이던 공식이지만 그 응용의 하나로 컴퓨터 공학에서 하드웨어 성능 측정이나 소프트웨어의 처리 속도 개선에도 쓰이게 된 공식이다.

리틀의 법칙은 통계적으로 안정 상태의 체제에 적용이 가능하다. 안정 상태이므로 대상이 정상적으로 균일하게 입출됨을 의미한다. 시간당 동시처리되는 요청 개수가 L이고 n은 전체 스레드의 평균 처리 개수이고 W는 평균 응답시간일때 리틀의 법칙은 아래처럼 된다.

L = nW

이 경우 단순화된 공식이지만 대기열에서 작동하는 하드웨어나 소프트웨어의 처리에 소요되는 응답시간과 같은 지표를 간단하게 예측할 수 있어 주목을 받았다. 성능 측정시에 하드웨어를 빠르게 하거나 소프트웨어의 실행을 빠르게 하는 경우 리틀의 법칙으로 대략 예측하여 성능 개선에 쓸 수 있다.

예를 들면 n이 25개, W가 100ms라면 250개의 처리가 1초에 동시에 된다.

마이크로프로세서의 성능 개선에 대한 노트

오늘 머리가 맹맹한게 개선되어 컴공 교과서를 더 읽었습니다. 노트를 남긴 것을 올립니다. 교과서에 나온 흐름을 참고해서 제 표현도 고안해서 해놨는데 몇 대목은 요약적입니다.


컴퓨터와 전자기기의 성능은 마이크로프로세서의 성능에 일차적으로 의존적입니다. 주변기기나 부품들의 성능도 중요하지만, 일단 중심이 되는 마이크로프로세서이기에 마이크로프로세서의 성능 개선이 전체 실행 속도의 개선에 중요한 구심점이 되는 것입니다.

요즘은 제작단가도 낮아지고 있어서 일회용으로 쓰고 버리는 마이크로프로세서도 있다고 하구요. 기술의 혁신이 가져온 시장인데, 제작단가는 낮추고 성능은 향상시키는 것입니다.

성능 향상은 명령어 인출과 저장, 실행, 버스와 캐시, 버퍼등의 하드웨어적 이점 등에 영향을 받습니다. 명령어를 한번에 많이 보내고 병렬로 처리하는 등의 단순해보이는 작업은 이들 구성요소들을 얼마나 효율적으로 분배하느냐에 따라 결정이 됩니다.

성능좋은 프로세서의 효용은 아래와 같습니다.

영상처리
3차원 렌더링
음성 인식
화상회의
멀티미디어 오소링
파일에 첨부되는 음성과 영상 실행
시뮬레이션 모델링

이들이 현재의 데스크탑 PC에서도 가능하게 프로세서 기능이 진화된 세상입니다. 속도와 성능은 대폭 개선되었지만, 오늘날의 컴퓨팅 기술은 폰노이만 형태의 IAS 컴퓨터와 구성요소 블록이 흡사합니다. 즉 조직은 이어져오는면이 있는데 이는 구조적으로 어떻게 성능이 결정되는지의 결정도 되죠. 예를 들면 마이크로프로세서가 나노세컨드로도 작동할때 보조기억장치는 1초에 80MB만 읽어들이면 병목현상이 있게 되고 이를 효과적으로 처리하는 기술들이 관건이 됩니다.

현대 프로세서들은 성장이 발전해서 여러 하드웨어적인 구조상으로 성능 향상을 주는 구현을 합니다. 아래와 같은 기술들이 우선 이해되면 좋습니다.

파이프라이닝(pipelining) – 명령어의 실행 단계를 여러개로 나누어 병렬로 실행하는 기술입니다. 여러개의 명령어를 동시에 서로 다른 단계에 실행해서 다수의 명령어를 동시에 실행합니다. 처리의 예를 들면 버퍼링을 하면서 영상의 디코더를 실행하는 것과 같은 연산을 할때 명령어로 읽어들이면서 다른 명령어를 해독하고 있으면 각각의 단계가 병렬로 실행되면서 프로세서가 바쁘게 돌아가는 작동이 되어 작업처리 속도가 빨라집니다. 이 각각의 단계는 파이프라인이라고 불리우며 이는 개념적으로 나타낸 도식의 각 단계로 유비됩니다. 인텔의 x86 계열 CPU는 파이프라인을 늘려서 처리속도 개선을 해왔는데, 각각의 파이프라인이 100개이고 4000MHz의 클럭속도일때, 각각의 파이프라인에 40MHz의 클록이 배정되게 작동합니다. 그러나 파이프라인을 너무 크게 설비하면 발열등의 현상으로 인해 성능외적인 문제가 있게 되어 요즘은 파이프라인을 적당히 설비하고 코어수를 늘려서 해결하는 방안이 널리 쓰입니다.

분기예측(branch prediction) – 프로세서는 알고리즘 설계를 토대로 소프트웨어의 작동을 미리 살펴보고 어떤 분기를 실행하여 명령어 집합이 다음에 처리될지 예측합니다. 명령어 집합을 미리 인출해서 버퍼에 저장하고 병렬처리를 합니다. 이 알고리즘을 고도화하면 이후에 나타날 여러 분기가 모두 예측될 수 있고 결국 효율이 높아집니다. 이는 잠재적으로 프로세서가 수행할 일의 양을 증가시켜 유후상태를 방지합니다. 그러면 작업 처리 속도도 증가합니다.

슈퍼스칼라 실행(superscalar execution) – 프로세서의 클럭 사이클마다 한개 이상의 명령어를 발송해서 여러개의 병렬처리가 가능해집니다.

데이터 흐름 분석(data flow analysis) – 명령어 사이의 결과값이나 데이터 의존성을 분석하여 최적의 실행 조건을 찾아냅니다. 프로그램 실행 순서를 너무 고지식하게 처리하기보다 준비되는 즉시 실행되도록 하여 지연을 줄여줍니다.

추정실행(speculative execution) – 분기 예측과 데이터 흐름 분석을 이용하는 경우, 명령어들이 실행되는 것을 결정하여 결과값을 임시 장소에 저장합니다. 이렇게 하면 필요한 것으로 예측되는 명령어들을 미리 실행함으로써 하드웨어를 가능한 한 바쁘게 만듭니다. 발열은 늘어나겠으나 처리속도가 개선됩니다.


프로세서의 속도가 무척이나 빨라져서 단순 지표로 40억개의 연산이 1초에 되기도 하고 놀라운 성능을 낸다. 하지만 컴퓨터의 속도는 프로세서만 빨라서는 안되고 타주변기기가 부품들의 속도가 지지되어야 향상이 가능하다. 프로세서의 속도와 주요 부품들의 속도를 최대한 맞추어주는 것을 성능 균형이라고 하고 다양한 부품이나 구성 요소들의 성능 불일치를 개선하는 것이 기술 개발의 한 주목 지점이다.

프로세서와 주기억장치 간의 인터페이스 기술
프로세서와 보조기억장치 간의 인터페이스 기술
그외 조합들

이 관건이다.

주기억장치는 x86 계열의 데스크탑용을 생각해보면 DDR 기술과 레이턴시가 그 지표가 된다. 레이턴시는 나노초 단위지만, 프로세서와 연동시 버스를 거쳐야 하므로 프로세서 내부의 캐시나 버퍼링보다는 통신이 오래 걸리는 편일 것이다. 3차원 모델링 표시들이 그 예가 된다. 이 경우 그래픽 카드 내에 램을 따로 달아 해결하기도 할 것이다. 모든 작업을 프로세서와 주기억장치의 통신으로만 해결하지 않고 해결하는 방법은 많다.

중요한 것은 기억장치들의 독립적인 성능향상도 그렇하지만 이들끼리의 통신을 얼마나 짧은 거리에서 얼마나 빠른 버스로 처리할지의 여부다. 상식적으로는 더 깊게 하는게 일반적이지만 때로는 더 넓게 해서 한번에 인출하는 개수를 높히기도 한다. DRAM을 칩상의 캐시나 버퍼링으로 포함하기도 한다. 프로세서 내부에도 캐시가 들어가고 외부에 두는 등의 선택지도 있다. 버스를 계층화하기도 한다.

설계적으로 입출력 장치들의 입출력 요구율과 입출력 처리율을 조정한다. 기술발전이 이루어져도 다양한 기술 대상에 대한 성능 변화는 얽혀있어서 이를 정리하고 균형을 맞추는게 중요하다.

마이크로프로세서의 성능 개선은 성능 균형을 고려하고 성능 불일치를 해결하는 것이다.

칩 조직과 구조 개선

성능 개선은 몇가지 기술적인 패턴이 있다.

프로세서 자체의 하드웨어 속도 개선 – 칩상의 논리게이트 수 감소와 동시에 더 많은 게이트를 조밀하게 배치.
프로세서와 주기억장치 사이의 속도 개선 – 캐시 크기와 속도 개선. 프로세서 내부에 위치시키도록 조정.
프로세서 아키텍처 개선 – 명령어 처리나 병렬성 개선.

대표적인 패턴은 클럭 속도 향상, 회로 밀도 증가다. 그러나 이 둘의 고도화가 진행될 수록 단점도 있게 된다.

전력 밀도가 높아진다. 발열과 쿨링 문제가 따라온다.
RC 지연이 된다. RC곱이 증가할때마다 지연도 길어진다. 칩상의 부품이 미세해질수록 저항이 증가하고, 더 가까이 위치할수록 커패시턴스도 증가한다.
기억장치 지연과 처리율 미비. 프로세서보다 느린 경우가 많다.

해결법은

칩상에 캐시 메모리의 배치를 늘린다
병렬처리를 위해 프로세서의 명령어 실행 회로를 고도화한다
많은 수의 트랜지스터를 직접하는 효율적 방법을 찾는다

이러한 것이 대표적인 설계에서의 성능 균형 맞추는 기법의 일단이다.

안드로이드 기기에서 이어폰 소리가 한쪽에서만 나는 문제

보통 이어폰을 막 굴리면서 가지고 다니면 단선이 됩니다. 이 경우 선이 완전히 끊어진게 아니면 소리 재생시 선을 위아래로 움직여보면 양쪽에서 소리가 납니다. 이 경우 완전 단선 위험도 있는데요.

PC나 다른 기기에 이어폰을 옮겨서 들어도 같으면 일단은 이어폰 문제 같지만, 최악의 경우 시스템 파일 변조나 기타 같은 효과의 원인도 있을 수 있습니다. 이 경우 이어폰을 바꿔서 연결해보면 되는데 이 경우에도 잘 되다가 다시 안되기도 하네요.

제 경우 이렇게 하니 복구가 됩니다.

(1) 재생되는 소리를 잠시 멈춘다. (유튜브 영상을 끄는 등의 작업)
(2) 설정에서 초기화 메뉴로 들어가 접근성 초기화를 실행한다.
(3) 다시 소리를 재생한다.

이외에도 접근성 메뉴에 있는 (위 접근성 초기화 메뉴와 다름) 청각보조 메뉴에서 (삼성의 경우입니다) 좌우 소리 균형 항목이나 모노 오디오 항목 등을 살펴보고 조정해서 되면 될 수 있네요.

저는 일단 (1)부터 (3)까지 하니 되었습니다. 중요한 것은 접근성 초기화하기전에 소리 재생을 멈추고 초기화후 다시 재생하는 것인데 메모리 상태와 연관이 있어보입니다. 시스템 파일 변조도 그렇구요. 모종의 이유로 이렇게 될 수도 있는 것 같습니다.

DAC와 ADC – 디지털화에 대한 이해

현실 세계에서 존재하는 물리량들은 아날로그적입니다. 아날로그라 함은 다시 말해 날 것 그대로의 자연적인 현상이라는 것입니다. 예를 들면 바람의 추운 정도, 열로 나타낼 수 있는 온도, 소리를 내는 음파와 같은 것입니다. 이 아날로그적인 자연 현상을 전자기기에서 의미있게 다루려면 전기적인 신호로 바꾸어야 합니다. 이 과정을 디지털화한다라고 설명합니다.

보통 센서라고 부르는 장비를 써서 아날로그적인 자연 현상을 전자기기에서 다룰 수 있는 데이터로 바꾸어야 하는데요. 여기에 DAC나 ADC가 관여합니다. DAC는 디지털에서 아날로그로 바꾸는 작업이고, ADC는 아날로그에서 디지털로 바꾸는 작업입니다.

흔히 말하는 이산 처리 과정인데요. 자연 현상을 측정한 데이터는 그래프로 보이면 연속적입니다. 주욱 이어지는 데이터의 흐름이죠. 그러나 전자기기는 처리할 수 있는 한도가 있기에 이를 변환하면 수치마다 딱딱 떨어져 있는 형태가 됩니다. 1부터 100까지로 나타난 아날로그 현상을 그래프로 그리면 특정 구간에서 보여지는 값들은 무한히 많은데요. 1부터 2까지에 1.00001, 1.00002, 1.00003, .. 1.000010, … 등으로 매우 촘촘합니다. 그러나 전자기기 내부 작동의 한도에서 이를 최대한 근사치로 변환해서 처리하는데 이를 가리켜 디지털화한다(digit-ization)이라고 하죠. 보통 정수형으로 변환한다고 설명합니다. 근사치지만, 고교시절 그래프를 그리듯이 대략적인 형태는 지속되기에 자연 상태의 데이터를 전자기기에서 다룰 수 있다고 간주하고 처리하는 것입니다.

전자기기의 작동은 기저에서 보면 두가지 작동으로 환원된다고 합니다. 전류가 인가되었음, 전류가 차단됨 이 두가지 상태입니다. 이를 0과 1 또는 1과 0 등으로 규정해서 데이터를 다루죠. 이 체제 내에서 정수도 표현하고 부동 소수도 표현합니다. 이 과정은 MCU의 비트수나 DAC, ADC의 샘플링 정확도에 의해 품질이 결정되는데요. MP3와 같이 44.1kHz, 128kbps 처럼 표시되는 것이 샘플링 정확도로, 소리를 그래프로 나타냈을때 근사치인 숫자로 변환시 얼마나 정밀한지 보는 척도입니다. 위에 말한 1부터 2까지 사이의 값들이 얼마나 촘촘한지를 의미합니다. 44.1kHz 128kbps보다 48kHz 128kbps가 음질이 더 좋다는 것도, 특정 구간의 그래프를 구성하는 숫자 샘플이 더 정밀하다는 것이구요. MCU 비트수와 DAC, ADC 회로의 성능도 결정 조건이 됩니다. 소프트웨어적인 API의 성능도 관건이구요.

이로부터 전자기기가 재현하는 온도 측정의 정확도, 소리 재생의 음질 등이 기술적으로 결정됩니다.

응용 분야는 영상 신호 처리, 음성 신호 처리, 온도 측정 등등으로 심화되죠.

최대한 전자기기가 알아볼 수 있는 근사치로 나타내면서도 원본 아날로그 값과 오차가 적게 하는 것이 디지털화 기술의 성패입니다. 이를 처리하는 것은 회로의 고도화와 처리 알고리즘의 고도화에 의지합니다.

알고 있는 사실을 요약적으로 해설해서 저보다 초보이신 분들께도 이해가 즉시되는 해설은 아니지만 ^^;; 일단 이해는 되실 것입니다. 위에 샘플된 각 수치들이 그래프로 그려져서 그래프 성분들의 복잡도가 단순화되는 것을 시각적으로 보이면 더 와닿는 해설이 되는데 그림판 열기가 싫어서 생략합니다.

라즈베리파이 피코로 구성하는 MP3 재생기도 DAC로 만듭니다. 이진화된 (디지털화된) MP3 음악파일을 읽어들여서 아날로그인 스피커 소리로 내보내는데 중요한 장치입니다.

일단 이정도로 생각난 것을 정리해두겠습니다. 요즘 생계지속용 공부하느라 공학공부는 재껴두었는데 그래도 틈틈히 라즈베리파이 피코 배우는 중입니다. 교재보다가 전에 배운 것이 생각나서 글로 썼는데 아주 대단한 글은 아니지만 일단은 개념 정리는 되었네요. 저를 위해 게시판도 따로 만들어주셔서 회원님들을 존경하고 있습니다. 열심히 하겠습니다.