[elektro] gyakorló ATMEL-sekhez kérdés

[hg12345]

Hi,

Biztos hatásos....

Ennél sokkal egyszerűbb megoldás, üzembiztosan működik....
- nincs RAM alapú függvény pointeres hívás
- a teljes program folyamatos CRC32 ellenőrzéssel
- folyamatos RAM validitás ellenőrzés
- készülékre jellemző adat, mindig frissen EEPROM-ból cache-b keresztűl elérve, 200ms öregedési tényezővel.
- belső értelmezők és interpreterek mindig flash-ből futnak, fordításkor felépített adathalmazokról
- mindenféle hiba számlálás és HW ellenőrzés.

Eddig amiket láttam működésben ott a hiba számlálók nullán voltak....



Info <info at kiralyelektronika.hu> írta:
>Valóban, sokat gondolkoztam rajta.
>Most úgy írtam meg egy oprendszert, hogy a RAM-ban lévő
>felügyelet nélküli adatok élettartama <20ms legyen.
>Az IT verme nyilván megfelel a kritériumnak, a taszkokét
>külön kezeli a proc, és váltáskor le-CRC32-zöm, betöltéskor
>csekkolás, ha nem egyezik RESET.
>Az júzer drivereit minden taszkból, IT-ből kétféleképp hívom:
>vagy 3 változóban a cím, és 2 egyezése esetén elfogadás+javítás,
>nem egyezéskor reset, vagy táblázat flashban és index, ami nem
>lehet sosem 10-nél nagyobb, így nem ugrik messzire :)
>Meg még pár apróság, nem lényeges.
>Kíváncsi leszek az eredményére, pár év után milyen lesz.
>
>> Helló!
>
>> Ilyen környezetben ez már nem oszt nem szoroz: a stack is a a memóriában
>> van és ha a visszatérési cím felülíródik akkor úgyis annyi.
>
>> Üdv
>
>
>> 2014. április 14. 11:52 hg12345 írta, <hg12345 at freemail.hu>:
>
>>> A megbízhatatlant  úgy értem, hogy elektromos zajjal erősen terhelt
>>> környezetben (ami túl mutat az EMI/EMC ajánlásokon) ( pl.: kis hazánkban a
>>> készülékeink 95% ilyen környezetben müködik :-(
>>> Nem biztos, hogy a main() függvény elején felinicializált függvény
>>> pointerek  365nap folyamatos üzem után is oda mutatnak. De még egy nap
>>> múlva se.
>>> Persze vannak megoldások erre is, HW támogatott hibajelzéssel védett RAM
>>> területes eszközök is kaphatóak.
>>> Amúgy minden megoldható, de még egy programozott újra indulás se
>>> szerencsés mert erősen látszik a szabályozott, vezérelt folyamaton.....
>>>
>>> Szerintem sokkal egyszerűbb, ha egy ilyen eszközben a program úgy van
>>> megírva, hogy minimális a RAM-ban elhelyezett nem vagy nehezen
>>> ellenőrizhető kódja, vagyis ilyen függvény pointereket én kihagynám.
>>> Egyébként se ad tömör kódot, szóval 40K program+adat 4 sor C programért
>>> elég sok, ez normál programozással, kb. 3-4K lenne.
>>>
>>> üdv
>>>
>>>
>>> Lajos Rancz <lajos.rancz at gmail.com> írta:
>>> >Helló!
>>> >
>>> >A megbízhatatlant nem értem! A C++ virtual függvények is így működnek
>>> (igaz
>>> >ott a compiler intézi). Nagyon sok helyen használják ezt.
>>> >
>>> >Üdv
>>> >
>>> >
>>> >2014. április 13. 9:51 hg12345 írta, <hg12345 at freemail.hu>:
>>> >
>>> >> Köszönöm ez bevált.
>>> >>
>>> >> Még egy kérdés, ez teljesen normális ATMEL körökben, hogy mindent a
>>> >> indirekt RAM-ban elhelyezett függvény pointereken keresztül csinálnak
>>> meg?
>>> >> Azért ez nem növeli az üzembiztonságot és kód tömörséget!
>>> >>
>>> >> Persze nagyon flexibilis lesz tőle a program (és megbízhatatlan), de nem
>>> >> ingyen adják 4 sor program C-ben 40K FLASH területet foglal!? Na kicsit
>>> >> ferdítettem optimalizálva csak 35K. :-)
>>> >>
>>> >> Mégegyszer köszönöm a segítséget
>>> >>
>>> >> üdv
>>> >>     G
>>> >>
>>> >> r3flow <nzoltan at freemail.hu> írta:
>>> >> >
>>> >> >
>>> >> >On 2014-04-12 19:38, hg12345 wrote:
>>> >> >> Próbálom használom az ASF-t, pont eddig jutottam
>>> >> >
>>> >> >
>>> >> >ASF-ben meg van írva a _write() és a _read(), a a "Standard serial I/O
>>> >> >(stdio)" modulban. Ha a projektedhez hozzáadtad ezt a modult akkor ne
>>> >> >írt meg a _write()-ot, ez esetben az stdio_serial_init() függvénnyel
>>> >> >tudsz adott USART-ot inicializálni úgy, hogy az egyúttal az stdio
>>> >> >kimenete is lesz.
>>> >> >
>>> >> >Üdv,
>>> >> >Z.
>>> >> >
>>> >> >-----------------------------------------
>>> >> >          elektro[-flame|-etc]
>>> >>
>>> >> -----------------------------------------
>>> >>           elektro[-flame|-etc]
>>> >-----------------------------------------
>>> >          elektro[-flame|-etc]
>>> >
>>>
>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>
>-----------------------------------------
>          elektro[-flame|-etc]