Trochę dokładniej zbadałem kod i jest tam bardzo poważny błąd. Komunikacja po UART (przerwania) zakłóca generowanie pakietów DCC!
Łatwo wywnioskować, że autor kodu, nie sprawdził czy i ile błędnych pakietów generuje program. Wszystko działa tylko dlatego, że pakiety generowane są w kółko i prędzej czy później pakiet wyjdzie niezakłócony. Użycie innych przerwań wywoła taki sam skutek. Błąd można poprawić ale wymaga to napisania własnych procedur obsługi przerwań UART pseudo wielopoziomowych. Aby zrobić dobrze trzeba robić wstawki ASM.
To tłumaczy, dlaczego obsługiwana jest tylko jedna lokomotywa (wiedza z wcześniejszych wypowiedzi Forumowiczów, sam tego nie sprawdzałem). Otóż, gdyby zwiększyć liczbę lokomotyw poprawnych pakietów docierających do każdej lokomotywy byłoby mniej. W konsekwencji lokomotywy reagowałyby z opóźnieniem albo zatrzymają się gdy timeout jest krótki. Możliwe też, że będą poruszać się skokami.
Nie pisałem, że arduinowe rozwiązania to zabawki-dema? Arduinowe DCC nadaje się do testowania pojedynczej lokomotywy, zapisu/odczytu CV ale już nie nadaje się nawet na amatorską makietę no chyba, że jeździ na niej jedna lokomotywa bez oświetlonych wagonów w DCC albo z oświetleniem sterowanym tym samym adresem co lokomotywa ale co to za makieta z jedną lokomotywą?
AVR to zła platforma do programowego generowania sygnału DCC. Do tego najlepszy jest uC z DMA ostatecznie z wielopoziomowym systemem przerwań. Xmega ma i jedno i drugie ale w stosunku do ARM jest droga więc jedynym rozsądnym rozwiązaniem jest ARM. DMA powinno pobierać czasy generowanych impulsów z tablicy i sterować timerem. Po wygenerowaniu całej tablicy wywołać przerwanie, w którym nastąpi zamiana adresu tablicy a poprzednia, teraz nieużywana, zostanie wypełniona nowymi wartościami. W ten sposób obciążenie CPU do generowania sygnału = 0%, DMA "ukradnie" 1-2% czasu CPU, zależnie od szybkości pracy CPU. Żadne pakiety nie wyjdą z błędem powodowanym przez przerwania. W AVR, mimo, że obciążenie CPU przez przerwania timera jest na poziomie 20-30% pakiety będą wychodzić z błędami gdy wykonywać będą się inne przerwania np używane w tym kodzie przerwania od UART. Należy zauważyć, że komunikacja AVR ze "światem zewnętrznym" jest przez UART więc błędnych pakietów jest sporo!
Kod raczej jest do uratowania ale po co się meczyć? Zamiast UNO za ok 90zł można kupić https://kamami.pl/zestawy-uruchomie...rozwojowa-z-mikrokontrolerem-stm32f411ce.html za niecałe 5 dych. Ma wszystko co potrzeba a nawet więcej, ma programator/debuger i nie jest to klon! Nawet jak porównać tą płytkę z klonem UNO za 30zł to jak porównać Lamborghini do najtańszego modelu Fiata z tym, że Lamborghini nie kosztuje miliony a mniej niż 100 tysięcy.
Wobec bardzo poważnych błędów, które znalazłem, nie ma sensu abym tracił czas na szukanie kolejnych. Jeśli jednak ktoś chciałby je poznac z chęcią przyjmę zlecenie. Z jeszcze większą zlecenie na poprawienie błędów ale od razu zaznaczam, że będzie to kosztowniejsze niż napisanie tego kodu od "zera" na ARM.
Łatwo wywnioskować, że autor kodu, nie sprawdził czy i ile błędnych pakietów generuje program. Wszystko działa tylko dlatego, że pakiety generowane są w kółko i prędzej czy później pakiet wyjdzie niezakłócony. Użycie innych przerwań wywoła taki sam skutek. Błąd można poprawić ale wymaga to napisania własnych procedur obsługi przerwań UART pseudo wielopoziomowych. Aby zrobić dobrze trzeba robić wstawki ASM.
To tłumaczy, dlaczego obsługiwana jest tylko jedna lokomotywa (wiedza z wcześniejszych wypowiedzi Forumowiczów, sam tego nie sprawdzałem). Otóż, gdyby zwiększyć liczbę lokomotyw poprawnych pakietów docierających do każdej lokomotywy byłoby mniej. W konsekwencji lokomotywy reagowałyby z opóźnieniem albo zatrzymają się gdy timeout jest krótki. Możliwe też, że będą poruszać się skokami.
Nie pisałem, że arduinowe rozwiązania to zabawki-dema? Arduinowe DCC nadaje się do testowania pojedynczej lokomotywy, zapisu/odczytu CV ale już nie nadaje się nawet na amatorską makietę no chyba, że jeździ na niej jedna lokomotywa bez oświetlonych wagonów w DCC albo z oświetleniem sterowanym tym samym adresem co lokomotywa ale co to za makieta z jedną lokomotywą?
AVR to zła platforma do programowego generowania sygnału DCC. Do tego najlepszy jest uC z DMA ostatecznie z wielopoziomowym systemem przerwań. Xmega ma i jedno i drugie ale w stosunku do ARM jest droga więc jedynym rozsądnym rozwiązaniem jest ARM. DMA powinno pobierać czasy generowanych impulsów z tablicy i sterować timerem. Po wygenerowaniu całej tablicy wywołać przerwanie, w którym nastąpi zamiana adresu tablicy a poprzednia, teraz nieużywana, zostanie wypełniona nowymi wartościami. W ten sposób obciążenie CPU do generowania sygnału = 0%, DMA "ukradnie" 1-2% czasu CPU, zależnie od szybkości pracy CPU. Żadne pakiety nie wyjdą z błędem powodowanym przez przerwania. W AVR, mimo, że obciążenie CPU przez przerwania timera jest na poziomie 20-30% pakiety będą wychodzić z błędami gdy wykonywać będą się inne przerwania np używane w tym kodzie przerwania od UART. Należy zauważyć, że komunikacja AVR ze "światem zewnętrznym" jest przez UART więc błędnych pakietów jest sporo!
Kod raczej jest do uratowania ale po co się meczyć? Zamiast UNO za ok 90zł można kupić https://kamami.pl/zestawy-uruchomie...rozwojowa-z-mikrokontrolerem-stm32f411ce.html za niecałe 5 dych. Ma wszystko co potrzeba a nawet więcej, ma programator/debuger i nie jest to klon! Nawet jak porównać tą płytkę z klonem UNO za 30zł to jak porównać Lamborghini do najtańszego modelu Fiata z tym, że Lamborghini nie kosztuje miliony a mniej niż 100 tysięcy.
Wobec bardzo poważnych błędów, które znalazłem, nie ma sensu abym tracił czas na szukanie kolejnych. Jeśli jednak ktoś chciałby je poznac z chęcią przyjmę zlecenie. Z jeszcze większą zlecenie na poprawienie błędów ale od razu zaznaczam, że będzie to kosztowniejsze niż napisanie tego kodu od "zera" na ARM.
Ostatnio edytowane:
