Hallo,
habe bei einem Projekt einen ATTiny45 gewählt. Stromsparend, 128kHz, 3x
8bit ADC, 1xIO Output... Nun komme ich leider mit dem Code an die
Grenzen der *.hex. ATTiny45 geht schon nicht mehr. Der 85er wird wohl
auch nicht reichen. Der Code bildet eine Logik ab, die kaum zu
reduzieren ist und sollte weiterhin ANSI-C gcc sein.
Welchen Atmel ATxxxx würdet ihr empfehlen, der einen "ATTiny85-V-DIL"
aber mit min. 16kByte gut ersetzen könnte. Anzahl der DIL wird wohl
wachsen. Dachte da z.B. an einen ATMEGA32L8 DIP,... Geschwindigkeit ist
untergeordnet, Energieverbrauch ist Prio 1.
Gruß und Dank Markus
mgolbs schrieb:> Der Code bildet eine Logik ab, die kaum zu> reduzieren ist und sollte weiterhin ANSI-C gcc sein.
Das halte ich aber für ein Gerücht.
8kB ist schon ne riesen Menge für so nen kleinen MC.
Das Programm mußt Du mir erstmal zeigen, das da nicht reinpaßt.
Du solltest vielleicht nicht für jede Bitvariable long long verwenden,
die Optimierung einschalten (-Os) und keinen Copy&Paste-Monstercode,
sondern Unterfunktionen mit Parametern.
Peter Dannegger schrieb:> Du solltest vielleicht nicht für jede Bitvariable long long verwenden,
Du solltest vielleicht nicht jedem Fragenden absolute Blödheit
unterstellen.
Hallo,
danke für die vielen Hinweise. Wass soll das Programm machen. Es werden
drei AD's benötigt, wo die drei Achsen des MEM's dran hängen. Der MEMS
ist beweglich an einem Objekt befestigt, oder besser das Objekt kann
keinen festen Bezug zur Erdbeschleunigung in Abhängigkeit vom Gehäuse
sicherstellen. Code muss vollkommen unabängig von räulicher Lage
funktionieren, Lage erkennen..
Dabei muss jede Sekunde der Betrag des Absolutbeschleunigungsvektors
berechnet und klassiert werden. Eine spezielle Einlauffunktion ist
ebenfalls notwendig. Weiterhin muss der Algorithmus noch
Zeitklassierungen von jeweils 25% Fenstern machen. Das alles ist durch
die Systembedingungen fest und fix.
Am Ende kommt noch eine Modul für die Datenanalyse. Code ist zu 90%
fertig und hat aktuell 7kB. Ich habe 3xfloat für die Fließzahlen (g's),
ein double (Wurzelfunktion) und einige int die anteilig byte sein
könnten....
Ich werde mir also mal die ATmega328P und ATMega168P anschauen.
Gruß und Dank Markus
mgolbs schrieb:> Code ist zu 90%> fertig und hat aktuell 7kB.
Das ist sehr verwunderlich, irgendwas läuft da schief.
Die float-Lib braucht nur einmalig 1kB, daran kanns nicht liegen.
Kannst Du den Code mal anhängen?
mgolbs schrieb:> habe bei einem Projekt einen ATTiny45 gewählt. Stromsparend, 128kHz, 3x> 8bit ADC, 1xIO Output... Nun komme ich leider mit dem Code an die
128kHz? Es könnte vom Energieverbrauch her günstiger sein, eine deutlich
fettere Architektur wie z.B. PIC32 (da gibts auch einige im SDIP28
Gehäuse, die rechnen eine Zehnerpotenz schneller als ein AVR, ohne dafür
das 10-fache an Leistung zu benötigen) zu verwenden, die die Aufgabe in
deutlichst kürzerer Zeit löst und dafür längere Zeit im Sleep-Zustand
verbringt, bis der nächste Zyklus startet.
fchk
Hallo,
danke für die Rückmeldungen. Habe jetzt alles auf int umgestellt, mit
einigen vertretbaren Abstrichen bei Genauigkeit. Bin nun mit einer
lauffähigen Grundversion bei knapp 8kB - ATTiny85.
Diese werde ich erst mal praktisch testen. Sollte die Logik weiter
wachsen müssen, werde ich auf 16kB AT... umsteigen. Die Logik macht
einfach den benötigten Flash Speicher aus. Sicher ist auch mein C-Code
nicht das absolute Optimum. Wenn es funktioniert und ich 1€ mehr für die
MC-Unit ausgebe, ist das mein bevorzugter Weg :-)
Auf andere Systeme möchte ich nicht umsteigen, auch wenn diese eventuell
besser sind. Das ist für einen gelegenheits Hobbyelektroniker von der
Vielfalt dann nicht zu beherrschen, Standdards sind für mich Prio 1.
Gruß und Dank
Markus
mgolbs schrieb:> Die Logik macht> einfach den benötigten Flash Speicher aus.
Für Bitvariablen kann man auch GPIOR2..0, USIDR, EEARL und EEDR
benutzen, die sind bitweise zugreifbar.
Hallo,
habe wohl doch noch einen größeren Fehler gemacht. Bin bei der Bewertung
für die Programmgröße im Flash immer von der hex Dateigröße im
Dateimanager ausgegangen. Mit AVRDude wird mir nach der Programmierung
aber ein deutlich kleinerer Flashbedarf angezeigt. Wie ist das zu
verstehen?
Gruß und Dank Markus
Hi
>Wie ist das zu verstehen?
Ein Hex-File ist keine Binärdatei. Jedes Byte wir durch zwei
ASCII-Zeichen dargestellt. Dazu kommen noch zusätzliche Informationen.
Pi mal Daumen ist ein Intel-Hex-File etwa zweieinhalb so groß wie die
darin enthaltenen Daten als Binärfile.
MfG Spess
Sprachlos schrieb:> Du solltest vielleicht nicht jedem Fragenden absolute Blödheit> unterstellen.
Würde man ja gerne machen, aber die Realität belehrt einen dann doch
immer wieder eines besseren...
Oliver
