Elektroda.pl
Elektroda.pl
X
CControls
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[STM32][C] FreeRTOS sterowniki peryferiów i semafory

Jagged 11 Lis 2010 19:02 1980 5
  • #1 11 Lis 2010 19:02
    Jagged
    Poziom 10  

    Witam,
    Przeglądam przykłady freeRTOS i widzę tam drivery peryferiów. Zdziwiłem się, gdy zobaczyłem, że np driver do SPI jest żywcem wzięty z przykładów ST (SPI_Flash_ST_Eval).

    I tu się rodzi moje pytanie:
    1. Dlaczego takie "drivery" nie dbają o to by tylko jeden proces mógł korzystać z SPI?
    2. Co się stanie jeśli dwa wątki będą korzystać równocześnie z tej biblioteki do SPI?
    3. Czy powinienem dopisać tam semafory, a jeśli tak, to dlaczego twórcy przykładu tam nie dali semaforów?

    pozdrawiam

    0 5
  • CControls
  • #2 11 Lis 2010 19:14
    nsvinc
    Poziom 35  

    1) bo nikomu nie chcialo sie pisac driverow takich, jakie powinien miec system operacyjny, tj takich, ktore albo multiplexuja, albo miksuja, albo udostepniaja procesowi wylacznosc.

    2) Wszystko sie spi***oli, i nic nie bedzie dzialac. Ten sam soft (w sensie procedury) wykonaja sie z roznymi parametrami gdzie miejsce na ktorym procedury operuja jest zawsze to samo. A jesli sterownik chodzi z procesu, no to dwie instancje tego sterownika wyprodukuja taki bajzel w ustawieniach, ze nie opanujesz tego.

    3) Nie musisz, jesli wiesz co piszesz. Jesli chcesz po prostu naficzerowac sterownik lub go poprawic, to wtedy:
    - po pierwsze, zamiast dopisywac semafory, napisz freeRTOSowi nowy naglowek (typ) taska, z argumentem, ktory definiuje to, kto, kiedy, po co i w jakich okolicznosciach proces moze sobie przydzielic bufor w ktore wpakuje dane (ktore inny watek rozpakuje i zmultipleksuje/zastapi/doda/cos_innego a nastepnie wyrzuci np. po SPI). Itd, itp etc...

    Nie dlugo, 22, napisze dokladnie (dla potomnych) jak to zrobic :]

    0
  • CControls
  • #3 11 Lis 2010 19:18
    michalko12
    Specjalista - Mikrokontrolery

    Ad.1
    Takie życie...

    Ad.2
    NIc sie nie stanie, tylko program moze róznie działać w zalezności jak sie zsynchronizują wątki tzn raz będzie działał a raz nie.

    Ad.3
    Musisz dopisac mutexy, a nie dopisali tego autorzy ponieważ są to źródła FreeRTOSa, a to co jest dołaczone jest napisane tylko na potrzeby dem załączonych do tych źródeł i najwyraźniej tam nie były potrzebne.

    0
  • #4 11 Lis 2010 20:21
    nsvinc
    Poziom 35  

    michalko12 napisał:
    Ad.2
    NIc sie nie stanie, tylko program moze róznie działać w zalezności jak sie zsynchronizują wątki tzn raz będzie działał a raz nie.


    No ok :] Skoro dla Ciebie raz_dziala_raz_nie != nie_dziala, to trwoga...
    Jesli juz precyzowac, niewiele zalezy od synchronizacji watkow. Zalezy od uzycia danego peryferium. Im czesciej watki beda konkurowac o jedno peryferium w trakcie gdy jest ono w trakcie pracy (glownie DMA!), to jedna transmisja bedzie rozwalac druga. Wyobraz sobie dane w EEPROMIE co sie z nimi stanie jak watki beda sobie wchodzic w droge w dostepie do peryferium i kazdy zapisze gdzie indziej co innego.

    Jesli watki nie robia w SPI zadnych specjalnych initow, a pracuja na tych samych ustawieniach i kazdy watek wrzuca jakies dane do SPI->DR, to whiskas. Wyleci:
    [Watek1#1][watek2#1][Watek1#2][Watek2#2]
    Miedzy innymi problemem jest wybor chip select-a, bo jesli dwa watki gadaja przez jedno SPI z dwoma innymi scalakami, to nie wolno przerwac zadnemu z nich transmisji poprzednika w momencie przelaczenia watka.
    W tym przypadku wypada albo:
    1) nie przelaczac watkow w trakcie transmisji + polling flag... [tragedia]
    2) posrednio buforowac dane z portow, stworzyc konkretny format pakietu ktory watki beda wrzucac do FIFO, watek drivera bedzie przelaczac CS/predkosc/inne w zaleznosci od targeta, no i jechac przez DMA w cyklu wybudz -> przekonfiguruj i poustawiaj co trzeba -> wlacz_dma -> idz kimac..
    Ale to juz dosyc zaawansowany sterownik. Moglby obslugiwac multiplexowanie jednej magistrali miedzy watki.

    mozna tez prosciej, po prostu na przerwaniach od DMA, jedno FIFO TX, jedno FIFO RX, bez ekstra watka, ale wtedy zapychanie kolejki jest utrudnione, bo yield nie moze wystapic w trakcie modyfikacji wskaznikow kolejek wiec semafory. No i trzeba wylaczyc przerwania te ktore modyfikuja te wskazniki.
    Ale wtedy az sie prosi o demux RX, zeby do watkow trafialy tylko interesujace ich dane. Albo podczepiac gotowy RX pod pakiet (ten ktory wrzuca sie do FIFO), i watki maja znac wskazniki swoich RXow.

    Jest tutaj sporo rozwiazan...

    0
  • #5 11 Lis 2010 22:21
    michalko12
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    No ok :] Skoro dla Ciebie raz_dziala_raz_nie != nie_dziala, to trwoga...


    nsvinc "nie odbieraj" życia zbyt poważnie ;)

    Nie do końca chyba zrozumiałes ton mojej wypowiedzi.

    0
  • #6 23 Lis 2010 18:13
    kapw
    Poziom 12  

    nsvinc napisał:

    3) Nie musisz, jesli wiesz co piszesz. Jesli chcesz po prostu naficzerowac sterownik lub go poprawic, to wtedy:
    - po pierwsze, zamiast dopisywac semafory, napisz freeRTOSowi nowy naglowek (typ) taska, z argumentem, ktory definiuje to, kto, kiedy, po co i w jakich okolicznosciach proces moze sobie przydzielic bufor w ktore wpakuje dane (ktore inny watek rozpakuje i zmultipleksuje/zastapi/doda/cos_innego a nastepnie wyrzuci np. po SPI). Itd, itp etc...

    Nie dlugo, 22, napisze dokladnie (dla potomnych) jak to zrobic :]


    przypominamy ...:P

    0