問題を少し紹介し
ます。これを投稿する前に google/stack で検索してみましたが、ほとんどが不明でした。
ベアメタル RTOS を実行している cortex-a8 ベースのボードがあります。ディスプレイ (フレームバッファ) は少し遅いです。これは、現在ターゲットに DMA を実装していないためですが、それほど遅くはないことに気付きました。改善の機会。私の CPU とツールチェーンの組み合わせでは、32 ビット演算、データ アクセスは 16 ビット アクセスよりも高速で、ディスプレイは 16 ビット rgb565 であるため、一部のフレーム バッファ操作は本来よりも少し遅くなります (一部は memcpy、memmove を使用します)。そして、データの整列などを処理する memset .)
私が試みたのは、2 つのピクセルを 1 つの 32 ビット データ型に詰め込み、それを使用してメモリにアクセスすることでした (覚えている限り、整列していなくても、私の CPU はハードウェアで整列されていないメモリ アクセスをサポートしているため、問題はこれではないはずです)。私は実装の速度について話しているのではなく、2つのピクセルを1つの32ビットデータ型に詰め込んでいると思われる奇妙な効果があることに注意してください。
ここに私の fb_putc のほとんどの部分があります
if (((unsigned char)c > 32) && ((unsigned char) c < 127)) {
check_for_scroll(49);
// fontdata starts from ASCII 33 shifted by logarithm(base2, font_height)
c -= 33;
c <<= 4;
uint16_t pallete_16[2] = {fb.fg_color, fb.tg_color};
uint32_t y;
uint32_t *pixel_32;
uint32_t fb_shifter;
uint32_t pixel_32_holder;
uint32_t fb_bg_32 = ((pallete_16[1] << 16) | (pallete_16[1]));
/*
* Each pixel is 16 bits, we access them using 32 bit data type,
* which is faster for aligned memory access. Also many architectures
* have free bit shifts with each instruction so we use that too.
*/
pixel_32 = (uint32_t *) fb.config->base;
pixel_32 += ( ((fb.cursor.y * (FONT_HEIGHT * fb.config->width)) + ((fb.cursor.x * (FONT_WIDTH))))
/ ((sizeof(uint32_t))/(sizeof(uint16_t))) );
for (y = 0; y < 16; y++) {
for ( unsigned x = 7; x >= 0; x -= 2 )
{
if (fontdata[c + y] & (1 << x)) {
pixel_32_holder = (pallete_16[0] << 16);
} else {
pixel_32_holder = (pallete_16[1] << 16);
}
if (fontdata[c + y] & (1 << (x -1))) {
pixel_32_holder |= (pallete_16[0] & 0xffff);
} else {
pixel_32_holder |= (pallete_16[1] & 0xffff);
}
*pixel_32++ = pixel_32_holder;
}
// Panel stride = width (480) - font_width (8)
pixel_32 += (472 / ((sizeof(uint32_t))/(sizeof(uint16_t))));
}
fb.cursor.x++;
}
私が間違った場所に関する助けはありますか？私はプログラミングに少し慣れておらず、これを趣味としてやっています。