moin, moin, ein paar Punkte sind mir klar: 1) keine 5 Volt 2) nur bis 85 Grad spezifiziert 3) stk500 geht nicht mehr 4) keine DIP-Gehäuse Aber: 1) man braucht eh 3.3V, z.B. für NOR-Flash, Oszillatoren, RTCs... 2) na gut, der zählt, aber nur ganz manchmal 3) egal, weil ich gerade erst mit Atmel anfange 4) das ist hart. Aber wenn man etwas größere Chips braucht, gibt's nur DIP-40, und das ist so riesig, dass ich vielleicht doch lieber TQFP-44 löte. Ich hab' jetzt die Datenblätter von den ATxmega-D4 und -E5 angeschaut und der erste Eindruck: "Atmel kann ja doch richtige Chips bauen". Na klar, die ATtiny haben nach wie vor ihre Berechtigung, aber für die erste Platine brauche ich relativ viele serielle Ports, also geht's für den Anfang um ATmega324PA gegen ATxmega32-- (da gibt's ja einige Alternativen). Mein Eindruck aus dem Forum war bisher "lieber kein xmega", jetzt würde ich gern ein paar aktuelle Meinungen lesen; danke schon mal.
:
Gesperrt durch Moderator
gnd3 schrieb: > Ich hab' jetzt die Datenblätter von den ATxmega-D4 und -E5 angeschaut Sehr löblich! Das schaffen längst nicht alle Forenteilnehmer. Was schätzt du, welchen Verbreitungsgrad die Xmegas haben?
Hi > Ich hab' jetzt die Datenblätter von den ATxmega-D4 und -E5 angeschaut Da gehören aber noch die passenden Manals dazu: http://www.atmel.com/Images/Atmel-8210-8-and-16-bit-AVR-Microcontrollers-XMEGA-D_Manual.pdf http://www.atmel.com/Images/Atmel-42005-8-and-16-bit-AVR-Microcontrollers-XMEGA-E_Manual.pdf MfG Spess
Ironischerweise sind die ARM cortex m0 und M3 Chips zB von st oder nxp günstiger, leistungsfähiger und bieten wesentlich mehr Peripherie ... Dafür ist der Einstieg hier schwerer, jedoch gibt es eine sehr große Community und man findet sehr viele Infos im Internet...daher neben viele gleich was größeres..
Komische Frage... Man wählt den uC der für das Projekt am besten geeignet ist und was man für Tools und Erfahrungen damit schon gemacht hat... Du hast 3,3 Volt und brauchst viele Serielle Ports? Na dann greif zu! Grüße Basti
gnd3 schrieb: > 4) keine DIP-Gehäuse Das ist für mich persönlich ein absolutes No-Go. Da können die anderen Werte noch so gut sein. Und wenn man doch SMD einsetzen muss, dann kann man gleich einen Cortex-M3 nehmen, die sind vom Preis her fast identisch.
Was ist eigentlich das große Problem mit SMD? Beim Chinesen gibt es für Centbeträge Breadboard-kompatible Adapterplatinchen, und mit ein bisschen Flussmittel & Co sollte da jeder so ein TQFP-Chip raufkriegen.
PIC32 kostet in etwa genau so viel, ist wesentlich leistungsfähiger als XMEGA (32 Bit MIPS), hat mehr Speicher und remappable Pins. Gibt es sogar noch als DIP, ein Minimalsystem kann auf einem Breadboard mir ein paar Teilen aus der Schublade zusammengesteckt werden: http://umassamherstm5.org/tech-tutorials/pic32-tutorials/pic32mx220-tutorials/pic32mx220-breadboard Du brauchst jetzt nur noch einen PICKIT3 Programmer (die Clone für 30 Euro gehen auch), dann kannst du sogar aus der MPLAB IDE Debuggen. Auf den PIC32 läuft sogar BSD Unix: http://retrobsd.org/wiki/doku.php Was spricht denn überhaupt für XMEGA bei dir?
greg schrieb: > Was ist eigentlich das große Problem mit SMD? Beim Chinesen gibt > es für > Centbeträge Breadboard-kompatible Adapterplatinchen, und mit ein > bisschen Flussmittel & Co sollte da jeder so ein TQFP-Chip raufkriegen. Es sind leider nicht nur Cent-Betrage, sondern durchaus stattliche Euro-Beträge, die die Kosten des zu adaptierenden IC oft deutlich überschreiten, insbesondere, wenn man auch noch die Versandkosten einrechnet. Ja SOIC und sowas ist als Adapter-PCB wirklich billig zu haben, aber QFP/QFN (was für die XMega relevant wäre) nicht wirklich. Dazu kommt dann noch der doppelte Arbeitsaufwand. Schließlich muß man zuerst den IC auf's Adapterboard brutzeln und die Drähte dann auch noch. Erst dann kann man damit anfangen, wo man bei auch in DIL verfügbaren ICs zu diesem Zeitpunkt schon längst mit fertig ist. Irgendwie kannst du nicht richtig rechnen...
Was ich beim Xmega blöd finde ist der ADC. Der ist zwar schön schnell, hat aber so einen bekloppten Eingangsspannungbereich von 0V bis Vref-0.6V. Das ist m.E der einzig wirkliche Nachteil ggü. den AVR. >> 1) keine 5 Volt Ja und? >> 2) nur bis 85 Grad spezifiziert Gebe ich dir recht. >> 3) stk500 geht nicht mehr Ja und? >> 4) keine DIP-Gehäuse DIP braucht heute auch wirklich keiner mehr.
c-hater schrieb: > greg schrieb: >> Was ist eigentlich das große Problem mit SMD? Beim Chinesen gibt >> es für >> Centbeträge Breadboard-kompatible Adapterplatinchen, und mit ein >> bisschen Flussmittel & Co sollte da jeder so ein TQFP-Chip raufkriegen. > > Es sind leider nicht nur Cent-Betrage, sondern durchaus stattliche > Euro-Beträge, die die Kosten des zu adaptierenden IC oft deutlich > überschreiten, insbesondere, wenn man auch noch die Versandkosten > einrechnet. Das war früher vielleicht so, aber mittlerweile gibt's Adapterboards doch sehr günstig, bei Ebay bekommt man die locker für <= 1 EUR das Stück. China sei dank. ;) Aber auch von deutschen Händlern gibt es die zu vernünftigen, wenn auch höheren Preisen. > Dazu kommt dann noch der doppelte Arbeitsaufwand. Schließlich muß man > zuerst den IC auf's Adapterboard brutzeln und die Drähte dann auch noch. > Erst dann kann man damit anfangen, wo man bei auch in DIL verfügbaren > ICs zu diesem Zeitpunkt schon längst mit fertig ist. > Klar, ich habe auch nicht behauptet, dass der Aufwand zu vernachlässigen ist. Aber er ist vergleichsweise klein. Es sind geringe Kosten und ein paar Minuten löten. SMD wird hier ja häufig als (für Bastelzwecke) unüberwindbares Hindernis angesehen, aber das kommt überhaupt gar nicht hin!
Meiner Meinung nach ist die Frage andersherum zu stellen: Was spricht in Anbetracht der Alternative ARM Cortex für den xMega? Wie schon beschrieben: Wenn schon "großer" Mikrocontroller mit den oben genannten Nachteilen für Bastler, dann kann man auch gleich auf einen Typ setzen, der von mehreren Herstellern mit quasi unendlich vielfältiger Peripherie angeboten wird und für den auch schon seit längerer Zeit anständiger Support bei libc und gcc vorhanden sind, damit man nicht an die Herstellersoftware (und Windows oder sogar bestimmte Windows-Versionen) gebunden ist. MfG, Arno
spess53 schrieb: > Da gehören aber noch die passenden Manals dazu: Danke für die Links! Test schrieb: > Ironischerweise sind die ARM cortex m0 und M3 Chips zB von st > oder nxp günstiger, leistungsfähiger und bieten wesentlich > mehr Peripherie ... Von den Freescale Kinetis garnicht zu reden, und die sind sogar lieferbar. Aber 32 Bit für Lüftersteuerung, DCF-Dekoder und so? Das ist doch Silizium-Frevel! Aber wenn ihr mich nicht von xmega überzeugen wollt, wird's wohl ein M0 werden. Basti M. schrieb: > Komische Frage... > > Man wählt den uC der für das Projekt am besten geeignet ist und was man > für Tools und Erfahrungen damit schon gemacht hat... ich würde ja gerne bei Freescale S12 bleiben, aber die sind sooo schlecht lieferbar und DIP-Gehäuse haben die erst recht nicht. Also muss was Neues her und wo wären da die Erfahrungen (gerade mit den Tools), wenn nicht hier im Forum? Das würde ich gerne anzapfen; bei den Chips selber sollten ja eigentlich die Datenblätter reichen. Für einen PIC hatte ich schon das Layout fertig, dann ist Microchip wegen seltsamer Lizenzbedingungen ausgeschieden (ja, vorher lesen macht schlau). Naja, jetzt ist Atmel dran... Test Einszweidre (test123) schrieb: > Und wenn man doch SMD einsetzen muss, dann kann man gleich einen > Cortex-M3 nehmen, die sind vom Preis her fast identisch. Ja, wenn's nur um das Gehäuse geht. LQFP-32 oder -44 mit 0.8mm gibt's in jeder Familie greg schrieb: > Was ist eigentlich das große Problem mit SMD? Beim Chinesen > gibt es für Centbeträge Breadboard-kompatible Adapterplatinchen, > und mit ein bisschen Flussmittel & Co sollte da jeder so ein > TQFP-Chip raufkriegen. Dann kann ich ihn auch gleich auf eine richtige Platine löten. Das Löten schreckt ab! Solche Adapterplatinen mit aufgelöteten Chip sind doch eine Marktlücke. Oder finde ich die nur nicht? Mc schrieb: > PIC32 kostet in etwa genau so viel, ist wesentlich leistungsfähiger > als XMEGA (32 Bit MIPS), hat mehr Speicher und remappable Pins. Naja, wenn 32 Bit, dann doch gleich ARM -- noch billiger und noch leistungsfähiger und vor allem viel verbreiteter. ARM würde ich aber kaum von Atmel und schon garnicht von Microchip nehmen, siehe oben. > Was spricht denn überhaupt für XMEGA bei dir? Die sehen (für meine Anwendung) in jeder Hinsicht besser aus, als die ATmega -- ich höre Gegenargumente? Hans W. (stampede) schrieb: > Was ich beim Xmega blöd finde ist der ADC. Der ist zwar schön > schnell, hat aber so einen bekloppten Eingangsspannungbereich > von 0V bis Vref-0.6V. das finde ich jetzt nicht so tragisch. Es ist ja vom Analogteil her verständlich und Eingangsspannungen aus dem Wirklichen Leben passen sowieso nie. > Das ist m.E der einzig wirkliche Nachteil ggü. den AVR. Das ist nett, danke. Mal sehen, ob ich noch einen finde ;) > > 4) keine DIP-Gehäuse > DIP braucht heute auch wirklich keiner mehr. Die können aber ggf. deutlich Geld sparen. Stell' die mal sowas wie eine Relaisplatine mit CAN-Bus vor (oder so). Bis auf Bus-Treiber und uC sind nur bedrahtete Teile drauf. Arno schrieb: > Meiner Meinung nach ist die Frage andersherum zu stellen: Was > spricht in Anbetracht der Alternative ARM Cortex für den xMega? Objektiv anscheinend nichts, nur dass 8 Bit locker ausreichen. Allerdings, von wegen "nicht an Herstellersoftware gebunden": Das ist ein sehr wichtiger Punkt für mich, und gerade deswegen bin ich bei Atmel gelandet. Ihr macht mich nachdenklich...
gnd3 schrieb: > Objektiv anscheinend nichts, nur dass 8 Bit locker ausreichen. Musst andersrum fragen: Stören die "überflüssigen" 16-24 Datenbits signifikant? Der RAM-Verbrauch wächst etwas, was sich aber dadurch ausgleicht, dass Chips gleicher Zielrichtung mehr davon haben. Dafür aber erspart man sich getrennte Adressräume für Strings im Flash und Strings im RAM. Braucht kein Banking von GPIO-Registern, um die schönen Bitbefehle der AVRs zu retten. Ein grosser Adressraum hat seine Vorteile, bei 4KB pro I/O-Modul muss der Modul-Designer nicht jedes Bit beim Boss einzeln beantragen. Die Kehrseite sind lustige Nebeneffekte des modularen Charakters der ARM basierten Controller. Was letzthin ein paar Leute merkten, die die Interrupt-Flags zu spät zurück setzten und die ISR deshalb gleich zweimal aufgerufen wurde.
:
Bearbeitet durch User
Hi > Was ich beim Xmega blöd finde ist der ADC. Der ist zwar schön > schnell, hat aber so einen bekloppten Eingangsspannungbereich > von 0V bis Vref-0.6V. Wo hast du das her? Ich finde nur, das Aref<=AVcc-0,6V sein darf. MfG Spess
spess53 schrieb: > Hi > >> Was ich beim Xmega blöd finde ist der ADC. Der ist zwar schön >> schnell, hat aber so einen bekloppten Eingangsspannungbereich >> von 0V bis Vref-0.6V. > > Wo hast du das her? Ich finde nur, das Aref<=AVcc-0,6V sein darf. > > MfG Spess Ja, und bei Spannungen die größer sind als die Referenz gibt der Wandler dann logischerweise nur noch 0x3ff aus. Ggf überlegt das der Pin sogar, aber messen kann ich dann in dem Bereich ja nicht. Und das ist ja das Problem. Das mag manchmal nicht stören, leider sind dann nur radiometrische Messungen nicht mehr so einfach möglich.
:
Bearbeitet durch User
A. K. (prx) schrieb > ein paar Argumente für 32 Bit alles richtig -- 32 Bit programmieren sich viel entspannter, auch (oder gerade?) in C. > Die Kehrseite sind lustige Nebeneffekte des modularen Charakters > der ARM basierten Controller. Was letzthin ein paar Leute merkten, > die die Interrupt-Flags zu spät zurück setzten und die ISR deshalb > gleich zweimal aufgerufen wurde. Da würde ich nicht der Modularisierung die Schuld geben, diese CPUs sind einfach nur zu schnell :) Aber ein spannender Fehler, gibt's evt. einen Link?
Beitrag "STM32: Timer-ISR löst 2x aus - Fehler im Flag-Reset bei Optimierung O3" Beitrag "Anfängerfrage STM32"
Hans W. schrieb: > spess53 schrieb: >> Hi >> >>> Was ich beim Xmega blöd finde ist der ADC. Der ist zwar schön >>> schnell, hat aber so einen bekloppten Eingangsspannungbereich >>> von 0V bis Vref-0.6V. >> >> Wo hast du das her? Ich finde nur, das Aref<=AVcc-0,6V sein darf. >> >> MfG Spess > > Das mag manchmal nicht stören, leider sind dann nur radiometrische > Messungen nicht mehr so einfach möglich. Gerade bei ratiometrischen hast du doch sowieso eine externe Referenz, die muss halt nur sicher kleiner als VCC sein. Nur die billige Schätz-Schaltung mit VREF=VCC geht halt nicht, aber dafür gibt's ja eine interne Referenz. Die ist zwar bei Atmel kaum genauer als 3.3V-Schaltregler, aber das reicht ja :)
@ A. K. (prx) >Dafür aber erspart man sich getrennte Adressräume für Strings im Flash >und Strings im RAM. Stimmt, das ist ein Manko am AVR. > Braucht kein Banking von GPIO-Registern, um die >schönen Bitbefehle der AVRs zu retten. ??? Das schluckt der Compiler. >Ein grosser Adressraum hat seine >Vorteile, bei 4KB pro I/O-Modul muss der Modul-Designer nicht jedes Bit >beim Boss einzeln beantragen. >Die Kehrseite sind lustige Nebeneffekte des modularen Charakters der ARM >basierten Controller. Was letzthin ein paar Leute merkten, die die >Interrupt-Flags zu spät zurück setzten und die ISR deshalb gleich >zweimal aufgerufen wurde. Und die Tatsache, dass AVRs besser für Bit-Bang Aufgaben geeigent sind als ARMs, die mit ihrer Pipeline und den ganzen Bussen das deutlich schlechter können. Niemand kann alles perfekt! Muss er auch nicht!
Falk Brunner schrieb: >> Braucht kein Banking von GPIO-Registern, um die >>schönen Bitbefehle der AVRs zu retten. > > ??? > Das schluckt der Compiler. Im Ernst? Wär m.E. zu viel Integration von I/O-Kram in einen Compiler. Die Xmegas haben einen 32-Byte Block pro GPIO, vergleichbar zu den 4KB Blöcken der ARM µCs. Damit aber nicht wie bei den ARMen für jeden GPIO-Zugriff LDS/STS notwendig ist, sondern die CBI/SBI/SBIC/SBIS Befehle genutzt werden können, gibts ein paar Sätze virtueller Register im bitadressierbaren Bereich, die auf jeweils eine GPIO gebankt wird. Letztlich sind die AVRs damit nicht schlechter dran als die ARMs, die ja mangels Bitbefehlen auf I/O schon immer mit Set/Reset-Registern arbeiten mussten. Aber wer diese virtuelle I/O nutzen will, um effizienter arbeiten zu können, der hat eben dieses Banking an der Backe. Ein wirklicher Nachteil ist das also nicht, aber es gehört zu jenen Hacks, an denen man die Limitierung einer irgendwann einmal für kleinere Lösungen erdachten Architektur erkennt. Mich erinnert das ein wenig an die 51er, die mit 128 Bytes RAM super und mit 256 Bytes RAM noch akzeptabel umgehen können. Aber bei denen man bei genauem Hinsehen merkt, dass die ursprünglich nie für mehr als 256 Bytes normales Arbeits-RAM gedacht waren.
:
Bearbeitet durch User
Falk Brunner schrieb: >>Dafür aber erspart man sich getrennte Adressräume für Strings im Flash >>und Strings im RAM. > > Stimmt, das ist ein Manko am AVR. Das war für mich ein entscheidender Grund, die Xmegas komplett zu ignorieren. Wie man das besser macht zeigt Microchip bei den PIC24. Da wird ein Teil des ROMs in die oberen 32KB des Datenadressraums eingeblendet. Auf die Art hätte sich auch bei den AVRs in den allermeisten Fällen die Problematik der getrennten Adressräume in Luft aufgelöst. Da wären nur wenige Fälle wirklich grosser Datenmengen im Flash für explizite Flash-Adressierung verblieben.
:
Bearbeitet durch User
Pro Xmega sehr billig, nur ein Bruchteil eines ARM auch wenn immer wieder gegenteiliges bahauptet wird. Siehe Mouser. Ab 2€ bekommt Du keinen Arm mit ähnlichen Daten Viele wissen noch gar nicht das es schon längst eine aktualliesierte Xmega version gibt, die nur ein Bruchteil kostet
Der neue XMEGA hat auch nen ganz normalen ADC wie die normalen megas auch....
c-hater schrieb: > Es sind leider nicht nur Cent-Betrage, sondern durchaus stattliche > Euro-Beträge, die die Kosten des zu adaptierenden IC oft deutlich > überschreiten, insbesondere, wenn man auch noch die Versandkosten > einrechnet. Ja SOIC und sowas ist als Adapter-PCB wirklich billig zu > haben, aber QFP/QFN (was für die XMega relevant wäre) nicht wirklich. Doch, durchaus: www.anvilex.de > Dazu kommt dann noch der doppelte Arbeitsaufwand. Schließlich muß man > zuerst den IC auf's Adapterboard brutzeln und die Drähte dann auch noch. > Erst dann kann man damit anfangen, wo man bei auch in DIL verfügbaren > ICs zu diesem Zeitpunkt schon längst mit fertig ist. Naja, das muss man meist nur einmal pro Typ machen und das geht doch recht flott. > Irgendwie kannst du nicht richtig rechnen... Das ist die Frage: warum sollte man sich bei der Auswahl der Controller auf Typen einschränken, die die gestellte Aufgabe mehr schlecht als recht erledigen? Meiner Meinung nach sollte man auch beim Hobby den Controller nach der zu erfüllenden Aufgabe aus wählen und nicht nach dem Gehäuse.
Kim Schmidt schrieb: > Ab 2€ bekommt Du keinen Arm mit ähnlichen Daten Wenn ich jemand wäre, der Massenprodukte herstellt, dann wär das ein Thema. Da zählen die Cents. Aber wer das als Hobby betreibt, der soll mir mal erzählen, dass es für ihn wirklich entscheidend ist, ob der µC 1,50€ oder 3€ kostet. Bei Ing-Büros und den dort üblichen Stückzahlen dürften auch eher die Kosten für die Entwicklungszeit dominieren. Da wird man deshalb die Anzahl verschiedener verwendeter Familien begrenzen. Und da ist man mit den aktuellen CMx ARMs wie STM32 oder LPC800/1000 flexibler bedient als mit AVRs. Die decken mehr Aufgabenbereiche ab.
:
Bearbeitet durch User
Kim Schmidt schrieb: > Pro Xmega sehr billig, nur ein Bruchteil eines ARM auch wenn immer > wieder gegenteiliges bahauptet wird. > Siehe Mouser. Preise ändern sich heutzutage sehr schnell ;) http://de.mouser.com/ProductDetail/Freescale-Semiconductor/MKE02Z64VQH2/?qs=%2fha2pyFadugcLOE3W0wY3A1rFZxUNAqxM9VWBIyrki0mmzipjGBNFQ%3d%3d http://de.mouser.com/ProductDetail/Atmel/ATXMEGA32D4-AU/?qs=%2fha2pyFaduiMp0ZKD42uKYkjInyAADgkO84vRG3OV4pFZwpZTALMOQ%3d%3d http://de.mouser.com/ProductDetail/Atmel/ATMEGA324PA-AU/?qs=%2fha2pyFadujcrAcowhVCzhs4ZEgkyzNmx4Clx3qvfPXSFoRiy4Lmdg%3d%3d das sind die drei Typen, die für mich in der engeren Wahl sind -- ausgewählt nach der zu erfüllenden Aufgabe. Zum Glück gibt's die nicht nur im QFN-Gehäuse ;)
@gnd3: Ich habe eine Artikelübersicht, die Du mal lesen könntest: (STM32 bezogen, jedoch übertragbar auf alle Hersteller mit Cortex-M0 / M3/M4 Kern) STM32 für Einsteiger Natürlich gibt es auch noch die Artikel: Entscheidung Mikrocontroller und Mikrocontroller Vergleich die andere Controller näher beschreiben. Bei diesem Thread jedoch habe ich das Gefühl, es wird einer gesucht der ordentlich was unter der Haube hat nicht nur ein I²C oder nur 3 Timer.
Hier wäre noch einer: http://de.mouser.com/ProductDetail/STMicroelectronics/STM32F030R8T6/?qs=sGAEpiMZZMvmogu7fABzFjP8fYdCFJcR ... die Qual der Wahl ... 2xSPI, 2xI²C, 2xUART, 5xTimer + 1xTimer Intern Mouser hat davon auch mehr auf Lager und der ist billiger.
:
Bearbeitet durch User
Bei der richtigen Quelle bekommt man auch z.B. den STM32F103 in kleinsten Stückzahlen für 2-3 EUR. Man muss nicht einmal wirklich suchen.
Markus Müller schrieb: > Hier wäre noch einer: > http://de.mouser.com/ProductDetail/STMicroelectronics/STM32F030R8T6/?qs=sGAEpiMZZMvmogu7fABzFjP8fYdCFJcR naja für bastler ganz ok aber wie kann man halb getestete ICs in sein seriöses Projekt einbauen? >Value line klingt toll, ist sie aber nicht. Nur ein Beispiel fürn Flash: hier gerade mal 1k erase cycles garantiert. diese ganzen 32bit für 32cent ist nur deswegen so billig, da heutzutage ein sehr großer Brocken des Preises die Tests der Chips ausmacht. Verkürzt man die Tests, schließt man Tests aus, dann ist der Preis natürlich niedriger. Ich bleib lieber bei Chips die keine Bauern fangen ;-) Zum Xmega meine Liste "für Xmega": - die Einfachheit - ich kann meine Tools weiterverwenden - sehr kleine Gehäuse 32pin 4x4mm qFN - mit 1.62V läuft noch sämtliche Peripherie, auch EEPROM erase und analoge Komponenten - 4 Kanal DMA - 8 Event Kanäle - einfacher multi-lever interrupt controller - CRC16/32 generator - AES/DES - sehr stabiler Stromverbrauch gegenüber Cortexe aller Art im Power down mit komplettem SRAM erhalt - 2x schnelle 12Bit ADC mit je 1/2 - 64x integriertem Verstärker + differentielle und single ended inputs! + viele interne Referenzspannungen: 1V, VCC/1.6, VCC/2, AREFA,AREFD - 4x 12Bit DAC Kanäle , nur 1kOhm minimale Last - 4x AC + flexible 64level programmierbare voltage scaler interner spannungen + output vom dac + bandgap ref voltage - 8x 16bit timer was 32 PWM Kanälen entspricht - fullspeed USB ohne ext. komponenten mit selbst gegen CM3 sehr niedriger CPU last (bei 1MByte Transfer <10% Last, STM32F >50% Last) - 8 USART - 4 I2C - 4 SPI - External Bus interface - komplett kostenlose Compiler/IDE vom Hersteller supported, ohne Einschränkungen in Codesize/Funktion die XmegaE vor allem: - Xmega custom logic - highend 16bit timer - adc mit offset/gain correction und averaging in HW (gibt low power) - irc mit 1MHz - SPI double buffered und DMA support - USART auch als ein-draht half duplex mode
Andreas schrieb: > naja für bastler ganz ok aber wie kann man halb getestete ICs in sein > seriöses Projekt einbauen? >Value line klingt toll, ist sie aber nicht. > Nur ein Beispiel fürn Flash: hier gerade mal 1k erase cycles garantiert. > > diese ganzen 32bit für 32cent ist nur deswegen so billig, da heutzutage > ein sehr großer Brocken des Preises die Tests der Chips ausmacht. > Verkürzt man die Tests, schließt man Tests aus, dann ist der Preis > natürlich niedriger. Gibt es irgend welche Beweise für Deine These? Berichte dass die "ValueLine" ständig kaputt gehen? Internetlinks?
Markus Müller (mmvisual) schrieb: > STM32 für Einsteiger danke, ein guter Artikel, besonders dieser Absatz: # Der für den STM32 empfohlene Segger J-LINK EDU ist zwar nicht der günstigste (...) aber eines der besten, mit sehr guten Software-Tools (...) ... unter Windows, Linux und MAC # gibt es vielleicht Open Source Software, die mit dem J-LINK, diesen Chips und am liebsten mit Debian funktioniert? Und/oder: stimmt das, dass man die STM32 per UART programmieren kann, also ganz ohne Programmiergerät und vor allem ganz ohne Programmiersoftware? # Niemals am Werkzeug sparen und man hat viel mehr Freude bei der Arbeit. # Was ich immer sag'... (naja, in gewissen Grenzen). > Hier wäre noch einer: > http://de.mouser.com/ProductDetail/STMicroelectron... wenn das Gehäuse nicht wäre; mit 0.5mm Pitch verweigern ja schon manche Leiterplattenhersteller. Aber den STM32F05xxx gibt's wohl auch mit 2 UARTs im 32-Pin-Gehäuse.
gnd3 schrieb: > gibt es vielleicht Open Source Software, die mit dem J-LINK, diesen > Chips und am liebsten mit Debian funktioniert? Der Artikel: STM32 Eclipse Installation Sollte entsprechend auch unter Linux klappen. > Und/oder: stimmt das, dass man die STM32 per UART programmieren kann, > also ganz ohne Programmiergerät und vor allem ganz ohne > Programmiersoftware? Per UART geht. ganz ohne Software wohl nicht, da es ein Handhake gibt. Von ST gibt es ein Programm, aber ob das auch unter Linux läuft weiß ich nicht. Den STM32F4xx kann man auch per USB programmieren, nicht nur per UART, denn der hat ein größeres Boot-ROM eingebrannt. > wenn das Gehäuse nicht wäre; mit 0.5mm Pitch verweigern ja schon manche > Leiterplattenhersteller. Aber den STM32F05xxx gibt's wohl auch mit 2 > UARTs im 32-Pin-Gehäuse. Recht günstig, die machen das noch mit: http://www.bilex-lp.com/user_d/ - Dauert dafür etwas länger - nur 2-Lagig (Das Bild aus dem einen Artikel ist von einer Platine von denen und von mir aufgelötet)
gnd3 schrieb: > Mein Eindruck aus dem Forum war bisher "lieber kein xmega".. Naja, ich formuliere das mal etwa so: 1. Es gibt rein sachlich für's gleiche Geld deutlich bessere µC's - sowohl technisch gesehen als auch von der Verbreitung und User-Basis her. 2. DIP Gehäuse und all die Steckbrett-Sachen sind bei kleineren und langsameren 8 Bittern vielleicht noch gangbar, aber für neuere und schnellere µC sind sie mega-out, weil solche µC, die mit 50 MHz und mehr 'rennen' eben richtige HF-Teile sind, die auch eine HF-gerechte Umgebung sprich Leiterplatte benötigen. Wer das mißachtet, erstickt irgendwann mal in unerklärlichen Effekten, Abstürzen, scheinbaren Fehlfunktionen. 3. Derzeit ist Cortex gerade sehr in Mode und das wird auch noch viele Jahre so bleiben. Wer da mitschwimmen will, ist mit xmega schlecht positioniert. Aber: Die Cortexe haben schon gewaltig aufgeräumt im Controllermarkt, eine ganze Reihe von Architekturen sind bereits den Bach runter gegangen. Das ist Monokultur und die ist auf lange Sicht schlecht, ganz schlecht. Man sieht etwas ähnliches bei den Programmiersprachen, wo derzeit eine ziemliche C-Monokultur herrscht. Später mal aus so einer Furche wieder herauszukommen, wird ganz, ganz schwierig. Deshalb ist es auch bei den Controllern so, daß alles, was die Monokultur nicht ganz so "mono"ig macht, also die Vielfalt so gut es geht erhält, eine gute Sache. Aus diesem Grunde heraus bastle du mal ruhig mit Atmel Xmega und mit PIC32. W.S.
W.S. schrieb: > Man sieht etwas ähnliches bei den > Programmiersprachen, wo derzeit eine ziemliche C-Monokultur herrscht. Vielleicht im Bereich der µC, aber das sehe ich nicht als großes Problem an. Im Gegenteil, ich finde es eher positiv, denn egal ob ich einen ARM, Atmega, PIC usw. nehme, bei der Programmierung muss ich (von hardwarespezifischen Besonderheiten einmal abgesehen) nicht umdenken.
ARM ist zwar eine Art Monokultur, aber eine ziemlich offene. ARM verkauft Cores und Lizenzen für selbstentwickelte Cores gleichermassen an jeden, der sie haben will, und tritt nicht selbst als Konkurrent auf. In diesem Sinn ist ARM eine Art Industriestandard mit gleichen Chancen für alle. Deshalb wäre es ein GAU, wenn ARM eines Tages per Übernahme unter die Haube eines Herstellers geraten würde, gegen den andere ARM Kunden dann in Konkurrenz antreten müssten. Solange das nicht geschieht sehe ich diese Art Monokultur sehr gelassen. Nicht jeden Controller-Hersteller gelüstet es danach, 32-Bit Cores selbst zu entwickeln. Die Investitionskosten für eine Eigenentwicklung sowohl der Cores als auch der Entwicklungsumgebung sind signfikant, die Fehlermöglichkeiten und entsprechende Blamagen auch. Cores von ARM (oder MIPS) ermöglichen somit auch Newcomern den Einstieg (Luminary Micro, Energy Micro, der 5V-Chinese), und fördern daher umgekehrt eine Vielfalt von darauf basierenden Controllern innerhalb der gleichen Entwicklungsumgebung beim Kunden.
:
Bearbeitet durch User
Markus Müller schrieb: > Per UART geht. ganz ohne Software wohl nicht, da es ein Handhake gibt. > Von ST gibt es ein Programm, aber ob das auch unter Linux läuft weiß ich > nicht. https://code.google.com/p/stm32flash/ Funktioniert gut und wird aktiv maintained. Bei den LPCs klappt das ähnlich gut mit dem Tool "lpc21isp". Also argumentieren, dass die ARM-µCs schwer an den PC anzubinden sind, kann wirklich niemand behaupten. :)
Schön, ich habe den Link gleich mal mit hier aufgenommen: http://www.mikrocontroller.net/articles/STM32#Boot_from_SYSMEM_.28RS232.2C_CAN_und_USB.29
W.S. schrieb: > Das ist Monokultur und die ist auf lange Sicht schlecht, ganz schlecht. Diese Monokultur fördert nicht nur die Vielfalt der µCs, die sich mit einer Entwicklungsumgebung abdecken lassen, sondern auch die Vielfalt von Entwicklungsumgebungen selbst. Wieviele davon gibt es für ARM? Noch einstellig, oder bereits zweistellig? Bei herstellerspezifischen Prozessoren gibts oft nur eine einzige. > Man sieht etwas ähnliches bei den > Programmiersprachen, wo derzeit eine ziemliche C-Monokultur herrscht. Wenn es einen Markt alternativer Programmiersprachen für Microcontroller gibt, dann ist das gerade ARM. Nur dieser eine Markt ist gross genug, um damit überhaupt wirtschaftlich Erfolg haben zu können.
So ein Quatsch. Als ob (Atmels) 8-Bitter keine industrielle Anwendung finden würden. Nee nee, die bleiben weiter aktuell und die XMegas sind eine sinnvolle Weiterentwicklung der älteren Baureihen, Vorzüge siehe weiter oben.
>und die XMegas sind >eine sinnvolle Weiterentwicklung der älteren Baureihen, Vorzüge siehe >weiter oben. Nur will sie kaum einer haben. Ich programmiere schon lange AVR. Wenn es sein muss tuts auch ein PIC18. Je nach Anwendung. Bei der Suche nach was fetterem bin ich dann gleich auf ARM gesprungen und hab das nicht bereut. Es hätte keinen Sinn gemacht da noch einen Zwischenschritt einzulegen.
Da hat doch auch keiner was dagegen, wenn es in einer konkreten Situation sinnvoll erscheint. Nur ist dieser Schritt angesichts der Vorzüge der XMegas -insbesondere für den AVR Anwender- alles andere als zwingend.
Ein 8Bitter mit 16Bit Adreßpointern für 384kB Flash und 16MB SRAM ist einfach nur krank. Zumindest der WINAVR konnte nur 64kB SRAM adressieren, unterstützen neuere AVR-GCC den Xmega besser? Ich hab mal den ATmega2560 benutzt, der ist dann ständig aufs Trampolin gesprungen, um die 256kB Flash zu erreichen. So ein Würg-Around ist heutzutage wirklich eine Zumutung. Über 64kB Flash/SRAM ist ganz klar ein 32Bitter das Mittel der Wahl. Da kommt mir kein 8Bitter mehr auf die Platine. Ich hab schon beim 8051 kein Banking (>64kB) benutzt, das war mir zu umständlich. Die Versuche, ihn zu pimpen (80251) von Atmel/Intel/Phillips sind alle kläglich gescheitert. Quasi war der 80251 der Xmega des 8051. Wenn sie wenigstens hoch auflösende ADCs hätten (>=16Bit), hätte ich ne Einsatzmöglichkeit. Und das die Xmega kein CAN können, gibt ihnen den Rest.
P.S.: Phillips hatte seinen erweiterten 8051 so gepimt, daß je 3 Register einen 24Bit Pointer bildeten und dann auch Flash und RAM hintereinander darin lagen (= Von Neumann), d.h. man hatte in den 4 Registerbänken insgesamt 8 Pointer mit 24Bit. Ob es dieser Typ überhaupt zu einer Keil C51 Version geschafft hatte, ist mir nicht bekannt. Es bringt einfach nichts, eine Architektur nachträglich für etwas aufzubohren, für das sie einfach nicht gedacht war.
Peter Dannegger schrieb: > Wenn sie wenigstens hoch auflösende ADCs hätten (>=16Bit), hätte ich ne > Einsatzmöglichkeit. ADC mit 16 Bit Auflösung, und das auf dem gleichen Die wie der Digitalspaß?!? Gibt es da überhaupt jemand, der das richitg beherrscht? Jens
Jens schrieb: > Gibt es da überhaupt jemand, der das richitg beherrscht? Z.B. Silabs, Analog Devices haben einige 8051 mit 16..24Bit ADCs.
:
Bearbeitet durch User
Jens schrieb: > Peter Dannegger schrieb: >> Wenn sie wenigstens hoch auflösende ADCs hätten (>=16Bit), hätte ich ne >> Einsatzmöglichkeit. > ADC mit 16 Bit Auflösung, und das auf dem gleichen Die wie der > Digitalspaß?!? > Gibt es da überhaupt jemand, der das richitg beherrscht? zB TI mit ihren MSP430. Beispiel: http://www.ti.com/product/msp430f6779 7 separate 24 SAR ADCs (die parallel wandeln) fchk
>> Natürlich gibt es auch noch die Artikel: >> Entscheidung Mikrocontroller und Mikrocontroller Vergleich >> die andere Controller näher beschreiben. Die sollten dringend überarbeitet werden, einfach zu alt und reflektieren nicht im geringsten den derzeitgen Stand.
Gegen Atmel spricht auch, dass es die JTAG Debug Kommandos nicht dokumentiert sind und bei den nicht-JTAG Bausteine fast jeder Baustein ein eigenes Flash/Debug Protokoll hat.
holger schrieb: >>und die XMegas sind >>eine sinnvolle Weiterentwicklung der älteren Baureihen, Vorzüge siehe >>weiter oben. > > Nur will sie kaum einer haben. Mich würden mal Belege interessieren für diese Behauptung. Die XMegas haben ein paar einzigartige Features, die sonst kein 8 oder 32 Bit Controller hat.
Hi, gnd3 schrieb: > Für einen PIC hatte ich schon das Layout fertig, dann ist Microchip > wegen seltsamer Lizenzbedingungen ausgeschieden (ja, vorher lesen macht > schlau). Naja, jetzt ist Atmel dran... Werde da doch mal etwas spezifischer... Im allgemeinen ist Microchip gerade was die Lizenzbedingungen ihrer Libs. angeht sehr Unproblematisch. (Solange man Die daraus entstandene Firmware auf ein Microchip µC spielt). Die meisten "Klagen" über die Lizenzbedingungen die ich gehört habe waren eher durch Missverständnisse begründet. Das heisst nicht das es keine Libs oder AN Beispielcodes mit Problematischen Lizenzen geben kann, insbesondere bei Fremdprodukten (Open source oder kommerzielle Libs von Drittanbietern) ist dies dann der Fall. Oder wenn man eine Technologie einsetzen möchte wo andere die Rechte dran haben und ggf. Lizenzgebühren verlangen (diverse Codecs). Das letztere ist dann aber kein Microchip spezifisches Problem sondern betrifft alle Mikrocontroller aller HErsteller gleichermaßen. Daher: Gib mal etwas konkretere Informationen zu deinem Lizenzproblem, dann kann man schauen ob da nicht bloß ein Missverständniss vorliegt oder ob es ein echtes Problem ist. Wobei man beim echten Problem dann wieder schauen muss ob sich das durch einen anderen Controller überhaupt lösen lassen würde oder in jedem Fall einschränkungen wie Sourcecodeveröffentlichung oder Lizenzgebühren hinzunehmen sind! (Egal welcher µC verwendet wird) Gruß Carsten
Simon K. schrieb: > Die XMegas haben ein paar einzigartige Features, die sonst kein 8 oder > 32 Bit Controller hat. Und die wären? Ich denke, ATMEL wird sich zukünftig auf ARM konzentrieren.
holger schrieb: > Nur will sie kaum einer haben. Atmels Problem ist wohl eher Verfügbarkeit denn als der Absatz. Peter Dannegger schrieb: > Über 64kB Flash/SRAM ist ganz klar ein 32Bitter das Mittel der Wahl. Das gut sein. Die Mehrheit der Apps (hier) bleibt darunter. wait for e w schrieb: > Simon K. schrieb: >> Die XMegas haben ein paar einzigartige Features, die sonst kein 8 oder >> 32 Bit Controller hat. > > Und die wären? Muss nicht alles hier wiedergekäut werden. Ab und zu lohnt wirklich mal genauere Beschäftigung mit den Teilen/Datenblättern. Gilt auch für Peter D. :-)
Uwe Bonnes schrieb: > Gegen Atmel spricht auch, dass es die JTAG Debug Kommandos nicht > dokumentiert sind und bei den nicht-JTAG Bausteine fast jeder Baustein > ein eigenes Flash/Debug Protokoll hat. Für welche Anwendung (hier) ist das nur entfernt relevant?
Tabaluga schrieb: > holger schrieb: >> Nur will sie kaum einer haben. > > Atmels Problem ist wohl eher Verfügbarkeit denn als der Absatz. Warum macht ATMEL sie nicht verfügbar? Braucht man die FAB für die ARM? :-D > Muss nicht alles hier wiedergekäut werden. Ab und zu lohnt wirklich mal > genauere Beschäftigung mit den Teilen/Datenblättern. Gilt auch für Peter > D. :-) Nö, es gibt keine Lücke, die durch das X gefüllt werden könnte.
Tabaluga schrieb: > Gilt auch für Peter > D. :-) Hab ich denn etwas übersehen? Gibt es doch welche mit ADC >12Bit und CAN?
Andreas schrieb: > Ich bleib lieber bei Chips die keine Bauern fangen ;-) Genau, ich bleib lieber bei Chips die technische und preisliche Daten vorweisen können, die in fast allen Optionen deutliche Vorteile gegenüber XMega bieten - und somit für Bastler besser geeignet sind. Die ganze AVR Fraktion sind für mich "Bauernfänger". Daher auch der recht neue Artikel: STM32 für Einsteiger Damit man den "Bauernfängern" mit der ganzen Information endlich das Handwerk legen kann.* (*) in Anwendungen mögen diese Chips niemals besser geeignet sein als welche mit einem Cortex-Mx Kern. Denn es gibt sicher Hersteller (Atmel, Energy Micro, Freescale, Holtek, TI, NXP, Nuvoton, ST, Toshiba, ...) die das gleiche Feature mit einem Cortex-Mx Kern auch haben und man somit mit einer Entwicklungsumgebung alles machen kann.
:
Bearbeitet durch User
@ Markus Müller (mmvisual) >Die ganze AVR Fraktion sind für mich "Bauernfänger". Schon wieder ein Kreuzzug? Ins heilige ARM-Land? >Damit man den "Bauernfängern" mit der ganzen Information endlich das >Handwerk legen kann. Gähn Hast DU schon mal ein Projekt fertiggestellt, das deine heißgelieben STM32 auch nur ansatzweise auslastet? Und ich meine jetzt nicht mit schlechter Programmierung und so . . .
Falk Brunner schrieb: > Schon wieder ein Kreuzzug? Ins heilige ARM-Land? Nun bist du schon so lange dabei und hast immer noch nicht gemerkt, dass MM seit Jahren auf diesem Kreuzzug ist? ;-)
Falk Brunner schrieb: > Hast DU schon mal ein Projekt fertiggestellt, das deine heißgelieben > STM32 auch nur ansatzweise auslastet? Und ich meine jetzt nicht mit > schlechter Programmierung und so . . . Jep. Ich hatte mal ein Design mit dsPIC und der war tatsächlich bei den PWM's zu langsam, bzw. konnte für die geforderte Frequenz nicht die Auflösung liefern. 3 Tage nach dieser Erkenntnis waren die Fachleute von Microchip bei uns in der Firma und die haben bestätigt, dass die KEINEN EINZIGEN in ihrem Sortiment haben, der das kann. Das war vor 6 Jahren. Der STM32 konnte das - Redesign war angesagt.
:
Bearbeitet durch User
Markus Müller schrieb: > Die ganze AVR Fraktion sind für mich "Bauernfänger". Was hat das mit Bauernfängerei zu tun? Atmel hat nun einmal µC im Angebot die für die meisten (Hobby-)Aufgaben vollkommen ausreichen und bietet dazu eine gescheite IDE sowie Programmer usw. zu halbwegs günstigen Preisen. Irgendwie muss es Atmel ja geschafft haben sich im Hobbybereich durchzusetzen, und ich wage zu bezweifeln, dass es daran liegt, dass die meisten Leute zu blöd oder ignorant sind geeignetere Alternativen zu erkennen. Und was deine STM32-Empfehlung angeht, warum sollte man solche ARM-Kraftpakete einsetzen, wenn ein kleiner MSP430, PIC, ATtiny, ATmega o.ä. auch schon ausreicht? Und wenn man tatsächlich die Leistung eines ARM braucht warum sollte man dann einen STM32 nehmen und z.B. keinen Atxmega oder SAM X (die ich z.B. für die bessere Wahl halte, wenn man gerade neu in diesem Segment einsteigt aber aus dem Atmel-Mikrokosmos kommt, d.h. mit der IDE und den Tools vertraut ist und schon passende Programmer/Debugger hat). Viele Grüße Daniel
:
Bearbeitet durch User
gnd3 schrieb: > was spricht eigentlich gegen die xmega? Gar nichts. Wenn man mit ihnen umgehen kann, sind es ganz angenehme Steine. Das "Upgrade" des Lernens vom klassischen AVR hin zum XMega hält sich aufgrund der bekannten Entwicklungsumgebung sehr in Grenzen und man kann sehr schnell zu adäquaten Entwicklungsergebnissen kommen. Bei mir lösen die XMegas mittlerweile die klassischen Megas ab, sowohl aus Leistungs- als auch aus Kostengründen. ARMs sind für meine Anwendungen nicht nötig und das Begreifen einer anderen Prozessorstruktur und der Umgang mit einer neuen (teuren) Entwicklungsumgebung bleibt mir vorerst erspart. Man muss ja nicht jeden Hype mitmachen, wenn es die Anforderung gar nicht braucht.
@ Markus Müller (mmvisual) >Jep. Ich hatte mal ein Design mit dsPIC und der war tatsächlich bei den >PWM's zu langsam, bzw. konnte für die geforderte Frequenz nicht die >Auflösung liefern. Beweise? Zahlen? STM32 kann ausser schnellen PWM nix? Schade.
> gescheite IDE sowie Programmer usw. zu halbwegs > günstigen Preisen. hmm. der "AT AVR ISP2" kostet bei Reichelt rund 37 Euro. Das Ding kann nichtmal debuggen (!). Schon komisch wenn ein komplettes Evaluationboard inklusive Debugging/Programming Funktion von ST dann schon für rund 8 Euro zu haben ist. Das "AVR-Programming Tool AT90 JTAG ICE MKII" Bei Reichelt kostet sogar 380 Euro. Es gibt da einfach einen eklatanten Unterschied bezüglich des Preis/Leistungs Verhältnisses. Ich habe damals mit Atmegas angefangen und war auch ein kleiner "Fanboy" der Teile. Als ich dann jedoch einmal den Schritt weg getan hatte, war das wie eine Erweckung (durchaus mit einem religiösen Erlebnis vergleichbar). :P Und seit man die 32-bitter schon für wenige Cent (< 1 Euro) hinterhergeworfen bekommt, spricht für mich eigentlich nichts mehr für 8 bit.
Falk Brunner schrieb: > @ Markus Müller (mmvisual) > >>Jep. Ich hatte mal ein Design mit dsPIC und der war tatsächlich bei den >>PWM's zu langsam, bzw. konnte für die geforderte Frequenz nicht die >>Auflösung liefern. > > Beweise? > Zahlen? Die Aufgabe war ein Magnet-Motor für ein Ventil. Gefordert war eine PWM Frequenz von 10KHz mit einer Auflösung von 1000 Schritten der Bewegung. Der Haken: die Bewegung von 100% Weg war bereits mit 20% Änderung des PWM Signals erreicht. Somit musste der PWM eine Auflösunf von ca. 5000 Zähler haben. Der STM32F103 konnte das: TIM1, mit 48MHz betrieben, teiler für 10000Hz = 4800 Zähler für die PWM Einstellung. Der dsPIC konnte nur um die 3000 und da war die Regelung nicht fein genug. > STM32 kann ausser schnellen PWM nix? Schade. Deine Meinung. Ab und zu solltest Du auch mal über den Tellerrand schauen. Knut Ballhause (Firma: TravelRec.) schrieb: > mit einer neuen (teuren) Entwicklungsumgebung Für den ARM gibt es genau so wie für AVR kostenlose und ohne Begrenzung nutzbare GCC Software. Ja sogar mit dem STM32 zu arbeiten ist weit aus günstiger: - STM32F4DISCOVERY Board gibt es für 9..20€ incl. Debugger! den man auch für eigene Projekte nutzen kann. ->> gegenvergleich alleine der AVR-Dragon kostet schon 40€ und ein MKII 380€ (Reichelt Preise)!!! - ein STM32 kann per serieller Schnittstelle von Haus aus programmiert werden (TTL-UART oder USB) ->> gegenvergleich für einen AVR muss man extra einen Programmer basteln oder kaufen Somit AVR Leute sind Bauernfänger. Überteuertes Entwicklungswerkzeug für schmalspurige Chips. Bisher kann hier NIEMAND der gesamten AVR Fraktion das Gegenteil beweisen, immer nur Heiße-Luft Postings ohne technische und nachvollziehbare Grundlagen. So wie hier: Beitrag "Re: was spricht eigentlich gegen die xmega?" Andreas bleibt mir immer noch die Antwort schuldig: Beitrag "Re: was spricht eigentlich gegen die xmega?"
:
Bearbeitet durch User
Was spricht gegen XMEGA ? ALLLES Was spricht dafür ? NICHTS. Ist so als ob du einen VW Golf mit einem 3liter V6 Motor bestückta uns alles mögliche umbaust. Es wird kein Sportwagen. Aber für DAS Geld was du da ausgegeben hast kannst du auch einen richtigen Sportwagen bekommen. Steht halt dann kein VW drauf, aber was solls...... Der XMEGA ist doch nur ein Versuch eine Veraltete Architektur auf neu zu Pimpen. Es macht mehr Sinn da den richtigen Schritt zu gehen. Solange die alte Architektur ausreicht nimm die. Brauchst du mehr Leistung geh direkt den richtigen Schritt und hole den aktuellen Industriestandard. Vom Preis her macht das auch keinen Sinn mehr. Die aktuellen Arms bekommst du Spottbillig. Und wenn du ein EvalBoard von STM oder TI holst hast du da eine komplette IDE inklusive Debugger für < 20 Euro.
mause-zahn schrieb: > der "AT AVR ISP2" kostet bei Reichelt rund 37 Euro. Das Ding kann > nichtmal debuggen (!). Schon komisch wenn ein komplettes Evaluationboard > inklusive Debugging/Programming Funktion von ST dann schon für rund 8 > Euro zu haben ist. Das "AVR-Programming Tool AT90 JTAG ICE MKII" Bei > Reichelt kostet sogar 380 Euro. Was hat denn der Programmer mit einem Evaluationsboartd zu tun? Wenn du schon vergleichst dann nimm z.B. bitte die "Xplained Pro"-Boards von Atmel, die bieten nämlich auch einen integrierten Debugger liegen aber mit ~30 bis 40€ natürlich über den ~8€ für das STM32F0DISCOVERY. mause-zahn schrieb: > Ich habe damals mit Atmegas angefangen und war auch ein kleiner "Fanboy" > der Teile. Als ich dann jedoch einmal den Schritt weg getan hatte, war > das wie eine Erweckung (durchaus mit einem religiösen Erlebnis > vergleichbar). :P Was ist für dich ein Schritt weg? Weg von Atmel? Weg von 8 Bit? Ich für meinen Teil habe hier auch ein Evaluationsboard mit einem STM32F407ZGT6 liegen. Ein super Teil, da werkele ich gerade mit asymmetrischen Kryptoverfahren herum, einfach weil der Controller die entsprechende Leistung bringt. Ich käme aber nie auf den Gedanken einen ARM (und sei es nur ein M0) z.B. für einfache LED-Ansteuerung in meinen Flugmodellen zu verschwenden, das wäre doch Perlen vor die Säue werfen. Selbst ein ATxmega wäre mir für sowas zu schade.
Knut Ballhause schrieb: > > gnd3 schrieb: > > was spricht eigentlich gegen die xmega? > > Gar nichts. Wenn man mit ihnen umgehen kann, sind es ganz angenehme > Steine. den Eindruck hatte ich eben auch > Das "Upgrade" des Lernens vom klassischen AVR hin zum XMega hält > sich aufgrund der bekannten Entwicklungsumgebung sehr in Grenzen das nun wieder nicht. Ich hab' mit Atmel noch garnichts gemacht und ich finde den Einstieg ziemlich schwer > ARMs sind für meine Anwendungen nicht nötig für meine erst recht nicht ;) > und das Begreifen einer anderen Prozessorstruktur und der > Umgang mit einer neuen (teuren) Entwicklungsumgebung bleibt mir > vorerst erspart. mir nicht, ich brauche auf jeden Fall was neues. Aber: STM32 braucht keine Entwicklungsumgebung. Eigentlich hatte ich mich ja auf zwei bestimmte Atmel Chips festgelegt, die Frage war nur noch (wir erinnern uns?), ob mega oder xmega. Aber flashen per UART ist so genial, da ist's mir egal, ob ein ARM dahinter steckt. Angefangen hatte das alles mit einer 8x16 mm kleinen Platine, da war ein ATtiny natürlich erste Wahl und der ATmega für die "große" Platine erstmal naheliegend. Der STM32 geht aber auch für beides! Das TSSOP-20 ist praktisch genauso groß wie ein SO-8, ich spare aber ISP-Pins (das UART ist sowieso rausgeführt). Faszinierend, ein ARM braucht weniger Platz als ein ATtiny! Auf der anderen Platine ist flashen per UART auch ein Bonus, weil das UART sowieso mit einem PC verbunden ist. Damit habe ich praktisch ein Programmiergerät fest eingebaut. Wieso gibt's überhaupt Progammer für STM32? Warum kauft man sowas? Also für mich ist das Thema damit abgeschlossen, tut mir leid für Atmel und Microchip. Ich hätte nicht gedacht, dass man mich so schnell ausgerechnet zu ST bekehren könnte, herzlichen Dank an alle!
gnd3 schrieb: > Auf der anderen Platine ist flashen per UART auch ein Bonus, weil das > UART sowieso mit einem PC verbunden ist. Damit habe ich praktisch ein > Programmiergerät fest eingebaut. Wieso gibt's überhaupt Progammer für > STM32? Warum kauft man sowas? Naja, für Debugging... was man zu kaufen bekommt sind doch JTAG/SWD-Interfaces!
> Ich käme aber nie auf den Gedanken einen > ARM (und sei es nur ein M0) z.B. für einfache LED-Ansteuerung in meinen > Flugmodellen zu verschwenden, das wäre doch Perlen vor die Säue werfen. > Selbst ein ATxmega wäre mir für sowas zu schade. Genau das verstehe ich nicht. Was meinst du mit Verschwendung? Der Preis kann es ja kaum sein. Ist es das Gefühl viel Leistung zur Verfügung zu haben, aber nur wenig davon zu nutzen? Ich nehme mittlerweile selbst für einfachste Dinge einen cortex M3. Warum auch nicht? Ein Atmega kostet doch genauso viel. Ich habe mir für Bastelsachen eine sehr kleine universelle Platine gemacht, wo cortex M3 oder M4 drauf kommt und die kann ich für alles anwenden was ich so brauche und sei es auch nur ein Blinklicht. Die Kosten sind kein Argument, der Platzbedarf ist kein Argument und die Komplexität erst recht nicht. Niemand zwingt mich alles zu nutzen was der Baustein kann. Aber das ist natürlich nur meine persönliche Philosophie.
Bei dem "Kanonen-Auf-Spatzen"-Argument habe ich auch manchmal das Gefühl das es hier nur um ein emotionales Argument geht. Der Anwender vermenschlicht gewissermaßen den Microkontroller und leidet mit ihm mit. Dies manifestiert sich dann häufig in dem Ausspruch "Der Controller langweilt sich doch". Der Controller langweilt sich nicht! Er hat keine Gefühle. Und wenn ein cortex M3 nur ein Lauflicht betreibt, dann ist das völlig ok! :-)
Hab kein ARM gefunden der an 3 PINS SPI, SPI mit halben Takt und das WS2801 (LED) Protokoll so ausgeben konnte, dass ein DMA genutzt werden kann. Außerdem brauchte ich noch zwei UARTs und eine weitere SPI Schnittstelle plus USB. Ganz nett ist auch, dass hier kein Quarz nötig ist. Hätte auch gern ARM genommen, hab mich dann aber für den XMega entschieden... Wer mag, kann mir ja den passenden ARM präsentieren. Vielleicht beim nächsten mal ;)
Carsten Sch. (dg3ycs) schrieb: > > gnd3 schrieb: > > Für einen PIC hatte ich schon das Layout fertig, dann ist Microchip > > wegen seltsamer Lizenzbedingungen ausgeschieden (ja, vorher lesen macht > > schlau). Naja, jetzt ist Atmel dran... > > Werde da doch mal etwas spezifischer... Ich dachte, ein PIC12 passt optimal auf meine Platine, Programmer hab' ich auch gefunden, es gäbe sogar eine Art IDE für Linux von Microchip. Mit dem sdcc und Debian sollte es auch gehen, also alles bestens. Aber dann: "crt0.o: no such file or directory". Was daran liegt, dass Debian diese und diverse Header aus Lizenzgründen nicht mitliefert. Die Lizenzen für die Header hab' ich bei Microchip nicht gefunden, also hab' ich mir die IDE für Linux geholt; da müssten die ja drin sein. Es gibt aber nur ein riesiges Binary ohne Begleittexte und einfach entpacken konnte ich es nicht. Na gut, wird's halt installiert. Die Installation richtet ein Verzeichnis "license" ohne Inhalt ein und verlangt dann root Rechte. An der Stelle hab' nochmal im Internet gesucht und z.B. die Lizenz für die "USB Framework software" gefunden :( > Im allgemeinen ist Microchip gerade was die Lizenzbedingungen ihrer > Libs. angeht sehr Unproblematisch. tja, da soll man Microchip das Recht auf eine Hausdurchsuchung einräumen, jederzeit und unangemeldet und nicht beschränkt auf meine Räume. O.K., da geht's um eine spezielle lib, das ist eigentlich nicht mein Problem, so weit komme ich ja garnicht. > Die meisten "Klagen" über die Lizenzbedingungen die ich gehört > habe waren eher durch Missverständnisse begründet. es kann eigentlich nur ein Missverständnis sein. Aber nachdem ich die entscheiden Texte nicht finde... > Das heisst nicht das es keine Libs oder AN Beispielcodes mit > Problematischen Lizenzen geben kann, insbesondere bei Fremdprodukten > (Open source oder kommerzielle Libs von Drittanbietern) ist dies dann > der Fall. > Oder wenn man eine Technologie einsetzen möchte wo andere die Rechte > dran haben und ggf. Lizenzgebühren verlangen (diverse Codecs). > Das letztere ist dann aber kein Microchip spezifisches Problem sondern > betrifft alle Mikrocontroller aller HErsteller gleichermaßen. Das ist schon klar und kein Problem, weil es da um genau abgegrenzte aufwendige Funktionen oder libs geht (wie auch die o.g.). Da kann man entscheiden, ob man die braucht. Beim sdcc fehlten aber die normalen, billigen Header. Was wäre eigentlich, wenn ich die selbst aus dem Datenblatt abtippe? Darf ich das auch nicht? > Wobei man beim echten Problem dann wieder schauen muss ob sich > das durch einen anderen Controller überhaupt lösen lassen würde > oder in jedem Fall einschränkungen wie Sourcecodeveröffentlichung > oder Lizenzgebühren hinzunehmen sind! Für Atmel gibt's den gcc-avr, da sind die Header mit einer BSD-Lizenz dabei. Bei ARM sieht's eher schlecht aus (mein Eindruck), aber es gibt immerhin auch einen gcc, das sollte reichen.
mause-zahn schrieb: > Ich nehme mittlerweile selbst für einfachste Dinge einen cortex M3. > Warum auch nicht? Ein Atmega kostet doch genauso viel. Kommt darauf an. Wenn man die größeren ATmegas mit den kleineren Cortex-M3 vergleicht dann sicherlich. Aber z.B. der ATmega88 ist regelmäßig deutlich günstiger als ein Cortex-M3, und wenn mir der Speicher und die Rechenleistung reichen, warum soll ich dann einen Cortex-M3 verbauen der knapp das doppelte kostet? Aber wenn du eine Quelle kennst, bei der man als Endverbraucher (aus Deutschland) günstig (~2€) an diverse Cortex kommt dann wäre es toll, wenn du mir sie nennen kannst, denn danach suche ich gerade, und wie es aussieht führt kein Weg an Digikey/Mouser vorbei, die Apothekenpreise vom blauen Klaus oder HBE zahle ich jedenfalls nicht :D
greg schrieb: > gnd3 schrieb: > > Auf der anderen Platine ist flashen per UART auch ein Bonus, weil das > > UART sowieso mit einem PC verbunden ist. Damit habe ich praktisch ein > > Programmiergerät fest eingebaut. Wieso gibt's überhaupt Progammer für > > STM32? Warum kauft man sowas? > > Naja, für Debugging... was man zu kaufen bekommt sind doch > JTAG/SWD-Interfaces! nee, schon klar, da hab' ich wohl vor lauter Begeisterung einen Smilie vergessen...
gnd3 schrieb: > "crt0.o: no such file or directory" O ha. Mir tut sich da beim Lesen von sowas ein Abgrund der Unfähigkeit auf. Du wirst doch wohl in der Lage sein, dir einen startupcode selbst zu schreiben oder wenigstens dessen Quelle mal durch den Assembler zu jagen. ODER??? W.S.
Markus Müller schrieb: > Andreas schrieb: >> naja für bastler ganz ok aber wie kann man halb getestete ICs in sein >> seriöses Projekt einbauen? >Value line klingt toll, ist sie aber nicht. >> Nur ein Beispiel fürn Flash: hier gerade mal 1k erase cycles garantiert. >> >> diese ganzen 32bit für 32cent ist nur deswegen so billig, da heutzutage >> ein sehr großer Brocken des Preises die Tests der Chips ausmacht. >> Verkürzt man die Tests, schließt man Tests aus, dann ist der Preis >> natürlich niedriger. > > Gibt es irgend welche Beweise für Deine These? > Berichte dass die "ValueLine" ständig kaputt gehen? > Internetlinks? wer sagt denn dass sie kaputt gehen? ich sagte nur dass eine value line weniger getestet wird, als bsp. die reduzierte erase cycles genannt die bei lächerlichen 1k liegt. dann kaufst du dir so einen chip, emulierst im flash eine eeprom und kannst ihn nicht mal vernünftig zur speicherung deiner daten nutzen. zum vergleich stm32f030 value line: 1k flash erase cycles endurance stm32f050 : 10k flash erase cycles endurance wenn man sich nun das lineup anschaut stellt man fest: nimmst du den kleinsten aus der billigen value line und benötigst du etwas mehr flash kommst du in eine sackgasse. du musst auf die (teureren) STM32F050 umsteigen da es in der value line nur ausgewählte part# gibt die eben so günstig sind. andersherum, während beim xmega du ohne probleme von einer high-end version z.b. atxmega64a3u auf die low-end variante atxmega64d3 umsteigen kannst wenn du nicht alle features nutzt und hast dann noch die freiheit ein device mit weniger oder mehr flash zu finden, bist du beim STM32F aufgeschmissen: - von einem STM32F051K8 hast du keine F030 Version - lässt du dich auf eine low cost variante ein, z.b. nimmst du zuerst eine F030K6 und brauchst dann mehr flash, musst du auf eine viel teurere version aufrüsten Hätte hier STM32F0 eine durchgehend flexible Lösung, wäre das brauchbar das ist durchgängige ST Praxis wie beim Mediamarkt die Leute mit billigen Preisen zu ködern, oder hat die MCU nix anderes zu bieten außer 32bit für 32cent? hat sich jemand mal gefragt warum wirbt der hersteller nicht mit features sondern mit dem preis? und wenn der ganze cortex hype so erfolgreich sein soll, warum überbieten sich freescale, efm32, st und infineon nur mit "der nächste xx cent cortex" anstelle mit Features zu trumpfen? und warum springt atmel nicht auf den zug drauf mit ihren samd20? jeder der o.g. hersteller hat auf sich mit "unter 50cent" aufmerksam gemacht, nur atmel nicht und microchip obwohl sie keine cortex haben werben auch nicht mit dem "aber wir haben <10cent mcu". vielleicht weil sie wissen was die ingenieure benötigen: 1) einfach zu verwenden 2) deadline einhalten 3) guten support jeder der sagt dass der preis das wichtigste ist soll zum media markt laufen und sich für 14euro seinen einkauf sichern...
W.S. schrieb: > gnd3 schrieb: > > "crt0.o: no such file or directory" > > O ha. Mir tut sich da beim Lesen von sowas ein Abgrund der Unfähigkeit > auf. Du wirst doch wohl in der Lage sein, dir einen startupcode selbst > zu schreiben wenn's sein muss; früher hab' ich für uC alles selber geschrieben. Aber bei anderen Herstellern als Microchip bekommt man das geschenkt. Das ist ein großer Unterschied, wenn sich die Chips nicht so sehr unterscheiden. > oder wenigstens dessen Quelle mal durch den Assembler zu jagen. es geht ja genau darum, dass Microchip eben diese Quelle nicht ohne weiteres hergibt.
gnd3 schrieb: > >> oder wenigstens dessen Quelle mal durch den Assembler zu jagen. > > es geht ja genau darum, dass Microchip eben diese Quelle nicht ohne > weiteres hergibt. doch, tun sie. Du solltest halt nur mal das richtige downloaden. Die IDe ist eben nur die IDE. Der Compiler für die jeweilige Architektur (8 Bit, 16 Bit, 32 Bit) ist extra. Und bei mir waren da immer auch die passenden Header und die Library-Sourcen dabei. Was Dich wohl eher stört, ist dass Microchip seinen Code nicht unter der GPL rausgibt, sondern unter einer kommerziellen Lizenz, die Dir ein einfaches Nutzungsrecht einräumt. Die ganzen Treiber und Protokollstacks darfst Du dafür dann aber auch problemlos in kommerziellen Produkten verwenden, ohne virale Kontraindikationen. Für mich war das immer ok so, wobei ich allerdings auch kein sonderlicher Open Source Verfechter bin. fchk
Hi, Carsten schrieb: > Die meisten "Klagen" über die Lizenzbedingungen die ich gehört > habe waren eher durch Missverständnisse begründet. > > es kann eigentlich nur ein Missverständnis sein. Aber nachdem ich die > entscheiden Texte nicht finde... Au Man(n?)! ICh denke hier liegt - um es mal sehr sehr höflich auszudrücken- ein riesen Missverständniss vor. 1. SDCC: Die Microchip eigenen Libs waren nativer Bestandteil von SDCC bis zum Versionswechsel auf 3.xx. Die Entscheidung diese Libs aus der Grundversion herauszunehmen hat NICHT Microchip getroffen sondern die SDCC Entwickler. Der Grund war das Microchip als einzig bindende Lizenzbedingung die Anforderung gestellt hat das diese Libs NUR für Entwicklungenverwendet werden in denen ein Microchip µC bzw. Schnittstellenbaustein (bsp. ENC28J60) zum Einsatz kommt. (Diese Einschränkung haben ALLE HArdwarehersteller in Ihren eigenen Libs! Oft noch mehr. Die ist nur bei absolut freien NICHT von den HArdwareherstellern herausgegebeenen Libs nicht vorhanden) Die Einschränkung das der mit diesen Libs erstellte Code nur mit Microchip Produkten genutzt werden darf verträgt sich nicht mit der Lizenz "GPL". Vermutlich um das Gesamtprojekt GPL kompatibel zu machen haben dann die SDCC Entwickler die Microchip Libs -neben einigen anderen!- aus dem Grundpaket herausgenommen. Die können aber einzeln nachinstalliert werden: "sdcc-libraries-nf" ist dein Freund! Das hättest du aber auch problemlos selbst herausbekommen können. Wer auf Linux setzt sollte zumindest in der Lage sein solche Dinge selbst zu recherchieren. Plug und Play ist schon mit Windows nicht voll machbar, aber bei Linux wird es haarig wenn man mehr als den Grundumfang der Distribution verwenden möchte und nicht selbst richtig nachlesen kann. Da SDCC keine Microchip Software ist findet man diese Dateien aber nicht für SDCC fertig aufbereitet auf deren Seiten... Und schon gar nicht wenn man nach Lizenzen sucht... Denn eine Lizenz ist eine Inmaterielle Gewährung gewisser Rechte, deren Umfang im SW oft durch die sogenannten Lizenzfiles festgehalten wird, was wiederrum reine Textdateien sind. Was du suchst sind reine Libs... 2. Mplab und Linux Was mit der MPLAB Installation bei dir los war keine Ahnung, ISt bei mir auch schon etwas länger her das ich mich mal an MPLAB unter Linux versucht habe. Ich meine für die Installation braucht man natürlich root rechte, aber bei der Programmausführung (oder gar fürs Programm?) ... Nee, nicht das ich mich erinnere. Aber Linux ist ja nicht gleich Linux... Also zusammenfassend zu sagen: Dein Problem hat NICHTS, aber wirklich gar nichts mit irgendwelchen besonders Nachteiligen Lizenzbedingungen zu tun gehabt. Sondern nur mit "Unwissenheit" bei der Programminstallation und der Grundsatzentscheidung der Programmentwickler nicht voll GPL kompatible Teile in einer eigenen Lib auszulagern... Gruß Carsten
:
Bearbeitet durch User
Frank K. schrieb: > Was Dich wohl eher stört, ist dass Microchip seinen Code nicht unter der > GPL rausgibt, sondern unter einer kommerziellen Lizenz, die Dir ein > einfaches Nutzungsrecht einräumt. Ich kenne das Microchip-Zeugs schlecht, aber was für eine Lizenz ist das denn? Ein einfaches Nutzungsrecht ist bei Sourcecode ja nicht so sinnvoll, den möchte man ja verändern dürfen, und sei es nur für eigene Zwecke. Frank K. schrieb: > Für mich war das immer ok so, > wobei ich allerdings auch kein sonderlicher Open Source Verfechter bin. Im Gegensatz dazu frage ich mich, warum im Bereich MCUs und eingebettete Systeme manchmal eine regelrechte Feindlichkeit gegen Open Source anzutreffen ist. Nach dem Motto "was nichts kostet, das taugt auch nichts" u.ä., ohne die Zusammenhänge zu verstehen, oder zu kapieren, dass Open Source nichts mit Freeware zu tun hat.
greg schrieb: > Frank K. schrieb: >> Was Dich wohl eher stört, ist dass Microchip seinen Code nicht unter der >> GPL rausgibt, sondern unter einer kommerziellen Lizenz, die Dir ein >> einfaches Nutzungsrecht einräumt. > > Ich kenne das Microchip-Zeugs schlecht, aber was für eine Lizenz ist das > denn? Ein einfaches Nutzungsrecht ist bei Sourcecode ja nicht so > sinnvoll, den möchte man ja verändern dürfen, und sei es nur für eigene > Zwecke. Das für gewisse Lizenzkonstrukte Namen haben ist ja eher die Ausnahme denn die Regel. Auch wenn der "Name" GPL auch für den 0815 Computernutzer meist schon ein Begriff ist. Das was bei Microchip gilt ist halt eine Individuelle Lizenzvereinbarung ohne speziellen Namen. Im Microchip Code findet sich dann üblicherweise dieser Text: //********************************************************************** ******** //Software License Agreement // //The software supplied herewith by Microchip Technology //Incorporated (the "Company") is intended and supplied to you, the //Company’s customer, for use solely and exclusively on Microchip //products. The software is owned by the Company and/or its supplier, //and is protected under applicable copyright laws. All rights are //reserved. Any use in violation of the foregoing restrictions may //subject the user to criminal sanctions under applicable laws, as //well as to civil liability for the breach of the terms and //conditions of this license. // Gibt auch irgendwo noch weitere Erläuterungen... Aber um es Abzukürzen: Du kannst den Code beliebig verwenden und verändern so lange die damit erstellte Software für ein Microchip µC bzw. Schnittstellenbaustein benutzt wird. Was du halt nicht darfst ist den Microchip USB Stack zu nehmen und den auf einen AT90USB einsetzen. (In den meisten Fällen ist soetwas ja auch recht Sinnbefreit da die umfangreichen Libs dann doch sehr Hardwarenah programmiert sind) > Frank K. schrieb: >> Für mich war das immer ok so, >> wobei ich allerdings auch kein sonderlicher Open Source Verfechter bin. > > Im Gegensatz dazu frage ich mich, warum im Bereich MCUs und eingebettete > Systeme manchmal eine regelrechte Feindlichkeit gegen Open Source > anzutreffen ist. Nach dem Motto "was nichts kostet, das taugt auch > nichts" u.ä., ohne die Zusammenhänge zu verstehen, oder zu kapieren, > dass Open Source nichts mit Freeware zu tun hat. Ich kann natürlich nicht für Frank sprechen, aber bei mir ist es keine wirkliche Feindlichkeit. Ich finde das es durchaus sehr gute OpenSource Software gibt. Es ist zumindest bei mir eher so das ich manchmal einfach den Kopf schüttele wenn einige Hardcore OpenSource Verfechter wieder einmal missionieren wollen und behaupten das NUR Open Source das einzig ware ist. (Das kommt dann halt manchmal anders rüber) Für mich kommt es nur auf die problemlose Nutzbarkeit und Hilfestellung bei Fragen an. Das kann bei Software A dann ein open Source Programm sein, bei Software B aber auch ein voll kommerzielles closed Source Produkt. Gruß Carsten
:
Bearbeitet durch User
Andreas schrieb: > Markus Müller schrieb: >> Andreas schrieb: >>> naja für bastler ganz ok aber wie kann man halb getestete ICs in sein >>> seriöses Projekt einbauen? >Value line klingt toll, ist sie aber nicht. >>> Nur ein Beispiel fürn Flash: hier gerade mal 1k erase cycles garantiert. >>> >>> diese ganzen 32bit für 32cent ist nur deswegen so billig, da heutzutage >>> ein sehr großer Brocken des Preises die Tests der Chips ausmacht. >>> Verkürzt man die Tests, schließt man Tests aus, dann ist der Preis >>> natürlich niedriger. >> >> Gibt es irgend welche Beweise für Deine These? >> Berichte dass die "ValueLine" ständig kaputt gehen? >> Internetlinks? > > wer sagt denn dass sie kaputt gehen? > ich sagte nur dass eine value line weniger getestet wird, als bsp. die > reduzierte erase cycles genannt die bei lächerlichen 1k liegt. dann > kaufst du dir so einen chip, emulierst im flash eine eeprom und kannst > ihn nicht mal vernünftig zur speicherung deiner daten nutzen. > zum vergleich > stm32f030 value line: 1k flash erase cycles endurance > stm32f050 : 10k flash erase cycles endurance > > wenn man sich nun das lineup anschaut stellt man fest: nimmst du den > kleinsten aus der billigen value line und benötigst du etwas mehr flash > kommst du in eine sackgasse. du musst auf die (teureren) STM32F050 > umsteigen da es in der value line nur ausgewählte part# gibt die eben so > günstig sind. > andersherum, während beim xmega du ohne probleme von einer high-end > version z.b. atxmega64a3u auf die low-end variante atxmega64d3 umsteigen > kannst wenn du nicht alle features nutzt und hast dann noch die freiheit > ein device mit weniger oder mehr flash zu finden, bist du beim STM32F > aufgeschmissen: > - von einem STM32F051K8 hast du keine F030 Version > - lässt du dich auf eine low cost variante ein, z.b. nimmst du zuerst > eine F030K6 und brauchst dann mehr flash, musst du auf eine viel teurere > version aufrüsten > Hätte hier STM32F0 eine durchgehend flexible Lösung, wäre das brauchbar > > das ist durchgängige ST Praxis wie beim Mediamarkt die Leute mit > billigen Preisen zu ködern Nun gut, Deine Chips haben 64KB Flash und 4KB RAM + EEPROM: atxmega64a3u : Mouser 3,49€ atxmega64d3 : Mouser 2,90€ bei STM32 sieht das so aus, die haben 8KB RAM: STM32F030R8 : Mouser 1,77€ + 24LC32 EEPROM 0,30€ = 2,07€ STM32L100R8 : Mouser 2,89€ (Incl. EEPROM) (Die anderen Werte sind in etwa gleich. Nun wie ich schon oben schrieb. Die AVR Fanboy-Gemeinde wollen nur Leute mit großen Sprüchen ködern - alles Bauernfänger. Wenn es an die nackten und für jeden überprüfbaren Tatsachen geht, dann gewinnt wieder einer aus der Cortex-Mx Welt. Wenn es mit einem speziellen Feature(*) nun mal nicht der STM32 ist, dann findet sich sicher einer von Atmel, Energy Micro, Freescale, Holtek, TI, NXP, Nuvoton, ST, Toshiba,... die ebenfalls einen Cortex-Mx verbaut haben. (*) bei der Anforderung "Extrem Stromsparend" sollte man eher bei PIC suchen - nicht bei Atmel. Bei den µC die Cortex-Mx verbauen gibt es wenigstens noch einen Preiskampf, das haben die Megas nicht nötig - als Monopolist. PS: Ich habe immer noch keinen Link gesehen, dass der "einfachere verkürzte Test": >>> Verkürzt man die Tests, schließt man Tests aus, dann ist der Preis >>> natürlich niedriger. zu mehr Problemen bei Endanwender führt oder dass irgend was nicht funktioniert. Es werden hier wieder mal nur Unwahrheiten verbreitet.
Carsten Sch. schrieb: > Ich kann natürlich nicht für Frank sprechen, aber bei mir ist es keine > wirkliche Feindlichkeit. Ich wollte für niemanden aus diesem Thread sprechen, aber das ist mir anderorts aufgefallen. Und klar, Open-Source-Zealots gibt's auch, insbesondere die RMS-Jünger sind manchmal schlimm...
Markus Müller schrieb: > dann findet sich sicher einer von Atmel, D.h. SAM3, SAM4, D20 usw. sind erlaubt? ;)
Markus Müller schrieb: > Nun wie ich schon oben schrieb. Die AVR Fanboy-Gemeinde wollen nur Leute > mit großen Sprüchen ködern - alles Bauernfänger. Das ist natürlich eine Ansage, für einen ARM Fanboy ;-)
greg schrieb: > Frank K. schrieb: >> Für mich war das immer ok so, >> wobei ich allerdings auch kein sonderlicher Open Source Verfechter bin. > > Im Gegensatz dazu frage ich mich, warum im Bereich MCUs und eingebettete > Systeme manchmal eine regelrechte Feindlichkeit gegen Open Source > anzutreffen ist. Nach dem Motto "was nichts kostet, das taugt auch > nichts" u.ä., ohne die Zusammenhänge zu verstehen, oder zu kapieren, > dass Open Source nichts mit Freeware zu tun hat. Ich bin kein Ideologe oder Politiker. Daher habe ich auch keine negativen Emotionen gegen Open Source - allerdings auch keine positiven. Ich nutze, was für mich funktioniert, egal welches Label draufsteht. Was ich nicht mag, ist die Vermischung von Politik und Technik. Wo man aufpassen muss, ist bei kommerziellen Produkten und Projekten. Ja, es gibt nicht nur Bastler, bei denen das egal ist, sondern auch Leute, die damit Geld verdienen. Und die wollen oder dürfen ihr Zeugs mitunter nicht open-sourcen. Da passen Lizenzen wie GPL eben nicht. Und so manche Software wird dann ganz schön teuer. Beispiel: das unsägliche V-USB, das ich kommerziell eh nie einsetzen würde. Für ein kommerzielles Produkt würde mich das auf einmal 500€ kosten(*). Den Microchip USB-Stack hingegen kann ich lizenzkostenfrei einsetzen, egal welche Stückzahlen. Dreimal darfst Du raten, für was ich mich entscheide. Also Augen auf beim Käsekauf! fchk (*) http://www.obdev.at/products/vusb/license-de.html
Daniel H. schrieb: > Markus Müller schrieb: >> dann findet sich sicher einer von Atmel, > > D.h. SAM3, SAM4, D20 usw. sind erlaubt? ;) Ja, klar, ich habe nichts gegen Atmel. Es ist eine gute Firma. Und jede Firma die µC mit einem ARM-Kern herstellt muss entsprechend sich preislich und Leistungsmäßig am Markt durchsetzen. Ich habe nur etwas gegen diese überteuerten AVR wo für einen gescheiten Debugger 380€ hingelegt werden muss. (PICkit 30€ / J-LINK EDU 50€ im Vergleich zu PIC / Cortex-Mx, wobei der J-LINK µC herstellerunabhängig ist!) Es wollen auch junge Schüler mal in den Genuss kommen etwas mit µC zu basteln und das sollte dann Gut+Günstig sein. Zudem hat man bei 8-Bittern auch noch andere Probleme zu bewältigen wie z.B. bei ISR, Stichwort "Read-Modify-Write"/Variablen ab 16 Bit und das gute alte ver-fusen.
Frank K. schrieb: > Beispiel: das unsägliche > V-USB, das ich kommerziell eh nie einsetzen würde. V-USB scheidet doch schon deshalb aus, weil es sich nicht wirklich an die Standards hält. Da sollte man doch lieber einen Controller mit USB-Peripherie nehmen. Frank K. schrieb: > Für ein kommerzielles > Produkt würde mich das auf einmal 500€ kosten(*). Genauer: du kannst V-USB problemlos kommerziell einsetzen, wenn die GPL für dich okay ist. Nur wenn du deinen Quellcode nicht veröffentlichen willst, musst du die alternativ lizensierte Version von obdev nehmen. Naja, wie auch immer, ich bin ebenfalls kein Fan der GPL. Open Source muss (IMHO) ohne Zwang funktionieren, und da sind dann permissive Lizenzen (BSDL & Co) angemessener. Die kann auch ein Nichtjurist verstehen und sie sind flexibler.
Markus Müller schrieb: > Ich habe nur etwas gegen diese überteuerten AVR wo für einen gescheiten > Debugger 380€ hingelegt werden muss. (PICkit 30€ / J-LINK EDU 50€ im > Vergleich zu PIC / Cortex-Mx, wobei der J-LINK µC herstellerunabhängig > ist!) Öhm, was ist mit dem AVR Dragon? Ist der nicht gescheit?
Markus Müller schrieb: > Ich habe nur etwas gegen diese überteuerten AVR wo für einen gescheiten > Debugger 380€ hingelegt werden muss. Diese Info ist veraltet. Den JTAGice3 bekommst Du bei Reíchelt für 99€, und der kann alles: ISP, TPI, PDI, JTAG, debugWire, und pogrammieren als auch debuggen (sofern die jeweilige Schnittstelle es zulässt). fchk
Der hat nicht einmal ein PVC Gehäuse und kostet auch schon 40€. Den wollte ich so nicht frei auf dem Arbeitsplatz herumliegen haben, wo immer mal Lötzinn und Drähte rumliegen. Auch taugt der nicht für alle AVR's. Der ST-Link/V2 kostet dagegen nur 20..30€ - dafür kann man den auch nur mit den STM's nutzen. (Im Gegensatz zum Segger J-LINK.)
OK, 99€ - werde ich mir merken. Ich habe den bei Reichelt gefunden: http://www.reichelt.de/Programmer-Entwicklungstools/AT-JTAG-ICE2/3/index.html?&ACTION=3&LA=446&ARTICLE=45038&GROUPID=2969&artnr=AT+JTAG+ICE2
Markus Müller schrieb: > OK, 99€ - werde ich mir merken. > Ich habe den bei Reichelt gefunden: > http://www.reichelt.de/Programmer-Entwicklungstools/AT-JTAG-ICE2/3/index.html?&ACTION=3&LA=446&ARTICLE=45038&GROUPID=2969&artnr=AT+JTAG+ICE2 Das ist der alte - der ist von der Hardware wesentlich aufwändiger. Braucht man nur noch, wenn man unbedingt AVRStudio 4 oder eine alte IAR-Version benutzen muss. Der 3'er ist hier zu finden: http://www.reichelt.de/Programmer-Entwicklungstools/AT-JTAG-ICE3/3//index.html?ACTION=3&GROUPID=2969&ARTICLE=111112&SEARCH=jtagice3&SHOW=1&OFFSET=500&; fchk
Markus Müller schrieb: > Der ST-Link/V2 kostet dagegen nur 20..30€ - dafür kann man den auch nur > mit den STM's nutzen. (Im Gegensatz zum Segger J-LINK.) Mit OpenOCD sollte damit doch alles gehen, was SWD spricht, oder?
Ich habe die 380€ auch schon auf 99€ im Artikel http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#Kosten abgeändert und den Link entsprechend auf die Atmel-Homepage angepasst. Hier sind bei der Spalte AVR noch ein paar "??" drin, die könnte ein AVR-Auskenner noch ersetzen: http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#Programmierumgebungen (Programmierumgebungen Linux und Mac) greg schrieb: > Markus Müller schrieb: >> Der ST-Link/V2 kostet dagegen nur 20..30€ - dafür kann man den auch nur >> mit den STM's nutzen. (Im Gegensatz zum Segger J-LINK.) > > Mit OpenOCD sollte damit doch alles gehen, was SWD spricht, oder? Ich bin mir jetzt nicht ganz sicher ob OpenOCD in der Zwischenzeit SWD kann, ansonsten ja. OpenOCD gibt es hier: http://www.freddiechopin.info/ >> Download >> OpenOCD Ich habe schon oft den Olimex-ARM-USB-OCD mit OpenOCD/JTAG genutzt. (Am besten Downloaden und das PDF Doku lesen.) Jedoch der Segger J-LINK läuft stabiler und ist nahezu doppelt so schnell, auch beim debuggen geht der Einzelstep deutlich schneller.
:
Bearbeitet durch User
Na endlich ràumt mal jemand mit dem Ammenmärchen eines 380 Euro Debuggers auf... Und ansonsten, um es mal auf den Punkt zu bringen: Für mehr als 2/3 der Projekte hier reichen locker AVRs, und den überwiegenden Rest erschlagen die XMegas. Alles andere ist akademische Diskussion. Die Situation ist vergleichbar mit den PC-Prozessoren: Mehr Leistung brauchen immer weniger, was zählt ist möglichst einfach und möglichst stromsparend. Wenn die höhere Leistung von ARM und Co wenigstens einer dramatischen Vereinfachung ihrer Programmierung zugute kommen würde- aber Fehlanzeige. Das Gegenteil ist der Fall. Überlasst ARM und Co Handys und anderen datenintensiven Gerätschaften, dort und nur dort machen sie Sinn.
Tintenfisch schrieb: > Und ansonsten, um es mal auf den Punkt zu bringen: Für mehr als 2/3 der > Projekte hier reichen locker AVRs, und den überwiegenden Rest erschlagen > die XMegas. Alles andere ist akademische Diskussion. Die Situation ist > vergleichbar mit den PC-Prozessoren: Mehr Leistung brauchen immer > weniger, was zählt ist möglichst einfach und möglichst stromsparend. Falsch: - Der Cortex-Mx muss nicht mit 168MHz betrieben werden, ohne PLL läuft der schon mit 16MHz und verbraucht entsprechend wenig Strom. (was auch für 2/3 der Projekte ausreicht und man muss die Clock's nicht einstellen). Und wenn man tatsächlich Strom sparen muss, dann nimmt man besser einen PIC18 oder PIC24 und keinen AVR: http://ww1.microchip.com/downloads/en/DeviceDoc/30009941F.pdf > Wenn die höhere Leistung von ARM und Co wenigstens einer dramatischen > Vereinfachung ihrer Programmierung zugute kommen würde- aber > Fehlanzeige. Das Gegenteil ist der Fall. Falsch: - Ein Cortex-Mx vereinfacht die Programmierung da bei Interrupts nicht so sehr auf das Read-Modify-Write geachtet werden muss. Auch hat die Peripherie mehr Funktionalität, was wiederum das Programmieren erleichtert da man Sonderfunktionen der HW direkt nutzen kann. > Überlasst ARM und Co Handys und > anderen datenintensiven Gerätschaften, dort und nur dort machen sie > Sinn. Falsch: - Ein Cortex-Mx wird wohl niemals in einem Handy eingesetzt werden, dafür ist der Cortex-Mx Core einfach nicht ausgelegt. Dafür ist ein Cortex-Ax geeignet, den ich hier nie empfohlen habe. Ein Cortex-Mx µC ist ein Chip mit maximaler Peripherie und Leistung zum kleinen und vernünftigen Preis.
Tintenfisch schrieb: > Für mehr als 2/3 der > Projekte hier reichen locker AVRs Und 3/3 kannst du mit ARM erschlagen. Warum soll ich einen Polo nehmen, wenn ich fürs gleiche Geld einen Passat bekomme. Nur weil der Polo auch fährt? Das ist doch total blödsinnig.
1) Die genügsamen XMegas laufen intern mit 2 MHz los, das langt in der Regel. Keine Clockeinstellung nötig. Die Umstellung auf intern 32 ist wenn nötig kurz und schmerzlos. Zumindest alle neueren laufen damit über den Temperaturbereich auch schön stabil- was etwa für die Uarts locker ausreicht. 2) Ein seltsames Verständnis von Vereinfachung Du hast :) Schon die Länge des Datenblatts spricht doch Bände. Im übrigen ist es ein Vorteil der AVRs daß deren Peripherie so simpel programmierbar ist. Immer mehr Funktionen mit immer flexiblerer Konfigurierbarkeit- das ist eben ein janusköpfiges Wesen, weil die vielen schönen Funktionen irgendwann keiner mehr nutzt und sie eher Verwirrung stiften.
Markus Müller schrieb: > Falsch: > - Der Cortex-Mx muss nicht mit 168MHz betrieben werden, ohne PLL läuft > der schon mit 16MHz und verbraucht entsprechend wenig Strom. (was auch > für 2/3 der Projekte ausreicht und man muss die Clock's nicht > einstellen). Naja. Ich hab mich mit dem Thema Stromsparen bei ARM-Controllern jetzt nicht in der Tiefe beschäftigt, aber bei einem kurzen Blick in die Datenblätter sah das nicht so rosig aus im Vergleich zu einem ganz normalen AVR oder PIC, gar nicht mal PicoPower oder NanoWatt oder was sich die Marketingabteilung sonst so ausdenkt. ;) Bei einem AVR, PIC & Co kann man mit Peripherie und allem was dazugehört bei niedrigem Takt deutlich unter 1 mA bleiben, und das ohne Sleep-Modi. Im Idle-Mode sind es dann wenige µA und im Powerdown-Mode bleibt man locker unter 1 µA und hat dabei noch das RAM versorgt. Sowas hab ich bei den ARMs nicht beobachtet.
waiting for e w schrieb: > Warum soll ich einen Polo nehmen, wenn ich fürs gleiche Geld einen > Passat bekomme. Nur weil der Polo auch fährt? Das ist doch total > blödsinnig. Den Polo nimmst Du weil Du ihn viel eher zum Laufen bekommst. Dann bist Du eher da wo Du hinwillst :)
Carsten Sch. (dg3ycs) schrieb: > Au Man(n?)! > ICh denke hier liegt - um es mal sehr sehr höflich auszudrücken- ein > riesen Missverständniss vor. > > 1. SDCC: > Die Microchip eigenen Libs waren nativer Bestandteil von SDCC bis zum > Versionswechsel auf 3.xx. Die Entscheidung diese Libs aus der > Grundversion herauszunehmen hat NICHT Microchip getroffen sondern die > SDCC Entwickler. und da fragte ich mich, warum haben sie das getan? Ich bin eben neugierig und es ist das erste Mal, dass ich mit kommerziellen Lizenzen zu tun bekomme. Na gut, eine Eagle-Lizenz, aber das ist doch was anderes. Für meine bisherigen Chips gab's immer nur Datenblätter, da gibt's solche Einschränkungen nicht (naja, nicht für Atomkraftwerke gedacht, o.k.). Notfalls hab' ich eben einen anderen Chip gekauft. Die ersten Assembler waren selbst geschrieben, dann gab's einen public domain, dann gcc/binutils > Der Grund war das Microchip als einzig bindende Lizenzbedingung die > Anforderung gestellt hat das diese Libs NUR für Entwicklungenverwendet > werden in denen ein Microchip µC bzw. Schnittstellenbaustein (bsp. > ENC28J60) zum Einsatz kommt. > (Diese Einschränkung haben ALLE HArdwarehersteller in Ihren eigenen > Libs!) das ist mir dank der sdcc-Geschichte eben erst klar geworden. > Vermutlich um das Gesamtprojekt GPL kompatibel zu machen haben dann > die SDCC Entwickler die Microchip Libs -neben einigen anderen!- > aus dem Grundpaket herausgenommen. > Die können aber einzeln nachinstalliert werden ja, oder durch die newlib ersetzt werden oder selbst geschrieben werden, das ist kein Problem. Ich brauche ja maximal einen kleinen Teil der libc. > Denn eine Lizenz ist eine Inmaterielle Gewährung gewisser Rechte, > deren Umfang im SW oft durch die sogenannten Lizenzfiles festgehalten > wird, was wiederrum reine Textdateien sind. > Was du suchst sind reine Libs... eben nicht, ich wollte diese Textdateien lesen > 2. Mplab und Linux > Was mit der MPLAB Installation bei dir los war keine Ahnung da ging's auch nur um die Lizenztexte, installieren wollte ich eigentlich nichts. Ein Debian-Paket kann man auspacken und findet dann die Texte in einem Unterverzeichnis. Was ich von Microchip runtergeladen hab', ließ sich nicht einfach auspacken, deshalb hab' ich woanders weiter gesucht. > Ich meine für die Installation braucht man natürlich root > rechte, aber bei der Programmausführung (oder gar fürs Programm?) ... auch eine Installation kann ohne root Rechte funktionieren. Wenn das Paket nicht genau zur Distribution passt, ist das sogar sehr empfehlenswert. MPLAB wollte sich nach /opt installieren, also habe ich ihm da ein Verzeichnis eingerichtet. Es wäre also kein Problem gewesen. > Dein Problem hat NICHTS, aber wirklich gar nichts mit irgendwelchen > besonders Nachteiligen Lizenzbedingungen zu tun gehabt. > Sondern nur mit "Unwissenheit" bei der Programminstallation und der > Grundsatzentscheidung der Programmentwickler nicht voll GPL kompatible > Teile in einer eigenen Lib auszulagern... diese Grundsatzentscheidung ist ja ganz normal, man kennt das von diversen Software-Projekten. Aber es geht eben auch einfacher (für den User). Der sdcc kann z.B. für den HCS08 übersetzen ohne dass man etwas nachinstallieren muss. Beim gcc-avr gibt's das "Problem" wahrscheinlich auch nicht. Und dann wieder: ohne diese Geschichte hättet ihr mich nicht auf die STM32 gestossen, die viel besser zu meiner Hardware passen. Und die Suche nach dem richtigen Programmer spare ich auch noch. Also vielen Dank!
greg schrieb: > Bei einem AVR, PIC & Co kann man mit Peripherie und allem was dazugehört > bei niedrigem Takt deutlich unter 1 mA bleiben, und das ohne Sleep-Modi. > Im Idle-Mode sind es dann wenige µA und im Powerdown-Mode bleibt man > locker unter 1 µA und hat dabei noch das RAM versorgt. > > Sowas hab ich bei den ARMs nicht beobachtet. soo groß ist der Unterschied nicht, z.B. MKL05Z32 (M0+, 32K Flash, 4K RAM): Very-low-power run mode current - 4 MHz core / 0.8 MHz bus and flash, all peripheral clocks enabled, code of while(1) loop executing from flash typ. 242.8uA, max. 631.8uA maximales Powerdown: typ. 221.7nA, max. 894.24nA na gut, bei 25 Grad, bei 85 werden es dann doch 25uA
Tintenfisch schrieb: > Im übrigen ist es ein Vorteil der AVRs daß deren Peripherie so simpel > programmierbar ist. Du scheinst außer AVR nix anderes zu kennen, oder? Die Peripherie gehört auch nicht zum ARM, sondern wird vom Halbleiterhersteller aus seinem eigenen Sortiment beigepackt. Tintenfisch schrieb: > Den Polo nimmst Du weil Du ihn viel eher zum Laufen bekommst. Findest du beim Passat das Zünschloss nicht?
waiting for e w schrieb: >Du scheinst...nix anderes zu kennen Genug um dann doch beim AVR zu bleiben :) > Findest du beim Passat das Zünschloss nicht? Genau. Und vieles andere auch nicht. Die Sicht verstellt viel Hardware, die zum spritsparenden Erreichen des Ziels nicht notwendig ist. Und Konfigurationsaufwand ohne Ende bedeutet. Ein armer Einsteiger, der damit das Fahren lernen soll, der doch eigentlich nur schnell ans Ziel kommen will.
gnd3 schrieb: > greg schrieb: >> Bei einem AVR, PIC & Co kann man mit Peripherie und allem was dazugehört >> bei niedrigem Takt deutlich unter 1 mA bleiben, und das ohne Sleep-Modi. >> Im Idle-Mode sind es dann wenige µA und im Powerdown-Mode bleibt man >> locker unter 1 µA und hat dabei noch das RAM versorgt. >> >> Sowas hab ich bei den ARMs nicht beobachtet. > > soo groß ist der Unterschied nicht, z.B. > MKL05Z32 (M0+, 32K Flash, 4K RAM): > > Very-low-power run mode current - 4 MHz core / 0.8 MHz bus and flash, > all peripheral clocks enabled, code of while(1) loop executing from > flash > typ. 242.8uA, max. 631.8uA > > maximales Powerdown: typ. 221.7nA, max. 894.24nA > na gut, bei 25 Grad, bei 85 werden es dann doch 25uA das ist die Kehrseite der Medaille, niedrige Prozessgeometrien = höherer Leakage current im low power mode, das betrifft alle Hersteller die in 90nm und tiefer gehen (Infineon soll in 65nm fertigen da ist es noch extremer) dafür sollen sie ja noch billiger können. while(1) loop bedeutet: kein Zugriff auf Flash, Pipeline "stalled", das ist ein ganz guter Marketing Trick den Stromverbrauch herabzusetzen. Wobei auf den EFM32 braucht man auch gar nicht so schielen, deren Angaben eines "Fibonacci Algorithmus" sind auch purer Trick den man glaubt wenn man keine Ahnung hat. Bei diesem Algorithmus werden Befehle ausgeführt die mehrere Zyklen benötigen, damit steht wieder die Pipeline länger was zu niedrigerem Stromverbrauch führt. Was wirklich zählt bei den meisten low power Anwendungen ist nicht die active power consumption, sondern power safe + watchdog + brown out detector (beim AVR BOD, beim MSP430 SVS). Markus Müller: > Überlasst ARM und Co Handys und > anderen datenintensiven Gerätschaften, dort und nur dort machen sie > Sinn. Falsch: - Ein Cortex-Mx wird wohl niemals in einem Handy eingesetzt werden, dafür ist der Cortex-Mx Core einfach nicht ausgelegt. Dafür ist ein Cortex-Ax geeignet, den ich hier nie empfohlen habe. Ein Cortex-Mx µC ist ein Chip mit maximaler Peripherie und Leistung zum kleinen und vernünftigen Preis. genau weil ein CortexM wohl zuviel strom verbraucht, deswegen setzen Microsoft in seinen Surface Pro einen 32Bit AVR ein, und in Samsung Tablets steckt ebenfalls ein 32Bit AVR. schon komisch obwohl Atmel auch einen SAMD20 gehabt hätte aber anscheinend ist ein ARM core nicht so effizient wie ein AVR32. Da hilft auch kein EFM32
Tintenfisch schrieb: > Genug um dann doch beim AVR zu bleiben Also keinen Einzeigen. :-( Tintenfisch schrieb: > Genau. Und vieles andere auch nicht. Dann solltest du Fahrrad fahren und es mit MCs lassen. ;-P Tintenfisch schrieb: > Ein armer Einsteiger, der damit das Fahren lernen soll So, so, die gängigen Fahrschulfahrzeuge sind Polo und gleichklassige? Bei uns sieht das anders aus.
steffen schrieb: > und in Samsung > Tablets steckt ebenfalls ein 32Bit AVR. Ist der Intel-ATOM ein AVR? http://www.heise.de/newsticker/meldung/Samsung-setzt-Intel-Prozessor-im-Samsung-Galaxy-Tab-3-ein-1875064.html
waiting for e w schrieb: > Tintenfisch schrieb: >> Genau. Und vieles andere auch nicht. > > Dann solltest du Fahrrad fahren und es mit MCs lassen. Richtig. Bei viel Verkehr ist man oft mit Fahrrad schneller und oft sogar zu Fuß. Merke: Immer die geeignetsten Mittel wählen. Mit Kanonen auf Spatzen ist eben wenig effizient! > Tintenfisch schrieb: >> Ein armer Einsteiger, der damit das Fahren lernen soll > > So, so, die gängigen Fahrschulfahrzeuge sind Polo und gleichklassige? > Bei uns sieht das anders aus. Na so langsam hinkt der Vergleich :) Was nichts daran ändert: Mit den 8-Bittern schneller am Ziel zu sein.
Tintenfisch schrieb: > Richtig. Bei viel Verkehr ist man oft mit Fahrrad schneller und oft > sogar zu Fuß. Ok, verstehe, für deine Anwendung reicht ein NE555. Bei mir nicht. Tintenfisch schrieb: > Was nichts daran ändert: Mit den > 8-Bittern schneller am Ziel zu sein. Wenn man nur AVR kennt, sollte man das nicht beurteilen.
Spätschicht schrieb: > Ist der Intel-ATOM ein AVR? In Handys und Tablets stecken neben dem Zentralprozessor zweifellos auch noch andere Prozessoren für Spezialaufgaben drin. Im hier betrachteten Kontext kann es nur um diese gehen.
:
Bearbeitet durch User
waiting for e w schrieb: > Tintenfisch schrieb: >> Richtig. Bei viel Verkehr ist man oft mit Fahrrad schneller und oft >> sogar zu Fuß. > > Ok, verstehe, für deine Anwendung reicht ein NE555. Bei mir nicht. Herablassung... > Tintenfisch schrieb: >> Was nichts daran ändert: Mit den >> 8-Bittern schneller am Ziel zu sein. > > Wenn man nur AVR kennt, sollte man das nicht beurteilen. und Unterstellungen- ich verstehe ja daß man hier nicht mehr entgegnen kann. Jeder will mal Porsche fahren, ist doch nur allzu menschlich. Kosten hin oder her.
Tintenfisch schrieb: > und Unterstellungen- ich verstehe ja daß man hier nicht mehr entgegnen > kann. Nö, für mich ist der ARM nicht schwieriger als ein AVR. Und ja, ich habe mehrere Projekte mit AVRs bearbeitet.
Spätschicht schrieb: > steffen schrieb: >> und in Samsung >> Tablets steckt ebenfalls ein 32Bit AVR. > > Ist der Intel-ATOM ein AVR? > http://www.heise.de/newsticker/meldung/Samsung-setzt-Intel-Prozessor-im-Samsung-Galaxy-Tab-3-ein-1875064.html nee, zb. hier http://www.mobilitytechzone.com/topics/4g-wirelessevolution/articles/2013/05/13/337815-atmel-sensor-hub-mcu-helps-enhance-samsung-galaxy.htm http://www.ifixit.com/Teardown/Microsoft+Surface+Teardown/11275 hier gings aber um Xmega, einige sagen es wäre eine Totgeburt und trotzdem wird Xmega auch in der Industrie eingesetzt: http://www.wirelessgoodness.com/2011/05/11/logitechs-k750-wireless-solar-powered-keyboard-gets-torndown-by-the-fcc/ auf alles AVR gibt Atmel übrigens ein 12jähriges Lifetime commitment ab, kann man beim Disti erfahren (ich hab die Info von Ineltek)
steffen schrieb: > nee, zb. hier > http://www.mobilitytechzone.com/topics/4g-wirelessevolution/articles/2013/05/13/337815-atmel-sensor-hub-mcu-helps-enhance-samsung-galaxy.htm Schon lustig, da ist auch ein PSoC mit Capsense onboard. steffen schrieb: > hier gings aber um Xmega, einige sagen es wäre eine Totgeburt und > trotzdem wird Xmega auch in der Industrie eingesetzt Das ist ein alter Schinken. Heute hätten die einen XMC1000 genommen. ;-)
Spätschicht schrieb: > Das ist ein alter Schinken. Heute hätten die einen XMC1000 genommen. ;-) Alter Schinken = ausgereift. Hat das keinen Wert? Man nehme aber die U-Varianten.
steffen schrieb: > hier gings aber um Xmega, einige sagen es wäre eine Totgeburt Für eine Totgeburt halten sich die Xmegas aber schon verdächtig lange! Das neuestes Mitglied, der E5 beweist doch, daß weiter frische Ideen in die innovative XMega Reihe gesteckt werden.
gnd3 schrieb: > Ein Debian-Paket kann man auspacken und findet dann > die Texte in einem Unterverzeichnis. Was ich von Microchip runtergeladen > hab', ließ sich nicht einfach auspacken Das ist mir auch schon sehr negativ aufgefallen. Vom Microchip bekommt man ein Executable in das man nicht reinschauen kann. Darüber hinaus besteht es darauf, als root ausgeführt zu werden (wofür überhaupt kein Grund besteht) und verweigert ansonsten schlicht die Arbeit. Damit konterkariert es jegliche Ansätze, ein System sauber zu halten. Ich meine wie oft bleuen wir den Einsteigern ein, keine Binaries aus unzuverlässiger Quelle auszuführen und vor allem nicht als root zu arbeiten. Und dann sowas! Ich habe jedenfalls ein Opfer-Debian in vmware aufgesetzt und dann MPLABX dort installiert. Ist weitgehend unspektakulär. Es entpackt tonnenweise Krempel nach /opt, und je eine Handvoll Files nach /etc und /usr/lib. Letzteres im wesentlichen für die USB-Unterstützung der Entwicklungstools (udev Regeln und Treibergedöhns). XL
gnd3 schrieb: > soo groß ist der Unterschied nicht, z.B. > MKL05Z32 (M0+, 32K Flash, 4K RAM): > Naja, es scheint einige ARMs zu geben, die recht effizient sind. Das ist aber nicht die Regel. ST z.B. hat eine Serie an low-power-ARMs (STM32L1) und die meisten anderen sind relativ verschwenderisch. Beim Kinetis scheint es auch diese Serie (L0) zu sein, die besonders low power ist. Darüber hinaus hat das Power Management eine große Komplexität, und um ordentlich Strom zu sparen, muss man immer die Versorgung für das SRAM abschalten. Bei den ARM-Controllern muss man also i.A. genau die richtige Controllerfamilie nutzen und eine Menge Arbeit in die softwareseitige Unterstützung für das Power Management stecken, um letztendlich auf das Level eines Wald-und-Wiesen 8-Bitters zu kommen. Finde ich jetzt nicht, dass der Unterschied klein ist.
Was spricht eigentlich gegen den Xmega war die Frage. Aus Hobbyperspektive nichts- wenn mit Blick auf geplante 3V Projekte dessen Leistung auf weit absehbare Zeit ausreicht. Vor allem nicht wenn man aus der vertrauten AVR Welt kommt, dann befeuern die zahlreichen neuen und innovativen Features die Kreativität ungemein :)
Da sich gerade die Spezialisten unter sich unterhalten - könnte mir einer von Euch sagen was bei den ATxmegas der Parameter # of Touch Channels aussagt. http://www.atmel.com/v2PFResults.aspx#%28actives:!%288238,8394,8431,8300,8358,8236,8449,8264,8254,8462,8400%29,data:%28area:%27%27,category:%2734864[33180[33083]]%27,pm:!%28%28i:8238,v:!%285,15%29%29,%28i:8394,v:!%288,10%29%29,%28i:8362,v:!%2815%29%29,%28i:8282,v:!%284%29%29,%28i:8431,v:!%288,25%29%29,%28i:8300,v:!%285,8%29%29,%28i:8358,v:!%2816,47%29%29,%28i:8392,v:!%281%29%29,%28i:8378,v:!n%29,%28i:8445,v:!%288%29%29,%28i:8236,v:!%2812,24%29%29,%28i:8449,v:!%282,8%29%29,%28i:8474,v:!%280%29%29,%28i:8248,v:!%281%29%29,%28i:8264,v:!%282,4%29%29,%28i:8447,v:!%281%29%29,%28i:8256,v:!%282%29%29,%28i:8254,v:!%286,12%29%29,%28i:8286,v:!%280,3%29%29,%28i:8462,v:!%281,8%29%29,%28i:8429,v:!%281,10%29%29,%28i:8458,v:!%281,4%29%29,%28i:8466,v:!%281%29%29,%28i:8400,v:!%284,18%29%29,%28i:8302,v:!%280%29%29,%28i:8278,v:!%280%29%29%29,view:table%29,sc:1%29 Bernd_Stein
Da hätte ich noch eine Frage. In dem Tutorial wird der ATxmega 128A3 verwendet. Ich möchte gern einen mit USB-Schnittstelle haben und mehr SRAM. Wenn ich den ATxmega 192A3U nehmen würde, könnte ich dem Tutorial dann immer noch folgen oder wären die Unterschiede so groß das einer der bisher nur bei den ATtinys geübt hat damit total überfordert ? http://www.jtronics.de/avr-projekte/xmega-tutorial.html Bernd_Stein
>nur bei den ATtinys geübt hat damit total überfordert ?
- Man hat einen Wunsch
- Dann sucht man die geeignete Peripherie anhand der Doku heraus
- Setzt die Register (bei USB nutzt man meist eine LIB passend zum µC)
Völlig egal was für ein µC das nun ist, völlig egal von welchem
Hersteller.
Nur muss man lesen können. Und kein Angst, die Dokus beißen nicht.
Ein Tutorial ist nur eine Hilfe, eine Erleichterung, da in der Doku
manchmal nicht das Beispiel so steht dass man es versteht.
:
Bearbeitet durch User
Bernd Stein schrieb: > Da hätte ich noch eine Frage. In dem Tutorial wird der > ATxmega 128A3 verwendet. > > Ich möchte gern einen mit USB-Schnittstelle haben und mehr SRAM. > Wenn ich den ATxmega 192A3U nehmen würde, könnte ich dem Tutorial dann > immer noch folgen oder wären die Unterschiede so groß das einer der > bisher nur bei den ATtinys geübt hat damit total überfordert ? > > http://www.jtronics.de/avr-projekte/xmega-tutorial.html Der Beispielcode sollte sich 1:1 verwenden lassen.
Markus Müller schrieb: > Oder frage mich: > STM32 CooCox Installation Offenbar scheint Dich niemand zu fragen, oder wie soll man die mittlerweile penetranten Hinweise auf Deine Artikel interpretieren? Welche Projekte von Dir finden sich in der Codesammlung, die die Leistung eines STM32F... benötigen und rechtfertigen würden? Mit der Suchfunktion bleibt man erfolglos. Hingegen liefern die Stichworte ATMEGA oder ATTINY erheblich mehr Treffer, als die zu STM32F. Offenbar sind die hiesigen Forumsteilnehmer damit besser bedient, oder auch mit PIC oder MSP430 ... Wenn Jemand mit den kleinen Controllern zufrieden ist, nervt das gebetsmühlenhaft wiederholte Stichwort ARM/Cortex ungemein. Und auch wieviel Cent man sparen kann, wenn man 10.000 Stück davon verwendet. Wenn jemand den ATXmega gut findet und einsetzen möchte: einfach machen!
Thomas F. schrieb: ....ATxmega 128A3 => ATxmega 192A3U..... >> http://www.jtronics.de/avr-projekte/xmega-tutorial.html > > Der Beispielcode sollte sich 1:1 verwenden lassen. > Danke. Markus Müller schrieb: > Völlig egal was für ein µC das nun ist, völlig egal von welchem > Hersteller. > Nur muss man lesen können. Und kein Angst, die Dokus beißen nicht. > > Ein Tutorial ist nur eine Hilfe, eine Erleichterung, da in der Doku > manchmal nicht das Beispiel so steht dass man es versteht. > Im übertragenen Sinne würde ich sagen ich lerne gerade lesen. Da ist es halt ein Unterschied, ob man ein Kinderbuch liest oder Shakespire. Ich möchte einen 16-Bit Wert von einem ADC einlesen und das in einem Zyklus, also sofort die gesamten 16-Bit aufeinmal. Jetzt lese ich gerade ATxmega 8/16 Bit. Kann der das überhaupt oder brauch ich hierzu einen reinen 16-Bitter ? Ich hatte früher mal am 68HC11 gelernt, AVR war da der Umstieg auf neuere 8-Bitter. Ist der HC12 ( 16-Bit ) zu empfehlen ? Wundere mich das man darüber wenig berichtet, da der HC11 ja sehr beliebt war. Oder ist der HC12 gar nicht der HC11 als 16-Bitter ? Bernd_Stein
Moby schrieb: > Aus > Hobbyperspektive > nichts- wenn mit Blick auf geplante 3V Projekte dessen Leistung auf weit > absehbare Zeit ausreicht Da wird aber die fehlende 5-Volt Toleranz der Atmel Bausteine übersehen.
@Bernd_Stein: Ein 68HC11 ist schon ein sehr altes Modell, den würde ich heute bei einer neuen Schaltung nicht mehr einsetzen wollen. Ein 8-Bit AVR kann natürlich 16Bit verarbeiten. Wenn man damit allerdings in Assembler rechnen will, dann wird das etwas kniffliger, daher besser die Hochsprache C nehmen. Bei einem 16 oder 32Bit µC kann man entsprechend 16Bit mit einem mal berechnen und somit ist auch ein programmieren in Assembler einfacher. Dennoch empfehle ich besser C zu nehmen, ist einfacher und Wartungsfreundlicher. Wenn Du unentschlossen bist was denn nun für µC der richtige für Dich ist, dann gibt es verschiedenen Artikel: - Entscheidung Mikrocontroller - Mikrocontroller Vergleich - STM32 für Einsteiger In Deinem Fall würde ich wohl zu einem MSP430 oder PIC24 raten, ich glaube mit dem würdest Du glücklich werden.
:
Bearbeitet durch User
Uwe Bonnes schrieb: > Da wird aber die fehlende 5-Volt Toleranz der Atmel Bausteine übersehen. > Stimmt. So ein Hobbylöter wie ich es bin - hat es glatt übersehen. Das ist doch mist, da braucht man wieder einen Spannungsregler ( 12V => 5V = 16-Bit ADC => 3,3V = µC ). Bernd_Stein
Uwe Bonnes schrieb: > Da wird aber die fehlende 5-Volt Toleranz der Atmel Bausteine übersehen. Ja deshalb ja auch ausdrücklich "3V Projekte". Bernd Stein schrieb: > Das ist doch mist, da braucht man wieder einen Spannungsregler > ( 12V => 5V = 16-Bit ADC => 3,3V = µC ). Dieser Trend ist dann aber alles andere als XMega-typisch... Immerhin, sehr viel und immer mehr Peripherie auf dem Markt ist damit kompatibel.
Markus Müller schrieb: > Bei einem 16 oder 32Bit µC kann man entsprechend 16Bit mit einem mal > berechnen und somit ist auch ein programmieren in Assembler einfacher. > Ich denke wenn ich schon weg vom DIL-Gehäuse komme und auf TQFP-64 umsteige, dann kann es auch ein 16-Bitter werden. Habe gelesen, das der Sprung zu 32-Bit preislich dann nicht mehr viel ist. Jedoch umso höher die Bitzahl, desto höher der Stromverbrauch. > > Dennoch empfehle ich besser C zu nehmen, ist einfacher und > Wartungsfreundlicher. > Ich mache die Sachen mit dem µC nur sehr sporadisch, also wenn ich mal eine Idee umsetzen möchte. Und von HC11 nach, AVR-Assembler zu C ist mir zu viel. > > Wenn Du unentschlossen bist was denn nun für µC der richtige für Dich > ist, dann gibt es verschiedenen Artikel: > > - Entscheidung Mikrocontroller > - Mikrocontroller Vergleich > - STM32 für Einsteiger > > In Deinem Fall würde ich wohl zu einem MSP430 oder PIC24 raten, > ich glaube mit dem würdest Du glücklich werden. > Danke, für deine Mühe. Da ich jedoch nicht so fit bin, denke ich es ist besser auf der AVR-Schiene zu bleiben. Der externe 16-Bit ADC macht 500kSPS und hat eine parallel-Schnittstelle die 8/16-Bit kann. Ich denke da ist dann genug Zeit 2x 8-Bit einzulesen und sogar noch in einem externen Speicher abzulegen bevor der nächste Wert vom ADC geliefert wird. Insofern bleibt eigentlich das einzig wichtige die USB-Schnittstelle. Und die gibts glaube ich erst bei den AVRs ab den Xmegas. Schade das es von den AVRs keine reinen 16-Bitter gibt. AVR war für mich damals der Umstieg, da die Assemblerprogrmmiersprache dem HC11 recht ähnlich ist. Zum Anderen gibt es die IDE kostenfrei, Programmer sind günstig ( es gibt sogar Nachbauprojekte ) AVRs sind bei Hobbylötern sehr beliebt, wegen dem DIL-Gehäuse. Das sind halt die Dinge die für mich für ATxmega sprechen. Bernd_Stein
gnd3 schrieb: > moin, moin, > > ein paar Punkte sind mir klar: > 1) keine 5 Volt Mittlerweile sehe ich das als Vorteil, dass die Dinger schon mit 3.3V alles können! In nem aktuellen Projekt bräuchte ich sonst mehr Pegelwandler! Die meisten ICs kommen auch gut mit 3.3V zurecht. Manche halten keine 5V mehr aus. > 2) nur bis 85 Grad spezifiziert Bei meinen Anwendungszwecken weniger relevant. Wenn ich da >85°C am Controller habe, dann hab ich größere Probleme ;-) > 3) stk500 geht nicht mehr für mich nicht relevant, hab es nie verwendet > 4) keine DIP-Gehäuse Wird Zeit, dass diese Dinosaurier endlich aussterben. Wie will man auch einen IC mit 100 Pins auf ein DIP-Gehäuse bringen? TQFP ist doch schön und gut. Lässt sich noch mit der Hand löten. (wobei es wieder speziellere AVRs gibt (die mit 2.4GHz Transceiver), die gibts nur noch mit QFN oder BGA. Liegt wohl an den Frequenzen!). Ich verwende die Atxmega durchaus noch, genauso wie einige Entwickler die ich kenne. Zwar ist das Preis-Leistungsverhältnis verglichen mit irgendwelchen Cortex Controllern nicht allzu gut. Aber man hat noch die Möglichkeit sehr Hardwarenah zu programmieren. Wenn man bisher mit Atmegas gearbeitet hat, dann ist der Umstieg auf die Atxmegas kein Problem. Wenn ich mich jetzt aber in einen ganz neuen Chip einarbeiten müsste, dann wäre das deutlich mehr Aufwand.
Rumpel Pumpel schrieb: > Hingegen liefern die Stichworte ATMEGA oder ATTINY erheblich mehr > Treffer, als die zu STM32F. Offenbar Tolle Wurst, in einem sehr stark AVR-lastigem Forum. > Wenn Jemand mit den kleinen Controllern zufrieden ist, nervt das > gebetsmühlenhaft wiederholte Stichwort ARM/Cortex ungemein. Naja, umgekehrt ist's auch nicht besser. In >90% der Threads wo sich einer über PIC, MSP430 und Co. informieren möchte, kommt ziemlich sicher irgendwas in die Richtung "nimm doch AVR". Das nervt mich persönlich zum Beispiel. Ich weiss auch nicht, ob diese Leute damit Atmel einen guten Dienst erweisen. Manchmal hat die AVR-Verehrung in diesem Forum ja fast schon religiöse Züge. Da gibt's dann seitenlange Threads, weil irgendwer in einem Autoradio zum Steuern des Bedienfelds einen AVR gefunden hat. Da kommen dann solche Threads wie Beitrag "Atmel AVR in der Industrie" oder Beitrag "ATMEL billiger und leistungsfähiger als PIC" oder Beitrag "Wieso vor allem AVR µCs bei Bastlern?" zustande. Wie sich die AVR-Gemeinde in solchen Threads gegenseitig bebauchpinselt darf man wohl oder übel als Fanboytum bezeichnen. Komisch, daß man sowas aus der PIC, MSP, Motorola, 8051er, $_youname_it -Ecke weit weniger liest. Um auf den polemischen Religions-Vergleich zurückzukommen: Die Religion der Atmelianer wäre dann wohl sowas wie die Zeugen Jehovas: Immer und überall präsent im Werbung machen, extrem hartnäckig (kommen immer wieder, auch wenn man nix von ihnen wissen will) und jedem, der nicht glaubt, wird eingeredet, er würde in der Hölle schmoren. > Wenn jemand den ATXmega gut findet und einsetzen möchte: einfach machen! Eben. Und wenn einer beim PIC seine große Liebe findet, dann ist da auch nichts verwerfliches dabei. Gerüchteweise solls sogar Leute geben, die eine Ehe mit dem 8051er haben und eine offe Liebschaft zum PIC, nebst Wochenendbeziehung zum Cortex und Techtelmechtel mit dem MSP. Sowas würde es bei den AVR-Jüngern natürlich nicht geben, die sind da eher romantischer, im Sinne von "es kann nur eine Liebe geben". N0R, heute mal etwas ironisch ;)
Johannes O. schrieb: > Aber man hat noch die > Möglichkeit sehr Hardwarenah zu programmieren. natürlich in ASM! Daß die AVRs inkl. XMega da noch so gut zugänglich und überschaubar sind schätze ich am meisten. Und auch Atmels Informationspolitik gibt sich bei weitem nicht so geheimnistuerisch und unübersichtlich wie manch ein anderer, größerer Hersteller :)
Bernd Stein schrieb: > AVR war für mich damals der Umstieg, da die Assemblerprogrmmiersprache > dem HC11 recht ähnlich ist. Zum Anderen gibt es die IDE kostenfrei, > Programmer sind günstig ( es gibt sogar Nachbauprojekte ) AVRs sind bei > Hobbylötern sehr beliebt, wegen dem DIL-Gehäuse. > Das sind halt die Dinge die für mich für ATxmega sprechen. Ein Kostenvergleich ist hier aufgelistet: http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#Kosten anhand der Liste ist der AVR mit der teuerste µC für den Einstieg.
Norbert M. schrieb: > Manchmal hat die AVR-Verehrung ... fast schon > religiöse Züge. Nun ja, im Gegensatz zur echten Religion liegen hier auch harte Pro-Argumente zugrunde :) Wenn mir eine Achitektur wie AVR den Einstieg so einfach ermöglicht hat man schon ein bischen Grund dankbar zu sein. PIC´s Pech war seinerzeit daß der 12F629 meines ersten uC Projekts so dermaßen umständlich programmierbar war daß ich sehr schnell auf Atmel/AVR umgeschwenkt bin.
Norbert M. schrieb: >> Wenn jemand den ATXmega gut findet und einsetzen möchte: einfach machen! > > Eben. Und wenn einer beim PIC seine große Liebe findet, dann ist da auch > nichts verwerfliches dabei. Gerüchteweise solls sogar Leute geben, die > eine Ehe mit dem 8051er haben und eine offe Liebschaft zum PIC, nebst > Wochenendbeziehung zum Cortex und Techtelmechtel mit dem MSP. Volle Zustimmung! > Um auf den polemischen Religions-Vergleich zurückzukommen: Die Religion > der Atmelianer wäre dann wohl sowas wie die Zeugen Jehovas: Immer und > überall präsent im Werbung machen, extrem hartnäckig (kommen immer > wieder, auch wenn man nix von ihnen wissen will) und jedem, der nicht > glaubt, wird eingeredet, er würde in der Hölle schmoren. ... und früher gab es die Religionen Märklin oder Fleischmann ;-)
Bernd Stein schrieb: > Ich hatte früher mal am 68HC11 gelernt, AVR war da der Umstieg auf > neuere 8-Bitter. Ist der HC12 ( 16-Bit ) zu empfehlen ? > Wundere mich das man darüber wenig berichtet, da der HC11 ja sehr > beliebt war. > Oder ist der HC12 gar nicht der HC11 als 16-Bitter ? Der HC12 ist auch schon wieder alt, aktuell ist HCS12. Freescale sortiert den bei 16 Bit ein. Er hat auch einen 16-Bit-Akku und Hardware-Mul und -Div bis zu 32/16=16+16Rest. Also wenn du in Assembler rechnen willst, ist er sehr angenehm. Und er ist wirklich nur ein erweiterter HC11, die Anleitung zum Umstieg auf HCS12 ist sehr kurz. Aber: ich hab' diesen Thread angefangen, weil mir der HCS12 zu schlecht lieferbar ist. Mag sein, dass man ihn ab 100,000 Stück leichter bekommt, aber soviel Lagerplatz hab' ich nicht ;)
Bernd Stein schrieb: > Ich möchte einen 16-Bit Wert von einem ADC einlesen und das in einem > Zyklus, also sofort die gesamten 16-Bit aufeinmal. Jetzt lese ich gerade > ATxmega 8/16 Bit. Kann der das überhaupt oder brauch ich hierzu einen > reinen 16-Bitter ? Du meinst einen externen ADC mit 16 Leitungen? Da hilft dir auch ein 16- oder 32-Bitter nicht unbedingt weiter, weil auch die ihren Ports typischerweise nur 8 Bits geben. D.h. die ALU könnte zwar 16 oder 32 Bits auf einen Rutsch verarbeiten, du bekommst sie aber nicht auf einen Rutsch eingelesen. Allerdings ist das nur höchst selten ein Problem, zumal bei der Eingabe. Da muß man nur alle Bits schnell genug abfragen, bevor die nächste Wandlung fertig ist. Abgesehen davon sind parallele Interfaces Schnee von gestern. Alles was mehr als 8 Bit braucht, macht man heutzutage seriell. > Ich hatte früher mal am 68HC11 gelernt, AVR war da der Umstieg auf > neuere 8-Bitter. Ist der HC12 ( 16-Bit ) zu empfehlen ? > Wundere mich das man darüber wenig berichtet, da der HC11 ja sehr > beliebt war. Sowohl der HC11 als auch der HC12 sind asbach-alt. Hauptnachteil ist der nichtvorhandene interne Flash. Ich mag die Teile eigentlich, aber für Neuentwicklungen ist man mit einem z.B. ATmega doch deutlich schneller. Schon weil man nicht erst ein Adreßlatch und externen Flash ranfummeln muß. > Oder ist der HC12 gar nicht der HC11 als 16-Bitter ? Nicht wirklich. Er ist ein aufgebohrter 8-Bitter. Aber als reiner 16-Bitter geht der bei mir nicht durch. XL
Angehängte Dateien:
-
050-bot.png
2,7 KB -
050-top.png
5,3 KB -
050-sch.png
7,9 KB
So, das habt ihr jetzt davon. Von wegen Kanonen und Spatzen, Perlen und Säue, Stromverschwendung und Silizium-Frevel: Meine erste STM32-Platine. 1 Pin für Nutzdaten, 2 für Strom, 4 zum Flashen und 32 Bit innen drin.
Axel Schwenke schrieb: > Sowohl der HC11 als auch der HC12 sind asbach-alt. Hauptnachteil ist > der nichtvorhandene interne Flash. deswegen gibt's ja jetzt den HC*S*12 mit 1MB ECC-Flash (wenn's etwas mehr sein darf): 64K RAM memory protection unit I/O coprocessor 2 12-Bit ADCs 5 CAN 8 16-Bit Timer und noch ein paar andere 8 PWM 3 SPI 8 UART 2 I²C 50 MHz, 3 bis 5 Volt
gnd3 schrieb: > So, das habt ihr jetzt davon. Glückwunsch! Endlich mal einer der nicht bloß rumlabert, sondern etwas macht. :-)
Dirk schrieb: > sondern etwas > macht. :-) ...etwas anfängt. Den Großteil der Arbeit ist eh Software. Und dann erst die spannende Frage: Hätts ein kleiner AVR nicht auch getan?
> Und dann erst die spannende Frage: Hätts ein kleiner AVR nicht auch > getan? Tja, zu spät, Chance vertan :)
Dummdödel schrieb: > Und dann erst die spannende Frage: Hätts ein kleiner AVR nicht auch > getan? Aber aber, wir haben doch gelernt, dass das esotherisches Gequatsche ist, das sich so ein µC ja nicht langweilt und man ihn daher auch auch nicht quälen kann, wenn man ihn wenig bis gar nicht auslastet. Ich bin schon vor langen Jahren dazu übergegangen, für jedes Projekt ein ITX-Board mit Intel Xeon zu verwenden. Kosmisch betrachtet ist der Preis ja vernachlässigbar, da macht es keinen Unterschied ob ich nun einen Attiny, einen Cortex oder einen Intel Xeon nehme. Das funktioniert soweit auch ganz gut, kleine Blinkschaltungen mit LEDs sind kein Problem, ich habe sogar einmal tatsächlich ein Relais damit angesteuert. Ok, der Stromverbrauch ist etwas höher, aber ich sag mal so, das Stahlwerk um die Ecke verbraucht ja viel mehr Energie, da macht das bischen für den Intel Xeon auch nichts aus.
So wie der Trend, mit einem Raspberry Pi, einem noch vor 10 Jahren fast unvorstellbaren SoC mit 1/2 GB SDRAM + GPU + PiPaPo Relais, LEDs und andere Belanglosgkeiten anzusteuern . . . Und das mit eher zusätzlichem Aufwand, wenn es etwas besseres Timing sein soll, denn man muss sich dann mit dem Linux um den Prozessor streiten. Brave new world.
gnd3 schrieb: > Aber: ich hab' diesen Thread angefangen, weil mir der HCS12 zu schlecht > lieferbar ist. Mag sein, dass man ihn ab 100,000 Stück leichter bekommt, > aber soviel Lagerplatz hab' ich nicht ;) > Hab mal bei Digi-Key geguckt unter 32Mhz-Typ S9S12HA32... würde man auch einzeln bekommen, aber 18,00 Euro Versand ist natürlich happig. Kommt wohl direkt aus den USA. Naja, so wie ich es leider lese ist der HC/S 12 wohl leider nicht so angesagt, also nichts für Hobbylöter. Axel Schwenke schrieb: > Du meinst einen externen ADC mit 16 Leitungen? Da hilft dir auch ein 16- > oder 32-Bitter nicht unbedingt weiter, weil auch die ihren Ports > typischerweise nur 8 Bits geben. D.h. die ALU könnte zwar 16 oder 32 > Bits auf einen Rutsch verarbeiten, du bekommst sie aber nicht auf einen > Rutsch eingelesen. > Ja, das meine ich - einen mit 16 Leitungen. Tja, so ist das wenn man keine Ahnung hat. Gut das ich nicht weiter nach einem 16-Bitter geguckt habe. Habe mich jetzt für den ATxmega 192A3U-AUR entschieden. > > Allerdings ist das nur höchst selten ein Problem, zumal bei der Eingabe. > Da muß man nur alle Bits schnell genug abfragen, bevor die nächste > Wandlung fertig ist. Abgesehen davon sind parallele Interfaces Schnee > von gestern. Alles was mehr als 8 Bit braucht, macht man heutzutage > seriell. > Aber doch nicht wenn es schnell gehen soll. Der ADC vom Typ ADS 8323 scheint von 2001 zu sein, mindestens das Datenblatt wurde 2010 überarbeitet und der stellt schlauerweise einen 8/16-Bit Modus bereit. Mir kann doch Niemand erzählen, das irgend ein serielles Interface eine Gewindigkeitskonkurenz für 16-Bit parallel sein könnte. gnd3 schrieb: > deswegen gibt's ja jetzt den HC*S*12 mit 1MB ECC-Flash (wenn's etwas > mehr sein darf): > 64K RAM > memory protection unit > I/O coprocessor > 2 12-Bit ADCs > 5 CAN > 8 16-Bit Timer und noch ein paar andere > 8 PWM > 3 SPI > 8 UART > 2 I²C > 50 MHz, 3 bis 5 Volt > Ich danke Euch allen für die Informationen, die Ihr mir erbracht habt und auch das Ihr auf meine Fragen eingegangen seid. Als Hobbylöter wechselt man glaube ich nicht so einfach den µC, deswegen bleibe ich beim AVR und übe mich mal an den ATxmegas und hoffe dann weiter unterstützung hier im Forum zu erhalten. Der ATxmega 192A3U-AUR ist leider erst Anfang Februar 2014 da, aber bis dahin habe ich eh noch viel zu tun. Bis dann Bernd_Stein
Falk Brunner schrieb: > So wie der Trend, mit einem Raspberry Pi, einem noch vor 10 Jahren fast > unvorstellbaren SoC mit 1/2 GB SDRAM + GPU + PiPaPo Relais, LEDs und > andere Belanglosgkeiten anzusteuern . . . Immer von der geplanten App her denken bewahrt vor solchen Absurditäten. Wenn dabei dann aber(leider) rauskommt 8-Bit reicht erzielt das nicht den Eindruck den mancher vielleicht schinden möchte- gnd3 schrieb: > 32 Bit innen drin klingt doch so schööön!
Einzeln bei Digikey 6,05€, bei 25 Stück 5,08€ und bei 100 4,12€
Bernd Stein schrieb: > Da sich gerade die Spezialisten unter sich unterhalten - könnte mir > einer von Euch sagen was bei den ATxmegas der Parameter > > # of Touch Channels du kannst dir die kostenlose QTouch library auf diesem Controller nutzen, die max. Anzahl der Kanäle wird damit angegeben die einen Button, Wheel oder Slider formen können. Während ein Button einen Kanal benötigt, braucht ein Wheel oder Slider drei Kanäle. Übrigens zu deiner Frage mit den 16Bit einlesen: Der SAM3S oder SAM4S von Atmel könnte für dich interessant sein. Dieser kann 8/16/24/32Bit daten von einer externen Komponente tatsächlich parallel einlesen, unabhängig vom ARM core. Das heißt für dich dank DMA ohne die CPU auszulasten. Das heißt bei Atmel parallel capture interface. Das Feature ist aber unabhängig davon ob ARM oder nicht ARM, das ist Atmels eigenentwicklung
Martinb. schrieb: > Bernd Stein schrieb: >> Da sich gerade die Spezialisten unter sich unterhalten - könnte mir >> einer von Euch sagen was bei den ATxmegas der Parameter >> >> # of Touch Channels > > du kannst dir die kostenlose QTouch library auf diesem Controller > nutzen, die max. Anzahl der Kanäle wird damit angegeben die einen > Button, Wheel oder Slider formen können. Während ein Button einen Kanal > benötigt, braucht ein Wheel oder Slider drei Kanäle. > Danke. Verstehe ich zwar nicht ganz, aber ich weiß zumindest schonmal worum es geht. > > Übrigens zu deiner Frage mit den 16Bit einlesen: Der SAM3S oder SAM4S > von Atmel könnte für dich interessant sein. Dieser kann 8/16/24/32Bit > daten von einer externen Komponente tatsächlich parallel einlesen, > unabhängig vom ARM core. Das heißt für dich dank DMA ohne die CPU > auszulasten. Das heißt bei Atmel parallel capture interface. Das Feature > ist aber unabhängig davon ob ARM oder nicht ARM, das ist Atmels > eigenentwicklung > Nein danke, als Hobbylöter möchte ich keine andere Assemblersprache mehr lernen und C liegt noch in weiter Zukunft. Bernd_Stein
@ Bernd Stein (bernd_stein) >Nein danke, als Hobbylöter möchte ich keine andere Assemblersprache mehr >lernen und C liegt noch in weiter Zukunft. Einen 32 Bit Controller programmiert man heut auch praktisch gar nicht mehr in Assembler, das bringt wenig bis nichts. Ausnahmen sind Treiber und Compilerbauer.
Falk Brunner schrieb: > Einen 32 Bit Controller programmiert man heut auch praktisch gar nicht > mehr in Assembler, das bringt wenig bis nichts. Das gilt auch für kleinere Controller. Die Compiler sind sehr gut und optimieren oft besser als der ASM-Programmierer.
> Warum soll ich einen Polo nehmen, wenn ich fürs gleiche Geld einen > Passat bekomme. Nur weil der Polo auch fährt? Das ist doch total > blödsinnig. Völlig egal mit welchem Auto du die 3 Meter fährst ;)
> Was nichts daran ändert: Mit den > 8-Bittern schneller am Ziel zu sein. Kann ich nicht bestätigen! Allerdings müsste man für eine gewisse Repräsentativität wohl eine Studie mit vielen Nutzern machen. Ich habe den Einstieg in die AVRs genauso schwer in Erinnerung wie in die Cortex. Was mich damals bei den AVRs ausbremste waren die Fuses. Da hatte ich ein wenig Pech.
mause-zahn schrieb: >> Was nichts daran ändert: Mit den >> 8-Bittern schneller am Ziel zu sein. > Ich habe den Einstieg in die AVRs genauso schwer in Erinnerung wie in > die Cortex. Letzteres vielleicht auf Basis schon vorhandenen AVR-Wissens? Das wärs dann mit 'genauso' !?
Moby schrieb: > mause-zahn schrieb: >>> Was nichts daran ändert: Mit den >>> 8-Bittern schneller am Ziel zu sein. >> Ich habe den Einstieg in die AVRs genauso schwer in Erinnerung wie in >> die Cortex. > > Letzteres vielleicht auf Basis schon vorhandenen AVR-Wissens? Das wärs > dann mit 'genauso' !? gut möglich - schwer zu sagen.
mause-zahn schrieb: > Was mich damals bei den AVRs ausbremste waren die Fuses. Die hat man aber bei den Xmegas (fast) nicht mehr. ;-) Die ganze Taktumstellerei geht dort (wie auch bei ARM) "on the fly".
Jörg Wunsch schrieb: > Die ganze > Taktumstellerei geht dort (wie auch bei ARM) "on the fly". Nein, nein, das ist zuviel Fortschritt für die Jungs hier! >;->>>
Jörg Wunsch schrieb: > Die hat man aber bei den Xmegas (fast) nicht mehr. ;-) Aber das war doch einer der großen Vorteile der AVR. Wie blöd jetzt. ;-)
Beast schrieb: > Jörg Wunsch schrieb: >> Die hat man aber bei den Xmegas (fast) nicht mehr. ;-) > > Aber das war doch einer der großen Vorteile der AVR. Wie blöd jetzt. ;-) Quark. <Verständnisvoll> Die Wahrheit daß es 8-Bitter nur zu oft auch tun ist für die Jungs mit den dicken Brummern eine bittere Pille </Verständnisvoll>
Bernd Stein schrieb: >> ... Abgesehen davon sind parallele Interfaces Schnee >> von gestern. Alles was mehr als 8 Bit braucht, macht man heutzutage >> seriell. > Aber doch nicht wenn es schnell gehen soll. Das kommt wohl auf die Definition von "schnell" an. > Der ADC vom Typ ADS 8323 scheint von 2001 zu sein, mindestens das > Datenblatt wurde 2010 überarbeitet und der stellt schlauerweise einen > 8/16-Bit Modus bereit. Mir kann doch Niemand erzählen, das irgend ein > serielles Interface eine Gewindigkeitskonkurenz für 16-Bit parallel sein > könnte. Einmal darfst du raten wofür das S in SATA steht. Und die Tatsache, daß SATA PATA abgelöst hat (und der serielle PCIe den parallelen PCI Bus) spricht wohl auch für sich. XL
Axel Schwenke schrieb: > Und die Tatsache, daß > SATA PATA abgelöst hat (und der serielle PCIe den parallelen PCI Bus) > spricht wohl auch für sich. Naja, wenns richtig schnell gehen soll, sind z.B. Speicher parallel angebunden und auch auf Grafikkarten wird parallel in die RAMs geschaufelt. SATA ist einfach besser hot-plug fähig, genauso wie USB und wie sie alle heissen (wobei sie sich bei den SATA Steckern nicht wirklich mit Ruhm bekleckert haben) Und PCI-E Grafik wird zumindest in meinem System auch parallel angesteuert.
> Ein Kostenvergleich ist hier aufgelistet: > http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#Kosten > anhand der Liste ist der AVR mit der teuerste µC für den Einstieg. Woran hast Du das abgelesen? Da steht: Einzelchip (Einzelstückpreise) STM32: 2..15€ AVR: 0,6–5€ PIC: 1-15€ Der niedrigste Preis steht ganz eindeutig bei AVR. Der höchste Preis steht bei PIC und STM32. Für Hobbyelektroniker zählt jedoch nicht nur der Einzelpreis, sondern auch die Verfügbarkeit von Einzelstücken für Privatkunden, sowie die Versandkosten. Stell Dir vor, ich kaufe Bei Händler X: Den Mikrocontroller für 10 Cent + 7 Euro Versandkosten Bei Reichelt: Alle anderen Teile im Wert von 95 Euro + 7 Euro Versandkosten Da kann ich gleich besser alles bei Reichelt bestellen, selbst wenn die den Controller sauteuer machen. Das ist doch die Situation, in der die Hobbyelektroniker stecken, also die meisten Teilnehmer dieses Forums.
Matthias Sch. schrieb: > Und PCI-E Grafik wird zumindest in meinem System auch parallel > angesteuert. PCI-Express ist im Grunde serieller Natur. Nur verwendet man abhängig von der benötigten Bandbreite mehrere serielle Verbindungen parallel. Einfache I/O verwendet im kleinen Stecker nur 1 Lane, wenns nicht ausreicht 4, Grafik 8-16. Das klingt jetzt ein wenig nach Sprachspiel, aber der Unterschied liegt in der Taktung. Serielle Übertragungen dieser Art takten sich aus dem einzelnen Signal selbst, während parallele Übertragung (wie SDRAM) einen separaten Takt für mehrere Leitungen verwendet und damit mit zunehmender Geschwindigkeit und Entfernung Probleme mit Laufzeitdifferenzen bekommt.
:
Bearbeitet durch User
Matthias Sch. schrieb: > Axel Schwenke schrieb: >> Und die Tatsache, daß >> SATA PATA abgelöst hat (und der serielle PCIe den parallelen PCI Bus) >> spricht wohl auch für sich. > > Naja, wenns richtig schnell gehen soll, sind z.B. Speicher parallel > angebunden und auch auf Grafikkarten wird parallel in die RAMs > geschaufelt. SATA ist einfach besser hot-plug fähig, genauso wie USB und > wie sie alle heissen (wobei sie sich bei den SATA Steckern nicht > wirklich mit Ruhm bekleckert haben) > Und PCI-E Grafik wird zumindest in meinem System auch parallel > angesteuert. Hallo, also schaut Euch mal richtige Server an, da ist nix mehr mit parallel und auch kein Sata, nur Glasfaser bei 10Gb und darüber. Gruß, Michael
Michael Appelt schrieb: > also schaut Euch mal richtige Server an, da ist nix mehr mit parallel > und auch kein Sata, nur Glasfaser bei 10Gb und darüber. Die Kommunikation zwischen Prozessor-Sockeln und zu I/O-Hubs ist zwar paketbasiert, aber mit einer separaten Taktleitung für mehrere Datenleitungen, darf also als im Kern parallel angesehen werden. Siehe Intel QPI und AMD Hypertransport. Der Speicher ist ebenfalls parallel angebunden. Was freilich nur auf sehr kurze Distanzen gut funktioniert. Massenspeicheranbindung erfolgt nicht selten per SAS, was technisch eng mit SATA verwandt ist. Was freilich beides seriell ist.
:
Bearbeitet durch User
greg schrieb: > Bei einem AVR, PIC & Co kann man mit Peripherie und allem was dazugehört > bei niedrigem Takt deutlich unter 1 mA bleiben, und das ohne Sleep-Modi. > Im Idle-Mode sind es dann wenige µA und im Powerdown-Mode bleibt man > locker unter 1 µA und hat dabei noch das RAM versorgt. > > Sowas hab ich bei den ARMs nicht beobachtet. Dann schau dir z.B. mal die STM32L1-Serie an: – 0.3 μA Standby mode (3 wakeup pins) – 0.9 μA Standby mode + RTC – 0.57 μA Stop mode (16 wakeup lines) – 1.2 μA Stop mode + RTC – 9 μA Low-power Run mode – 214 μA/MHz Run mode http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1295
Stefanus schrieb: >> Ein Kostenvergleich ist hier aufgelistet: >> http://www.mikrocontroller.net/articles/STM32_f%C3%BCr_Einsteiger#Kosten >> anhand der Liste ist der AVR mit der teuerste µC für den Einstieg. > > Woran hast Du das abgelesen? Da steht: > > Einzelchip (Einzelstückpreise) > STM32: 2..15€ > AVR: 0,6–5€ > PIC: 1-15€ > > Der niedrigste Preis steht ganz eindeutig bei AVR. Der höchste Preis > steht bei PIC und STM32. Für Hobbyelektroniker zählt jedoch nicht nur > der Einzelpreis, sondern auch die Verfügbarkeit von Einzelstücken für > Privatkunden, sowie die Versandkosten. Dennoch ist der AVR mit einer der teuersten µC FÜR DEN EINSTIEG. Denn ich rechne auch die Kosten für einen guten Debugger mit dazu und der ist beim STM32 um Faktor 5 kleiner. Und für diese Differenz kann man sehr viele STM32 µC kaufen - was für viele Hobby-Projekte ausreicht.
Markus Müller schrieb: > Dennoch ist der AVR mit einer der teuersten µC FÜR DEN EINSTIEG. > Denn ich rechne auch die Kosten für einen guten Debugger mit dazu und > der ist beim STM32 um Faktor 5 kleiner. Und für diese Differenz kann man > sehr viele STM32 µC kaufen - was für viele Hobby-Projekte ausreicht. Naja, auf dem AVR (und anderen 8-Bittern) kommen die meisten Hobbyisten ohne Debugger aus. Bei der geringeren Komplexität des Gesamtsystems ist das auch praktikabel. Kein Anfänger kauft sich gleich einen Debugger, um in AVR-Programmierung einzusteigen, die holen sich billige, einfache ISP-Programmer. Ich mach mir die Welt, widewide wie sie mir gefällt? :p
Falk Brunner schrieb: > So wie der Trend, mit einem Raspberry Pi, einem noch vor 10 Jahren fast > unvorstellbaren SoC mit 1/2 GB SDRAM + GPU + PiPaPo Relais, LEDs und > andere Belanglosgkeiten anzusteuern . . . Hier noch was Besseres: Pentium-Dualcore misst Temperatur,Atmung und Puls eines Babys http://www.heise.de/newsticker/meldung/Intels-Edison-Pentium-System-im-Format-einer-SD-Karte-2076917.html
> die holen sich billige, einfache ISP-Programmer. Beim STM32 braucht man dank eingebautem Bootloader erst kein speziellen ISP-Programmer kaufen. Der kann direkt per UART oder USB an den PC angeschlossen werden. (So auch LPC1xxx) Ich verstehe immer noch nicht was komplexer sein soll.
@ Moby (Gast)
>Pentium-Dualcore misst Temperatur,Atmung und Puls eines Babys
Der erste Satz beschreibt die Sache ganz gut . . . ;-)
"Intel hat sein System-on-a-Chip (SoC) Quark auf die Größe einer
SD-Karte
^^^^^
geschrumpft"
Klingt für mich alles nach, "Biete Lösung, suche Problem"
Markus Müller schrieb: > Dennoch ist der AVR mit einer der teuersten µC FÜR DEN EINSTIEG. Na na na für den Einstieg langt auch ein kleiner Tiny, selbst ein schöner Xmega32e5 ist doch mit 2,70 Euro bezahlbar. Die Beliebtheit hat dann auch ihren Preis :) Den Debugger schafft man sich erst an wenns wirklich professioneller werden soll. Beim Mega aufwärts kann man sich ggf. einen Bootloader draufmachen und auf dem gleichen Uart gibts Feedback -> PC für Analysen aller Art, das langt auch schon sehr weit.
Moby schrieb: > Pentium-Dualcore misst Temperatur,Atmung und Puls eines Babys Eher 486 Dualcore.
:
Bearbeitet durch User
Markus Müller schrieb: > Dennoch ist der AVR mit einer der teuersten µC FÜR DEN EINSTIEG. Vor allem, wenn man die vielen verfuseten Exemplare dazurechnet. Bei PIC, ARM, MSP430 etc kann man sich nicht aussperren, egal wie blöd man sich anstellt. Idiotensicher sozusagen. fchk
Frank K. schrieb: > Vor allem, wenn man die vielen verfuseten Exemplare dazurechnet. Bei > PIC, ARM, MSP430 etc kann man sich nicht aussperren, egal wie blöd man > sich anstellt. Idiotensicher sozusagen. LPC2000 geht auch. Musst nur an die richtige Stelle vom Flash den richten Wert schreiben. Ausserdem kannst du bei denen m.W. die Takt-PLL so programmieren, dass sie abraucht.
:
Bearbeitet durch User
greg schrieb: > Naja, auf dem AVR (und anderen 8-Bittern) kommen die meisten Hobbyisten > ohne Debugger aus. Bei der geringeren Komplexität des Gesamtsystems ist > das auch praktikabel. Kein Anfänger kauft sich gleich einen Debugger, um > in AVR-Programmierung einzusteigen, die holen sich billige, einfache > ISP-Programmer. Kein Wunder. Die meisten AVRs können auch gar nicht debuggt werden - ISP ist eben nur zum Programmieren, debugWire ist ein Krampf, und JTAG haben nur die größeren. Wer mit PICs anfängt, kauft sich ein PICKIT3 für 50€ (original) oder 20€ (China-Clone) und hat damit automatisch einen Debugger für alle aktuellen 8, 16 und 32 Bit PICs. Besser ist das. Bei anderen Familien siehts ähnlich aus. fchk
Stefanus schrieb: > Woran hast Du das abgelesen? Da steht: > Einzelchip (Einzelstückpreise) > STM32: 2..15€ > AVR: 0,6–5€ > PIC: 1-15€ > > Der niedrigste Preis steht ganz eindeutig bei AVR. Der höchste Preis > steht bei PIC und STM32. Für Hobbyelektroniker zählt jedoch nicht nur > der Einzelpreis, sondern auch die Verfügbarkeit von Einzelstücken für > Privatkunden, sowie die Versandkosten. Au man, da vergleicht aber mal wieder jemand gewaltig Äpfel und Bananen! Die angegebenen Preisspannen sind ca. Preise und beziehen sich auf das komplette Bastlerrelevante Lieferprogramm. Die 15Euro sind dabei wohl der hoch angesetzte Einzelstückpreis für einen PIC32MX795L! Das ist der (derzeit) mächtigste µC überhaupt im regulären Microchip Lieferprogramm. (Wenn der auch in absehbarer Zeit durch die 32MZ Serie nach oben ergänzt wird die aber noch nicht "ganz" Serienreif ist, Momentan nur als Vorabentwicklungsexemplare verfügbar) Das ist aber eine ganz andere Klasse und Technologie als die 8Bit ATMEGA. Für den 8Bit Bastler hat das keine Nur weil es von einem Hersteller neben den günstigen µC auch eine sehr viel leistungsfähigerer Serie gibt deren größte Exemplare in Kleinststückzahlen teuer sein können heisst es noch lange nicht das die "teuer" sind. (Gilt Sinngemäß auch für die STM32 die ja in der selben Klasse spielen wie die PIC32, aber weit höher als die ATMEGA/PIC18) Davon abgesehen ist die Preisspanne falsch, denn die PIC18 beginnen bei REichelt mit dem PIC18F45K22 für 0,49 Euro. Dieser ist von den Daten (Speicher/Preipherie) im Bereich zwischen dem ATMEGA16 und dem ATMEGA32 einzuordnen. Diese werden so zwischen 2 und 3 Euro gehandelt... Und der (derzeit noch) absolute "günstigste" Pic kostet bei REichelt 0,33Euro. Wobei das im Gegensatz zum obigen 18F45K22 aber sicher kein Exemplar für den µC Einsteiger mit Lernabsicht ist. Und es steht sogar eine Ankündigung für den PIC16LF707 für 0,19 Euro! Das ist im gegensatz zum PIC10 für 33ct sogar ein vollwertig einsetzbarer µC. (Auch wenn ich den heute auch nicht unebedingt als Einstiegs µC empfehlen würde) > Stell Dir vor, ich kaufe > Bei Händler X: Den Mikrocontroller für 10 Cent + 7 Euro Versandkosten > Bei Reichelt: Alle anderen Teile im Wert von 95 Euro + 7 Euro > Versandkosten > > Da kann ich gleich besser alles bei Reichelt bestellen, selbst wenn die > den Controller sauteuer machen. > > Das ist doch die Situation, in der die Hobbyelektroniker stecken, also > die meisten Teilnehmer dieses Forums. JA - aber gerade das Beispiel bei Reichelt würde doch eher für die PIC sprechen. Derzeit günstigster PIC18F 0,49 Euro (Mit den Leistungsdaten eines gößeren ATMEGA), günstigster AVR überhaupt für 0,99Euro, günstigster ATMEGA für 1,70 Euro. Wobei ich noch einmal betonen möchte das ich diese Vergleiche jetzt nur exemplarisch herausgesucht habe um die falsche Behauptung zu wiederlegen. Grundsätzlich sehe ich die ganze Diskussion um centbeträge bei den Beschaffungskosten für eine Bastler einfach als Blödsinn an. Die allgemeine Größenordnung sollte passen, aber sonst... Was eine Rolle spielt sind die Gesamtkosten des Einstiegs UND die Beschaffbarkeit generell. Bei der Beschaffbarkeit tun sich AVR und PIC nichts und die Kosten für den Einstieg sind jetzt auch nicht so unterschiedlich. Wenn auch der PIC die nase da leicht vorne hat. Gruß Carsten
Markus Müller schrieb: > Beim STM32 braucht man dank eingebautem Bootloader erst kein speziellen > ISP-Programmer kaufen. Der kann direkt per UART oder USB an den PC > angeschlossen werden. (So auch LPC1xxx) Yep, das ist eine coole Sache, hab ich auch schon genutzt. Ich find ARM-MCUs ja auch gut. Aber ich würde nie auf die Idee kommen, deshalb den kleineren 8/16-Bittern die Existenzberechtigung abzusprechen. Du verdrehst hier dauernd Fakten um deine ARM-Lieblinge ins gute Licht zu stellen, das wirkt auf Dauer nicht wirklich überzeugend, im Gegenteil.
Autor: Carsten Sch. (dg3ycs) > Davon abgesehen ist die Preisspanne falsch, denn die PIC18 beginnen bei >REichelt* mit dem PIC18F45K22 für 0,49 Euro. Nun, das ist aber auch nicht richtiger, denn bei R****** kostet der PIC18F45K22 zwischen 2,72 und 2,87 (je nach Gehäuseform). Aber wenn du welche um 0,49 Euro hast, nehme ich gerne 25 Stück ;-)
Chris B. schrieb: > Autor: Carsten Sch. (dg3ycs) >> Davon abgesehen ist die Preisspanne falsch, denn die PIC18 beginnen bei >>REichelt* mit dem PIC18F45K22 für 0,49 Euro. > > Nun, das ist aber auch nicht richtiger, denn bei R****** kostet der > PIC18F45K22 zwischen 2,72 und 2,87 (je nach Gehäuseform). Aber wenn du > welche um 0,49 Euro hast, nehme ich gerne 25 Stück ;-) OK, hast ja recht... HAbe das "L" vergessen - Seit dem ich bis auf wenige Ausnahmen nur noch in der 3,3V lebe passiert das manchmal... Also wenn dir die PIC18´L´F45K22 reichen verkauft Reichelt dir sicher gerne welche für 0,49Euro! http://www.reichelt.de/PIC-18-Controller/PIC-18LF45K22IPT/3/index.html?&ACTION=3&LA=2&ARTICLE=109943&GROUPID=2968&artnr=PIC+18LF45K22IPT Also: Preisspanne richtig, Genauer Controllertyp nur halb - war ein anderer Untertyp! Gruß Carsten
:
Bearbeitet durch User
greg schrieb: > Du verdrehst hier dauernd Fakten um deine ARM-Lieblinge ins gute Licht > zu stellen, das wirkt auf Dauer nicht wirklich überzeugend, im > Gegenteil. Wenn es die AVR-Fraktion ebenfalls ständig irgend was verdreht (wobei viele von denen Chips mit ARM Core erst gar nicht kennen), dann darf ich das auch. Was genau habe ich denn jetzt schon wieder verdreht?
Wass soll denn immer diese Off Toppic Prozessortyp-Diskutiererei? Die Frage war was gegen XMEGA spricht. Antwort: Nichts. Der uC macht genau das wofür er gebaut wird. Jeder soll den Prozessor verwenden der die Aufgabe ohne all zu viele Klimmüge erledigen kann. Und zwar den Prozessortyp, der einem am meißten zusagt bzw. für den man die benötigte Peripherie hat bzw. besorgen kann. Die gesammte Diskutierere ist nur ein Getrolle und Spammen von irgendwelchen Fakten die absolut überhaupt nichts zur Sache tun. Zu der genzen Angelegenheit hat Dave ein gutes Video gemacht: http://www.youtube.com/watch?v=DBftApUQ8QI
Wozu gibt es diese Vergleichstabelle ueberhaupt in diesem Artikel? Der Artikel soll vom STM32 handeln und kein Schauplatz von gekraenkten Egos sein. Da haben andere Controller ueberhaupt nichts drin verloren.
Bernd schrieb: > Die gesammte Diskutierere ist nur ein Getrolle und Spammen von > irgendwelchen Fakten die absolut überhaupt nichts zur Sache tun. Genauer gesagt ist es weitgehend faktenfreies Getrolle. > Zu der genzen Angelegenheit hat Dave ein gutes Video gemacht: > http://www.youtube.com/watch?v=DBftApUQ8QI Also "gut" würde ich das nicht nennen. Tasächlich habe ich es nach 5 Minuten ausgemacht, weil er sich eigentlich die ganze Zeit nur über "die AVR Fanboys" beklagt. Wenn er hier mitgelesen hätte, würde er sich aber wohl eher über die ARM Fanboys beklagen. Es hat schon seinen Grund, warum Missionare historisch so oft über die Klinge springen mußten. Die nerven einfach. XL
Axel Schwenke schrieb: > Also "gut" würde ich das nicht nennen. Tasächlich habe ich es nach 5 > Minuten ausgemacht, weil er sich eigentlich die ganze Zeit nur über "die > AVR Fanboys" beklagt. Wenn er hier mitgelesen hätte, würde er sich aber > wohl eher über die ARM Fanboys beklagen. Du solltest dir aber zumindest den Schluss anschaun.
Axel Schwenke schrieb: > Also "gut" würde ich das nicht nennen. Tasächlich habe ich es nach 5 > Minuten ausgemacht, weil er sich eigentlich die ganze Zeit nur über "die > AVR Fanboys" beklagt. Dave Jones ist ganz offensichtlich ein (zumindest kleiner) PIC-Fanboy. ;)
Axel Schwenke schrieb: > Du meinst einen externen ADC mit 16 Leitungen? Da hilft dir auch ein 16- > oder 32-Bitter nicht unbedingt weiter, weil auch die ihren Ports > typischerweise nur 8 Bits geben. Axel, du solltst dringendst mal deinen geistigen Horizont erweitern. Lies einfach mal ne Doku zu einem mittelprächtigen ARM oder Cortex. Deren Ports sind typischerweise 16 oder 32 Bit breit - aber das ist nur die halbe Weisheit, denn viele Typen haben einen herausgeführten Systembus, wo man 8, 16 und 32 Bit breite Peripherie anschließen kann - ja, auch gemischt. Da wäre so ein ADC als 16 Bit Device ganz prächtig aufgehoben und könnte mit einem einzigen Lesebefehl entweder von der CPU oder vom DMA ausgelesen werden. Also schreib nicht so einen hanebüchenen Unsinn. W.S.
Ein gutes Beispiel für breite Ports ist z.B. die LPC Serie von Philips/NXP. Ich schlage mich am Rande gerade mit der Betty und solchen Portpins wie 'P0.25' herum. Zum Thema: Ich habe vor einiger Zeit ein und dasselbe Projekt für 3 Zielprozessoren gebaut. Es handelt sich um eine BLDC Ansteuerung eines Sensor Motors mit Sinusmodulation, Konsolenunterstützung und PID Regler. Die Konsole dient dabei zur Steuerung und Diagnose des MC und des laufenden Motors (in meinem Fall ein 4kW/48V Radnabentyp). Die Prozessoren waren: * ATMega88 @16Mhz * ATXMega192D3 @32Mhz * STM32F100RBT6B @24MHz (VL Discovery) Sofern der MC eine spezielle Hardware zur Unterstützung hatte, wurde diese auch benutzt, also z.B. das Event System des XMega und die DMA des STM32. Zur Messung der Auslastung lief in der Hauptschleife ein Profiler, die gesamte Motorkontrolle ist in ISR untergebracht. Während der kleine Mega88 recht gut beschäftigt war und nur noch etwa 10% seiner Zeit übrig hatte, um die Konsole zu bedienen, waren sowohl XMega als auch STM32 mit nur knapp 40%-50% ausgelastet. Dabei punktete der XMega vor allem durch die AWEX Unit, die PWM und Totzeiten zur Ansteuerung praktisch fertig servierte, der STM32 durch den Advanced Timer und die 32-bit Verarbeitung. Unangenehm fiel mir beim STM32 das gewöhnungsbedürftige Interrupthandling auf, ein Bug im Atollic TS Lite war dann noch eine Hürde, dafür kann aber der MC nichts. Am vorhersehbarsten war tatsächlich der XMega, so dass dieser im Moment in zweifacher Version in unserer Demoansteuerung arbeitet. Der XMega zeigte sich empfindlich auf der Reset Leitung. Unser grosser Motor schweinert ein wenig auf der Betriebsspannung herum (zieht ja bei Vollast auch so eben mal 60-80A, beim Anfahren auch mal 100A) und trotz DC/DC Wandler und sauberer Absiebung der 3,5V (ja, der MC arbeitet bei 3,5V besser als bei 3,3V) ging er ab und zu in den Reset. Ein kräftiger Pullup beseitigte dieses Problem aber zuverlässig. Alle o.a. Prozessoren würde ich im Automotive Bereich aber nicht nehmen. Da sind Freescale oder Renesas einfach etablierter und haben mehr Erfahrung.
:
Bearbeitet durch User
Nur weil ich es gerade zufällig gefunden habe. Bei der Einführung zum ATXmega war diese Threadüberschrift wohl gar kein Thema. Für mich Hobbylöter wird wohl so ein Xmega schon eine ganz schöne Herausforderung werden. Beitrag "ATXMega128 - Erste Erfahrungen" Bernd_Stein
soviel zur Xmega Totgeburt: erster Xmega der eine Automotive Qualifizierung erhält: http://www.atmel.com/devices/ATXMEGA64D3AUTOMOTIVE.aspx Damit dürfte der Xmega noch ein Jahrzehnt oder länger leben...
>Die XMegas haben ein paar einzigartige Features, die sonst kein 8 oder >32 Bit Controller hat. Und welche ??? >Damit dürfte der Xmega noch ein Jahrzehnt oder länger leben... Noch ein Jahrzehnt? Die CPU ist seit Urzeit 1997 unverändert! Die hatten das wohl aus Norwegen gekauft, und nie mehr angerührt. Warum nicht ein paar Bits mehr im OP-code? >Was spricht gegen XMEGA ? dito
MCUA schrieb: > Warum nicht ein paar Bits mehr im OP-code? Also die AVR haben doch wohl genug Befehle. Was mal nötig wäre ist nen Barrelshifter.
Thread beobachten
Seitenaufteilung abschalten