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

[r3flow]

Cortex-R-ből van hibatűrő kivitel

8. oldal pl.
http://event.on24.com/event/69/75/40/rt/1/documents/slidepdf/tifinal2a.pdf

- Physical separation: CPUs separated and rotated on the die
- 2nd CPU delayed by 2 clock cycles
- ECC memória

stb.


On 2014.04.14. 14:24, Info wrote:
> 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]
>