Blikací LED

daton
Příspěvky: 664
Registrován: 16 bře 2013, 16:12

Re: Blikací LED

Příspěvek od daton »

Ahoj Davide
Moc si cením toho, že mi to tady tak pěkně vysvětluješ, doufám že tě to neomrzí :-) i když já jsem docela dost protivný s dotazy co??? :-) :-)

Ale ted k tomu co jsi mi napsal. Tak že flash jako taková je pamět pro program a tedy pokud by mi docházela tak by mi nemělo F pro data k tisku nijak pomoci protože když bych to napsal před řetězec k tisku tak se to uloží do stejné paměti.... ale pomůže, velikost ve flash se zmenší což při tvém vysvětlení znamená jen jedno uloží se to nějak jinak a úsporněji (je to tak?). Protože jinak bych si to nedovedl vysvětlit. Myslel jsem totiž že ty řetězce za F se neukládají do flash ale na tu eeprom což je zjevně špatná úvaha.

Ale shrnu zatím pochopená fakta
flash pamět je pamět do které se ukládá program předpokládám že dále už není dělená, respektive dle tohoto odkazu dělená je ale
https://learn.adafruit.com/memories-of- ... o-memories
a to na část s proměnnými a na část s uloženým programem.
RAM je jasná v ní se - odehrává děj.. nevím jak to popsat výstižněji
EEPROM vypálený obsluha samotné platformy arduino

No ale stále to nevystihuje jak to že se zmenší obsah paměti když použiji to F.

A ještě jeden dotaz
a pokud neuděláš nějakou kravinu s příliš hlubokým zanořením funkcí,
tohle jak jsem pochopil je když uděláš if v if a dalším if a pak ještě v jenom if tedy se zanoříš 3x. Toto jsi měl na myslí? A jak to tedy zamotá programu hlavu? Je jasné že si musí pamatovat odskok vyřešit podmínku ale ne ona má další odskok a tak dál. to znamená nechat v ram určitou část kodu a začít pracovat s další v odskoku a pak ještě další .. tak jsi to mysle? Je to tedy záběr pro RAM protože se rychle zaplňuje a mohla by přetéci. Normální PC by si obsah ram hodilo do odkládacího prostoru na disk ale co arduino? Také má takovýto prostor (tedy něco jako v linuxu SWAP)?
Dík za vysvětlení :-)
DavidO
Příspěvky: 1133
Registrován: 01 kvě 2013, 21:27

Re: Blikací LED

Příspěvek od DavidO »

