Hallo, steht grad vor der Überlegung welchen ARM Controller ich einsetzen soll: AT91SAM7S64 oder STR911FAM (benötigen tue ich USB 2.0 Full-Speed, Flash und RAM sollte im Controller bereits implementiert sein, SPI, I2C, RS232)... Welcher von den beiden Controllern ist eurer Meinung besser (schneller)? Gruß Herbert
Zur Anwendung: ich hab drei TLC5912 LED Treiber über SPI, einen Encoder und drei Taster sowie einen SPI-Touch-Controller angeschlossen: sämtliche Daten müssen ausgewertet werden im ARM und das Ergebnis via USB an einen PC gesendet werden. Reicht hier die Performance der beiden Controller aus? Im Prinzip müssten wahrscheinlich alle Eingabe-Elemente jede 1ms abgefragt werden, um ein optimales Ergebnis zu erhalten... Gruß Herbert
Der STR9 hat exakt einen Vorteil: Es gbt ihn mit bis zu 2MB Flash. Von der Performance sollte man aber nicht allezu viel erwarten, seine 96MHz sind aufgrund des langsamen Flash-Zugriffs auf Daten nicht unbedingt viel mehr als die 55MHz des SAM7. Wenn Performance ein wesentliches Thema ist, dann orientiere dich lieber an LPC1700. Oder, wenn der Fladen für das bischen Anwendung zu gross ist, am STM32 (USB in LQFP48). Wobei deine Beschreibung nicht so sehr nach hoher Performance klingt.
A. K. schrieb: > Wobei deine Beschreibung nicht so sehr > nach hoher Performance klingt. eigentlich nicht, nur die Auswertung der verschiedenen Inputs und der USB-Kram (die große Unbekannte für mich, was die Performance etc. angeht). A. K. schrieb: > STM32 (USB in LQFP48) hab ich mir grad angeschaut - was ist hier eigentlich der Unterschied genau zu den STR911? Cortex sind strom-sparsamer, aber aus welchem Grund sind diese schneller in der Abarbeitung von normalen Code? Herbert
Herbert schrieb: > hab ich mir grad angeschaut - was ist hier eigentlich der Unterschied > genau zu den STR911? Cortex sind strom-sparsamer, aber aus welchem Grund > sind diese schneller in der Abarbeitung von normalen Code? Der Befehlssatz von ARM7/9 und Thumb(1) kann Konstanten zunächst unbekannten Wertes (z.B. Adressen) praktisch nur PC-relativ laden, also typischerweise aus dem Flash. Mit Cache oder entsprechenden Puffern ist das weniger kritisch, aber wenn jedem solchen Ladebefehl unweigerlich 5 Waitstates auf den Buckel geschnallt werden (STR9@96:5, SAM7@55:1), dann macht sich das bemerkbar. Diese Ladebefehle sind in normalem ARM Code ziemlich häufig und sind einer der Gründe, weshalb beim ARM7 Code im RAM erheblich schneller sein kann. Mit dem Thumb2 Befehlssatz ist das anders. Da lassen sich 32bit Konstanten wie bei vielen anderen RISCs in 2 Hälften ohne Datenzugriff auf das Flash laden. Braucht etwas mehr Platz (8 Bytes statt 6), wird aber nicht durch Waitstates ausgebremst. Bei NXP kommt von Anfang an noch eine Pufferung von Code- und Datenzugriffen auf das Flash hinzu, die beim LPC1700 schon an einen kleinen Cache erinnert. Die entsprechenden Puffer vom STR9 beziehen sich jedoch nur auf Code, dort fehlt jegliche Pufferung von Datenzugriffen auf das Flash. Der STR9, jedenfalls in der mir vorliegenden ursprünglichen Version ohne "A", hat wohl noch andere kleine gelegentlich bremsende Fiesheiten drin, jedenfalls benimmt er sich bei bestimmten Performance-Tests teilweise recht seltsam, bricht dann markant ein, während LPC2100 und STM32 sich wie erwartet verhalten. Dann gibt's bei den Grosshirnen natürlich noch die Division. Wenn man die in der Anwendung oft brauchen sollte, dann kann das auch eine Rolle spielen.
nachdem die Cortex-ARMs ja auf dem Vormarsch sind, werd ich mal einen von ST austesten. Performance-mäßig sollte dieser (mit 72MHz) das ja hinbekommen, oder? Bin mir hier wie gesagt nur bezüglich des USBs nicht sicher. Vielleicht kannst du das etwa abschätzen?
Ich habe USB dort noch nicht verwendet und kann deine Anwendung auch nicht abschätzen. In den letzten Wochen gab es hier einen Thread, der auf den Datendurchsatz von USB und die erforderlichen Performance abzielte. Daraus lässt sich vermuten, dass es für den vollen Durchsatz von USB mit 12Mbps mit jedem solchen vollintegrierten Controller eng werden dürfte, zumal wenn die Daten nicht einfach vom Baum fallen, und es dann eher auf grössere Kisten wie ARM9 mit 3stelligen MHz rausläuft.
hab zwar wahrscheinlich nicht diesen aber einen anderen Thread über ARM7 und USB Performance gefunden:; Beitrag "AT91SAM7X USB Datenrate" Aus diesem Thread: >Kann ich nur bestätigen, auf einem AT91SAM7S256 habe ich auch knapp über >800 kB/s erreicht. Bulk mit libusb "Treiber". Der µC ist dann aber auch >schon gut beschäftigt. Die Datenrate reicht für mich auf jeden Fall; sind ja nur die Auswertungen (Touch-Koordinaten, Tastendruck, Encoder, und die LED Treiber)... Wenn ich auf externe Sachen wie Flash und SDRAM verzichten möchte, wird das die schnellste Alternative sein...
ich denke die Frage ob der STM32F ausreicht, wird sein ob dieser in der Lage ist drei Endpoints (alle Interrupt Mode) zu verwalten und jede 1ms Daten wenn notwendig (reichen dann die 64kB) an den PC zu versenden. Diese müssen natürlich zuvor per SPI (Touch-Contrller) entsprechend ausgewertet werden, damit nur die reinen Touch-Koordinaten versendet werden. Beim Encoder / Tasten ist die Auswertung schnell zu erledigen.
800kB/s / 64BByte/pkt = 12.5k Pakets/s -> 12.5Pakets/ms -> bin ich auf dem richtigen Weg? Ich bräuchte ja nur 4 Pakets pro 1ms -> dann müsste das doch aufgrund dieser Angaben funktionieren von der Performance her, oder? Die 64Byte sind reine Nutzdaten, oder?
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.