Jaki uC do analizy sygnału NRZI 375kbit/s zamiast STM32F103?

Niestety STM32F103 taktowany nawet 96Mhz nie wyrabia się z analizą i symulacją tego sygnału w którym dane "lecą" z prędkością 375kbit/sec.
Pytanie do znawców rdzeni: Który uC ma dużo szybszy dostęp do portów oraz szybsze "skoki" do przerwań? Analizowany protokół nie jest standardowy więc pozostaje tylko programowa obsługa.

A jakby taki pomysł wypalił:

Ustawić Timer jako Input Capture reagującego na obydwa zbocza sygnału. DMA skonfigurować na żądania od Timer i jako Circular buffer, Periph -> Memory. Analizować w wątku bufor kołowy z DMA, ślędząc licznik transferu i ładować do innego bufora wykryte stany 1 i 0 na podstawie róźnicy czasu obydwu zbocz. Z innego wątku ściągać dane z tego bufora i je spokojnie analizować.

Jeśli ten STM32 nie będzei miał prawie nic innego do roboty, to i programowo mógłby to dekodować. Sensowniej jednak byłoby zaprząc do tego timer w trybie pomiaru okresu i szerokości PWM. Uda się i jedno i drugie, o ile nie będziesz korzystał z SPL.

Problem mam nie z dekodowaniem ramki tylko z wystawieniem takiej samej na innym pinie. Ramki lecą w odstępach do 100us (sprawdzanie poprzedniej ramki kończy się gdzieś w połowie bajtu synchronizacji następnej ramki). Nie udało się mi niestety analizować ramki "w locie" i muszę poczekać aż wszystkie dane trafią do bufora. Generalnie wykonałem "łapanie" przebiegu na przerwaniach w których odczytuje licznik timera. Jak timer się przepełni oznacza to że ramka już jest cała w buforze.
Wystawienie złapanej ramki wykonuję przy pomocy timera (jego przerwania) i odpowiednio spreparowanego bufora danych które wstawiam do rejestru ARR timera. Problem jest taki że prawdopodobnie kwarc mi się "rozjeżdza" (a niby jest 15ppm) i bity w ramce mają niewielkie rozbieżności (1 bit to 2,66us) rzędu 0,2-0,3us.
Pamietam swego czasu ktoś próbował analizować ramki USB (też NRZI) na rdzeniu ARM7....niestety okazało się to niewykonalne....a AVR sobie z tym poradził

markosik20 napisał:

niestety okazało się to niewykonalne....

Pewnie do odczytu stanu pinu wykorzystywana byłą jakaś magiczna funkcja która robiła 100 niepotrzebnych rzeczy...

4\/3!!

Freddie Chopin napisał:

Pewnie do odczytu stanu pinu wykorzystywana byłą jakaś magiczna funkcja która robiła 100 niepotrzebnych rzeczy...

4\/3!!

No bez przesady



Szybciej się już chyba nie da....
Panowie... SPL omijam szerokim łukiem.

Da się:

GPIOB->IDR >> Tx_IND & 1

Będzie szybsze przynajmniej wtedy, gdy numer bitu nie będzei zbyt mały.

A jednak udało się ramkę "wystawić" na inny pin.
Przegrupowałem priorytety przerwań tak aby timer "symulujący" nie czekał z przerwaniem (brakowało dosłownie paru us aby rozpoczać wysyłanie ramki do urządzenia). Okazało się że najwęższym "gardłem" czasowym nie był sam STM.. lecz czas "wychwycenia" całej ramki danych (tak aby obliczyć CRC). Dziękuję wszystkim za pomoc.

markosik20 napisał:

No bez przesady

Nie mówię o Twoim projekcie, tylko o tej próbie analizy programowej USB na ARM7 którą opisałeś jako "niewykonalną" dla ARM7, zaś dla AtMegi nie była problemem, co miałoby udowadniać, że AtMega jest szybsza (; Tak czy siak przykład jest oczywiście mało sensowny, bo po to w ARM jest interfejs USB żeby się nie bawić w robienie tego programowo <:

4\/3!!

Freddie Chopin napisał:

...próbie analizy programowej USB na ARM7 którą opisałeś jako "niewykonalną" dla ARM7, zaś dla AtMegi nie była problemem, co miałoby udowadniać, że AtMega jest szybsza (;
4\/3!!

AVR relatywnie jest szybszy jeżeli chodzi o bezpośredni dostęp do portów.

albertb napisał:

Jak jest "relatywnie" szybszy, to co to właściwie oznacza jeśli chodzi o obiektywną szybkość dostępu do portu: jest wolniejszy, czy szybszy?

Albert

Ile rozkazów trzeba na ustawienie / wyzerowanie portu w AVR a ARM?
I weźmy pod uwagę że nie wszystkie rdzenie ARM "pędzą" 72Mhz i więcej.

markosik20 napisał:

Ile rozkazów trzeba na ustawienie / wyzerowanie portu w AVR a ARM?

Rozkazów czy cykli zegara? Bo rozkazów tyle samo - jeden (;

4\/3!!

Na twoim miejscu zainteresowałbym się jak rozwiązany jest problem emulatorów FDD zbudowanych na podobnych procesorach - poszukaj sobie np Gotek floppy emulator itp. Jest kilka podobnych projektów, niektóre dość otwarte (źródła są dostępne).

PS
Myślę ze powinieneś zainteresować się SPI a nie bit bangingem.