mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC 32 Erfahrungsberichte


Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle !

Ich wollt mal nach euren erfahrungen mit dem PIC 32 fragen ?


MFG Patrick

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
arbeitet wirklich niemand von euch mit PIC 32 ?

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

Bewertung
0 lesenswert
nicht lesenswert
Kommt mir langsam auch so vor:
Beitrag "PIC24F und PIC32 als USB Host"
Das sind meine bisherigen Erfahrungen damit.

Auch google findet kaum etwas das nicht direkt von Microchip oder einem 
Distributor stammt.

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja das is mir auch aufgefallen

ich denke das liegt daran, dass microchip da in eine sparte sticht wo 
bereits ne menge andere drinnen sind.

ich wollte den pic32 auch verwenden, da ich aus der pic-schiene komme.

im endeffekt verzichte ich auf das bissi mehrleistung und bleibe beim 
pic24f, der ist flexibler, außerdem sagts der chef :D

der schritt vom pic32 zum ARM kaum vorhanden und dann geht man gleich 
besser auf eine bekanntere architektur.

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

Bewertung
0 lesenswert
nicht lesenswert
Michael H. schrieb:
> ja das is mir auch aufgefallen

Eventuell liegt es daran, dass die Controller noch relativ neu sind. 
Lange Zeit war es bei den dsPICs ähnlich, mittlerweile findet man 
etliche Projekte damit.

> der schritt vom pic32 zum ARM kaum vorhanden und dann geht man gleich
> besser auf eine bekanntere architektur.

Das könnte ein weiterer Grund sein.
Das einzige echte Argument das meiner Meinung nach für die PIC32 
spricht, ist die Pin und großteils C-Code und Peripherie Kompatibilität 
zu den dsPIC33, PIC24H und PIC24F. Daher kann jederzeit von den PIC24/33 
auf die PIC32 wechseln ohne die Hardware verändern zu müssen. Und 
natürlich die vielen Beispielprogramme von Microchip.

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann dir nichtmal bei Letzterem beipflichten.

Ich verwende eigentlich nur PIC24 und dort sehr gerne das PPS, somit 
ergibt sich nichtmal eine Pinkompatibilität.

Ich hoffe Microchip wird dieses Feature weiter in die Produkte einbauen, 
die kleinen PIC18FXXJXX können es auf einigen Pins bereits, das ist eine 
echte Erleichterung beim Routing.

Auch hats mir schon einmal den Hintern gerettet weil ich 2 SDI/SDO 
vertauscht hatte im Layout :) Einfach die Register anders setzen und 
danke.

Werde mich dennoch bald mit den PIC32 beschäftigen, Microchip ist sehr 
großzügig und hat mir ein paar Demoboards vermacht =)

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Released wurden die PIC 32 im Oktober 2008 wenn ich mich ned ganz irre. 
Also noch ganz grün hinter den Ohren ^^
Michael was muss man kaufen das man so "Sample Boards" bekommt ^^

MFG Patrick

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich beginne langsam mit den 24er PICs und bin begeistert: ressourcen 
fast zum aus spass zu verschwenden ;-) die 32er interessierten mich noch 
nicht, da ich die mehrleistung bis jetzt noch nie brauchte...

Autor: Stampede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze die PIC32 neuerdings. Die PIC24 hab ich mir allerdings 
gespart.
Der 32er ist echt flott, und ganz einfach in der Handhabung. Die vielen 
Beispiele (USB Device, Ethernet) funktionierend auch hervorragend und 
richtig flott. Bis auf das Pin Mapping habe ich noch nichts an den PIC32 
auszusetzen.

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

Bewertung
0 lesenswert
nicht lesenswert
@Stampede
Hast du zufällig mal gemessen wie schnell der USB Code in etwa bei dir 
ist? Ich erreiche mit dem Code von Microchip nur etwa 40kByte/s beim 
Lesen von einem USB Stick was mir sehr langsam vorkommt. Mit einem 
PIC24F sind es nämlich bereits über 100kByte/s.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hat es den mit dem PIN MAPING auf sich ? Besser gefragt was nervt 
dich daran ?

