Możliwości atmegi16??

[OldSkull]

Powiem tak: robiłem pomiar z enkoderów dla 2 silników z enkoderami dwukanałowymi 10000imp/obrót i prędkości do 100rpm, co dawało mi przy badaniu tylko obu zbocz jednego kanału ponad 66tys. przerwań na sekundę. Dodatkowo obliczałem 63 razy na sekundę prędkość, oraz pełną odometrię oraz komunikowałem sie przez SPI. Procesor był mocno obciążony, ale wytrzymał. Wniosek: nie trzeba kombinować.

Dodatkowo: sprawdzenie kierunku wymaga wykonania sprawdzenia if() dotyczącego stanu drugiego kanału, ale porównaniu prędkości to też wykonanie sprawdzenia if() dotyczącego prędkości. Zysk? Zależy od tego jak jest napisana reszta programu, ale albo jest zerowy albo bardzo niewielki i w praktyce nieopłacalny.

[dondu]

Wniosek: nie trzeba kombinować.

Zależy od tego jak jest napisana reszta programu, ale albo jest zerowy albo bardzo niewielki i w praktyce nieopłacalny.

Każde oprogramowanie można napisać nieefektywnie np. tak jak to opisałeś, zwalając całą robotę na CPU, nie wykorzystując dedykowanych do tego typu zadań układów wewnętrznych.

Skoro nie widzisz zysku, który wymieniłem już parokrotnie w tym temacie - no cóż - Twoja wola. Na siłę przekonywać Cię nie mam zamiaru

A potem się dziwią czemu samochody Red Bull'a są najszybsze.

[OldSkull]

Uważam, że nie napisałem nieefektywnie, powiem wręcz, że bardziej efektywnie się nie dało (w tym przypadku). W którym niby miejscu zwalam całą robotę na CPU? Nie zapominaj, że AVRy mają stosunkowo mało peryferii. Najlepiej byłoby wykorzystać wejścia Capture od liczników, ale w takim wypadku liczników musiałoby być minimum cztery 16-bitowe. Jak niby mam wykorzystać coś, czego procesor nie posiada?

Nie potrafisz zrozumieć, że nakład obliczeniowy na sprawdzenie kierunku jest taki sam jak na sprawdzenie prędkości.

edit: poprawka, wystarczą 2 timery, ale i tak problem kierunku zostaje.

[dondu]

Masz rację, zbyt pochopnie napisałem, że Twoje rozwiązanie jest nieefektywne tym bardziej, że nie podałeś typu procesora.

Nie potrafisz zrozumieć, że nakład obliczeniowy na sprawdzenie kierunku jest taki sam jak na sprawdzenie prędkości.

Odpowiem podobnie: Nie potrafisz zrozumieć, że sprawdzanie kierunku powyżej Vmin nie jest Ci potrzebne.

[OldSkull]

Nie jest potrzebne, ale co z tego, skoro należy sprawdzać prędkość? Zysku nie widzę.

Procesor w moim przypadku to był ATmega128

[dondu]

Nie jest potrzebne, ale co z tego, skoro należy sprawdzać prędkość? Zysku nie widzę.

Ja o kozie Ty o wozie - tylko proszę nie obrażaj się, bo nie jest to moim celem.

Ideą tego tematu od początku jest zliczanie impulsów z enkoderów programowo.

Ja proponuję rozwiązanie sprzętowe. I to jest zysk, wielokrotnie przeze mnie cytowany.

Ale jeszcze raz wymienię:

Zyskujesz moc obliczeniową CPU przez co:

- możesz ją wykorzystać w innych bardziej potrzebnych celach,
- możesz zastosować mniejszy/tańszy/wolniejszy mikrokontroler,
- możesz zmniejszyć pobór prądu przez jednostkę sterującą pracująca z reguły z akumulatora.

Mało? Jak dla mnie to spory zysk.

[Bobby]

dondu, ale gdzie zyskujesz tą moc obliczeniową? Przecież i tak musisz sprawdzić IFa, czy to od Vmin czy to od kierunku.

[dondu]

dondu, ale gdzie zyskujesz tą moc obliczeniową? Przecież i tak musisz sprawdzić IFa, czy to od Vmin czy to od kierunku.

Zanim zadasz pytanie, poświęć trochę czasu i przeczytaj to co wielokrotnie już pisałem.

Jeżeli każdemu mam ciągle to samo tłumaczyć, to wybacz nie mam na to chęci.

Ale zrobię wyjątek by już następni pytań nie zadawali i na przykładzie:

Powiem tak: robiłem pomiar z enkoderów dla 2 silników z enkoderami dwukanałowymi 10000imp/obrót i prędkości do 100rpm, co dawało mi przy badaniu tylko obu zbocz jednego kanału ponad 66tys. przerwań na sekundę. Dodatkowo obliczałem 63 razy na sekundę prędkość, oraz pełną odometrię oraz komunikowałem sie przez SPI. Procesor był mocno obciążony, ale wytrzymał.

66tys przerwań na sekundę! zgroza!

A w mojej wersji z licznikami, 63 przerwań na sekundę jak chce OldSkull, czy nawet 1000 jak chce autor tematu.

Teraz widzisz gdzie jest zysk i jak duży?

[OldSkull]

Wiem już o co chodzi, ale przerwania mają jedną wielką zaletę: w każdym przerwaniu mogę zmieniać zbocze na którym wywołuję przerwanie, dzięki czemu zwiększam w tani sposób dwukrotnie rozdzielczość, a przy dwóch kanałach nawet czterokrotnie. Można nawet obliczać prędkość na podstawie czasu miedzy impulsami, co jest bardzo przydatne przy enkoderach niskiej rozdzielczości. To są dwa rozwiązania tego samego problemu. Ale nikt nam nie karze zawsze nie używać liczników oraz co określony czas sprawdzać kierunek w przerwaniu od innego licznika - w takim wypadku zysku nie ma.

Częściowo zwracam honor , problemem były pewne niedopowiedzenia. Każde z tych rozwiązań ma pewne wady. Chodzi Ci o rozwiązanie: przerwania na zboczach vs liczniki.

AVRy generalnie mają niewiele timerów wysokiej rozdzielczości i równoczesne sterowanie dwoma silnikami i pobieranie informacji od dwóch dwukanałowych enkoderów może być bardziej niż kłopotliwe.

[dondu]

w każdym przerwaniu mogę zmieniać zbocze na którym wywołuję przerwanie, dzięki czemu zwiększam w tani sposób dwukrotnie rozdzielczość, a przy dwóch kanałach nawet czterokrotnie.

Można nawet obliczać prędkość na podstawie czasu miedzy impulsami, co jest bardzo przydatne przy enkoderach niskiej rozdzielczości.

Ale ten problem nie występuje przy zastosowaniu liczników. już wcześniej o tym pisałem, ale mogło ujść Twojej uwadze.

To samo robisz na timerach:

- od 0 do Vx, timer liczy w trybie zliczania czasu trwania szerokości impulsu enkodera (timery mają odpowiedni tryb pracy),
- od Vx do Vmax tylko zlicza impulsy.

gdzie Vx jakaś ustalona granica, zmiany sposobu liczenia prędkości.

A zyski wymienione powyżej nadal pozostają

... problemem były pewne niedopowiedzenia.

Tak to zawsze jest problem tego typu tematów

Każde z tych rozwiązań ma pewne wady. Chodzi Ci o rozwiązanie: przerwania na zboczach vs liczniki. AVRy generalnie mają niewiele timerów wysokiej rozdzielczości i równoczesne sterowanie dwoma silnikami i pobieranie informacji od dwóch dwukanałowych enkoderów może być bardziej niż kłopotliwe.

Oczywiście zawsze to jest pewien KOMPROMIS.

Propozycja:

Z chęcią pomógłbym komuś napisać tego typu rozwiązanie, jeżeli będzie zainteresowany, w C na mikrokontroler PIC lub AVR.

----------------------------------------

Częściowo zwracam honor

Może herezja to za duże słowo,..

.

Oj, nie o honor czy herezje mi tutaj chodzi

Generalnie odczuwam niechęć ze strony Diodowców, to tego co piszę.

Nie twierdzę, że zawsze mam rację, ale proponując rozwiązania, chciałbym abyście je traktowali jako tematy do dyskusji. Ja także się uczę tutaj i nabywam doświadczenia, bo może robota jakiegoś konkretniejszego machnę (na razie tylko trzy małe mam na koncie).

Ja zawsze jestem pozytywnie nastawiony do wymiany doświadczeń

[Bobby]

A teraz to już rzeczywiście widzę Podobnie, zwracam honor.

[dondu]

Nie ma sprawy

[grabo]

A ja lubię prowokować bo dzięki temu powstają ciekawe dyskusje w tematach, a nie ciągle tylko problemy z podłączeniem ATmegi do STK200 albo sprawdzenie schematów

[dondu]

No to już będę wiedział

Ale prośba nie rób tego wobec mnie, bo nie znam Was jeszcze na tyle, by filtrować takie zaczepki :D:D