21.08.2015 15:25
[#1]
Moja platforma badawcza z interfejsem SPI
Moja platforma jest zakładana na port zegara i posiada sprzętowy kontroler SPI (master).
Na chwilę obecną mam przetestowane dwa urządzenia. Pierwsze to zegar czasu rzeczywistego oraz dekoder mp3 (i jeszcze 2 innych formatów).
Oczywiście stoi otworem także sieciówka (już idzie pocztą
).
O postępach będę informował, a co niektórzy będą mogli niebawem testować nowe "ustrojstwa" 
Ostatnia aktualizacja: 21.08.2015 15:27:51 przez spidi
Na chwilę obecną mam przetestowane dwa urządzenia. Pierwsze to zegar czasu rzeczywistego oraz dekoder mp3 (i jeszcze 2 innych formatów).
Oczywiście stoi otworem także sieciówka (już idzie pocztą
).O postępach będę informował
, a co niektórzy będą mogli niebawem testować nowe "ustrojstwa" Ostatnia aktualizacja: 21.08.2015 15:27:51 przez spidi
21.08.2015 16:01
[#4]
Re: Moja platforma badawcza z interfejsem SPI
@spidi, post #1
Fajne. SPI master jest na CPLD czy na mikrokontrolerze zrobiony?
Taka uwaga/propozycja. Jeśli ma to być platforma badawcza, to może warto byłoby połączyć siły, bo chyba każdy, kto tutaj zajmuje się projektowaniem sprzętu, coś podobnego już sam zdążył zrobić...
Gdybyśmy opracowali zunifikowaną wersję tej platformy, to potencjalnie byłoby to z pożytkiem dla użytkowników
.
Nota bene, jeśli chodzi o dekoder MP3, to układy VS1xxx jeśli mają być sterowane z Amigi, wymagają większego bufora, zaimplementowanego np. w postaci mikrokontrolera. W innym wypadku bardzo ciężko utrzymać płynność odtwarzania (co wiedzą wszyscy którzy posiadają kiepściacki dekoder MP3 na clockport z a1k.org).
Kolega Sanjyuubi zbadał już tą kwestię dość dokładnie
.
Taka uwaga/propozycja. Jeśli ma to być platforma badawcza, to może warto byłoby połączyć siły, bo chyba każdy, kto tutaj zajmuje się projektowaniem sprzętu, coś podobnego już sam zdążył zrobić...
Gdybyśmy opracowali zunifikowaną wersję tej platformy, to potencjalnie byłoby to z pożytkiem dla użytkowników
.Nota bene, jeśli chodzi o dekoder MP3, to układy VS1xxx jeśli mają być sterowane z Amigi, wymagają większego bufora, zaimplementowanego np. w postaci mikrokontrolera. W innym wypadku bardzo ciężko utrzymać płynność odtwarzania (co wiedzą wszyscy którzy posiadają kiepściacki dekoder MP3 na clockport z a1k.org).
Kolega Sanjyuubi zbadał już tą kwestię dość dokładnie
. 21.08.2015 17:18
[#5]
Re: Moja platforma badawcza z interfejsem SPI
@strim_, post #4
Kontroler SPI jest zrobiony na CPLDku. Ma zaimplementowaną komunikację full-duplex, kontrolę dla CPOL, CPHA, programowalny dzielnik dla sygnału zegarowego. Posiada rejestr sterujący, statusu oraz rejestry dla zapisu i odczytu danych.
Jeśli chodzi o pierwsze eksperymenta z VS1..., to już jakiś czas temu wypadły obiecująco :)
Jeśli chodzi o pierwsze eksperymenta z VS1..., to już jakiś czas temu wypadły obiecująco :)
21.08.2015 17:45
[#6]
Re: Moja platforma badawcza z interfejsem SPI
@strim_, post #4
Bardzo podoba mi się idea platformy do eksperymentów. Sam zastanawiałem się jak ją zrobić. Byłbym zainteresowany, żeby wspólnie ją uzgodnić. Mogę mieć troszkę inne priorytety niż Wy, ze względu na to, że dysponuję już zestawem startowym FPGA.
Rozważałem troszeczkę bardziej elastyczną wersję. Przede wszystkim zależało mi na możliwości przechwycenia dekodowania adresów / sterowania sygnałami chip select (funkcjonalność Gayle'a), pełnej szynie 32-bitowej dla danych i 24-bitowej dla adresów. W ten sposób oprócz szerszej szyny danych byłaby możliwość zadania innego timingu dostępu do peryferiów (odsyłam do specyfikacji Gayle'a). Oprócz dużo większej przepustowości można by zrealizować prosty mechanizm DMA, co zwolniłoby procesor od żmudnego kopiowania danych z urządzeń zewnętrznych do pamięci (np. IDE).
Myślałem o wpięciu się w Gayle'a przy pomocy podstawki PLCC84, a linie danych i adresowe można chapnąć z ROMu - jest to rozwiązanie identyczne jak w FastATA. Przy zdekodowaniu interesującego zakresu adresów Gayle'a można wyłączyć pinem OVR. Zamiast CPLD dałbym konwertery stanów logicznych i złącza gold pin do wpięcia się tanim i potężnym zestawem startowym FPGA (można zamówić od Chińczyków) biegającym na 3.3V.
Co o tym myślicie?
Rozważałem troszeczkę bardziej elastyczną wersję. Przede wszystkim zależało mi na możliwości przechwycenia dekodowania adresów / sterowania sygnałami chip select (funkcjonalność Gayle'a), pełnej szynie 32-bitowej dla danych i 24-bitowej dla adresów. W ten sposób oprócz szerszej szyny danych byłaby możliwość zadania innego timingu dostępu do peryferiów (odsyłam do specyfikacji Gayle'a). Oprócz dużo większej przepustowości można by zrealizować prosty mechanizm DMA, co zwolniłoby procesor od żmudnego kopiowania danych z urządzeń zewnętrznych do pamięci (np. IDE).
Myślałem o wpięciu się w Gayle'a przy pomocy podstawki PLCC84, a linie danych i adresowe można chapnąć z ROMu - jest to rozwiązanie identyczne jak w FastATA. Przy zdekodowaniu interesującego zakresu adresów Gayle'a można wyłączyć pinem OVR. Zamiast CPLD dałbym konwertery stanów logicznych i złącza gold pin do wpięcia się tanim i potężnym zestawem startowym FPGA (można zamówić od Chińczyków) biegającym na 3.3V.
Co o tym myślicie?
21.08.2015 18:03
[#7]
Re: Moja platforma badawcza z interfejsem SPI
@cahir, post #6
@Spidi
Spróbuj coś bardziej zasobożernego robić na Ami w trakcie odtwarzania, to zobaczysz w czym jest problem. Bufor VSów jest bardzo mały i ciężko się zarządza jego zawartością w trakcie odtwarzania. Generalnie trzeba pollować z Amigi, a to znów nie jest eleganckie rozwiązanie. A gdyby mieć bufor w mikrokontrolerze zrobiony, można to zrobić bardzo elastycznie i np. wywoływać przerwanie do Amigi tylko wtedy gdy połowa bufora mikrokontrolera została wysłana do VSa. Efekt: praktycznie 0% obciążenia CPU w trakcie odtwarzania i nic nie zrywa.
@cahir
Pomysł jest fajny do testów, choć nie za bardzo wyobrażam sobie rozwiązania produkcyjnego, instalowanego w ten sposób (kanapka ble~). W tym momencie można byłoby już rozważyć wykonanie karty na trapdoor, bo przecież tam też są wszystkie sygnały których potrzebujesz (z OVR włącznie)...
No ale, tak, generalnie jestem za jakąś otwartą platformą do eksperymentowania z FPGA (choć można w tym celu zrobić osobny watek).
Jeśli chodzi o specyfikację Gayle, to weź pod uwagę że ona dotyczy jakiegoś wczesnego prototypu i jest w wielu miejscach niepoprawna (choćby adresy są złe)! Choć akurat OVR działa generalnie tak jak tam napisano.
Btw. Ty nie jesteś przypadkiem gościem co napisał sterownik FastATA dla Linuxa?
Ostatnia aktualizacja: 21.08.2015 18:22:37 przez strim_
Spróbuj coś bardziej zasobożernego robić na Ami w trakcie odtwarzania, to zobaczysz w czym jest problem. Bufor VSów jest bardzo mały i ciężko się zarządza jego zawartością w trakcie odtwarzania. Generalnie trzeba pollować z Amigi, a to znów nie jest eleganckie rozwiązanie. A gdyby mieć bufor w mikrokontrolerze zrobiony, można to zrobić bardzo elastycznie i np. wywoływać przerwanie do Amigi tylko wtedy gdy połowa bufora mikrokontrolera została wysłana do VSa. Efekt: praktycznie 0% obciążenia CPU w trakcie odtwarzania i nic nie zrywa.
@cahir
Pomysł jest fajny do testów, choć nie za bardzo wyobrażam sobie rozwiązania produkcyjnego, instalowanego w ten sposób (kanapka ble~). W tym momencie można byłoby już rozważyć wykonanie karty na trapdoor, bo przecież tam też są wszystkie sygnały których potrzebujesz (z OVR włącznie)...
No ale, tak, generalnie jestem za jakąś otwartą platformą do eksperymentowania z FPGA (choć można w tym celu zrobić osobny watek).
Jeśli chodzi o specyfikację Gayle, to weź pod uwagę że ona dotyczy jakiegoś wczesnego prototypu i jest w wielu miejscach niepoprawna (choćby adresy są złe)! Choć akurat OVR działa generalnie tak jak tam napisano.
Btw. Ty nie jesteś przypadkiem gościem co napisał sterownik FastATA dla Linuxa?
Ostatnia aktualizacja: 21.08.2015 18:22:37 przez strim_
21.08.2015 18:25
[#9]
Re: Moja platforma badawcza z interfejsem SPI
@strim_, post #7
Racja - gdyby myśleć o przejściu z fazy prototypu do produkcji to w grę wchodzi wyłącznie trapdoor. Tam jest nawet więcej sygnałów niż teraz potrzebuję.
Problem jest oczywiście w samym złączu portu rozszerzenia. Rozumiem, że jest to jeden z droższych komponentów całej karty (przynajmniej według Jensa). Czy istnieje tańsza alternatywa?
Zauważ, że prototyp nie musi być ładny. Lepiej, żeby był tani - kanapka może zdać egzamin. Grunt, żebyśmy się zgodzili na jakiś standard - tj. które sygnały, w jaki sposób konwertujemy, do jakiej płytki FPGA podłączamy, etc.
FPGA (+ ew. rdzeń ARM) daje niezliczoną ilość możliwości - myślę, że innej opcji rozbudowy nie ma. Dobrze, żeby prace szły w jakimś kooperatywie.
Tak - to ja popełniłem sterownik do FastATA :P
Problem jest oczywiście w samym złączu portu rozszerzenia. Rozumiem, że jest to jeden z droższych komponentów całej karty (przynajmniej według Jensa). Czy istnieje tańsza alternatywa?
Zauważ, że prototyp nie musi być ładny. Lepiej, żeby był tani - kanapka może zdać egzamin. Grunt, żebyśmy się zgodzili na jakiś standard - tj. które sygnały, w jaki sposób konwertujemy, do jakiej płytki FPGA podłączamy, etc.
FPGA (+ ew. rdzeń ARM) daje niezliczoną ilość możliwości - myślę, że innej opcji rozbudowy nie ma. Dobrze, żeby prace szły w jakimś kooperatywie.
Tak - to ja popełniłem sterownik do FastATA :P
21.08.2015 18:35
[#10]
Re: Moja platforma badawcza z interfejsem SPI
@cahir, post #9
Założyłem osobny wątek aby nie zaśmiecać dyskusji o SPI na clockport.
Tutaj dyskusji na temat FPGA ciąg dalszy.
Tutaj dyskusji na temat FPGA ciąg dalszy.
25.08.2015 08:56
[#16]
Re: Moja platforma badawcza z interfejsem SPI
@spidi, post #15
Ale już teraz na filmie widać, że można wysyłać nieskompresowany PCM tzn. nie licząc opóźnienia da się wykorzystać tak jak zwykły codec audio do odtwarzania innych formatów w 16bit do 48kHz. Tylko szkoda, że nie ma AAC/MP4, bo 060 jest za słabe do odtwarzania. MP2 audio też by się przydało na przykład do odtwarzacza filmów AMP2.
30.08.2015 22:42
[#25]
Re: Moja platforma badawcza z interfejsem SPI
@] SKOLMAN_MWS ˇ agrEssOr [, post #23
Nie wiem, czy masz jakąś recesję kory mózgowej czy trollujesz, bo szczerze wątpię, że rozumiesz o czym piszę?
Do kontrolera SPI Spidiego podłączasz kartę SD, bo karta SD potrafi się komunikować po SPI i masz czytnik SD w cenie kontrolera SPI (dajmy komercyjnie 100zł?) i karty SD.
Za 70-100zł masz czytnik SD do Amigi i nie musisz kupować drogiego kontrolera USB na clockport, jeśli zależy ci tylko na przenoszeniu danych.
Do kontrolera SPI Spidiego podłączasz kartę SD, bo karta SD potrafi się komunikować po SPI i masz czytnik SD w cenie kontrolera SPI (dajmy komercyjnie 100zł?) i karty SD.
Za 70-100zł masz czytnik SD do Amigi i nie musisz kupować drogiego kontrolera USB na clockport, jeśli zależy ci tylko na przenoszeniu danych.
31.08.2015 01:17
[#27]
Re: Moja platforma badawcza z interfejsem SPI
@sanjyuubi, post #25
Dzięki za wyjaśniene, myślałem że na podstawie tej platformy Spidi będzie projektował nowe urządzenia z tym kontrolerem, a w takim układzie będzie można podłączyć taki tani dekoder audio link 
http://www.vlsi.fi/en/products/vs1053.html
http://www.vlsi.fi/en/products/vs1053.html
31.08.2015 13:50
[#29]
Re: Moja platforma badawcza z interfejsem SPI
@] SKOLMAN_MWS ˇ agrEssOr [, post #27
No generalnie tak, tylko sam dekoder ma zbyt mały bufor (2kB). Ja jak bawiłem się tym VLSem, to na 020 28MHz mogłem co najwyżej przesuwać ikony, bo każda mocniej obciążająca system operacja jak odświeżanie okna objawiała się przerwami w odtwarzaniu. Podejrzewam, że na 68000 samo poruszanie kursorem mogłoby mieś już na to wpływ.