mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP DSP für batteriebetriebenen RFID Reader


Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Gibt schon was so gut wie fertiges:

http://www.analog.com/library/analogdialogue/archi...

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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Über welches RFID sprechen wir? 125kHz? Da reicht ein AVR8 denke ich.

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blanvolet schrieb:
> Die analoge Version braucht zum Auslesen im Moment "ein paar
> Sekunden" laut Bericht.
Was heißt "die analoge Version"?

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ^^

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dig. Filter, demodulation, UI

Autor: Friedrich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Blanvolet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 -.-

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry für doppelpost: Gibt es günstige Eva Board für die Analog Shark? 
Die sind auch sehr nett

Autor: BoeserFisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 (Youtube-Video "Graphics (SDL, DirectFB & Qt) and Video on Blackfin Linux") 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 ^^

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Signal Einlesen --> Demodulation inkl. FIR Filter --> Protokoll
                                                          |--> 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.

Autor: Tobias Korrmann (kurzschluss81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist aber kein DSP richtig?

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.