Tak vyřešeno s GCC 4.8.1 a přidáním do “custom compilation options” -gstrict-dwarf a -gpubnames Simulator padal případně nešlo krokovat kód, protože vygenerovaný ELF vypadal jinak. Ještě zkusím GCC 5 ale tenhle výsledek zatím stačí, šlo o to NEPOUŽÍVAT pgm_read_xx() macra.
alongo:
To proto, že jsi ‘slovnik’ deklaroval jako lokální, ve funkci.
Proměnné PROGMEM se deklarují jako globální.
V tvém kódu jsi přehodil obsah hranatých závorek.
Toto funguje:
[code]//const char slovnik[6]] PROGMEM = // nebo
const char* slovnik] PROGMEM = // totéž
{ “sk0”,
“en0”,
“sk1”,
“en1”,
“sk2”,
“en2”
};
char string_in_ram[4];
int main(void)
{
strcpy(string_in_ram, slovnik[0]); // “sk0”
strcpy(string_in_ram, slovnik[1]); // “en0”
lcd_puts(slovnik[0]);[/code]
Ale jestli si myslíš, že ty stringy jsou umístěné v paměti programu, tak se mýlíš.
Ve flash je umístěná jenom proměnná ‘slovnik’. což je tabulka ukazatelů na stringy. Ale tyto stringy jsou umístěné v RAM.
Můžeš se o tom přesvědčit tak, že po spuštění simulátoru se podíváš na obsah paměti DATA. Stringy jsou tam vidět.
Postup pro umístění pole stringů ve flash je složitější a je popsaný tady
nongnu.org/avr-libc/user-man … space.html
Tady se mýlíš Ty. Ve Flash jsou stringy umístěné vždy - jak jinak by se po zapnutí mcu v SRAM vzaly, že?. V případě použití modifikátoru PROGMEM ukazují pointry (ty jsou uložené v SRAM) do programové paměti. Pokud se modifikátor PROGMEM nepoužije, pak pointry ukazují do SRAM, kam se stringy z programové paměti zkopírují ještě před spuštěním main(). Pokud do programové paměti nacpeš třeba 10kB dat (nemusí to být jenom stringy) a nepoužiješ PROGMEM, tak se Ti data do 1kB SRAM určitě nevejdou a nepůjde to přeložit. Jediný data, který nejsou v programové paměti jsou data, která označíš jako EEMEM. Ty se nekopírují do EEPROM při startu mcu, ale překladač vygeneruje *.EEP soubor a ten pak do mcu nahraješ při programování. Není to ale úplně nejvhodnější způsob, protože pokud si smažeš obsah EEPROM, tak jí musíš nějak obnovit. Nové přehrání EEPROM pomocí programátoru nebo programové nakopírování “default” obsahu do EEPROM. Osobně používám to druhé. Program si zkontroluje data a v případě potřeby si je do EEPROM zkopíruje.
Zkoušel jsi to přeložit ? Nejde to :
A tohle taky ne …
To jistě každý ví.
Já mluvím o tom, že v uvedeném příkladu jsou stringy uloženy i v RAM, takže tam trvale zabírají místo.
V odkazu pak je metoda při keré jsou uloženy pouze ve flash.
Je tam přesně to co jsem popsal v předešlém příspěvku.
Jestli se mýlím tak mi vysvětli kde se v následujícím příkladu vzalo 628 bajtů v RAM, když stringy jsou podle tebe uloženy ve flash
<<Zkoušel jsi to přeložit ? Nejde to
Jak vidíš v mé příloze, tak mně to jde.
Tady je příklad na umístění pole stringů pouze ve flash.
Je vidět že v RAM je jenom proměnná ‘buffer’.
V tom případě jediná možnost je, že máš novější AVR Studio nebo novější (případně jiný) C kompilátor, než používám já … U mně se to chová tak, jak jsem psal Alongovi :
char const Texty][17] to našoupe do SRAM,
char const PROGMEM Texty][17] to nechá ve flash…
Zápis, který používáš Ty mi nechodí (viz. příspěvek výše …)
Používám AVR Studio 4.19 Build 716 a AVR Toolchain 3.4.5.1522
<<char const PROGMEM Texty][17] to nechá ve flash…
To by mne zajímalo.
Mohl bys, prosím, sejmout obrazovku jako já aby to bylo vidět?
Tady to je.
Tohle je z AVR Studia 5 z jiného PC, ale chová se to stejně, jako u mně v AVR Studiu 4 doma.
Díky.
Musím se se na to ještě jednou podívat.