Podczas budowy dekodera http://forum.modelarstwo.info/threads/budowa-tanich-dekoderów-trakcji-dźwięku-funkcyjnych.50313/ wdrożyłem SUSI. Zdziwiłem się dlaczego funkcje dekodujące przeniesione. Po zgłębieniu tematu okazało się, że dana jest wystawiana po narastającym zboczu sygnału CLK!
Powiększenie:
Analizator, to nie klon SaleAE 24MHz za 40zł tylko oryginalny LA za blisko 500zł ale dla pewności sprawdziłem na dosyć szybkim 200MHz (to niekonieczne, wystarczyłby 10MHz) oscyloskopie:
W powiększeniu:
Według dokumentacji, dana musi być wystawiona przed narastającym zboczem CLK i utrzymana do czasu zbocza opadającego. W ZIMO tak nie jest! Warto o tym wiedzieć gdy pisze się oprogramowanie dla dekodera funkcyjnego, zwłaszcza na szybkie uC lub korzystając ze sprzetowego SPI. Problemu nie ma gdy uC jest wolne, jak popularne PIC czy AVR. Zanim CPU wejdzie w przerwanie, odczyta GPIO minie tak dużo czasu (2us), że czy program nawet gdy reaguje na zbocze narastające, dane od czytywane są poprawnie. Niestety, w szybkim uC tak już nie jest. Wstawianie w kodzie delay jest "godne" Arduinowca ale nie poważnego programisty. Pozostaje użyć timera, który kilka us po zboczu narastającym odczyta daną albo reakcja na zbocze opadające tak jak zrobiłem ja. Niestety, trzeba się liczyć, że inny producent może zmieniać daną przed zboczem opadającym
SUSI mimo, że podobny do half-duplex SPI, utrudnia wykorzystanie sprzętowego SPI do nadawania/odbioru danych. Jest to możliwe ale wymaga, zarówno w przypadku nadawania, włączania SPI na czas transmisji i wyłączania po jej zakończeniu co jest potrzebne do odbioru ACK. W przypadku odbioru, na czas nadania ACK trzeba wyłączyć SPI. Zdecydowanie prościej udało się zrealizować tą funkcjonalność w sposób programowy, zarówno dla nadawania, jak i odbioru. Zaletą rozwiązania programowego jest to, że mogę wykorzystać dowolne GPIO (w AVR to nie takie oczywiste, bo nie każdy pin moze generowac przerwanie w każdym uC) do SUSI. Max CLK SUSI to 50kHz, więc niewielkie obciążenia dla ARM (w AVR juz niekoniecznie, zwłaszcza gdy jest taktowany 8MHz aby nie podłączać zewnętrznego kwarcu).
Ten problem, wyjaśnia, dlaczego testerzy dekoderów muszą dysponować oscyloskopem i analizatorem logicznym. Bez tym urządzeń nie byłoby możliwości szybkiego zdiagnozowania problemu.
Na zakończenie, zegar SUSI ZIMO:
Widać, że coś mu przeszkadza (przerwania) aby był generowany stabilnie. To nie ma wpływu na działanie SUSI bo MX623 jest masterem ale da się do zrobić dobrze, nawet programowo.
Dlaczego zanan firma, przez lata, sprzedaje dekoder z SUSI, który niczym Window$ nie jest zgodny nawet sam ze sobą?
Powiększenie:
Analizator, to nie klon SaleAE 24MHz za 40zł tylko oryginalny LA za blisko 500zł ale dla pewności sprawdziłem na dosyć szybkim 200MHz (to niekonieczne, wystarczyłby 10MHz) oscyloskopie:
W powiększeniu:
Według dokumentacji, dana musi być wystawiona przed narastającym zboczem CLK i utrzymana do czasu zbocza opadającego. W ZIMO tak nie jest! Warto o tym wiedzieć gdy pisze się oprogramowanie dla dekodera funkcyjnego, zwłaszcza na szybkie uC lub korzystając ze sprzetowego SPI. Problemu nie ma gdy uC jest wolne, jak popularne PIC czy AVR. Zanim CPU wejdzie w przerwanie, odczyta GPIO minie tak dużo czasu (2us), że czy program nawet gdy reaguje na zbocze narastające, dane od czytywane są poprawnie. Niestety, w szybkim uC tak już nie jest. Wstawianie w kodzie delay jest "godne" Arduinowca ale nie poważnego programisty. Pozostaje użyć timera, który kilka us po zboczu narastającym odczyta daną albo reakcja na zbocze opadające tak jak zrobiłem ja. Niestety, trzeba się liczyć, że inny producent może zmieniać daną przed zboczem opadającym
SUSI mimo, że podobny do half-duplex SPI, utrudnia wykorzystanie sprzętowego SPI do nadawania/odbioru danych. Jest to możliwe ale wymaga, zarówno w przypadku nadawania, włączania SPI na czas transmisji i wyłączania po jej zakończeniu co jest potrzebne do odbioru ACK. W przypadku odbioru, na czas nadania ACK trzeba wyłączyć SPI. Zdecydowanie prościej udało się zrealizować tą funkcjonalność w sposób programowy, zarówno dla nadawania, jak i odbioru. Zaletą rozwiązania programowego jest to, że mogę wykorzystać dowolne GPIO (w AVR to nie takie oczywiste, bo nie każdy pin moze generowac przerwanie w każdym uC) do SUSI. Max CLK SUSI to 50kHz, więc niewielkie obciążenia dla ARM (w AVR juz niekoniecznie, zwłaszcza gdy jest taktowany 8MHz aby nie podłączać zewnętrznego kwarcu).
Ten problem, wyjaśnia, dlaczego testerzy dekoderów muszą dysponować oscyloskopem i analizatorem logicznym. Bez tym urządzeń nie byłoby możliwości szybkiego zdiagnozowania problemu.
Na zakończenie, zegar SUSI ZIMO:
Widać, że coś mu przeszkadza (przerwania) aby był generowany stabilnie. To nie ma wpływu na działanie SUSI bo MX623 jest masterem ale da się do zrobić dobrze, nawet programowo.
Dlaczego zanan firma, przez lata, sprzedaje dekoder z SUSI, który niczym Window$ nie jest zgodny nawet sam ze sobą?
Załączniki
Ostatnio edytowane:
