Bascom Attiny13 - Led pwm i serwo - jak oszukać program?

Cześć.

Jest sobie program, w którym jest 6 następujących po sobie case. Kiedy warunki w jednym się wykonają, przeskakujemy do kolejnego i tak w kółko.
W 4 z nich migają diody, dodatkowo w dwóch z nich uruchamianie na chwilę jest serwo i tu jest pies pogrzebany...
Diody migają elegancko, aż wskakujemy w case z obsługą serwa - pulseout. Wtedy program zajmuje się serwem i diody zaczynają migać dużo wolniej.

Nie zastosuję timer, bo on zajmuje się programowym pwm dla płynnego migania dwóch diod.

Mogę w każdym case wysyłać do serw te same powtarzające się wartości, ale wtedy serwa niepotrzebnie brzęczą i grzeją stabilizator 7805.

Mam głupi pomysl:
Jest jakis patent na "lewe obliczenia" które wykonywał by uC w momencie kiedy nie obsługuje serwa, tak, żeby program pracował w jednym tempie i Led migaly zawsze tak samo?

Nie zamieszczę kodu, bo go nie ma.
Wszystkie próby spelzly na niczym i w końcu nie mam żadnego kodu, a jedynie działające osobno fragmenty.

Dodano po 8 [minuty]:

Z grubsza:
Case 0
Czekamy na naciśnięcie przycisku
(naciśniety - idziemy do 1)
Case 1
Migaja diody na przemian (płynnie, tu używamy programowego pwm pędzonego timerem)
Po chwili skaczemy do 2
Case 2
Diody migają, uruchamiamy serwo zwiększamy powoli zmienna i wysyłamy poprzez pulseout
(tu zaczynają się cyrki z led)
Po osiągnięciu przez zmienna określonej wartości skaczemy do 3
Case 3
Migaja diody, czekamy na przycisk, żeby wykonać operacje odwrotnie decr zmienna i pulseout, itd...
po czym wracamy do case 0

Nie wiem po co sobie utrudniasz z "programowym" pwm . Attiny13 ma timer0 i dwa kanały sprzętowy pwm (OC0A i OC0B) . Jeden kanał używasz do migania LED a drugi do sterowania serwem , w "case" gdzie masz serwo musisz tak manipulować zmienną dla led i serw po przez np: pętle i będzie chodzić.
Najlepiej to zmień procesor np: na attiny2313 , trochę większy a masz 2x timer i 4x pwm i inne bajery .

W jaki sposób jednym timerem sterować dwiema diodami niezależnie i jeszcze serwem?

Programowy PWM? Choćby dlatego, że mam go na tych pinach na których chcę, a nie tam gdzie muszę.

Esencja tego forum:
Nie szukaj rozwiązania...
i"zmień procesor", "przejdź na C", "czemu nie użyjesz arduino" To pojawia się w 80% tematów które czytam.
To powinno widnieć w nagłówku działu AVR

Nie można poprosic uC, żeby w tym czasie zajął się czymś niepotrzebnym (czym?) ale równie obciążającym?

Jak będzie sobie dodawal/odejmował zmienną dla serwa ale jej nie wysyłał chyba rozwiąże sprawę połowicznie. Wysyłać jej nie chcę j/w

Rozumiem to tak, że w każdym case musiałby dokonywac wszystkich obliczeń i dla led i dla serwa, ale tylko te potrzebne wywalać na zewnątrz.
Choć pewnie samo pojawienie się instrukcji pulseout już wplybie na szybkość pracy programu. Jakieś nie duże zmiany mogę skorygować poprzez indywidualne waitus w case, ale też bez przesady.

Też wydaje mi się, że buduję jakaś wielką, zupełnie niepotrzebną konstrukcje, która zaraz się zawali, albo przynajmniej nie zmieści, a rozwiązanie jest tuż obok i proste...

Justyniunia napisał:

Nie można poprosic uC, żeby w tym czasie zajął się czymś niepotrzebnym (czym?) ale równie obciążającym?

Procesor nie wie co jest potrzebne - robi co mu programista nakazał kodem programu (czasem nieświadom co nakazał ).
Po drodze od programisty do kodu maszynowego (czyli tego co wykonuje procesor) jest jeszcze kompilator i miewa wbudowane opcje optymalizacji. Jak wpiszesz sto razy
moja_kochana_znienna = 4;
to niestety może zostać zoptymalizowane do pojedynczego zapisu do zmiennej. Zależy od stopnia optymalizacji.
Podobnie jak to umieścisz w pętli - pętla może zostać zredukowana do pojedynczego zapisu.
Jeżeli jednak zadeklarujesz zmienna jako volatile:
volatile int moje_kochna_zmienna;
to kod wynikowy powinien wykonać wszystkie 100 zapisów czyli stracić troche czasu.
To niestety dotyczy C jak jest w Bascom nie wiem ale może tam nie ma takiej optymalizacji i po prostu wykonuje co ma napisane.