daton píše: 03 pro 2018, 12:12 Ahoj Davide
Moc si cením toho, že mi to tady tak pěkně vysvětluješ, doufám že tě to neomrzí :-) i když já jsem docela dost protivný s dotazy co??? :-) :-)
Bez komentáře. :mrgreen:
daton píše: 03 pro 2018, 12:12 Ale ted k tomu co jsi mi napsal. Tak že flash jako taková je pamět pro program a tedy pokud by mi docházela tak by mi nemělo F pro data k tisku nijak pomoci protože když bych to napsal před řetězec k tisku tak se to uloží do stejné paměti.... ale pomůže, velikost ve flash se zmenší což při tvém vysvětlení znamená jen jedno uloží se to nějak jinak a úsporněji (je to tak?). Protože jinak bych si to nedovedl vysvětlit.
To je pro mě zajímavé, zatím jsem na to nikdy nenarazil, ale asi si to umím vysvětlit (tak, že když to bude bez F tak se to chová jako statický řetězec, který se musí při nahrávání kódu uložit do Flash, a pak při startu okopírovat z Flash do RAM, no a to kopírování je taky kousek kódu, který se musí někam uložit. Zatímco s tím F se to uloží do Flash, ale při startu se to nikam nekopíruje, protože pak při volání toho tisku se zavolá vlastně jiná funkce, která data pro výstup nebere z RAM ale z Flash. Ta samozřejmě taky musí někde být uložená, ale nejspíš každé přepsání z "ne-F" na "F" o kousek zkrátí výsledný kód)
daton píše: 03 pro 2018, 12:12 Myslel jsem totiž že ty řetězce za F se neukládají do flash ale na tu eeprom což je zjevně špatná úvaha.
Ne, ukládají se do Flash a ne do EEPROM. Ta je celá k dispozici tobě.
daton píše: 03 pro 2018, 12:12 flash pamět je pamět do které se ukládá program
Ano, a taky hodnota proměnných, kterou při deklaraci proměnné uvedeš. Např. int odpoved=42; versus int nejakaPromenna; - tak ta univerzální odpověď na základní otázku života, vesmíru a vůbec se musí někam uložit, aby se při zapnutí napájení a startu kontroléru měla odkud vzít a dát do té proměnné (která jinak je v SRAM, jejíž obsah se bez napájení nezachová). U nejakaPromenna se to ukládat nemusí, protože pokud to je globální proměnná nebo statická lokální, z definica jazyka C++ plyne, že se bude inicializovat nulou a tak to není potřeba ukládat, a pokud to je lokální proměnná, tak je na programátorovi, aby si tam něco přiřadil sám a tedy je jedno, co tam při startu bude.
daton píše: 03 pro 2018, 12:12 předpokládám že dále už není dělená, respektive dle tohoto odkazu dělená je ale
https://learn.adafruit.com/memories-of- ... o-memories
a to na část s proměnnými a na část s uloženým programem.
Je dělená jen "logicky", resp. že se v ní najdou jak program, tak proměnné, které jsou už při deklaraci inicializované.
daton píše: 03 pro 2018, 12:12 RAM je jasná v ní se - odehrává děj.. nevím jak to popsat výstižněji
Ano.
daton píše: 03 pro 2018, 12:12 EEPROM vypálený obsluha samotné platformy arduino
Ne. Aby se nějaká deska tvářila jako Arduino a mohl jsi programovat pomocí těch funkcí jako digitalWrite a tak, tak to zařídí IDE (nebo CLI) na tvém počítači, kdy ke tvému programu ještě přilepí všechny potřebné funkce a přeloží do strojáku pro ten který mikrokontroler. Jiná věc je, jak pak ten přeložený program dostat z počítače do toho mikrokontroleru, a na to je "bootloader", který vždycky při resetu kontroléru (což zahrnuje jak zmáčknutí tlačítka reset, tak zapnutí napájení a nakonec i příkaz v IDE "nahraj" nebo jak se to tam jmenuje) ověří, jestli mu náhodou někdo nechce poslat nový uživatelův kód. Pokud ano, tak ho postupně přijme, uloží do Flash (od začátku) a pak ho zavolá a tvůj program se tím spustí. Ten bootloader je ale z pohledu mikrokontroleru taky program, a je to udělaný tak, že je přednahraný v paměti Flash podobně jako pak je ten tvůj program, akorát že bootloader je úplně na jejím konci zatímco tvůj program se nahrává od začátku. A v Arduino IDE ta maximální velikost programu už je spočítaná jako velikost celé Flash mínus velikost bootloaderu, čili i kdybys to využil na 100%, tak to ten bootloader nepřepíše.
daton píše: 03 pro 2018, 12:12 No ale stále to nevystihuje jak to že se zmenší obsah paměti když použiji to F.
Ano, nevysvětluje, ale jak jsem psal výše, nějakou ideu mám. Pošli mi (asi soukromě) celý ten kód a budu třeba moct tu ideu potvrdit nebo vyvrátit a přijít na jinou.
daton píše: 03 pro 2018, 12:12 A ještě jeden dotaz
a pokud neuděláš nějakou kravinu s příliš hlubokým zanořením funkcí,
tohle jak jsem pochopil je když uděláš if v if a dalším if a pak ještě v jenom if tedy se zanoříš 3x. Toto jsi měl na myslí? A jak to tedy zamotá programu hlavu? Je jasné že si musí pamatovat odskok vyřešit podmínku ale ne ona má další odskok a tak dál. to znamená nechat v ram určitou část kodu a začít pracovat s další v odskoku a pak ještě další .. tak jsi to mysle? Je to tedy záběr pro RAM protože se rychle zaplňuje a mohla by přetéci. Normální PC by si obsah ram hodilo do odkládacího prostoru na disk ale co arduino? Také má takovýto prostor (tedy něco jako v linuxu SWAP)?
Dík za vysvětlení :-)
Nene, ifů můžeš nořit kolik chceš. Tam je jasně dané strukturou kódu, kam se má jít, když podmínka je splněná a kam když ne a hlavně čím se má pokračovat potom. Problém je ve volání funkcí (jako je třeba setup nebo loop nebo jiné funkce z knihovny (třeba to println) anebo i libovolná jiná, kterou si sám napíšeš). Tam se musí zapamatovat, kde se má po skončení té funkce pokračovat, a to nemůže vědět ta funkce, protože když ji voláš ze dvou různých míst, tak ta funkce by nevěděla, na které se pak má vrátit. Takže se musí někam uložit "návratová adresa" a to je to, co žere RAM. Zatímco u toho ifu se nikdy "nechodí dovnitř z různých míst".
Kromě toho se taky někam musejí uložit parametry (argumenty) té funkce. Tam to je v případě gcc pro AVR (tj. překladač, co používá Arduino) šikovně udělané, že když jich je málo, tak to místo v RAM nezabírá protože se předají přes registry, ale když jich je hodně nebo to jsou třeba pole nebo tak, tak se zase musejí uložit někam do RAM.
Nikoho plánovaně neurážím. Jestli se Vám nelíbí co píšu, tak to nečtěte. A ostatně, třeba za to nemůžu - Researchers believe that dark humor can be a significant symptom of dementia.
daton
Příspěvky: 664
Registrován: 16 bře 2013, 16:12

Re: Blikací LED

Příspěvek od daton »

Aha tak to je super už vím nebo si alespoň myslím že vím podstatně víc než předtím :D . Prosím tě a ještě tedy jedna věc mi vrtá hlavou. Ty jsi napsal, že zanořené mohou být tyto funkce např
setup nebo loop nebo jiné funkce z knihovny (třeba to println) anebo i libovolná jiná, kterou si sám napíšeš

Pro hladší chod (pokud se to dá přirovnat třeba k mechanickému soukolí :-) ) je lépe natáhnout kod a vypsat tam například jak jsme řešily na začátku to blikání diod pokud se bude v programu vyskytovat třeba dvakrát nebo třikrát, tedy celkový kod bude mít o pár řádků více ale nebude se volat funkce jako taková.
Nebo udělat vlastní funkci na blikání a volat ji ze dvou nebo tří míst?
Co bude lepší pro chod a stabilitu arduina?
Pro přehlednost bych volil napsat si funkci a volat ji, ale zase ji nepoužívám tolikrát, není lepší ji naopak zařadit do kodu?
(už jen proto že blikání bude v hlavní funkci nastaveno stále na zelenou a je to jen kontrola chodu, ostatní žlutá nebo červený bude tvořit výstrahu a chybu ).
Díky za odpověď.
Uživatelský avatar
gilhad
Příspěvky: 262
Registrován: 29 kvě 2015, 00:36
Kontaktovat uživatele:

Re: Blikací LED

Příspěvek od gilhad »

Lepsi je funkce pouzivat, protoze kdyz se kus kodu opakuje, tak to jednak zabira pokazde dalsi flash, druhak a zejmena, kdyz pak delas jakoukoli upravu, tak ji musis delat nekolikrat a celkem zarucene v tom nekde udelas chybu.

Zanorovani funkci je, kdyz funkce vola funkci, ktera vola funkci, ktera ... tak to trochu ubira RAM,(ale vetsinou ne tolik jako to opakovani ubira flash - pokud nemas moc velkych lokalnich promennych)

