Jaki uC proponujecie ??

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.

Jakoś nic mi się nie udało wyguglać.. Jak coś macie , proszę o link.

Pozdrawiam ,

MH

Reply to
MH
Loading thread data ...

MH pisze:

Mógłbyś się zdecydować, czy ten uC ma mieć pamięć programu, czy danych >= 512kB. O ile z pamięcią programu nie będzie problemu, to tak duży RAM będziesz musiał dołożyć na zewnątrz. Nie podałeś żadnych wymagań co do prędkości, ilości linii I/O, A/D, interfejsów komunikacyjnych, magistral itp.

Reply to
Zbych

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.

Prędkość "byle jaka" , nawet 1MHz wystarczy. A/D nieistotne. Interfejs do reprogramowania np. SPI , 16-24 lini I/O powinno wystarczyć.

Pozdrawiam ,

MH

Reply to
MH

MH pisze:

No to wybór masz duży. STM32:

formatting link
formatting link
formatting link

Reply to
Zbych

formatting link
LPC:
formatting link
SAM:

formatting link

Jutro to przetrawię. Jeżeli będę miał pytania , pozwolę sobie pozawracać głowę jeszcze raz.. Tak czy inaczej , dzięki !!

MH

Reply to
MH

W dniu 2010-05-16 20:08 Zbych napisał(a):

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.

Reply to
Adam Dybkowski

W dniu 2010-05-16 22:25 Adam Dybkowski napisał(a):

Oczywiście chodziło mi o zewnętrzny RAM. W środku jest za mało (a miało być min. 512KB AFAIR).

Reply to
Adam Dybkowski

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?

Reply to
Sebastian Biały

Pewnie to wziales pod uwage ale pozwole sobie napisac ze rok ma jakies

31mln sekund, co w powiazaniu z (z glowy pisze) stu tysiacami programowan, daje jakies 310 sekund. Te 310 sekund to czas co ile reprogramowujac uklad ubije mu flash w rok. Ale pewnie sam scalak bedzie mial staly bootloader a program bedzie w ram...
Reply to
ptoki

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.
Reply to
shg

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....

Reply to
Konop

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).

Reply to
Jerry1111

formatting link
>

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

Reply to
MH

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

MH

Reply to
MH

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

Reply to
MH

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

Reply to
MH

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.

Reply to
Jerry1111

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

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?

Reply to
Adam Dybkowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.