was man so alles in 1024 Flash Words eines PICs bekommt

Ich halte nicht viel davon alles bis aufs letzte Bit auszuquetschen. Ich habe gerade einen 3xRegler geschrieben der laeuft in einem R8C29 mit 16kb Flash. Hat den Vorteil das ich mir um Platz keine Gedanken machen musste und es kein Problem war ein SoftwareRS232 zusaetzlich rein zu machen das mir 1x pro Sekunde saemtliche Regelparameter ausgibt. Ausserdem haben so gut wie alle meine Projekte eine I2C Schnittstelle wo man jederzeit ein LCD anstoepseln kann und dann ein paar wichtige Infos ablesen kann. Das macht Service und Diagnose, gerade auch im Feld, deutlich einfacher. Und man kann dasselbe IC auch in mehreren Projekten verwenden, also ist es keine grosse Sache da auch mal einen Berg auf Halde zu legen weil man sie sowieso brauchen wird.

Ich vermute mal nicht. Aber warum darueber nachdenken? Privat verwende ich nur noch einen M16C mit 96kb Flash, 10k Ram, 2k Dataflash, mehr Timer, SPI, DMA, Uart, I2C usw als man jemals braucht und er kostet

Und beruflich dimensioniere ich den Speicher auch immer 2x ueber. Zum einen kann man sich auch auch mal vertun und es waere doch irgendwie bloed viele Entwicklungsstunden wegwerfen zu muessen, zum anderen ist es meine Erfahrung das im Nachhinein immer jemand ankommt und noch was zusaetzlich reingebaut haben will.

Geiz ist nicht geil, ausser man entwickelt Sachen die im Bloedmarkt

Olaf

Da setzen A/D- und D/A-Wandler Grenzen in der Auflösung. Selbst wenn man z.B. 16 Bit Wandler verbauen würde, wären Sensoren und Aktoren die nächste Grenze. Die sind auch oft mit 8 Bit ausreichend gut bedient.

MfG JRD

Rafael Deliano schrieb:

Ich behaupte ja gerne, daß nichts, das sich nicht gerade mit Physik oder Mathematik beschäftigt, Fließkommazahlen braucht. Aber das führt gerne zu Glaubenskriegen ;-)

Ich finde es aber schon interessant, daß

Falk, der immer Pickel bekommt, wenn er "float wert=getadc(N);" liest.

Ich habe mal spa=DFeshalber ein Hello World Programm mit einer Flie=DFkommamultiplikation und einem Vergleich durch den AVR GCC gedreht.=

Die Flie=DFkomma Routinen ben=F6tigen ~1,5kB Speicher. Mit einer 1kB Maschine wird es da nichts, mit 2kB hat man auch praktisch keinen Platz f=FCr eine Applikationslogik. Meiner Erfahrung nach macht das ab 4kB aufw=E4rts Spa=DF. Aber braucht man wirklich Flie=DFkomma in so einem kleinen Rechner ? PID geht auch mit 16bit, da wie andere hier schon schrieben die AD / DA(PID)

Macht der Compiler ein echtes float oder nur 16 oder 32bit Festkomma ? Ich meine so etwas schon gesehen zu haben. Wenn nicht, Hut ab, da haben sehr dichten Code erstellt.

Gru=DF Hans

Mit Renesas-Controllern schießt man sich doch grundsätzlich ins Knie...

Myn

Das ist echtes Float. Man kann wählen zwischen IEEE 754 kompatiblen 32 Bit Modus oder einem abgespecktem 24 Bit Modus. 32 Bit läuft aber irgendwie nicht mit meinem Projekt oder der CPU.

Beim 24-Bit Modus sieht die Auslastung so aus:

Program space used 30Eh ( 782) of 3FFh words ( 76.4%) Data space used 33h ( 51) of 40h bytes ( 79.7%)

Wenn ich irgendwo ein * 2.0f hinzufüge, steigt der Program Space Bedarf um

Das stimmt schon, aber als fauler Programmierer wie ich möchte man nicht dauernd shiften und sich überlegen müssen, ob ein Koeffizient und das Ergebnis denn nun noch in die gewählte Darstellung passt, sondern einfach die mathematischen Formeln hinschreiben :-)

Generell gebe ich dir recht, mehr Speicher und mehr IOs machen einem das Leben leichter und für Hobbyprojekte mach es nicht viel Unterschied. Allerdings gibt es die größeren Chips meist nicht als kleine 8 Pin Chips. Wenn man wirklich nur z.B. einen einfachen VCO braucht, überlegt man sich dann schon zweimal, ob man sich das antun möchte und sowas großes einsetzen will. Ist wohl auch sportlicher Ehrgeiz, es möglichst klein und preiswert hinzubekommen. Einen fetten Wollmilchsau Microcontroller zu nehmen und den vielleicht sogar noch in Basic zu programmieren, ist keine Kunst :-)

eigentlich alles, was vorrangig mit Multiplikation, Division und höheren Rechenarten arbeitet. Mit Addition und Subtraktion haben Floats so ihre Probleme. Dabei reduziert sich die Genauigkeit.

