Hallo, im Thread "ATxMega Stick" im Markt Forum behauptet Max (Gast) am 04.11.2011 23:34 : "Aber so weit wird es wohl nicht kommen, da ja bereits der ATxMega eine Todgeburt geworden ist und die Zukunft von Atmel nicht gerade rosig ausschaut." ist das eine persönlich Einschätzung von Max oder steht mehr dahinter ? Was soll den bei Atmel los sein das es (angeblich ?)schlecht um deren Zukunft aussieht ? Ist die Masse der Hobbyanwender auf den falschen Zug aufgesprungen ? Die AVR sind doch nicht schlecht und ausreichend für sehr viele Anwendungen. Und warum soll der ATxMega ein Todgeburt sein, wird er von der Industrie nicht angenommen und wenn ja, warum nicht ? Für den Hobbybereich wäre es auf jeden Fall sehr Schade wenn Atmel vom Markt verschwinden würde und die AVR (8Bit) Linie nicht von anderen Anbietern weitergeführt wird. Da es sich um µC handelt denke ich das hier das richtige Forum ist, leider ist es im Offtopicforum nur nach Anmeldung möglich einen Beitrag zu schreiben. mfg "AVR User"
:
Verschoben durch Moderator
Naja, glaub eher, dass das völlig aus der Luft gegriffen ist. Den XMega braucht eher sogut wie niemand (STM32 ist da in so gut wie jedem Fall die bessere Alternative), aus demselben Grund dürfte der AVR32 eine Totgeburt sein, die Mega- und Tiny-AVR sind inzwischen gut aufgestellt, mir persönlich sind sie inzwischen zu teuer geworden, bei grösseren Serien habe ich PIC umgestellt. Atmels Hauptgeschäft dürften aber nachwievor das Flashbausteine in diversen Varianten sein. Müsste man mal einen konkreten Geschäftsbericht durchblättern. Ich mag die AVRs nach wie vor. Sollte es sie nicht mehr geben, geht die Welt nicht unter.
AVR User schrieb im Beitrag #2409356: > "Aber so weit wird es wohl nicht kommen, da ja bereits der ATxMega > eine Todgeburt geworden ist und die Zukunft von Atmel nicht gerade rosig > ausschaut." > > ist das eine persönlich Einschätzung von Max oder steht mehr dahinter ? Zum Teil ist es natürlich die persönliche Meinung des Schreibers. Aber es gibt auch Anzeichen: > Was soll den bei Atmel los sein das es (angeblich ?)schlecht um deren > Zukunft aussieht ? 1. Sie haben alle ihre Halbleiterfabriken bis auf die in Colorado verkauft und lassen fremdfertigen. Microchip auf der anderen Seite fertigt fast alles in eigenen Fabriken und kann liefern. 2. Sie haben definitiv Probleme, entwickelte Produkte tatsächlich auf den Markt zu bringen. Vieles von dem, was auf ihrer Webseite steht, kannst Du immer noch nicht kaufen. 3. Sie haben nicht genug Manpower, um alle CPU-Linien zu supporten. Diesem Mangel ist beispielsweise der AVR32AP7000 und seine Nachfolger zum Opfer gefallen. > Die AVR sind doch nicht schlecht und ausreichend für sehr viele > Anwendungen. Darauf kommt es nicht an. > Und warum soll der ATxMega ein Todgeburt sein, wird er von der Industrie > nicht angenommen und wenn ja, warum nicht ? Es ist ein Nischenprodukt. Für den gleichen Preis gibts auch schon 32 Bit, z.B. von NXP, oder die 16 bittigen dsPIC33, die teilweise wesentlich schneller sind. > Für den Hobbybereich wäre es auf jeden Fall sehr Schade wenn Atmel vom > Markt verschwinden würde und die AVR (8Bit) Linie nicht von anderen > Anbietern weitergeführt wird. Wer das Prinzip kennt und nicht einfach nur abschreibt, wird sich auch auf anderen Prozessoren zurechtfinden. fchk
Hi, das mit der ATxMega Totgeburt (und Fehlgeburt) kann ich nur bestätigen. Die ATMEL Distris glauben selbst nicht mehr an den Erfolg. Ich war vor 1-2 Jahren mit einem Kollegen auf einer Infoveranstaltung von ATMEL. Mein Kollege war damals noch ein großer Fan des ATxMega. Bei dieser Veranstaltung wurden XMEGA Boards verschenkt und in einem kurzen Workshop eingeführt. Da zeigte sich dann auch schon der Nachteil: teuerer als ein Cortex M3, weniger Rechenleistung, aber genauso aufwendig zu programmieren. In der gleichen Veranstaltung wurden die damals neuen Cortex M3 von ATMEL vorgestellt. Am Ende des Tages waren auch die größten XMEGA Fans ernüchtert. Mein Kollege beschäftigt sich seitdem übrigens mit ARM Controllern ;-) Wir setzen auf Arbeit AVR im 6 stelliger Stückzahl ein. Selbst bei diesen Größenordnungen ist ein Cortex M0 von NXP schon günstiger zu haben !!!! Das wird wohl in den nächsten Jahren den Todesstoss für die AVR, xMEGA und AVR32 bedeuten (Für ein paar Bastler wird ATMEL die wohl nicht mehr herstellen).
Zu den XMega faellt mir auch immer die fehlende 5-Volt Toleranz der IO Pins auf, und das keine CAN faehigen XMegas geplant sind...
A(R)M verzweifeln schrieb: > Das wird wohl in den nächsten Jahren den Todesstoss für die > AVR, xMEGA und AVR32 bedeuten Halbwissen -> Nixwissen.
Frank K. schrieb: > 1. Sie haben alle ihre Halbleiterfabriken bis auf die in Colorado > verkauft und lassen fremdfertigen. Microchip auf der anderen Seite > fertigt fast alles in eigenen Fabriken und kann liefern. Wär nicht der erste Fabless-Hersteller.
Knut Ballhause schrieb: > Halbwissen -> Nixwissen. Das die Cortex M0 preiswerter sind ist Fakt und kein Halbwissen!
Der Preis ist nicht alles! Welche Firma durch welche Aktion gewinnt oder verliert, weisst aber selbst Du nicht, noch Dein Distributor. Alles nur Gelaber am Sonntag Nachmittag!
AVR User schrieb im Beitrag #2409356: > Und warum soll der ATxMega ein Todgeburt sein, wird er von der Industrie > nicht angenommen und wenn ja, warum nicht ? Wenn Max (Gast) das schreibt, stimmt das auch: > "Aber so weit wird es wohl nicht kommen, da ja bereits der ATxMega > eine Todgeburt geworden ist und die Zukunft von Atmel nicht gerade rosig > ausschaut." Und er ist ja auch nicht der einzige. @Mods: Bitte diesen Thread ganz schnell löschen, bevor die Börse davon Wind bekommt und im Sog der drohenden Atmel-Pleite die gesamte Chipindustrie in den Abgrund gerissen wird. mfg.
Wie viele Fabs hat nochmal ARM? ;-) Wenn allerdings Konkurrenzprodukte das gleiche leisten und günstiger sind, stellt sich schon die Frage warum man gerade Atmels einsetzen sollte. Von Hobby-Bastlern allein kann wohl keine Mikroprozessorfirma auf Dauer leben.
Mark Brandis schrieb: > Wie viele Fabs hat nochmal ARM? ;-) ARMs Geschäft ist es auch nicht zu produzieren, sondern zu entwickeln, daher brauchen sie auch keine, bei Atmel sieht das dagegen anders aus. Ich denke über kurz oder lang macht Atmel einen Fehler, die Tiny und Megaserie vom XMega ersetzen zu lassen, aber mal sehen.
Thomas Eckmann schrieb: > Bitte diesen Thread ganz schnell löschen, bevor die Börse davon Wind > bekommt und im Sog der drohenden Atmel-Pleite die gesamte Chipindustrie > in den Abgrund gerissen wird. ...na wenn schon davon die Halbleiterbranche in Abgrund stürzt ... naja obwohl... Gab es nicht erst vor einiger Zeit die Meldung "Microchip kauft Atmel" - da ist ja wohl auch keine Panik ausgebrochen.
Knut Ballhause schrieb: > Der Preis ist nicht alles! Welche Firma durch welche Aktion gewinnt oder > verliert, weisst aber selbst Du nicht, noch Dein Distributor. Mark Brandis schrieb: > Wenn allerdings Konkurrenzprodukte das gleiche leisten und günstiger > sind, stellt sich schon die Frage warum man gerade Atmels einsetzen > sollte. Das Problem: Wir als Otto Normaluser kennen nur die Preise/Lieferprogramme, die die normalen Versandhändler/Elektronikapotheken offerieren. Wir solten immer davon ausgehen, daß Großabnehmer mit Stückzahlen im 5, 6, oder gar 7-stelligen Bereich ganz andere Konditionen bekommen. Das gilt auch für die Verfügbarkeit. Reichelt ist sicherlich nicht der Maßstab, was die echte Lieferbarkeit ab Fab anbelangt, auch wenn jetzt ein bekannter Distributor dahinter steht. Eine echte Zustandsbeschreibung einer amerikanischen AG erhält man sowieso nur, wenn man die 8K- und 10K-Forms liest, die bei der SEC von jeder US-AG zu hinterlegen sind. Selbige sind im Internet abrufbar. Knut Ballhause schrieb: >Alles nur Gelaber am Sonntag Nachmittag! Korrekt. nur weil ein paar Serien nicht so laufen, wie erhofft, heißt das nicht, daß es der Firma schlecht geht. Und laufen diese Serien wirklich schlecht? Wir wissen es nicht. Gruß Jadeclaw.
H.joachim Seifert schrieb: > Naja, glaub eher, dass das völlig aus der Luft gegriffen ist. > Den XMega braucht eher sogut wie niemand (STM32 ist da in so gut wie > jedem Fall die bessere Alternative), aus demselben Grund dürfte der > AVR32 eine Totgeburt sein, die Mega- und Tiny-AVR sind inzwischen gut > aufgestellt, mir persönlich sind sie inzwischen zu teuer geworden, bei > grösseren Serien habe ich PIC umgestellt. AVR32 spielt in einer Liga mit Cortex-XX, RX oder MIPS M4K etc. und hat einige Vorteile (z.B. die geringere Stromaufnahme oder das Event-System). Zudem sind die UC3C auch AEC-Q100 grade 1 (-40 °C - 125 °C) qualifiziert (so was macht eine Firma nicht zum Spaß). Microchip hat bzw. wird in Zukunft einige Probleme haben: Hohe Stromaufnahme, kein richtiger ext. Speicher/Datenbus, Software (Libs, kein offizieller C++ Support, Architektur (nicht die PIC32, aber die anderen Baureihen, auch wenn die PIC24, dsPICs ein Schritt in die richtige Richtung waren)). D.h. hier: Zukünftig überhaupt keine PICs der 8-Bit und 16-Bit-Baureihen, PIC32 nur wenn sie signifikante Vorteile gegenüber AVR32, Cortex-M/R und RX in der konkreten Anwendung hätten. (Microchip hat allerdings noch einen Trumpf: Man bekommt dort auch fast die gesamte Peripherie) > Atmels Hauptgeschäft dürften aber nachwievor das Flashbausteine in > diversen Varianten sein. Nein, Microcontroller 892 Mio USD, Non volatile 277 Mio USD, RF/automotive 188 Mio, ASIC 286 Mio USD http://files.shareholder.com/downloads/ATML/1489548738x0xS950123-11-20486/872448/filing.pdf Microchip: Microcontroller 1014 Mio USD, Memory 221 Mio USD, Analog/Interface 178 Mio USD http://www.microchip.com/sec/filings/FY11/Form%2010-K%20filed%2005-31-2011.pdf
Ich hab grad eine neue Dose Popcorn aufgemacht. Wie wäre es wenn man das Mikrocontroller-Logo mal abändert und ein STM oder zumindest ARM rein schreibt. Das ewige AVR nervt langsam.
Für's Hobby sind die AVRs schon recht gut geeignet: viel Auswahl in DIP, guter freier C Compiler, weiter Spannungsbereich, kräftige Treiber, relativ einfache und einheitliche Architektur, gut erhältlich. Die xMegas passen da nicht ganz zu. Ist halt ein Versuch die Leistung etwas zu steigern ohne gleich was ganz neues zu machen. Fürs Hobby sind die aber eher weniger Interessant. Das Atmel jetzt vieles extern fertigen lässt hat auch den Vorteil, dass im Falle eine Falles die AVR Reihe relativ leicht weitergeführt werden kann unabhängig von Atmel. Ist zwar noch keine "second source", aber doch schon eine gewisse Sicherheit für die Anwender.
Ulrich schrieb: > Das Atmel jetzt vieles extern fertigen lässt hat auch den Vorteil, dass > im Falle eine Falles die AVR Reihe relativ leicht weitergeführt werden > kann unabhängig von Atmel. Eher nein. Patente und Urheberrecht verhindern dies zuverlässig. Und das externe Auftragsfertigung ein Produkt nicht in seinem Bestand sichert, durften Maxim-Kunden vor einigen Jahren erleben. Der MAX038 flog aus dem Programm, weil der Auftragsfertiger nicht mehr wollte. Und eine neue Line bei einer anderen Foundry zu etablieren, erschien Maxim wohl nicht lohnenswert genug. Bei den aktuellen AVR-8bit-Lines sehe ich jedoch kein Risiko, dafür verkaufen sich die Teile zu gut. ( Was Atmel im 10-K auch bestätigt. ) H.joachim Seifert schrieb: > Den XMega braucht eher sogut wie niemand Ich sage hier mal, die XMegas haben eine spezielle Zielrichtung: Weiternutzen der AVR-8Bit-Developmentinfrastruktur. Software gibt es für lau, Programmiergeräte/JTAG-Adapter werden mit einem Firmware-Update fitgemacht und da sich am Kern und vielen Peripherieelementen nur wenig geändert hat, ist auch die Einarbeitszeit recht kurz. So lassen sich vorhandene Konzepte kostengünstig upgraden. Vergiß nicht den Kostenvorteil, wenn gelerntes Wissen weiterverwendet werden kann. Gruß Jadeclaw.
H.joachim Seifert schrieb: > (STM32 ist da in so gut wie > jedem Fall die bessere Alternative) Wie viel Strom braucht der im Schlaf, wenn du auch die Daten noch erhalten willst? Nur mal so … kleiner (in den Strukturen) ist zwar billiger, aber nicht in jeder Hinsicht besser. Das dürfte der wesentliche Grund sein, warum es eben neben den diversen Cortex-M3s auch noch einen nicht zu kleinen Markt für 8/16-bit-MCUs gibt. Kann sich noch jemand daran erinnern, dass Microchip vor ein paar Jahren lauthals Pläne durch die Presse schwirren lassen hatte, nach denen sie Atmel aufkaufen wollten. Scheiterte damals offiziell nur daran, dass sie OnSemi nicht ins Boot bekommen haben, die einen nennenswerten Anteil davon zu stemmen gehabt hätten. Die Atmel- Aktionäre wollten sie damit anfüttern, ihnen stolze USD 5 pro Aktie zu geben (beim damaligen Zeitwert von irgendwas um die USD 4). Nun guck' mal, wieviel man für die Atmel-Aktie heute blechen muss … kann sein, dass Microchip gut damit fährt, ihren Krempel noch selbst zu produzieren, aber ganz offenbar war Atmels Strategie, veraltete Fabs abzustoßen und als Auftrag fertigen zu lassen nicht ganz daneben. Dass bei derartigen Firmen auch nur irgendwas nach technischen Kriterien entschieden wird, kann man sich sowieso abschminken: "shareholder value" ist das Einzige, was da zählt, und wenn man das als Cheffe da nicht zählen lassen wöllte, würden sie einen wohl sofort aufkaufen. AVR User schrieb im Beitrag #2409356: > Da es sich um µC handelt denke ich das hier das richtige Forum ist, > leider ist es im Offtopicforum nur nach Anmeldung möglich einen Beitrag > zu schreiben. Dann musst du dich eben anmelden. Faule Ausrede. Jadeclaw Dinosaur schrieb: > Software gibt es für lau, Programmiergeräte/JTAG-Adapter werden > mit einem Firmware-Update fitgemacht > und da sich am Kern und vielen Peripherieelementen nur wenig geändert > hat, > ist auch die Einarbeitszeit recht kurz. So lassen sich vorhandene > Konzepte kostengünstig upgraden. Die ersten beiden Punkte wären jedoch bei Cortex-M3 nicht anders.
Ich hoffe mal, daß die AVRs genug Absatz haben, damit sie noch weiter verfügbar sind. Es gibt sie ja schon seit 1997 und da waren Flash-MCs noch rar gesäht. Daher haben sie sich auch schnell verbreitet. Auch die PICs hatte damals noch so komische Fensterchen oder man schmiß nach jedem Programmierversuch einen in den Mülleimer. Für den Bastler waren die AVRs mit ISP-Flash schon eine deutliche Vereinfachung. Für die neuen Xmega sehe ich aber überhaupt keine Zukunft. Was völlig anderes wäre es gewesen, wenn die Xmega zu den AVRs kompatibel wären. D.h. daß man z.B. den AT90CAN128 durch eine kompatiblen Xmega ersetzen könnte und das alte Programm weiterhin funktioniert. Und dann könnte man bequem die zusätzlichen Features ausprobieren. Kein Entwickler springt nunmal gerne ins kalte Wasser. Ich bin doch nicht blöd und machen eine neue Platine mit dem Xmega, um dann Probleme zu bekommen, ehe wieder alles wie auf dem alten Stand läuft. Peter
Hi, Jörg Wunsch schrieb: > kann sein, dass Microchip gut damit fährt, ihren Krempel noch selbst zu > produzieren, aber ganz offenbar war Atmels Strategie, veraltete Fabs > abzustoßen und als Auftrag fertigen zu lassen nicht ganz daneben Das mit der reinen Fremdfertigung kann aber auch gehörig nach hinten losgehen. Ich hatte letztes Jahr (als Auftragsarbeit) zwei "Design Out" von Atmel AVR realisiert und das ganze auf PIC umgestellt. Problem war das weder der benötigte noch irgendein anderer "passender" AVR in Ausreichender Stückzahl in akzeptabler Zeit lieferbar war. (Irgendwas in >6Mon. als Vorankündigung) In der Fa. sind jetzt alle Atmel µC für Neuentwicklungen Tabu. 8Bit ist nun PIC, 32Bit C-M3 (STM oder TI) bzw. PIC, je nachdem welcher am besten passt. Der µC Durchsatz der Fa. ist nicht riesig, aber trotzdem ansehlich, über alle Produkte knapp 10K/Monat. Und Kleinvieh macht auch Mist. Jörg Wunsch schrieb: > Jadeclaw Dinosaur schrieb: >> Software gibt es für lau, Programmiergeräte/JTAG-Adapter werden >> mit einem Firmware-Update fitgemacht ... > Die ersten beiden Punkte wären jedoch bei Cortex-M3 nicht anders Doch SCHON! Es gibt natürlich für C-M3 freie Software und Toolchains. Aber das ist doch kein Vergleich zu den vom Hersteller Supporteten IDEs wie bei Atmel oder Microchip. Für den Kommerziellen Einsatz durchaus nicht immer geeignet. Bei AVR_Studio oder MPLAB habe ich zumindest einen Basissupport und einen Ansprechpartner von dem ich auch mal Problembehebung fordern kann. Zudem habe ich insbesondre beim MPLAB (und ähnlichen) die gewissheit das es einfach läuft, ohne riesiges HErumkonfigurieren. Es ist alles aus einer HAnd und ich muss nicht befürchten das nach dem irgendein Teil meiner Toolchain ein Update erfahren hat gar nichts mehr läuft und ich wieder alles völlig anders konfigurieren muss... Und bei den Entwicklungstools ist es auch so eine Sache. ST hat mit dem ST-Link ein ganz brauchbares Tool für wenig Geld. Aber dann wird es Tools wo ich zumindest halbwegs gewissheit habe das die fast immer sauber laufen und noch lange umfassend Supportete werden schnell dünn. Für den Hobbyisten gibt es da noch den J-Link EDU, aber für jemand der da sein Geld mit verdient... Arc Net schrieb: > Microchip hat bzw. wird in Zukunft einige Probleme haben: Hohe > Stromaufnahme, kein richtiger ext. Speicher/Datenbus, Software (Libs, > kein offizieller C++ Support, Architektur (nicht die PIC32, aber die > anderen Baureihen, auch wenn die PIC24, dsPICs ein Schritt in die > richtige Richtung waren)). D.h. hier: Zukünftig überhaupt keine PICs der > 8-Bit und 16-Bit-Baureihen, PIC32 nur wenn sie signifikante Vorteile > gegenüber AVR32, Cortex-M/R und RX in der konkreten Anwendung hätten. > (Microchip hat allerdings noch einen Trumpf: Man bekommt dort auch fast > die gesamte Peripherie) Da bin ich teilweise aber völlig anderer Meinung. Mit dem fehlenden C++ Support stimmt natürlich (im Moment) wobei das zur Zeit noch eher eine Nischenfrage ist. Bei den "kleineren" auf jeden Fall. Bei den "dicken Brummern" wird es gerade erst interessanter. Abe rMomentan spricht man halt in der µC Welt ohne OS noch überwiegend C. Wenn dann C++ wirklich relevanter werden sollte kann Microchip ja noch nachlegen... (ICH bin aber eh kein CPP fan, Für MEINE Anwendungen ist C besser) LIBs sehe ich bei PICs eher sogar als Vorteil. OK, für Atmel gibt es mehr... Aber das ist alles von dritter Seite mit einem riesen Mischmasch an Programmierstielen und Lizenbedingungen. Kommerziell sehr Heikel. Bei Microchip kommt alles aus einer HAnd, ist ordentlich dokumentiert, ist ein Stil und es gibt keine Lizenzrechtlichen Fragen. Die interne Architektur spielt für den Anwender der in C schreibt einfach so gut wie keine Rolle mehr. Bei jemanden der ausschließlich Assembler schreibt vielleicht noch geringfügig anders. Aber so dramatisch ist es auch nicht. Hauptkriterium ist: Erbringt der µC die Leistung die er soll. ZWeites HAuptkriterium ist: WElche Peripherie habe ich -> Und da hat Microchip absolut die Nase vorn! Und beim Stromverbrauch hat sich einiges Getan. Insbesondere bei den 8Bittern bekomme ich mit die "stromsparensten µC überhaupt" von Microchip. Bei den 32ern gibt es zwar noch ganz schön "Leistungshungrige", abe rauch da tut sich was. Aber letztendlich ist vieles was die Zukunft betrifft pure Kaffeesatzleserei. Es gibt viele GErüchte und noch mehr haltlose Unterstellungen oder Behauptungen von Fanboys "irgendeiner" MArke die meinen damit "ihr" Produkt noch besser aussehen zu lassen. (Meist sind diese PErsonen Atmel Fans, aber definitiv nicht nur...) ICh entscheide für meine Anwendungen jedes mal neu "welcher" µC da am besten passt. In den Fällen wo es ein PIC in die "engste Wahl" geschafft hat ziehe ich den aber vor. Zumindest bei den 8Bit Anwendungen. Liegt aber daran das ich bisher hinsichtlich Problemen bei Microchip die bessere Unterstützung bekommen habe, während ich bei Atmel so manches mal nur "Schulterzucken" wahrnahm. Selbst in der Zeit wo ich mich noch als "normaler" Hobbybastelr dort gemeldet habe -und mich auch als solcher zu erkennen gegeben habe, wurde immer unterstützt. Auch die Wartung der Entwicklungssoftware ist bei Microchip im Vergleich zum AVRStudio von Atmel fast vorbildlich... Aber letztendlich soll es doch einfach jeder für sich selbst entscheiden. Solange die "vorlieben" nicht so weit gehen das man wirklich für JEDES Problem unbedingt unter großen Aufwand ein Produkt der Lieblingsfirma hineinquetschen will obwohl die Mitbewerber wesentlich besseres haben, sind gewisse Vorlieben doch in Ordnung. Gruß Carsten
Ich fände es gut, wenn Atmel lieber weiter an den 8 Bittern tüftelt, statt am ATxmega. Auch der 32 Bit Bereich bei Mikrocontrollern dürfte so gut wie überhaupt nicht zu erreichen sein, mit einer komplett eigenen Neuentwicklung, da ARM Prozessoren auf dem Markt etabliert sind. Bei den 8 Bittern hingegen könnte man Speicher, Takt oder Peripherie noch "pimpen". Mit Verbesserungen beim Stromverbrauch kann man auch so gut wie nichts falsch machen. ADC oder DAC bei 8 Bittern sind bei Atmel auch irgendwie eine "angebrochene Baustelle", da ADCs nach wie vor nur bis 10 Bit gehen und DACs gar nicht (kaum?) verfügbar sind. USB wird nur von wenigen Geräten unterstützt. Ethernet wäre doch auch mal interessant (auch, wenn man nur wenige kb/s fahren könnte). Wie auch immer: Ich bin auch kurz davor mich bei den STM32 oder NXP ARMs einzuarbeiten, da ich bei den AVRs auch auf längere Zeit "schwarz" sehe. Die Dinger sind ja mittlerweile so teuer wie einfache ARMs. In erster Linie für kommerzielle Projekte (wo es ja durchaus um Geld geht), aber Privat würde es mich auch interessieren.
Carsten Sch. schrieb: > Problem war das weder der benötigte noch irgendein anderer "passender" > AVR in Ausreichender Stückzahl in akzeptabler Zeit lieferbar war. > (Irgendwas in >6Mon. als Vorankündigung) Woher weißt du, dass das an der Auslagerung der Fabs liegt? Maxim ist stolz darauf, viel in eigenen Fabs zu produzieren, trotzdem haben sie oft genug berüchtigt lange Lieferzeiten. >>> Software gibt es für lau, Programmiergeräte/JTAG-Adapter werden >>> mit einem Firmware-Update fitgemacht ... >> Die ersten beiden Punkte wären jedoch bei Cortex-M3 nicht anders > > Doch SCHON! > Es gibt natürlich für C-M3 freie Software und Toolchains. Aber das ist > doch kein Vergleich zu den vom Hersteller Supporteten IDEs wie bei Atmel > oder Microchip. Für den Kommerziellen Einsatz durchaus nicht immer > geeignet. Da sind wir beim alten Lied. Wie viel kannst du dir im Ernstfall für den Herstellersupport denn wirklich kaufen, und wieviel davon beruhigt nur $Cheffe? Sprich, wie schnell bekommst du denn ein für dich (aber nicht unbedingt auch für andere) wichtiges Problem wirklich vom Hersteller gelöst? Der Cortex-M3-Support im GCC stammt im Wesentlichen wohl von Codesourcery und ist seinerzeit von ARM finanziert worden. Der ist gewiss nicht schlechter als der Xmega-Support im GCC durch Atmel. PIC32 wiederum ist MIPS und benutzt meiner Erinnerung nach auch einen GCC.
Simon K. schrieb: > Ich fände es gut, wenn Atmel lieber weiter an den 8 Bittern tüftelt, > statt am ATxmega. Der Xmega ist doch ein 8-Bitter. ;-) > ADC oder DAC bei 8 Bittern sind bei Atmel > auch irgendwie eine "angebrochene Baustelle", da ADCs nach wie vor nur > bis 10 Bit gehen und DACs gar nicht (kaum?) verfügbar sind. Beim ADC hast du in so einer Umgebung immer ein Problem mit den Störabständen. Von genaueren DACs hatte ja neulich Anja schon in irgendeinem Thread geschrieben, dass sich deren Technologie mit den kleinen Strukturen normaler Controller einfach mal beißt. Lediglich mit Sigma-Delta-Wandlern kann man auf beiden Seiten deutlich mehr erreichen (für vergleichsweise niedrige Raten), aber das wiederum riecht nach Audio-Verarbeitung und damit eher nach DSP denn allgemeinem Controller. > Wie auch immer: Ich bin auch kurz davor mich bei den STM32 oder NXP ARMs > einzuarbeiten, ... Warum denn nicht auf einen AT91SAM3? Es gibt einige Hersteller von Cortex-M3, aber irgendwie reden alle immer nur von STM32 oder NXP … wobei bei NXP einige der ARMs Cortex-M0 sind, die in den Features und auch in der GCC-Unterstützung deutlich hinter ihren M3-Kollegen hinterher hinken (dieweil sie keinen Thumb2-Befehlssatz haben). Der einzige wirkliche Grund, warum man sich sowas antun wöllte, dürfte wohl der Preis sein.
Peter Dannegger schrieb: > Für die neuen Xmega sehe ich aber überhaupt keine Zukunft. Ich habe die auch abgeschrieben. Zu viel Verarsche am Anfang, zu viele der angekündigten XMegas nie erschienen, zu viele Fehler für meine Anwendungen. Angeblich sollen sie ein paar große Kunden für die XMegas haben. Na ja, Glück gehabt. Momentan ist eine neue B-Serie angekündigt. Abgesehen davon, dass Atmels Ankündigungen nicht viel wert sind, sollen die mit neuer Peripherie kommen, nicht etwa mit fehlerbereinigter. Von der neuen Peripherie weiß man natürlich nicht welche neuen Fehler Atmel schon wieder eingebaut hat. Dazu USB und LCD-Schnittstelle. Letzteres eine gute Idee, wenn man große Stückzahlen produziert, für die sich ein eigenes LCD-Glas lohnt. Sonst nicht. Dann geht mir Atmel mit AVR Studio 5 auf den Geist. Meiner Meinung nach ein unglaublicher Haufen Müll, der vorne und hinten nicht richtig funktioniert, mit einem schon fast albernen "Toolchain" Compiler.
Jörg Wunsch schrieb: > Simon K. schrieb: >> Ich fände es gut, wenn Atmel lieber weiter an den 8 Bittern tüftelt, >> statt am ATxmega. > > Der Xmega ist doch ein 8-Bitter. ;-) Ups, ja klar. Meinte natürlich die Standard AVR Serie. >> ADC oder DAC bei 8 Bittern sind bei Atmel >> auch irgendwie eine "angebrochene Baustelle", da ADCs nach wie vor nur >> bis 10 Bit gehen und DACs gar nicht (kaum?) verfügbar sind. > > ... Ich weiß nicht, aber wo anders bekommt man sowas doch auch hin?! Siehe ATxmega bspw. >> Wie auch immer: Ich bin auch kurz davor mich bei den STM32 oder NXP ARMs >> einzuarbeiten, ... > > Warum denn nicht auf einen AT91SAM3? > Es gibt einige Hersteller von > Cortex-M3, aber irgendwie reden alle immer nur von STM32 oder NXP … Eben genau aus dem von dir genannten Grund ;-) Weil alle über über NXP oder ST ARMs reden. Habe mal vor längerer Zeit bei beiden Herstellern vorbeigeschaut und die Peripherie-Ausstattung war eigentlich ziemlich gut. Von daher habe ich gar nicht mehr woanders nachgeschaut. Außerdem kann es nicht schaden den Firmenkreis, in dem man sich aufhält zu vergrößern. Immer nur Atmel ist doch auch einseitig ;-)
Simon K. schrieb: > Immer nur Atmel ist doch auch einseitig ;-) Naja, wie schon geschrieben, pass halt auf, dass du nicht Äpfel mit Birnen, ähm, Cortex-M0 mit Cortex-M3 vergleichst.
Jörg Wunsch schrieb: > Simon K. schrieb: >> Immer nur Atmel ist doch auch einseitig ;-) > > Naja, wie schon geschrieben, pass halt auf, dass du nicht Äpfel mit > Birnen, ähm, Cortex-M0 mit Cortex-M3 vergleichst. Zwar nicht direkt eine Antwort, aber wenn man schon mal dabei ist... Mich wundert es immer wieder das anscheinend nur fünf Firmen in Betracht gezogen werden: Atmel, Microchip, TI, NXP, STM. obwohl es Alternativen gibt u.a.: Freescale springt gerade mit den Feature-Monstern der Kinetis-Reihe auf den ARM-MCU-Zug (Cortex-M4 z.T. mit FPU, die "großen" K50/K53 haben bspw. u.a. 16-Bit SAR ADCs + PGA + Opamps, 12-Bit DAC, AES, SHA-256, Ethernet, USB-OTG, Touch, Segment-LCD, SDHC und I2S integriert, wenn sie denn verfügbar wären) Fujitsu hat was anderes ("zwar nur" Cortex-M3) "Long term Availability 10 years +" 1) Renesas die RX600, RX200 (und man kann davon ausgehen, dass sie genügend Mittel haben und die Reihe weiterentwickeln). Auch die anderen z.T. zugekauften Baureihen (M16C, V850, Super-H, R8, H8...) sind noch nicht tot. 1) http://www.fujitsu.com/downloads/MICRO/fme/documentation/a45.pdf
Jörg Wunsch schrieb: > Carsten Sch. schrieb: > >> Problem war das weder der benötigte noch irgendein anderer "passender" >> AVR in Ausreichender Stückzahl in akzeptabler Zeit lieferbar war. >> (Irgendwas in >6Mon. als Vorankündigung) > > Woher weißt du, dass das an der Auslagerung der Fabs liegt? > > Maxim ist stolz darauf, viel in eigenen Fabs zu produzieren, trotzdem > haben sie oft genug berüchtigt lange Lieferzeiten. Definitiv wissen tu ich es nicht. Das wurde damals halt von vielen Seiten gemunkelt. (Damals VERMUTETES Szenario: Atmel erwartet -wie viele andere- Wirtschaftskrise, vergibt Fertigungsaufträge nicht oder Storniert gar. Wirtschaftskrise bleibt Bankenkrise, Bestellrückgang nur kurzzeitig und Minimal. Atmel reagiert und will Aufträge vergeben. Fertiger haben aber schon andere Aufträge angenommen und Atmel muss warten...) Ob da was dran ist weiß ich nicht, das IST -und war- mir völlig EGAL. Atmel konnte LANGFRISTIG nicht Liefern - Und das alleine aus eigenem VErschulden, denn andere konnten ja. Warum die nicht liefern konnten spielt da fast keine Rolle. Und da kann ich meinen damaligen Auftraggeber gut verstehen wenn der sagt das er sich einmal verarschen lässt, aber kein zweites mal... Von anderer Seite habe ich sogar gehört das die "dieser" Firma genannten Lieferzeiten noch "Gnädig" wären, andere SOLLEN sogar Angaben deutlich über 60 Wochen für deren benötigte Teil bekommen haben... Aber das ist reines Hörensagen von mir! Es ist ja nicht so wie bei einer NAturkatastrophe oder ähnlich höherer Gewalt die jeden treffen kann - wo man natürlich auch Ausweichen muss um selber Lieferfähig zu bleiben - Aber zumindest etwas Verständniss aufbringen kann und auch die Hoffnung das soetwas so schnell nicht wieder passiert! Jörg Wunsch schrieb: >>>> Software gibt es für lau, Programmiergeräte/JTAG-Adapter werden >>>> mit einem Firmware-Update fitgemacht ... >>> Die ersten beiden Punkte wären jedoch bei Cortex-M3 nicht anders >> >> Doch SCHON! >> Es gibt natürlich für C-M3 freie Software und Toolchains. Aber das ist >> doch kein Vergleich zu den vom Hersteller Supporteten IDEs wie bei Atmel >> oder Microchip. Für den Kommerziellen Einsatz durchaus nicht immer >> geeignet. > > Da sind wir beim alten Lied. Wie viel kannst du dir im Ernstfall für > den Herstellersupport denn wirklich kaufen, und wieviel davon beruhigt > nur $Cheffe? Sprich, wie schnell bekommst du denn ein für dich (aber > nicht unbedingt auch für andere) wichtiges Problem wirklich vom > Hersteller gelöst? Eine irgendwie geartete Sicherheit ist Herstellersupport -solange eine Leistung nicht ausdrücklich Vertraglich garantiert wird- natürlich nicht. Aber in der Vergangenheit hat Microchip mir da durchaus immer wieder bereitwillig weitergeholfen. Selbst als ich noch "nur" Bastler war. Egal ob Anfrage über Telefon oder Email. Und immer hatte ich das GEfühl das die wirklich HELFEN WOLLTEN. Bei Atmel gestaltete sich das etwas schwieriger. Und wenn dann mal etwas passierte kam es mir durchaus so vor das die Frage eher als Störend empfunden wurde. ODer anderes Beispiel vor ein paar JAhren brauchten wir für ein Hochschulprojekt USB Microcontroller. Ich wollte sowohl PIC wie auch AVR in die engere Wahl nehmen. Die waren beide da noch recht "frisch". Über den normalen Elektronikhandel waren die USB AVR in Kleinstückzahlen nicht zu bekommen. Anfrage an Distri: Kauf nur in großen VE (einer hatte sogar auf Lager). Anfrage nach Samples: Ist im Moment schwierig, wird wohl so schnell nichts... (Ob es wirklich so war oder die nur keine Lust hatten -KA) Anfrage (ALS HOCHSCHULE!) direkt an Atmel: Über die Telefonistin bin ich nicht herausgekommen, KAUF oder SAMPLES? Nur über Distri... DIE KÖNNEN ODER WOLLEN NICHT! Ja dann müssen Sie weiterfragen, wir können nichts machen? ANDERE BESCHAFFUNGSQUELLE? - Nur über die genannten Distri. Anfrage an Microchip: BEZUGQUELLE: Reichelt hat welche im Programm aufgenommen, wird wohl nur noch nicht im Katalog stehen. Was genau sollen die denn Können. TJA, AUF JEDEN FALL USB HID ALS DEVICE, ANSONSTEN IST DAS NOCH IN PLANUNG. Wie gesagt, Reichelt wird die jetzt, oder ganz kurzfristig haben. Geben Sie mir aber mal die Kontaktdaten und Adresse, dann schaue ich mal ein paar Typen raus und schicke Ihnen was zu. 10 TAGE SPÄTER HATTE ICH 20 PICs (diverse TYPEN) AUF DEM TISCH... Und das ist nur ein Fall von mehreren. Auch wenn ich keinen immer garantierten Support habe. Wenn ich zwei Firmen habe - eine davon zeigt sich immer Zuvorkommend und bemüht, bei der anderen habe ich immer das Gefühl zu stören. Wo habe ich wohl das bessere GEfühl -und auch die besseren Chancen- hinsichtlich Support. Das sind halt die "Soft-Facts". Ich befinde mich halt in einem Bereich wo aufgrund der Stückzahl der Preis natürlich nicht völlig unwichtig ist, aber 20ct mehr im Einkaufspreis für den µC noch nicht Entscheidungsrelevant sind. (Wobei die PICs ja mittlerweile teilweise sogar günstiger sind) > Der Cortex-M3-Support im GCC stammt im Wesentlichen wohl von > Codesourcery und ist seinerzeit von ARM finanziert worden. Der ist > gewiss nicht schlechter als der Xmega-Support im GCC durch Atmel. > PIC32 wiederum ist MIPS und benutzt meiner Erinnerung nach auch einen > GCC. Ja, für die Implemtierung der Übersetzungsfunktion hast du sicherlich recht. Aber ich habe immer die gesamte Toolchain und das ganze Handling im Blick. Die Compiler für AVR und PIC32 basieren zwar im Grunde wie auch die für die ARM auf GCC, da hast du recht. Aber im Gegensatz zu zum Beispiel Microchip gibt es meines Wissens KEINE "offizielle" ARM Version des Mikrocontrollerhersteller die von diesem kontrolliert und gewartet wird auch noch komplett auf die ebenfalls vom Mikrocontrollerhersteller herausgegebene IDE abgestimmt ist. Ich muss mir alle Teile der TOOLCHAIN einzeln aus verschiedenen Quellen zusammensuchen* und aufeinander zuschneiden. Und die Programmierhardware kommt noch von einer Weiteren seite... Wenn etwas nicht läuft wie es soll muss ich erst einmal herausfinden ob tatsächlich ein Teil der Software nicht will, meine Einstellungen nicht passen oder tatsächlich die HArdware nicht stimmig ist. DEN EINEN Ansprechpartner gibt es nicht. Und für jedes TEil der Chain gibt es einen anderen Entwickler der nach eigenen Gutdünken entscheidet ob und in wie weit er seine Programme oder HArdware weiterentwickelt. Dasselbe gilt für Erweiterungen und Einschränkungen der Kompatiblitäten. ICh denke da mit grausen an das µC Praktikum bei mir an der FH. Da haben wir für das Semester "LeihBoards" mit einfacher Peripherie und LCD Display auf Basis AT91SAM7 für das Semester bekommen um auch daheim "Spielen/Üben" zu können. Als IDE war da natürlich Eclipse und die Toolchain mit OPENOCD usw. genutzt. Ständig wenn sich auch nur eine Kleinigkeit bei mir am Laptop geändert hatte musste ich die Toolchain wieder Konfigurieren... Einmal verklickt und man durfte wieder raten warum es nicht funktioniert, usw. usf. Wobei ich definitiv nicht der einzige war dem es so ging. Irgendwann war ich so genervt das ich daheim jede Vorarbeit gelassen habe und anstelle die Praktikumsarbeiten daheim vorzubereiten und beim Pflichtterim nur den "antrittstest" zu schreiben und direkt die Aufgabe abzugeben (war ausdrücklich erlaubt- dann war man nach 15Minuten fertig) habe ich dann nur wegen dem ständigen Ärger mit der IDE entschieden die Arbeit wirklich vor Ort am NUR für das Praktikum genutzen PC in der FH zu erledigen, anstelle bequem am Abend vorm Fernseher... (Die Aufgaben waren nicht wirklich kompliziert, reine Tipparbeit...) (In diesem Beispiel habe ich Microchip als "positives Beispiel" genannt, aber hinsichtlich der AVR meine ich ist es bei Atmel ja identisch, wenn auch mit geringerer Updaterate) Jörg Wunsch schrieb: >> Wie auch immer: Ich bin auch kurz davor mich bei den STM32 oder NXP ARMs >> einzuarbeiten, ... > > Warum denn nicht auf einen AT91SAM3? Es gibt einige Hersteller von > Cortex-M3, aber irgendwie reden alle immer nur von STM32 oder NXP … VErgesse TI nicht, die werden auch noch häufiger genannt... Der Grund dürfte eine Kombination von Verfügbarkeit, Peripherie und Preis sein. Wobei innerhalb der "Bastlerszene" die mittlerweile gute Marktdurchdringung gerade bei den STM beginnt diese zum Selbstläufer zu machen. Auf den "professionellen" Bereich hat das aber natürlich nur recht mittelbare Effekte, durch die Foren mit vielen Hobbyisten ist die Wahrnehmung im verhältniss zu den tatsächlich umgesetzten Stückzahlen schon recht verzehrt. Gruß Carsten
Hi, Peter Dannegger schrieb: > Ich hoffe mal, daß die AVRs genug Absatz haben, damit sie noch weiter > verfügbar sind. Es gibt sie ja schon seit 1997 und da waren Flash-MCs > noch rar gesäht. Daher haben sie sich auch schnell verbreitet. Auch die > PICs hatte damals noch so komische Fensterchen oder man schmiß nach > jedem Programmierversuch einen in den Mülleimer. > Für den Bastler waren die AVRs mit ISP-Flash schon eine deutliche > Vereinfachung. Also 1997, als die AVR auftauchten, da hatte Microchip durchaus schon einige FLASH/EEPROM PICs im Programm. Der "berühmte" 16C84 (Anfangs gab es ja sogar noch einen kleineren 16C83 zusätzlich!) hatte da schon ein paar Jahre auf dem Buckel und wurde gerade durch den 16F84 abgelöst. Im selben Atemzug kamen auch die ersten "leistungsfähigeren" 16F PICs. Aber die "echten" EPROM Typen die nur als OTP bezahlbar waren während die JW (Fenstertyp) so ab 50DM aufwärts kosteten und dabei sobald man versehentlich mal die CP Fuse setze schrott waren, bildeten natürlich noch die Mehrzahl. ´97 waren die Leistungsfähigsten PICs allesamt noch "normal" Eprom. Der wohl tatsächliche Grund für die schnelle Verbreitung der AVR war wohl eher der zeitnah verfügbare freie C Compiler dem Microchip da noch nichts (freies) entgegenzusetzen hatte. Zudem stiegen die ersten AVR im Vergleich zu den damaligen FlashPic schon mit beachtlichen Leistungsdaten und deutlich niedrigeren PReis in den Kampf ein. War halt eine Neuentwicklung! Und das ganze zu einer Zeit wo gerade das Internet begann auch unter "normalen" Privatleuten populär zu werden und ein PC Grundausstattung in so gut wie jedem HAushalt wurde. Vielen Hobbyelektronikern wurden so die "tollen" Möglichkeiten der µC schnell nahegebracht. Das währe wohl auch ohne die Markteinführung der AVR wohl die ZEit mit der schnellsten Wachstumsrate der Verbreitung der µC unter den Hobbyisten gewesen. Damit hatte Atmel genau den "richtigen" Zeitpunkt erwischt. Und es ist schon wahr: In den JAhren 98 bis kurz nach der Jahrtausendwende WAR AVR für die Neueinsteiger sicher mit Abstand die bessere Wahl im Vergleich zu PICs. ICh bin damals um 99 auch Umgestiegen. Später hat Microchip dann aber gehörig nachgezogen und insbesondere hinsichtlich programmierung (physikalisch) und Debugtools Atmel wieder einiges Abgerungen, ja eindeutig überholt. (Vom ersten 16C83 bis zu heutigen Neuentwicklungen EINE Programmierschnittstelle -Ok, ein paar wechselnde Optionale gibt/gab es-, kein WirrWarr wie bei AVR. Debugging mit billigen und glecihzeitig sehr robusten Tools, keinerlei Gfahr des Verfusens und Aussperren.) Somit bin ich dann mit der Zeit wieder auf die PICs zurückgekommen. Arc Net schrieb: > Zwar nicht direkt eine Antwort, aber wenn man schon mal dabei ist... > Mich wundert es immer wieder das anscheinend nur fünf Firmen in Betracht > gezogen werden: Atmel, Microchip, TI, NXP, STM. obwohl es Alternativen > gibt u.a.: Naja, wie im obigen Beitrag schon von mir geschrieben ist die Wahrnehmung natürlich immer etwas verzehrt. In Foren wie diesem hier, insbesondere in den deutschsprachigen, schreiben halt sehr viele Hobbyisten. Und von den professionellen Anwendern hier haben die meisten auch nur verhältnissmäßig kleine bis mittlere Durchsatzraten. Es ist somit keine repräsentative Abbildung der Realität. Ausschlaggebend für die Beschränkung auf die genannten fünf Firmen ist wohl in erster Linie die Verfügbarkeit und die im Netz erhältlichen Informationen/Support in Foren. Und da sieht es bei den von dir genannten (bis auf einige Renesas Serien) für die Hobbyisten/Kleinanwener eher recht mau aus. Bei Renesas, von denen einige Serien ja durchaus auch in Hobbyistenkreisen Einzug gehalten haben, ist teilweise die Verfügbarkeit besser, für viele ist aber gerade die von dir aufgezählte Serienvielfalt mit der Vielzahl untereinander völlig inkompatiblen Typen (Auch von den Entwicklungstools), für die Hobbyisten abschreckend. Wenn die "weniger" Serien hätten, dann gäbe es sicher mehr Hobbyanwender. Aber mit Blick auf die Industrie währe dies aber wohl trotz deutlich mehr Hobbyisten ein dickes Minusgeschäft. Gruß Carsten
Carsten Sch. schrieb: >> Woher weißt du, dass das an der Auslagerung der Fabs liegt? > Definitiv wissen tu ich es nicht. Das wurde damals halt von vielen > Seiten gemunkelt. Aha. Und daher muss es richtig sein. ;-) > Atmel konnte LANGFRISTIG nicht Liefern - Und das alleine aus eigenem > VErschulden, denn andere konnten ja. Warum die nicht liefern konnten > spielt da fast keine Rolle. Richtig, da stimme ich dir völlig zu. Hat doch aber überhaupt nichts damit zu tun, dass sie ein paar veraltete Fabs geschlossen haben. Auch, wenn diese noch gelaufen wären, hätten sie genauso gut mal irgendwann ihre Kapazitätsgrenze erreicht gehabt (vermutlich sogar schon viel eher als die externen Fabs, die darauf getrimmt sind, viel Durchsatz zu bringen), und wenn besonders große Nachfrage nach einem Produkt besteht, bleibt halt was anderes auf der Strecke. Dass dafür solche Kunden, die dergestalt auf der Strecke geblieben sind (weil man offenbar andere vorrangig bedienen wollte), dann den Hersteller wechseln, das muss den Entscheidern sicher klar gewesen sein. Trotzdem haben sie sich so entschieden. Nur ganz ehrlich: wenn es dieser Firma schlecht gehen würde, dann hätte sich nicht ihr Aktienwert gegenüber der Zeit "davor" mehr als verdoppelt. Leider wird eine AG nur nach dem Aktienwert gemessen am Markt. Ob sie dabei vergoldete Sche*** produziert oder schönes Silizium, ist den Börsenheinis völlig schnuppe. > Ja, für die Implemtierung der Übersetzungsfunktion hast du > sicherlich recht. Aber ich habe immer die gesamte Toolchain und das > ganze Handling im Blick. Ich auch. Ich möchte dabei nicht für jeden Hersteller eine neue IDE haben müssen, daher ist es mir sehr recht, wenn die Toolchain (die ja eigentlich alles reine backend-Kommandos sind, die man auf einer Kommandozeile ausführen kann) möglichst unabhängig von Editor und Debugger sind. Auf diese Weise habe ich seit 20 Jahren die gleiche "IDE", egal, ob ich für den Kernel meines FreeBSD entwickele, irgendeine normale Unix-Applikation, oder Code für einen AVR oder einen ARM. Von den backend-Tools erwarte ich in allererster Linie, dass sie aus dem, was ich ihnen vorsetze, korrekten und möglichst optimalen Code produzieren. Für mich privat heißt das übrigens, dass für einen von mir zu benutzenden Controller unbedingt eine Kommandozeilen-Toolchain verfügbar sein muss als Backend, die auf meinem Betriebssytem auch läuft. Opensource und selbst compilierbar ist dabei der Vorzug (weil ich dann ggf. für mich wichtige Bugs auch selbst reparieren könnte), allerdings könnte ich mit "binary only" auch leben, sofern das backend halt irgendwie unter FreeBSD lauffähig ist (Linux-Binaries beispielsweise wären da auch praktikabel). Genau das war aber der Grund, warum ich vor reichlich 10 Jahren nach einem kurzen Versuch mit den (damaligen) PICs diesen den Rücken gekehrt habe und zu AVRs gekommen bin: da gab's einen GCC, und dass der noch ein paar Verbesserungen gebraucht hat, war für mich eher Herausforderung als Hindernis. > Aber im Gegensatz zu zum Beispiel Microchip gibt es meines Wissens KEINE > "offizielle" ARM Version des Mikrocontrollerhersteller die von diesem > kontrolliert und gewartet wird auch noch komplett auf die ebenfalls vom > Mikrocontrollerhersteller herausgegebene IDE abgestimmt ist. Doch, Codesourcery. Ob du die nun "offiziell" nennst oder "inoffiziell", bleibt sich ja wohl gleich. Kommerziellen Support kannst du dafür auch bekommen.
Carsten Sch. schrieb: > Vom ersten 16C83 bis zu > heutigen Neuentwicklungen EINE Programmierschnittstelle -Ok, ein paar > wechselnde Optionale gibt/gab es-, kein WirrWarr wie bei AVR Da kann ich dir allerdings nicht mehr folgen. Was hat sich denn an der ISP-Schnittstelle der AVRs bislang geändert? Erst beim Xmega ist eine neue gekommen, für alles andere kann ich nach wie vor meinen Parallelport-Programmer aus dem Jahr 2000 benutzen, wenn ich will. Dafür braucht man keine +12 V für die normale Programmierung. Meinst du, zwei verschiedene Schnittstellen in reichlich 10 Jahren rechtfertigen wirklich den Begriff "WirrWarr" [sic]?
Christian H. schrieb: > Ich denke über kurz oder lang macht Atmel einen Fehler, die Tiny und > Megaserie vom XMega ersetzen zu lassen, aber mal sehen. Atmel hat in den letzten ein, zwei Jahren von einigen ATtinys und ATmegas überarbeitete Versionen auf den Markt geschmissen (erkennbar am A hinten), das ist für mich ein starkes Indiz dafür, dass diese weiter geführt werden. Die Verfügbarkeit war zeitweise schlecht und die Zeit zwischen Ankündigungen neuer Controller und deren Lieferbarkeit ist mitunter lang, inzwischen hat sich jedoch meinem Eindruck nach vieles geändert. Auf größere Stückzahlen müssen wir zwar mitunter drei Monate warten, aber alles unter 1000 Stück klappt eigentlich sofort (wobei das auch den Distributoren zu danken ist).
Jörg Wunsch schrieb: > Carsten Sch. schrieb: > >>> Woher weißt du, dass das an der Auslagerung der Fabs liegt? > >> Definitiv wissen tu ich es nicht. Das wurde damals halt von vielen >> Seiten gemunkelt. > > Aha. Und daher muss es richtig sein. ;-) Das es die absolute Wahrheit ist habe ich ja niemals behauptet. Aber hast du Belege dafür das es DEFINITIV NICHT so ist? Davon Abgesehen ist das trotzdem eine Gfahr die IMMER real für Probleme sorgen kann. Genau nach diesem Schema sind schon einige Firmen "auf die Schnauze" gefallen. Da plant man mit den alten verkauften Fabriken wie als wenn es noch die eigenen währen... Und plötzlich stellt man erstaunt fest das der neue Eigentümer ja auch etwas von Marktwirtschaft versteht und ihm sein eigenes Wohl näher liegt als das der früheren Besitzer. Aber lassen wir das. >> Atmel konnte LANGFRISTIG nicht Liefern - Und das alleine aus eigenem >> VErschulden, denn andere konnten ja. Warum die nicht liefern konnten >> spielt da fast keine Rolle. > > Richtig, da stimme ich dir völlig zu. Hat doch aber überhaupt nichts > damit zu tun, dass sie ein paar veraltete Fabs geschlossen haben. > Auch, wenn diese noch gelaufen wären, hätten sie genauso gut mal > irgendwann ihre Kapazitätsgrenze erreicht gehabt (vermutlich sogar > schon viel eher als die externen Fabs, die darauf getrimmt sind, viel > Durchsatz zu bringen), und wenn besonders große Nachfrage nach einem > Produkt besteht, bleibt halt was anderes auf der Strecke. > > Dass dafür solche Kunden, die dergestalt auf der Strecke geblieben > sind (weil man offenbar andere vorrangig bedienen wollte), dann den > Hersteller wechseln, das muss den Entscheidern sicher klar gewesen > sein. Trotzdem haben sie sich so entschieden. Bist du sicher das es damit nichts zu tun hat, Ode rnimmst du das auch nur an. Davon Abgesehen haben die nicht "Ein paar alte Fabriken" Dichtgemacht, sondern ALLE Fabriken bis auf eine abgestossen... Das ist schon ein Unterschied. Und es waren mitnichten ...Nur ein Produkt was auf der strecke blieb um anderen Produkten den Vorrang zu geben... ISt hier im Forum doch ganz gut noch nach zu lesen man muss nur 1-2 JAhre zurückgehen. Atmel hatte MASSIVE Lieferprobleme fast über das GESAMTE Produkspektrum (zumindest was µC angeht) Atmel war natürlich nicht die einzige Firma die diese Probleme damals hatte. Aber es gab auch eine ganze Reihe von Firmen die überhaupt keine oder auch nur geringe Liefermöglichkeiten haben. Und sollte deine Behauptung: > Dass dafür solche Kunden, die dergestalt auf der Strecke geblieben > sind (weil man offenbar andere vorrangig bedienen wollte), dann den > Hersteller wechseln, das muss den Entscheidern sicher klar gewesen > sein. Trotzdem haben sie sich so entschieden Wahr sein, dann finde ich das noch schlimmer. Fehlplanungen sind eine Sache. Aber wenn das Auflaufen lassen von kleinen bis mittleren Kunden. (Wie geesagt, wir reden hier ja duchaus von Firmen mit 100K µC/Jahr und mehr) mit voller Absicht geschah ist das doch ein wirklich eindeutiges Zeichen das in der Geschäftspolitik dieser Firma man als solcher keine Rolle mehr spielt. Auch nicht in der Betrachtung als Kleiner in einer großen Menge von Kleinen. DAS währe dann ein ECHT FUNDIERTER GRUND ein schnellstmögliches Design Out von SÄMTLICHEN Atmel Produkten vorzunehmen für die es keine "SecondSource" gibt. MAn muss ja ganz klar bedenken das soetwas selbst für ein "gesundes" Mittelständiges Unternehmen SEHR SCHNELL das komplette Aus bedeuten kann, während der "BigPlayer" nur ein leichtes "Jucken" verspürt. > > Nur ganz ehrlich: wenn es dieser Firma schlecht gehen würde, dann > hätte sich nicht ihr Aktienwert gegenüber der Zeit "davor" mehr als > verdoppelt. Leider wird eine AG nur nach dem Aktienwert gemessen am > Markt. Ob sie dabei vergoldete Sche*** produziert oder schönes > Silizium, ist den Börsenheinis völlig schnuppe. Ach komm... Der Verlauf des Aktienkurses ist nun wirklich kein Verdienst von Atmel selsbt sondern Lediglich der "Großwetterlage" geschuldet... Ich habe mal die Kursverläufe von Microchip, Atmel und als dritten Willkürlichen Part von Infineon als Grafik übereinander gestellt und angehangen. Fällt dir etwas auf? >> Ja, für die Implemtierung der Übersetzungsfunktion hast du >> sicherlich recht. Aber ich habe immer die gesamte Toolchain und das >> ganze Handling im Blick. > ... > ... > Ich auch. Ich möchte dabei nicht für jeden Hersteller eine neue IDE erhersteller herausgegebene IDE abgestimmt ist. > > Doch, Codesourcery. Ob du die nun "offiziell" nennst oder > "inoffiziell", bleibt sich ja wohl gleich. Kommerziellen Support > kannst du dafür auch bekommen. Naja, da sind wir dann an einem Punkt angekommen wo es wohl eine reine Geschmackssache ist. Du bevorzugst halte "echte Toolchains" möglcihst Open Source mit Linux hintergrund... Ich bevorzuge echte "integrierte" Entwicklungsumgebungen wo alles aus einem Guss ist "Out of the Box" auf meinem 0815 WindowsRechner läuft. Moemtan habe ich einen Rechner in der Fa. einen in meinem privaten Arbeitszimmer (mache teilweise "HomeOffice") dazu noch zwei Laptops. Mit all diesen REchnern arbeite ich an einem Projekt. Da ist es sehr Angenehm einfach nur den USB Stick ,mit dem Installprogramm anzustecken, das Setup zu starten und 5Minuten später auf jedem Rechner die absolut gelich eingestellt IDE zu haben wo ich durch simples kopieren des Projektverzeichnisses innerhalb von 5sec, immer denselben Zustand herstellen kann. ICh hätte noch nicht einmal die Zeit, selbst wenn ich wollte, mich in das Innenleben der IDEs einzuarbeiten und gar selbst änderungen vorzunehmen die ja im Komerziellen Umfeld auch noch genauestens auf alle Auswirkungen getestet gehören. Von der Lust mal ganz abgesehen. PC ist für mich halt Mittel zum Zweck und der soll einfach nur meine Anwendungssoftware zum laufen bringen. Spielereien machen mir schon seit Jahren keinen Spass mehr. Die letzte Linux Installation ist deshalb auch schon vor JAhren bei mir runtergeflogen. Aber wie gesagt, DAS ist reine Geschmackssache. Jeder soll doch so arbeiten wie er es für richtig erachtet. Wie schreibe ich immer wieder wenn jemand fragt welchen µC er nehmen soll: "Der der am besten zu dem Projekt passt, unabhängig vom aufgedruckten HErstellernamen" ICh habe hier nur MEINE Entscheidungsgründe für die (fast völlige) Abkehr von der Fa. Atmel dargelegt, wobei ich von einigen weiß das es denen ähnlich geht. GRuß Carsten P.S: Wegen Schnittstelle: OK, ich gebe zu da habe ich es etwas "missverständlich" geschrieben. Für mich gehört Programmieren und Debuggen halt mittlerweile zusammen... Gemeint mit "Wirrwarr" waren die jeweiligen Debugmöglichkeiten die ja bei Microchip über dieselben IOs laufen wie das normale Programmieren. ISt alles eine Schnittstelle... Wobei ich zugeben muss das die alten 16F84 natürlich noch nicht debugfähig waren...
Angehängte Dateien:
-
Chart.jpg
63 KB
Hi, Carsten Sch. schrieb: >> >> Nur ganz ehrlich: wenn es dieser Firma schlecht gehen würde, dann >> hätte sich nicht ihr Aktienwert gegenüber der Zeit "davor" mehr als >> verdoppelt. Leider wird eine AG nur nach dem Aktienwert gemessen am >> Markt. Ob sie dabei vergoldete Sche*** produziert oder schönes >> Silizium, ist den Börsenheinis völlig schnuppe. > > Ach komm... > Der Verlauf des Aktienkurses ist nun wirklich kein Verdienst von Atmel > selsbt sondern Lediglich der "Großwetterlage" geschuldet... > Ich habe mal die Kursverläufe von Microchip, Atmel und als dritten > Willkürlichen Part von Infineon als Grafik übereinander gestellt und > angehangen. Fällt dir etwas auf? hatte oben die Grafik vergessen. Reiche ich hiermit nach:
Carsten Sch. schrieb: > hatte oben die Grafik vergessen. Ja, da fällt schon was auf: Microchip 1,4:1, Infineon 2:1, Atmel 2,5:1. Allerdings ist die Skalierung so, dass man die vergleichsweise schlechten Microchip-Werte nicht auf den ersten Blick sieht. ;-) Ist jedenfalls sehr weit davon entfernt wie im Oktober 2008, als Microchip seine großen Bögen gespuckt hat. Carsten Sch. schrieb: > Bist du sicher das es damit nichts zu tun hat, Ode rnimmst du das auch > nur an. Ich bin mir sicher. Schau dir nur mal sowas an: http://www2.atmel.com/About/corporate/factsheet.aspx 2009 ein leichter Umsatzeinbruch bei Microcontrollern gegenüber 2008, dürfte im Wesentlichen wirklich die Folge der damaligen Krise sein. 2010 dann doppelt so viel wie 2009 — meinst du ernsthaft, das würde man erreichen, indem man nichts verkauft? Die Fab in Rousset ist aber erst Mitte 2010 verkauft worden, das kann also kaum einen Einfluss auf die schlechteren Zahlen von 2009 gehabt haben, anderer- seits war der Verkauf ganz offensichtlich kein Hinderungsgrund, 2010 ein gutes Ergebnis einzufahren.
Jörg Wunsch schrieb: > Ja, da fällt schon was auf: Microchip 1,4:1, Infineon 2:1, Atmel 2,5:1. > Allerdings ist die Skalierung so, dass man die vergleichsweise > schlechten Microchip-Werte nicht auf den ersten Blick sieht. ;-) > > Ist jedenfalls sehr weit davon entfernt wie im Oktober 2008, als > Microchip seine großen Bögen gespuckt hat. Naja, vergleiche hinken. Microchip zahlt seit 2003 regelmäßig Dividende. Bei Atmel gab es in all den Jahren keinen Cent. Damit ist MCHP ein Invest, ATML spekulativ und somit die Kursentwicklung schlecht vergleichbar. Das sich die Verkäufe nach der Finanzkrise stark erhöht haben ist ebenfalls kein Alleinstellungsmerkmal, es gab überall Nachholbedarf. Die Umsatzentwicklung ist über die Zeitreihe gesehen bei ATML und MCHP ähnlich. Was das Fab-outsourcing angeht halte ich das an und für sich nicht als Hinweis ob es einer Firma gut/schlecht geht. Was die BWL Heinis so entscheiden hat oft nicht mit dem langfristigen Geschäft zu tun. Wenn man aber z.B. auf http://www.finanzen.net/bilanz_guv/Atmel schaut sieht man das Atmel nur 2010 mal plus gemacht hat und selbst in diesem Jahr ist das Ergebnis vor Steuern weitaus geringer als das nach Steuern. Bilanzgewinne sind erstmal pure Kosmetik, Steuerzahlungen und Dividenden meiner Meinung nach Hard-Facts. Da sieht es bei Atmel nicht sehr rosig aus. Eine weitere Kennzahl ist für mich die Mitarbeiterentwicklung. Atmel ~ 9000-> 5000, Microchip ~ 4000 -> 7000
naja, Gewinn/Verlust hat ja nicht allzuviel zu bedeuten wenn man Leute findet die Kohle nachschiessen(siehe AMD...allzu oft haben die auch keinen Gewinn gemacht aber die gibts immer noch)
A. B. schrieb: > Gewinn/Verlust hat ja nicht allzuviel zu bedeuten wenn man Leute > findet die Kohle nachschiessen Haben Sie das denn? Eigenkapitalquote jetzt ca. 2/3 (von 50/50) und die Verbindlichkeiten (sowas ähnliches wie Schulden) mehr als halbiert. So wie es aussieht hat sich Atmel wohl restrukturiert, was auch die fehlenden Gewinne begründet (wurden zur Tilgung verwendet). Langfristig muss aber jedes Unternehmen mal Geld verdienen und wenn man die Wahl hat ist Atmel von der finanztechnischen Seite nicht gerade die erste. Technisch halte ich die Markenbindung übrigens weitgehend für überholt. Die Märkte sind aufgeteilt und sollte doch noch einer der verbliebenen Hersteller mal verschwinden; Nun, die Teile sind sich doch mittlerweile so ähnlich das man sich wunderbar über Unterschiede streiten kann ;-). Portieren / migieren ist wohl in 99,9% kein großes Problem mehr.
2/3 Eigenkapitalquote ist doch immerhin mehr als jede Bank hat ;)
A. B. schrieb: > 2/3 Eigenkapitalquote ist doch immerhin mehr als jede Bank hat ;) Eine Bank produziert auch nix außer heißer Luft... Für Banken sollte man die Glücksspielsteuer erheben. ...
Hannes Lux schrieb: > Für Banken sollte man die Glücksspielsteuer erheben. Das ist doch mal eine richtig gute Idee. Das solltest du dem Schäuble mal vorschlagen. 50%. Wie beim Lotto. mfg.
Hannes Lux schrieb: > Für Banken sollte man die Glücksspielsteuer erheben. Der war gut!! Muss ich mir merken!
>Ich bevorzuge echte "integrierte" Entwicklungsumgebungen wo alles aus >einem Guss ist "Out of the Box" auf meinem 0815 WindowsRechner läuft. >Moemtan habe ich einen Rechner in der Fa. einen in meinem privaten >Arbeitszimmer (mache teilweise "HomeOffice") dazu noch zwei Laptops. Mit >all diesen REchnern arbeite ich an einem Projekt. Da ist es sehr >Angenehm einfach nur den USB Stick ,mit dem Installprogramm anzustecken, >das Setup zu starten und 5Minuten später auf jedem Rechner die absolut >gelich eingestellt IDE zu haben wo ich durch simples kopieren des >Projektverzeichnisses innerhalb von 5sec, immer denselben Zustand >herstellen kann. Wow, vier mal die IDE lizensiert, und das bei den gepfefferten Preisen, die die haben. Respekt. Gruss Axel
Axel Laufenberg schrieb: > Wow, vier mal die IDE lizensiert, und das bei den gepfefferten Preisen, > die die haben. > > Respekt. > > Gruss > Axel ??? Willst du mir etwas unterstellen? Dann geht das aber nach hinten los. 1. Nicht JEDE IDE hat gepfefferte Preise, einige sind durchaus human, JA -es gibt sogar kostenlose auf die das o.g. zutrifft. UND VOR ALLEM: 2. Wenn du nur etwas Ahnung hättest, dann wüsstest du das in vielen Fällen die Anzahl der Lizenzen nicht die Zahl der Installationen sondern die Zahl der gleichzeitigen Nutzer beschränkt! Es sind somit gar keine vier Lizenzen sondern nur EINE erforderlich. Denn meinen Arbeitsplatzrechner in der Fa. kann ich nicht zur selben Zeit nutzen wie meinen PC im privaten Arbeitszimmer. (Irgendwie habe ich sogar noch etwas im Hinterkopf das selbst in den Fällen in denen etwas anderes in der Lizenzvereinbarung steht das in DL unwirksam ist... Aber da würde ich jetzt nicht drauf wetten, ich beziehie mich für das o.g. ausdrücklich auf die LV des HErausgebers.) Einen Dongle, wenn vorhanden, kann man Umstecken. Für eine andere Anwendung hatte ich mal einen Dongle der praktischerweise gleich einige 100MB Speicherplatz für Arbeitsergebnisse bot, da konnte man dann den Dongle als "Arbeitsverzeichniss" festlegen... War gar nicht schlecht. (Obwohl ohne Dongle immer besser ist...) Gruß Carsten
Wo wir gerade bei einem allgemeinen talk sind: ich spiele gerade mit dem Gedanken, mich mit den STM32 zu befassen und bin etwas erstaunt wegen der Pinbelegung: Der Hersteller hat ja scheinbar äußerst wenig Wert drauf gelegt, die Pins nach den zugeordneten Ports anzuordnen. Hat das irgendeinen tieferen Grund, wie die Pins liegen (Verteilung der Sonderfunktionen, ...), oder ist es nicht wirklich vorgesehen, abgesehen von PortA einen Port als parallelen Bus zu verwenden? Letzteres wird durch das Layout quawsi unmöglich.
Kevin K. schrieb: > Der Hersteller hat ja scheinbar äußerst wenig Wert > drauf gelegt, die Pins nach den zugeordneten Ports anzuordnen. Hat das > irgendeinen tieferen Grund, wie die Pins liegen Es gibt den technisch gleichen Controller mit beispielsweise 64, 100 und 144 Pins. Intern ist es das gleiche Die, nur sind je nach Gehäuse einige Pads nicht nach aussen geführt. Das bleibt wohl nicht ohne Konsequenzen für die Anordnung.
Dafür sind die STM32, von F10x..F20x..F40x zueinander Pin kompatibel. Bis auf ein paar kleine Ausnahmen was in der Doku beschrieben ist. Sowohl die 64, 100, 144 und 176 Pinner! Mehr Leistung >> einfach nächst größeren Chip nehmen... Andere Pheriperiefunktionen >> einfach anderen Chip mit gleichem Gehäuse... der eine STM32 momentan nicht "kaufbar" >> einfach den nächst dickeren mit mehr Flash nehmen. So eine konsequente Durchgängigkeit bei wirklich vielen Chips gibt es selten bei den Herstellern.
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.