Hallo ich bearbeite gerade ein größeres Projekt und benötige hierfür einige floating point Operations. Bis her habe ich mich nur mit 8 bittern beschäftigt. Ist die Avr32 Familie z.B. der AT32UC3A3256 für floating point Berechnungen geeignet? Danke. PS. Hat schon wer mit den avr32 gearbeitet? Wie verhält es sich mit der Einarbeitungezeigt?
AVR32 ist ziemlich tot. Empfehlenswert ist eher ein ARM-basierter Mikrocontroller. Sehr verbreitet und kostengünstig ist hier STM32, aber auch von Atmel gibt es da was.
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.
:
Bearbeitet durch User
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.
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?
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/
:
Bearbeitet durch User
Könnt ihr ein gutes dev Bord mit einem atmel arm empfehlen? (Bis 100 Euro )
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.
Angenommen ich habe einen avr (mega 16) und einen cortex m3 jexeil ohne fpu. Um vieviel schneller ist der cortex bei float berechnungen Im gegensatz zum avr?
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.
:
Bearbeitet durch Moderator
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.
Möchte ein integral berechnen? Und wenn nur gerundete werte verwende, läuft es mir schnell davon.
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. ;-)
Ich denke, zur Embedded-World werden die Cortex-M7 vorgestellt, dann werden sowieso wieder die Karten neu gemischt werden. Ich hoffe da auf nen schnuckligen 64 Pinner mit 2 CANs von Atmel aber M7 ist eventuell zu dick für sowas.
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.
Tobi schrieb: > ich bearbeite gerade ein größeres Projekt und benötige hierfür einige > floating point Operations. Aller Wahrscheinlichkeit nach glaubst du nur, diese zu benötigen. Tatsächlich gibt nur sehr, sehr wenige Anwendungen, die wirklich quasi zwingend float benötigen. Was es allerdings gibt, ist eine riesige Menge von Anwendungen, die sich mit weniger Vorüberlegungen und deshalb (zumindest scheinbar) schneller und einfacher umsetzen lassen, wenn man float benutzt. Aber dabei kann man auch ganz gewaltig auf die Fresse fallen, float ist genauso tückisch wie int, wenn man die Vorüberlegungen einspart, die Tücken sind nur andere, aber sie sind deshalb nicht weniger tückisch, eher sogar mehr... Deshalb solltest du als Erstes unbedingt mal erklären, warum du glaubst, float-Operationen zu benötigen.
Naja, wer schon mal Mainframes in ASM programmiert hat, dem kommen viel ARM Details bekannt vor. Und die wurden designed, als ich noch in den Windeln lag. Anfang der 60er!
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?
:
Bearbeitet durch User
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. > > Ausser natürlich man steht auf Assembler-Programmierung. ;-) Wieso sollte Assembler da ein Hinderungsgrund sein? Auch bei der Behandlung von float ist der Assembler des Zielsystems natürlich immer zumindest potentiell effizienter als jede denkbare höhere Sprache. Das gilt übrigens sogar ziemlich unabhängig davon, ob es auf dem Zielsystem eine Hardwareunterstützung für float-Typen gibt oder die Sache in einer Int-ALU abgehandelt werden muß. Was man natürlich nicht zuletzt am Besten und Überzeugendsten daran sehen kann, daß die float-Libs der weniger effizienten Sprachen zu einem guten Teil dann eben doch wieder in Assembler geschrieben sind. Und zwar sowohl die, die vorhandene FP-Hardware nutzen als auch die, die FP in einer Int-ALU emulieren. ;o) Asm rules.
A. K. schrieb: > Der M4 hat, M3 nicht. Aber auch nur in 32-Bit. 64-Bit > Fliesskommarechnung in Hardware findet sich im Controller-Umfeld > deutlich seltener. Zum Cortex-M7 bietet ARM auch eine 64Bit-Floatingpoint Einheit an (FPv5-SP). Der ein oder andere Hersteller wird die sicherlich in einigen Controllern implementieren.
Klar, so allmählich kommt das. Und irgendwann steckt dann im neuesten SO-8 µC ein 64-Bit-Controller mit Vektor-FPU drin. ;-)
Und warum nicht das was ich mir jetzt bestellt habe? http://www.ebay.de/itm/STM32F4-DISCOVERY-STM32F429-TFT-LCD-STM32-ARM-Cortex-M4-Development-Board-/161177600716?pt=Bauteile&hash=item2586ef02cc Ist ARM drin (Cortex M4, 150 Mhz, 1MB Flash, 128kb RAM), 1800 Seiten Manual für viele Wochen Lesefreude .... 14 Timer, 3 Uarts, 2 SPI, voller Support an IDE, Libs, HAL blablablab.... und eine echte FPU, die von den Libs supported wird :-) Und das Ganze fürn Appel und nen Ei!
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.
@Tobi: Stellt sich nur die Frage, ob du beruflich oder hobbymaesssig umsteigen willst/musst? Die 8-Zylinder sind ziemlich easy. Da stellst du die Taktfrequenz mit einem Register ein und einem Quarz und fertig. Bei 32 Bit wird das Ganze schon interessanter, die haben PLL, Peripheriebus, Mult und DIV Register , noch eine extra Takt-Unit für die Uarts und ein Timer ist kein 8 Bit Register mehr mit einem Capture/Compare sondern ein Gerät, bei dem Du erst 100 Schalter drehen musst, bevor der Motor läuft. Du schreibst nicht in einen port rein sondern hast einen zum Lesen, einen zum Schreiben, du hast Fast-IO und Slow IO.... der Codeaufand explodiert dir um eines um selbst einfache Dinge zu tun. Für relaisgeklapper und LED an/aus deutlich überzüchtet aber um mit Grafik TCP/IP, USB und SD Karten zu hantieren genau das richtige, vorausgesetzt du hast die Libs bei der Hand, denn sonst scheiterst du schon an der enormen Komplexität der USB Hardware oder des MMC/SD Interfaces.
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: > Die > haben lange Zeit auf die Kooperation mit IAR gebaut und nur den > gepusht; alle Codebeispiele von Atmel haben IAR-Syntax. Für Lottogewinner ist IAR für AVR immer noch eine gute Wahl. 64-Bit double sind einfach verwendbar und werden schnell gerechnet. Irgendwie habe ich den Eindruck, die STM32F4-Fraktion ist noch in den Winterferien (zusammen mit Moby) ;-)
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.
Jörg Wunsch schrieb: > Später jedoch hat dann selbst die Industrie teilweise auf GCC > geschwenkt. 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 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.
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.
Jörg Wunsch schrieb: > Tss tss. Warst du mal bei Atmel angestellt oder ich? ;-) Nee... aber bei dem Verein mit den 3 Buchstaben :-)
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.
:
Bearbeitet durch User
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.
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 > 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. Ach was, mal wieder der typische Anti-Open-Source-FUD. Praktisch alle namenhaften Open-Source-Projekte werden von Firmen betreut. "Hobbyprogrammierer" sind recht selten und haben zumeist wenig Einfluss. Die Qualität schwankt natürlich, wie überall sonst. Allerdings sieht kommerzielle Closed-Source-Software häufig obrflächlich nur deshalb besser aus, weil man nicht sehen kann, was für ein Misthaufen der Kram eventuell ist und die Hersteller natürlich vollmundige Versprechen abgeben, obwohl sie die u.U. gar nicht halten können. Ob die Quellen offengelegt sind oder nicht hat i.A. sehr wenig mit der Qualität oder Sicherheit der Software zu tun.
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!" :-)
:
Bearbeitet durch Moderator
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.