Witam serdecznie.

Napisałem sobie program o następujących założeniach: Gdy naciskam i przytrzymuje wciśnięty przycisk wypełnienie sygnału sterującego silnik narasta do pewnego momentu a następnie maleje. Gdybym w trakcie narastania/ zmniejszania prędkości puścił przycisk to prędkość zostaje utrzymana na takim poziomie jak była tuż przed momentem puszczenia przycisku.



Przyspieszanie i zwalnianie przycisku nazwijmy jednym cyklem. Problem polega na tym że pod koniec takiego cyklu tzn. gdy silnik zwalnia i zatrzymuje się, to zamiast płynnie przeskoczyć do pierwszego warunku if(i<=255) w przerwaniu INT0 i zacząć znowu powoli się rozpędzać, to silnik dostaje nagłego i krótkotrwałego "kopa" z prędkością a następnie wedle planu powoli jego prędkość zaczyna narastać (cały czas trzymam przycisk a więc cały czas generowane są przerwania) By to lepiej zobrazować nagrałem pare filmików:

https://www.youtube.com/watch?v=te9TawAdtV0

a tutaj jest po kilku cyklach (zwarłem przewody bo nie chciało mi się trzymać tak długo przycisku)

https://www.youtube.com/watch?v=TDfhCK4xAUY

Widać że problem znacznie urasta tzn. ten "kop" prędkości dla silnika w przejściu między cyklami staje się coraz większy i coraz dłuższy. Moje pytanie brzmi: z czego to wynika i jak to wyeliminować? Przeczuwam że ma to związek z czasem trwania przerwań ale nie wiem jak to naprawić i czy na pewno to jest przyczyną.

Pomijam oczywiście sposób wywołania przerwania zewnętrznego tzn. drgania sytków i wystąpienie niekontrolowanych przerwań. Jest to w tej chwili dla mnie nieistotne. Jeżeli program będzie w całości dobrze działał to pomyślę jak to zrobić bez użycia INT0.

Przekombinowałeś. Wywal to int0 i badaj normalnie przycisk, a całą logikę umieść w głównej pętli i wykorzystaj dodatkowy znacznik zmiany kierunku, bo go tu dostrzec nie mogę. To program na dosłownie kilka linijek.

_________________
http://www.sylwekkuna.com

Nie chce zmieniać programu, dobrze jest jak jest. Chce się dowiedzieć tylko dlaczego tak się dzieje i jak rozwiązywać takie problemy, gdy nie będzie alternatywy innego rozwiązania. W założeniach do programu nie uwzględniałem zmiany kierunku.

Chodziło mi o zmianę kierunku liczenia prędkości - narastanie/opadanie

_________________
http://www.sylwekkuna.com

Nadal nie bardzo rozumiem... Jak zmieniać kierunek, po co?

Nie rozumiemy się... Chodzi o fazę zmiany prędkości, np. 0-zwiększa prędkość, 1- zmniejsza prędkość.

_________________
http://www.sylwekkuna.com

Witam

Troszkę zalatuje teorią spiskową, ale kto wie.
Nie widzę sztywnego powiązania i/k - może to się jakoś rozłazi.
Przetestuj to; pisałem na brudno, więc sam nie wiem:


Pozdr.

Edit: zmiana w ostatniej linijce kodu - niedopatrzenie

Również uważam, że niepotrzebnie tak kombinujesz. Szczególnie chodzi mi o inkrementowanie dwóch zmiennych 'i' oraz 'k', bo z tego właśnie wynikają problemy, co już zauważył kolega kicajek. Można to zrobić prościej, np. tak jak proponuje kolega SylwekK (to dobra rada, choć widzę, że na razie nie wiesz za bardzo, o co mu chodzi).

Mimo tego postaram się odpowiedzieć na Twoje pytanie.

Po osiągnięciu przez zmienną i wartości 511, operacja k--; spowoduje przepełnienie zmiennej (k zmieni wartość z 0 na 255).
Gdybyś użył wartości 510, to pewnie byłoby OK:

...nie uważam jednak, że to prawidłowe rozwiązanie problemu.


Może jednak nie jest aż tak dobrze, skoro zadajesz pytanie na forum

Witam
dot. kodu kol.panjakub94

To fakt, też się zawiesiłem chcąc przyjrzeć się temu rozwiązaniu; niemniej jeśli

trzeba to uszanować.
Czasem może być tak, że takie rozwiązanie może mieć zastosowanie w całkiem innym projekcie i wówczas będzie jak znalazł.

Pozdr.

Dzięki serdeczne:) No racja! Czasami ciężko dostrzec takie podstawowe błędy. Twój pomysł zadziałał, dziękuje:)

Kolego kicajek
Sugerujesz, że kiedy widzę, jak ktoś nieświadomie wjeżdża na grząski grunt, to mam go utrzymywać w przekonaniu, że dobrze robi?
Moim zdaniem, kiedy program nie działa zgodnie z założeniem, to TRZEBA go zmienić (lub zmienić założenia  ).
Kiedy ktoś zwraca się o pomoc na forum, to należy mu wskazać błędy i przedstawić jak najlepsze rozwiązanie. Nie jest to chyba wyraz braku szacunku? Nie zrobiłem tego chyba w jakiś chamski sposób?
Jeśli ktoś pomimo otrzymania rady zrobi po swojemu, to jego sprawa (przynajmniej dopóki ktoś inny nie musi ponosić konsekwencji jego decyzji). Ja szanuję jego prawo wyboru i nie zmuszam, żeby zrobił według moich wskazówek (choć być może będę próbował przekonać go do moich argumentów).

@panjakub94
Proponuję, abyś rozważył użycie nieco innego algorytmu (myślę, że to będzie mniej więcej to, co proponował kolega SylwekK):

Myślę, że zadziała równie dobrze, a moim zdaniem kod jest bardziej przejrzysty i mniej podatny na błędy - nie trzeba obliczać jaką wartość musi mieć zmienna 'i', aby zmienna 'k' nie uległa przepełnieniu.
Dodatkowy profit - oszczędzasz w ten sposób 1 bajt pamięci RAM i prawdopodobnie nieco taktów zegara potrzebnych na wykonanie procedury obsługi przerwania.

PS
Mam nadzieję, że nikogo nie uraziłem, nazywając go kolegą

No i właśnie dokładnie o to mi chodziło ze zmianą kierunku liczenia
Takie rozwiązanie jest o wiele bardziej elastyczne i jak przyjdzie pisać autorowi program pokroju jednego z moich sterowników ze swoimi założeniami to mam wrażenie, że zapląta się już na podstawowych funkcjach. Bez urazy, ale ja mam zasadę pisać optymalnie zgodnie ze sztuką nawet najprostsze programy, bo to procentuje w przyszłości

_________________
http://www.sylwekkuna.com

Witam

Absolutnie nie; być może nie jasno opisałem mój tok myślenia, ale sam niejednokrotnie ubzdurałem sobie jakiś algorytm - próbowałem go dopieszczać itd. a na końcu i tak kończyło się to w inny sposób.
Na wszelki wypadek pierwotny kod zachowywałem, a później okazywało się że po drobnych poprawkach z powodzeniem może mieć zastosowanie w całkiem innym urządzeniu.
Czym innym jest przyjęta propozycja "zmień kod" a czym innym jest wczytanie się w zastrzeżenie - nic nie zmieniać tylko poprawić istniejące.

Pozdr.