Piotr Wyderski <b...@p...com> wrote:
> a...@m...uni.wroc.pl wrote:
>
> > Pisza ze na ARM chodzi Linux. No to masz 1000 powodow ze
> > cos sie moze przytkac.
>
> Ale to jest ich zadanie, by to wyja?ni?. W tym celu m.in. mo?e na ARMie
> przesta? chodzi? Linux.

OMAP3530 to raczej wymaga dosc skomlikowanego inicjowania, bez
gotowca (jak Linux) to sporo roboty.

> Praca skupia si? na przepustowo?ci po??czenia, wi?c rezultat inny ni?
> warto?? maksymalna przy tak elementarnym interfejsie ?wiadczy o
> niedba?o?ci lub niekompetencji.

Jak masz sporo warstw sofware to czesto wydajnosc jest nizsza
niz "teoretyczna". Nazwij jak chcesz, ale to fakt.

> > Ogolniej, to jest na poziomie (gorszych) notek aplikacyjnych
> > producentow. Nic odkrywczego, ale ludziom ktorzy tego wczesniej
> > nie robili moze sie przydac.
>
> Nawet ludzie, kt?rzy tego wcze?niej nie robili domy?laj? si?, ?e da si?
> po??czy? FPGA z MCU przez SPI. Zapewne chcieliby dowiedzie? si? jak si?
> robi np. SPI slave w Verilogu, ale z tej publikacji si? nie dowiedz?.

Autorzy twierdza ze pisali w VHDL...

> A szkoda, bo w tym problemie wyst?puje co najmniej jedno przekroczenie
> domeny zegarowej i trzeba to "umi?", z odpowiedni? dyskusj? konstrukcji
> synchronizatora dla czytelnik?w.

Moze jest naiwny (dla mnie na razie FPGA to teoria), ale synchronizacja
szyn to powinien byc prosty standartowy blok. Tak a propo,
przy zegarach z pracy synchronizatory przy pinach SPI bylyby
prostsze.

> W przeciwnym razie, jak to uj?? Kaczin,
> "interfejs nie b?dzie dzia?a? ze 100% skuteczno?ci?", bo im si? przy
> tych pr?dko?ciach metastabilno?? b?dzie pojawia? co kilka milisekund.
>
> Mam pewne przypuszczenia, ?e dok?adnie tu le?y inny ich problem:
>
> "Do?wiadczalnie osi?gni?t? maksymaln? cz?stotliwo?ci? transmisji danych
> jest 24 MHz, przy cz?stotliwo?ci 48 MHz wyst?puj? b??dy podczas
> transmisji spowodowane najprawdopodobniej nie najlepsz? jako?ci?
> elektrycznego po??czenia p?yt ARM i FPGA."
>
> Mo?e tak, mo?e nie -- nie pokazali kodu, to zostaj? tylko spekulacje.
> A spr?bowa?y szanowne doktory skr?ci? i zaekranowa? te kabelki?
>
> Dlatego warto?? edukacyjna tej pracy jest zerowa. Abstrakt tej pracy
> powinien brzmie? "Uda?o nam si? po??czy? FPGA z ARM przez SPI, ale
> dzia?a nam wolniej, ni? powinno. Nie spr?bowali?my wyja?ni?, dlaczego.
> Dzi?kujemy Ministerstwu Dziwnych Krok?w za sfinansowanie naszej zabawy."
>
> > Inna sprawa ze takie
> > publikacje nie powinni sie liczyc do "dorobku naukowego",
> > co najwyzej jako popularyzacje/rozpowszechnianie.
>
> No ale czego si? z niej dowiedzia?e?, Waldku? ?e si? da po??czy?
> procesor z FPGA za pomoc? SPI? No to da si? jeszcze UARTem, I2C, I3C i
> I2S. Bo jak, to si? nie dowiedzia?e?. Ja bym tego nie przyj?? jako
> sprawodzania z laboratorium, a tym panom to kto? opublikowa?.

Ze da sie polaczyc i uzyskac 2MiB na Linuxowym driverze. Ze calosc
wymaga minimalnej modyfikacji standartowych blokow FPGA i ze
zuzycie zasobow FPGA jest skromne. To sie moze wydawac oczywiste,
ale np. ludzie ktorzy zakladali ze na Raspberry Pi obsluza
klasyczne MIDI przekonali sie ze sa problemy.

> W tym ?wietle "Elektronika dla Wszystkich" jawi si? jako czasopismo z
> Listy Filadelfijskiej, bo tam si? trzeba podzieli? kodem z czytelnikami.
> Recenzent te? jest znacznie bardziej wymagaj?cy.

No, o ile wiem w EdW norma bylo wystawianie binarek bez zrodel.
Moze to sie zmienilo, ale piszemy o artykule z roku 2011.

--
Waldek Hebisch