mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Leistungsbedarf des 32-bit Controllers LPC2106 von Philips


Autor: Andreas Kirsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich hoffe Ihr könnt mir weiter helfen.
Im Rahmen meiner Diplomarbeit ist es für mich wichtig eine Abschätzung
des Leistungsbedarfs (statisch wie dynamisch) des LPC2106
durchzuführen. Dem Datenblatt konnte ich lediglich den Ruhestrom und
Kernspannung entnehmen. Die Daten beziehen sich auf den Fall, dass der
Controller zwar mit 60MHz getaktet wird, aber keine zusätzliche
Peripherie (Timer, UARTs, sonstige I/Os, ...) angeschlossen ist. Mit
diesen Werten komme ich auf 54mW, was mir doch sehr wenig erscheint.
Von Interesse wäre daher der Bedarf bei angeschlossener Peripherie und
zudem in wie weit sich der Leistungsbedarf senkt, wenn ich mit
lediglich 25MHz takte.

Nach Aussagen eines Kommilitonen unterscheiden sich statischer und
dynamischer Leistungsbedarf nur unwesentlich, da die "Clock" ständig
am Laufen ist. Wenn dem so ist hätte ich (bzw. ihr, wenn ihr mir Helfen
wollt) ein Problem weniger. Ich denke allerdings das die Algorithmen
die verarbeitet werden sollen schon einen Einfluß auf den
Leistungsbedarf haben. Vielleicht gibt es eine schöne Formel bzw.
Vorgehensweise wie ich den dynamischen Bedarf berechnen kann.
Die Algorithmen die ich zu verarbeiten habe stehen noch nicht alle
fest, allerdings wird auf jedenfall eine FFT benötigt.

Ich hoffe es gibt jemanden unter Euch der schon Erfahrungen mit dem
Philips Baustein (Serie 210x) gesammelt hat und der mir weiter helfen
kann.

Gruß Andy

Autor: Andreas Kirsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger
Diesem beitrag habe ich nur zuzufügen, das es wohl doch Leute gab die
Ihn aufgrund meines Hilfeschreis gelesen haben.


Ich bitte um Entschuldigung das ich mich selbst hier wieder vorschiebe,
eignetlich halte ich das auch nicht für die feine Englische.

@MMerten
Danke für die bisherige Antwort
ich werde auch bei Atmel direkt mal nach dem ARM7 Prozessor schauen

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Frequenzabhängigen Leistungsaufnahme:
Wenn es in den Datenblättern kein Diagramm oder ähnliches gibt, ist das
nicht theoretisch ermittelbar, dürfte wohl kein linearer Verlauf sein.
Ich halte es auch für müßig, den genauen Leistungsbedarf feststellen zu
wollen. Dieser ist abhängig von:
- Leistungsaufnahme des Kerns (scheint bekannt)
- Leistungsaufnahme der Peripherie (abhängig vom aktuellen
Betriebszustand, welche Frequenz haben die Signale, welche Kapazitäten
müssen sie treiben etc etc)
- Umgebungstemperatur (Widerstandsänderung)
- und viele Kleinigkeiten, an die man momentan nicht denkt.

Mehr als eine Schätzung über den groben Daumen +/- 50% wird wohl nicht
heraus kommen, da es viel zu viele unbekannte Parameter gibt.
Allerdings glaube ich auch nicht, daß es meßbare Unterschiede der
Leistungsaufnahme bei Ausführen einer Software oder einer Warteschleife
gibt. Sofern der Controller über einen Stand-by Modus verfügt, kann es
aber schon Unterschiede der Leistungsaufnahme geben.

Mal im Ernst: Um wirklich exakt auf die Leistungsaufnahme während eines
bestimmten Betriebszustands zu kommen, bleibt nur die Praxis - also
einfach messen - oder besorg Dir das Layout des Controllers, zähle
sämtliche Gatter aus, erstelle eine Analyse der voraussichtlich
verwendeten Prozessorbefehle und berechne an Hand der verwendeten
Gatter pro Befehl die Werte (nicht ganz so ernst gemeint ;-))

Was spricht dagegen, das Projekt nebst Software fertigzustellen und die
Leistungsaufnahme am Ende in der Praxis zu ermitteln?

