Hi Ich bin gerade an einem Projekt in dem es um einen DSP basierten, batteriebetriebenen RFID reader geht. Einen Tag zu lesen dauert ungefähr 300ms. Die Elektronik soll das ganze möglichst genauso schnell auslesen und schnell auswerten das im Falle eines Fehlers zwei mal gelesen werden kann. Nun geht es darum den DSP auszuwählen. Dank dieser Website bin ich an den TI C5000 und den dSPIC hängen geblieben - letztere hab ich vorher schon gekannt. Nun kann ich mich nicht so richtig entscheiden. Der TI TMS320VC55x ist ein super Teil und mit sicherheit mehr als ausreichend. Vorteil: Er könnte es ermöglichen eine SD Karte anzuschliesen (ist bis jetzt nicht vorgesehen wäre aber nett wenn man das optional zur Verfügung hätte). Genial ist auch das er für Batteriebetrieb vorgesehen ist. Das Entwicklungstool ist mit 50$ auch erschwinglich. Nachteil: Er ist teuer. 14,40$ ist ein haufen Holz, besonders wenn man bedenkt das wir von eventuellen Stückzahlen von >1000 sprechen. Bei dSPIC kann ich mich nicht entscheiden. Die sehen alle recht ... kraftlos aus. Wobei Kraft in meinem Fall auch eher nebensächlich ist denke ich (fast jeder DSP wird genug Kraft haben um die Aufgabe zu bewältigen). Ich kann mich nur nicht entscheiden welcher davon am ehesten in Frage kommt.... kann mir da jemand helfen? Grüße
Hi, Gibt schon was so gut wie fertiges: http://www.analog.com/library/analogdialogue/archives/40-09/rfid.html Laeuft auf uClinux, allerdings wuerde ich aus verśchiedenen Gruenden (auch des Stromsparens wegen) den BF527 nehmen. Damit kann man gleich per USB auch noch die Daten ueber diverse Sticks verschicken (WLAN/Bluetooth) oder speichern. Gruss, - Strubi
Über welches RFID sprechen wir? 125kHz? Da reicht ein AVR8 denke ich.
135kHz. Die analoge Version braucht zum Auslesen im Moment "ein paar Sekunden" laut Bericht. In fertig soll es dann allerdings nicht (viel) länger dauern als der Tag Hersteller für seine Tags angibt: 300ms. Klar, gehen tut das bestimmt auch mit einem 8bit Mikroprozessor. Auftraggeber sagt aber: Okay wir haben digitale Filter drin, demodulation und so einen Käse mach das mal mit einem DSP. Ich hab den Link mal durchflogen, so wie ich das sehe gibt es Blackfin Prozessoren für RFID? Wenn ja schau ich mir den mal genauer an. Wie gesagt, wichtig ist - schnelle Signalverarbeitung - schnelle Demodulation (hab da schon was im Kopf aber das hat hier mit nur "indirekt" was zu tun) - günstig - Strom ist rar da wo das ganze in Einsatz kommt (bzw nicht vorhanden) sollte also auch Stromsparend sein. Man muss dann erorieren wie ein mehrpreis für den Proz im vergleich zu einer teureren Stromquelle aussieht ... Aber auch das gehört hier nicht her.
Blanvolet schrieb: > Die analoge Version braucht zum Auslesen im Moment "ein paar > Sekunden" laut Bericht. Was heißt "die analoge Version"?
Filter um Träger- und Nutzsignal zu Trennen (wird durch einen Mixer ersetzt) und dann ein Komparator ums in ein Rechtecksignal umzuwandeln - die Highzeit wird dann entsprechend gemessen. Das soll jetzt nach dem Mixer digitalisiert werden und gefiltert werden
Blanvolet schrieb: > Ich hab den Link mal durchflogen, so wie ich das sehe gibt es Blackfin > Prozessoren für RFID? Wenn ja schau ich mir den mal genauer an. Nicht als SoC, aber du brauchst ja nur noch den MxFE chip, der geht ohne Extralogik direkt an den PPI ran, Treiber sind auch schon da. Schlimmstenfalls muss noch ein Verstärker her. Allerdings sind die Blackfins (zumindest BF527) nicht mords-billig, aber da man mit uClinux eine Vielzahl an Referenzapplikationen gratis "mit dazu bekommt", ist die time to market sehr kurz, ergo kostensparend auf der Entwicklungsseite. Die paar Kroeten die man bei ein paar 1000 Geraeten sparen wuerde, rechnen sich im Vergleich damit nie. Kannst dich also bei der Loesung im grossen Ganzen auf die Entwicklung der DSP-Algorithmen konzentrieren. Gruss, - Strubi
Hallo, von den Blackfins würde ich die Finger lassen. Der JTAG-Programmer kostet allein 3000Euro. Was das Visual-DSP kostet weiß ich zwar nicht, aber ist bestimmt auch teuer. Auch ist mir bei Deiner Problemstellung nicht klar, warum ausgerechnet ein DSP genommen werden soll. Hier würde ich eine schnelle ARM für die Auswertung nehmen. Es geht hier doch gar nicht um Signalverarbeitung, sondern um die Auswertung von einem Protokoll, oder ? SD-Karten auslesen kann man auch mit jedem uC oder einer ARM. Und dann noch die der letzte Punkt: Energie sparen. Für eine Batterieapplikation sind die BFs respektive DSPs keine gute Wahl. Also auch hier würde ich zu einem ARM greifen. Gruß, H
Ein ARM (STM32) würde sicherlich mit einem guten ADC eine nguten Job tun - für 5$. Mein "Chef" will halt einen DSP haben. Ich hab die STM32 version aber notiert und werde sie vortragen - dann muss ich zwar mein Thema ändern aber egal :D die Blackfin sin mit sicherheit zu groß und tuer. Die C5000 sind eigentlich auch zu teuer... und die dSPICs sind mit 300mA max. nicht gerade Stromsparend ^^
Harald schrieb: > von den Blackfins würde ich die Finger lassen. Der JTAG-Programmer > kostet allein 3000Euro. Was das Visual-DSP kostet weiß ich zwar nicht, > aber ist bestimmt auch teuer. Das war mal vor 5 Jahren so. Inzwischen kostet die komplette Toolchain mit ICEbear JTAG keine 120 Euro mehr und ist - wenn man sowieso schon GNU spricht - mindestens so gut wie VDSP, wenn nicht besser, aber das ist oft auch Geschmackssache. ARM-Entwicklung kann im Prinzip aehnlich guenstig sein, wenn da nicht das Problem mit zig Derivaten und unterschiedlich gut dokumentierten/supporteten Toolchains waere. Was das Stromsparen angeht: Die neuen Blackfins sind mindestens so stromsparend wie aktuelle ARMs, teils sogar deutlich besser. Genau deswegen setzen wir den ja ein, das MIPS*Laufzeit-Produkt ist bei denen im Vergleich zu anderen DSP-Hybriden optimal.
Ja ich denke aber die Blackfin sind zu teuer - die C5000 schätzungsweiße auch... Deshaöb ja die Frage welchen dSPIC man nehmen könnte .D
Naja, bei der Hardware gilt meistens: You get what you pay for - solange du auch die versteckten Kosten (Tools/Lizenzen) im Auge behaeltst. Wie gesagt, was die eigentlichen Kosten reisst, ist ja die Entwicklungszeit. Wenn ich da mit einer stabilen uClinux-Loesung ein halbes Mannjahr EWK sparen kann, jucken mich 5 Dollar Unterschied bei 5000er-Stueckzahlen nicht mehr.. Gruss, - Strubi
Wobei Linux in dem Fall oversized wäre und meine kompetenzen dann übersteigt - ich hab halt noch nie Software für Linux geschrieben (ok is auch nur C Code) der dann wie normaler Code auf einem Mikrocontroller was steuert. Sollte in dem Fall aber auch übertrieben sein :D FreeRTOS auf dem STM32 wäre da Sinniger... Warum sollte die Entwicklung mit dem dSPIC hässlich/aufwändiger werden?
Also, ich bin natuerlich stillschweigend davon ausgegangen, dass du die eingelesenen RFID-Daten irgendwie mit einem Server abgleichen willst, ergo irgend einen Protokoll-Stack brauchst, wenn nicht sogar einen simplen SQL-Client. Wenn du natuerlich nur eine Zeichenkette per UART an einen Bluetooth-Adapter schickst, dann tut's natuerlich auch ein FreeTOS, oder du schreibst gleich alles "bare metal". Mir war der dsPIC halt damals bei der Entscheidung zu schmalbruestig, PIC hatte wegen der Tools generell schon schlechte Karten (JTAG buggy, usw.). Im Endeffekt finde ich, soll man das benutzen, wo man sich am besten auskennt, ergo am effektivsten debuggen und die Risiken am besten abschaetzen kann. Ich bin halt generell ein Fan von Code-Recycling bzw. bewaehrten "Lego-Bausteinen", auch wenn uClinux manchmal nach "Kanone auf Spatz" aussieht.
Die Geräte werden in einem Wald hängen. Nix Bluetooth, Server, SQL oder sonst was. Die eingelesenen Tags werden entweder on chip oder externer Speicher (ich schlage eine SD Karte mit einer *.csv datei vor) gespeichert. Dafür tuts mit sicherheit ein STM32 - die Aufgabe sieht aber eben eigentlich einen DSP vor. Das mit der Toolchain von PIC hab ich schon gelesen ... das hab ich auch notiert. Also ich denke entweder die Aufgabe umschreiben auf normalen µP (STM32) oder einen C5000 nehmen. PS: Wenn ich da bleibe wo ich bin muss ich Atmel nehmen :D
Blanvolet schrieb: > Klar, gehen tut das bestimmt auch mit einem 8bit Mikroprozessor. > Auftraggeber sagt aber: Okay wir haben digitale Filter drin, > demodulation und so einen Käse mach das mal mit einem DSP. Ich würde mich erst mal genauer erkundigen was das für ein Käse ist, statt einfach irgend einen DSP zu kaufen.
Hallo Blanvolet. ich arbeite seit einigen Monaten auf einer TI C2000 DSP Platform. Hat einen 60MHz 32bit core, ausreichend AD und Ports, auch für SD-Karte. Mit Flash und SRAM on board. Entwicklungswerkzeuge sind günstig (ca 50USD) und die Serienbausteine kosten etwa 2-3EUR. Platform ist einigermaßen skalierbar. Das Entwicklungswerkzeug ist für diese Platform frei erhältlich. Des weiteren: Batterie und DSP lässt sich aber m.E. schlecht vereinbaren. Ich mutmaße bei der Applikation "im Wald hängen" einen geforderten mehrtägigen Einsatz. Dann musst Du die einen intelligenten Sleep Mode überlegen denn die Prozessoren von denen ich hier gelesen habe dürften alle mehr als 100mA (= 300mW) benötigen, heißt bei 24h und 3V etwa 2500mAh (grob überschlagen). Das ist eine dicke fette Lithiumzelle pro Tag. Grüße
Dann schau ich mir den C2000 auch mal an. Und ja - Strom ist ein Problem und ein Sleepmode aus dem man schnell rauskommt muss her. Ich mach mir vor dem Sleepmode und dem Fall "Zwei Tags in Antenne" mehr sorgen als vor dem rest. Ich schlag jedenfalls noch Brennstoff- und Solarzelle als Stromversorgung vor. Ansonsten könnte das eng werden mit Strom, sleepmode hin oder her. Kann ja nicht angehen das man jeden Tag da hin muss um die Batterie zu kontrollieren ...
Nur so als Anmerkung, bei meinem Blackfin-System hab ich mal gemessen: - uClinux Vollast, mit Ethernet-Traffic (160 mA), Core clock 500 MHz, Sysclk 133 MHz - uClinux idle (Peripherie auf Standby): ~80mA Das ist das komplette Board (mit Kamerasensor und Phy), also nicht nur Prozessor. Deep Sleep habe ich noch gar nicht getestet. Im Standalone-Betrieb (ohne komplexes OS) kommt man mit reduzierten Clocks und ohne SDRAM-Betrieb auf ca. 45mA, Sleep Mode hab ich nur kurz mal getestet, da zieht wohl die Peripherie mehr als der Proz, kaum Aenderungen am Verbrauch, Unterschied von 3 mA (traf sich in etwa auch mit der theoretischen "power dissipation" bei 50MHz). Sind also riesige Unterschiede zu aelteren Architekturen, bei neuen Blackfins soll laut Datenblatt 90mW bei Vollast (400 MHz Coreclock) drinliegen. Weiss nicht mehr genau, wie's bei den TIs war, aber duerfte etwa ueberall dieselbe Strategie sein: PLL bypassen, in den IDLE state gehn, und die CPU so selten wie moeglich per RTC aufwecken, Aufwach-Bedingungen pollen und dann wieder ab in den IDLE. Der eigentliche Stromfresser duerfte wohl eher die A/D section sein, bzw. die Frage, wie schnell sich das Gesamtsystem aufwecken laesst, wenn ein Waldtier vorbeirennt (oder was taggt ihr da, wenn man fragen darf?) Gruesse, - Strubi
Ich tagge Fledermäuse :D Ich denke das ist ok wenn ich das sage. Hab da keine Klausel oder so unterschrieben. Ich bastel im laufe des Tages mal eine Tabelle wieviel Strom der Prozessor nach Tabelle wann verbraucht. So richtig abschätzen kann man das nicht, da geh ich einfach mal von best- und worst-case aus. Kann ja nur besser werden :D Ich denke aber halt das die Blackfins bei dem /1000 Preis zu teuer sind ... Und µLinux drauf laufen lassen, weiß nich. Ich glaub ein normales OS tuts da ganz gut. Nicht das ich was gegen Linux hätte, ich habs nur noch nie (auf einem µP) benutzt und ich hab keine Ahnung ob mir das Vor- oder Nachteile bringt. (Genauso muss ich noch eroieren ob mir ein Port für SD/MMC Karten Vor- oder Nachteile bringt). Ich denke weiterhin das ein ARM ala STM32 fast die beste wahl ist: Sehr "kräftig", sehr günstig, sehr gut erreichbar. Mal sehen was der Prof sagt
Sag doch gleich, dass es ein akademisches Projekt ist :-) Da duerfte die Zeit-ist-Geld-Rechnung und time-to-market einen etwas anderen Stellenwert haben.. Wuerde aber trotzdem mal schauen, wenn ich du waere, ein Pflichtenheft zusammenzubekommen, bevor du dich mit neuen Architekturen in unbekanntes Terrain vorwagst. Manchmal haben Profs diesbezueglich zu hohe Erwartungen... Gruesse, - Strubi
Das passt schon, ich hab hier als "deutscher Ingenieur" relativ freie Hand :D Also ich soll benutzen was ich möchte, Geld ist relativ wurscht ich kann jedes EVA Board haben das ich möchte :D Doch Blackfin? Nein! Ich denke im Moment ernsthaft über den C5000 nach. Er hat definitiv zuviel Power, aber das macht ihn eher noch attraktiver. Ich muss das ganze am Mittwoch dem Team vorstellen was ich denke. und ich werde speziell auf den C5000 hinweisen, der kann einfach alles was wir brauchen und noch mehr. Ich habe auch mal gerechnet: Angenommen wir nehmen eine 2500mAh NiMh Batterie. Angenommen der Prozessor läuft, wenn ein Tag zu lesen ist, 2sec lang auf 130mA. Dann kommen wir mit der Batterie auf ~34000 Zyklen oder 19h Dauerbetrieb. Wir rechnen im Moment damit das wir in einer Woche 20 Fledermäuse "fangen" können (was mir bei einer Population von ~10000 pro Höhle wenig vorkommt aber ich bin kein Fledermaus-Experte). Wie sich rausstellte wäre eine Brennstoffzelle perfekt, aber teuer. Ich werd mal schauen was ich so finde. Im Moment soll eine Auto Batterie benutzt werden - ich sag nur eins: Ich bin in den USA, die Batterie wird für gefühlte 2 Jahre dauerbetrieb reichen und die Winter hier wo ic hbin gehen auf -20°C bis -30°C :D Eine Frage an die dSPIC User: Was für Fehler weißt die Toolchain auf? Was berichtet eure Erfahrung darüber? Noch eine Frage: Gibt es Betriebssyteme für DSPs? Ich meine jetzt nicht Linux, sondern eher sowas wie FreeRTOS. We can't stop here, this' bat county! PS: Ich als Atmel Fanat und mehrjähriger User darf eigntl kein dSPIC nehmen :P Danke für eure Hilfe. Ein Pflichten/Lasten/Dingsbumsheft muss ich für meinen Bericht eh anfertigen. Genauso wie zwei Präsentationen, und eine hier in den USA. Ich freu mich -.-
Sorry für doppelpost: Gibt es günstige Eva Board für die Analog Shark? Die sind auch sehr nett
Blanvolet schrieb: > Noch eine Frage: Gibt es Betriebssyteme für DSPs? Ich meine jetzt nicht > Linux, sondern eher sowas wie FreeRTOS. Ich habe mir mal eCos und RTEMS angesehen. Bin aber im Endeffekt auch bei uClinux gelandet und benutze die Adeos-Realtime-Erweiterungen. Das Zeug lief auf Anhieb sehr stabil auf dem STAMP BF537. Der eCos-Port kam auch von einem RFID-Projekt (rfidguardian). Aber mal ganz ehrlich: Wenn Du ohne Vorkenntnisse betr. OS und Architektur loslegst, holst Du dir auf jeden Fall eine blutige Nase (so geschehen bei uns mit TMS320C5xx und 6xx, Code Composer fasst hier keiner mehr an). Deswegen mein dringender Rat: Wenn ihr wirtschaftlich arbeiten wollt, nehmt eine funktionierende Referenzlösung, die sich bewährt hat, gerade wenn es um ein Produkt geht, was nicht alle paar Wochen vor Ort debuggt werden muss.
Wie gesagt, ein Linux und einen Blackfin möchte ich nicht - da hol ich mir auf jeden Fall eine blutige Nase. Erfahrungen mit Programmieren und FreeRTOS hab ich. Falls das auch in Frage stand... Oder wolltest du sagen: Wenn man etwas noch nie gemacht hat sollte man es bleiben lassen ;)? Dann gäbe es keine Diplom, Master und Doktorarbeiten mehr ... Ich denke ich entscheide mich zwischen dSPIC, C5000 und Sharc. Bei letzterem ist die Frage obs ein günstigeres EVA Board gibt, den ganzen Audio Quatsch brauch ich ja nicht. Selbst stricken geht nicht, keine Zeit... Wo war das Problem bei eCos und RTEMS? Macht ein OS wie FreeRTOS (ich nehm an die ersten beiden sind sowas) sinn?
Moin, Ano Nym schrieb: > Wie gesagt, ein Linux und einen Blackfin möchte ich nicht - da hol ich > mir auf jeden Fall eine blutige Nase. Verstehe ich immer noch nicht. Warum solltest du dir mit einer Referenzloesung eine blutige Nase holen? Hoer dich doch mal in der Industrie um... eCos und RTEMS sind v.a. Realtime-Systeme und von der Treiber-Entwicklung aehnlich komplex wie uClinux, mit dem Unterschied, dass uClinux fuer fast alles Treiber-Frameworks bereitstellt. Bei eCos musst du mindestens aehnlich OS-Knowhow haben wie fuer Linux. Apropos: Wenn ich mich nicht taeusche, basiert die Firmware von www.rfidguardian.org auf einem eCos-Port fuer den BF548 (letzterer ist allerdings eine rechte Spatzenkanone). Wenn Ihr das Rad neuerfinden wollt: Das kann mal locker 1-2 Jahre dauern. Kein Problem, wenn man eine Doktorarbeit draus macht. Wenn aber schon die Zeit fuer ein eigenes Evalboard nicht da ist, sehe ich etwas schwarz - nimm's mir nicht uebel, aber ich habe schon so einige akademische Ansaetze scheitern bzw in chaotischem Gebastel (was im Endeffekt mehr kostet) enden sehen. Ist nicht immer ein Problem, aber man muss sich eben genau ueberlegen, ob man ein skalierbares industrietaugliches Produkt haben will, oder eine Lernplattform. Gruss, - Strubi
Ich denke das ich mir eine blutige Nase hole weil ich 0 Ahnung davon habe. Und ich finde einen C5000 (5515) völlig ausreichend ... außerdem gehen die Kosten ganz schön nach oben wenn wir einen Blackfin nehmen. Wir würde das denn dann laufen mit uCLinux? So wie bei FreeRTOS oder anders? Das Wort Linux erinnert mich immer bisschen an PC, hab noch nie ein Linux auf einem Chip laufen lassen. Und: Gibts auch was lauffähiges für die 5000er? Edit: Nein Edit: Ich schätze mal ich brauch zwingend ein Betriebssystem um gescheite parallelisierung hinzukriegen oder? Edit: Nach dem Video (http://www.youtube.com/watch?v=fKyQOntPEFs) denke ich das der Blackfin zu oversized ist. Und ich denke eh das Linux nichts ist wenn die Waldarbeiter oder Biologen das Teil in die Hand gedrückt bekommen und anschalten sollen ^^
@ Ano Nym (oorim) 1. Bei TI schimpft sich das Betriebssystem "DSP/BIOS". 2. Unter Linux kannst du mit Sicherheit auch so entwickeln, dass der Biologe/Waldarbeiter nichts von dem Linux mitbekommt. Bei nem DSL-Router oder nem SAT-Receiver siehst du ja auch nix davon.
Also das mit dem DSP/Bios 6.x klingt wirklich 1a. Ich denke dann bleib ich beim 5515. Ich denke mit dem und dem OS werde ich glücklich - wobei ich noch nich weiß wie blöd oder unblöd das OS is :D Ich bin mir zum derzeitigen Punkt noch nicht sicher ob ich ein OS brauch oder nicht. Ich denke aber, dass wenn ich das OS als Statemachine laufen lasse und den ablauf so Plane
1 | Signal Einlesen --> Demodulation inkl. FIR Filter --> Protokoll |
2 | |--> fertige Bytes parallel auf SD Karte speichern in *.csv |
das ganze ganz gut läuft (von der Performance her). Mal das OS morgen untersuchen. Danke fürs helfen :) Aufs Forum ist doch oft verlass.
Hallo nur mal so als Einwand Einige MSP430 haben integrierte OPV (zum Filtern) Comparatoren ADCund 32 Bit Hardware Multiplier und sind für Batterieanwendungen geradezu prädestiniert
Ich verstehe wirklich nicht warum da ein DSP verwendet werden muss. 135KHz das ist garantiert Lastmoduliert. Da musst Du doch nur runter mischen und mit einem Interrupt-Eingang mit-Triggern. Ich habe ein Projekt gesehen, da wurde mit einem Mega8 und einem SA612 ein Reader gebaut. Das Protokoll hatte einen Datenrate von 26Kbit. Das sollte wohl auch schneller sein als bei dem 135KHz-System. Da kannst Du sogar redundant parallel lesen. Zweimal lesen geht sowieso nicht. Prinzip-bedingt.
Es hätte aus akademischer und beruflich-zukunftstechnischer sicht eher Sinn gemacht einen FPGA zu nehmen. Ist immerhin das, mit dem der Signalverarbeitende Ingenieur in zukunft was zu tun haben wird. Ich denke mal es soll ein DSP verwendet werden weil die aktuelle Mikrocontroller Version langsam ist. Ich habe versucht den Prof zu überzeugen (es gibt zB einen Chip der quasi die ganze analoge Elektronik die im Moment benutzt wird ersetzt (ich weiß nur nicht ob der wirklich funktioniert oder nicht)) und das einzige was passiert ist, ist das jemand anders parallel an der Lösung arbeitet ... Ich werde mich nun stur an dem Festhalten was mir aufgetragen wurde, versuchen parallel oder wenn nach Lösung eins noch Zeit ist Lösung zwei durchzusetzen oder pro und kontra theoretisch auszuloten und das in meinem Bericht gegenüberstellen. Mein derzeitiger Plan ist nach dem Dioden Envelope Detector (wenn ich nicht was besseres finde, bin im Moment dabei mich schlau zu machen) einen ADC zu setzen und das Signal zu verwursten. Eventuell sync. ich noch mit zero crossing, weiß ich jetzt aber noch nicht. Wenn ich mir das allerdings so überlege finde ichs käse nach dem digitalisieren einen Software Schmitt-Trigger drüber laufen zu lassen um eindeutig 1 und 0 zu haben, das würds genauso analog tun ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.