nebo kdyz funkce vola sebe sama (i neprimo prez jine funkce), cemuz se taky rika rekurze a kdyz se v tom udela chyba, tak se to vola samo sebe dokola tak dlouho, dokud nedojde RAM. Na druhou stranu jsou pripady, kdy naopak rekurze je nejlepsim resenim ...

Pro stabilitu arduina - pokud nedojde RAM, tak neni problem. Pro stabilitu programu je dulezite, aby ses v nem vyznal - cili prehledny a komentovany kod, opakujici se bloky spis jako vhodne pojmenovane funkce, obecne prilehava jmena jak funkci, tak promennych. Vhodna struktura programu (coz spagetti kod, kde se vsechno mockrat opakuje v naproste vetsine neni.)

A ostatne, kdyz to nebude chodit, tak chces, aby ti, co se na ne obratis pro radu, s tim ctenim, pochopenim a nalezenim chyb meli co nejmin prace (tedy aby nasli chybu driv, nez je to prestane bavit, nebo jim to prestane davat smysl)

Komentare prekladas sam zahodi, takze nezabiraji ve vyslednem kodu zadne misto a neni tedy duvod jimi setrit - ty vis, co to ma delat, proc tohle volas a na co je tato promena, ale ctenar na to musi nejak prijit a ty to taky za rok (nebo za deset let - i po takove dobe po me nekdo chtel nejake drobne upravy v mych programech) vedet nebudes. Takze komentaru pis dost a k veci (ze se nekde pricita jednicka je jasne z kodu, ze to o dvacet radku niz chces pouzit pro pripadnou zmenu barvy je uz poznamenani vhodne. Stejne jako je vhodne psat poznamky k deklaraci promennych, aby bylo jasnejsi na co je potrebujese (i kdyz vhodne jmeno napovi, dobry komentar to upresni).

Jmena volit rozumne dlouha a vystizna - kompilator to stejne prevede na adresy, takze pojmenovanim zadne byty neusetris, prilis dlouha jmena zase odradi ctenare ...
Uživatelský avatar
Dex
Administrátor
Příspěvky: 1519
Registrován: 16 úno 2013, 14:26

Re: Blikací LED

Příspěvek od Dex »

Já se asi budu opakovat, ale je to potřeba :)

Doporučuji zakoupit knihu o programování v C od pana Herouta a zaměřit se alespoň na pasáže popisující tzv. štábní kulturu. Spousta z toho je platná bez ohledu na programovací jazyk.
"all your robots are belong to us"
robodoupe.cz
DavidO
Příspěvky: 1133
Registrován: 01 kvě 2013, 21:27

Re: Blikací LED

Příspěvek od DavidO »

daton píše: 03 pro 2018, 14:03Pro hladší chod (pokud se to dá přirovnat třeba k mechanickému soukolí :-) ) je lépe natáhnout kod a vypsat tam například jak jsme řešily na začátku to blikání diod pokud se bude v programu vyskytovat třeba dvakrát nebo třikrát, tedy celkový kod bude mít o pár řádků více ale nebude se volat funkce jako taková.
Když to okopíruješ na víc míst, tak si v tom uděláš leda čurbes. Navíc když to pak budeš třeba opravovat nebo měnit, tak bys to musel měnit nebo opravovat všede, ale to si to obvykle rozbiješ, protože změnu uděláš na míň místech, než je potřeba (nebo na víc místech, i v úplně jiném kódu...)
daton píše: 03 pro 2018, 14:03Nebo udělat vlastní funkci na blikání a volat ji ze dvou nebo tří míst?
Rozhodně.
daton píše: 03 pro 2018, 14:03Co bude lepší pro chod a stabilitu arduina?
AVR je šumák, jak je kód smatlanej. Dělá co se mu řekne a pojede pořád stejně stabilně. Nestabilita zařízení je chybným kódem nebo nevyhovujícíma podmínkama provozu (elektrosmog, teplota atd. mimo tolerance stanovené výrobcem).
daton píše: 03 pro 2018, 14:03Pro přehlednost bych volil napsat si funkci a volat ji, ale zase ji nepoužívám tolikrát, není lepší ji naopak zařadit do kodu?
Co se velikosti kódu týče i co se srozumitelnosti týče, tak jednoznačně psát funkce!!!

Pokud se bude volat aspoň 2x, tak jsi ušetřil programovou paměť, a kdyby se volala jen z jednoho jediného místa, tak ti ji překladač celou plácne místo toho volání, jako by sis to tam napsal rovnou.

A čitelné to s těma funkcema bude líp, než kdyby to byl jeden velký blemc.
Nikoho plánovaně neurážím. Jestli se Vám nelíbí co píšu, tak to nečtěte. A ostatně, třeba za to nemůžu - Researchers believe that dark humor can be a significant symptom of dementia.
daton
Příspěvky: 664
Registrován: 16 bře 2013, 16:12

Re: Blikací LED

Příspěvek od daton »

Moc děkuji za rady bylo to alespoň pro mne hodně přínosné a pokud to dalo někomu dalšímu trochu osvícení tím lépe. Díky pánové ;)
Vladimir66
Příspěvky: 385
Registrován: 02 dub 2014, 15:30

Re: Blikací LED

Příspěvek od Vladimir66 »

daton napsal:
Myslel jsem totiž že ty řetězce za F se neukládají do flash ale na tu eeprom což je zjevně špatná úvaha.
priklad:
program se preklada a kam se ulozi textovy retezec (data pro zobrazeni) ?
s eFkem se ulozi do Flash,
bez eFka do RAMky (do oblasti za registry)
bud tam nebo tam.
.
kod_bez_F.png
kod_bez_F.png (11.49 KiB) Zobrazeno 15115 x
.
.
kod_s_F.png
kod_s_F.png (11.53 KiB) Zobrazeno 15115 x

RAMka je cenna a pokud je misto a nesetris zlomky casu pri cteni dat, tak ukladat vzdy do Flashky.
moje zkusenost.
DavidO
Příspěvky: 1133
Registrován: 01 kvě 2013, 21:27

Re: Blikací LED

Příspěvek od DavidO »

Vladimir66 píše: 04 pro 2018, 20:32 s eFkem se ulozi do Flash,
bez eFka do RAMky (do oblasti za registry)
bud tam nebo tam.
NE. Konstantní data (a to je třeba tady takovýhle nějaký text k vypsání) jsou vždycky ve Flash a obvykle navíc i v RAM:
Pokud neřekneš jinak, tak se musejí po nastartování programu okopírovat do RAM, aby se s nima mohlo pracovat jako s normálníma proměnnýma, které jsou od přírody v RAM. Funkce print a println jsou napsané tak, aby kromě toho, že jako parametr dostanou odkaz na text v RAM, uměly brát jako parametr odkaz na text ve Flash (technicky to jsou dvě různé funkce, co se ale stejně jmenujou a o kterou jde se pozná podle typu těch dat - to zařídí kompilátor, ostatně funkcí print je ve skutečnosti 11 různých podle typu parametru a přitom uživateli si stačí pamatovat "print").
Vladimir66 píše: 04 pro 2018, 20:32 RAMka je cenna a pokud je misto a nesetris zlomky casu pri cteni dat, tak ukladat vzdy do Flashky.
moje zkusenost.
Na druhou stranu, stojí to o trochu víc Flash kvůli té funkci na tisk z Flash - všimni si, že v tom příkladu ti to narostlo ze 1738 na 1764.
Nikoho plánovaně neurážím. Jestli se Vám nelíbí co píšu, tak to nečtěte. A ostatně, třeba za to nemůžu - Researchers believe that dark humor can be a significant symptom of dementia.
Vladimir66
Příspěvky: 385
Registrován: 02 dub 2014, 15:30

Re: Blikací LED

Příspěvek od Vladimir66 »

ok, je to logicke,
v RAMce po zapunuti nic byt nemuze (jen v EEPROM)
totalni mistake :)
Odpovědět