Förslag på MCU för snabbhet

[bos]

Jag ska ta emot en (digital) dataström på 500kbps som jag ska dekoda och utföra beräkningar (bland annat checksummor) på. När allt är klart ska datat skickas vidare via USB till en PC.

En PIC18 kanske eventuellt klarar av uppgiften, men jag tvivlar på det. Vissa PIC18 har dock inbyggd USB-modul, så en tanke uppstod att jag skulle kunna ha två kontrollers; en som dekodar och sen skyfflar till en PIC18 som skickar vidare via USB. Om det är praktiskt genomförbart vet jag inte, det var bara en tanke som ploppade upp när jag skrev det här inlägget.

Hur som helst, det jag egentligen undrar över är vilka MCU:er (inte FPGA eller liknande) det finns som kan ge mig ordentlig prestanda. Jag är ointresserad av features som ADC/DAC, komparatorer och liknande. Snabba beräkningar är viktigast, och ju mer RAM-minne desto bättre. 16kb RAM vore trevligt, men det är nog bara att drömma om antar jag.

Parallax SX sägs vara PIC på steroider, mer än så vet jag inte om vem. Vilka ytterligare controllers finns det som passar kriterierna ovan?

(Projektet ska inte volymproduceras, så om nån krets kostar $1 istället för $0.1 spelar ingen roll, men det spelar roll om den kostar $100 istället för $1)

[sodjan]

> en (digital) dataström på 500kbps

Det är rellativt mycket. Är det i "burst" eller kontinuerligt ?
Är det i USART format eller hur ska det "läsas" ?

> som jag ska dekoda och utföra beräkningar

Det beror ju väldigt mycket på vad "dekoda" och "utföra beräkningar"
betyder i verkligheten.

Vanliga 8-bitars PIC/AVR eller liknande kan du sannolikt glömma. Du
måste säkert upp i betydligt snabbare processorer. Kanske (om du vill
köra Microchip) någon PIC14 eller dsPIC (som har en del finessar
i DSP delen som kan komma till användning).

[Mindmapper]

AVR brukar vara snabbare än PIC.
Du kan se här.
http://www.obdev.at/products/vusb/index.html

Då får du kanske en aning om du kanske klarar det med en krets utan inbyggd usb.

ATxmega256A3 har 16kb sram, 32MIPS har jag för mig

http://www.atmel.com/dyn/products/produ ... xmega256A3

[sodjan]

Det helt avgörande är om 500 kbps strömmen kommer i burst eller
om det är kontinuerligt. Om det är kontinuerligt så tror jag ingen
vanlig 8-bitars AVR eller PIC fixar det inkl "dekoda och utföra
beräkningar" (vad nu *det* betyder) samt samtidigt köra USB
(speciellt inte med programvaru-USB!)...

Om det kommer i korta bursts så skulle man kunna ha en extern
buffring (någon slags FIFO) där 500 kbps strömmen lagras
och sedan läses ut av processorn i lagom takt.

Men något definitivt svar går naturligstvis ine att ge med så pass
dålig beskrivning av fallet som vi har just nu.

[bos]

Jag är osäker på vad termen burst innebär. Om det är 1MB data totalt, och det kommer 10kb åt gången till processorn, är det burst?

Isåfall är svaret ja. Datat är i 1MB-stycken som kommer att skickas 10-12kb i taget i 500ksps. Datat i fråga kommer ha 40-50% overhead. Steg 1 är att sålla bort overheaden. Steg 2 är att göra om det filtrerade resultatet till användbar data och här beräkna checksumma för att kolla att datat är okej. Steg 3 är att skicka över den användbara datan över USB till en PC.

Jag har antagligen missat att berätta något mer. Min ursäkt för det är att jag suttit med huvudet i böcker och datablad sen igår morse och har lite svårt att se vad som är uppenbart och inte. Påpeka gärna om jag glömt berätta något.

[sodjan]

"burst" = "skur".

