Zarovnani v LPC11U68

[Miroslav Mraz]

Na dané architektuře tím nic neušetříte. Cortex-M0+ prostě unaligned 
access neumí, takže ať to budete dělat jak chcete, tak se to bude 
kopírovat byte po byte. Neuvádíte co používáte za překladač, 
předpokládám gcc, který to co chcete před pár léty ještě neuměl, nyní by 
s tím už problém být neměl. Mám testovací funkci

const  uint8_t  pole[] = {1,2,3,4,5,6,7,8};
static uint32_t gi;

void test (void) {
   uint8_t const* ptr = pole;
   ptr += 1; // dáme si tam lichou adresu
   gi = *(uint32_t*) ptr;
   prn << gi << EOL;
}
která pro gcc 4.7.2 skončila tak jak vy uvádíte hard fault, ve verzi 
4.9.3 už správně vypíše 0x05040302. Lze si pohrát s přepínači
-munaligned-access
-mno-unaligned-access
viz. https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
ale pro Cortex-M0(+) -munaligned-access skončí (logicky) varováním
x.c:1:0: warning: target CPU does not support unaligned accesses
přičemž překlad proběhne úplně stejně. Nehledě na to, že takové 
přetypování je dost nečistá praktika, stejně probíhá kopírování byte po 
bytu, protože to jinak nejde. Koukněte, co překladač vyplodí za asm kód.
Pokud opravdu chcete šetřit čas při kopírování dostatečně dlouhých bloků 
dat, použijte funkci memcpy(), ta by měla být napsána inteligentně tak, 
aby si s tím poradila. Pro 3 byty je to ovšem zbytečné.

Mrazík

Dne 10.7.2016 v 13:28 Pavel Hudecek napsal(a):
> Pak vzniká problém, kde získat zarovnané fonty. Tenhle má prostě 3 B na
> řádek. Vygeneroval jsem ho v LCD vision.
>
> Cílem je šetřit RAM a čas. Je to tedy nadeklarováno jako const, takže je
> ve flash. A čas chci šetřit tak, že celý řádek se použije jako B, word,
> dword, nebo qword, podle počtu B v řádku. A dost nerad bych je při změně
> fontu kopíroval do RAM, je jí jen 36 kB a font pak může zabrat i přes
> půlku. V nejhorším tedy změním přístup na B a budou 2 fory v sobě.
>
> PH
>