 STM32F411/196; 128x128 픽셀 1676;리 oled를 가1648;고 놀고 1080;lj16;데요.
 메모리에 프/112;1076; 버6140;를 .160;고 ᄸ1;신한 다1020; 통1704;/196; 올리lj16; 식1004;/196; Ǹ16;고 1080;습니다..
 한 프/112;1076; 올리고 나서 다시 버6140;를 1204;ǥ12; 01004;/196; ᄸ1;신Ȣ16;고 다1020; 프/112;1076;1012; 올리lj16; 식1004;/196;요.
 그런데 memset() 1060; 너무 오래 ,152;리더라고요...
 그래서 memset() Ȣ16;lj16; ᇼ1;안 다른,144; 라도 Ȣ16;/140;고 DMA memory to memory 기능1004;/196; 수행Ȣ16;도/197; 만들었습니다.
 1060;/111;,172; Ȣ16;면 CPUlj16; 다른 ,152; 돌릴 수 1080;1004;니까요..
 근데 CPU/196; memset()1012; 했1012;ǐ12; 12ms ,152;리Nj12;,172;... DMA 올/140; 놓고 완료 .112; ǐ12;까1648; ,152;리lj16; 시간1012; 1116; 봤더니 2ms 0150;에 안 ,152;립니다!
 1060;,144; 원래 1060;런 ,148;가요? 
 뭔가 1228;가 최1201;화 .104;1648; 않1008; 1096;못.108; memset() 1012; 참1312;Ȣ16;고 1080;lj16;,152;까요??
 큐브mx가 생성한 프/196;1229;트에 아.160;1060;노용 그래픽 라1060;브러리를 땡겨와서 Ǹ16;고 1080;습니다...
그리고 아두이노용 라이브러리는 다른 mcu에서 잘 안돌아가는 수가 많습니다. 최적화가 목적이 아니고 범용성과 간편한 사용이 목적입니다.
원래 빠른게 당연했군요..
memset 자체가 원래 DMA를 쓰지 않고 CPU를 통해 메모리를 복사합니다.
DMA는 개발자가 직접 써야 하기 때문에 직접 세팅해주셔야 합니다.
일을 사람의 관점에서 이해하면 0으로 체우라고 시키는건 어디서 구지 000000을 복사해서 거기 붙여 넣는것 보다 빠르게 만들 수 있을것 같기도 하고 그레서요..
memset가 자기맘대로 DMA Ch0을 쓴다고 하면 개발자가 DMA Ch0을 써야 하는 경우에 못쓰게 되는거죠.
그리고 DMA 채널마다 사용할 수 있는 메모리 영역(페리페럴)이 다르기도 하구요.
https://m.cafe.naver.com/ca-fe/web/cafes/10750951/articles/311600
참고해 보세요~
이 메모리 IO라는건 CPU의 처리 성능에도 직결되는 문제니까.. CPU 코어 쪽에서도 최선을 다해서 강화 할태고
그럼 결국 겯다리로 붙은 코 프로세서 격 장치 보다는 묵직한 코어가 더 빨리 처리하지 않을까 하는 그런 이미지가 있어서요...
실상은 그냥 같은 클럭으로 접근하니 오버해드가 적은 전용 구조가 더 빠른가 보네요.. 쩝...
밑바닥 까지 들여다 보기는 너무 햄들겠다 싶어서요...