Leniví to při pípání, jednou se mi stalo, že se na displeji objevily nesmysly a rádio se vyplo. Ale to jsem byl až na hraně, chťa ho dorazit.
Ale kolem těch 250 se pomaleji překresluje displej, občas tam problikávají jiné řádky než se displej "usadí". FUngovat to funguje. Jak říkám, Když nemože, tak prostě nějaký mix přestane zpracovávat...
Pípal jsem třeba 4servové křídlo se "vším" a při připípání funkce křidélek na klapky přestalo chodit krajní křidélko. Po restartu vysílačky křidélko chodilo, ale výškovka přestala reagovat na pohyb kniplem.

Prostě, jak je tam 250 a víc, člověk musí bejt vopatrnej

_________________
________________________________
Modeláři sobě http://www.ok-rimr.com

Viem že niekto to skúšal prekompilovať s nastavením max riadkov na 64 (namiesto 32), ale nechodilo to a ďalej to neskúmal. Či to bol len formát pamäte alebo čo, to neviem. Stálo by to za lepšie prezretie, aby tam nebolo také nezmyselné (podľa mňa) obmedzenie - ale ani neviem či vyhradená pamäť je variabilná alebo nie (ak je, tak pri každom vložení musí všetko posunúť a prehádzať odkazy na celé modely??)

Jó tak to já netuším, na to jste jiní ptáčci co se v tom vyznáte
Já jen empiricky rýpu klackem do ho*na a čekám co to udělá

_________________
________________________________
Modeláři sobě http://www.ok-rimr.com

to RiMr:

neviem preco tiu to robi, ale teraz som si pozeral a mam tam 2 modely cez 260 a rychlost v pohode, ziadne spomalenie.

_________________
http://bobo.matej.name

Možná to souvisí z dobou od "restartu".
Například v té poslední lekci, když na klapky přidám křidélka, někde něco vypadne. Budu k těm lekcím dávat EEPROM na stažení, můžeš si to vyzkoušet, jestli až přidáš pár mixů ti někde něco "ufoukne"
(ufoukne, zkoušeno na více rádiích )

_________________
________________________________
Modeláři sobě http://www.ok-rimr.com

To je bug, jasný neodškriepiteľný (tak sa rádio nesmie správať), a je aj ohlásený a nesledoval som čo nasledovalo, ale neverím že tak zostane naveky. Niekde som videl návrh nech to jednoducho nedovolí pridať nový a zapípa...

No chlapci přidali varování na snížení celkové velikosti volné paměti. Údajně to varuje i při přidávání mixů. Ale nevim nevim. Dřív než bych něco takového byl schopen zahlídnout, tak "dávno" před tím začne haprovat funkčnost jako taková...

_________________
________________________________
Modeláři sobě http://www.ok-rimr.com

Bolo by to dobre presne identifikovať, či sa tam neprejaví aj niečo ďalšie (napr. že okrem mixov tam je viac nejakých podmienok, kriviek, neviemčo?) a potom ohlásiť oficiálne.
- Lebo samotných 32 riadkov bolo vraj vyriešené (ohlásené 1.5 a riešené 13.5 )
http://code.google.com/p/er9x/issues/detail?id=277

No nevím... Mám r357 a žádné varování se nekoná...

A jak říkáš, nebudou to jen řádky. Já tam mám třeba 8 Soft. spínačů. TO musí taky něco sežrat

_________________
________________________________
Modeláři sobě http://www.ok-rimr.com

Jazyk C, ve kterém je firmware ER9X psaný, má výhody v tom, že patří k těm rychlým, ale na druhou stranu má i nevýhody v tom, že řadu věcí neřeší a v rámci jazyka ani netestuje a ponechává je zcela v režii programátora, který se o ně musí velmi dobře postarat jinak se může dočkat dost záludných nesyntaktických chyb a neočekávaného chování programu, které ani překladač neodhalí.

V tomto ohledu je otázkou nakolik jsou veškeré alokace paměti v rámci firmware ER9X ošetřeny ve vztahu k reálnému množství dostupné paměti, která je používána pro příslušné datové struktury programu v cílovém zařízení. Pokud to není ošetřeno a jen se zvedne nějakou definicí požadovaná velikost paměti tak to může být problém. Pokud velikost alokací prováděných za běhu programu přesáhne velikost dostupné paměti v rámci cílového zařízení pak to může mít v případě nevhodného ošetření ten následek, že různé části programu pak pracují s kusy paměti, které sice považují za vzájemně se nepřekrývající, ale v reálu se tyto kusy paměti překrývají a tak dochází k neočekávanému chování programu ve smyslu vzájemnému přepisování některých částí paměti.

