M128 czy podoła - enkodery inkrementalny i inne peryferia

Witam.
Podczas projektowania robocika 4 kołowego z 4 silnikami(pololu lub HL149) chciałem założyć na oś 4 tarcze z myszy kulkowej i układ opto (dioda IR +fototranzystor podwójny)+komparatory LM358D
Planuje kontrolować przebytą drogę jak i kierunek obrotu kół(coś ala kontrola trakcji),
8 wyjść z komparatorów planuje podłączyć pod 8 przerwań zewnętrznych AT128 .
O sprzętowych peryferiach to wiem i je uwzględniłem
I teraz nasuwa się pytanie a właściwie pytania :

1- int1 ma wyższy priorytet niż inne nie będzie konfliktu jak enkodery wywołają przerwanie na innych pinach przerwań ??(przerwanie będzie inkrementowało zmienna(droga) i sprawdzało ustawiało flagę kierunku

2-czy atmega przy 16MHz (Vcc-3,3V) wyrobi się z m.in. : karta sd (mapa terenu) lcd z s65
(proste menu) , akcelerometr,

3-generowanie PWM 2 kanały

4-kontrola nap aku (adc)

5-uart (btm222)

6-kilka pinów sterowanie oświetleniem

7-określanie najbardziej optymalnej drogi (algorytmu jeszcze nie określiłem)

8-timer1 32,768kHz

I to na razie tyle chyba że jeszcze mi się coś przypomni a sam liczę, myślę i już sam nie wiem może zredukować enkodery do 2 sztuk tzn. 4 wyjść tylko z tylnych kół ??
Pomóżcie

Schemat myślę że nie jest potrzebny ale mogę umieścić.
Pozdrawiam i dziękuje za pomoc

Atmega przy zasilaniu 3,3V nie powinna być taktowana 16 MHz. Sam procek oczywiście bez problemu podoła zadaniu ktore opisujesz, tak naprawdę to tam nigdzie nie ma jakiś szczególnych wymagań związanych z mocą obliczeniową. Ważne aby poprawnie napisać program.

A możesz opisać dokładniej jak ty byś to zrobił ??
Bo ja już głupieje :/
8przerwań zew. generowanych co "chwile" , w których inkrementacja ,znacznik obrotów . Potem wyliczenie odległości i pozycji robota , zapis na sd wyliczenie najbardziej optymalnej trasy z pkt A do B .

8 przerwań, ale nie co chwilę. Jak szybko będą się kręcić te tarcze? 300 imp/s? To masz 300*8 przerwań na sekundę, dla taktowania 16 MHz, masz prawie 6700 taktów na przerwanie. Skoro ono ma inkrementować licznik + cośtam to masz powiedzmy 100 taktów na jego obsługę. Ciągle zostaje 6600 taktów na coś innego.

Nie wiem co ty za potwora tworzysz , ale trochę mnie dziwi, że chcesz na koła zakładać wskaźnik kierunku ich obrotów do czego potrzebne jest dwie linie. Ja bym to uprościł i zrobił tylko na jednym impulsatorze (potrzebna tylko jedna linia portu i dużo prostsza obsługa) aby mieć informację o tym, że koło się kręci (w samochodowych ABS ma po jednym czujniku na koło i to wystarczy). Przecież w programie deklarujesz kierunek i wątpię żeby miała miejsce sytuacja, w której koło będzie się kręcić "pod włos"...

ABS-owi w samochodzie to bez znaczenia w którą stronę się koła kręcą.
Np. w programie z jazdy na wprost przy 80% prędkości max zmieniam na jazde do tyłu i co wtedy ??? zanim silniki wyhamują i zmienią kierunek obrotu to enkoder złapie kilka kilkanaście imp. nawet uwzględniając hamowanie przeciw prądem .

Albo czegoś nie łapie albo opisz swój pomysł trochę lepiej .

tmf tak ale zapis odczyt SD , obliczanie trasy myślisz ze dam rade się w tych taktach zmieścić ??
Załóżmy obroty silnika 3000/min enkoder , 24ipm/360st. , 4 koła , podwójne fototranzystory

czyli
3000 * 24 *2 *4= 576000 przerwań na min czyli 9600 przerwań na sekundę każde przerwanie z 500 cykli .

A to tylko dla przykładu mojego rozumowania ale enkodery będą miały sporo więcej imp/360 st

Kolego, zanim przejdziesz do realizacji tego projektu to zacznij od podstaw. Nie obraź się, ale z tego co piszesz widać, że masz niezbyt duże doświadczenie. Prosty przykład - twoje koła będą miały 3000 obr/min? A pozycję kół chcesz mieć z dokładnością lepszą niż 1 stopień? Zastanów się nad tym. Zresztą nawet gdybyś miał aż 9600 przerwań/s to i tak przy 16 MHz, masz ponad 1600 taktów na przerwanie, aż nadto. Operacje z SD są czasochłonne, ale nie dla procesora. Dobrze napisana obsługa SD (nieblokująca) zajmuje procesor minimalnie.

Fobos319 napisał:

Np. w programie z jazdy na wprost przy 80% prędkości max zmieniam na jazde do tyłu i co wtedy ??? zanim silniki wyhamują i zmienią kierunek obrotu to enkoder złapie kilka kilkanaście imp. nawet uwzględniając hamowanie przeciw prądem .

I gdzie tu problem ?? Przecież i tak cały czas musi być mierzona częstotliwość więc po zmianie kierunku procesor o tym wie (jakiś odpowiedzialny za to znacznik musi być w programie...) i teraz wystarczy badać aż częstotliwość spadnie do zera (osiągnie jakieś minimum) i znowu zacznie rosnąć - to wyraźny znak że koła kręcą już w dobrą stronę.