Możliwość wdrożenia algorytmu PID na prostym CPLD - czy wystarczy zasobów?

i miesiąc siedzenia nad softem, ktoremu czasem zdarzy sie pojsc w maliny i
dźwig wjedzie w sciane albo winda do nieba pojedzie

Pozdrawiam

Witam ponownie
już liczyłem to co kolega pisze
mam enkodery już sprzęgnięte fabrycznie z servem mam takie co maja 250 imp
/obr
ale mam i takie co mają 2500 i 5000 i tu zaczynają się schody AVR już się
nie wyrobi
oprócz obsługi enkodera powinno byc miejsce na prosty PID
i tak sobie kombinuje co by tu mądrego wymyslić

Ale czy aż taka rozdzielczość jest Koledze potrzebna ?! 5000imp/obr to
0,072 stopnia. A jakie obroty ? W ostateczności można do obsługi enkodera
zaprząc liczniki w AVRku.
Korzystając z zewnętrznego licznika enkodera na jakimś CPLD trzeba jakoś
ten stan licznika zczytać do procesora. Jeśli pojemność licznika ma mieć
np. 32bity to musisz w CPLD zaszyć jakiś rejestr buforowy coby na czas
transmisji zatrzasnąć bieżący stan licznika. Inaczej gdy w podczas
przesyłania danych z CPLD do uC przyjdzie impuls z enkodera (co przy
takiej rozdzielczości jest wysoce prawdopodobne) to uC może odczytać
niezłą kaszankę.

Użytkownik Szumek napisał:
Pozdrawiam

Witam ponownie
już liczyłem to co kolega pisze
mam enkodery już sprzęgnięte fabrycznie z servem mam takie co maja 250
imp /obr
ale mam i takie co mają 2500 i 5000 i tu zaczynają się schody AVR już się
nie wyrobi
oprócz obsługi enkodera powinno byc miejsce na prosty PID
i tak sobie kombinuje co by tu mądrego wymyslić


Ale czy aż taka rozdzielczość jest Koledze potrzebna ?! 5000imp/obr to
0,072 stopnia. A jakie obroty ? W ostateczności można do obsługi enkodera
zaprząc liczniki w AVRku.
Korzystając z zewnętrznego licznika enkodera na jakimś CPLD trzeba jakoś
ten stan licznika zczytać do procesora. Jeśli pojemność licznika ma mieć
np. 32bity to musisz w CPLD zaszyć jakiś rejestr buforowy coby na czas
transmisji zatrzasnąć bieżący stan licznika. Inaczej gdy w podczas
przesyłania danych z CPLD do uC przyjdzie impuls z enkodera (co przy
takiej rozdzielczości jest wysoce prawdopodobne) to uC może odczytać
niezłą kaszankę.

Pozdrawiam
Grzegorz

ponieważ z CPLD dopiero zaczynam trudno mi jest ocenic co wejdzie do takeigo
układu a co nie
czy jego sasoby pozwolą na stworzenie to o czym my tu piszemy czy nie ?

ponieważ z CPLD dopiero zaczynam trudno mi jest ocenic co wejdzie do
takeigo układu a co nie
czy jego sasoby pozwolą na stworzenie to o czym my tu piszemy czy nie ?

Co do CPLD - polecam poeksperymentować ... ale tak "z góry" oszacować
wymagania też się da. Podstawowy problem to ilość makrocel, a co za tym
idzie też przerzutników... Musisz ocenić ile stanów ma obsługiwać
urządzenie... jeśli robisz licznik - no to potrzebujesz tyle makrocel ile
bitów ma licznik. Pamiętaj też o preskalerach częstotliwości (jeśli byś do
czegoś potrzebował ;P) - to też są liczniki. Jeśli potrzebujesz buforować
stan licznika - to podobnie znów drugie tyle bitów leci... jakieś
sterowanie - powiedzmy SPI, jeśli typowe - to 8 bitów zużywasz na
zapamiętanie sygnałów wejściowych/wyjściowych plus 3 bity, żeby policzyć
do 8 ... to takie minimum... więc dla licznika 32 bity z buforowaniem i
dostępem przez SPI potrzebujesz 75 makrocele... Lub więcej Wszystko
zależy na ile masz zaawansowaną logikę... w większości przypadków
wystarczy logika "podpięta" do danej makroceli... Wówczas nie ma problemu.
Gorzej, gdy któraś funkcja "rośnie"... i jest zależna od dużej liczby
sygnałów... wtedy logika podłączona do innej makroceli zostaje
wykorzystana do jakiegoś sygnału "wewnętrznego", albo połączona z logiką
"sąsiednią" - i wtedy jakby maleje Ci liczba makrocel, którymi
dysponujesz...
Tak więc określasz minimum które potrzebujesz i pozostawiasz zapas. Warto
także wybrać takie układy, które mają swoje większe odpowiedniki ... Ja
się tak kiedyś wkopałem, wziąłem CPLD 64 makrocele w PLC44, nie starczyło
miejsca i psikus, wersji 128 makrocel nie można było dostać w tej obudowie
... Warto projekt (prototyp) zrobić w większym układzie, gdy przejdzie
testy, można śmiało w programie eksperymentować w który układ kod się
wciśnie, a w który nie i później stosować już mniejszy (tańszy) układ...

Pozdrawiam
Konop

PS Oczywiście makrocele to nie wszystko... miałem projekt, który
"wchodził" w ukłąd XCR3064 (64 makrocel), a nie wchodził w układ XC9072XL
(72 makrocele)... ale nie będę Cię zamęczać szczegółami ...

już mi się sprawa dzięki wam naświetla
narazie wezmę mniejsze servo ze słabszym enkoderem i podziałam na avr z tym
co mam dopuki nie wymyslę jak sterowac tamtymi

On Sat, 5 Dec 2009 14:43:05 +0100, Szumek wrote:
już mi się sprawa dzięki wam naświetla
narazie wezmę mniejsze servo ze słabszym enkoderem i podziałam na avr z tym
co mam dopuki nie wymyslę jak sterowac tamtymi

Uzycie CPLD/FPGA moze nie byc takie glupie - jest mniejsza szansa ze
zgubi impulsy, wiec przynajmniej dekoder i licznik bym tam wsadzil.

J.F. wrote:
Uzycie CPLD/FPGA moze nie byc takie glupie - jest mniejsza szansa ze
zgubi impulsy, wiec przynajmniej dekoder i licznik bym tam wsadzil.

Aha, ta
Zwlaszcza jak nie odkloci zboczy i wsadzi je na licznik rewersyjny jako
asynchroniczne do zegara
Zwlaszcza te drugie powoduje ciekawe efekty uboczne.

Zwlaszcza jak nie odkloci zboczy i wsadzi je na licznik rewersyjny jako
asynchroniczne do zegara
Zwlaszcza te drugie powoduje ciekawe efekty uboczne.

Zwlaszcza jak nie odkloci zboczy i wsadzi je na licznik rewersyjny
jako asynchroniczne do zegara
Zwlaszcza te drugie powoduje ciekawe efekty uboczne.

A jakie są przeciwskazania do podłączenia tego sygnału jako zegarowy??

Tylko po co? Bedziesz i tak musial przejsc do domeny zegarowej ukladu,
wiec zegar lokalny dla enkodera nie ma sensu. Z enkodera masz 2
asynchroniczne sygnaly, z nich generujesz + i -, ktore dalej sa
asynchroniczne. W ktoryms miejscu przechodzisz do doemny zegarowej
ukladu - jak nie wiesz jak to zrobic, to sie beda dzialy cuda.