Problém tam bol diskutovaný len s veľkosťou stack ktorá rastie každým vnoreným volaním funkcií, a do toho aj pridávajú volania prerušení. Aj tú veľkosť pridali do diagnostiky... Ale to im rástlo kvoli pridávaniu telemetrie frsky ak sa nemýlim.
Keby sa to naozaj stretlo tak by mal podľa mňa program spadnúť.. aj keď za letu radšej nie, nech pokračuje aspoň jeho časť ...

Lenže hĺbka vnorenia nemá dôvod závisieť na počte riadkov po ktorých postupne prechádza. Ak by to pretieklo, tak asi kedykoľvek aj na modeli s dvoma servami, a pár bajtmi nastavenia - akurát so správnou kombináciou viacerých vnorení....

Teraz neviem, ale dúfam že logické switche to vyhodnotí na začiatku a nie pri každom použití?!? To by možno bola schodná cesta do pekla, keby ich to nejak volalo pri každom použití v každom riadku (aby reagovali na aktuálne hodnoty, mohlo to niekoho napadnúť... keď bude čas pozriem).

V rámci zařízení T9X neběhá žádný paměťový manažer na úrovni operačního systému ani operační systém jako je zvykem u jiných sofistikovanějších zařízení. Paměťový manažer na úrovni operačního systému různé podobné chyby zachytává a případně následně způsobuje odstavení programu, ale v rámci ER9X nic takového není. Takže různé chyby v alokacích nevedou k "pádu programu", ale spíše k různému vzájemnému přepisování částí paměti s alokovanými daty.

Narýchlo: pre každý riadok "mixov" sa ako prvé testuje či má byť aktívny (nastavený switch je true), pričom sa vždy volá
bool getSwitch(int8_t swtch, bool nc, uint8_t level)
...
ktorý v ER9x.cpp začína riadkom:
if(level>5) return false; //prevent recursive loop going too deep
....
takže tam vidím celkom dobrú možnosť že to Rimrovi tých 8 logických switchov pri správnom zreťazení a dostatočnom počte volaní, aj spomalia, aj možno že zhodia.
Chcelo by to nájsť model kedy to naozaj pekne blbne a pri ktorej kombinácii prepínačov konkrétne, možno by sa našlo že 5 je moc?
Nebolo to ale aj tak že pridanie logického switchu spôsobilo že niektorý iný prestal reagovať? Lebo to mohlo dosiahnuť 5 rekurzívnych vnorení a ten ochranný test (niekto na to myslel) to zastavil a teda sa nevykonali a možno sa neaktivoval mix ktorý bol inak zapnutý....?
Tá podmienka to zastaví úplne potichu, bez varovania.
Je to len hádanie z ničoho a možno som netrafil, ale pripadá mi to logicky.

Našťastie, a preto to nehádže takzvaný BSOD (Windowsácka "modrá obrazovka smrti") s citátom Božího poselství k veškerému stvoření ("ospravedlňujeme se za způsobené potíže").
CPP kompilátor je v tomto prípade dosť vymakaný a osobne mu verím - nie že by mi nedovolil hrabať sa v kóde namiesto čísel, ale aspoň varovanie by napísal.
ER9x nie je napísaný nijak optimálne a ani príliš čisto, ale zato nie je ani natvrdo nadrátovaný s chaotickými prístupmi do pamäte a všetko je pekne cez odkazy. Ak nepretečie ten zásobník, nečakal by som problémy (hlavne nie také ktoré by sa prejavili len raz za čas - ak tam bude bug tak sa prejaví včas a pekne výrazne).
Neviem o tom že by to niekomu mrzlo - keby si to hrabalo náhodne po pamäti, vyzeralo by to inak.
Verím že u Rimra by sme to mohli vysvetliť tými piatimi vnoreniami logických switchov a následným vrátením False namiesto správnej hodnoty.

Dám na web z domu tu EEPROM a můžete vyzkoušet ty SW switche vyházet a dát tam normální. Já už balím do Anglie a ještě musím dodělat Čmeláka, bych ho protáhnul hrdým ALbionem

_________________
________________________________
Modeláři sobě http://www.ok-rimr.com