Hallo alle ! Ich wollt mal nach euren erfahrungen mit dem PIC 32 fragen ? MFG Patrick
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.
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.
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.
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 =)
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
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...
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.
@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.
Was hat es den mit dem PIN MAPING auf sich ? Besser gefragt was nervt dich daran ? MFG
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.
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
@Benedikt: Die Funktion
1 | 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
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-cores/mips32-m4k/ MFG
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ß
Stampede schrieb: > Die Funktion >
1 | SYSTEMConfig(GetSystemClock(), SYS_CFG_WAIT_STATES | |
2 | > 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.
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.
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
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.
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ß
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.
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.
>> 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.
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.
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.
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.
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.
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.
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.
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.
Eigentlich muss sich die Übertragungsrate proportional zum SPI-Takt verhalten, oder hat die Karte selbst einen Taktgeber (RC-Oszi?) ab Bord?
>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?
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.
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.
Ja, aber woher weiß der Controller in der Karte wie lange er warten muss? Hat er einen Zeitgeber außer dem SPI-Takt?
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.
> 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?IdcService=SS_GET_PAGE&nodeId=2602
@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
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
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.