Jaki uC proponujecie ??

May 16, 2010 37 Replies

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


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.

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

MH pisze:

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

formatting link
formatting link
formatting link

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

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.

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

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?

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

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.

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

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

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.

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

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

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

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

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.

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?

Je¶li ju¿ bêdziesz mia³ FPGA to czemu nie dasz wiêkszego i nie wsadzisz procka do ¶rodka? Altera robi fajne FPGA serii Cyclone (dzi¶ ju¿ seria III) i do nich mo¿na wsadziæ 32-bitowy procek Nios2. Wiêksze kostki FPGA maj± sporo pamiêci ram w ¶rodku. Kod mog± ³adowaæ z taniej pamiêci CFI.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required