CPLD - Implementacja układu taktowania interfejsu szeregowego z zegarem

Chciałbym wykonać na układzie programowalnym układ taktowania interfejsu
szeregowego który też będzie na tym układzie. Układ przeliczania ma za zadanie
zliczać okres który będzie zmienny czasowo (będzie pływał) i tak dobrać zegar
interfejsu by ten w wyliczony czasie załoadował interfejsem odpowiednią ilość bitów.
Z interfejsem myślę że nie będzie problemów ale zegar z samym dzieleniem nie wyjdzie. Mam koncepcje żeby wykożystać liczniki rejestry i porównywać je.
Coś na zasadzie jak robi się tajming w procesorze. Ustawiać licznik z zegarem cloka
i wywoływać przerwanie które generuje clock do intefejsu.
Czy da się to przenieść na CPLD?

Nie bardzo rozumiem.
To co jest w procesorze się da przenieść na CPLD bo to jest zwykły dzielnik częstotliwości (czasami nawet ułamkowy ale mniejsza o to).
Ale Ty chcesz coś innego?
Żeby to się synchronizowało do zmiennego zegara (pływającego) a nie stałego jaki jest w normalnym procku?
Tak?
No to to też się pewnie da ale trzeba najpierw wiedzieć co się chce. Ja w tej chwili nie rozumiem o czym piszesz więc się dokładniej nie wypowiem na razie.

Trzeba zczytać okres jednego obrotu w sekundzie i po tym
wyliczyć clocka do interfejsu szeregowego żeby ten np w 1/360 załadował
pewną paczkę bitów. Obroty mogą być nie stabilne a paczki muszą być równo pakowanie w ciągłym czasie pracy układu. 360 paczek na obrót. Chyba będzie potrzebny fpga.

A co to jest obrót w sekundzie?
Bo dla mnie to jest 1obr/s.
A więc nie trzeba mierzyć bo już wiadomo że jest 1obr/s.
Jakoś dziwnie tłumaczysz że nie wiadomo o co chodzi. Narysuj to może jakoś.

sorrki liczbę obrotów w sekundzie ok 8.

Czyli po prostu pomiar prędkości obrotowej.
Skoro wysyłanie tej paczki bitów już masz (albo będziesz miał bo piszesz że to nie będzie problemem) to Ci brakuje tylko tego pomiaru prędkości.
W czym masz z tym konkretny problem?

Pomiar prędkości obrotowej to nie wszystko.
Załóżmy że masz 8 obr/s to jest 125ms na obrót i w tym czasie
musisz załadować 360 paczek po 4 kbit szeregowo x 2 lub 3 nie wiem jeszcze.
Trzeba ten okres 125ms/360 i wyliczać clock do interfejsu szeregowego.
125/360 to masz 340us i wtym czasie musisz 4kbit załadować wychodzi ok clock 11Mhz. I trzeba cały szas to synchronizować z obrotami.
Nie wiem czy samo cpld to zrobi czy raczej fpga?

Nie rozumiem co to za interfejs szeregowy. Myślałem że coś jak UART. Czyli że liczą się dane. A częstotliwość jest stała (też ważna ale stała).
A Ty chyba chcesz coś odwrotnego?
Czyli zmieniać częstotliwość a dane nie są ważne? To sam zegar ma lecieć?
Prościej to na zwykłym analogowym układzie PLL zrobić.
Przy okazji nie musiał byś tych obrotów mierzyć tylko układ sam z siebie by generował odpowiednią częstotliwość wyjściową (bez bezpośredniego pomiaru częstotliwości wejściowej).
Mógbyś napisać do czego to ma być? Bo to dość dziwne.
Mi to raczej wygląda na próbę zsynchronizowania jakiegoś silnika krokowego z wrzecionem w obrabiarce (np. przy nacinaniu gwintu), niż na "interfejs".

To ma też wysyłać dane i laczować po zapakowaniu, czyli trzy linie na interfejs. A wszystko to pobierane z uc po isp. Przydałby się też bufor ram żeby po isp pakować całość a układ ma to rozdzielać i ładować synchronicznie do obrotów. Bez bufora też by się dało ale komplikuje to rozwiązanie. W sumie ISP musi być master do pobierania z synchronicznym clockiem.

Mimo wszystko nie rozumiem dlaczego miało by to być synchronizowane z obrotami.
Na pewno się nie da inaczej?

Nie da. Ja się pytam czy na CPLD się da?

Skoro mówisz że się nie da bez synchronizacji z obrotami to ja jestem na 1000% pewny że się da.
Tak jak chcesz zrobić (czyli z synchronizacją z obrotami) powinno się dać na CPLD, ale trzeba by dołożyć zewnętrzny układ PLL.
A to dlatego że PLLa w CPLD nie zrobisz (wymaga to torów analogowych i nawet w FPGA tego nie upcha). No chyba że jako proteza PLLa czyli jako miernik i generator częstotliwości (cyfrowy).
Od razu mówię że użycie PLLa umieszczonego w układzie CPLD (często takie są wbudowane do generowania zegara) odpada ze względu na zbyt odległy zakres jego częstotliwości (są to jakieś MHz co najmniej, a Tobie trzeba pojedyncze Hz).

Niektóre fpga mają PLL po dwie i trzy.

To co napisałem wyżej dotyczy też FPGA: nie ten zakres częstotliwości.

Ale bez zmiany zegara (przy ustawieniu go na max) też by się wyrobiło. Po prostu przy mniejszej prędkości obrotowej, ze względu na to że zegar nadal by był wysoki, były by przerwy w wysyłaniu tych paczek danych. To nie wydaje mi się być wadą. Ale nie wiem bo autor nie chce powiedzieć co wymaga żeby ten zegar się zmieniał.
Wiem natomiast że prościej wygenerować te dziury w paczkach niż zmieniać zegar w trakcie nadawania.

No ja też rozumiem. Po prostu z doświadczenia wiem że problem może być sztuczny.
Dyskusja jednak jałowa nie była. Odpowiedz kolega dostał.

Na razie odrzuciłem projekt.
Niestety wyliczenie płynności zegara dla transmisji szeregowej ok 14mhz
jest nie do zrobienia. Ale doszedłem do wniosku że nie jest to potrzebne
bo ładować dane do rejestrów można ze stałą prędkością dla układów rejestrów
to 30Mhz. A jedynie kontrolować czas wyzwolenia ładowania danych i czas
przerzucania danych z latch do źródeł prądowych w tych układach połączonych szeregowo. Ramki wyzwalające o ile pamiętam były by co 273ms i udało mi się to
zrobić na cyklon4 nawet nieźle działa. Obliczenia po jednym obrocie czyli reakcja spóźniona o jeden obrót. Nie było by to jednak duża przeszkodą niezauważalną.
Projekt jest do zrealizowania bo znalazłem na sieci gotowy układ podobnie zrobiony do mojej koncepcji z tym że tam do obliczania obrotów służył encoder.
Może to i lepsze ale mieli problemy z tym enkoderem i musieli dopisać korekcję
do zmierzonych impulsów na obrót.