MFG

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sample boards kriegt man als hochschule zu günstigen konditionen bzw. 
ein paar gabs total gratis.

also keine zauberei, nur leider nicht für bastler.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja es wär vielleicht mal interessant so eine Art "PIC Stammtisch" ins 
leben zu rufen, um solche performance Probs in den griff zu bekommen. 
Aber auch vielleicht mal so wissen auszutauschen über was auch immer ^^
Sodale klingt etwas kitschig ^^


MFG Patrick

Autor: Stampede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:
Die Funktion
SYSTEMConfig(GetSystemClock(), SYS_CFG_WAIT_STATES | SYS_CFG_PCACHE);
rufst auf um die Kiste mit max. Performance laufen zu lassen?
Ich habe bisher nur den PIC32 als USB Device getestet, da sind je nach 
Massenspeicher (SD oder HDD) 300 bis 800kb/s drin.
Für Host ist mein Board zwar auch ausgelegt, getestet habe ich es aber 
noch nicht. Wie hast du die Übertragung denn gemessen?
Das Pin Mapping ist super, der PIC32 hat nur keins^^

Gruß
Stampede

Autor: seennoob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit PIN Mapping und PIC32 ist klar den es ist ja ein MIPS M4k Core. 
Ich würd agen das der leicht vergewaltig worden ist normalerweise ist 
der ausgelegt auf bis zu 400MHz !(bei 90nm)
Aber wird wohl noch 130nm Fertigung beim PIC 32 sein.

http://www.mips.com/products/processors/32-64-bit-...

MFG

Autor: Stampede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Patrick,

war eben auch auf der Seite und habe mir die Daten bzgl. max. Frequenz 
angesehen. Bis vor kurzem war da auch der 130nm Prozess angegeben, da 
lag die Fmax bei 100MHz wenn ich mich recht entsinne...
Ich will hoffen die nächsten PIC32 sind in dem neuen Prozess gefertigt!

Gruß

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

Bewertung
0 lesenswert
nicht lesenswert
Stampede schrieb:
> Die Funktion
>
SYSTEMConfig(GetSystemClock(), SYS_CFG_WAIT_STATES |
> SYS_CFG_PCACHE);
> rufst auf um die Kiste mit max. Performance laufen zu lassen?

Ja, ist leider drin.

> Ich habe bisher nur den PIC32 als USB Device getestet, da sind je nach
> Massenspeicher (SD oder HDD) 300 bis 800kb/s drin.

Sowas in der Richtung hatte ich auch erwartet. Hast du den Code von 
Microchip verwendet?

> Wie hast du die Übertragung denn gemessen?

Einen Timer gestartet, die Datei geöffnet, in 2kByte Blöcken gelesen und 
dann nachgeschaut wie weit der Timer ist. Auch die gefühlte Zeit bis die 
Messwerte über UART gesendet werden ist deutlich länger als auf dem 
PIC24, von daher gehe ich davon aus, dass die Werte passen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stampede schrieb:

> Ich will hoffen die nächsten PIC32 sind in dem neuen Prozess gefertigt!

Bevor dir der Mund zu wässrig wird: Was hast du von einem 400MHz Core, 
wenn jeder Flash-Zugriff 10 Takte braucht? Das Flash wird dadurch 
nämlich seinem Namen zum Trotz nicht wesentlich schneller.