Nja, jag tänkte mig kanske "skurar" med 10-20 bytes (100-200 bitar)
åt gången. Även 10 kb (kilobit eller byte?) är ju en ganska stor
datamängd för en vanlig 8-bitars AVR/PIC.

Men som sagt, en skriven specifikation över dataflödet behövs. Inklusive bl.a:
- timing (både på bit-nivå och övergripande)
- datavolymer
- dataformat (t.ex om det består av byte/tecken eller något annat format).
- innehåll
- vad är overhead och ska bort
- vad är riktig data och ska skickas vidare
- hur ska checksumman beräknas
- o.s.v, o.s.v.

Just nu har vi i väldigt lite att gå på...

[Stranne]

ARM Cortex? "Tefatet" är ju billigt och ger prestandamarginal. Snygg statusdisplay får du på köpet

http://www.electrokit.se/item_show.php?code_no=41002974

[Swech]

Låter mer som ett jobb för en ALTERA / XILINX FPGA av lite vassare modell
Dessa kan man få upp i bra fart, prisbilden är helt ok.
Har kört båda delarna och fastnat för ALTERA. Mest för att mjukvaran är klart
snabbare än XILINX.

Och så får du ju lära sig ett nytt område också

Swech

[chille]

Jag tror mer på en ARM, AVR32 eller liknande. Då kan du få ett enkelt devkit för någon hundralapp och de lär ha kraft nog att koda av data i 500kbps. Framförallt är det inte så begränsat med resurser, så det går att slafta ihop något i C/C++ utan att behöva optimera varenda instruktion.

[sdujolo2]

Kanske en PIC32?

[jbulow]

Kan varmt rekommendera den (UBW32). Extremt lätt att komma igång med. Dessutom kan den köra StickOS ( http://www.cpustick.com/ rakt av.

Edit:
Tog bort en citerning som citerade hela förra inlägget. //lgrfbs

[f.petrini]

XMOS XCore kanske?

XS1-G4 - Fyra kärnor med 8 trådar och 64kb per kärna.

Mycket trevlig processor med rejäl prestanda. En stor nackdel är dock att den i nuläget bara finns i BGA-kapsel vilket gör den svår att använda på egna kort. Dock snackar de om att ta fram breakout-kort m.m.

Jag använder deras XC-1 development kit och bygger runt det med egna kort som kopplas via headers.

[declint]

Om det bara rör sig om 500kbps dvs ca 63kbyte/s så bör ju vilken vanlig MCU som helst klara av beräkningar på simpla checksummor.

Beror givetvis på vad det är för checksumma som ska beräknas, men en checksumma är ju sällan en alltför cpu-krävande beräkning. Det är ju ofta poängen med de flesta checksum algoritmer.

Det är väll mera RAM minnet som klurigt om du måste buffra upp data innan det ska skickas vidare. Om du nu måste buffra all data?

Det blir ju mycket enklare att komma med en rekommendation på en lämplig MCU om du är lite mer specifik med vad som ska göras. Just nu är det ju som att försöka hjälpa dig att hitta en lämplig bil när den enda infon du kommit med är att du vill kunna åka till ICA.

[sodjan]

Nu var det varken "byte/sec" eller beräkningen av checksummor som
var problemet, utan 500 kb/s som kan vara lite svårt att hantera.

Däremot har du helt rätt i att det igentligen inte går att svara alls
p.g.a den väldigt bristfälliga informationen...

Och dessutom är nog det hela helt ointressant, den som frågade
verkar ha lämnat tråden helt, so why bother...

[declint]

Han har ju skrivit 500kbps, det är ju alltså ca 62.5kbyte/s. Dvs man får in 62500 byte data att titta på varje sekund (ev ännu lägre med paritet och stopbit)
Har man en vanlig MCU som klarar 20MIPS så har man kring 320 instruktioner per byte inkommande data att räkna med. Borde ju räcka, så hög är ju trots allt inte datatakten.