Autor: Andreas Kirsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais
Genau auf die genannten Probleme bin ich auch gestoßen und ich denke
mir das eine Messung die besten Ergebnisse liefert.
In meiner Arbeit geht es jedoch nicht direkt um die Verwirklichung auf
dem MC sondern um eine Hardwarelösung auf FPGA Basis. Die
Leistungsabschätzung soll lediglich dazu dienen einen Vergleich
zwischen    den Lösungsansätzen zu ermöglichen und ob es für weitere
Anwendungen wirklich sinnvoll ist die FPGA Lösung zu wählen. Aus diesem
Grund werde ich nicht die Zeit haben die beiden Alternativen diskret
aufzubauen, zumal ich mit der Verarbeitung auf dem MC und dessen
Programmierung so gut wie noch keine Erfahrungen habe und die Zeit
sicherlich benötige um die andere Hardware sicher zum Laufen zu
bringen.

Mit Dank Andy

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn die Wahl der Methode ausschließlich von der Stromaufnahme
abhängig? In letzter Zeit werden, soweit ich das mitbekomme, auf Unis
äußerst gern FPGAs verwendet - warum auch immer, wahrscheinlich wegen
der netten grafischen Programmiermöglichkeiten g

Wenn Du nicht die Zeit zum Messen hast, bleibt nur die Schätzung an
Hand der Datenblätter. Ich würde mich garnicht lange an der Problematik
festbeißen. Alles, was Du theoretisch ermittelst, wird
höchstwahrscheinlich sowieso nicht der Realität entsprechen - also hake
die Geschichte ab, nimm den FPGA und fertig, sonst verrennst Du Dich
und Dir läuft die Zeit davon.
Ich selbst beschäftige mich nur in der Freizeit mit Controllern - und
der Mehrheit im Forum wirds wohl so gehen - und da wird nicht unbedingt
mit den mWatts gegeizt, deshalb gibts wohl auch keine Erfahrungswerte
in diese Richtung. Aber vielleicht hat jemand anders doch noch eine
Idee, wie man zu halbwegs brauchbaren Ergebnissen kommen könnte.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

die Leistungsaufnahme was den reinen Controller angeht sollte neben der
"Grundlast" relativ linear mit der Taktfrequenz steigen. Die rein
theoretische Ermittlung der Leistungsaufnahme halte ich aber für
theoretischen Uni-Blödsinn. Das kann man evtl abschätzen aber was
besseres als +-50% kommt dabei nicht raus. Also entweder den Controller
mal mit "NOP's" füttern und messen oder einfach einen über den
Daumen gemittelten Wert der halbwegs plausibel ist in die Diplomarbeit
schreiben. Ich glaube kaum das sich irgend ein Prof. die Finger
schmutzig macht und das nachprüft.

Matthias

Autor: Andreas Kirsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais
Die Wahl ist eigentlich wirklich schon auf den FPGA gefallen.
Warum?
Es ist einfach ganz schön die Hardware je nach Anwendungsgebiet
umgestallten zu können und die Verarbeitung weitestgehend von der
Hardware machen zu lassen und im Gegensatz zur Softwareverarbeitung
einen Geschwindigkeitsgewinn zu erzielen. Das auch mit vernünftiger
Assemblerprogrammierung etliche Hürden genommen werden können steht
außer Frage und ich bedauere es auch sehr diese Basics nur am Rande
erlernt zu haben. Aber welcher Computerneuling kennt sich den heute
noch mit DOS und den eigentlichen Verzeichnisstrukturen aus und wer
wird in einigen Jahren noch wissen was ein Schaltgetriebe ist. Schade
eigentlich.

Ich möchte auch wirklich nicht allzuviel Zeit für die simple
Leistungsabschätzung aufwenden, daher hoffe ich immer noch auf jemanden
der evtl. Erfahrungen mit dem LPC gesammelt hat, ansonsten werde ich
mich wirklich nur auf die Kernleistung beziehen müssen, da der Rest der
Arbeit noch genügend Energien in anspruch nehmen wird.

Herzlichen dank auf jeden Fall für deinen Beitrag

@Mathias
Das es sich bei einer genauen Abschätzung ohne die Hardware einmal in
vivo laufen zu lassen um Uni-Blödsinn handelt mag sein. Der Sinn der
bei mir dahinter stecken würde, wenn ich evtl. Erfahrungswerte bzgl.
des MC angeben könnte, wäre entweder der, den FPGA Zweiflern recht zu
geben (zu hohe Verluste gegenüber MC) oder diese darauf hinzuweisen,
das es gerade im Bereich der Entwicklung doch Sinnvoll sein könnte auch
konfigurierbare Hardware (nur geringfügig höhere Verluste aber evtl.
schneller und Hardware anpassbar) mit in die Überlegungen einzu
beziehen.

Gruß an Euch zwei Andy

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.