Atmel MC; ATTiny45/85 Alternative mit mehr Flash - 16kByte, Rest möglichst gleich, stromsparend,.

[mgolbs (Gast)]

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

[M. N. (Gast)]

ATmega328P bietet viel Speicher und rel. wenig Pins bei gutem Preis.

[Michi (Gast)]

Sollen wir jetzt für dich die parametrische Suche div. Distris anwerfen?

[Spess53 (Gast)]

Hi

>Dachte da z.B. an einen ATMEGA32L8

Wie wäre es mit einem ATMega168P oder 328P?

MfG Spess

[Peter D. (peda)]

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.

[Sprachlos (Gast)]

Peter Dannegger schrieb:
> Du solltest vielleicht nicht für jede Bitvariable long long verwenden,

Du solltest vielleicht nicht jedem Fragenden absolute Blödheit 
unterstellen.

[mgolbs (Gast)]

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

[Simon K. (simon)]

Die float Bibliothek frisst auch Speicher. Am Besten vermeidet man das 
einfach und verwendet Fixkommadarstellungen.

[Peter D. (peda)]

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?

[Frank K. (fchk)]

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

[mgolbs (Gast)]

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

[Peter D. (peda)]

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.

[mgolbs (Gast)]

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

[Spess53 (Gast)]

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

[Peter D. (peda)]

Das AVRStudio zeigt doch nach dem Build immer an, wieviel Flash und SRAM 
belegt werden.
Bzw. für den AVR-GCC macht das avr-size.exe.

[Oliver (Gast)]

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