Arduino

ruzne programy,konverze dat, digitalizace, atd...
StoupaCZ
Příspěvky: 284
Registrován: 2. 6. 2017, 8:12

9. 10. 2020, 6:17

Na první pohled jsem si všiml v každém kódu jedné věci:

V prvním zbytečně voláš 2x calc_error() a protože v této funkci vždy voláš read_thermocouple(), mohou být výsledky těch 2 volání rozdílné, což způsobí malou nekonzistenci v previous_error. V praxi to asi nebude vadit, ale zavolal bych calc_error() jednou a uložil výsledek do lokální proměnné.

V druhém bych pro výpočet nové hodnoty spark_time použil přímo hodnotu z funkce millis() namísto původní hodnoty spark_time. Bude to pak více odpovídat aktuálnímu stavu časovače a při použití malých hodnot spark_on a spark_off nebude problém s "doháněním" aktuální hodnoty časovače v případě, kdy časovač z nějakých důvodů "ujede" moc dopředu.
prcek
Příspěvky: 404
Registrován: 31. 10. 2016, 2:26

9. 10. 2020, 8:03

pokud
static boolean spark_state = LOW;
chces pouzit k uchovani stavu mezi volanimi funkce nesmi byt lokalni
--
Všechno je snadné, než to zkusíš sám.
atlan
Příspěvky: 2135
Registrován: 7. 2. 2011, 9:12

9. 10. 2020, 11:47

Najprv si to rozmysli. Prva vec je casovy interval pid slucky napr 100ms, a druha vec jehodnota ktora je vystupom pid regulatora. V tojim pripade dlzka on zaputbnia kurenia napr v sekundach.
Uživatelský avatar
Mr. MR
Příspěvky: 125
Registrován: 31. 5. 2020, 10:05

9. 10. 2020, 12:16

Najprv si to rozmysli. Prva vec je casovy interval pid slucky napr 100ms, a druha vec jehodnota ktora je vystupom pid regulatora. V tojim pripade dlzka on zaputbnia kurenia napr v sekundach.
Zatím to mám vymyšlené tak, že jednou za interval (řekněme každou sekundu) změřím teplotu, proženu ji výpočtem, získám hodnoty p, i, d; tyto hodnoty si někam uložím, asi do globální proměnné, nevím kam jinam. Odtud si je pak vezmu na výpis pro ladění přes seriový port, ale hlavně jejich součtem získám PID_hodnotu, kterou aplikuju takto

topeni_on = PID_hodnota
topeni_off = sekunda - PID_hodnota

samozřejmě si to pojistím tak, že:
max PID_hodnota = interval
min PID_hodnota = 0
Uživatelský avatar
Mr. MR
Příspěvky: 125
Registrován: 31. 5. 2020, 10:05

9. 10. 2020, 3:02

Jak pise Radhard, modularita je zaklad. Ok, ja bych si pod takovym pojmem predstavil, ze treba ten kod ohledne pid bude proste cerna bedna, kterou nekam kakopiruju, reknu co se do ni sype (teplota realna a pozadovana), a kterym pinem s topnym telesem ma cvakat. Pokud musim pouzivat globalni promenne abych si zapamatoval minule namerenou hodnotu, kterou potrebuju pro dalsi vypocet, tak mi to prijde jaksi polovicate. Nebo to tak normalne chodi a jenom si na to musim zvyknout?
prcek
Příspěvky: 404
Registrován: 31. 10. 2016, 2:26

9. 10. 2020, 3:11

Mr. MR píše:
9. 10. 2020, 3:02
Jak pise Radhard, modularita je zaklad. Ok, ja bych si pod takovym pojmem predstavil, ze treba ten kod ohledne pid bude proste cerna bedna, kterou nekam kakopiruju, reknu co se do ni sype (teplota realna a pozadovana), a kterym pinem s topnym telesem ma cvakat. Pokud musim pouzivat globalni promenne abych si zapamatoval minule namerenou hodnotu, kterou potrebuju pro dalsi vypocet, tak mi to prijde jaksi polovicate. Nebo to tak normalne chodi a jenom si na to musim zvyknout?
No tak ta funkce, co budes volat dostane jeste aktualni stav a vrati stav novy, ktery si uchovas v te globalni promenne