Autor: Sebastian Hepp (sebihepp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm, also ich habe vor 2 Monaten mit einem PIC16 und einem PIC18
angefangen und möchte demnächst auch diese PIC32 ausprobieren.
Mir fehlt leider die Idee für ein schönes Projekt.

Weiss zufällig jemand, wie lange ein Cycle bei den PIC32 braucht?
Bis zu den PIC18 galt ja: 1 Cycle = 4 Takte. Damit konnte man
genau bestimmen, wie lange ein Assemblerprogramm braucht. Wie
ist das bei den PIC32?

Viele Grüße
Sebihepp

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

Bewertung
0 lesenswert
nicht lesenswert
Sebastian Hepp schrieb:

> Weiss zufällig jemand, wie lange ein Cycle bei den PIC32 braucht?

Bestenfalls 1 Takt. Genau vorhersagen ist etwas schwer da dieser einen 
Cache hat.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allerdings einen sehr kleinen. 256 Bytes.

Autor: Stampede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

@Prx:
Ja, der Flash ist ja schon im Moment der limitierende Faktor. Da hilft 
nur ein größerer Cache mit breiterer Anbindung (die ist z.Z 128Bit). 
Aber bei kleinerem Herstellungsporzess ist der Flash bestimmt auch 
schneller, aber das ist erst mal eine reine Vermutung. Mir würde sowas 
im Bereich mit 120MHz schon genügen.
Ein prinzipielles Problem der PIC32 gegenüber der PIC24 ist m.E. der 
Befehlssatz. Da die Register nur über das RAM bearbeitet werden können, 
dauert beispielsweise ein IO Zugriff auf einen Pin immer 3 Takte. Auch 
fehlen die mächtigen Sprungbefehle für Schleifen. Bei kleinen Schleifen, 
die oft durchlaufen werden, ist der Overhead bei den PIC24 bedeutend 
kleiner.

@Benedikt:

Ja ich verwende den Code von MC, aber wie gesagt nicht als Host sondern 
als Device. Habe auf meinem Starterkit mal den Host getestet, der war 
gefühlt nicht sonderlich schnell, aber genaue Zahlen habe ich nicht.
Was auch noch einen kleinen Boost brachte war die Umstellung auf 
interruptbasierte Abarbeitung des USB Stacks.

Gruß

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stampede schrieb:

> Mir würde sowas im Bereich mit 120MHz schon genügen.

Probier es aus. Einen 130nm STM32 hat jemand grad versehentlich 
problemlos mit 128MHz betrieben. Wird schon nicht der Deckel wegfliegen.

> Ein prinzipielles Problem der PIC32 gegenüber der PIC24 ist m.E. der
> Befehlssatz. Da die Register nur über das RAM bearbeitet werden können,
> dauert beispielsweise ein IO Zugriff auf einen Pin immer 3 Takte.

PIC32 entspricht dabei genau den ARMs. So ziemlich alle Cores, die nicht 
spezifisch für low-end Controller Anwendungen entwickelt wurden, haben 
keine spezielle Befehlssatzunterstützung für I/O-Ports.

Was hat das übrigens mit dem RAM zu tun? Sowohl in PIC24 als auch in 
PIC32 werden I/O-Ports über normale Speicherbefehle angesprochen. Der 
Unterschied liegt nur darin, dass die PIC24H im gleichen Takt Speicher 
lesen und wieder modifiziert zurückschreiben können. Was eine eher 
exotische Fähigkeit ist.

> Auch fehlen die mächtigen Sprungbefehle für Schleifen. Bei
> kleinen Schleifen, die oft durchlaufen werden, ist der Overhead
> bei den PIC24 bedeutend kleiner.

Die DO-Loop der dsPIC ist ziemlich frei von Overhead und in Assembler 
leicht verwendbar. Der Compiler verwendet sie jedoch m.W. nicht und die 
PIC24 kennen sie auch nicht.

Die REPEAT-Loop der PIC24 beschränkt sich auf einen einzigen Befehl. Das 
ist ganz nett, aber jenseits von Speicherblockoperationen und der 
Division (derentwegen er wohl überhaupt existiert) ist sie von 
begrenztem Nutzen.

Andererseits springen die PIC24 mit einem Takt Verzögerung. Der 
MIPS-Core, der diesen pipelinetypischen Delay-Slot naturgemäss auch hat, 
kann ihn produktiv für einen Befehl nutzen, PIC24 nicht.

Ich würde behaupten wollen, dass das Schleifenverhalten des MIPS Cores 
insgesamt effizienter ist.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Unterschied liegt nur darin, dass die PIC24H im gleichen Takt Speicher
> lesen und wieder modifiziert zurückschreiben können. Was eine eher
> exotische Fähigkeit ist.

PS: Und weshalb die I/O-Ports der PIC32 ähnlich wie viele ARMs spezielle 
Zugriffsregister besitzen, die dieses Modifikationen selbst durchführen, 
weshalb für Bitoperationen auch keine keine load-modify-store 
Operationen erforderlich sind, sondern einfache store Operationen 
ausreichen.

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

Bewertung
0 lesenswert
nicht lesenswert
>> Ein prinzipielles Problem der PIC32 gegenüber der PIC24 ist m.E. der
>> Befehlssatz. Da die Register nur über das RAM bearbeitet werden können,
>> dauert beispielsweise ein IO Zugriff auf einen Pin immer 3 Takte.
> Der
> Unterschied liegt nur darin, dass die PIC24H im gleichen Takt Speicher
> lesen und wieder modifiziert zurückschreiben können. Was eine eher
> exotische Fähigkeit ist.
>
>> Auch fehlen die mächtigen Sprungbefehle für Schleifen. Bei
>> kleinen Schleifen, die oft durchlaufen werden, ist der Overhead
>> bei den PIC24 bedeutend kleiner.
> Ich würde behaupten wollen, dass das Schleifenverhalten des MIPS Cores
> insgesamt effizienter ist.

Von daher würde mich mal interessieren, wie schnell ein PIC32 mit 80MHz 
im Vergleich zu einem PIC24/dsPIC33 mit 40MHz wirklich ist. Aus 
offiziellen Quellen wird man wohl eher rechenintensive Benchmarks 
bekommen, wo der PIC32 klar deutlich besser abschneidet.
Mich würden daher die Geschwindigkeit bei typischen Aufgaben 
interessieren, die praxisnäher sind wie z.B. einem Webserver der per 
8/16 bit Bus an die IO Ports angebunden ist, und dessen Daten sich z.B. 
auf einer SD Karte befinden, nur um mal etwas Peripherie mit ins Spiel 
zu bringen.
Meine Vermutung ist, dass das der Geschwindigkeitsvorteil des PIC32 
relativ schnell zusammensackt, so dass effektiv nicht mehr allzu viel 
Unterschied zu den PIC24/dsPIC33 übrig bleiben wird.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dem TCP/IP dürfte eine 32-Bit Architektur durchaus zupass kommen und SPI 
mit DMA hat PIC32MX ebenso. Wenn dann die SD-Karte oder ein per externem 
Bus angebundenes Peripherieteil ihn ausbremst kann der Core wohl kaum 
was dafür.

Aber das Beispiel hinkt insofern, dass für einen Webserver ein 
vorhandenes Ethernet-Interface einigermassen nützlich sein dürfte. Wenn 
man also darauf abzielt, dann sollte man gleich in die richtige Richtung 
gehen und einen entsprechenden Controller aussuchen.

Darin liegt dann auch der Haken an PIC32: Bei ARM kann man mit dem 
gleichen Entwicklungswerkzeug die Familien verschiedener Hersteller mit 
ihren jeweiligen spezifischen Vorteilen verwenden, z.B. LM3 oder LPC2000 
mit Ethernet. Beim PIC32 ist man weniger flexibel.

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

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> und SPI mit DMA hat PIC32MX ebenso.

Offtopic: Wie setzt man DMA eigentlich bei sowas sinnvoll ein? DMA ist 
vor allem sinnvoll, da man damit im Hintergrund Daten übertragen kann, 
während der Prozessor an etwas anderem arbeitet. Dummerweise sind nahezu 
alle Dateisystemroutinen die man findet so aufgebaut, dass diese Daten 
dann anfordern wenn diese gebraucht werden. Also selbst wenn man DMA 
verwendet, dann wartet die CPU bis die Daten der DMA Transfer fertig 
ist.

> Wenn dann die SD-Karte oder ein per externem
> Bus angebundenes Peripherieteil ihn ausbremst kann der Core wohl kaum
> was dafür.

Naja, der schnellste Kern nützt nichts wenn die Peripherie außenrum lahm 
ist. Das ist der Punkt auf den ich hinauswollte: Zu einem µC gehört mehr 
als nur die CPU und ein µC greift eben nunmal recht häufig auf diese zu.
Daher sollte diese in einem realistischen Geschwindigkeitsvergleich auch 
berücksichtigt werden.

Mit einem PIC24H übertrage ich z.B. über einen 16bit breiten Bus der 
durch normale IO Pins gebildet wird, mit rund 10MByte/s Datenrate.
Das ist ein Grund wieso ich mich u.a. für die PIC24 entschieden habe 
ist, denn mit diesen kann ich aufgrund der schnellen IOs notfalls 
einfach mal ein Businterface in Software machen, und es ist dennoch 
ausreichend schnell. Die größte Bremse dabei ist nichtmal der µC selbst, 
sondern die minimalen Impulsbreiten des Angesteuerten.
Ich steuere z.B. öfters Displays damit an. Viele der größeren 
Displaycontroller besitzen einen Wait\ Pin der den Buszyklus verlängert, 
da der Speicher im Displaycontroller abwechselnd beschrieben und gelesen 
wird. Es gibt nämlich kaum schnelle µC die ein Businterface besitzen die 
dieses Feature bieten, bzw. wenn doch dann sind das entweder 
ausgewachsene CPUs, oder Controller zu denen man unter ein paar k€ keine 
Entwicklungsumgebung bekommt. Mit einem PIC24 mache ich das ganze eben 
mal schnell in Software.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. schrieb:

> Also selbst wenn man DMA
> verwendet, dann wartet die CPU bis die Daten der DMA Transfer fertig
> ist.

Wenn man an zwei Stellen Massentransfers abwickelt, also sowohl beim 
Ethernet als auch bei der SD-Karte, dann ist DMA sinnvoller als 
CPU-Power. Denn mit DMA geht das gleichzeitig.

Bei der Flashkarte kommt hinzu, dass es recht verschiedene 
Peripheriemodule dafür gibt:
- SPI ohne jeden Puffer (AVR),
- SPI mit einfacher Puffer (viele, z.B. Microchip, STM32),
- SPI mit tiefem Puffer (auch schon irgendwo gesehen),
- 4-Bit SD/MMC-Card Interface (manche NXP und STM32).

> Naja, der schnellste Kern nützt nichts wenn die Peripherie außenrum lahm
> ist. Das ist der Punkt auf den ich hinauswollte: Zu einem µC gehört mehr
> als nur die CPU und ein µC greift eben nunmal recht häufig auf diese zu.

Völlig richtig. Und keine Frage, für Pingewackel ist angesichts des 
zudem geringeren Aufwands grad bei kleineren Lösungen PIC24H ziemlich 
effektiv. Der Propeller ist da zwar auch nicht übel, aber die 
Programmierung ist etwas krude.

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

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. schrieb:
> A. K. schrieb:
>> und SPI mit DMA hat PIC32MX ebenso.
>
> Offtopic: Wie setzt man DMA eigentlich bei sowas sinnvoll ein? DMA ist
> vor allem sinnvoll, da man damit im Hintergrund Daten übertragen kann,
> während der Prozessor an etwas anderem arbeitet. Dummerweise sind nahezu
> alle Dateisystemroutinen die man findet so aufgebaut, dass diese Daten
> dann anfordern wenn diese gebraucht werden. Also selbst wenn man DMA
> verwendet, dann wartet die CPU bis die Daten der DMA Transfer fertig
> ist.

Wenn du ein Betriebssystem hast kannst du nach dem Anstoßen des 
DMA-Transfers einen Kontextwechsel veranlassen und den Task bei 
Beendigung des Transfers per Interrupt wieder aufwecken. Die 
Zwischenzeit kann ein anderer Task nutzen, oder der Prozessor legt sich 
schlafen und spart Strom. Was auch vorkommen kann ist dass die CPU bei 
einer schnellen Übertragung der begrenzende Faktor ist, und man es ohne 
DMA gar nicht schaffen würde die Daten schnell genug abzuholen und zu 
speichern.

Autor: Stampede (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

um noch mal kurz auf die Architektur PIC24 / PIC32 zurückzukommen:
Ja, der PIC24 hat do/repeat Befehle, der PIC32 hat diese nicht. Man muss 
also einen Schleifenzähler immer explizit mit hochzählen und dann bei 
der Bedingung springen. Ausserdem gibt es soweit ich weiß keine PostInc 
/ PostDec Befehle um Zeiger zu verändern, da fällt dann noch ein 
weiterer Befehl an.
Besonder kommt das zu tragen, wenn man kurz Schleifen hat mit hoher 
Iterationzahl. Wenn die Schleifen dann aber gerade etwas länger als der 
Cache sind, wird nochmal langsamer.
Ein Kollege und ich hatten mal folgendes getestet:
Ich PIC32@80MHz , er PIC24 @ 16MIPS, Anstuerung einer SD Karte mit 20MHz 
beim PIC32, 8MHz beim PIC24. Es musste zum Lesen eines Sektors 512 Byte 
aus der SPI über einen Zeiger in ein Array geschrieben werden.
Bei Verwendung der gleichen USB Stack war der PIC32 nur minimal 
schneller 300kb/s vs. 330kb/s. Eine weitere Analyse brachte hervor, dass 
der PIC32 die meiste Zeit in der Leseschleife verbracht hat. Daher ist 
das Schleifenverhalten des MIPS definitiv schlechter.

DMA konnte ich leider noch nicht testen, allderings weiß ich auch noch 
nicht genau wo ich es anwenden will. Bei SPI entsteht glaube ich der 
größte Vorteil, ggf. bei Beschreiben des PMP über DMA (wobei es hier 
einen Bug gibt).
Das PMP Modul ist hingegen eine wirklich feine Sache. Ich steuere damit 
einen Epson S1D13748 (funktioniert jetzt fast Benedikt), und ich kann 
ohne Verzögerungen mit vollem Takt übertragen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hat die Leseroutine der SD-Karte mit USB zu tun? Und wenn eine per 
SPI betriebene SD-Karte bei 8MHz und 20MHz Taktrate die praktisch 
gleiche Transferrate von um die 300KB/s zeigt, dann ist bei nicht völlig 
schnarchlangsamen Cores naheliegernderweise weder SPI noch Core sondern 
die Karte der begrenzende Faktor.

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

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Und wenn eine per
> SPI betriebene SD-Karte bei 8MHz und 20MHz Taktrate die praktisch
> gleiche Transferrate von um die 300KB/s zeigt, dann ist bei nicht völlig
> schnarchlangsamen Cores naheliegernderweise weder SPI noch Core sondern
> die Karte der begrenzende Faktor.

Würde ich nicht sagen. Meiner Erfahrung nach ist die Datenrate ziemlich 
proportional dem SPI Takt. Mit anderen Worten: Die Zugriffszeit beim 
Lesen einer SD Karte sind meist vernachlässigbar.
Ein dsPIC33 mit den ELM Chan Dateisystemroutinen und mit einem auf 20MHz 
übertakteten SPI Interface kommt bei mir auf fast 900kByte/s beim Lesen.
Mit nur 10MHz SPI Takt sind es um die 550kByte/s, also etwas mehr als 
die Hälfte.

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

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich muss sich die Übertragungsrate proportional zum SPI-Takt 
verhalten, oder hat die Karte selbst einen Taktgeber (RC-Oszi?) ab Bord?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich steuere damit
>einen Epson S1D13748 (funktioniert jetzt fast Benedikt), und ich kann
>ohne Verzögerungen mit vollem Takt übertragen.

@Stampede
Was kosten diese Teile in kleinen Stückzahlen und welcher Distributor 
empfiehlt sich dafür?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. schrieb:

> Würde ich nicht sagen. Meiner Erfahrung nach ist die Datenrate ziemlich
> proportional dem SPI Takt.

Wenn die Karte das hergibt. Er schreibt nicht was für eine das war, und 
was beispielsweise beim Lesen via PC rauskommt.

Was war denn die Aussage:
- PIC24/16MIPS mit 8MHz SPI liest mit 300KB/s.
- PIC32/80MIPS mit 20MHz SPI liest mit 330KB/s.

Und daraus wird dann der Schluss gezogen, dass die Schleifenoperationen 
eines PIC32 eine höhere Performance verhindern.

Sorry, aber das ist Bullshit. Das sind 240 Zyklen pro Byte beim PIC32
und 50 Zyklen pro Byte beim PIC24. Um das auf die Schleife 
zurückzuführen müsste ein einzelner Bytetransport beim PIC32 fast 200 
Zyklen langsamer sein als beim PIC24.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:

> Eigentlich muss sich die Übertragungsrate proportional zum SPI-Takt
> verhalten, oder hat die Karte selbst einen Taktgeber (RC-Oszi?) ab Bord?

Ich habe mir das Protokoll von SDs nicht angesehen. Ist dort wirklich
definiert, dass jeder Block verzögerungsfrei gelesen werden kann? Oder
ist nicht vielmehr so, dass wie bei allen anderen mir bekannten
Massenspeicheren nach dem Lesekommando erst einmal abgewartet werden
muss, bis der Block zur Übertragung zur Verfügung steht?

Innerhin gibt es bei SDs wie auch SDHCs seitens des PC durchaus nicht
nur unterschiedliche Schreib- sondern auch unterschiedliche Leseraten.

Mein Verdacht im beschriebenen Fall ist, dass dieses Warten auf den
Block einen wesentlichen Teil der Gesamtzeit ausmacht.

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

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber woher weiß der Controller in der Karte wie lange er warten 
muss? Hat er einen Zeitgeber außer dem SPI-Takt?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar hat er. Denn das ist doch der gleiche Controller, der auch für die 
Schreiboperationen ins Flash zuständig ist. Was ziemlich komplex werden 
kann, denn erstens sind die Flash-Blöcke viel grösser als die 
Transferblöcke (r-m-w nötig), zweitens führen solche Controller ein wear 
levelling durch. Das alles mit einem SPI-Takt, der ausserhalb der 
Transferoperationen überhaupt nicht anliegt?

Nope, auch ohne das SD-Protokoll zu kennen ist klar, dass der Controller 
auf der Karte autark taktet und der SPI-Takt nur die Übertragung selbst 
steuert.

Autor: Patty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> arbeitet wirklich niemand von euch mit PIC 32 ?

Hier findest Du eine Übersicht, wer so alles Support für den PIC32 
leistet:

http://www.microchip.com/stellent/idcplg?IdcServic...

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:

"Mit einem PIC24H übertrage ich z.B. über einen 16bit breiten Bus der
durch normale IO Pins gebildet wird, mit rund 10MByte/s Datenrate.
Das ist ein Grund wieso ich mich u.a. für die PIC24 entschieden habe
ist, denn mit diesen kann ich aufgrund der schnellen IOs notfalls
einfach mal ein Businterface in Software machen, und es ist dennoch
ausreichend schnell. Die größte Bremse dabei ist nichtmal der µC selbst,
sondern die minimalen Impulsbreiten des Angesteuerten."

Laut PIC32 Datasheet lassen sich die IOs auch bis zu 80Mhz togglen, was 
du dann mit nem 16 bit breiten SW-emulierten Bus machst, ist ganz dir 
überlassen.
Also sollte in dieser Hinsicht ein PIC32 mehr als ebenbürtig sein.

Gruß Hannes

Autor: Dimitri M. (dimitri)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ihr redet hier von lahmen 300kB/s Schreiben auf eine SD-Karte. Ich komme 
auf 2.5MB/s mit SPI DMA und Multiple Block Write bei PIC24HJ128GP204.

Man soll bedenken, dass man zwischen den einzelnen Bytes enorm viel Zeit 
verschwendet, wenn man SPI entweder per Interrupt oder in der 
Polling-Schlaufe füttert.

Übrigens, der 2. DMA-Channel übernimmt das Einlesen von SPIBUF. Auch so 
eine lästige aber unverzichbare Sache. Es gibt Null-Byte-Write aber kein 
Null-Byte-Read => SPIBUF will geleert sein.

PIC32 bietet im Vergleich zu PIC24, dsPIC33 auch DMA-Transfers 
memory-to-memory. Bei PIC24 ist kein DMA mit PMP möglich. Auch der 
DMA-Speicherbereich scheint nun nicht mehr auf 2kB begrenzt zu sein wie 
bei 16-Bitern. Ich kann mich aber überlesen haben.

Gruss
Dimitri

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.