RoboDoupě.cz

(mam takovy pocit, ze zrovna jsi narazil na situaci, kdy je vhodne opustit Arduino a zacit pouzivat AVR - jasne, ze je to stejny HW a pripadne i SW, ale proste uz musis zmenit pristup od "poslepuju par veci z internetu a da-li buh, tak to bude neco nejak delat" k pristupu "zjistim si, jak vlastne muj HW funguje a co s nim softwarove musim udelat, abych dostal pozadovany vysledek" - v podstate uloha Arduina byla zahackovat lidi na rychle vysledky bez namahy a koho to chytne, tak uz ma motivaci se ponorit do studia. Koho ne, tak aspon trochu pochopi neco malo, treba mu to bude ke stesti stacit (ono se s tim da udelat dost i touto metodou) a diky masovosti odberu a tedy i vyroby dopomuze k nizsim cenam i pro ty ostatni.)

Asi jsem méně bystrý nebo nepozorný?
Bylo tu napsáno jaký display? Jestli připojen paralelně či sériově.

Mi se zpomaloval zápis na grafický-paralelní 128x64px při periodickém vzorkování AD převodníku Timer1 na 100kHz.

Pokud rádi vaříte z vody, zkuste polévky v sáčku.
Vyrábí je i číňan a koupíte ji v samoobsluze, ne v zelenině!

pgerla píše:Asi jsem méně bystrý nebo nepozorný?

Asi ano, alespoň jedno z toho.

pgerla píše:Bylo tu napsáno jaký display? Jestli připojen paralelně či sériově.

Například tam bylo napsáno, že nejpomalejší je displej přes SPI.
Ale o to vůůůbec nejde. Jde o to, jestli je kód napsaný tak, aby se obsluha motoru prováděla pravidelně a dostatečně často, což zřejmě není, takže jde o to, jak to udělat, aby byl. A je úplně jedno, jestli je displej připojený tvarohově nebo makově, v obou případech se to dá napsat správně i špatně.

Pro pfifferlinga (ale i pro jiné čtenáře, které to zajímá): velká část příkladů a knihoven, které k Arduinu jsou, funguje, jen když jsou samy. Jakmile se zkombinují, je bohužel velká šance, že to nebude fungovat tak, jak by člověk chtěl. Klasický případ jsou dvě věci, které využívají timer, ovšem obě stejný a potřebují ho přitom mít různě nastavený. To je myslím jasné, že nemůže fungovat zároveň (tenhle případ displej + motor je něco jiného, jen jsem chtěl uvést průhledný příklad). Tehdy je nutné hrábnout víc do kódu jak svého sketche, tak knihoven a udělat to jinak, například předělat filozofii programu tak, aby ta kritická věc běžela přesně jak má a až ve zbylém strojovém času to ostatní. (mezi náma, ono to často je vhodnější udělat jak psal gilhad, tj. přepsat si ten kód úplně podle svého, bez využití Arduino systému, ale to taky není pro začátečníka, který se s Arduinem teprve seznamuje)
Otázkou je, jak poznat ve fázi tvorby sketche, že tam je problém. Odpověď je v analýze zamýšleně použitých částí a pochopení, jak fungují, a to znamená koukat do zdrojáků použitých knihoven, což je práce pro začátečníky značně nejednoduchá. A zpět k tématu: my se tu můžeme pokusit pomoct identifikovat hlavní potíže, ale myslím, že stejně budete potřebovat rozumět, jak ten kód je udělaný a co se kde děje. Tedy přečíst si pořádně dokumentaci od Accelstepper i od té obsluhy displeje, zorientovat se v jejich zdrojákách a zamyslet se, jak to zkombinovat, aby to sedlo. Především co se týče časování - zjistit, co a jak často se má dělat a jak to je dlouhé. Za druhé, navrhnout si, jak tyto dvě úlohy, které mají běžet v podstatě paralelně, zpracovávat na jednom procesoru. Jde to, není to extra složité, ale už to je další level nad vypisováním na displej a točením motorem jako dvěma samostatnými aplikacemi.

pgerla píše:Pokud rádi vaříte z vody, zkuste polévky v sáčku.
Vyrábí je i číňan a koupíte ji v samoobsluze, ne v zelenině!

Vtipe, vylez.

