[defoxe]

#elektronika #mikrokontrolery #programowanie


Próbkuję dźwięk przetwornikiem analogowo-cyfrowym i wysyłam przez magistralę CAN.
Odbieram i odtwarzam przez PWM.
Problem w tym, że chyba CAN się trochę na zakręcie nie wyrabia i chciałbym zmierzyć się z kompresją danych.
Gdzie szukać ADPCM albo RPE-LTP? Zastanawiam się czy to w ogóle wydoli...
Mikrokontroler od Microchip z serii PIC18.

[krowa_pro]

@defoxe: jakie masz tam próbkowanie na tym przetworniku ? Wiecej niż 44.1 kHz ? Jakie duże próbki ? 16bit ? CAN do 40m powinien wyciągać 1Mbit/s ? Jeśli to połączenie punkt->punkt w razie czego, można zastąpić innym protokołem w oparciu o uart, gdzie spokojnie >1Mbit/s powinno ciągnąć. Jesteś pewny że to CAN nie wyrabia ? Bo może się okazać, że z CANem wszystko w porządku i problem leży gdzie indziej. Masz

[RicoElectrico]

@defoxe: IMA ADPCM jak najbardziej uciągnie każdy mikrokontroler.
RPE-LTP - szacowałem bardzo pobieżnie ostatnio implementację dekodera na AVR i być może ledwie-ledwie wyrobiłby się na czas (i nie zostałoby CPU na nic innego).
BTW edukacyjnie bardzo polecam to, obrazki lepiej tłumaczą niż specyfikacja ETSI ( ͡° ͜ʖ ͡°)

[defoxe]

@krowa_pro @RicoElectrico
Mikrokontroler to PIC18F25K80, sprawę trochę komplikuje (i zarazem ułatwia) fakt iż piszę w CCS C.
Na pierwszym PICu próbkuję sygnał i wsadzam do ramki CAN, jednocześnie podaje na PWM by mieć odsłuch. Dźwięk jest dobrej jakości.
Odbieram ramkę na drugim PIC'u i na identycznych ustawieniach PWM odtwarzam otrzymane dane.
Dźwięk jednak jest kiepskiej jakości. Aktualnie poważnie namieszałem i jest bardzo źle.
Obawiam się, że drugi PIC odbierając dane, sprawdzając IFami

[krowa_pro]

@defoxe: Jeśli nie gubisz żadnej ramki CAN, a zakładam że nie gubisz, bo nie wygląda na to na oko (ale można by oscyloskopem dla 100% pewności sprawdzić). To strzelam, że jakość dźwięku kiepska ze względu na brak synchronizacji próbek na 2 procku(sampling jitter?). Na 1 procku, masz tak jakby dosynchronizowane domyślnie, pobierasz próbkę, stały delay i odtwarzasz próbkę, na 2 próbujesz odebrać po 8 próbek i odtworzyć je w jakichś magicznych

[defoxe]

na 2 próbujesz odebrać po 8 próbek i odtworzyć je w jakichś magicznych pewnie odstępach między sobą, które mogą tylko mniej więcej korelować z odstępami w jakich je próbkowałeś i jakość leci.

@krowa_pro: Tutaj myślę, że to jakoś działa. Jak dostanie 8 próbek to ładnie odtworzy. Problem pojawia się w czasach nadawanie-odbiór.
O ile w warunkach "na stole" jestem może w stanie obliczyć ile to trwa. Natomiast w realnych warunkach, przy

[krowa_pro]

@defoxe: Spróbuj odpuścić printfa, nie wiem jaka tam jest implementacja, ale na często mikroproców printf na straszny nakład obliczeniowy. Wysyłaj bajt po bajcie swoje dane mniej więcej coś w stylu:

wysyłanie bajtu:

while (TXSTA1bits.TRMT == 0);
TXREG1 = bajt;

odbieranie bajtu:

while (PIR1bits.RC1IF == 0);
bajt = RCREG1

możesz zrobić test z timerem, bez przerwań, ale z odpalonym timerem, wysłać 1kB albo inną znaną wielkość, i z 2 strony odebrać, zmierzyć

[defoxe]

Spróbuj odpuścić printfa

@krowa_pro: Masz kurcze rację - ta funkcja przecież jest straszną kobyłą.
Wrzuciłem funkcję putc() i o całe rzędy wielkości działa szybciej.
"Nadajnik" działa płynnie sprawdzę jak sobie radzi odbiornik

zmierzyć timerem ile cykli upłyneło i policzyć faktyczny transfer, potem dołożyć do tego testu to próbkowanie z adc, i odtwarzanie i dalej patrzeć na transfer.

To są świetne pomysły. Jednak na początek chciałbym osiągnąć stabilną transmisję.

[defoxe]

@krowa_pro: I jest stabilna transmisja po UART. Działa pięknie. ( ͡º ͜ʖ͡º)