optymalna predkosc robota

[OldSkull]

Niezbyt mnie zrozumieliście - 10 (nawet 16) instrukcji między pomiarami to niewiele, pętle sobie można darować, a zwykłych obliczeń też za dużo nie zrobimy. A na to, że ważniejsze są koła i silniki (oraz ogólnie konstrukcja), również zwróciłem uwagę. Z 20-80kS/s już nie ma najmniejszego problemu, ale jest to wartość mniejsza o ponad rząd wielkości.

[KD93]

Treker, tylko wiesz, japoniec to jeszcze pisać nie potrafi a już elektronikę montuje, nie ma się co porównywać z Japonią.

[TIMONek]

@OldSkull

Ja cały czas Ciebie nie rozumiem. Pokażę może przykład kodu (ATmega 1280). Przetwornik ustawiony, aby pracował z częstotliwością 1MHz.

Obsługa przerwania od ADC:

ISR(ADC_vect)
{
WynikiADC[i] = ADCH; // Zapisanie wyniku konwersji
i++; // Nowy indeks tablicy

if((7&ADMUX) == 7){
	ADMUX = ADMUX & (0b11111000);

	if((ADCSRB & (1<<MUX5)) == 0) ADCSRB |= (1<<MUX5);
	else{
		ADCSRB &= ~(1<<MUX5);
		i=0;
	}
}
else ADMUX = ADMUX + 1;

ADCSRA |= (1<<ADSC); // Następna konwersja ADC
}

Powyższy kod zapisuje do tablicy wyniki konwersji z 16 wejść przetwornika ADC. Ja używam tego do programowania sumo. Co z tego, że za 13 us będzie kolejne przerwanie od przetwornika ADC, to w niczym nie przeszkadza. Wręcz odwrotnie - bardzo często uaktualniane dane z czujników pozwalają mi zrobić np. dodatkowe uśrednianie wyników w bardzo krótkim czasie.

Ale nawet jeśli konwersja co 20 taktów procesora (czyt. co parę rozkazów) Ci 'przeszkadza' (choć nie wiem czemu miałoby) to co za problem użyć dodatkowego timer'a, który będzie wyzwalał przetwornik tak często jak potrzebujesz.

Moim zdaniem nie ma lepszego sposobu na sprawdzanie czujników, szczególnie sharpów (choć kwestia dotyczyła linefollower), gdy dochodzą zakłocenia od silników i pozostałych czujników.