[elektro] FreeRTOS periferia muveletek vedelme

[potyo]

Nem FreeRTOS, de nyilvánosan nem szeretném mondani, mi volt a cég
neve (privátban lehet esetleg), de fizetős cucc volt, és ilyenek voltak
benne. DSP proci modulra szerelve, és hozzá árulták a különféle stack-eket.
Az első gond, amit észrevettünk az az volt, hogy a ping kérések 30%-ára nem
jött válasz közvetlen switch-el összekötve, ezt viszonylag gyorsan
javították is, amikor jeleztük a hibát. De voltak ott még egyéb tákolások
is, pl. az Ethernet PHY driverben, amit teljesítményoptimalizálás miatt nem
épp úgy oldottam volna meg, ahogy meg volt oldva, bár az csak nagyobb
terhelésnél okozott volna problémát, odaáig meg igazából el sem jutottunk
igazán... Pedig már 4.1 vagy 4.2 verzió volt nálunk először, és a
megrendelő ebből akart egy elég jelentős megbízhatósági mutatóval szerelt
cuccot faragni. Hát szerintem nem jött össze végül nekik, de én meg közben
elhagytam a céget, nem tudom mi lett a projekt vége...

2015. december 22. 9:13 Lajos Rancz írta, <lajos.rancz at gmail.com>:

> Hello!
>
> Itt én elég nagy tervezési hibákat látok (ezek a FreeRTOS-ban voltak?):
>
>
>    1. Real-time taskba nem teszünk (valódi) malloc-ot, mivel a futási ideje
>    nem állandó; innentől kezdve nem lehet semmilyen futási idő megkötést
>    vállalni
>    2. IRQ-t sosem tiltunk (bár kényelmesnek tűnik, de pont ilyen szívások
>    lesznek belőle)
>
> Üdv
>
>
> 2015. dec. 21. 18:27 ezt írta ("potyo" <potyo.ada at gmail.com>):
>
> > Jól. A taskváltás ütemezőjénél magasabb prioritású legyen az az IRQ, amit
> > nem akarsz, hogy megszakíthasson a taskváltás. Ami magas prioritású
> > kiszolgálást kell, hogy kapjon, az fölé nyúl az OS-nek és saját
> > megszakításkezelő rutinban kezelődik le, mint hagyományos esetben.
> > Szerintem jobban szétnézel, találsz is erre példa kódot az OS-ben.
> >
> > Rosszabb esetben valamelyik task dinamimusan akar memóriát foglalni, a
> > szabad hely keresésének idejére lekapcsolja az IRQ-kat, aztán bejön egy
> > stop és egy start esemény az I2C buszon, amik egymásra futnak, és onnan
> nem
> > tudod, hogy mi hogyis volt. Megtörtént eset, több hetet szívtunk vele,
> mert
> > hát elsőre az ember mindenre gondol csak ilyenre nem, majd írtunk a
> > supportnak, mire kiadtak egy új verziót, aminek a leírásába belevették,
> > hogy ne használjuk pl. I2C slave-re. Hát kösz szépen a fizetős
> supportot...
> >
> > 2015. december 21. 17:27 Moravcsik Szilard írta, <
> > levlista.mszilard at gmail.com>:
> >
> > > 2015.12.21. 16:47 keltezéssel, hg12345 írta:
> > > > Ha biztosra akarsz menni, akkor az IT megszakítás szintet, magasabbra
> > > állítod mint az RTOS alapidő IT-jét.
> > > > Amúgy állítható a task szintje is.
> > > >
> > >
> > > Ez azt jelenti, hogy egy taskot megszakíthasson az IRQ, de az IRQ-t ne
> > > szakíthassa meg egy taskváltás (ütemező), ha jól értem?
> > >
> > > Üdv:
> > > Szilárd
> > >
> > > > Moravcsik Szilard <levlista.mszilard at gmail.com> írta:
> > > >> Sziasztok!
> > > >>
> > > >> Egyáltalán nem használtam még RTOS-t, ezért lehet, hogy butaságot
> > > kérdezek.
> > > >>
> > > >> Szóval hogyan lehet megoldani egy taskban, hogy egy perifériával
> > történő
> > > >> kommunikációt illetve elemi műveletsort (USART, I2C, SPI, EEPROM
> > > >> írás/olvasás, stb.) ne szakítson meg egy rosszkor jött task váltás?
> > > >>
> > > >> Régóta készülök lelkiekben a címbeli RTOS-szal történő
> > megismerkedésre,
> > > >> de elég sok a homályos dolog vele kapcsolatban.
> > > >>
> > > >> Egyébként a tanuló hardver elsősorban STM32F4xx Discovery vagy
> Nucleo
> > > >> lesz. Talán AVR xmegával is eljátszanék: xmega384C3 Xplained, 32kB
> > RAM,
> > > >> 384kB flash, DMA-k, 32MHz belső órajel, szóval hátha bírná az
> > RTOS-t...
> > > :)).
> > > >>
> > > >> Üdv:
> > > >> Szilárd
> > > >>
> > > >> U.i.:
> > > >> A ChibiOS nevű RTOS-t ismeri valaki? Érdemes lenne inkább annak
> > > >> megtanulásába fektetni az energiát, szemben a FreeRTOS-szal?
> > > >>
> > > >>
> > > >> ---
> > > >> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus
> > > védelme ellenőrizte azt.
> > > >> https://www.avast.com/antivirus
> > > >>
> > > >> -----------------------------------------
> > > >>           elektro[-flame|-etc]
> > > >>
> > > >
> > > > -----------------------------------------
> > > >            elektro[-flame|-etc]
> > > >
> > >
> > >
> > > ---
> > > A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus
> > > védelme ellenőrizte azt.
> > > https://www.avast.com/antivirus
> > >
> > > -----------------------------------------
> > >           elektro[-flame|-etc]
> > >
> > -----------------------------------------
> >           elektro[-flame|-etc]
> -----------------------------------------
>           elektro[-flame|-etc]
>