Koukal jsem teď chvilku do toho kódu a do jakýchsi zdrojáků Nextion na webu (snad aspoň řádově podobných Vašim), a vidím:
- Nextion používá defaultně softwarový seriák, ten je blokující (tj. nevrátí se z funkce, dokud akce neskončí) a na dobu vysílání navíc vypíná interrupty
- nastavení komponenty t0 na slovo "text" znamená poslat řetězec o 13 znacích, za ním ještě navíc třikrát ff, to není málo.
Čili je jasné, že to bude fakt zdržovat.

Při použití třídy Serial Arduino potvrzování nepoužívá. To jen tak samo trvá dlouho. Hardwarový Serial je na tom líp, než SoftwareSerial, není aspoň tak výrazně blokující (viz můj popis bufferem, těch prvních několik znaků není tak dlouhých).

DavidO píše:A zpět k tématu: my se tu můžeme pokusit pomoct identifikovat hlavní potíže... Za druhé, navrhnout si, jak tyto dvě úlohy, které mají běžet v podstatě paralelně, zpracovávat na jednom procesoru.Jde to, není to extra složité, ale už to je další level nad vypisováním na displej a točením motorem jako dvěma samostatnými aplikacemi.

Doufám to zvládnete, bez toho aniž by jste znal konkrétní display

Na další pětiletku tu mám podobnou úlohu. Měření otáček DC motoru a nastavování pozice 3 krokových motorů v reálném čase. Pro bystré 3 osá frézka bez GRBL.

ad display, jak jsem psal, neni to na nem zavisle, je uplne jedno jaky displej to je, delaji to vsechny, byt je prodleva u kazdeho jina. zkousel jsem i paralelni a je to totez.

Na hrabani se v knihovnach zatim nemam a zrovna Accelstepper je celkem hutnej, nicmene tomnedele jen ta ale i jine knihovny. Z laickeho pohledu bych rekl, ze to neni uplne jednoduchy problem, protoze jsem nikde nenasel aplikaci, kde by nekdo tohle mel pouzite. Pritom treba u slideru nebo cnc se to doslova nabizi.

jinak tedy rozchodit tri krokace naraz zrovna pomoci accelstepperu neni problem. To mereni k tomu taky neni problem. Mam aplikaci dvou krokacu a k tomu mi jede jeste enkoder, naprosto bez problemu. Dokud tu hodnotu nechci zobrazit

To je právě případ té kolize. Sám AccelStepper funguje dobře i s více motory, protože s tím autor knihovny počítal a s vědomím, že je v Arduinu sám, to napsal tak, že to funguje. Ale v jednoduché (přímočaré) kombinaci s něčím dalším, co zdržuje, už ne. Ono není divu: v dokumentaci pro funkci run se píše:

You must call this as frequently as possible, but at least once per minimum step time interval, preferably in your main loop. Note that each call to run() will make at most one step, and then only when a step is due, based on the current speed and the time since the last step.

přičemž obě dvě věty jsou důležité. S tím displejem zjevně dochází k tomu, že příští zavolání stepper.run() nastane až tak pozdě, že si i člověk všimne zacukání. Třeba.

AccelStepper to dělá tak, že s každým zavoláním run() zjistí, jestli od minulého kroku uplynul aspoň čas spočítaný při posledním kroku podle rychlosti a nastaveného zrychlení, pokud ne, nic nedělá, pokud ano, udělá právě jeden krok a spočte, za jak dlouho má zase udělat. Čili aby to bylo plynulé, musí se všechno ostatní v aplikaci (zde výpis na displej) v tomhle čase stihnout a to včetně režie vlastního Arduina. To vše bez použití přerušení. Jakmile se k tomu přidá něco dalšího, co může principiálně trvat dlouho, tak mezi dvěma zavoláními stepper.run() uplyne víc času, než by mělo a když to udělá ten jeden krok, tak ten bude trvat déle, než měl.
Pokud se to má opravit, je potřeba do toho hrábnout tak, aby:
1. se kroky prováděné AccelStepperem neřídily co nejčastějším voláním run() a testováním, jestli už je čas na krok, ale hodinami (budíkem), který se nastaví na čas, kdy se má udělat další krok
2. jakákoli další činnost v aplikaci nezakazovala přerušení (nebo jen na dobu opravdu nezbytně dlouhou k přijetí události, její vyřízení pak musí být už s přerušeními povolenými). Když nebude ovlivňovat to přerušení, tak pak nebude vadit, když by trvala dlouho, protože ji třeba přeruší ten budíček od motorů, ale pak se to po obsloužení motoru zas vrátí do téhle činnosti tam, kde se přerušila
3. vykonání obsluhy přerušení pro budík na krok krokáče nebylo tak dlouhé, že by ovlivnilo nepříznivě tu činnost v 2. nebo dokonce nebylo tak dlouhé, že by mezitím už byl čas na další budík.
ad 1 - to bych si já asi napsal sám, ale chápu, že hrabat se v cizích knihovnách není snadné, takže bych na Vašem místě zkusil najít, kdo to už udělal před náma, třeba iAccelStepper.
ad 2 - tohle záleží na tom, jak se bude s displejem komunikovat. Bacha na SoftwareSerial, ten používá přerušení PCINT0-3 a v rámci obsluhy při příjmu se v něm zdrží a při odesílání zakazuje přerušení ("turn off interrupts for a clean txmit") přičemž to posílání po seriové lince je opravdu pomalé. Bacha na Serial (=HardwareSerial), ten dělá to bufferování jak jsem psal před časem a navíc pro vyřizování bufferu používá přerušení od USARTu (naštěstí ještě docela rozumně). Bacha na SPI, i2c, KZR, PZR a další, nevím sice konkrétně, jak je pro Arduino implementované, ale cosi mi říká, že tam budou podobné nabíhačky.
ad 3 - tady by mohlo nastat, že kvůli přerušení od budíku krokáče nebude komunikace s displejem na plynulá a rozsype se (tj. displej to přestane dobře přijímat). Tím by vzniknul začarovaný kruh, jehož rozetnutí by zřejmě už vyžadovalo gilhadem zmíněný postup zapomenout na Arduino a napsati si to celé sám ...

Ještě abych se ujistil, že ten projekt chápu dobře:
Kód je z příkladu "Bounce"?
Driver pro krokáč je ovládaný dvěma signály a je připojený na piny 4 (step) a 7 (direction)? (správněji by měl být konstruktor volaný místo s jedničkou s hodnotou AccelStepper::DRIVER z příslušného výčtového typu)
Driver krokuje na náběžnou hranu signálu step?

Jestě mě napadla taková prasá... chci říct neortodoxní řešení, až se to skoro stydím napsat pod vlastním loginem: v ideálním případě se run zavolá těsně po vypršení toho času mezi jednotlivými kroky. Když se zavolá těsně před ním, tak hned na začátku zjistí, že ještě čas nenastal a skončí a tím pošvihne příležitost, a když by se volala ne tak moc často, tak to zrovna v tuhle chvíli zakulhá. Tak mě napadlo, že by se to dalo malinko upravit a na začátku run zkontrolovat, jestli je čas ne "víc, než co jsem chtěl", ale jestli do vypršení zbývá méně než epsilon a v takovém případě si prostě na hulváta počkat do toho času.

Samozřejmě to neřeší problém, že komunikace v loop sebere tolik času, že by se mezitím mělo udělat kroků víc. To by se dalo upravit tak, že by se místo vždy jednoho kroku udělalo v rámci jednoho zavolání run tolik kroků, kolik se jich od minule mělo udělat - teda pokud je přijatelné, že po delším výpadku pak náhle motor rychle poskočí a dohání zmeškané (teď se to podle mě chová tak, že motor jakoby usne a po probuzení pokračuje stejně jako kdyby nespal). Ale při výpadku jen málo kroků by to mohlo chování zlepšit. Takže v runSpeed zaměnil if za while a _lastStepTime by se místo doskočení na aktuální čas jen posunul o _stepInterval. Ten by se samozřejmě musel nechat přepočítat (computeNewSpeed();) a taky by asi bylo potřeba počkat s vykonáním dalšího kroku nějakou chvilku protože mechanicky motor nemůže reagovat tak rychle, jak se vykonává program (to jde spočítat z maximálních skutečně dosažitelných otáček a počtu kroků na otáčku konkrétního motoru).

Výše popsané neřeší podstatu problému, jen obchází a to ještě kdoví jestli.

Já bych se jen optal, o jakých frekvencích respektive otáčkách motoru se tu bavíte? Třeba by se to dalo řešit bez té knihovny pro motor. Mám pocit, že například pro ten slider by to nemuselo být zase až tak kritické.