logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak zapewnić efektywną komunikację między dwoma uC z minimalnym obciążeniem?

arturromarr 25 Cze 2012 13:41 2184 17
REKLAMA
  • #1 11039903
    arturromarr
    Poziom 17  
    Witam
    Mam pytanie jak sprzętowo zapewnić komunikację pomiędzy dwoma uC tak by jak najmniej je do niej angażowała.
    Sprawa wygląda tak że jest pewna pula (np 100) danych które muszą być widoczne i edytowalne dla obu procesorów (jakieś megi). Jeden z nich będzie wykonywał pomiary i główny program zaś drugi będzie je wybiórczo (wskazane przez użytkownika) pokazywał oraz pozwalał konfigurować prace pierwszego.
    Chodzi o to że jak np pierwszy sterownik robi pomiar i zmienia wartość tylko jednej zmiennej, żeby nie był spowolniony ciągłymi zapytaniami drugiego o np. 20 zmiennych
    Wygląda skomplikowanie ale chcę rozdzielić pomiar od wizualizacji tak by nic nie mogło go spowolnić.
    Wymyśliłem sobie że idealnym buforem który powodowałby że oba kłady nie widzą się była by pamięć z dwoma interfejsami. Wtedy jedna komórka pamięci mogła by być odczytywana i zapisywana (oczywiście nie jednocześnie) przez obydwa procesory, ale czy coś takiego jest dostępne czy to tylko moja wybujała wyobraźnia? :)
    Jeśli nie to jak to rozsądnie rozwiązać?

    Pozdrawiam
  • REKLAMA
  • #3 11040031
    dondu
    Moderator na urlopie...
    arturromarr napisał:
    Chodzi o to że jak np pierwszy sterownik robi pomiar i zmienia wartość tylko jednej zmiennej, żeby nie był spowolniony ciągłymi zapytaniami drugiego o np. 20 zmiennych

    Wygląda skomplikowanie ale chcę rozdzielić pomiar od wizualizacji tak by nic nie mogło go spowolnić.

    Jakie pomiary i jaką wizualizację robisz, że boisz się spowolnienia?
    Opisz dokładniej, ponieważ być może idziesz w niewłaściwym kierunku, utrudniając sobie zadanie.
  • REKLAMA
  • #4 11040719
    tmf
    VIP Zasłużony dla elektroda
    No właśnie, dobrzy by było gdyby autor sprecyzował założenia projektu. Bo może się okazać, że da się to zrobić na jednym procku, bez spowolnienia. Taki więc, jakie to pomiary i jak często? Na czym polega wizualizacja?
    Jeśli koniecznie chcesz na dwóch to dobrym rozwiązaniem jest synchroniczny USART - mega ma rejestry USART podwójnie buforowane, co ułatwia rozkład obciążenia. Synchroniczność z kolei sprawi, że nie będzie kłopotów z wymianą informacji. Jeśli i to za mało, to można wziąć większy procek, np. ze stajni AVR XMEGA. Raz, że masz procek o 1/3 szybszy, to jeszcze możesz zrobić synchroniczny USART z wykorzystaniem DMA, co praktycznie zapewni brak obciążenia obu procków. Pamięć dwuportowa to raczej ciekawostka :)
  • #5 11041325
    drzasiek
    Specjalista CNC
    tmf napisał:
    można wziąć większy procek, np. ze stajni AVR XMEGA. Raz, że masz procek o 1/3 szybszy, to jeszcze możesz zrobić synchroniczny USART z wykorzystaniem DMA, co praktycznie zapewni brak obciążenia obu procków. Pamięć dwuportowa to raczej ciekawostka :)


    Jak już xmega, to chyba można jeszcze lepiej.
    Połączyć PORT<->PORT i w "Masterze" uruchomić Timer taktujący DMA, wygenerować z niego dodatkowo zegar na zewnątrz. W "Slave" Timer taktować zegarem z Mastera a DMA przerzuci port do pamięci. Teoretycznie to chyba 4MBps, nie?
  • #6 11041670
    gaskoin
    Poziom 38  
    Czemu z góry zakładacie, że autor używa AVR ? Równie dobrze może to być Blackfin albo EFM albo cokolwiek innego.
  • REKLAMA
  • #8 11041785
    LordBlick
    VIP Zasłużony dla elektroda
    A czemu Ty zakładasz, że oni zakładają ? ;) Każdy tylko proponuje rozwiązania mu najbliższe... ;)
    Co do tematu, bez doprecyzowania o jaki przepływ danych trudno coś dokładniej zaproponować Z reguły wizualizacja na typowym wyświetlaczu nie potrzebuje zbyt dużego przetwarzania danych. Chyba, ze jest jakaś nietypowa, typu wirujące LED-y, procesor robiący za kontroler LCD itp.
  • REKLAMA
  • #9 11043520
    arturromarr
    Poziom 17  
    Bardzo dziękuję za dyskusję.
    Dobrze zakładacie że atmele. :) (niestety becnie nie miałem do czynienia z innymi)
    Wizualizacja prosta na wyświetlaczu i możliwość transmisji praktycznie wszystkich danych modbusem po rs-sie, więc przy dużej częstotliwości "odpytań" może pochłonąć całkowicie procka.
    Pomysł z pamięcią by mi pasował bo szybko bym wiedział jak to wykonać.
    Robiłem już podobny układ ale wymieniałem jedynie trzy bajty, więc scalaki były połączone portami bezpośrednio. Działało bardzo wydajnie jak na dwie zwykłe megi i stabilnie. układ odczytujący również coś regulował więc nie mogło być ryzyka spowolnienia przez odczytywanie danych.
    Chyba zrobię tak że połączę dwoma portami (dane i adresy) obydwa uc i pierwszy będą do siebie nadawały zmiany, ale pojawią się problemy synchronizacją, kierunkiem transmisji boję się że to spowolni pracę całości.

    Dzielenie zasobów przez osobne układy interesuje mnie również z powodów "akadmickich", chciałbym zwyczajnie potestować takie rozwiązanie.
  • #10 11043563
    LordBlick
    VIP Zasłużony dla elektroda
    Wszystko, co piszesz o zajętości µC przez Modbus to są zabobony (prędkości transmisji nie są w tej magistrali zbyt oszałamiające, a przecież sprzętowy RS bufor jest podwójny w AVR) - mam skończony projekt, w którym ATmega164@11,0592MHz gada z falownikiem, pisze do LCD co 200ms, po tych samych liniach odczytuje klawiaturę i robi jej debouncing, obsługuje programowy PWM do RGB LED, zapisuje parę bajtów po SPI do FRAM, obsługuje podwójną barierę IR(blokada bezpieczeństwa), załącza grzałkę (taka specjalna żarówka) bez błyskania w trybie zredukowanej mocy sterowania grupowego, obsługuje cały automat zdarzeń i nie wygląda na to, aby się pociła, bo jeszcze daje radę w trybie odpluskwiania "zeznawać" mi po drugim USART-cie, to co chcę. Raczej obstawiałbym, ze używasz blokującego kodu i wydaje się, ze procesor się "nie wyrabia", a tak naprawdę każesz mu się obijać w jakiejś lewej pętli typu waitms() w czasie, gdy mógłby spokojnie robić co innego.
  • #11 11043615
    arturromarr
    Poziom 17  
    No ale moje procki maja robić jeszcze kilka rzeczy, lcd, przerwania pomiary więc nie będą odpoczywały.
    Pewnie najłatwiej było by wziąć jakiś lepszy uc, ale teraz muszę uporać się z tematem nie ucząc się nowej architektury. (choć widać że trzeba będzie niedługo)
    Zwykłe megi nie mają DMA chyba, jak to się w ogóle "je", od czego zacząć, są w necie jakieś przykłady?
  • #12 11043661
    LordBlick
    VIP Zasłużony dla elektroda
    arturromarr napisał:
    Zwykłe megi nie mają DMA chyba,
    Ale mają obsługę przerwań jak najbardziej.
    arturromarr napisał:
    są w necie jakieś przykłady?
    Na pewno są, tylko musisz wiedzieć konkretnie o jakie przykłady chodzi...
  • #13 11043764
    arturromarr
    Poziom 17  
    Przerwania będą mi potrzebne do innych celów, poza tym ich obsługa raczej by normalnie obciążała procesor.
    Pytając o przykłady DMA chodziło mi oczywiście o mój post, czyli wymianę danych pomiędzy układami, może skusze się na XMEGA, jeśli to nie jest bardzo skomplikowane. ATXMEGA32D4-AU nawet nie drogi, tylko jako amatora troszkę mnie niepokoi zasilanie do 3,6V bo dotąd wszelkie peryferia projektowałem w standardzie TTL.
  • #14 11044377
    tmf
    VIP Zasłużony dla elektroda
    Jak już ją kupisz i będziesz miał problem z DMA to pytaj, to ci pomogę. Pomimo strasznej nazwy sprawa jest prosta - ustawiasz adres źródła (rejestr UDR), adres przeznaczenia (wspólny obszar pamięci współdzielony przez oba MCU), ustalasz parametry transmisji (autopowtarzanie, triggery) i... zapominasz o tym. Wszystko robi się dalej samo. Dzięki temu dostaniesz obszar pamięci współdzielony przez dwa MCU przy pomocy USART, jedyna wada, że pamięć będzie miała dostęp sekwencyjny, a nie swobodny, ale to chyba nie problem. Z drugiej strony, XMEGA ma do 32 MIPSów i lepiej rozwiązane peryferia, więc niewykluczone, że po prostu zmieścisz się w jednym MCU. Prawdę mówiąc do tej pory jedyne co mnie przekonuje do dwóch MCU to podany przez ciebie argument "powody akademickie" :)
  • #15 11045092
    arturromarr
    Poziom 17  
    Ale jak wygląda fizycznie transmisja, określa się ją jakoś, jest jakiś protokół?
    Łączy się jakimiś portem, dwoma czy konkretnymi pinami?
    Jak to wygląda przy pisaniu w c, deklaruje się jakieś zmienne jako wspólne czy trzeba odczytywać konkretne rejestry?
    Jakby był jakiś przykład gdzieś w necie to pewnie nie zadawałbym głupich pytań? :)
    Jeśli chodzi o DMA to czuje się jak "dziecko w mgle" ale trochę mnie zachęciliście.
  • #16 11045339
    tmf
    VIP Zasłużony dla elektroda
    Tak jak pisałem - procki łączysz synchronicznym USARTem, czyli masz RS232-TTL + sygnał zegara. DMA automatycznie przerzuca dane pomiędzy prockami przez ten interfejs. Po dwóch stronach deklarujesz po prostu tablicę, która ma być wspólna dla obu procków. Jeśli dane lecą tylko w jednym kierunku to sprawa jest prosta - zapisujesz tablicę i na koniec inicjujesz transfer DMA w celu synchronizacji. Jeśli dostęp ma być RW po obu stronach to trzeba się bawić w semafory, mutexy itd. Czyli normalnie jak to w wielozadaniowym systemie, gdzie masz shared memory. Powinno cię to zainteresować ze względu na "akademickość" :)
  • #17 11045577
    arturromarr
    Poziom 17  
    No już mnie zainteresowało na tyle że chyba dojrzałem do decyzji o "przesiadce".
    Dzięki za odrobinę wyjaśnień, już trochę mi się to chociaż "sprzętowo" rozjaśniło.
    Czyli takie całkowite dzielenie zasobów tak że obydwa układy będą mogły je zmieniać, będzie bardziej skomplikowane programowo, czy też bardziej obciąża procesor?
    Czy jest generowane jakieś przerwanie u odbiorcy po zmianie jakiejś zmiennej?
    Jest gdzieś w necie przykład użycia DMA w C ?

    PS?
    Z użyciem dwóch układów mam bardzo dobre doświadczenie. Ponieważ używam dotąd mało wydajnej architektury to raz potrzebując dużej wydajności od sterownika i robienia kilku rzeczy jednocześnie podzielenie tej pracy na dwa układy uratowało projekt. Powstało coś w rodzaju układu wielozadaniowego. Jeden procek dla drugiego był jakby "sprzętową" realizacją potrzebnych funkcji. Kod podzielony na dwa układy był przejrzystszy i miałem więcej zasobów do wykorzystania. Reasumując wiem że zawsze można sięgnąć po wydajniejszy procesor, ale trzeba przyznać że podzielenie pracy na dwa układy (namiastka wielowątkowości) daje zalety w postaci prostszych kodów i dużej stabilności, wady naturalnie też są.
  • #18 11046378
    tmf
    VIP Zasłużony dla elektroda
    Oczywiście użycie dwóch układów jest programowo bardziej skomplikowane. Sama wymiana danych to banał, ale pojawiają się problemy typowe dla systemów wielozadaniowych ze współdzieloną pamięcią - trzeba stworzyć mutexy, uwzględnić potencjalne miejsca powstawania zakleszczeń itd. Wyobraź sobie, że do tej samej komórki pamięci jednocześnie próbują uzyskać dostęp dwa procki - jakoś ten konflikt trzeba rozwiązać. Problemem nie jest oczywiście sam dostęp, tylko to, aby procki pobrały sensowne dane. Podobnie podczas operacji read-modify-write po jednej stronie, trzeba jakoś zadbać aby po drugiej stronie MCU nie próbował czytać tego obszaru, albo go modyfikować. Na jednym rdzeniu rozwiązanie bywa proste - np. zamknięcie takich fragmentów w sekcjach atomowych (tylko uwaga na race conditions), dla dwóch niezależnych MCU rozwiązanie nie jest już takie proste. Tu z małą pomocą przychodzi assembler XMEGA, który ma dodatkowe instrukcje, np. LAT robiące operacje RMW w sposób atomowy.
REKLAMA