> Do kontroli innych urządzeń , które są na pokładzie PCB dane mogą być w
> przestrzenie programowej. Ich ewentualna zmiana będzie następować tylko przy
> reprogramowaniu uC , np. przez SPI.

A jak często będziesz to reprogramować? Czy Flash wytrzyma? Moim zdaniem
lepszy byłby procek z zewnętrzną pamięcią programu, wtedy dajesz tam RAM
i tyle... No ale jeśli ma to służyć do zmiany programu 2x na dzień, to
flash pewnie wystarczy....

--
Pozdrawiam
Konop

do góry

On 16/05/2010 16:34, MH wrote:
> Witam ,
>
> Najpierw opiszę co projektuję. Jest to rodzaj karty pomiarowej z 32
> przetwornikami A/D (próbkowanie 50MHz/kanał) , dane z tych przetworników są
> zbierane i transmitowane poprzez PCI do peceta. Wstępna obróbka danych jest
> robiona na FPGA z pewnych względów. Pecet też ma kupę roboty : dalsza obróbka
> zawiadowanie transmisją i takie tam.. Jednocześnie muszę w tym samym czasie
> kontrolować pewne inne parametry innych układów , które są na pokładzie PCB.
> Wpadłem na pomysł wykorzystania jakiegoś uC , któremu mógłbym zmieniać dane do
> kontroli reszty , a więc musi być reprogramowalny w układzie, czas programowania
> rzędu 1-2s , i pamięć programu/danych>=512kB.

Jak masz FPGA na tej plytce PCI, to wsadz procka w VHDLu, doloz kostke
SDRAMu, a program do procka laduj przez driver z PCta. IMO najprosciej
(pod wzgledem hardware).

--
Jerry1111

do góry

32 kanały (8 bitów) * 50 MHz = 1,6 GB/s
Przepustowość najszybszej magistrali PCI: 533 MB/s, i to jest
magistrala 64-bitowa taktowana zegarem 66 MHz. Widział kto takie w
ogóle?

Serwery.

do góry

> W dniu 2010-05-16 22:25 Adam Dybkowski napisał(a):
>
> >> LPC: http://ics.nxp.com/products/mcus/parametric/?code=51
2~512
> >> SAM:
> >>
http://www.atmel.com/dyn/products/param_table_v2.asp
?family_id=605&OrderBy=part_no&Direction=ASC
> >
> > Oj chyba się z czasem programowania w 2s nie wyrobi.
> > Ja bym raczej poszedł w kierunku procka, który potrafi uruchamiać
> > program z pamięci RAM (czyli odpada większość LPC i SAMy). Wtedy czas
> > reprogramowania wyjdzie super szybko - a bootloader może program wciągać
> > choćby i z SPI.
>
> Oczywiście chodziło mi o zewnętrzny RAM. W środku jest za mało (a miało
> być min. 512KB AFAIR).
>
> --

Rozważałem takie roziązanie już wcześniej. Problem jest taki , że musiałbym
modyfkować zewnętrzny ram via FPGA i zaczyna mi trochę robić się za dużo I/O.
Jasne , można dać większy FPGA , ale to już zaczyna niebezpiecznie kosztować.

MH

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> MH wrote:
> > któremu mógłbym zmieniać dane do
> > kontroli reszty , a więc musi być reprogramowalny w układzie, czas programowania
> > rzędu 1-2s , i pamięć programu/danych>=512kB.
>
> Jestes pewien że musisz przeprogramowac całe 512kB za każdym razem bo
> oprogramowanie jest aż tak różne ? Może jednak chcesz mieć staly program
> i robić update jedynie parametrów bądź jakiś malych kawałków?

Dokładnie tak!! Problem w tym , że sam program jest bardzo mały , reszta to dane.

MH


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> On 16 Maj, 17:34, "MH" <l...@o...pl> wrote:
> > Witam ,
> >
> > Najpierw opiszę co projektuję. Jest to rodzaj karty pomiarowej z 32
> > przetwornikami A/D (próbkowanie 50MHz/kanał) , dane z tych przetworników są
> > zbierane i transmitowane poprzez PCI do peceta.
>
> 32 kanały (8 bitów) * 50 MHz = 1,6 GB/s
> Przepustowość najszybszej magistrali PCI: 533 MB/s, i to jest
> magistrala 64-bitowa taktowana zegarem 66 MHz. Widział kto takie w
> ogóle? Typowe mają 32 bity.

U mnie jest jeszcze gorzej !! 32 kanały (12 bitów) , co daje 2,4GB/s...
Stąd jak wcześniej napisałem wstępna obróbka jest wykonywana hardwarowo w FPGA ,
resztę robi pecet. Aż tak rąbnięty nie jestem , żeby popełnić tak sztubacki bląd..