Justyniunia napisał:

Choć pewnie samo pojawienie się instrukcji pulseout już wplybie na szybkość pracy programu.

Tu trzeba zobaczyć czy jest napisane jak ona działa ale możliwe, że jej czas wykonania jest zmienny i to zależy od długości impulsu czyli inny będzie czas wykonania dla krótkich impulsów a inny dla długich. Trzeba by dodać taką odwrotna pętlę - jak impuls krótki to więcej obiegów pętli a jak długi to mniej ale strojenie tego aby czas był zawsze taki sam to troche jak strojenie wahadła albo balansu w zegarku - dużo cierpliwości.
A nie da się tego algorytmu startować w równych odstępach czasu - jakiś timer/przerwanie czy oczekiwanie na konkretną wartość pracującego stale licznika. Ten odstęp powinien być trochę większy niż najdłuższy czas wykonania.

Justyniunia napisał:

Esencja tego forum:
Nie szukaj rozwiązania...

Można na to tak patrzeć. Można też z drugiej strony - tworzysz babole, a inni ci piszą jak się to powinno robić. Zamiast pracowicie rozwiązywać stworzone przez siebie problemy, zrób to jak należy.
Nawet jeśli timer masz jeden i wykorzystujesz go do generowania PWM, to nic ne stoi na przeszkodzie, aby dodatkowo go wykorzystać do innych rzeczy. Czyli nie żadne pulseout, programowe, które blokuje MCU, tylko przenieść to sterowanie do np. funkcji obsługi przerwania ovf timera. Wtedy masz gwarancję wykonania tego kodu w ścisłych interwałach czasowych. Rzeźbiąc jakieś opóźnienia w pętli cudem uzyskasz pożądany efekt, przekonując się, że zmiana jednego elementu kodu sypie wszystkie timingi...

Justyniunia napisał:

W jaki sposób jednym timerem sterować dwiema diodami niezależnie i jeszcze serwem?

Bardzo prosto. Masz dwa niezależne kanały PWM właśnie idealne do sterowania LED, a ponieważ PWM ma stały okres, masz jeszcze dodatkowo przerwanie np. ovf do generowania impulsów o czasie trwania dłuższym niż okres PWM, czyli odealne do zastąpienia owego pulseout.

Justyniunia napisał:

Programowy PWM? Choćby dlatego, że mam go na tych pinach na których chcę, a nie tam gdzie muszę.

Tak, w przypadku 8-pinowego MCU to istotnie problem, aby zaprojektować poprawnie układ elektryczny

tmf napisał:

Tak, w przypadku 8-pinowego MCU to istotnie problem, aby zaprojektować poprawnie układ elektryczny

Wybacz, ale to ja najlepiej wiem jak bardzo akurat ten problem jest istotny.
Jeden z przykładów (nie moich, ale w tym kierunki idziemy) i musi się zmieścić, a nie że zrobię sobie A4, bo akurat tu mam PWM

Justyniunia napisał:

Jeden z przykładów (nie moich, ale w tym kierunki idziemy) i musi się zmieścić, a nie że zrobię sobie A4, bo akurat tu mam PWM

W układzie, w którym jest tyle elementów co na przedstawionym zdjęciu, liczba dozwolonych aranżacji jest tak duża, że rearanżacja pinów nie stanowi najmniejszego problemu. Zapewne też laminat użyty na tej fotce jest co najmniej 4-warstwowy, co dodatkowo zwiększa liczbę możliwych kombinacji prowadzących do pożądanego efektu.
Generalnie jeśli masz postawę, że czegoś się nie da zrobić poprawnie, to masz efekt jaki opisałeś w pierwszym poście - nie robisz czegoś poprawnie. Reszta to już tylko konsekwencje błędów popełnionych wcześniej:
- brak przemyślenia i dostosowania projektu elektrycznego do np. pinoutu MCU -> skutek: konieczność rzeźbienia w kodzie jakiś protez,
- brak przemyślenia wymogów co do dostępnych układów peryferyjnych/pamięci/pinów -> skutek: konieczność rzeźbienia w kodzie protez,
- brak przemyślenia algorytmu -> skutek:niedziałający zgodnie z założeniami kod
- pokręcony kod -> skutek: konieczność jego jeszcze większego pokręcenia
- jeszcze bardziej pokręcony kod -> skutek: w końcu to wszystko przestaje działać.
Oczywiście można się obrażać na rzeczywistość, psioczyć na elektrodę, tyle, że to nie zmienia faktów. Na końcu to ty zostajesz z problemem, a nie otoczenie, które ci daje wskazówki, jak coś należy zrobić.

To teraz popatrz ile jest wpisów o dupie Maryny a ile przykładów rozwiązania.

Jest problem to się dąży do jego rozwiązania.
Bo podejście - zamiast robić remont, to wyburzyć i postawić od nowa, to żadne podejście.
Stan jest jaki jest i trzeba coś z tym zrobić, tyle odnoście zmiany uC, platform, języków programowania i wielkości płytek.

W ostateczności nie będzie dla led PWM, tylko 1/0
Tez tak może być, ale jeśli się da, to wolę z PWM, dlatego dążę do rozwiązania istniejącego problemu, a nie zrobienia wszystkiego od nowa.

Jeszcze NIGDY nie pojawiła się odpowiedź w stylu "hmm, zastanówmy się, może spróbuj tak i tak, a jeśli nie zadziała - będziemy myśleć dalej",
Zawsze jest zmień to, zmień tamty, a w ogóle to wyrzuć, czemu AVR, przeciesz jest PIC, czy STM.

Wiecznie szukanie 100 nowych problemów i ani jednej próby rozwiązania istniejącego.

Odnoszę wrażenie, że większość użytkowników elektrody w rzecywistosci nie robi nic.

Nie obrażam się na elektrodę (nadal tu jestem), ale podejście nie zmieniło się od 10 lat i już się nie zmieni.

Pozdrawiam.

Justyniunia napisał:

To teraz popatrz ile jest wpisów o dupie Maryny a ile przykładów rozwiązania.

Przecież rozwiązanie już padło. A nawet kilka - od zmień układ połączeń, do zmień swój program, rozwiązując problem jak należy przy pomocy timera. W pierwszym swoim poście opisałem ci dokładnie co masz zrobić, żeby to działało, bez jakichkolwiek kompromisów, inny zaproponowali rozwiązania sprzętowe.

Justyniunia napisał:

Jest problem to się dąży do jego rozwiązania.
Bo podejście - zamiast robić remont, to wyburzyć i postawić od nowa, to żadne podejście.

Niestety, czasami poprawianie błędów nie ma sensu, prościej jest wyburzyć i zrobić od nowa.

Justyniunia napisał:

Jeszcze NIGDY nie pojawiła się odpowiedź w stylu "hmm, zastanówmy się, może spróbuj tak i tak, a jeśli nie zadziała - będziemy myśleć dalej",
Zawsze jest zmień to, zmień tamty, a w ogóle to wyrzuć, czemu AVR, przeciesz jest PIC, czy STM.

Bo zwykle każdy problem można rozwiązać na wiele sposobów, stąd różne propozycje.
Jednak mam wrażenie, że oczekujesz po prostu potwierdzenia, że to co wymyśliłeś jest świetne i należy iść w tym kierunku, a tak nie jest. Zadając pytanie, musisz założyć, że czegoś nie wiesz, dlatego, pytasz. Musisz też założyć, że to co zrobiłeś nie jest zbyt dobre, w efekcie inny to wytkną i zaproponują inne rozwiązanie. Jeżeli uznajesz, że to co wymyśliłeś jest doskonałe, to po co pytać innych o zdanie? Nie dziw się, że opisując projekt w którym masz 8-pinowy MCU, dwa LEDy i wyjście czymś sterujące, ktoś ci wskazuje najmniej kosztowne rozwiązanie - dostosować układ elektryczny do pinoutu procesora. Dostałeś też rozwiązanie czysto softwarowe, które w tym przypadku się sprawdzi. Co z tym zrobisz to już twoja sprawa.

Justyniunia napisał:

Jeszcze NIGDY nie pojawiła się odpowiedź w stylu

Jeśli naprawdę jesteś przekonany, że nigdy nie uzyskałeś pomocy, to zakładając, że jesteś rozsądnym człowiekiem, kierującym się logiką, nie wiem po co zadajesz pytania na forum? Przecież jest niepomocne...
Jak już pisałem, w tym wątku otrzymałeś obszerną pomoc, tylko nie chcesz, lub nie potrafisz z niej skorzystać. Jeśli to drugie, to proponuję opisać co jest niezrozumiałego we wcześniej zaproponowanych rozwiązaniach.

Nie mowie o Twoim wpisie, tylko ogólnie - jak postrzegam rozwiązywanie problemów na tym forum.
Ktoś o coś zapytał? Ok, więc zajmujemy się wszystkim innym, byle nie tym o co autor pyta. 3, 2, 1 start!

Wracając do ukladu:
Jest to stan zastany i próba dorobienia do tego płynnego migania Led (rozjazsnianie/ściemnianie, ale nie 1/-1 tylko np kiedy jedna Led gaśnie powoli - 1, to druga rozjaśnia się 3x szybciej.

Rozumiem, że można timerem obsłużyć procedurę programowego pwm, ale i samo miganie Led, czylindodawanie/odejmowanie zmiennych odpowiedzialnych za jasność i to będzie sobie działało niezależnie od tego co w pętli głównej, czy tak?

Justyniunia napisał:

Rozumiem, że można timerem obsłużyć procedurę programowego pwm, ale i samo miganie Led, czylindodawanie/odejmowanie zmiennych odpowiedzialnych za jasność i to będzie sobie działało niezależnie od tego co w pętli głównej, czy tak?

Dokładnie. Czyli timer generuje np. 1000 przerwań/s, tam sobie inkrementujesz/dekrementujesz zmienne, robiąc programowy PWM. W analogiczny sposób sterujesz tym trzecim wyjściem. W takiej sytuacji w pętli głównej programu określasz tylko stan jasności LED oraz czy ten dodatkowy impuls ma być czy nie. Ponieważ przerwanie timera jest deterministyczne, więc odpada problem z nierównym czasem wykonania pętli, co było związane zapewne z blokowaniem procka przez pulseout - tak zakładam, bo nie znam Bascoma.

Wszystko przeniesione do timer, ale sytuacja się powtarza.
Jakiekolwiek zmiany w pętli głównej wpływają na działanie pwm i szybkości migania diod :/

Justyniunia napisał:

Wszystko przeniesione do timer, ale sytuacja się powtarza.
Jakiekolwiek zmiany w pętli głównej wpływają na działanie pwm i szybkości migania diod :/

Czyli źle to zrobiłaś. Pokaż kod.

Pulseout jest ewidentnie blokujacy. Procesor zajmuje się wtedy tylko generowaniem podanej liczby impulsów.

oryginalnie wygląda to tak:



Teraz podobne, ale z serwem i miganiem diodami bez PWM
(tu już są problemy które koryguję waitusami w case, ale działa)



Teraz chcę albo do pierwszego kodu dodać serwo, albo do drugiego PWM dla LED.

Z tego co widzę, to nadal masz funkcję miganie wrzuconą do pętli głównej... a ma być w funkcji, która obsługuje przerwanie timera.
Druga sprawa - nie znam Bascoma, więc nie wiem na ile radzi on sobie z jednoczasowym dostępem do zmiennej z pętli głównej programu i przerwania. W C programista musi sam o to zadbać stosując volatile i sekcje krytyczne. Nie wiem czy Bascom jest tak sprytny, że potrafi sam o to zadbać.
Zmienna czas też nie powinna być inkrementowana w pętli głównej, bo jej czas wykonania jest zmienny, ale np. w przerwaniu timera. Dzięki czemu jej wartość nie będzie zależna od czasu obiegu pętli.

Chwile mnie nie było
Napisałbym to inaczej, ale wracając do pytania z pierwszego postu. Jeśli chcesz by procesor zawsze był tak samo zajęty to każ mu w tych innych Case`ach także nadawać Pulseout tylko na pin Reset. Bascom to przełknie bo ten pin może pracować jako normalny I/O ale jak jest resetem to nic mu się nie stanie jak napiszesz Pulseout Portb , 5 , A

Proponuję jednak sterować tym serwem z przerwania.
Masz Timer 8bit czyli 256.
9,6MHz/256=37500Hz
Książkowo to serwo powinno dostawać impuls co 20ms czyli 50Hz
37500Hz/750=50Hz
Teraz serwo przyjmuje impulsy od 1000us (czyli1ms) do 2000us (2ms)
Żeby odliczyć 1ms przy 37500 trzeba policzyć do 36
Żeby odliczyć 2ms przy 37500 trzeba policzyć do 74
To daje 38 kroków nastawy serwa. Może Tobie to wystarczy.
Można zwiększyć precyzję sterowania przechodząc Timerem w tryb CTC i skracając period.

Tak więc w przerwaniu, obok sterowania LED`ami, umeszczasz kod:


Zmienna A powinna mieć minimum 36 a maksimum 74 i bedzie odpalała impuls 1ms-2ms 50Hz

@tmf Bascom jest sprytny Wystarczy zmienną zadeklarować jako Safe "Dim Moja_zmienna As Word Safe" wtedy przy dostępie do niej w petli głównej obuduje ją CLI i SEI.

@Justyniunia Mam jeszcze jedną radę gdybyś się upierała przy Pulseout.
Ten fragment sprawia, że czasy zawsze będą się rozjezdżać gdy będzie się zmieniała wartość "A"


Pulseout to w przybliżeniu czas równy A x 1us
Im większe A tym dłużej tu stoi.
Proponuję odejmować wartość A od tych 1500us i zawsze czas bedzie ten sam.



Czas na Pulseout zawsze będzie kompensowany tym krótszym dla Waitus.