Kód: Vybrat vše

static bool heating_state = HEATING_OFF;
...
heating_state = adapt_heating(temp_measured, temp_requested, heating_pin, heating_state);
...
pravdepodobne tam mam 2-3 syntakticke chyby
pricemz konstanty HEATING_OFF a HEATING_ON muzes mit definovane v hlavickovem souboru te knihovny...
--
Všechno je snadné, než to zkusíš sám.
StoupaCZ
Příspěvky: 284
Registrován: 2. 6. 2017, 8:12

10. 10. 2020, 7:35

prcek píše:
9. 10. 2020, 8:03
pokud
static boolean spark_state = LOW;
chces pouzit k uchovani stavu mezi volanimi funkce nesmi byt lokalni
Ale právě proto, aby se uchovala její hodnota mezi jednotlivými voláními funkce je ta proměnná statická. Je velký rozdíl mezi normální lokální proměnnou a statickou.
Normální se vytváří na zásobníku volání a je tudíž při návratu z funkce zahozena (její obou platnosti je pouze uvnitř dané funkce).
Oproti tomu statická proměnná se vytváří na haldě, a je tudíž dostupná počas celého běhu programu. Oproti globální proměnné je viditelná jen v té metodě, kde byla deklarovaná, a tudíž se neplete s dalšími globálními proměnnými.
prcek
Příspěvky: 404
Registrován: 31. 10. 2016, 2:26

10. 10. 2020, 8:32

StoupaCZ píše:
10. 10. 2020, 7:35
Ale právě proto, aby se uchovala její hodnota mezi jednotlivými voláními funkce je ta proměnná statická. Je velký rozdíl mezi normální lokální proměnnou a statickou.
Normální se vytváří na zásobníku volání a je tudíž při návratu z funkce zahozena (její obou platnosti je pouze uvnitř dané funkce).
Oproti tomu statická proměnná se vytváří na haldě, a je tudíž dostupná počas celého běhu programu. Oproti globální proměnné je viditelná jen v té metodě, kde byla deklarovaná, a tudíž se neplete s dalšími globálními proměnnými.
Pravdu mas, napsal jsem pitomost.
--
Všechno je snadné, než to zkusíš sám.
Uživatelský avatar
Cjuz
Příspěvky: 1802
Registrován: 17. 2. 2013, 6:27
Bydliště: Předklášteří
Kontaktovat uživatele:

12. 10. 2020, 7:56

Jen info:
Teď jsem hledal problém zamrzávání a resetu Arduino DUE s komunikací I2C na OLED display.
Zkoušel jsem posilovat sběrnici rezistory 2k2 proti 3,3V a zlepšilo se to, ale stále se to sem tam (1xmin) zaseklo.
Nakonec stačilo na kablík cca 100mm mezi diplejem a MCU nacvaknout feritový váleček.
Je to pro mě první zkušenost kde opravdu váleček funguje skoro jako zázrak, není tam a reset každých cca 5s, je tam a celý den bez chyby i bez rezistorů.

Třeba informace někdy někomu pomůže.
Na konci poznávacího procesu je omyl zcela vyvrácen a my nevíme nic. Zato to víme správně.
Mex
Příspěvky: 7461
Registrován: 6. 2. 2014, 10:29

12. 10. 2020, 8:23

Cjuz píše:
12. 10. 2020, 7:56
Jen info:
Teď jsem hledal problém zamrzávání a resetu Arduino DUE s komunikací I2C na OLED display.
Zkoušel jsem posilovat sběrnici rezistory 2k2 proti 3,3V a zlepšilo se to, ale stále se to sem tam (1xmin) zaseklo.
Nakonec stačilo na kablík cca 100mm mezi diplejem a MCU nacvaknout feritový váleček.
Je to pro mě první zkušenost kde opravdu váleček funguje skoro jako zázrak, není tam a reset každých cca 5s, je tam a celý den bez chyby i bez rezistorů.

