I2C - Arduino STM32 Nucleo L476RG

[Jan Waclawek]

>No ja to myslel hlavne s ohledem na interni bootloader, 

Ten sa ale spusti len ak to uzivatel explicitne povoli (piny, konfiguracne
bity), takze tam nie je dovod na obavy.

>mozna existuje 
>nejaka specifikace jake oblasti RAM pouziva, pak OK, zatim jsem ale nic 
>takoveho nepotkal, 

AN2606, na zaciatku kazdej kapitoly (t.j. pre kazdu rodinu) je tabulka s
pouzitymi zdrojmi, ktora zahrna aj RAM. Ta hodnota tam uvadzana je
konzervativna, a je pravdepodobne, ze ak by nastala revizia bootloadera
(ktore tam mimochodom tiez su uvedene), tak sa to do tej hodnoty zmesti.

Mimochodom, je to najslusnejsie urobeny a pravidelne udrziavany AN k STM32.

>Take jsem v DS ani RM nenasel informaci, ktera by zarucovala zachovani 
>obsahu RAM po RESETu, 

To som nenasiel ani ja, ale jednoducho su veci, ktore su prilis obvykle na
to, aby to bolo explicitne uvadzane. Za cele tie roky som sa nestretol s
mcu, kde by to tak nebolo (teda od doby 8048, ktora mala dynamicke
registre a teda asi aj RAM). Nie je dovod na obvodove mazanie beznej SRAM
a vzhladom na jej spotrebu ani na odpajanie napajania pri resete (co by
mohlo sposobit stratu informacie) ci taky navrh, ktory by pocas resetu
sposobil neurcite stavy na internych zberniciach. 

Vynimkou su rozne secure mcu, kde to vsak samozrejme je velmi vyrazne
uvedene, lebo to je featura a stoji to plochu kremika t.j. sa to prejavi
na vyslednej cene obvodu. Napr. v niektorych STM32 je par registrov v RTC
ktore su hardwarovo mazane od tamper udalosti/pinu; pritom vsak baterkou
zalohovana relativne velka RAM (BKPSRAM) mazana pri tamper udalosti nie je.


>dalsi vec jsou ruzne budouci verze knihoven a API, 
>ktere se muzou chovat ruzne, takze bych s tim proste obecne nepocital. 

To je jeden z mnohych dovodov, preco sa rozne kniznice a "kniznice" v
profesionalnej praxi maju pouzivat len s maximalnou opatrnostou (do coho
patri aj ich nepouzitie).

wek