Och, ADCs sind ja per se auch nicht exakt. Und für ein IIR-Filter tut man sowieso gut daran, ein paar Stellen hinter dem Komma vorzusehen, damit das Ding nicht oszilliert. Bei Geldbeträgen finde ich es immer deutlich ambitionierter. :-)

Marcel

für solche Zwecke sind Bibliotheken mit Rationalzahlen zuweilen hilfreich. Allerdings ist man damit auch nicht mehr so weit von den Floats entfernt. Der Unterschied ist, dass bei denen der Nenner immer eine Zweierpotenz sein muss.

Wenn man C++ hat, kann man den Nenner auch zum Teil des generischen Typs machen. Dann hat man Fixpunktarithmetik mit Compile-Time-Checks. Der erzeugte Code bleibt dabei unverändert.

Marcel

heute macht man viele Optimierungen zu lasten der Code-Größe. Z.B. Loop Unrolling oder spezielle Unterroutinen für häufige Sonderfälle.

Ich denke, wenn man die Runtime mal mit "optimize for size" übersetzt, wird es auch ruhiger. Ein anderer Punkt sind Fabrikmethoden jeglicher Art, z.B. für printf. Die ziehen Abhängigkeitsbäume zu allen potentiellen Komponenten nach sich, auch wenn der reale Code nur einen Bruchteil davon nutzt. So explodiert z.B. die Bibliothek von printf, sobald das Programm den ersten Aufruf in die Floatingpoint-Bibliothek macht - auch dann, wenn niemals %f o.ä. genutzt wird.

Marcel

Ich habe nicht den Eindruck das Wandler bei einem normalen Regler da eine Grenze setzen. Du brauchst aber sehr schnell grosse Datentypen oder notfalls Fliesspunkt weil du mit Zahlen hantierst die sehr unterschiedlich gross sind.

Wie schon erwaehnt ich habe gerade einen Temperaturregler gebaut. Dort wird long als Datentyp verwendet, die Parameter sind alle skaliert. Da musste ich mir schon Gedanken ueber die groesse meiner Zahlen machen damit es zu keinem Registerueberlauf kam. Ich musste sogar eine Funktion welche mir die Regelparameter fuer den jeweiligen Arbeitspunkt liefert, so schreiben das sie einen Parametersatz in Abhaengigkeit der Eingangsgroesse unterschiedlich berechnet weil ich da sonst ein Problem hatte. So gesehen waere Fliesskomma schon schoen gewesen. Liess sich aber noch umgehen. :)

Olaf

Am Sun, 22 Nov 2009 12:16:03 +0100 schrieb Marcel Müller:

C++ und schlanken Code für Microcontroller bekomme ich nicht so richtig unter einen Hut.

Lutz

Ich verwende lieber meinen HP48 und seine ->Q Funktion. Damit kann ich dann die Zahlen in Brueche umwandeln, gelegentlich springt einen dann sofort ins Auge wie man den Bruch bei geringen Genauigkeitsverlust auf kleinere Zahlen bringen kann, und ansonsten die einzelen Zahlen in seinen Funktionen geschickt umsortieren damit keine Maximamalwerte ueberschritten werden.

Olaf

Also ich rufe immer olaf_printf auf, da passiert das nicht. :-)

Einfach seine eigene Printf-funktion schreiben. Zahlt sich immer aus. Ausserdem kann man so gleich den vergessenen Parameter 'b' dazuerfinden um auch binary auszugeben.

Olaf

Auf einem 8 Bit Controller ist typisch selten mehr als ein 8 Bit A/D-Wandler verfügbar, an einem 8 Bit Port kann man dann noch per R2R-Netzwerk einen 8 Bit D/A ankleben. Die Kombination rauscht mehr und hat weniger Dynamik als z.B. ein analoger PID mit beliebig billigen OPs. Es gibt zwar A/D-Wandler mit nominell 10-12 Bit Auflösung in Controllern, da schränkt aber das Kleingedruckte oft die Freude ein. Man kann auch versuchen 16 Bit PWM als D/A zu verwenden, aber da wird einem maue Geschwindigeit bzw. der Ripple bei simplem Filter bei Regler oft keine Freude machen.

MfG JRD

Sind nicht 10-12Bit eher ueblich? Ich meine selbst der alte 80535 hatte doch schon irgendwie mehr aufloesung oder taeusche ich mich da?

Du nimmst kein PWM Ausgang?

Analoger PID kann unbrauchbar sein weil du die Koeffizienten nicht mal eben so aendern kannst.

Ich nutze bei meinem Regler 10Bit am Eingang und 8Bit PWM am Ausgang und habte trotzdem eine hoehere Aufloesung beim Rechnen gebraucht.

Olaf

Hmm? Kannst du elaborieren?

Viele Grüße, Johannes

-- "Aus starken Potentialen können starke Erdbeben resultieren; es können aber auch kleine entstehen - und "du" wirst es nicht für möglich halten (!), doch sieh': Es können dabei auch gar keine Erdbeben resultieren."

-- "Rüdiger Thomas" alias Thomas Schulz in dsa über seine "Vorhersagen"