Umstieg auf 32 bit Atmel?

Tobi schrieb:
> ich bearbeite gerade ein größeres Projekt und benötige hierfür einige
> floating point Operations.

Jeder MC, für den es einen C-Compiler gibt, kann float.
Ob der MC ein 4-, 8-, 16-, 32- oder 64-Bitter ist, spielt keine Geige.

Auch die meisten 32-Bitter haben keine FPU, sondern benutzen die 
Math-Lib des Compilers.

Beim AVR kostet die float Lib einmalig 1kB Flash.

Wenn Du eine FPU haben willst, musst Du etwas aus der AT32UC3C* Serie 
nehmen. Die anderen haben keine FPU.

Ansonsten stimme ich @greg zu: Atmel hat nicht die Finanzen, um zwei 32 
Bit Architekturen (ARM und AVR32) gleichermaßen zu unterstützen. AVR32 
wird nicht sofort vom Erdboden verschwinden, aber der Großteil des 
Entwicklungsaufwandes wird in die ARM-Linie fließen. Und die 
AVR32AP7000-Serie ist ja schon weg, und das hat so einige Leute ziemlich 
kalt erwischt.

fchk

Tobi schrieb:
> Wie viel float kann ich den einem 8 bitter ohne fpu zumuten?

10.000 FIPS sollten kein Problem sein.

Tobi schrieb:
> Kann ich den nur für atmel arm nutzen oder für alle?

Üblicher Weise gibt es zu jedem Tool ein Manual und darin eine Liste der 
unterstützten Targets.

Tobi schrieb:
> Vielleicht sollte ich doch gleich auf ARM umstellen.
> habe den Atmel ICE. Kann ich den nur für atmel arm nutzen oder für alle?

"Programming and debugging of all Atmel SAM ARM Cortex-M based MCUs on 
both SWD and JTAG interfaces"

Präziser, als Atmel es hier sagt, kannst Du es nicht haben.

Der obige Satz schließt zB die SAM A5 Controller aus, weil die keinen 
Cortex-M, sondern einen Cortex-A haben. Auch ein SAM9XE geht nicht, weil 
es ein ARM9 ist. Der Atmel ICE kann also nur eine Teilmenge der Atmel 
ARM-Controller bedienen.

fchk

Frank K. schrieb:
> Der Atmel ICE kann also nur eine Teilmenge der Atmel ARM-Controller
> bedienen.

Wobei das schätzungsweise nicht technisch bedingt ist, d. h. es könnte
auch passieren, dass Atmel das per Firmwareupgrade „aufbohrt“.  Dagegen
dürfte es ziemlich ausgeschlossen sein, dass sie das Debuggen von
Konkurrenzprodukten mit dem Tool auf diese Weise freischalten würden.

Tobi schrieb:
> Warum ist der avr32 tot?

Atmel hat mit den AVR32 den gleichen Schritt versucht wie früher mit den 
AVRs. Damals konnten sie 8051 Lizenzen einsparen, mit Erfolg. Dieses Mal 
wollten sie wohl ARM Lizenzen einsparen, mit deutlich weniger Erfolg.

Als Kunde sieht man nicht so schell ein, weshalb man sich mit der 
gesamten komplexen Umgebung, Hard- wie Software, an einen Hersteller 
binden soll, von dem man nicht weiss, ob es ihn oder diese Produkte in 2 
Jahren noch gibt. Wenn es reichlich Alternativen mit den 
Quasi-Standard-Cores von ARM gibt, die günstig verfügbar sind und dank 
weit skalierender Cores ein grosses Leistungsspektrum abdecken.

ARM hat auch manches richtig gemacht: Sie treten nicht mit eigener 
Hardware in Erscheinung, d.h. alle die ARM einsetzen sind in der 
gleichen Lage. Würde die Firma ARM von einem Hardware-Hersteller 
aufgekauft, würde sich die Situation auf lange Sicht vermutlich 
erheblich ändern.

http://www.eejournal.com/archives/articles/20120822-armchoice/

A. K. schrieb:
> Damals konnten sie 8051 Lizenzen einsparen, mit Erfolg.

Naja, und eine eher krückige und nicht mehr zeitgemäße Architektur
durch was Modernes ablösen.  Beim AVR32 dagegen ist es nun nicht gerade
so, dass der ARM als Architektur gleichermaßen krückig und altmodisch
gewesen wäre (auch wenn ich mich erinnere, dass zur AVR32-Motivation
damals hie und da ein paar eingesparte Takte noch mit vorgezeigt
wurden).  Blieben also nur die paar eingesparten Cents an ARM-Royalties,
die die Kunden aber offenbar nicht so sehr stören.

Tobi schrieb:
> Könnt ihr ein gutes dev Bord mit einem atmel arm empfehlen?  (Bis 100
> Euro )

Das hier vielleicht?

http://store.atmel.com/PartDetail.aspx?q=p:10500371

OK, dein ICE bräuchtest du dafür nicht einmal, aber das kannst du
ja sicher immer noch gebrauchen, wenn du dann den Spiel- und
Stöpsel-Status des Devboards verlässt und auf eigene Hardware gehst.

Tobi schrieb:
> Kann denn dieser embedded debugger das selbe wie mein ice?

Jein: meines Wissens kann er nur das Board selbst bedienen.  Du
kannst ihn also nicht abtrennen und als kompletten Ersatz für das
Atmel-ICE benutzen.  (Vermutlich allerdings als externen Debugger
an einem Board mit dem gleichen Prozessor, d. h. er ist auf einen
konkreten Prozessor mit dessen Device-ID gebunden.)

Tobi schrieb:
> Was haltet ihr vom arduino due als dev board?

Ich dachte, du wolltest auch 'ne FPU haben?

Tobi schrieb:
> Ist die Avr32 Familie z.B. der AT32UC3A3256 für floating
> point Berechnungen geeignet?

Jeder Prozessor kann Fliesskommarechnung durchführen. Die Frage ist 
immer nur wie schnell er dabei ist, denn manche haben dafür spezielle 
Hardware, andere verwenden Software und Hardware ist schneller.

Tobi schrieb:
> Hat der cortex m3 des arduino keine fpu ?

Der M4 hat, M3 nicht. Aber auch nur in 32-Bit. 64-Bit 
Fliesskommarechnung in Hardware findet sich im Controller-Umfeld 
deutlich seltener.

Das heisst aber nicht, dass die M3 Cores dabei langsam sind. Nur eben 
langsamer als die M4 Cores.

A. K. schrieb:
> Tobi schrieb:
>> Warum ist der avr32 tot?
>
> Atmel hat mit den AVR32 den gleichen Schritt versucht wie früher mit den
> AVRs. Damals konnten sie 8051 Lizenzen einsparen, mit Erfolg. Dieses Mal
> wollten sie wohl ARM Lizenzen einsparen, mit deutlich weniger Erfolg.

Das klingt mir nach einem Gerücht. Bis wann waren denn bitte 8051 
Lizenzen notwendig? Die Architektur war schon Ende der 90er, als die AVR 
auf den Markt kamen, steinalt.

Tobi schrieb:
> Um vieviel schneller ist der cortex bei float berechnungen Im gegensatz
> zum avr?

Vielleicht sagst du ja erstmal, welche Geschwindigkeit du überhaupt
so brauchst?  Brauchst du auch 64-bit-Gleitkomma?

Ich benutze auch auf 8-bit-AVR durchaus Gleitkommarechnungen, so extrem
langsam sind sie nun auch nicht.

Einen ARM wiederum kann man ganz verschieden takten, je nach Umgebung,
verfügbarem Energievorrat etc.  Wenn er schnell getaktet wird, muss
man fürs Flash-Lesen wiederum wait states reinwerfen, d. h. der
wirkliche Vorteil würde vor allem dann entstehen, wenn man Code aus
dem RAM ausführen kann.

Tobi schrieb:
> Um vieviel schneller ist der cortex bei float berechnungen Im gegensatz
> zum avr?

Wenn es auf Geschwindigkeit ankommt, würde ich mir erst einmal die Frage 
stellen, ob es überhaupt floating point sein muss. Die meisten 
rechenintensiven DSP-Anwendungen benötigen den Dynamikbereich überhaupt 
nicht.

Tim    schrieb:
> Die Architektur war schon Ende der 90er, als die AVR
> auf den Markt kamen, steinalt.

Das schenkt sich aus heutiger Sicht nicht viel.
8051 ist von 1980, ARM von 1985. ;-)

A. K. schrieb:

> Das schenkt sich aus heutiger Sicht nicht viel.
> 8051 ist von 1980, ARM von 1985. ;-)

Man könnte aber auch argumentieren, dass 8051 bereits zur Zeit seines
Designs veraltet war, während Acorn der Zeit voraus war …

A. K. schrieb:
> Tim    schrieb:
>> Die Architektur war schon Ende der 90er, als die AVR
>> auf den Markt kamen, steinalt.
>
> Das schenkt sich aus heutiger Sicht nicht viel.
> 8051 ist von 1980, ARM von 1985. ;-)

Du zitierst hier etwas aus dem Kontext. Es ging darum, dass der 8051 
wahrscheinlich schon 1995 lizenzfrei war und deswegen geringere 
Lizenzgebühren kein Argument für den AVR war.

Tim    schrieb:
> Du zitierst hier etwas aus dem Kontext. Es ging darum, dass der 8051
> wahrscheinlich schon 1995 lizenzfrei war

Weshalb? Zudem musst man wohl zwischen Architektur und Implementierung 
unterscheiden. Weshalb sollte beispielsweise der Original-Core von Intel 
heute lizenzfrei sein? Patente wiederum laufen erst nach 20 Jahren ab.

Möglicherweise sind sogar die Namen eigentlich identischer Befehle 
relevant. Es wird einen Grund gegeben haben, weshalb sich Zilog und NEC 
in der Doku ihrer Nachbauten grosse Mühe gaben, gleichen Befehlen andere 
Namen zu geben.

Bastler schrieb:
> Naja, wer schon mal Mainframes in ASM programmiert hat, dem kommen viel
> ARM Details bekannt vor.

Welche konkret hast Du da im Auge? Mal abgesehen von den 32 Bits 
Datenbreite und dem 12 Bit Offset. So arg gross erscheint mir die 
Ähnlichkeit zwischen IBM 360 und ARM nämlich nicht, auch nicht mit CDC 
6600 oder TR440.

c-hater schrieb:
> Tatsächlich gibt nur sehr, sehr wenige Anwendungen, die wirklich quasi
> zwingend float benötigen.

Stimmt. Allerdings gibt es auch viele Anwendungen, bei denen es keinen 
Grund gibt, zwanghaft "float" zu vermeiden, auch wenn der Prozessor 
damit nicht direkt umgehen kann.

Ausser natürlich man steht auf Assembler-Programmierung. ;-)

Tobi schrieb:
> Möchte ein integral berechnen? Und wenn nur gerundete werte verwende,
> läuft es mir schnell davon.

Ist Dir bewusst, dass ein float nur 23 Bit Genauigkeit hat? (Double 
natürlich mehr) Wenn Du Probleme mit Rundungsfehlern hast, müsstest Du 
Dir evtl. mehr Gedanken über Deinen Algorithmus machen.

A. K. schrieb:
> Stimmt. Allerdings gibt es auch viele Anwendungen, bei denen es keinen
> Grund gibt, zwanghaft "float" zu vermeiden, auch wenn der Prozessor
> damit nicht direkt umgehen kann.

Ein Grund ist auf jeden Fall, dass eine Fehlerrechnung für int deutlich 
einfacher als für floating point ist. Man kann leichter abschätzen wo 
die Grenzen sind.

Tobi schrieb:
> Möchte ein integral berechnen? Und wenn nur gerundete werte verwende,
> läuft es mir schnell davon.

Die Frage bei Soft- oder Hardware ist nicht, was man berechnen will, 
sondern wie oft. Also wieviele Fliesskomma-Operationen pro Sekunde circa 
anfallen.

Tim    schrieb:
> Ein Grund ist auf jeden Fall, dass eine Fehlerrechnung für int deutlich
> einfacher als für floating point ist.

Ein Grund dagegen ist, dass man bei int ständig im Blick behalten
muss, dass die Dinger nicht während der Rechnung versehentlich
überlaufen.

Ein weiterer Grund dagegen ist, dass sich Mathematik nun mal einfacher
mit Gleitkomma erledigen lässt.  Wenn ich Messwerte habe, die sowieso
bloß auf drei Stellen genau sind, habe ich bis zu den sechs oder sieben
Stellen Genauigkeit, die ein 32-bit-Float bietet, so viel Reserve, dass
ich mir oft genug einfach nur gar keine Gedanken um die Fehlerrechnung
machen muss.

>Könnt ihr ein gutes dev Bord mit einem atmel arm empfehlen?  (Bis 100
Euro)

Wenn der Preis des Dev Boardes massgebend sind, solltest du das Ganze eh 
vergessen.


>Möchte ein integral berechnen? Und wenn nur gerundete werte verwende,
läuft es mir schnell davon.

Nee. Integer bedeutet in diesem Kontext Fixed Point Real. Dh ein 
Integrator laeuft nicht davon. Ein dynamischer Bereich von 2E9 sollte 
gnuegen.


Worum geht es denn ? Ein Temperaturregler mit PID, der "hochgenau" sein 
muss?

Klar, so allmählich kommt das. Und irgendwann steckt dann im neuesten 
SO-8 µC ein 64-Bit-Controller mit Vektor-FPU drin. ;-)

Meine Güte, dieses Assemblergesabbel ist doch wirklich sinnlos.

c-hater schrieb:
>
> Asm rules.

C-Hater, wo sind denn Deine ganzen Cortex Assemblerprogramme? Zeig sie 
uns doch 'mal :)

Eine durchoptimierte IEEE754 lib wäre sicherlich interessant. Die 
könnten wir dann aus c heraus nutzen.

A. K. schrieb:
> Damals konnten sie 8051 Lizenzen einsparen

Und warum stellt dann Atmel auch 8051 her und entwickelt sogar neue?

Im Gegenteil, der AT89C2051 war für mich überhaupt erst der Grund, was 
bei Atmel zu kaufen. Das war 1993 der erste preiswerte Flash-MC 
weltweit.

Den AT90S1200 habe ich dann probiert und war bitter enttäuscht (schwerer 
Power-On Bug). Erst ab ATmega8 waren die AVRs auch wirklich zuverlässig 
benutzbar.

Den großen Erfolg der AVRs schreibe ich hauptsächlich dem AVR-GCC zu, 
der schnell brauchbaren Code erzeugte.
Beim 8051 wurde das leider versäumt und der Keil C51 Compiler ist 
preislich weit jenseits der Bastlergrenzen.

Peter Dannegger schrieb:
> Den großen Erfolg der AVRs schreibe ich hauptsächlich dem AVR-GCC zu,
> der schnell brauchbaren Code erzeugte.

Eher nicht.  Das Ding wurde von Atmel anfangs völlig ignoriert.  Die
haben lange Zeit auf die Kooperation mit IAR gebaut und nur den
gepusht; alle Codebeispiele von Atmel haben IAR-Syntax.

Peter Dannegger schrieb:
> Und warum stellt dann Atmel auch 8051 her und entwickelt sogar neue?

Man kann das Eine tun ohne das Andere zu lassen.

Jörg Wunsch schrieb:
>> Den großen Erfolg der AVRs schreibe ich hauptsächlich dem AVR-GCC zu,
>> der schnell brauchbaren Code erzeugte.
>
> Eher nicht.  Das Ding wurde von Atmel anfangs völlig ignoriert.

GCC wird schon ziemlich wesentlich zumindest für die Bastler gewesen 
sein. Nur hatte Atmel das nicht auf der Rechnung.

A. K. schrieb:
> GCC wird schon ziemlich wesentlich zumindest für die Bastler gewesen
> sein. Nur hatte Atmel das nicht auf der Rechnung.

So isses.

Später jedoch hat dann selbst die Industrie teilweise auf GCC
geschwenkt.  Wenn man automatisierte Tests fahren will, dann ist
die Nasenlänge, die der IAR zuweilen besser ist, plötzlich im Vergleich
zu den Kosten für vielleicht 10 Lizenzen (weil man 10fach parallel
testen möchte) doch eher untergeordnet.

Beim ARM stellt sich die Frage zum Glück gleich gar nicht mehr.

Christian J. schrieb:
> Hat sie nicht. GCC ist ein Produkt wo niemand die Haftung übernimmt und
> niemand verantwortlich gemacht werden kann. GCC zu verwenden heisst,
> sich auf "Hobbyprogrammierer" zu verlassen. IAR und KEIL haben in allen
> mir bekannten Firmen die Nase vorn, GCC wurde dagegen "angemahnt" dass
> das

Troll... Dann besteht also ca. 95% unserer IT-Infrastruktur aus 
unzuverlässigem Hobbykram.

> die Zertifizierung "Verwendung von Produkten aus vertrauenswürdigen
> Quellen" kosten kann. Spätetens seit dem SSL Hartbeat Bug sind einige
> aufgewacht, dass diese Art Software aus nicht überprüfbaren Quellen
> stammt bzw aus Quellen die kein Qualitätsmanagement haben. Einmal sudo
> apt-get upgrade und schon kannst Du bei Sicherheitsprodukten deine
> Akkreditierung in den Wind schreiben.

Wie groß ist denn der Marktanteil an "Sicherheitsprodukten"? Das bei 
nach ASIL zertifizierten Produkten jede Codezeile per FMEA abgesegnet 
und anschließend im Vier-Augen Prinzip händisch compiliert wird, kann ja 
sein, für die meisten Produkte ist eine Haftbarkeit des 
Compilterherstellers aber ziemlich irrelevant.

Garantieren IAR und KEIL so etwas überhaupt? Oder wird eine Haftung in 
den Geschäftsbedingungen ausgeschlossen?

Christian J. schrieb:
>> Später jedoch hat dann selbst die Industrie teilweise auf GCC
>> geschwenkt.
>
> Hat sie nicht.

Tss tss.  Warst du mal bei Atmel angestellt oder ich? ;-)

Nachtrag: Was m.E. eher für kommerzielle Compiler spricht, ist der 
Service. Bei AVR-GCC ist man bei Bugs ja leider häufig auf Selbsthilfe 
angewiesen. Siehe z.B. ATtiny10 unterstützung.

Tim    schrieb:
> Nachtrag: Was m.E. eher für kommerzielle Compiler spricht, ist der
> Service. Bei AVR-GCC ist man bei Bugs ja leider häufig auf Selbsthilfe
> angewiesen. Siehe z.B. ATtiny10 unterstützung.

Den halbherzigen Support dafür hat Atmel allerdings selbst verbockt.

Da sie wissen, dass das ringsum buggy ist, haben sie es auch bislang
noch nicht in Richtung FSF weitergeschoben.

Christian J. schrieb:
> Nee... aber bei dem Verein mit den 3 Buchstaben :-)

ARM?
BND?
FSF?

Je mehr Personen aus verschiedensten Kreisen das Recht haben, im 
offiziellen Quellcode eines Produktes rumzufroschen, desto leichter ist 
es, dort Unsinn anzustellen. Ob nun Vorsatz, Dummheit oder Mut zum 
Risiko - ist ja nicht sein Geld. Wobei das aber m.E. bei GCC nicht 
jedem zusteht. Es kann aber jeder Einblick nehmen und Änderungen 
vorschlagen.

Umgekehrt gilt das freilich auch: Je mehr Leute Einblick in Quellcode 
haben, desto wahrscheinlicher ist es, dass Probleme identifizierbar sind 
und Lösungen gefunden werden, bevor sie zum Himmel stinken. Und dass es 
schnell Lösungen gibt, wenn es zum Himmel stinkt.

Welcher dieser beiden Effekte überwiegt lässt sich schwer 
verallgemeinern. Mal trifft dies zu, mal jenes.

Kommerzielle Closed Source Produkte können eine grössere Stabilität 
aufweisen, weil aus Kostengründen nur geändert wird, wenn man meint, es 
könne sich finanziell lohnen. Vorausgesetzt der Hersteller bringt die 
neue Version wenn sie fertig ist, und nicht, wie öfter der Fall, weil 
jemand gerne mal wieder mit schwarzer statt roter Tinte schreiben will.

Umgekehrt schliesst eine solche konservative Haltung auch Bugs mit ein. 
Auch die werden erst geändert, wenn es sich zu lohnen droht oder ein 
Entwickler mangels Wichtigerem sonst bloss in der Nase bohrt. Was 
bedeutet, dass bekannte Bugs auch lange drin bleiben können, wenn es 
keine Showstopper sind.

Christian J. schrieb:
> Einmal sudo
> apt-get upgrade und schon kannst Du bei Sicherheitsprodukten deine
> Akkreditierung in den Wind schreiben.

Ich persönlich kenne keinen, der Sicherheitsanwendungen programmiert.
Das Gro wird nur normale Anwendungen programmieren (Tamagotchi, 
Fernseher, Waschmaschinen usw.) und da ist es wurscht, welcher Compiler 
verwendet wird. Billig muß es sein, schnell muß es gehen und 
einigermaßen funktionieren.

Es sind ja nicht nur die Kosten für die Lizenz, sondern der tägliche 
Ärger mit Lizenzserverabstürzen usw.
Was bei mir die Kollegen mit Altium schon geflucht haben, wenn sie 
plötzlich nicht mehr abspeichern konnten und sie nur hämisch ein 
Alert-Button angrinste.

A. K. schrieb:
> Umgekehrt schliesst eine solche konservative Haltung auch Bugs mit ein.
> Auch die werden erst geändert, wenn es sich zu lohnen droht oder ein
> Entwickler mangels Wichtigerem sonst bloss in der Nase bohrt. Was
> bedeutet, dass bekannte Bugs auch lange drin bleiben können, wenn es
> keine Showstopper sind.

Einmal das - das andere ist, dass kommerzieller Code auch ein ziemlicher 
Wildwuchs sein kann. Auch da wird oft und viel gepfuscht und Krücken 
verwendet - sieht ja keiner. Alles schon erlebt.

Frei nach dem Motto:
"Wie gut, dass die Konkurrenz unsere Quellcodes nicht kennt - das würde 
sie um Jahre zurückwerfen!"

:-)