Udało mi się komputer do współpracy namówić.
Kolego
Yogi_, w odpowiedzi na twoje pytanie przeprowadziłem krótkie testy z wykorzystaniem avr-gcc (pod ATmega32):
Kod: Zaznacz cały
Działanie c = a / b
Optymalizacja: 0
Typ Ilość cykli
int8: 248
uint8: 93
int16: 254
uint16: 221
int32: 646
uint32: 613
int64: 4001
uint64: 3726
float: 473
Z tym że ilość cykli będzie zależna od wartości zmiennych, najbardziej dla float, waha się w zakresie +/-20.
Optymalizacja nieznacznie poprawi te wyniki bo dzielenie wykonują i tak już zoptymalizowane funkcje.
Yogi_ pisze:Ośmiobitowego procka może to zaboleć
Czy ma go co boleć? Jeśli (po spojrzeniu na to pobieżnie) dobrze rozumiem to przy każdym roku jest przeliczane tylko tylko
p a to tylko dodawanie i 3 mnożenia (w trakcie ramp) i jakieś skoki warunkowe. Zakładając użcie float-ów (przy całkowitych możnaby myślę, że prawie 2 krotnie zaoszczędzić czasu), icząc PI razy drzwi wychodzi coś kolo 600 cykli, przy 16MHz to 37,5us i puki nie będziemy silnika kręcić szybciej niż te około 20~25kHz to można się zmieścić jeszcze z jakąś komunikacją.
20kHz przy mikrokroku 1/16 i silniku 200 step/rev daje nam 6,25 obr/sek, przy kole o średnicy 1 cm to prawie 20 cm/s na pasku prędkości przesuwu karetki.
Yogi_ pisze:ten "variable delay period" bym stablicował, w zależności od ilości
Może mi coś umknęło, ale co tam jest do tablicowania?
R obliczamy raz przed wykonaniem ruchu a
m przyjmuje tylko trzy wartości, jeden
if i po sprawie.
Są AVRki co i szybsze zegary wytrzymują a i tak drobny mikrokrok w tym zastosowaniu nie wydaje się aż tak potrzebny (jedynie aby wygładzić przejazd, ale to też i przy mniejszej ilości kroków odpowiednim sterownikiem można zrobić), stąd też uważam, że nie ma się co martwić.
Pozdrawiam,
GSM
P.S.
W dzień przeczytam sobie dokładnie tego PDF-a, bo teraz trochę ciężko się myśli.
,to jest to o co mi chodziło 