Třeba informace někdy někomu pomůže.
To je nějaké divné.
Píšeš, že vedení k displeji má 100mm. Tak pokud nesedíš přímo před anténou televizního vysílače, tak na tom kousku drátu se toho moc nenaindukuje.
Je zbytek zapojení OK? Pull-upy na I2C, zablokované napájení, správné napěťové úrovně atd.?
Řekl bych, že ten feritový kroužek jen trochu posunul nějaké parametry, takže se něco, co je špatně, dostalo těsně za hranu a už to nějak funguje.
Ale chyba tam (podle mě) pořád někde bude.
Uživatelský avatar
Cjuz
Příspěvky: 1802
Registrován: 17. 2. 2013, 6:27
Bydliště: Předklášteří
Kontaktovat uživatele:

12. 10. 2020, 8:47

Mex píše:
12. 10. 2020, 8:23
Cjuz píše:
12. 10. 2020, 7:56
Jen info:
Teď jsem hledal problém zamrzávání a resetu Arduino DUE s komunikací I2C na OLED display.
Zkoušel jsem posilovat sběrnici rezistory 2k2 proti 3,3V a zlepšilo se to, ale stále se to sem tam (1xmin) zaseklo.
Nakonec stačilo na kablík cca 100mm mezi diplejem a MCU nacvaknout feritový váleček.
Je to pro mě první zkušenost kde opravdu váleček funguje skoro jako zázrak, není tam a reset každých cca 5s, je tam a celý den bez chyby i bez rezistorů.

Třeba informace někdy někomu pomůže.
To je nějaké divné.
Píšeš, že vedení k displeji má 100mm. Tak pokud nesedíš přímo před anténou televizního vysílače, tak na tom kousku drátu se toho moc nenaindukuje.
Je zbytek zapojení OK? Pull-upy na I2C, zablokované napájení, správné napěťové úrovně atd.?
Řekl bych, že ten feritový kroužek jen trochu posunul nějaké parametry, takže se něco, co je špatně, dostalo těsně za hranu a už to nějak funguje.
Ale chyba tam (podle mě) pořád někde bude.
Já to taky nechápu, ale pokud dám na i2c osciloskop tak si ani neškrtne, procesor padá hned ani displej nenaběhne. S feritem jsem schpný průběh měřit, úrovně jsou správné, hrany taky jakš takš, jen je tam nějaké rušení, není to čisté. Chyba - ale, kde ji hledat. Mám teorii že ten OLED něco vrací zpět a celé to pak havaruje, možná je to i tím že MCU u DUE jede na jiné frekvenci než běžná arduina.
Na konci poznávacího procesu je omyl zcela vyvrácen a my nevíme nic. Zato to víme správně.
Uživatelský avatar
Radhard
Příspěvky: 24
Registrován: 1. 7. 2020, 10:19
Bydliště: Praha
Kontaktovat uživatele:

12. 10. 2020, 10:03

Oled vrací kromě ACK bitu něco jen když po něm požaduješ data. DUO stojí na procesoru ARM, ale to je jedno. Důležitý je správný časování (max 400KHz) a strmé hrany (správné pulup odpory).
A nezapomenout - I2C není navržena jako externí sběrna, ale jen pro komunikaci po desce.
Naposledy upravil(a) Radhard dne 12. 10. 2020, 10:25, celkem upraveno 1 x.
Mart76
Příspěvky: 353
Registrován: 17. 12. 2016, 11:04
Bydliště: Prostějov

12. 10. 2020, 10:12

Nebo bude někde utržená zem (GND).
A taky bych zkusil zjistit důvod těch resetů, tzn. podívat se do příslušného registru, na základě čeho se ten reset vygeneroval.
Vývoj HW, návrhy DPS (OrCAD, Eagle, Pads)
t256
Příspěvky: 1522
Registrován: 19. 1. 2012, 4:49

12. 10. 2020, 10:26

Nektere OLED dost rusi, pokud tam mas nejakou prasecinku z hlediska EMC ktera u LCD projde, tak u OLED uz bude problem.
Ferit dost pomuze, ja mam napriklad bezny lcd s hd44780 krmeny plochym kabelem o delce cca 1m ve stroji kde se spinaji rychlym mosfetem desitky amper a bez feritoveho navleku na kabel se taky vubec nechytal. S nim jede zcela bez problemu.
Odpovědět

Zpět na „Ostatní software“