www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Eure Meinung zum dsPIC


Autor: derHerr{LOL} (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
ich wollt mal ein paar Meinungen von euch über den dsPIC einholen.
Ich habe vor ein Audio spectrum anaylzer zu bauen, da kam mir dieser 
Microcontroller eigentlich recht passen vor.
Hat vlt. jemand schonmal den FFT Code von Microchip ausprobiert,
bzw lässt sich dieser problemlos benutzen???

Könnt ja mal was schreiben wenn ihr Lust habt!!!^^

Achso und sind die Controller immer noch verbuggt???

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst sie kaufen wenn sie ganz frisch sind. Denn mit den Jahren 
kommen immer mehr Bugs rein. Wenn man den Erratasheets glauben darf ;-).

Der 6013/A ist ein schönes Beispiel. Der war dermassen verbuggt, dass MC 
der nächsten grösseren Revision (immerhin - ist leider nicht typisch) 
eigens den eigenem Namen 6013A verpasst hat, damit man die in der 
Beschaffung auseinander halten kann. Anfangs war das Erratasheet vom 
6013A fast leer. Anfangs.

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andere uC/DSPs haben auch bugs, nur gibts kein erratasheet, oder es 
bleibt leer obwohl der hersteller von bugs weiss... da habe ich lieber 
einen ehrlichen hersteller wie Microchip, der auch workarounds 
vorschlägt ;-)
aber zu den dsPICs zurück: für audio sollten sie allemal geeignet sein.

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.

>Du musst sie kaufen wenn sie ganz frisch sind. Denn mit den Jahren
>kommen immer mehr Bugs rein. Wenn man den Erratasheets glauben darf ;-).

Der ist gut :)

Du sprichst jetzt aber von ds30, die nicht mit den neueren ds33 
identisch sind. Außerdem finden wir es doch lobenswert, dass Microchip 
mit neu entdeckten Bugs nicht hinterm Berg hält, oder?

@derHerr

>Moin,
>ich wollt mal ein paar Meinungen von euch über den dsPIC einholen.

Wie gesagt, den dsPIC gibt es nicht. Schau dir doch zunächst mal die 
Unterschiede der einzelnen Familien-Mitglieder an.

>Hat vlt. jemand schonmal den FFT Code von Microchip ausprobiert,
>bzw lässt sich dieser problemlos benutzen???

Nein, habe ich (noch) nicht. Bisher bin ich aber mit Microchip Libs und 
ANs immer gut zurecht gekommen.

>Achso und sind die Controller immer noch verbuggt???

Am besten erst mal ein paar Kandidaten auswählen und dann in die Errata 
schauen, alles Andere ist Sterndeuten.

Gruß,
Edson

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hat vlt. jemand schonmal den FFT Code von Microchip ausprobiert,
>bzw lässt sich dieser problemlos benutzen???
Ja, die DSP Libs sind super. PID, Filter, FFT.
Auch die Math lib ist nicht schlecht.
Auch die Spracherkennung ist 1A.

DsPic, die 30er können 5V, die 33 nicht !!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
derHerr{LOL} wrote:

> Hat vlt. jemand schonmal den FFT Code von Microchip ausprobiert,
> bzw lässt sich dieser problemlos benutzen???

Mittlerweile ja. Am Anfang hatten die da einen Bug drin, mittlerweile 
passts.
Der Code ist auch ziemlich schnell: Die FFT ist schneller als das 
berechnen der Sinuskurve als Testdaten (OK, FFT ist Festkomma und sin 
ist Fließkomma, aber trotzdem).

> Achso und sind die Controller immer noch verbuggt???

Die neueren sind OK. Die älteren haben durchaus einige Bugs, die man ab 
und zu mal umgehen muss, aber schlimmer finde ich die Softwarebugs die 
gelegentlich im Compiler bzw. den Header Files sind. Da sucht man 
stundenlang den Fehler, da eine Schnittstelle nicht geht, und findet am 
Ende raus, dass in der Header Datei vom µC zwei Werte in einem struct 
vertauscht sind. Sowas ist schon nervig, aber ich will nicht meckern, 
denn immerhin ist der Compiler in der Studentenversion kostenlos und die 
proprietäre Optimierung die Microchip dem gcc Compiler verpasst hat, ist 
nichtmal schlecht.

Die neueren dsPICs wie z.B. der dsPIC33FJ128GP802 sind echt schön:
Ein 40MIPS µC mit DSP Funktionen, 16bit Stereo DAC und 16kByte RAM in 
einem DIL28 Gehäuse ist schon etwas außergewöhnlich. Dazu kommt noch, 
dass man die ganzen Peripherifunktionen per Software auf beliebige Pins 
legen kann: Sowas vereinfacht das Platinenlayout extrem, und man muss 
nicht immer den nächstgrößeren mit mehr UARTs, Timern usw. nehmen, da 
z.B. UART und Timer beide den selben Pin verwenden, man aber beide 
benötigt.

Und vor allem: Obwohl die dsPICs sich geschwindigkeitsmäßig nicht weit 
hinter einem ARM7 befinden, lassen sie sich sehr viel leichter 
programmieren, da man die Register alle direkt ansprechen kann, und es 
nicht getrennte Register zum setzen/löschen/lesen gibt oder ähnliche 
Verrenkungen. Der Zugriff auf die Register ist daher auch sehr viel 
schneller.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meister Eder wrote:

> Du sprichst jetzt aber von ds30, die nicht mit den neueren ds33
> identisch sind.

Klar. Nur sind die in dieser Hinsicht nicht unbedingt viel besser. 
Jedenfalls nicht im Ax Silicon.

> Außerdem finden wir es doch lobenswert, dass Microchip
> mit neu entdeckten Bugs nicht hinterm Berg hält, oder?

Ja. Noch lieber wär's mir freilich, wenn sie die Dinger selber mal 
besser testen und dicksten Eier vorher beheben würden. Möglichst ohne 
ein altes handhabbares Problem durch 2 neue schwerer handhabbare zu 
ersetzen (wie bei PIC18F258 => 2580).

Das gilt aber für alle Hersteller, stimmt schon. Von den AVRs ist man da 
etwas verwöhnt.

Autor: derHerr{LOL} (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dankeschön für die Antworten!!

Ja ich denke mal ich werden es mit einem dsPIC probieren,
mal schauen ob ich da ein "schönes" Modell finde.
Da ich bisher nur mit 8Bit uControllern gearbeitet habe, hoffe ich mal 
das mir der Umstieg nicht allzu schwär fällt bzw. dass das ganze nicht 
in einem Debakel endet!!! hehe

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
derHerr{LOL} wrote:

> Da ich bisher nur mit 8Bit uControllern gearbeitet habe, hoffe ich mal
> das mir der Umstieg nicht allzu schwär fällt

Im Vergleich zum Umstieg auf einen ARM merkt man es kaum (außer an der 
Geschwindigkeit).
Das Portieren von C Code von AVR auf dsPIC ist auch kein großes Problem, 
man muss eigentlich nur die Peripherie + IO Pins anpassen.

PS: Um gleich mal eine gemeine Falle zu vermeiden: Schreib am Anfang von 
jedem Programm ADPCFG=0xFFFF; Ansonsten kann man die ADC Pins nicht als 
IOs verwenden. Und hier sollte man noch aufpassen, dass es bei den 
dsPICs mit mehrerern ADCs diese Register für jeden ADC gibt, und bei den 
dsPICs die mehr als 16 ADC Eingänge haben, gibt es jeweils ein High und 
Low Register.

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.