.. vim: noexpandtab fileencoding=utf-8 nomodified wrap textwidth=270 foldmethod=marker foldmarker={{{,}}} foldcolumn=4 ruler showcmd lcs=tab\:|- list tabstop=8 noexpandtab nosmarttab softtabstop=0 shiftwidth=0 :date: 2024.01.09 20:04:48 :_modified: 1970.01.01 00:00:00 :tags: SW,Arduino :authors: Gilhad :summary: SpeedTestPgm_v.0.1 :title: SpeedTestPgm_v.0.1 :nice_title: |logo| %title% |logo| %HEADER% SpeedTestPgm_v.0.1 -------------------------------------------------------------------------------- Tl;dr; - Jak je rychlá práce s řetězci v paměti, versus v PROGMEM (F-makro)? - Mě to vyšlo celkem nastejno, kdo chce, může si to překontrolovat či upravit po svém. Brzdit by se to nijak výrazně nemělo, co jsem koukal do poznámek v knihovnách Arduina, tak PROGMEM (a F-makro) se od normální verze liší naprosto nepatrně. Ale šedivá je teorie, zelený strom života, tak jsem si zkusil udělat testy na Arduino Mega (protože to používáš ty) a vyšlo mi, že je to v podstatě stejné, ale co zdržuje jsou výpisy přez Serial. Příklad jsem se pokusil udělat tak, aby do toho nemohl překladač moc optimalizovat (proto ty volatile, jinak to normálně sečetl a vložil rovnou výsledek) a PROGMEM musí být const, nebo mimo funkci ``__ Protože vypisovat stovky řetězců je otročina, napsal jsem si program v Pythonu na napsání programu v ino. Zracovávají se unikátní řetězce o délce 8 znaků, v páru testů se ličí jen pořadím znaků na 5. a 6. místě, 7. a 8. místo je pořadí řetězce, aby to kompilátor prostě nemohl zoptimalizovat. Takže tady jsou výsledky a zdrojáky ``__ .. code:: Sketch uses 57658 bytes (22%) of program storage space. Maximum is 253952 bytes. Global variables use 2146 bytes (26%) of dynamic memory, leaving 6046 bytes for local variables. Maximum is 8192 bytes. ... Test_Pgm_Print: 6800 Test_Raw_Print: 6801 Test_Pgm_Cnt: 102 Test_Raw_Cnt: 87 Je vidět, že u tisku je to jedno, u přímé práce je to o 17% pomalejší, což by většinou vadit nemělo.