Zum testen ob mein ARM9 (str912, programmiert mit Embedded Workbench 5) wirklich mit PLL auf 96 MHz läuft habe ich einfach eine Endlosschleife geschrieben, die nur einen GPIO-Pin toggeln läßt. Obwohl er beim Start laut Debugger durch die PLL-Initialisierung läuft im Startup.s), messe ich nun am Ausgang gerade mal o,8-1us zwischen den Pegelwechsel. Da der ARM doch mit einem CPU-Zyclus auf die GPIO schreiben können sollte und eine Schleife, eine Ausgabe und eine Invertierung doch auch in Assembler nicht mehr als drei Befehle sein sollte, kann ich das irgendwie nicht nachvollziehen! Müßte das nicht irgendwo die dreifache Geschwindigkeit sein? Hatte zwischendrin auch immer mal Probleme das er beim Programmstart in der PLL_Lock Schleife hing, und nach ein paar resets wars wieder ok, keine Ahnung ob da ein Zusammenhang besteht... Im Endeffekt will ich mit meiner Anwendung ein Signal abtasten, und da ist es natürlich entscheident zu wissen wie schnell ich die Werte abfragen kann. Hoffe es kann mit diesen Phänomenen jemand was anfangen. Danke euch!
Der Thomas wrote: > Da der ARM doch mit einem CPU-Zyclus auf die GPIO > schreiben können sollte Warum sollte er das können? Beim STR9 hängen die Ports an einem der eher langsamen Peripheriebusse. Wobei man an den diversen Busbridges auch ein bischen rumkonfigurieren kann. Wenn du schneller Pin-I/O benötigst, bist du mit neueren LPC2000 besser dran. Da hängt die Fast-I/O am schnellen Bus.
Ich habe irgendwas im Hitex Guide gelesen, das durch die zusätzlichen DR ja keine zusätzliche maskierung mehr nötig ist beim Schreiben in die Register, das hab ich wohl irgendwie durcheinander geworfen. Kannst du mir ein paar Tipps geben, wie ich das Optimum raushole? Wäre mir sehr, sehr hilfreich. Und wie gesagt, im Endeffekt muss ich schnell lesen, weniger schreiben...
Erstens ist, wie du schon erwähnst, üblicherweise kein read-modify-write nötig, da in der Adresse eine Maske mitgegeben werden kann. Wenn du darüber hinaus maximale Leistung rauskitzeln willst, kann es nötig sein, die entsprechende Doku reinzuziehen. Da gibt's so einiges, nicht nur von ST sondern insbesondere auch von ARM, aber dieses Thema ist nicht wirklich trivial. Das fängt damit an, dass die Peripheriebusse ab Reset mit halben Takt (HCLK) arbeiten. Was nicht sein muss. Aber was dein Startup-Code da anstellt musst du selber rauskriegen. Und geht dann weiter mit dem Bus Split. Wobei ich nicht weiss ob der bei GPIO relevant ist, aber wenn, dann ist dieser Parameter der zuständigen AHB Bridge die nächste Stellschraube weil ein Split zwar effiziente Busausnutzung ermöglicht, aber mindestens Lesezugriffe leicht ausbremsen kann. Was schnelle Schreibzugriffe angeht, ist dann Lektüre der Dokumentation des ARM verwendeten Cores wichtig (ARM966E-S, kriegt man bei arm.com), denn darin ist die BIU nebst ihrer Pufferung beschrieben. Spielt aber bei reinen Lesezugriffen nicht so die grosse Rolle. Einen Eindruck von Arbeitsweise und Zeitverhalten der AHB Bridge vermittelt die AMBA Spezifikation (auch arm.com, IHI0011A).
Wenn es dir nur darum geht, rauszufinden wie schnell das Teil ist, dann ist schnelle Port-I/O der falsche Weg. Dann machst du ganz gemütliche Port-I/O mit einer wohldefinierte längeren Wartezeit dazwischen. Und schon spielen AHB&Co kaum noch eine Rolle.
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.