MH


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> On 16/05/2010 16:34, MH wrote:
> > Witam ,
> >
> > Najpierw opiszę co projektuję. Jest to rodzaj karty pomiarowej z 32
> > przetwornikami A/D (próbkowanie 50MHz/kanał) , dane z tych przetworników są
> > zbierane i transmitowane poprzez PCI do peceta. Wstępna obróbka danych jest
> > robiona na FPGA z pewnych względów. Pecet też ma kupę roboty : dalsza obróbka
> > zawiadowanie transmisją i takie tam..  Jednocześnie muszę w tym samym czasie
> > kontrolować pewne inne parametry innych układów , które są na pokładzie PCB.
> > Wpadłem na pomysł wykorzystania jakiegoś uC , któremu mógłbym zmieniać dane do
> > kontroli reszty , a więc musi być reprogramowalny w układzie, czas programowania
> > rzędu 1-2s , i pamięć programu/danych>=512kB.
>
> Jak masz FPGA na tej plytce PCI, to wsadz procka w VHDLu, doloz kostke
> SDRAMu, a program do procka laduj przez driver z PCta. IMO najprosciej
> (pod wzgledem hardware).
>
> --

Zgadza się , tak jest najprościej , ale czy najpewniej?? Nie testowałem procków
z opencores więc nie wiem czy na pewno wszystko działa jak trzeba i ile logiki z
FPGA to pożera.. Jeżeli masz jakieś doświadczenie w tej kwestii , podziel się
swoimi uwagami..

MH


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On May 17, 11:13 pm, "MH" <l...@o...pl> wrote:
>
> U mnie jest jeszcze gorzej !!  32 kanały (12 bitów)  , co daje 2,4GB/s...
> Stąd jak wcześniej napisałem wstępna obróbka jest wykonywana hardwarowo w FPGA ,
> resztę robi pecet. Aż tak rąbnięty nie jestem , żeby popełnić tak sztubacki bląd..

Skoro juz tyle wepchnales w to FPGA to jakis algorytm kontrolny
zakodowany na sztywno tez sie tam zmiesci. Zwlaszcza, ze jak piszesz,
"program jest bardzo maly, reszta to dane".

JD

do góry

On 17/05/2010 15:19, MH wrote:
> Zgadza się , tak jest najprościej , ale czy najpewniej?? Nie testowałem procków
> z opencores więc nie wiem czy na pewno wszystko działa jak trzeba i ile logiki z
> FPGA to pożera.. Jeżeli masz jakieś doświadczenie w tej kwestii , podziel się
> swoimi uwagami..

Uzywam Altera Nios praktycznie wszedzie, gdzie maly PIC/AVR32 nie
wystarczy. Gdy nabierzesz nawyku wyrzucania wiekszosci zadan do logiki,
to procek glownie zajmuje sie transmisjami i obsluga menu ;-)

Jak dotad zero problemow. Fakt, nie jest to-to z Opencores...
Zajmuje w zaleznosci od wersji 1000-1500LE + peryferia. W Cyclone3
kompiluje sie na 80-110MHz (w zaleznosci ile peryferii mu napcham).
Plusem jest to ze nie ma licencji per-product jak w uCos/II, tylko
kupujesz Niosa raz i uzywasz do woli.

--
Jerry1111

do góry

W dniu 2010-05-17 16:03 MH napisał(a):

> http://www.atmel.com/dyn/products/param_table_v2.asp
?family_id=605&OrderBy=part_no&Direction=ASC
>>>
>>> Oj chyba się z czasem programowania w 2s nie wyrobi.
>>> Ja bym raczej poszedł w kierunku procka, który potrafi uruchamiać
>>> program z pamięci RAM (czyli odpada większość LPC i SAMy). Wtedy czas
>>> reprogramowania wyjdzie super szybko - a bootloader może program wciągać
>>> choćby i z SPI.
>>
>> Oczywiście chodziło mi o zewnętrzny RAM. W środku jest za mało (a miało
>> być min. 512KB AFAIR).

> Rozważałem takie roziązanie już wcześniej. Problem jest taki , że musiałbym
> modyfkować zewnętrzny ram via FPGA i zaczyna mi trochę robić się za dużo I/O.
> Jasne , można dać większy FPGA , ale to już zaczyna niebezpiecznie kosztować.

Ależ oczywiście nie podłączasz RAMu prosto do FPGA. Prockowi dajesz
reset i gadasz z jego bootloaderem (przez co lubisz - SPI, UART itp).
Procek sam wciska odebrane dane do RAMu. I teraz dwie wersje - albo
weźmiesz procka z Flashem, któremu dodatkowo można podczepić SRAM (i
wtedy dowolnie wymyślasz jego bootloader aby gadał z FPGA, może być
nawet magistralą 4 lub 8-bitową + stroby) - albo w drugiej wersji
bierzesz procka bez wewn. Flasha i korzystasz z możliwości bootloadera
ROM'owego.

Zresztą napisz gdzie właściwie chcesz trzymać n alternatywnych wsadów do
procka? Za każdym razem pobierane są z komputera gadającego z FPGA?

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry