uC Auswahl / rechenleistung

Wenn Du direkt die generierten Alogrithmen aus irgendeiner
Algebra-Software ausführen lassen willst, wird keiner der üblichen 8bit
uCs ausreichen. Diese Code-Generatoren gehen eigentlich immer von einer
CPU mit Floating-Point Einheit aus, die uCs müssen das simulieren.

Also, entweder Code händisch schreiben, und sich evtl. von dem
generierten Code inspirieren lassen, oder nen richtig grossen
Controller mit 32Bit ints, FPU in hardware, etc nehmen.

/Ernst

Danke Ernst,

ich habe eher um 16-bit Processoren gedacht, C167 oder HC12 Familie.
Die sind dazu wahrscheinlich doch zu schwach. Hat jemand Erfahrungen
mit TriCore von Infineon?

Übrigens die generierte Code sieht ziemlich gut aus, ich komme jetzt
ziemlich klar damit, es ist nur viel "overhead" wegen typedefs usw,
das hat aber keinen Einfluss auf Effizienz. Ich schätze mal, dass
händllich geschriebene code nur etwa um 10-20% schneller wäre.

"ich habe eher um 16-bit Processoren gedacht"

Da ist kein großer Unterschied, wenn es um floating point geht.

Selbst die 32Bit Philips LPC-Serie ist absolut kein Rechenmeister, die
haben gerademal ne Integer-Multiplikation und mehr nicht.

Ein 8-Bitter mit 32Bit-Divisionseinheit schlägt den locker.


Wenn man dagegen die Rechnungen auf 16 oder 32-Bit Integer umschreibt
und noch möglichst viele Divisionen ersetzt, erreicht man Zeitgewinne
von mindestens 10000% und mehr.


Peter

Ich brauche auch trigonometrische Funktionen, und tanh, exp .. Also muss
sowieso mit FP rechnen.

Die frage ist jetzt also welcche MC gibts mit FPU unterschtützung,
nicht zu teuer und nicht zu kompleziert (hab nur ein analoge Eingang-
und ein Ausgangsignal und brauche evtl. CAN oder RS232 Schnitstelle).

Wieviel Zeit dürfen solche Operationen benötigen?

Der MPC555 dürfte genau das Richtige für dich sein, dafür gibts auch ein
Embedded Target von Mathworks.
* 32 Bit PowerPC Core
* 64 Bit FPU
* CAN
* RS232
Ist aber nicht billig und vor allem nur professionell zu verarbeiten.
Schau mal bei Phytec, die haben Module, die sich auch noch in double
Layer routen und von Hand löten lassen. Ich mache sowas im Moment mit
dem MPC565, kann dir da bei konkreten Fragen also gerne weiterhelfen.
Zumindest der C166 könnte auch noch was für dich sein, hab ich aber
keine Erfahrungen mit.

Mark,
Wenn Du etwas Zeit in die Code-Optimierung steckst, wird das
höchstwarscheinlich sogar mit einem 8Bit AVR gehen.

Dein Analog-Eingang wird warscheinlich 8 oder 10 Bit Genauigkeit haben,
das LSB würd ich beim Auslesen schon Rausglätten, z.B. moving average
über die letzten Messungen, davon 9 Bit verwenden, aber auch mit 10
Bit=1024 möglichen Werten sollte das gehen:

Deine Formel so umformen das Du möglichst grosse Funktionsblöcke
isolierst, die nur von einem Eingabewert abhängen, und die dann in
Tabellen auslagern. AVRs gibts z.B. mit 256KB Flash, da passen dann
locker 100 solche Tabellen rein, und es ist noch genug Platz für die
Applikation. Das sollte auch für komplizierte Formeln mit mehreren
Rückkopplungen etc reichen.

Den Matlab-generierten Code kannst Du dann allerdings nur noch zum
Berechnen der Tabellen verwenden, aber der Formel-Rest im AVR ist dafür
dann recht simpel.

/Ernst

"Ich brauche auch trigonometrische Funktionen, und tanh, exp .. Also
muss sowieso mit FP rechnen."


Das is ein Irrtum !

Man kann sowas auch prima ohne float machen. Dein Taschenrechenr z.B.
macht das nur mit ner 4 Bit Integer CPU.

Es gibt z.B. Tabellen, Reihenentwicklung, Interpolationsmethoden oder
nen Mix daraus, kommt ganz auf die benötigte Genauigkeit an.


Peter

"Es gibt z.B. Tabellen, Reihenentwicklung, Interpolationsmethoden oder
nen Mix daraus, kommt ganz auf die benötigte Genauigkeit an."

Meine Rede, allerdings kann man da schnell viel Unsinn produzieren.
Ich kenn keinen Code-Generator der da nur halbwegs Sinnvolles in der
Richtung produziert, ist also auf jedenfall Handarbeit angesagt.

Die Mathematik hinter den Formeln im Algebra-System sollte man dann
schon genau verstanden haben, und ohne zumindest ein bischen Gefühl für
Numerik wirds auch schnell ungenau werden.

/Ernst

>>Man kann sowas auch prima ohne float machen. Dein Taschenrechenr z.B.
macht das nur mit ner 4 Bit Integer CPU.


Aber letzlich macht er auch float ! Würde auch mit 1-Bit CPU gehen und
mit 8/16/32 umso schneller. Aber wie schnell hier überhaupt was
gerechnet werden muß, weiß doch niemand. Sind alles nur Spekulationen.

Wenn der µC etwas Zeit zum rechnen hat und 32bit Fliesskommaformat
ausreicht, tut's jeder µC mit C Compiler, dessen Library das bietet.

Wenn die Zeit nicht bleibt, dann rutsch rüber ins DSP-Forum. DSPs sind
auf sowas spezialisiert.

Bandbreite muss etwa 2-5 kHz sein, brauche also Zyklus-Zeit etwa 20-90
us.

Um DSP habe ich auch schon gedaht, die sind aber für viele
Ein-/Aus-gänge gedacht sind. Oder vielleicht ein uC mit
DSP-Funktionalität.

Mit den Anforderungen bist du im DSP Lager besser aufgehoben. Was hast
Du gegen die Dinger? Und DSPs sind gerade nicht für viele I/O Pins
berühmt, sondern für Rechenaufgaben. Kannst ja mal bei den
ausgesprochen übersichtlichen dsPICs reingucken, vielleicht reichen die
schon aus. Aber DSP-Spezis können dir da besser weiterhelfen.