uC-Plattformen, die für eine schnellere CPU und mehr als 30 GPIO-Pins in Betracht gezogen werden sollten

Ich baue ein Persistence of Vision -Projekt mit 120 RGB-LEDs (= 360 zu steuernde Gesamtlinien). Wir haben uns für den TLC5940 zum Ansteuern der LEDs entschieden (und könnten offen sein, dies zu ändern), aber jetzt haben wir ein Problem, die Daten schnell genug zu den LED-Treiberchips zu bringen. Derzeit verwenden wir Chips der ATmega328/ATmega128-Klasse, die bei 20 MHz enden, und wir sind nicht in der Lage, die auf die TLC5940s zu ladenden Daten schnell genug zu verarbeiten. Sollten wir einen anderen uC in Betracht ziehen? Die Wünsche sind:

  • Niedrige Kosten/uC
  • Niedrige Anlaufkosten (Zum Beispiel erfordern CPLDs eine gewisse Anfangsinvestition, um loszulegen)
  • 3,0-5,0 V
  • Idealerweise in einem DIP-Paket für einfaches Prototyping erhältlich
  • 30+ GPIO-Leitungen (um die LED-Controller parallel zu laden)

Diese Frage mag ein intellektuell schlechter Verwandter dieser Frage sein , aber ich denke, unsere Anforderungen sind etwas anders.

Details: warum ATmega328 (bisher) nicht schnell genug ist

In der idealen Welt sollten wir in der Lage sein, die Daten für alle LEDs in weniger als 746 uS zu laden (das sind die Projektanforderungen), und wiederum sollten wir theoretisch in der Lage sein, wenn wir mit 2 Takten/Bit bitbangen, in 108 uS @ 20 MHz , aber die ganze Bitverschiebung, um zu entscheiden, welche Intensität an jede LED gesendet werden soll, gibt uns jetzt Ladezeiten von 1536uS. Das geht mit avr-gcc OPTLEVEL=2oder OPTLEVEL=3, alle möglichen Schleifen manuell abrollen, paralleles Laden aller LED-Controller und jede erdenkliche zeitsparende Technik.

Warum klopfst du auf die Uhr? Verwenden Sie die integrierten SPI- oder USART-Module. Das sollte schnell genug sein.
Der Hauptgrund ist, dass ich mit Bitbanging bis zu 8 Datenleitungen (eine für jeden Treiber) an jedem Port anlegen und dann 8 Bits auf einmal laden kann, indem ich ihre Taktleitungen zusammen probiere. Dies ist am Ende schneller als das serielle Laden, denke ich. Auf jeden Fall ist es nicht so sehr das "Bits aus den Ports schieben", das die meiste Zeit in Anspruch nimmt, sondern zu entscheiden, welche Bits hier hinkommen sollen: viel Bit-Gedrehe, das eine Menge Zeit kostet. Vielleicht sollte ich den Code dafür posten?
In diesem Fall sollten Sie vielleicht deutlicher machen, dass Sie CPU-eingeschränkt sind, nicht IO-eingeschränkt. Daher ist "schnelles GPIO" nicht wirklich relevant, Sie benötigen in erster Linie mehr CPU-Leistung.
Ich glaube, Du hast recht. Betreff entsprechend geändert. Danke schön.
Vielleicht werfen Sie einen Blick auf den Parallax-Propeller , der auch in DIP für etwa 10 € pro Stück erhältlich ist.
Ja, das klingt vielversprechend. - Übrigens, programmierst du in C? Das Codieren von Teilen in Assembler kann die Leistung erheblich verbessern, insbesondere wenn es um bitweise Operationen geht, indem alle Flags im SREG voll ausgenutzt werden.
Ja, das schaue ich mir an.

Antworten (4)

Ich würde auf einen billigen ARM umsteigen. Sie können das Freedom Board bekommen , das ein Cortex-M0+ ist, das bis zu 48 MHz laufen kann. Da Sie auch ein Arm sind, erhalten Sie 32-Bit-Register, sodass Sie mehr pro Op-Code tun können. Außerdem verfügt es über eine DMA-Engine, sodass Sie möglicherweise das Laden der LEDs auf DMA auslagern können, während der Prozessor den Speicher aktualisiert. Sie können sie von Digikey sowie den anderen üblichen Verdächtigen erhalten.

Als Entwicklungstools gibt es CooCox , mbed und CodeWarrior .

Dieses Board unterstützt auch die mbed-Plattform, eine benutzerfreundliche Entwicklungsplattform mit Tools, Bibliotheken und einer großen Community, ähnlich wie Arduino. Damit können Sie im Handumdrehen loslegen. mbed.org/handbook/mbed-FRDM-KL25Z

Die Atmel XMEGA-Leitung hat eine Nennfrequenz von bis zu 32 MHz, ist ziemlich billig und wird in Gehäusen mit bis zu 100 Pins geliefert.

Sparkfun hat einen vorgefertigten Breakout für den xmega128A1 für das Prototyping: https://www.sparkfun.com/products/9546 – ​​es gibt auch eine Reihe von Entwicklungskits, darunter das XPLAIN-Board von Atmel.

Wir haben XMega in Betracht gezogen, da es jedoch weniger als die doppelte Taktrate von ATmega hat, schien es keine ideale Lösung zu sein, da wir die LEDs doppelt so schnell laden müssen.

Ich würde wahrscheinlich in die mbed- Plattform schauen. Möglicherweise können Sie eines ihrer DIP-Module als "uC DIP" verwenden, obwohl es auch die erforderlichen umgebenden Peripheriegeräte (Quarz, Stromversorgung usw.) enthält. Dies ist zwar erheblich teurer als der Kauf bloßer Mikrocontroller-Chips, aber es hört sich so an, als würden Sie dies nicht in Massen produzieren, sodass dies kein allzu großes Problem darstellen sollte.

Es gibt eine große Entwickler-Community und die Hardware kann definitiv Ihre I/O- und Geschwindigkeitsanforderungen erfüllen. Aufgrund der leicht zugänglichen Entwicklungswerkzeuge haben diese ziemlich komplexen Mikrocontroller immer noch fast keine Startzeit.

Arm, ja. Aber wahrscheinlich nicht eingebettet, da dies nur die paar Tage verzögert, die benötigt werden, um zu lernen, mit den nackten Teilen zu arbeiten - besser, das im Voraus aus dem Weg zu räumen und keine anstehenden Überraschungen zu haben. TQFPs sind ziemlich zugänglich.

Der PIC24EP256GP204 ist ein 16-Bit-Rechner, kann mit 70 MIPS laufen und hat 35 I/O-Leitungen. Leider ist es nicht in DIP verfügbar.

Es benötigt keinen externen Oszillator und ist ein 3,3-V-Gerät. Es kann mit kostengünstigen Programmierern wie PICkit3 (ca. 70 US-Dollar) In-Circuit-programmiert werden, verfügt über einen kostenlosen nicht optimierenden C-Compiler (XC16 - die Lizenzierung bringt Ihnen Optimierung) und zwei kostenlose IDEs mit Simulatoren (MPLAB 8 und MPLAB X) .

Ich habe die Erfahrung gemacht, dass die Arbeit in Assembler an diesem Teil nicht so schlecht ist - ich verwende die kostenlose Version des Compilers und optimiere in Assembler bei Bedarf von Hand.