Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Asynchronizm domen zegarowych

tmf 15 Maj 2017 22:38 1425 28
  • #1 15 Maj 2017 22:38
    tmf
    Moderator Mikrokontrolery Projektowanie

    Pytanie proste i zasadniczo podejrzewam, że znam odpowiedź, ale... Wykorzystuję jeden generator zegara, który taktuje wszystkie komponenty MCU. Stąd też wszystkie wydaje się, że pracują w jednej domenie zegarowej. W takim przypadku jak sądzę nie muszę czekać na synchronizację rejestrów IO - bo skoro wszystko jest w jednej domenie to synchronizacja dokona się w czasie dostępu i stosowny bit będzie od razu wskazywał, że zapis został zsynchronizowany.
    Czy moje myślenie jest na 100% poprawne, czy jednak rdzeń ARM kryje jakieś ciekawostki, powodujące, że nie do końca jest to prawda?
    Idąc dalej - załóżmy, że mam GCLK0 i z niego taktuję komponent, dzieląc zegar np. przez 2. W takim razie dostęp do rejestru tego komponentu zajmie mi dwa takty GCLK0, bo zegar tego komponentu jest pochodną GCLK0, więc żadna inna sytuacja nie może mieć miejsca. Prawda, czy fałsz?

  • #2 15 Maj 2017 23:01
    Marek_Skalski
    Poziom 32  

    Nie do końca tak to działa. W przypadku tych uC, z których korzystam między domenami z różnym zegarem i/lub zasilaniem są mostki, aby nie spowalniać rdzenia. Do tego jeszcze dochodzi pipeline, gdzie operacje mogą zostać przesunięte. W zależności od długości kolejki, wpływ może być mniej lub bardziej istotny. A tutaj jest cytat z dokumentacji dla Cortex M-7: PM0253 (STM32F7x6).
    "Memory system ordering of memory accesses
    For most of memory accesses caused by explicit memory access instructions, the memory system does not guarantee that the order in which the accesses complete, matches the program order of the instructions. Providing any re-ordering does not affect the behavior of the instruction sequence. Normally, if a correct program execution depends on two memory
    accesses completing in the program order, the software must insert a memory barrier instruction between the memory access instructions, see 2.3.4: Software ordering of memory accesses on page 35.
    However, the memory system does guarantee some ordering of accesses to Device and
    Strongly-ordered memory..." Poniżej tego jest tabela, pokazująca priorytety.
    Podobnie jest też w przypadku PIC32MZ, gdzie kolejność dostępu do pamięci może być zmieniona podczas wykonywania programu. Wprowadzono też kilka różnych instrukcji odczytu i zapisu, w zależności od tego czy wynik ma być zapisany do pamięci lub urządzenia przed wykonaniem kolejnego rozkazu z kolejki już pobranych do dekodera.
    W przypadku CM0 lub CM0+ chyba nie ma takich problemów.

  • #3 15 Maj 2017 23:07
    tmf
    Moderator Mikrokontrolery Projektowanie

    Czy pod pojęciem pamięć rozumiesz także zapis do rejestrów IO układów podłączonych do szyn AHB? Bo o te mi chodzi, zapis do pamięci np. RAM to inna para kaloszy i tu wiadomo, że rdzeń będzie miał fantazję. W przypadku zapisu do IO myślę, że musieli poskromić reordering, bo nie miałoby to sensu i prowadziło do co najmniej dziwnych efektów.

  • #4 15 Maj 2017 23:23
    Marek_Skalski
    Poziom 32  

    Tak, chodzi o obszar pamięci określony jako Device. Więcej szczegółów od strony 33. w tym dokumencie. PM0253
    Wiem, że to dla STM32F7, ale to jest opis rdzenia, który pochodzi od ARM i jeżeli pracujesz z Cortex-M7, to prawdopodobnie jest nadal wiążący.
    Niestety, nie wiem gdzie szukać takich dokumentów na stronie ARM.

    Dlaczego pytasz? Jaki rdzeń Cię interesuje?

    Sprawdziłem. Dokładnie ten sam mechanizm jest zaimplementowany w rdzeniach CM0+ Vide PM0223 (STM32L0x1).

  • #5 15 Maj 2017 23:59
    tmf
    Moderator Mikrokontrolery Projektowanie

    Dzięki za dokument. Jutro poczytam. Pytanie jest ogólne, takie przemyślenia nad dystrybucją zegarów w układzie. A powód jest prosty - lenistwo. Po prostu praktycznie przy dostępie do każdego rejestru, przed kolejnym dostępem trzeba czekać na synchronizację. Jest to uciążliwe i kod wygląda dziwnie.

  • #6 16 Maj 2017 00:25
    Marek_Skalski
    Poziom 32  

    Nie bardzo rozumiem o co chodzi :/
    Jeżeli odwołujesz się stale do tego samego obszaru, np. 0x40000000-0x5FFFFFFF, czyli standardowa przestrzeń peryferiów, to kolejność operacji zostaje zachowana i nie trzeba na nic czekać. Problem jest tylko wtedy, kiedy np. próbujesz jednocześnie operować w przestrzeni adresowej 0xA0000000-0xBFFFFFFF (rejestry FMC lub QuadSPI) lub poniżej 0x40000000 (SRAM), a sąsiednia instrukcja odwołuje się do obszaru pozostałych peryferiów (0x40000000-0x5FFFFFFF). Tylko wtedy kolejność operacji może zostać zamieniona. To wynika z osobnych mostków, które mogą wykonać operację dostępu w dogodnym dla siebie czasie; kiedy są wolne.
    Dodatkowo, podczas operacji w obszarze systemowym rdzenia, kolejność jest zawsze wymuszona programem.
    Oczywiście, kolejność może zostać zamieniona podczas zwykłych dostępów do pamięci SRAM, ale to nie jest zaskoczeniem.
    W CM7 dochodzi jeszcze zarządzenie pamięcią podręczną. Stąd też instrukcje write-through i write-back związane z cache. Z mojego doświadczenia, czasami problemy pojawiają się, kiedy zapomnę przepisać data cache do ramu, po wykonaniu większej ilość operacji MAC na danych. ST i ARM zalecają również "cache invalidation", kiedy chcemy przesyłać ostatnio dotykany obszar przez DMA. Bez przepisania, DMA prześle stare dane albo wcale nie ruszy zgłaszając błąd dostępu do pamięci.

  • #7 16 Maj 2017 09:53
    tmf
    Moderator Mikrokontrolery Projektowanie

    Ok, nie zrozumieliśmy się, może mętnie to napisałem. Nie chodzi o kolejność dostępu lecz synchronizację nowowpisanej wartości z rejestrem danego układu peryferyjnego. Np. wpisuję wartość do rejestru kontrolnego modyfikując jakieś bity, następnie muszę czekać aż ta wartość ze względu na asynchronizm zegarów zostanie rzeczywiście wpisana do rejestru, co sygnalizują odpowiednie bity, a następnie ponownie modyfikuję ten rejestr. Bez czekania będę miał wyjątek. Pytanie dotyczy sytuacji w której traktowanie wszystkich podsystemów pochodzi z tego samego zegara - czy wtedy również trzeba czekać na synchronizację stanu rejestrów.

  • #8 16 Maj 2017 10:20
    kijas1
    Poziom 12  

    Przeglądając notę SAMD też rzucił mi się opis tej synchronizacji dla znacznej części rejestrów, ale jakość jeszcze nie zabrałem się za sprawdzenie tego. Podpatrzyłem jedynie jak to robią w ASF i kod wyglądał dziwnie(zapis, synchro, zapis, synrcho). Może mnie ktoś poprawi, ale w STM-ach zdaje się tego aż tyle nie ma.

  • #9 16 Maj 2017 10:24
    Piotrus_999
    Poziom 39  

    A mógłbyś taka rzeczywisty przykład podać. Bo jakoś sobie nie mogę praktycznie wyobrazić, przynajmniej w tych procesorach o których piszemy.. Problemem może to być np w multicore ale tam też jest gwarantowane in order w przypadku tego samego peryferium.

    Ale np BCM -radzá uæycie barierowych przed pierwszym pisaniem i po ostatnim czytaniu, oraz w przerwaniach przed pierwszym czytaniem po ostatnim pisaniu.

    Dodano po 2 [minuty]:

    kijas1 napisał:
    SAMD też rzucił mi się opis tej synchronizacji dla znacznej części rejestrów,
    Nie ma. Moze drobne błędy w krzemie :). Ale fakt SAMD w życiu w ręku nie miałem.

  • #10 16 Maj 2017 10:53
    tmf
    Moderator Mikrokontrolery Projektowanie

    @kijas1 W ASF nie dłubie, IMHO nie ma sensu. To samo można zrobić na rejestrach szybciej i kod IMHO jest bardziej przejrzysty. Ale to inna dyskusja.
    @Piotrus_999 Nie chodzi o kolejność dostępu i bariery.
    Są dwie domeny zegarowe. Przepisujesz dane z rejestru znajdującego się w jednej domenie do rejestru znajdującego się w drugiej. Ponieważ oba układy są synchroniczne, więc istnieje sekwencja - polecenie zapisu - synchronizacja w drugiej domenie - zapis do właściwego rejestru w drugiej domenie. Dopiero od tego momentu możemy ponownie modyfikować rejestr. Pytanie brzmi - jeśli w obu domenach jest to samo źródło zegara, to czy synchronizacja ciągle jest wymagana.
    Przykład - zapisuję rejestr kontrolny timera. Przed kolejnym jego zapisem muszę czekać na skasowanie odpowiedniej flagi synchronization busy. Brzmi logicznie jeśli zegar rdzenia jest inny niż zegar taktujący timer. Jeśli zegar rdzenia jest taki sam jak zegar taktujący timer (to samo źródło, np. GCLK0) to czy ciągle potrzebne jest czekanie na synchronizację? Na logikę nie, chyba, że synchronizacja jest jakoś magicznie zaimplementowana.
    Pytanie nie tylko dotyczy SAMD, ale każdego ARMa, bo w każdym peryferia mogą być taktowane z innych zegarów niż rdzeń i magistrale.

  • #11 16 Maj 2017 11:33
    Piotrus_999
    Poziom 39  

    tmf napisał:
    Przykład - zapisuję rejestr kontrolny timera. Przed kolejnym jego zapisem muszę czekać na skasowanie odpowiedniej flagi synchronization busy
    Szczerze powiem spojrzałem pobierznie w DS-a M7 i flagi synchronizacji rejestru z magistralą nie znalazłem, tak że nawet nie za bardzo mogę przeczytać o co chodzi.

    Dodano po 1 [minuty]:

    tmf napisał:
    jeśli w obu domenach jest to samo źródło zegara, to czy synchronizacja ciągle jest wymagana.
    PS Wydaje mi się że po prostu w przypadku braku możliwości zapisu rdzeń czeka na zwolnienie magistral, a te które muszą być synchronizowane sa wyraźnie opisane.

  • #12 16 Maj 2017 11:42
    kijas1
    Poziom 12  

    @tmf, wiem że z asf nie korzystasz, napisałem tylko, że ja się temu przyglądałem.
    W nocie znalazłem coś takiego na temat synchronizacji: "Access between these
    clock domains must be synchronized. As this mechanism is
    implemented in hardware the synchronization process takes
    place even if the different clocks domains are clocked from the same source and on the same frequency.". Czyli wychodzi chyba na to, że trzeba to sprawdzać nawet dla tego samego źródła, chyba że źle to rozumiem.

  • #13 16 Maj 2017 12:26
    Marek_Skalski
    Poziom 32  

    Punkt dla ST i NXP :) W ich produktach nie ma synchronizacji o ile magistrale są pędzone z tego samego źródła. Synchronizacja występuje tylko w przypadku dostępu do rejestrów taktowanych w pełni asynchronicznie z zupełnie innej domeny, np. RTC.
    2 lata temu kupiłem jedną z pierwszych płytek z SAM V71 i pamiętam, że miałem mnóstwo kłopotów z konfiguracją DMA, a programy demo nie działały, a przynajmniej nie tak jak tego oczekiwano. Ale wtedy dokumentacja nie mówiła nic na temat synchronizacji. Z mojego punktu widzenia, jeżeli naprawdę trzeba czekać na sprzętową synchronizację przy dostępie do peryferiów, to ktoś zrobił sporo błędów w krzemie i teraz próbuje to leczyć poprzez jakieś dziwne zabiegi. Normalnie, synchronizacją zajmują się mostki między magistralami. Jeżeli jakiś mostek jest mocno obłożony pracą, to wystawia wait state do rdzenia i ten czeka. Ale to raczej sporadyczne przypadki w nowszych uC.
    Przejrzałem też dokumentację do PIC32MZ oraz PIC32MK i nie widzę żadnej konieczności czekania na synchronizację. Widać, tylko Atmel ma takie cudo.

  • #14 16 Maj 2017 13:06
    Piotrus_999
    Poziom 39  

    @Marek_Skalski A nie wiesz przypadkiem - czy w przypadku STM-a (co prawda nie spotkałem się z takim przypadkiem osobiście) jezeli nastapia odczyty z dwóch peryferiów (jak w opisywanym przeze mnie BCM-ie) to będzię in-order, czy też out of order. Teraz mnie to zastanowiło a przecież to w sumie częsty przypadek (np jak nadejdzie przerwanie). Zrobiłem pare testów - ale wydaje mi się że zakonczenie istniejących działań na magistrali następuje sprzetowo. W dokumentacji nic nie znalazłem

  • #15 16 Maj 2017 13:34
    tmf
    Moderator Mikrokontrolery Projektowanie

    Marek_Skalski napisał:
    Punkt dla ST i NXP :) W ich produktach nie ma synchronizacji o ile magistrale są pędzone z tego samego źródła. Synchronizacja występuje tylko w przypadku dostępu do rejestrów taktowanych w pełni asynchronicznie z zupełnie innej domeny, np. RTC.

    I stąd właśnie moje pytanie. Wszyscy się zgodzimy, że jeśli domeny zegarowe są różne, to synchronizacja jest potrzebna. Można to rozwiązać na dwa sposoby:
    - wstrzymujemy egzekucję programu przy dostęie do takiego zasobu (jak rozumiem to wykorzystuje STM),
    - wprowadzamy flagi i programista musi dbać o dostęp (rozwiązanie Atmela), ale za to program jest wykonywany bez wstrzymywania.
    I teraz moje pytanie ile trwa synchronizacja, jeśli taktowanie jest z tego samego źródła? Jeśli max tyle ile wykonanie instrukcji, to program nie zauważy ustawionej flagi, więc kolejna instrukcja bez sprawdzenia mogłaby się odwołać do tego samego rejestru. Potwierdza to doświadczenie - olewam synchronizację i działa ok. Zapis bez synchronizacji przy różnych zegarach generuje wyjątek. Wynikałoby z tego, że przy takich samych zegarach po prostu olewam flagi synchronizacji, czyli mam rozwiązanie jak w STM. Przy różnych zegarach - muszę poszekać na skasowanie odpowiedniej flagi sygnalizującej zakończenie synchronizacji.

  • #16 16 Maj 2017 13:46
    michalko12
    Specjalista - Mikrokontrolery

    tmf napisał:
    - wstrzymujemy egzekucję programu przy dostęie do takiego zasobu (jak rozumiem to wykorzystuje STM),

    Zapis jest buforowany i jeśli bufor jest pusty dane do zapisu są buforowane, a program wykonuje się dalej, próba zapisu przy pełnym buforze wstrzymuje rdzeń. Prawdopodobnie w atmelu nie ma tego wstrzymania rdzenia.
    tmf napisał:
    I teraz moje pytanie ile trwa synchronizacja, jeśli taktowanie jest z tego samego źródła
    Według mnie co najmniej 2 takty i nie ważne, że z tego samego źródła.

  • #17 16 Maj 2017 13:48
    kijas1
    Poziom 12  

    Gdyby tak było to fajnie, ale w nocie jest również taki zapis:
    The synchronization will delay the write or read access duration by a delay D, given by the equation: 5 PGCLK+2*PAPB<D <6*PGCLK+3*PAPB, czyli chyba nie jest to tyle ile wykonanie instrukcji.

  • #18 16 Maj 2017 14:15
    tmf
    Moderator Mikrokontrolery Projektowanie

    @kijas1 No właśnie. Ale jeśli takie opóźnienie byłoby wprowadzane automatycznie to po co te flagi sygnalizujące synchronizację?

  • #19 16 Maj 2017 14:26
    Marek_Skalski
    Poziom 32  

    Pytałem na samym początku o jakim uC rozmawiamy i dostałem odpowiedź, że problem jest ogólny. A to nie jest prawda. Problematyczny jest przypadek szczególny, niedoróbka ze strony Atmel'a. 5 czy 6 cykli zegara na synchronizację? Dramat.
    Może mało wiem i mało widziałem, ale żaden inny uC oparty na rdzeniach Cortex-M nie ma takich cudów.. Konstrukcje oparte na innych rdzeniach, np. MIPS 32K również nie mają takiej bolączki. Wszystko działa fajnie.
    Synchronizacja, o której wspomniałem dla wcześniej dla domen asynchronicznych dotyczy powolnych zegarów, np. 37kHz vs. 168MHz, ale nawet wtedy rdzeń nie jest wstrzymywany, tylko realizowana jest operacja, następnie można sprawdzać stan flagi poprzez polling (w pętli while), albo poczekać na przerwanie, albo powrócić do zadania po określonym czasie. Kod aplikacji może być realizowany bez przeszkód; przerwania również.

  • #20 16 Maj 2017 14:29
    michalko12
    Specjalista - Mikrokontrolery

    tmf napisał:
    Ale jeśli takie opóźnienie byłoby wprowadzane automatycznie to po co te flagi sygnalizujące synchronizację?

    Tyle czasu potrzebuje mostek AHB-APB na zapis danych do rejestru peryferiala. W Atmelu brak jest wstrzymania rdzenia przed zakończeniem poprzedniego zapisu i w takim przypadku skutkuje to wyjątkiem, aby się przed tym zabezpieczyć trzeba korzystać z systemu flag. Przykre.

  • #21 16 Maj 2017 14:51
    tmf
    Moderator Mikrokontrolery Projektowanie

    Ok, powoli dochodzimy do konkluzji. Czyli synchro normalnie trwa 5-6 taktów i na tyle jest wstrzymywany rdzeń - ponieważ to się robi hardwarowo więc flaga do tego procesu nie jest potrzebna. Natomiast jeśli układ do którego uzyskujemy dostęp jest taktowany wolniej, to dodatkowo musimy poczekać na synchronizację zapisu w wolniejszej domenie zegarowej, co sygnalizuje ustawienie odpowiedniej flagi.
    Jak rozumiem, jeśli obie strony pracują z tym samym zegarem, to tracimy tylko 5-6 taktów na synchronizację sprzętową na mostku, ale flaga już nie będzie ustawiona ani przez chwilę, gdyż w czasie tych 5-6 taktów dojedzie do uaktualnienia rejestru docelowego.
    Przynajmniej na to wskazywałyby wyniki eksperymentu na żywym organizmie :) I jest to konkluzja (o ile jest prawdziwa), która mnie satysfakcjonuje.
    @Marek_Skalski Jak widać problem jest ogólny, tyle, że zaimplementowane rozwiązania mogą się różnić, na co też warto zwrócić uwagę.

  • #22 16 Maj 2017 17:30
    Marek_Skalski
    Poziom 32  

    Piotrus_999 napisał:
    @Marek_Skalski A nie wiesz przypadkiem - czy w przypadku STM-a (co prawda nie spotkałem się z takim przypadkiem osobiście) jezeli nastapia odczyty z dwóch peryferiów (jak w opisywanym przeze mnie BCM-ie) to będzię in-order, czy też out of order.

    To jest dość dobrze opisane w Programming Manuals, do których odnosiłem się na początku tego tematu. Generalnie, kolejność operacji zostaje zachowana, poza odwołaniami do sektora 0xA0000000-0xBFFFFFFF dla I/O.
    Jak już @kijas1 zauważył, opóźnienie to nie jest 5-6 taktów, ale między 5 a 6 GCLK (rdzeń?) + 2 lub 3 APBCLK (takty magistrali?). Czyli dla APBCLK = GCLK/2 opóźnienie wynosi 9-12 taktów. Wynika też z tego, że nawet zmniejszenie prędkości rdzenia nie jest rozwiązaniem, ponieważ nadal trzeba czekać na realizację operacji I/O. Masakra! Nie lubię tego słowa, ale tutaj nie mogłem się powstrzymać :D
    @tmf Bardzo dziękuję za założenie tego tematu i zwrócenie uwagi na to jak bardzo konstrukcje Atmela odstają od innych. Jak będę miał wolną chwilę, to zobaczę ilu rodzin SAM to dotyczy.
    edit:
    Właśnie przeglądam dokumentację do SAM D21 i teraz już wiem o co chodzi. To jest wyjątkowo szkaradny mechanizm. Synchronizacja rejestrów jest opisana w 194 miejscach. Nie dość, że normalny, pojedynczy zapis trwa 2xAPBCLK, więc jest dość powolny, to sama synchronizacja jest jeszcze rozróżniana na pojedynczą i ciągłą, na synchronizację odczytu i synchronizację zapisu.

  • #23 16 Maj 2017 20:40
    tmf
    Moderator Mikrokontrolery Projektowanie

    Panowie, możemy się skupić na problemie? Naprawdę nie za bardzo interesuje mnie, że firma XX rozwiązała coś lepiej/gorzej/inaczej.
    Wobec powyższych faktów pytanie jest proste - czy jeśli wszystko jest taktowane z tego samego zegara to moge bezpiecznie pominąć sprawdzanie flag synchronizacji?
    Próba wskazuje, że tak. Czy do tego ktoś może coś dodać konstruktywnego?

    Dodano po 2 [minuty]:

    Marek_Skalski napisał:

    Jak już @kijas1 zauważył, opóźnienie to nie jest 5-6 taktów, ale między 5 a 6 GCLK (rdzeń?) + 2 lub 3 APBCLK (takty magistrali?). Czyli dla APBCLK = GCLK/2 opóźnienie wynosi 9-12 taktów. Wynika też z tego, że nawet zmniejszenie prędkości rdzenia nie jest rozwiązaniem, ponieważ nadal trzeba czekać na realizację operacji I/O. Masakra! Nie lubię tego słowa, ale tutaj nie mogłem się powstrzymać :D


    Chyba nie do końca tak jest, bo przy takich opóźnieniach machanie pinem IO nawet z f=1 MHz byłoby wyzwaniem, podczas, gdy tak nie jest. Podobny problem byłby z szybkimi interfejsami, np. USB.

  • #24 16 Maj 2017 21:01
    Piotrus_999
    Poziom 39  

    tmf napisał:
    Wobec powyższych faktów pytanie jest proste - czy jeśli wszystko jest taktowane z tego samego zegara to moge bezpiecznie pominąć sprawdzanie flag synchronizacji?
    To ja już nic nie rozumiem. Pisałeś że masz wyjątek. Teraz że jest OK. Czyli rozumiem że ta flaga ma charakter informacyjny, skoro możesz pisać i jest ok.

  • #25 16 Maj 2017 21:05
    kijas1
    Poziom 12  

    Wyjątek ma, jeśli domeny nie są z tego samego źródła, jak z tego samego to wyjątku nie ma.

  • #26 16 Maj 2017 21:10
    Marek_Skalski
    Poziom 32  

    tmf napisał:
    Panowie, możemy się skupić na problemie?

    Oczywiście, że tak. W tej sytuacji wydaje mi się, że należy przyjąć to co ma do powiedzenia producent. Ponieważ nie wiem o który uC chodzi Tobie, to wybrałem przypadkowy, na przykład tutaj: http://ww1.microchip.com/downloads/en/DeviceDoc/40001882A.pdf
    Rozdział czternasty, ze szczególnym uwzględnieniem 14.2 i 14.3. Temat synchronizacji został bardzo dobrze opisany.
    A dlaczego USB i I/O'ki nie mają błędów przy braku synchronizacji? USB jest przypięty częściowo do AHB jako master, więc transfer danych odbywa się bezproblemowo. Tylko rejestry są do APB. Być może w połączeniu z prędkością magistrali to wystarcza.
    Do machania pinami I/O używana jest zupełnie inna szyna i żaden z rejestrów portów nie wymaga synchronizacji. Vide sekcja 23. w tym samym dokumencie.
    Dla Cortex M-4, znalazłem całkiem dobry opis synchronizacji rdzenia w tym dokumencie: http://ww1.microchip.com/downloads/en/DeviceD...-Microcontroller-SAM4E16-SAM4E8_Datasheet.pdf
    Sekcja 11.4. W przypadku tego rdzenia, nie ma żadnych problemów z synchronizacją i opóźnieniami. Podobnie w SAM V70/V71 (Cortex-M7) nie znalazłem tego mechanizmu synchronizacji. Stąd wnioskuję, że cały problem dotyczy przypadku szczególnego, Cortex M0+ w uC Atmel.

  • #28 16 Maj 2017 23:02
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Piotrus_999 napisał:
    Problem?

    No właśnie... To jest taki "problem" jak to, że przy pełnej prędkości w Bugatti Veyron opony zużyją się w 15 minut (*). Jeszcze N-I-G-D-Y nie odczułem tych mitycznych braków prędkości machania pinem, tak więc raczej nie wzdycham po nocach do tych super 8051 które machają pinem z prędkością światła. Jakoś bardziej przemawia do mnie FPU i wydajność obliczeniowa, niż zupełnie do niczego nieprzydatne machanie pinami (;

    (*) - co ponoć nie jest problemem, bo paliwa zabraknie po 12 minutach...

  • #29 17 Maj 2017 10:55
    michalko12
    Specjalista - Mikrokontrolery

    Freddie Chopin napisał:
    Jakoś bardziej przemawia do mnie FPU i wydajność obliczeniowa, niż zupełnie do niczego nieprzydatne machanie pinami (;

    Ale to nie jest problem dotyczący machania pinami, bo portów i tak już chyba żaden producent nie dołącza do APB. Chodzi tylko o świadomość ile czasu co może zająć. Jak masz procesor taktowany >100MHz to te opóźnienia nie będą miały żadnego znaczenia, ale jak są układy z zegarem 30MHz i mniej przy LP i w przerwaniach dane są ładowane do FIFO SPI czy UARTa to już MOŻE mieć jakiś wpływ na działanie całego programu, np. poprzez zastosowanie nieodpowiednich priorytetów przerwań. Jeśli w tym samym czasie są jeszcze transfery DMA przez te samo APB to sytuacja jeszcze bardziej może się skomplikować. Warto mieć na uwadze takie niuanse.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME