Hallo, ich bin leider etwas Ratlos. Aus diesem Grund die Frage in die Allgemeine Runde. Ich möchte einige kleine Projekte Realisieren. Zum einem einen Batterie-Wächter mit einer Siebensegment-Anzeige oder einem LCD für 2 Mignons. Ein anderes Projekt ist ein Schalter der auf Umwelteinflüsse (Licht, Temperatur) reagiert. Im Grunde wirkliche Mini.Schaltungen, die in der Regel mit 1 oder 2 ADC und einem bis 7 Pinouts auskommen. Mein Problem ist jetzt, welche µC Familie sollte ich einsetzen. Beruflich arbeite ich im wesentlichen mit STM32XX, doch die sind einfach etwas überdimensioniert für solche Projekte. Deswegen suche ich für kleine Schaltungen eine Alternative. Heraus gesucht habe ich mir MSP430-Familie. Lowpower sowie geringe Beschaltung waren ausschlaggebend und natürlich der Preis. Spricht irgendwas dagegen? Oder doch lieber ein Atiny? Die 4kByte Speicher sollten ja locker reichen vom MSP430F2121 für meine Projekte. Und reicht es tatsächlich aus, nur das Launchpad zu holen. Denn wenn ich das richtig Verstanden habe, ist das ja ein Programmierer und ein Evolutionsboard in Einem. Ich Arbeite im wesentlichen an einem Laptop (USB) und kann bis 0.31525 mm hinunter alles selber herstellen. Eine Testschaltung baue ich gerne mal auf einem Breadboard auf. vielen Dank für die Antworten schon mal im Voraus. PS: Ich möchte keinen Glaubenskrieg zwischen den Anhängern der verschiedenen µC-Familien damit provozieren...
:
Gesperrt durch Moderator
Schau Dir doch einfach mal die "üblichen Verdächtigen" der verschiedenen Hersteller an, welcher uP am besten zu Deinen Anwendungen passt. Z.B. verfügbare Gehäuse (bei Breadboard sind DIP imme nice), Stromverbrauch im Sleep. Anzahl der ADC/Timer/whatever Peripheriekomponenten, Verfügbarkeit von Software/Debugger/Programmer usw. Auch die Verfügbarkeit des Bauteils selbst solltest Du prüfen. Nicht alle uPs sind zu Hobbykonditionen gut erhältlich. Eigentlich solltest Du da schnell was passendes finden. Grüße Andreas
Auch wenn ein kleiner Atmel-µC mit Sicherheit für diese beiden Projekte reichen würde, willst Du nicht die berufliche Erfahrung und "Schwung" nutzen und einen kleinen STM32 nehmen? Bei Reichelt geht das mit dem "STM32 F101C8T6" zu 3,30 Euro los. Aber wenn Ihr die Familie sowieso schon in der Firma einsetzt, dann dürfte ja auch alles Notwendige sowieso schon vorhanden sein. Inklusive kostenlose Samples von ST. Bei der guten Grundvoraussetzung willst Du Dich noch mal in eine ganz andere µC-Familie einarbeiten?
Ich würde bei Cortex-M bleiben, STM32 oder Kinetis. Was spricht gegen eine M0+. Die haben sehr kleine Varianten, überhaupt nicht überdimensioniert.
Warum nicht mal was anderes? Erweitert den Horizont ungemein und man kann sich dann auch mal eine fundierte Meinung zu den Beiträgen hier im Forum bilden. Entscheidend fürs Hobby sind doch der Preis für die Grundausstattung der Toolchain und die Hilfe, die man bekommen kann. Blackbird
So etwas Kleines würde ich mit ATtiny aufbauen. Habe mir gestern den
ersten ATtiny13 in SOIC auf DIP-Adapterplatine gelötet und eben getestet
- Schieberegister ansteuern mit demselben Programm, anderem
Zielprozessor und -Os statt -O2. Passt hervorragend.
ADC wollte ich in Kürze mit dem freigewordenen ATtiny85 antesten und
sehe da jetzt keinen großen Unterschied zum ATmega328 ("Righstsizing"
meines Furzsensors mit RGB-LED-Feedback).
Für mehr IO habe ich mir noch SPI-Expander zugelegt, die gibt es
ebenfalls spottbillig. Etwa der MCP23S17, der bietet 16 IOs via
SPI/10MHz ansteuerbar:
http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf
http://www.ebay.de/itm/300980101037
Gibt es auch mit 8 E/As.
Wenn du unbedingt was neues ausprobieren möchtest: PSoC von Cypress: Beitrag "Cortex M3 kit für 3 Euro"
Maze schrieb: > PS: Ich möchte keinen Glaubenskrieg zwischen den Anhängern der > verschiedenen µC-Familien damit provozieren... Dafür reicht bereits der Titel.:-)
Ein STM32F030 im TSSOP20 wäre für diese Aufgabe auch nicht schlecht. Gibt es bei Mouser. http://at.mouser.com/Semiconductors/Embedded-Processors-Controllers/Microcontrollers-MCU/ARM-Microcontrollers-MCU/_/N-a85pc?P=1z0z7by&Keyword=STM32F03&FS=True
Das Launchpad reicht für den Start mit dem MSP430 aus, der Programmer ist on Board, der Controller ist gesockelt, ein zweiter wird mitgeliefert.
Kommt drauf an, ob man für jede Idee erstmal umständlich eine Platine machen will oder ganz schnell was auf Lochraster zusammen löten. Die AVR gibt es im DIP als 8-, 14-, 20- und 28-Pinner. Als Versorung geht ein billiges USB-Steckernetzteil (5V), da die AVR von 1,8..5,5V laufen. Und auch auf dem 8-Pinner (ATtiny85) darf man float und long long benutzen.
:
Bearbeitet durch User
Da ich den Umgang mit ATtiny und ATmega gewohnt bin, würde ich dabei bleiben. Wenn ich wie du aber schon Erfahrung mit den STM32 hätte, würde ich dabei bleiben. Es stört doch nicht, dass der Controller mehr kann, als du brauchst. Immerhin sind die kleinen STM32 (in Einzelstücken) nicht wesentlich teurer, als die üblichen 8 Bit Controller. Warum einen Trabbi kaufen, wenn schon ein Porsche vor der Türe steht?
In der Bucht werden sonst auch grade STM8-Minimalboards billigst verschleudert. Da bleibt durch die Bibliothek von STM die Nomenklatur gewohnt. Ich habe nur noch keine Toolchain dafür ;) Mehr IO, etwas teurer: http://www.ebay.de/itm/380916664459 Weniger IO, absoluter Preisschlager: http://www.ebay.de/itm/171346510522
Erstmal Danke für die vielen Beiträge! Ja, also es ging auch darum mal wieder etwas neues zu probieren, so schön der STM32 auch ist. Zu mal die Packages nicht so der Renner sind, wenn man sie per Hand löten muss. Also ich kann zwar TSSOP löten aber! Ich mach es einfach ungern... . SOP oder DIP wäre mir da lieber. Es geht auch ein bisschen darum effizienter sein zu müssen. Ich neige dazu, wenn der STM32 nicht viel zu tun hat, umständliche Programme nicht nochmal zu überarbeiten. Aber ich denke es wird wohl der MSP430 werden. Das mit dem Launchpad gefällt mir. (Danke @Tom).Vielleicht reicht meine Motivation auch beides auszuprobieren. Auch wenn ich mich vermutlich damit aus dem Fenster lehne, aber ich kann mir nicht vorstellen, dass es schwieriger sein sollte, sich in die MSP340-Familie einzuarbeiten, als in den STM32. Auch wenn der STM32 besser dokumentiert ist. IMHO nochmals vielen Dank mit freundlichen Grüßen Maze
> Und reicht es tatsächlich aus, nur das Launchpad zu holen. Nicht, wenn Du steinalte MSP430-Varianten benutzen willst, die kein SpyBiWire (SBW) kennen. Und dazu gehört der von Dir genannte 'F2121. Der ist, wie auch die 'F1xx-Reihe, schlichtweg zu alt, und kann nur mit 4-Draht-JTAG programmiert werden. Dafür verwendest Du am besten den MSP-FET430UIF, der aber deutlich mehr kostet als ein Launchpad, nämlich knapp 100 EUR. Damit sind dann aber auch alle MSP430-Familienmitglieder verwendbar, sowohl die mit 4-Draht-JTAG als auch die mit SBW. Sinnvoller aber dürfte es sein, sich auf neuzeitlichere MSP430-Varianten zu konzentrieren, die sind i.d.R. deutlich günstiger, performanter und mit interessanterer Peripherie ausgestattet. > Denn wenn ich > das richtig Verstanden habe, ist das ja ein Programmierer und ein > Evolutionsboard in Einem. Nicht nur ein Programmierer, sondern ein Debugger. Ein deutlicher Unterschied zu den nur-Programmierer-Lösungen der AVR-Familie, bei denen ein Debuggen nur mit einem dann doch sehr teuren JTAG-Interface möglich ist. (BTW: "Evaluation") Ja, ist es, aber es lässt sich, wenn der IC-Sockel freigelassen wird, auch als SBW-Adapter zum Programmieren und Debuggen von in anderen Schaltungen verbauten MSP430 verwenden. > Eine Testschaltung baue ich gerne mal auf einem Breadboard auf. Das ist nicht das ideale Habitat für MSP430, weil es nur sehr wenige Modelle im DIP-Gehäuse gibt. Der interessanteste verfügbare im DIP-Gehäuse wird mit der aktuellen Variante des Launchpads mitgeliefert, das ist der 'G2553 mit 16 kiB Flash und 512 Byte RAM im 20poligen Gehäuse. Im Prinzip gibt es auch einen größeren Bruder im 40-poligen DIP-Gehäuse, aber dessen Verfügbarkeit ist ... umstritten, zumal TI selbst ihn im "parametric selection guide" auch unterschlägt, jedenfalls was die Gehäusebauform betrifft. Das ist der 'G2744, den man derzeit wohl nur zusammen mit einer Platine von Olimex bekommen kann: https://www.olimex.com/Products/MSP430/Booster/MSP430-G2744BP/open-source-hardware Insgesamt sind MSP430 recht sparsam mit RAM bestückt, und da es keinen externen Speicherbus gibt, ist das auch nicht ohne massive Performanceeinschränkungen erweiterbar. Mit Performanceeinschränkungen kann man natürlich SPI- oder I²C-RAMs anschließen, aber da muss man dann auch jedes einzelne Byte programmatisch hin- und herschieben.
:
Bearbeitet durch User
Fuer so "Kleinzeug" mit bis zu 6 bzw. 12 IO bieten sich auch die "kleinen" Midrange PICs an: 12F675 - 1 kWorte Flash, 64 Reg., 4 ADC, 6 IO 12F683 - 2 kWorte Flash, 128 Reg., 4 ADC, PWM, 6 IO, Int Osc 125 kHz-8MHz 16F684 - 2 kWorte Flash, 128 Reg., 8 ADC, PWM, 12 IO, Int Osc 125 kHz-8MHz in 8 bzw. 14 Pin DIP/SOIC/TSSOP/... Im Zehnerpack guenstig und versandkostenfrei aus China. Die Exemplare mit einstellbarer Taktfrequenz sind auch recht sparsam zu betreiben.
Dirk K. schrieb: > In der Bucht werden sonst auch grade STM8-Minimalboards billigst > verschleudert. Du solltest vielleicht erwähnen, dass das 8-Bit uPs sind ;-) /regards
Naja, wenn ATtiny eine Alternative sind, also 8-Bitter, dann sind doch auch die von STM ok. Die tragen die Bittigkeit ja sogar direkt im Namen: STM8 vs STM32?
Der STM8 ist nicht schlecht und von der internen Architektur sehr einfach. Als IDE bietet sich das ST Visual Develop (STVD) an http://www.st.com/web/catalog/tools/FM147/CL1794/SC1808/SS1767/PF210567 Dazu benötigt man noch einen externen Compiler. Getestet habe ich das Ganze mit der Testversion vom Cosmic (16 KB Code-Limit) Neuerdings gibt es STM8-Support im SDCC, allerdings noch keine Integration in STVD
kopfkratz Ja was willst Du denn nun wissen ? Für Deine Anforderungen sind ALLE µCs mit ausreichendem I/O und ADC geeignet. Ob nun AVR mit USB-ASP oder PIC-Kit oder MSP-USB oder STM-USB oder oder oder ... Schau Dir mal die ARM Module vom aktuellen Wettbewerb an, bekommt man ab 6,- Euro als Platine mit USB und I/Os und sind sicherlich für wesentlich mehr geeignet als Deine angegebenen Projekte. Das gleiche gilt halt auch für sämtliche andere Produkte. Du könntest nun die Herausforderung annehmen und einfach mal alle µC Familien benutzen, einen AVR für den "Schalter", einen MSP für den Batteriewächter, einen ARM für XYZ usw. usf. ;-)
Mittels leichter Projekte über den Tellerrand der bereits bekannten MCUs zu schauen, ist eigentlich der klassische Ansatz, um den eigenen Erfahrungssschatz auszubauen. Selbst wenn du nur die Datenblätter der anderen MCUs durchliest, du bekommst genug Input für ein gutes Dutzend Aha-Effekte. Und das alles fällt auf deine normale Arbeit mit dem STM32 zurück. Was willst du mehr? Geh auf die (Bildungs-)Reise! Lass dich nicht von den typischen Ausreden wie: "das haben wir immer schon so gemacht" oder ähnliches abhalten.
Maze schrieb: > Ja, also es ging auch darum mal wieder etwas neues zu probieren, so > schön der STM32 auch ist. Zu mal die Packages nicht so der Renner sind, > wenn man sie per Hand löten muss. Also ich kann zwar TSSOP löten aber! > Ich mach es einfach ungern... . SOP oder DIP wäre mir da lieber. Dann schau dich doch mal die Cortex-M von NXP an: http://de.farnell.com/nxp/lpc810m021fn8fp/mcu-32bit-cortex-m0-30mhz-8dip/dp/2320692 http://de.farnell.com/nxp/lpc812m101jd20/ic-mcu-32bit-cortex-m0-so20/dp/2295531 Mal etwas anderes aber auch nicht alles neu wenn man STM32 schon kennt...
Maze schrieb: > Zum einem einen > Batterie-Wächter mit einer Siebensegment-Anzeige oder einem LCD für 2 > Mignons. Gibts hier schon fix und fertig als Artikel Batteriewächter Einfach die Verpolschutzdiode entfernen dann sollte es auch für 2 Mignons reichen. Gruß Anja
Die Wahl der einzig wahren µC Familie ist genauso einfach, wie die Wahl des einzig richtigen Autos. Frag Deinen Nachbarn.
Hallo Maze, Wenn Du die Testplatine selber herstellen kannst/möchtest, schau doch mal bei [http://www.sprut.de/electronic/pic/test/index.htm] vorbei und bau Dir selbst eine Testplatine für 18- oder 28-Pin PIC-µC. Wenn Dir ein guter 8Bitter genügt, böte ein "enhanced" PIC wie z.B. der 16F1827 oder ähnlich mit seinen Modulen für ADC/Capacitive sensing/UART/Capture/PWM usw.... jede Menge Möglichkeiten. Sehr preisgünstig sind die PICs auch und dazu im DIL/DIP-Gehäuse erhältlich Schau einfach mal in die entsprechenden Datenblätter [http://www.reichelt.de/PIC-16F1827-I-P/3/index.html?&ACTION=3&LA=446&ARTICLE=96480&artnr=PIC+16F1827-I%2FP&SEARCH=PIC+16+F1827]. mfG Ottmar
Dirk K. schrieb: > ...Unterschied zum ATmega328 ("Righstsizing" > meines Furzsensors mit RGB-LED-Feedback)... :D Echt jetzt?
Maze schrieb: >SOP oder DIP wäre mir da lieber. bei den PICs gibt es sogut wie alles als DIP und das pickit is auch erschwinglich
Für dein Vorhaben ist det MSP schon die richtige Wahl. Mit dem Launchpad bist du günstig dabei und die Dokumentation ist sehr gut: Family User Guide. Der Controller Aufbau ist schnell zu verstehen und man ist schnell eingearbeitet. Für 'nebenbei' genau das richtige.
>Der STM8 ist nicht schlecht und von der internen Architektur sehr >einfach. und schnell ist er, viele CISC-Befehle nur 1 Takt, kleinster bereits 1kB-Ram, 5V. ..hat aber viele Einschränkungen hinsichtl. Benutzung einzelner Portpins (nicht alle sind für hohe Geschwindigk, fast keine zusammenhängende 8-bit-Ports (das bei AVR viel besser). Fast kein DIL (für manche ja relevant), rel. wenige Typen. >MSP430 sind Süß=) viele Adr.arten, aber (zu) langsam.
Oh je... ALLE genannten Controller sind für dieses Mamutprojekt geeignet. Auf welchen hast DU den am meisten Lust ? Meine Empfehlung: AVR, wenn Du es kuschelig magst. XMega wenns ein eleganter und moderner 8bitter sein darf. STM8 wenn Du das maximale fürs Geld willst und gerne mal von hinten durch die Brust ins Auge denkst. (ich finde die gut...) Der große Bruder STM32 wenn es extreme Performance für Dein 7seg. sein muß. PIC's sind auch immer wieder lustig aber die Doku oft schmerzhaft. 8051 ist zeitlos und von schlichter Eleganz. Ich hätte auch noch ein paar 8085 irgendwo rumfliegen, wenn Du auf der Suche nach minimalen Nutzen bei maximalem Hardware Aufwand bist und schon immer mal wieder Deinen Eprom Brenner nutzen wolltest. 80186 müßte ich mal schauen, irgendwo ... Dirk K. schrieb: > (STM8) Ich habe nur noch keine Toolchain dafür ;) IAR bis 8K Kostenlos und sehr brauchbare IDE + 5€ STM8S Value Line Discovery als Eval, Programmer, Debugger.
Andreas H. schrieb: > Du solltest vielleicht erwähnen, dass das 8-Bit uPs sind ;-) Oh mein GOTT. Wirklich ? Und was sagt uns das nun ? Komisch, das hat bei mir vor 25 Jahren mit einem 1Mhz 8085 ganz gut funktioniert. Was hat sich denn an den 7Seg. Anzeigen so fundamental verändert, das ich nicht nur die 50fache Performance eines modernen 8bitters dafür brauche, sondern auch die 4fache Datenbusbreite ?
Michael Knoelke schrieb: > Was hat sich denn an den 7Seg. Anzeigen so fundamental verändert, das > ich nicht nur die 50fache Performance eines modernen 8bitters dafür > brauche, sondern auch die 4fache Datenbusbreite ? Vielleicht ist ein kleiner ARM eben billiger und einfacher zu programmieren. Und falls mit "moderner 8bitter" XMEGA gemeint ist, da gibt es weit "modernere" hier mal ein "Internet-of-Things" 8051: http://www.ti.com/product/cc1110f8
Naja, ein vierstelliges Siebensegment mit einem Takt/int32 ansprechen können ist schon eine lustige Idee :D Bzgl STM8 - habe diverse STM32Discos mit integriertem STLink und zusätzlich noch einen losgelösten STlink als USB-Stick für grob 2€. Scheint auch via SWIM die STM8 ansprechen zu können, lässt sich mit der normalen STLink-Firmware aktualisieren. IAR ist nicht so meins, ich arbeite am Mac bislang mit Eclipse, AVR-GCC, GNU-arm-eabi, ... SDCC hätte ich auch schon da, muss das mit etwas Geduld versuchen, in Eclipse zu integrieren.
Lothar schrieb: > Vielleicht ist ein kleiner ARM eben billiger und einfacher zu > programmieren. Vieleicht aber auch nicht. Ich tendiere zu: Kein wesentlicher Unterschied Das Argument hört man ständig, aber ich sehe zwischen 8 und 32 bit kaum einen Unterschied ausser das man nicht 4 Register beschreibt, sondern eines das 4 mal so breit ist. Wenn das die Veinfachung sein soll, na gut, dann sind die einfacher. Bei der Verwendung der peripheral Librarys wird es schon sehr viel schwerer einen Unterschied zu erkennen. Geht man runter auf assembler Ebene und debugt tief auf Hardwarebene ist weniger oft mehr und die ARM werden schnell ganz schön eklig. Der STM8 ist dabei trotzdem billiger und hat mehr features. In dem betrachtetem Leistungsbereich selbstverständlich. Bei kleiner 0,3€ in Stückzahlen für einen STM8S003 sehe ich irgendwie keinen 32bitter. Der STM32 im tssop20 kommt in die nähe mit 0,55€ hat dafür aber einiges nicht was ich brauch. Nur Rechenleistung die ich nicht brauche. Lothar schrieb: > Und falls mit "moderner 8bitter" XMEGA gemeint ist, da gibt es weit > "modernere" hier mal ein "Internet-of-Things" 8051: Ja, der war in der Tat gemeint. Modern heißt für mich nicht zwangsläufig noch mal Funktionen die ich kaum brauche, sondern ein schlankes, effizientes Konzept mit Pfiff. Was mir an dem Xmega sehr gut gefällt ist einfach die Organsiation und Benennung der Hardwareregister. Alles extrem Aufgeräumt und mit sehr sinnvoller und flexibler Hardware. Siehst Du selbst wenn Du Dich damit beschäftigst. Immerhin bekräftigst Du meine Aussage das die 8051 zeitlos schön sind. Und ja, es gibt immer noch eine MCU die besser, billiger, geiler ist. Berücksichtigt man die persönlichen Vorlieben, die Gesammtkosten der Toolchain und 349 andere Punkte dann ist sicher für jeden was dabei. Dirk K. schrieb: > Naja, ein vierstelliges Siebensegment mit einem Takt/int32 ansprechen > können ist schon eine lustige Idee :D Race to sleep ... Das funktionier aber nur in einem Takt, wenn die LEDs nicht hardwaresparend interleaved ( z.b. 4x 4 Matrix direkt am Portpin ) angesteuert werden. Schon ist er hin der 32bit Vorteil. > SDCC > hätte ich auch schon da, muss das mit etwas Geduld versuchen, in Eclipse > zu integrieren. Geht das ganze debugging, memory view, hardware breakpoint etc. pp. mit stlink + eclipse + sdcc ? Ich wollte auch erst kein IAR, aber das war der einzige der drei kommerziellen bei dem mir nicht der *rsch geplatzt ist weil einfach nichts richtig geht oder die codesize beschränkung unbenutzbar ist oder die IDE nach 60er Jahre aussieht.
Michael Knoelke schrieb: > Geht man runter auf assembler Ebene und debugt tief auf Hardwarebene ist > weniger oft mehr und die ARM werden schnell ganz schön eklig. Ich versuche grade einen Filter in AVR-Assembler auf ARM zu portieren und sehe es genau anders herum.
Michael Knoelke schrieb: > Oh mein GOTT. > Wirklich ? > Und was sagt uns das nun ? Dir anscheinend nichts. Aber dem TO eventuell, dass er da anders rangehen sollte als bei einem STM32, den er auf Arbeit benutzt. > Komisch, das hat bei mir vor 25 Jahren mit einem 1Mhz 8085 ganz gut > funktioniert. > Was hat sich denn an den 7Seg. Anzeigen so fundamental verändert, das > ich nicht nur die 50fache Performance eines modernen 8bitters dafür > brauche, sondern auch die 4fache Datenbusbreite ? Wenn Du nach 25 Jahren immer noch die Hauptaufgabe eines uPs darin siehst eine 7-Seg. Anzeige zu steuern dann verstehe ich allerdings Deine Frage^^ Falls Du mal etwas komplizierteres versuchst, dann wirst Du aber vermutlich auch die Vor-/Nachteile der unterschiedlichen Bitbreiten erkennen. Beispiel: Zwei Mikrofonsignale einlesen (10Bit, 10KS/s), Identification & Ortszuweisung von Schallquellen (nur 2D, 160°, 50Hz-4KHz), Lautstärke einer steuerbaren, exteren Quelle so anpassen (via IR), dass deren Lautstärke n-dB über den anderen Schallquellen liegt (Welche das von den georteten Quellen ist, musst Du natürlich auch rauskriegen). Die n-dB werden über IR (normale Haushaltsfernsteuerung) vorgegeben. Das mit 8-Bit ? Viel Spass^^ /regards Andreas P.S: Verteh mich nicht falsch. Wenn es passt setze ich auch eher 8-Bit als 16/32 Bit ein. A.
Andreas H. schrieb: > Beispiel: Zwei Mikrofonsignale einlesen (10Bit, 10KS/s), Identification > blablablablabla ... Ja, Du bist mein Held, auch wenn Du das Thema verfehlt hast. Es ging nämlich genau darum: ein paar 7seg Anzeigen + kleinkram für eine lächerlich kleine Spaßanwendung. Gähn, ja ich habe auch durchaus schon das eine oder andere gemacht das nur mit 40MIPS und DSP noch flott geht. In diesem Fall aber ist es einfach Quatsch schockiert zu reagieren das 8bitter dafür vorgeschlagen wurden. Andreas H. schrieb: > Wenn Du nach 25 Jahren immer noch die Hauptaufgabe eines uPs darin > siehst eine 7-Seg. Anzeige zu steuern dann verstehe ich allerdings Deine > Frage^^ Welche Frage ? Worin sehe ich die Hauptaufgabe von MCUs ? Wo genau hat es bei Dir ausgesetzt und wie kann kann ich Dir helfen ? Ach hör doch auf. Immer dieses rumgelaber das 8bit tot ist und 32bit um so vieles besser und jeder dumm ist der was anderes behauptet. Das ist alles der gleiche Quatsch und alles der gleiche Aufwand. Dein toller STM32 ist auch *rschlangsam wenn ich von Aufgaben quatsche die einen i7 brauchen. Wie kannst Du nur einen STM32 verwenden, wo ich doch schon mal eine Aufgabe hatte die PC Power brauchte. Laberkopf !
Meine Empfehlung: MSP430G2-Serie. Nicht sonderlich komplex, tun was du willst, wenig Überraschungen. Und wenn die Stromversorgung irgendwann mal nur eine Coin-Cell sein sollte, machen die MSP430er viel Sinn. Mit dem Launchpad bekommst du alles was notwendig ist (inkl. Debugger), und auf 43oh.com gibt's auch eine sehr lebhafte und hilfreiche Community. Schlussendlich sind die Dinger ja auch noch Made in Germany :) PS: Zu den STM8ern: pass bei der Value-Line auf die Flash-Endurance auf, laut Datenblatt teilweise nur mickerige 100 Zyklen (problematisch hauptsächlich beim Entwickeln).
In den STM8-Datenblättern finde ich ~10.000 Zyklen als kleinsten Wert, die haben nur die Datenerhaltung nach 100 Schreib/Löschzyklen gemessen (der Wert für x Jahre). Oder habe ich was übersehen?
Ecki schrieb: > PS: Zu den STM8ern: pass bei der Value-Line auf die Flash-Endurance auf, > laut Datenblatt teilweise nur mickerige 100 Zyklen (problematisch > hauptsächlich beim Entwickeln). Mist, dann sind die ganzen 30cent weg ? Ok, danke, werde es im Hinterkopf behalten. Bis dato hatte ich damit noch keine Probleme.
Michael Knoelke schrieb: > Bei kleiner 0,3€ in Stückzahlen für einen STM8S003 sehe ich irgendwie > keinen 32bitter. Der STM32 im tssop20 kommt in die nähe mit 0,55€ hat > dafür aber einiges nicht was ich brauch. Nur Rechenleistung die ich > nicht brauche. Ihr kauft zu teuer ein. 0.30 EUR für einen STM32F030 sind bei Stückzahlen (z.B. 10k/Jahr) ohne weiteres drin, auch bei größeren Gehäuseformen.
MSP430 lassen sich im Assembler sehr elegant programmieren und sind als 16 Bitter ohne Klimmzüge für weite Bereiche einsetzbar. Am Markt sind sie recht weit verbreitet, z.B. in den Fluke Multimetern. Die klassischen AVRs wie Mega16 haben das DIP Gehäuse als Vorteil und die 5V I/O. Rechenleistung ist bescheiden aber für viele Fälle ausreichend. Nich vergessen werden sollten die LPC2000 von NXP z.B. LPC2134. Die haben genügend Performance für die Steuerung eines Frequenzumrichters mit True RMS Messungen bei 400kHz usw. Ideal ist ein Kickstartset mit J-Link ARM und dem IAR Embedded Workbench. Da lassen sich Breakpoints setzen und die Variableninhalte begutachten.
knoelke schrieb: >> Beispiel: Zwei Mikrofonsignale einlesen (10Bit, 10KS/s), Identification >> blablablablabla ... > > Es ging nämlich genau darum: > ein paar 7seg Anzeigen + kleinkram für eine lächerlich kleine > Spaßanwendung. Das Beispiel IST eine Spassanwendung: Regeln der Lautstärke eines Fernsehers in Abhängigkeit vom aktuellen Strassenverkehr (lästig bei offenem Fenster). Und das Ganze OHNE Eingriff in den Fernseher. Aber zugegeben, das Teil hat keine 7-Seg. Anzeige. Also nix für Dich. > In diesem Fall aber ist es einfach Quatsch schockiert zu reagieren das > 8bitter dafür vorgeschlagen wurden. Wer reagiert schokiert ? Es war ja bei weitem nicht der erste 8-Bitter der vorgeschlagen wurde. Er gehört allerdings zu einer komplett anderen Productline bei STM. Darauf wollte ich hinaus. Der einzige, der da etwas durchdreht bist Du. >> Wenn Du nach 25 Jahren immer noch die Hauptaufgabe eines uPs darin >> siehst eine 7-Seg. Anzeige zu steuern dann verstehe ich allerdings Deine >> Frage^^ > > Welche Frage ? > Michael Knoelke schrieb: > Oh mein GOTT. > Wirklich ? > Und was sagt uns das nun ? knoelke schrieb: > Wo genau hat es bei Dir ausgesetzt und wie kann kann ich Dir helfen ? DU ? Eher garnicht^^ > > Immer dieses rumgelaber das 8bit tot ist und 32bit um so vieles besser > und jeder dumm ist der was anderes behauptet. > Das ist alles der gleiche Quatsch und alles der gleiche Aufwand. > Dein toller STM32 ist auch *rschlangsam wenn ich von Aufgaben quatsche > die einen i7 brauchen. Obwohl, Du würdest mir einen grossen Gefallen tun, nicht permanent irgendwelche Sachen zu unterstellen. Wieso ist das plötzlich MEIN STM32 ? Vielleicht liest Du einfach mal den zweiten Post in diesem Thread um zu sehen, was meine "Lieblingsprozessoren" sind. Grüße Andreas
Der MSP ist aktuell die beste Variante, wenn es kein ARM sein soll. Im Gegensatz zum ST8 oder kleinen AVR hat er 16 Bit. Mit dem Launchpad ist der Einstieg günstig und TI macht es Einsteigern leicht mit Beispielen und Beschreibung. Es gibt auch ein RTOS und vollständigen Stack für den Funkkram.
"Die beste Variante" ist doch sicherlich sehr subjektiv. Für mich das Beste ist nicht für dich das Beste. Während etwa anaerobe Zersetzer am besten ohne Sauerstoff klarkommen, sieht das mit Escherichia Coli sicherlich anders aus, die finden O2 auch toll (für die Biologen unter uns, ja, ich weiß, dass E.Coli auch anaerob können. Das Beispiel ist Absicht.) Die fühlen sich mit Sauerstoff richtig wohl ;) Also hängt das immer davon ab, - welchen Lernaufwand man betreiben will, - welche Kosten man stemmen möchte, - welche Vorkenntnisse man bereits hat, - was die Aufgabe angemessen erfüllt, - wofür man eine (wieder subjektiv!) gut bedienbare Entwicklungsumgebung zu welchen Kosten bekommt, - ... Einen Teil dieser Prämissen hat der Thread-Starter ja genannt. Und dafür viele Hinweise bekommen. "Das Beste" kann jedoch immer nur "nach Abwägung der Prämissen mit meinen Kenntnissen und Fähigkeiten sowie Budgetgrenzen" sein. Und nicht so pauschal der MSP430. ... den ich auf der Fensterbank liegen habe und noch nicht einmal auf Funktion getestet auf dem Launchpad. Ich brauche einfach mal mehr Zeit. Hat wer welche über? ;)
:
Bearbeitet durch User
Hobby schrieb: > Der MSP ist aktuell die beste Variante, wenn es kein ARM sein soll. Im > Gegensatz zum ST8 oder kleinen AVR hat er 16 Bit. Und das bedeutet in der Praxis? Dürfen die deswegen keine 16 Bit rechnen? Na ein Glück, daß meinem AVR noch niemand gesagt hat, daß er keine 16Bit rechnen darf. Der rechnet char, int, long, long long und float zu meiner vollsten Zufriedenheit. Nur double kann der AVR-GCC leider nicht.
Für die genannten Randbedingungen ist der MSP aktuell die beste Wahl. Da beisst die Maus keinen Faden ab. Keiner sagt, dass die 8 Bitter keine 16 oder 32 Bit rechnen können. :-( Aber der 16 Bitter kann das besser. Das ist nur ein weiteres Argument, nicht das ausschlaggebende. Hast bisher bessere Beiträge geschrieben. Die Polemik und Unterstellung passt nicht zu dir. :-(
Hobby schrieb: > Hast bisher bessere Beiträge geschrieben. Die Polemik und Unterstellung > passt nicht zu dir. :-( Peters "Polemik" ist doch eher eine sarkastische Antwort auf Hobby schrieb: > Der MSP ist aktuell die beste Variante, wenn es kein ARM sein soll. Im > Gegensatz zum ST8 oder kleinen AVR hat er 16 Bit. Und (nicht böse sein) Deine Aussage ist schon ziemlich dogmatisch. WIE kommst Du zu dieser Aussage ? Du stellst das einfach als Glaubenssatz in den Raum und alle sollen es glauben. Du schreibst auch nicht, warum 16-Bit für Dich (!) ein sehr wichtiges Kriterium ist. Viele Anwendungen brauchen die 16-Bit garnicht in Hardware. Da reicht es auch, wenn der C-Compiler entsprechenden Code dafür zusammenbastelt. Also nicht gleich so hochgehen ;-) Grüße Andreas
Andreas H. schrieb: > Peters "Polemik" ist doch eher eine sarkastische Antwort auf Ja, das kann der Peter auch ganz von alleine beantworten. Es kann ja nicht sein, dass hier ständig User für andere antworten.
khg schrieb: > Ja, das kann der Peter auch ganz von alleine beantworten. > > Es kann ja nicht sein, dass hier ständig User für andere antworten. Das war doch gar nicht Andreas' Intention. ;)
:
Bearbeitet durch User
khg schrieb: > Ja, das kann der Peter auch ganz von alleine beantworten. > > Es kann ja nicht sein, dass hier ständig User für andere antworten. Dirk K. schrieb: > Das war doch gar nicht Andreas' Intention. ;) Eben. Ich habe nicht für Peter geantwortet. Das kann er ganz sicher auch allein. Ich habe nur mal geschrieben, wie sich das Ganze für mich darstellte. Und das war ja schon "etwas" anders als Hobby sich das vorstellte. Grüße Andreas
Dirk K. schrieb: > Das war doch gar nicht Andreas' Intention. ;) Schon wieder so ein Quergeantworte.
>MSP430 lassen sich im Assembler sehr elegant programmieren und sind als >16 Bitter ohne Klimmzüge für weite Bereiche einsetzbar. Ja, stimmt. Aber die sind sehr langsam u. brauchen für etwas kompliz. Befehle doch sehr viele Taktzyklen!. PIC24/33 z.B. wären da viel besser u. schneller; zudem deren PPS (fast) einmalig ist. für >im Assembler sehr elegant programmieren .. ist wohl R32C unschlagbar (?)
Dirk K. schrieb: > "Die beste Variante" ist doch sicherlich sehr subjektiv. Für mich das > Beste ist nicht für dich das Beste. Mit der Einstellung hast Du aber ganz schnell alle MCU Religionsgemeinschaften gegen Dich. Solche Ansichten werden hier schnell als eklatante Dummheit ausgelegt und könnten dazu führen das Du Dich ratz fatz in einem Umerziehungslager wiederfindest. Wie sonst sollte man Dich bemitleidenswertes Geschöpf von Deinem Wahn befreien auf das Du den falschen Göttern abschwörst und die einzig wahre MCU erkennst. Dagenen ist der Nahe Osten ja ein Bällebad. [Achtung ! Kann vereinzelt Spuren von Sarkasmus enthalten]
khg schrieb: > Dirk K. schrieb: >> Das war doch gar nicht Andreas' Intention. ;) > > Schon wieder so ein Quergeantworte. Ui, der ist jetzt unerwartet. http://de.wikipedia.org/wiki/Emoticon - zum besseren Verständnis des oben Geschriebenen. @Michael: ThumbsUp! :D
:
Bearbeitet durch User
Man kann alles kaputt reden. Hier hat jemand eine konkrete Frage gestellt, seine Randbedingungen und eigene Einschätzung abgegeben und dafür kann man die geeignetste HW benennen: MSP430. So einfach ist das. :-P
Du kannst natürlich mit einem Trecker zum Aldi einkaufen fahren. Ein Golf Variant ist aber viel angemessener - entsprechend einem ATtiny13 oder 85.
Du meinst der Atiny ist ein Bobbycar im Vergleich? Da hast du recht. :-) Der MSP ist moderner, hat bessere Features, hat 16 Bit und keinen einzigen Nachteil gegenüber den AVR. Warum dann die zweite Geige spielen? :-P Billiger und einfacher ist der Einstieg auch noch. Aber das hatten wir ja schon.
Endlich mal wieder ein Popcorn-Thread. Der Thread-Ersteller hat sich wohl schon längst ausgeklingt...
Moby schrieb: > "Richtig" ist stets das einfachste. In diesem Fall also wieder mal > 8-Bit AVR ;-) Aha, der ohne Ahnung ist auch wieder da? Es geht doch gar nicht um 32Bit ARM. Verteufelst du jetzt alles größer 8Bit? Aber na klar, im Sandkasten spielt man ja mit Förmchen. Der TO hat bestimmt schon das Launchpad bestellt, das war bereits seine Vorauswahl. :-) AVR war gestern (gut), heute gibt es Besseres fürs gleiche Geld und weniger Einarbeitungsaufwand.
Hobby schrieb: > AVR war gestern (gut) AVR war vorgestern (schon nicht gut) Hobby schrieb: > Der MSP ist moderner, hat bessere Features Zur Zukunft vom MSP: "MSP-430-Chef wechselte zu Freescale. Sein Nachfolger war zuvor General Manager für die ARM-basierten MPU-Produkte."
Hobby schrieb: > heute gibt es Besseres fürs gleiche Geld und > weniger Einarbeitungsaufwand. Na Humor haste wirklich- weil, Ahnung kann das ja nicht sein... Für die Mini-Schaltungen des TO (und auch noch zehn Nummern größer) gibts nix passenderes als AVR. Das galt gestern, gilt heute und sicher noch ne ganze Weile.
Lothar schrieb: > "MSP-430-Chef wechselte zu Freescale. Sein Nachfolger war zuvor General > Manager für die ARM-basierten MPU-Produkte." Das interessiert in diesem Zusammenhang 0,nix
> AVR war gestern (gut), heute gibt es Besseres fürs gleiche Geld und > weniger Einarbeitungsaufwand. Ich würde es sogar noch drastischer forlmulieren: Es gibt heute für weniger Geld wesentlich Besseres. Für 6 euro gibts doch schon ganze Cortex M3 Evaluationboards inklusive Programmer/Debugger und Target. Bei AVR undenkbar. Dennoch würde ich sagen, dass jeder das nutzen sollte womit er am Besten zurechtkommt. Allerdings würde ich einem Anfänger nicht mehr zu einem Atmega raten. Wenn man sich schon in etwas neues einarbeiten will/muss, dann doch lieber etwas zeitgemäßes.
schnuppu schrieb: > Es gibt heute für > weniger Geld wesentlich Besseres. Wesentlich komlizierteres. schnuppu schrieb: > zeitgemäßes ... ist zeitlos das was am einfachsten ist. Warum es wohl immer noch RS232 gibt?
Moby schrieb: > ... ist zeitlos das was am einfachsten ist. Schon länger keinen Abakus mehr gesehen ... Moby schrieb: > Warum es wohl immer noch RS232 gibt? Wo gibt es das noch? Auch Industriesteuerungen kommen jetzt mit USB oder Ethernet.
Lothar schrieb: > keinen Abakus Na der Taschenrechner ist da doch einfacher, oder? Lothar schrieb: > Wo gibt es das noch? So spätnachts noch zu Späßchen aufgelegt ?
Angehängte Dateien:
-
billich-nano.jpg
26 KB -
billich-UNO.jpg
36 KB
schnuppu schrieb: >> AVR war gestern (gut), heute gibt es Besseres fürs gleiche Geld > und >> weniger Einarbeitungsaufwand. > > Ich würde es sogar noch drastischer forlmulieren: Es gibt heute für > weniger Geld wesentlich Besseres. > > Für 6 euro gibts doch schon ganze Cortex M3 Evaluationboards inklusive > Programmer/Debugger und Target. Bei AVR undenkbar. Cool, das würde ich gerne sehen, für 6 Euro inklusive Versand ein benutzbares M3-Board mit Programmer/Debugger. Hast du einen Beleg für diese Behauptung? Ich sehe als billigste Cortex-Mx-Lösung mit Programmer/Debugger die STM32F0-Disco für 12 € inklusive Versand. Und da gibt es keine Einfachstlösung á la Arduino-GUI, die einstöpseln - frickeln - flashen und starten erlauben würde. (Lässt sich auch ohne Arduino-Lib nutzen, oder man nimmt AVR-GCC und Eclipse und hat dann sogar richtiges Programmieren.) Den ersten Teil kann man natürlich äußerst simpel widerlegen, dass das der größte textgewordene Blödsinn ist: Fertig aufgebauter ATmega328 mit USB-zu-Seriell-Anbindung: http://www.ebay.de/itm/360954055339 - 3,04€ inklusive Versand ATmega328 mit USB-zu-Seriell für die DIP-Ausführung: http://www.ebay.de/itm/231258586488 5,98€ inklusive Versand
:
Bearbeitet durch User
Es ist immer dasselbe, auf das solche Threads hinauslaufen: AVR gegen 32 Bit Man soll doch bitte das benutzen, was einem am meisten liegt bzw was man kennt. Ob irgendein Board 1-2 Euro teurer ist, ist doch für den Heimbereich (und um den ging es dem OP) vollkommen irrelevant. Viel wichtiger ist, dass man damit schnell die gewünschten Ergebnisse erhält. Der OP schreibt: > Beruflich arbeite ich im wesentlichen mit STM32XX, doch die sind > einfach etwas überdimensioniert für solche Projekte. Deswegen suche ich > für kleine Schaltungen eine Alternative. Das würde ich mir gut überlegen. STM32 kennst Du doch sehr gut und von ST gibt es wirklich für fast jede Anwendung einen passenden Chip für wenig Geld. Warum sollte man sich da in etwas vollkommen Neues einarbeiten? Wir haben bspw. alles von AVR auf STM32 umgestellt, eben weil wir nur eine Architektur pflegen und beherrschen müssen, aber gleichzeitig aus der größten Bandbreite an Leistung (F0-F4) auswählen können. Die Zeit, die wir damit sparen, wiegt die paar Cent mehr als auf. Man kann dann eben einen 32-Bitter sowohl für eine 7-Segment-Anzeige als auch Videostreaming auf einem 1024x800-TFT ein. Das ist für uns der große Vorteil. Maze schrieb: > PS: Ich möchte keinen Glaubenskrieg zwischen den Anhängern der > verschiedenen µC-Familien damit provozieren... Ich fürchte, dafür ist es zu spät ;-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Wir haben bspw. alles von AVR auf STM32 umgestellt, Ich hätte da mal ne Frage dazu: Warum STM32 - und das so häufig? Wenn ich hier im Forum lese, dann sehe ich an jeder Ecke die STM32 mich angrinsen. Ich hab ja nix dagegen, aber es ist schon ein bemerkenswerter Unterschied in der Häufigkeit zwischen ST und NXP zu beobachten. Dabei finde ich die Teile von NXP gleichwertig oder stellenweise deutlich besser. Da hatte man schon vor Jahren nen 32 Bit breiten, für SDRAM geeigneten externen Bus, ebenso eine TFT-Displayanschluß (wo ST inzwischen nach langer Zeit endlich nachgezogen hat). Ist das alles eine Folge der billig in die Welt gestreuten Discovery-Boards? Also schreib doch mal, warum ST bei euch und nicht NXP. W.S.
Welcher Mikrocontroller bevorzugt wird, hängt vom Forum. D.h. hier gibt es vermutlich einfach bedeutend mehr Leute die AVR oder beispielsweise STM einsetzen UND sich darüber austauschen. Das ist auch wohl der Grund, warum AVR oder ein ARM hier als wa(h)re weisheit angepriesen wird. In anderen Foren sind es halt anders aus.
W.S. schrieb: > Ich hätte da mal ne Frage dazu: Warum STM32 - und das so häufig? > ... > Ist das alles eine Folge der billig in die Welt gestreuten > Discovery-Boards? > Also schreib doch mal, warum ST bei euch und nicht NXP. Das war eigentlich mehr oder weniger Zufall. Ich wollte auf Cortex umstellen, einfach weil ARM schon mehr und mehr Standard wird und wir mit AVRs bzgl. GUI/Displaygrößen einfach an der grenze angekommen sind. Ob die Chips jetzt von Atmel, NXP oder ST sind, war erstmal nebensächlich. Wichtig war eine Entwicklungsoberfläche/Toon chain, die unter Linux läuft und auch preiswert ist (nur ein Teil unserer Arbeit besteht aus der programmierung von Controllern, daher sind fünfstellige Beträge dafür hier nicht wirtschaftlich). Warum es nun STM32 wurde? Das lag zuerst einmal daran, dass die STM32-Reihe unsere Anforderungen sehr gut abdeckt und nach oben hin viel Luft für zukünftige Entwicklungen ist. Zusätzlich hat sich ST um uns sehr bemüht, obwohl wir wirklich nur Kleinstmengen abnehmen. Es gab sehr gute kostenlose Seminare zur Einführung; ich habe zwei, drei Telefonnummern/E-Mailadressen von ST, unter denen ich bisher immer kompetente Hilfe selbst zu kniffligen Problemchen erhalten habe ("Schicken Sie mir einfach kurz den Codeschnipsel, ich schaue mal drüber"). Und das alles ohne 0900-Nummer. Für Muster reicht ein kurzer Anruf, dann hab ich die morgen im Briefkasten. Und wie gesagt: unsere Stückzahlen bewegen sich im unteren dreistelligen Bereich - alle Chips von ST zusmamengenommen! Das habe ich zumindest so bei anderen Herstellern noch nicht erlebt. Und natürlich findeen sich im Netz einfach auch immer mehr Infos/Schaltungen und Code für die STM32-Serie. Du siehst das ja schon hier im Forum - es wird kontinuierlich mehr. Man nutzt natürlich lieber etwas, bei dem man mit großer Wahrscheinlichkeit im Netz jemanden findet, der das Problem auch schon in einer ähnlichen Form hatte. Ähnlich lief/läuft das ja bei den AVRs ab. Die STM8-Serie ist auch sehr schön, aber es kennt sie eben "keine" Sau :-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Wir haben bspw. alles von AVR auf STM32 umgestellt, eben weil wir nur > eine Architektur pflegen und beherrschen müssen, aber gleichzeitig aus > der größten Bandbreite an Leistung (F0-F4) auswählen können. So kann ein Schuh draus werden- betrieblich ein eleganter, fast zwingender Gedankengang. Als Bastler kann ich es mir freilich leisten, einen Leistungs-/Komplexitätslevel tiefer zu gehen und mich in der Range vom kleinstem Tiny bis Xmega zu bedienen, wenn - es keine allzu speziellen Anwendungen sind - es keine datenintensiven Anwendungen sind - wenn man datenintensive/komplexe Anwendungen auf spezielle Zusatzhardware auslagern und etwa über eine UART Schnittstelle bedienen kann - genug Zeit und Lust für maschinennahes ASM-Programmieren zur Verfügung steht!
>Ist das alles eine Folge der billig in die Welt gestreuten >Discovery-Boards? Bei den meisten wohl ja. Man hats halt hat da liegen, dann benutzt man es (darauf hofft der Hersteller). Im Vergleich zu RX100/200/600/700 sieht sowohl STM32 als auch LPC.. ganz schön alt aus.
Moby schrieb: > genug Zeit und Lust für maschinennahes ASM-Programmieren zur Verfügung > steht Wenn Du genug Zeit hast, warum gibst Du dann ARM-Assembler nicht mal eine Chance? Vielleicht änderst Du ja dann Deine Meinung zu AVR-Assembler. Einfach den kleinsten LPC810 für 50 Cent aufs Steckbrett und ein 4 EUR USB-seriell-Kabel und los geht's :-)
Es gibt ja nicht nur billige Dicovery-Boards, sondern eben auch andere billige Minimal-Boards. Die muss man per Jumper zum Flashen via UART umstöpseln - haben aber schon gut Rechen-Wumms. Solche STM32F103-Breakout-Boards gibt es für 5,50€. Ok, ich hatte zuvor eine F0-Disco da, aber die ist mir für einige Sachen schon zu Schade/teuer. Zumindest in diesem Kontext. Die Suche nach Minimal- oder günstgen Boards für NXP/Freescale/... endet darin, dass es unter 10€ einfach nichts gibt, es geht bei 18 Euro + Versand los. Da bekomme ich schon fast eine F429-Disco, auf jeden Fall aber eine F103-basierte vergleichbare Lösung mit Touchdisplay, V-Version des Prozessors mit endlos vielen IOs und so weiter. Im Hobby-Bereich daher eher STM als NXP/Freescale/... .
:
Bearbeitet durch User
Lothar schrieb: > warum gibst Du dann ARM-Assembler nicht mal > eine Chance? Michael Knoelke schrieb: > Geht man runter auf assembler Ebene und debugt tief auf Hardwarebene ist > weniger oft mehr und die ARM werden schnell ganz schön eklig. Zum einen. Unnütz komplex das Ganze und wie Du weißt bei ARMs ganz sicher nicht die geeignetste Programmierart. Zum anderen will auch 'genug' Zeit nicht sinnlos verbraten werden- wenns denn AVR Assembler locker tut ;-)
Michael Knoelke schrieb: > Geht man runter auf assembler Ebene und debugt tief auf Hardwarebene ist > weniger oft mehr und die ARM werden schnell ganz schön eklig. Warum das eigentlich? Was ist denn zB beim ARMv7M (für Cortex-M3,4) Assembler so eklig, bzw. ekliger als zB AVR? Beispiel: Offset-Zugriff. Angenommen in r0 befindet sich ein Pointer, und man möchte 1 Byte von der Adresse des Pointers + 7 laden. ARMv7M:
1 | ldb r1, [r0, #7] |
AVR (Pointer in r0/r1):
1 | mov r30, r0 |
2 | mov r31, r1 |
3 | adiw r31:r30, 7 |
4 | ld r2, Z |
Da finde ich den ARMv7M Code doch etwas... einfacher?
Chris D. schrieb: > Das war eigentlich mehr oder weniger Zufall. Naja, gut. Das ist wohl häufiger als man es i.allg. erwartet. Chris D. schrieb: > ich habe zwei, drei > Telefonnummern/E-Mailadressen von ST,... Das ist gut. Mir fehlt das bei ST völlig. Chris D. schrieb: > Warum es nun STM32 wurde? Das lag zuerst einmal daran, dass die > STM32-Reihe unsere Anforderungen sehr gut abdeckt und nach oben hin viel > Luft für zukünftige Entwicklungen ist. OK, in diesem Punkt unterscheiden wir uns. ST ist ja mittlerweile beim (mühseligen) Aufholen, aber das bisherige Portfolio von ST war m.M. nicht gerade berauschend sondern eher "me too" - und so etwa 30..40% teurer als NXP sind sie auch. Günstig ist für dich, daß du für einige periphere Cores die gleichen Treiber nehmen kannst wie bei NXP: beim SDIO Port zum Beispiel. Der USB-Core ist hingegen ne Krücke, Statusänderung durch VerXORen der Statusbits.. grrmpf. Dirk K. schrieb: > Die Suche nach Minimal- oder günstgen Boards.. Nun gut, ich hab sowas vermutet. Aber es erstaunt mich schon, daß so viele Leute hier auf fertige Eval-Boards angewiesen sind. OK, ich sehe da Unterschiede zwischen Gewerblich und Privat, die gerade hier in D zu einem krassen Mißverhältnis an Möglichkeiten geführt haben. W.S.
Dr. Sommer schrieb: > mov r30, r0 > mov r31, r1 > adiw r31:r30, 7 > ld r2, Z Aber,aber, ldd r16,Z+7 gibts da auch noch ;-)
Dr. Sommer schrieb: > Warum das eigentlich? Was ist denn zB beim ARMv7M (für Cortex-M3,4) > Assembler so eklig, Mehr als die Syntax ist es die ausufernde Systemarchitektur, die das nackte Programmieren in Asm, ohne in Komfort-C Bibliotheken gebettet zu sein, so eklig macht. Das sind Hochsprachen-Prozessoren, viel mehr noch als die simplyAVRs ;-)
Moby schrieb: > Dr. Sommer schrieb: >> mov r30, r0 >> mov r31, r1 >> adiw r31:r30, 7 >> ld r2, Z > > Aber,aber, ldd r16,Z+7 gibts da auch noch ;-) Genau das würd mich auch bei der Wahl zu einem Miniprojekt-µC interessieren. Vielen Dank auch für die tief blicken lassenden Beiträge der Spezialratgeber.
Moby schrieb: > Aber,aber, ldd r16,Z+7 gibts da auch noch ;-) Ach, ldd, ja. Aber das klappt auch nur mit Konstanten, beim ARMv7M kann man noch ein Register als Offset draufaddieren ;-) Moby schrieb: > Mehr als die Syntax ist es die ausufernde Systemarchitektur Und was heißt das jetzt? Dass man zum Interrupt enablen nicht 1 sondern 2 Bits setzen muss?
W.S. schrieb: > daß so > viele Leute hier auf fertige Eval-Boards angewiesen sind Tja, wenns denn unbedingt die sooo sehr verlockend günstigen sooo sehr leistungsstärkeren ARM Derivate sein sollen dann muß das wohl so sein. Dr. Sommer schrieb: > Da finde ich den ARMv7M Code doch etwas... einfacher? Hab gerade nochmal einen Blick ins über 1000 seitige ARMv7-M Architecture Reference Manual geworfen... Also beim besten Willen, wer da von 'einfach' redet dem ist nicht zu helfen. Und dermaßen unübersichtlich und undurchsichtig. Aber das liegt wohl im System. Möge das jeder Interessierte mal selbst mit der AVR Doku vergleichen!
Dr. Sommer schrieb: > beim ARMv7M kann > man noch ein Register als Offset draufaddieren ;-) Na sicher doch. Und noch tausend andere Dinge mehr! Flexibel bis zum geht nicht mehr. Wann begreift der Profi endlich, daß mehr und mehr Komplexität für die Anwendung mehr und mehr Hindernis ist ? SimplyAVR sag ich da nur. Schneller am Ziel!
Moby schrieb: > Also beim besten Willen, wer > da von 'einfach' redet dem ist nicht zu helfen. Das kommt drauf an. Der ARMv7M ist halt mächtig, ja; aber du musst noch lange nicht alle Features nutzen um die 7-Segment-Anzeige anzusteuern, und auch nicht alle 1000 Seiten lesen. Moby schrieb: > Und dermaßen > unübersichtlich und undurchsichtig. Wieso das? Es ist gut strukturiert und sortiert, wie sich das für eine technische Dokumentation gehört. Schritt-für-Schritt-Anleitungen gehören in ein Tutorial.
Moby schrieb: > Dr. Sommer schrieb: >> beim ARMv7M kann >> man noch ein Register als Offset draufaddieren ;-) > > Na sicher doch. Und noch tausend andere Dinge mehr! Achso. Wie heißt die Instruktion dafür? > Flexibel bis zum > geht nicht mehr. Und der Cortex-M3,4 ist nicht flexibel? Weil er mehr kann? > Wann begreift der Profi endlich, daß mehr und mehr > Komplexität für die Anwendung mehr und mehr Hindernis ist ? SimplyAVR > sag ich da nur. Schneller am Ziel! Ich hatte immer das Gefühl AVR hätte weniger Rechenleistung. Achja, der ärmste Profi, der von der Komplexität erschlagen wird... Wenn selbst Hobbybastler den ARMv7M bewältigen, dann kann der Profi das auch.
Wenn ich Brötchen holen fahre, will ich nicht Porsche fahren, sondern Brötchen haben.
dumdidumm schrieb: > Wenn ich Brötchen holen fahre, will ich nicht Porsche fahren, sondern > Brötchen haben. Für manche aus der Sekte der ARMen Komplexitätsfanatiker hier ist eben Mittel&Weg das Ziel und nicht die Anwendung selbst, könnte man meinen.
Ach, wenn man mal tatsächlich die Komplexitat/Ekligkeit der Programmierung am konkreten Beispiel vergleichen will kommen nur noch Allgemeinplätze und dumme Sprüche. "simplyAVR", ist das dein persönlicher Werbespruch? Kriegst du Provision dafür? Warum nicht simplyARM?!?!!1
Dr. Sommer schrieb: > simplyAVR", ist das dein > persönlicher Werbespruch? Nee- der bringts auf den Punkt. Dr. Sommer schrieb: > simplyARM? Wer das schon mal gehört hat der hebe den ARM
dumdidumm schrieb: > Wenn ich Brötchen holen fahre, will ich nicht Porsche fahren, > sondern Brötchen haben. Wenn aber der Porsche in der Garage steht, soll ich dann extra noch einen Fiat kaufen. @all Der Moby ist doch eine one man frikkel show. Wen interessiert seine Meinung? Lasst ihn links liegen und argumentiert mit technisch interessierten Leuten. Und wieder zum Ausgangthema: MSP scheint noch Kandidat Nr.1 für den TO.
Moby schrieb: > Hab gerade nochmal einen Blick ins über 1000 seitige ARMv7-M > Architecture Reference Manual geworfen Die Original 10 Seiten ARM Assembler Manual tun es für den Anfang auch: http://www.riscos.com/support/developers/bbcbasic/appendices/armassembler.html Übrigens ein ARM Assembler Programm für einen DIP8 M0 läuft auch auf einem Raspberry Pi mit ARM11 :-)
Hobby schrieb: > Der Moby ist doch eine one man frikkel show. Sehr nett, danke. Werd weiter gegen den Strich bürsten, das haben manche hier bitter nötig ;-)
Du bürstest nicht gegen den Strich, sondern laberst nur Sch... ähh Mist! Von mC hast du offensichtlich keinerlei Ahnung.
Hobby schrieb: > dumdidumm schrieb: >> Wenn ich Brötchen holen fahre, will ich nicht Porsche fahren, >> sondern Brötchen haben. > > Wenn aber der Porsche in der Garage steht, soll ich dann extra noch > einen Fiat kaufen. Nur wenn es dein Wunsch wäre wie der des TO aus dem Eröffnungspost (den er später auch nochmal bestätigt hat): "... Beruflich arbeite ich im wesentlichen mit STM32XX, doch die sind einfach etwas überdimensioniert für solche Projekte. Deswegen suche ich für kleine Schaltungen eine Alternative."..."
Hobby schrieb: > Sch... ähh Mist! ... ist wohl alles das was Dir nicht in den Kram passt. Und im übrigen halt Dich an Deine Regel und ignorier mich ;-)
Moby schrieb: > ... ist wohl alles das was Dir nicht in den Kram passt. Ich korrigiere: Deinen Hobby-Horizont übersteigt ;-)
W.S. schrieb: > Ist das alles eine Folge der billig in die Welt gestreuten > Discovery-Boards? > Also schreib doch mal, warum ST bei euch und nicht NXP. Die ARMen NXP waren mir im Vergleich zu den 100MHz RX von Renesas einfach zu langsam und intern mit (für mich) zu wenig RAM bestückt. Das STM Discovery-Board winkte dann mit 196kB RAM und 168MHz zu einem verlockenden Preis. Verbunden mit der Demo-Version von IAR zeigte sich schnell die Leistungsfähigkeit des M4. Die NXP-Boards, die ich mir auch besorgt hatte, waren direkt an CodeRed gekoppelt, womit ich nie warm geworden bin. MCUA schrieb: > Im Vergleich zu RX100/200/600/700 sieht sowohl STM32 als auch LPC.. ganz > schön alt aus. Jein :-) Der STM32F4xx ist richtig schnell und der Code ist kompakter als bei RX (obwohl es anders zu erwarten wäre). Was bei Renesas immer schwieriger geworden ist, ist die Verfügbarkeit zu akzeptablem Preis. Allein future electronics konnte bis vor einigen Monaten gängige Typen ab Lager liefern; das ist aktuell wohl vorbei. DK oder RS sind zu teuer für die Serie und beim Distributor bekommt man Preis/Lieferzeit nur für genau den Typen, den man anfragt; online hat man keinen Einblick, ob ein ähnlicher Typ besser verfügbar ist oder sogar günstiger und auf Lager liegt. Aber vielleicht kenne ich auch nicht die richtigen Telefonnummern für prompte Bedienung :-) Sobald man aber ins Detail mit dem STM gehen muß, sieht man, dass die RXe wesentlich eleganter sind. Beim STM wollte ich einen Speicherbereich (Ausgabe eines Bildes 180° gedreht) in umgekehrter Reihenfolge ausgeben: Pustekuchen. Beim RX hätte ich einfach die DMA-Ausgabe rückwärts initialisiert und den Speicher belassen, wie er ist. Beim STM mußte ich das Bild im Speicher verdreht anlegen, was deutlich aufwendiger war. Dies nur als kleines Beispiel. Nichtsdestoweniger, für die kleinen Sachen zwischendurch ist ein AVR immer noch bestens geeignet.
m.n. schrieb: > Sobald man aber ins Detail ... gehen muß, kommt der Teufel zum Vorschein! Bei 8-Bit weniger, bei höherbittigem mehr. Deshalb: Simple MC nutzen solange wie möglich! Auch ein AVR ist nicht nur für "kleine Sachen zwischendurch" brauchbar!
Dirk K. schrieb: > Cool, das würde ich gerne sehen, für 6 Euro inklusive Versand ein > benutzbares M3-Board mit Programmer/Debugger. Hast du einen Beleg für > diese Behauptung? Hi Dirk, ok mittlerweile kostet es 7,9 Euro (exklusive Versand, den man sich aber sparen kann, wenn man eine Sammelbestellung macht). http://de.mouser.com/ProductDetail/STMicroelectronics/STM32VLDISCOVERY/?qs=sGAEpiMZZMud4uhvMu9vpfd0cIzCMFfc Aber auf 1,9Euro kommt es doch jetzt nicht an. Vergleichen wir das doch mal mit dem Atmega. Was kostet denn ein Programmer für Atmegas, der nicht nur programmieren, sondern auch debuggen kann? Und wir sprechen dann nur von einem Debugger/Programmer und nicht von einem kompletten Board mit Target. Wenn ich bei Reichelt schaue, kostet ein einfacher Programmer (ohne Debugging!) stolze 36 Euro. http://www.reichelt.de/AT-AVR-ISP/3/index.html?&ACTION=3&LA=446&ARTICLE=45040&artnr=AT+AVR+ISP&SEARCH=mk2 Für rund 20 Euro bekomme ich das STM32F429I-DISCO mit Programmer/Debugger & Target & 2.4" QVGA TFT LCD & SDRAM & 3D Gyroskop/Beschleunigungssensor und vielem mehr. http://de.mouser.com/ProductDetail/STMicroelectronics/STM32F429I-DISCO/?qs=sGAEpiMZZMvh0aGzCjJ9ppxivASqTeq%2f lg schnuppo
schnuppu schrieb: > Was kostet denn ein Programmer für Atmegas, Na sind wir doch mal ehrlich: Populäres hat immer seinen Preis. Wobei ich würd hier gleich den neuen Atmel-ICE empfehlen der vielseitiger einsetzbar ist. Ansonsten führen viele Wege (auch günstiger) nach Rom, man informiere sich doch mal in diesem Forum! schnuppu schrieb: > Für rund 20 Euro bekomme ich das STM32F429I-DISCO mit Super. Ist das Ding paßgenau für Dein Projekt? Gratuliere. Als Basis für viele weitere wirds wohl kaum taugen, wenn die Gehäusegröße auch mal kleiner ausfallen soll. Und wenns dann mit allem Pipapo zu teuer wird weil vielleicht nur ein Bruchteil der Hardware zur Anwendung kommt.
dumdidumm schrieb: > "... Beruflich arbeite ich im wesentlichen mit STM32XX, doch die sind > einfach etwas überdimensioniert für solche Projekte. Deswegen suche ich > für > kleine Schaltungen eine Alternative."..." Was ist an einem 14-Pin Controller für 30 Cent (Stückzahlenpreis) mit einer 40-MegaByte-Open-Source-IDE (Selbst das AVR Studio 4 war größer, von dem Atmel Studio ganz zu schweigen) und einem Debugger < 10 Euro denn bitte überdimensioniert? Wer Einfachkeit predigt aber Assembler verteidigt, hat offensichtlich einen gewaltig an der Waffel. Wer einfach haben will, nimmt Arduino oder etwas ähnliches.
Antimedial schrieb: > Einfachkeit predigt aber Assembler AVR Assembler IST einfach (Klartext). Antimedial schrieb: > Was ist ... > denn bitte überdimensioniert? http://www.pjrc.com/teensy/beta/DDI0403D_arm_architecture_v7m_reference_manual.pdf Wer das Zeugs für normale Projekte empfielt hat in meinen Augen auch einen ... ;-)
Moby schrieb: > AVR Assembler IST einfach (Klartext). Nein. Assembler ist generell nicht einfach, weil man immer erst den inneren Aufbau des Prozessors verstanden haben muss, um zu Programmieren. Dagegen ist jede Hochsprache viel einfacher. Moby schrieb: > Wer das Zeugs für normale Projekte empfielt hat in meinen Augen auch > einen ... ;-) Tja, wenn man eine Hochsprache benutzt, braucht mich das ganze gar nicht zu interessieren. Wenn ich es einfach haben will, nehme ich eine Hochsprache und einen ARM-Prozessor.
> Super. Ist das Ding paßgenau für Dein Projekt?
Wenn nicht, kann man es doch immernoch als Debugger/Programmer für alle
stm benutzen. Da gibts auch ganz winzige M0 Typen. :-)
Oder man greift zu einem anderen Evalboard, wo weniger drauf ist.
Antimedial schrieb: > Assembler ist generell nicht einfach, weil man immer erst den > inneren Aufbau des Prozessors verstanden haben muss, Das schadet aber ganz und gar nicht und ist im Fall von AVR und im Gegensatz zu ARM wirklich keine Wissenschaft. Antimedial schrieb: > Wenn ich es einfach haben will, nehme ich eine > Hochsprache und einen ARM-Prozessor. Na sicher.
> ich würd hier gleich den neuen Atmel-ICE empfehlen für über 100 euro? Nur zum proggen und debuggen von AVR-Urgesteinen? Mich überzeugt das nicht... ;-)
schnuppu schrieb: > Wenn nicht, kann man es doch immernoch als Debugger/Programmer für alle > stm benutzen. Da gibts auch ganz winzige M0 Typen. :-) Na gut, ist aber von ca. 10 Euro Mehrpreis fürs populäre AVR-Programmiergerät abgesehen dann auch keine andere Sachlage. Nur das die AVRs trotzdem mehr simply sind ;-)
schnuppu schrieb: > für über 100 euro? Nur zum proggen und debuggen von AVR-Urgesteinen? Informier Dich mal genauer. Alles falsch.
Moby schrieb: > schnuppu schrieb: >> Wenn nicht, kann man es doch immernoch als Debugger/Programmer für alle >> stm benutzen. Da gibts auch ganz winzige M0 Typen. :-) > > Na gut, ist aber von ca. 10 Euro Mehrpreis fürs populäre > AVR-Programmiergerät abgesehen dann auch keine andere Sachlage. > Nur das die AVRs trotzdem mehr simply sind ;-) Naja wenn die 20 euro zuviel sind, gibts ja immernoch das CortexM3 board für rund 8 euro mit programmer/debugger + Target. Aber die Atmegas sind natürlich weniger komplex, dass ist schon richtig. Habe ja selber mit den Teilen angefangen. Allerdings sind die Cortexe genauso einfach zu benutzen, wenn man eine Hochsprache benutzt. Habe ich jedenfalls für mich selber so erfahren. Es entfallen jedenfalls die Probleme mit den Fuses, wo ein Anfänger schonmal auf die Nase fallen kann. Ansonsten muss man auch wenig ins Datenblatt gucken, da es die Library von st gibt. :-))
Moby schrieb: > schnuppu schrieb: >> für über 100 euro? Nur zum proggen und debuggen von AVR-Urgesteinen? > > Informier Dich mal genauer. Alles falsch. Moby schrieb: > Atmel-ICE ok ich korrigiere: Er unterstützt auch die 32bit Varianten. Aber deshalb 100 Euro löhnen?
Moby schrieb: > Das schadet aber ganz und gar nicht und ist im Fall von AVR und im > Gegensatz zu ARM wirklich keine Wissenschaft. Doch, es schadet, weil es nicht einfach ist! Moby schrieb: > Na gut, ist aber von ca. 10 Euro Mehrpreis fürs populäre > AVR-Programmiergerät abgesehen dann auch keine andere Sachlage. > Nur das die AVRs trotzdem mehr simply sind ;-) Und das populäre AVR-Programmiergerät bietet auch die Möglichkeit zu debuggen? Das macht die Entwicklung nämlich 1000 mal einfacher.
schnuppu schrieb: > Aber deshalb > 100 Euro löhnen? Die Basic-Variante kostet direkt bei Atmel immer noch 49 Dollar + Versand. Die einfachen AVRs sinds auf jeden Fall wert ;-) schnuppu schrieb: > genauso einfach zu benutzen, wenn man eine Hochsprache benutzt. Wenn, ja wenn vielleicht- und auch nur mit einigem Wissen um die Zusammenhänge. Man kann die Anwendung von Hunderten Bibliotheksfunktionen (die man auch erst mal im Detail kennen muß) ja gerne und je nach Erfahrung als einfach bezeichnen. Diesen jahrelangen Lernaufwand spare ich mir aber und spreche mit dem MC lieber ganz auf eigene Rechnung total eigenverantwortlich Klartext. Und das ist nun mal easy und mit dem AVR easy möglich.
Antimedial schrieb: > Doch, es schadet, Man sollte schon wissen was man programmiert. Egal mit welcher Sprache. Hochsprachler sind da aber erfahrungsgemäß im Nachteil ;-)
Moby schrieb: > Man sollte schon wissen was man programmiert. Egal mit welcher Sprache. > Hochsprachler sind da aber erfahrungsgemäß im Nachteil ;-) Nicht wirklich. Hochsprachen erlauben einen Überblick, den ein Assemblerprogrammier nie haben wird. Ganz zu schweigen von Wartbarkeit. Die Prozessorarchitektur wird ein Compilerhersteller sowieso besser begreifen als ein Möchtegern-Assembler-Heini wie du.
Antimedial schrieb: > Nicht wirklich Doch wirklich. Antimedial schrieb: > Hochsprachen erlauben einen Überblick, Über was bloß? Ihre Abhängigkeit von Bibliotheken und Compilereigenheiten vielleicht? Antimedial schrieb: > Möchtegern-Assembler-Heini Nicht nur "Möchtegern", sondern langjähriger "KannWirklich". Aber ein Antimedial findet eben immer wieder zielsicher auf sein Niveau zurück, nicht wahr? Ohne Beleidigung gehts nicht.
Moby schrieb: > AVR Assembler IST einfach Da sagt dieser Thread was anderes: Beitrag "AVR Assembler-Frage" Allein die Tatsache dass es keine solchen Threads zu ARM-Assembler gibt zeigt ja dass damit jeder zurecht kommt :-)
Also, ich programmiere mit MSP430 , und habe vor kurzem den neuen MSP430Debugger/Programmer mir EnergyTrace++ technologie zugelegt. Der Ti macht mir einen sehr guten Eindruck, sie veröffentlichen regelmäßig neue und billige StarterKits, sorgen viel um Community die MSP werden immer weiterentwickelt.
> Wenn, ja wenn vielleicht- und auch nur mit einigem Wissen um die > Zusammenhänge. Man kann die Anwendung von Hunderten > Bibliotheksfunktionen (die man auch erst mal im Detail kennen muß) ja > gerne und je nach Erfahrung als einfach bezeichnen. Diesen jahrelangen > Lernaufwand spare ich mir aber und spreche mit dem MC lieber ganz auf > eigene Rechnung total eigenverantwortlich Klartext. Und das ist nun mal > easy und mit dem AVR easy möglich. ich denke das es hier kein richtig oder falsch gibt. ich kann hier nur von mir selbst sprechen. bin komplett von den avr auf die stm umgestiegen. nutze die cortexe auch fuer einfache anwendungen vom lauflicht bis zum quadrokopter. ich stimme aber zu das die avr natuerlich schon sehr einfach zu handlen sind. allerdings kann die geringe leistung manche aufgaben auch erschweren weil man effizienter proggen muss. mein credo lautet: jeder sollte das nutzen was ihm zusagt. erst recht im hobbybereich...
Lothar schrieb: > Da sagt dieser Thread was anderes: Find ich nicht. Verständnisschwierigkeiten und beliebig komplizierte Konstruktionen sind mit jeder Sprache möglich. Und der C-Support erreicht ganz andere Dimensionen. Lothar schrieb: > Allein die Tatsache dass es keine solchen Threads zu ARM-Assembler gibt > zeigt ... daß ARM in Assembler wirklich ein hoffnungsloses Unterfangen wäre ;-)
Moby schrieb: > Und der C-Support erreicht ganz andere Dimensionen. Bei ARM braucht es keinen C-Support läuft auch so :-)
Moby schrieb: > ARM in Assembler Da gibt es zumindest keinen solchen Blödsinn (deswegen ist AVR übrigens auch kein RISC): SEC Set Carry CLC Clear Carry SEN Set Negative Flag CLN Clear Negative Flag SEZ Set Zero Flag CLZ Clear Zero Flag SEI Global Interrupt Enable CLI Global Interrupt Disable SES Set Signed Test Flag CLS Clear Signed Test Flag SEV Set Two’s Complement Overflow CLV Clear Two’s Complement Overflow SET Set T in SREG CLT Clear T in SREG SEH Set Half Carry Flag CLH Clear Half Carry Flag
schnuppu schrieb: > mein credo lautet: jeder sollte das nutzen was ihm > zusagt. erst recht im hobbybereich... Absolut. Und stets ergebnisorientiertes "Keep it simple", es sei denn der Weg ist das Ziel ;-)
Lothar schrieb: > keinen solchen Blödsinn Was ist daran aus Anwendersicht blödsinnig? Das sind doch klare Ansagen! ASM eben.
Moby schrieb: > Was ist daran aus Anwendersicht blödsinnig? Ich zumindest kann mir höchstens 20-30 Assembler-Befehle gut merken. Wenn nun für jede Aktion und jedes Spezialregister extra Befehle eingeführt werden, geht es nicht mehr ohne Manual. Oder die tollen extra Befehle werden einfach nicht genutzt.
Lothar schrieb: > Ich zumindest kann mir höchstens 20-30 Assembler-Befehle gut merken. Da bin ich vermutlich nicht besser. Der Instruktionssatz ist aber sehr übersichtlich und schnell nachzuschlagen. Manche Instruktionen haben zwar gewisse Einschränkungen, aber das moniert spätestens das Projekt-Building.
Moby schrieb: > Der Instruktionssatz ist aber sehr > übersichtlich und schnell nachzuschlagen. Ich bringe jetzt grade tatsächlich 30 ARM-Befehle ohne nachschlagen zusammen. Es gibt zwar ein paar mehr, aber diese 30 machen 99% aller Programme aus. Das letzte Mal wo ich was nachschlagen musste war in diesem Thread :-) Beitrag "wait condition mit ATmega* vs. Cortex-M4"
>Mehr als die Syntax ist es die ausufernde Systemarchitektur, die das >nackte Programmieren in Asm, ohne in Komfort-C Bibliotheken gebettet zu >sein, so eklig macht. Mit MacASM kann man das umgehen (zudem ist der ASM auch nicht so schlimm). (was aber nicht heisst, das wegen dem RISC nicht zu viele Takte nötig wären) >Der ARMv7M ist halt mächtig.. Nö, ist er nicht. > Hab gerade nochmal einen Blick ins über 1000 seitige ARMv7-M > Architecture Reference Manual geworfen Ein paar Seiten reichen, zur Befehlsübersicht. >Die ARMen NXP waren mir im Vergleich zu den 100MHz RX von Renesas >einfach zu langsam STM ist da auch nicht besser. >Der STM32F4xx ist richtig schnell und der Code ist kompakter >als bei RX (obwohl es anders zu erwarten wäre). Der Code kann bei ARM nicht kompakter sein. RX ist CISC, hat mächtigere Befehle, und was CM3/4 kann, kann RX schon lange. >Was bei Renesas immer schwieriger geworden ist, ist die Verfügbarkeit.. Richtiger Distributor? >Sobald man aber ins Detail mit dem STM gehen muß, sieht man, dass die >RXe wesentlich eleganter sind. Sieht die Industrie auch so. >> Sobald man aber ins Detail ... gehen muß, >kommt der Teufel zum Vorschein! Vonwegen. Erstmal ein RX-Datasheet ansehen.
MCUA schrieb: >>Die ARMen NXP waren mir im Vergleich zu den 100MHz RX von Renesas >>einfach zu langsam > STM ist da auch nicht besser. Ich zeige Dir gerne ein Beispiel, bei dem sich der STM32F407 mit 168MHz deutlich von einem RX610 mit 100MHz absetzt: http://www.mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-1 >>Der STM32F4xx ist richtig schnell und der Code ist kompakter >>als bei RX (obwohl es anders zu erwarten wäre). > Der Code kann bei ARM nicht kompakter sein. > RX ist CISC, hat mächtigere Befehle, und was CM3/4 kann, kann RX schon > lange. Beim obigen Beispiel habe ich die gleiche C-Quelle verwendet, die ursprünglich vom H8SX kommt; der Code vom F407 ist deutlich kompakter. Eigentlich sollte Dir aufgefallen sein, dass ich neben Dir und auch Olaf ein Freund von Renesas (u.a. der RXe) bin. Dennoch beurteile ich, was ich sehe und nicht, was in meine 'Religion' paßt :-) >>Was bei Renesas immer schwieriger geworden ist, ist die Verfügbarkeit.. > Richtiger Distributor? Offensichtlich; gerne folge ich Deiner Empfehlung.
MCUA schrieb: > Sieht die Industrie auch so. Deswegen ist Renesas ja auch so erfolgreich, dass sie gerettet werden mussten: http://www.elektroniknet.de/automotive/sonstiges/artikel/91662/
m.n. schrieb: > Eigentlich sollte Dir aufgefallen sein, ... Eigentlich ... ist diese Diskussion arg ausgeufert, wenn ich weiter oben von Porsches und Garagen lesen muß. Aber derzeit schüttet es wie aus Gießkannen und da fällt unserenem nix besseres ein, als seinen Senf hier dazuzugeben.. Es gibt m.M. ein ganz gewichtiges Argument gegen Renesas: Die Tools. Nicht daß ich ein besonderer Freund des gcc-arm-eabi oder wie der heißt wäre, aber allein die Verfügbarkeit von Tools, die auch ein privater Bastler einfach herunterladen und benutzen kann, ist ein Argument, was ein ziemliches Gewicht hat - und das ist unabhängig von der eigentlichen Qualität der konkreten Zielarchitektur. Ich hab von Glyn auch noch so ein Renesas-Board herumschwirren - oder besser gesagt: es ist sedimentiert, weil ich mich gefragt habe, ob es denn wirklich derart vorteilhaft wäre, den Kauf der Tools ins Auge zu fassen. Ansonsten kann man ne ziemlich saubere Trennlinie zwischen Arm und Konsorten und den sinnvollen Anwendungen für kleinere Chips ziehen: die Grafik. Wer ein buntes TFT anschließen will, wird mit allem unterhalb 32 Bit nicht mehr wirklich zurecht kommen, weil allein schon der verfügbare Adreßraum zu eng wird. Hier gibt es ne Menge Verbohrte, die partout versuchen, ein zu großes Display an einen zu kleinen Controller dranzubasteln - und sie kommen bestenfalls zu einem statischen Testbild. Heureka? von wegen. Jaja, ich hatte auch schon mal ein LSU07 (Pollin) an einen PIC16F871 drangebastelt und es geht prinzipiell - aber all sowas ist blanker Mutwillen. Und wenn man schon einen Teil seines Jobs mit 32 Bittern erledigt, dann ist es durchaus einzusehen, daß man für was Kleineres ebenfalls 32 Bitter benutzt und sich nicht noch mit einer zweiten oder dritten Familie befaßt - obwohl dies durchaus ginge. W.S.
>Dennoch beurteile ich, was >ich sehe und nicht, was in meine 'Religion' paßt :-) Ich beurteile auch, was ich sehe (und 'Religion' habe ich keine). Und ich sehe, dass der RX mit dem konkret vorhandenen (*) CISC-Befehlssatz all das kann, was auch CM3/4 kann, und mehr. Also ist schon deshalb RX-Code kompakter (R32C-Code wäre noch kompakter). Zudem hat RX weitere Vorteile, die man auch sehen kann. (gut, Verfügbarkeit zählt wohl eher nicht dazu). In der Industrie (ups, das sind ja mehr als 3 Leute) wird das genommen, was für den Preis am meisten bietet, das ist oft RX. (*)es gibt ein paar ganz wenige Ausnahmen hinsichtl. LD/SD-Adress.arten, aber die können nicht ausschlaggebend sein)
MCUA schrieb: > In der Industrie (ups, das sind ja mehr als 3 Leute) wird das genommen, > was für den Preis am meisten bietet, das ist oft RX. Diese "Industrie" hat in der Vergangenheit eben die falsche Entscheidung für RX etc. getroffen und ist nun so davon abhängig dass diese Renesas vor der Pleite retten musste: http://www.elektroniknet.de/automotive/sonstiges/artikel/91662/
W.S. schrieb: > Wer ein buntes TFT anschließen will, Ist es nicht so, daß ein buntes TFT zunehmend unwichtiger wird? Warum soll man sich in Zeiten der Tabletts und Smartphones noch die Mühe machen, damit den Aufwand aufzublähen, wenn sich doch allerorts billige Mobildisplays zur Ausgabe anbieten? W.S. schrieb: > Und wenn man schon einen Teil seines Jobs mit 32 Bittern erledigt, dann > ist es durchaus einzusehen, daß man für was Kleineres ebenfalls 32 > Bitter benutzt und sich nicht noch mit einer zweiten oder dritten > Familie befaßt Wie die Dinge noch einfacher umzusetzen sein könnten sollte man nicht aus den Augen verlieren ;-)
MCUA schrieb: > Zudem hat RX weitere Vorteile, die man auch sehen kann. (gut, > Verfügbarkeit zählt wohl eher nicht dazu). > In der Industrie (ups, das sind ja mehr als 3 Leute) wird das genommen, > was für den Preis am meisten bietet, das ist oft RX. Verfügbarkeit ist aber ein Killerkriterium in der Industrie. Standardisierung auch. Und deswegen gehen auch immer mehr Industriekunden in Richtung ARM. Renesas und Microchip sind wohl noch die einzigen große Hersteller, der nicht ARM-Kerne in breiter Masse einsetzt. Selbst Atmel trägt gerade seinen AVR mit großen Schritten ins Grabe. Die ganz neuen SAM D1x sind ganz klar als Ersatz der Attiny platziert. Würden das die Hersteller machen, wenn Cortex M nicht von der Industrie akzeptiert wären? Wohl kaum.
Antimedial schrieb: > Selbst Atmel trägt gerade seinen AVR mit großen Schritten ins > Grabe. Wunschdenken. Aber klar doch. Deshalb kommen auch laufend neue 8-Bitter auf den Markt.
Moby schrieb: > Wunschdenken. Aber klar doch. Deshalb kommen auch laufend neue 8-Bitter > auf den Markt. Produktpflege nennt man das. Industriekunden haben Produktlebenszyklen von 10 bis 25 Jahre. Da muss ein ernsthafter Hersteller auch mal überarbeitete Typen herausbringen. Meistens als verbesserte und billigere, aber pin- und binärkompatible Ersatztypen für vorhandene Typen. Du brauchst also keine Angst zu haben, dass du in 10 Jahren keinen deiner geliebten AVR mehr bekommst. Die Industrie wird bei Neuentwicklungen trotzdem immer stärker auf ARM setzen.
Moby schrieb: >> Wer ein buntes TFT anschließen will, > > Ist es nicht so, daß ein buntes TFT zunehmend unwichtiger wird? Genau. Probleme einfach wegdefinieren ;). Wozu ein TFT wenn es auch ein 2x16 Zeichen Display tut. > Warum soll man sich in Zeiten der Tabletts und Smartphones noch die Mühe > machen, damit den Aufwand aufzublähen, wenn sich doch allerorts billige > Mobildisplays zur Ausgabe anbieten? Wird ja auch gemacht. Blos wo bekommen die Mobilgeräte ihre Daten her um sie anzeigen zu können? Per USI von einem attiny? Oder doch eher von einem 32Bitter über LAN/Wifi?
An einem wichtigen Punkt kommt der ganze inszenierte 32Bit Hype nicht vorbei: Für die Mehrheit der Anwendungen reicht 8 Bit, und was denen nicht reicht findet ggf. auf irgendwelchen Servern statt. Die Ansprüche bei High-End Anwendungen steigen aber sprunghaft weiter. Deshalb ist der AVR (hoffentlich innovativ weiterentwickelt) auch in 20 Jahren noch auf dem Markt, wenn von den heutigen ARM/Cortexen keine Rede mehr sein wird. Antimedial schrieb: > Produktpflege nennt man das. Nö. Einsicht in die Notwendigkeit.
Stefan schrieb: > Probleme einfach wegdefinieren Nicht wegdefinieren sondern auf mobilen Displays als gelöst erachten... Die Übertragung? Natürlich drahtlos. Und komme mir jetzt niemand mit Video...
Moby schrieb: > An einem wichtigen Punkt kommt der ganze inszenierte 32Bit Hype nicht > vorbei: Für die Mehrheit der Anwendungen reicht 8 Bit, und was denen > nicht reicht findet ggf. auf irgendwelchen Servern statt. Das spielt doch keine Rolle. Wenn ich die gleiche Anwendung für weniger Geld und weniger Aufwand besser wartbar in einem ARM-Controller lösen könnte, ist das Argument "es geht doch auch auf einem 8-Bitter" ziemlich schwach. Moby schrieb: > Deshalb ist der > AVR (hoffentlich innovativ weiterentwickelt) auch in 20 Jahren noch auf > dem Markt, wenn von den heutigen ARM/Cortexen keine Rede mehr sein wird. Mit dieser Einschätzung liegst du daneben. Die Cortex M sind inzwischen so in der Industrie etabliert, dass es sie aufgrund der oben erwähnten Produktlebenszyklen auch in 20 Jahren noch geben wird. Das Anwendungsspektrum ist inzwischen bis ganz unten abgedeckt und nach oben wird es sicher demnächst mit einem M4-Nachfolger erweitert. Moby schrieb: > Nö. Einsicht in die Notwendigkeit. Notwendigkeit zur Produktpflege. Für Neuentwicklung gibt es keine Notwendigkeit. Die meisten Hersteller haben die Weiterentwicklung ihrer 8-Bit-Kerne schon längst eingestellt. Von Atmel hört man diesbezüglich auch nichts mehr. Moby schrieb: > Die Übertragung? Natürlich drahtlos. Das Internet der Dinge ist ein klassischer Anwendungsbereich von 32-Bit-Kernen. Mit AVR fängt da keiner ernsthaft an. Und um deinen Lieblingshersteller zu erwähnen: Im neuesten WLAN-Modul von Atmel steckt ein M0+.
Antimedial schrieb: > Im neuesten WLAN-Modul > von Atmel steckt ein M0+. Der kann da gern bleiben. Aber das wird von mir trotzdem mit 8-Bit gesteuert... Antimedial schrieb: > Das Internet der Dinge ist ein klassischer Anwendungsbereich von > 32-Bit-Kernen. Mit AVR fängt da keiner ernsthaft an. Genau dafür langt 8-Bit dicke. Antimedial schrieb: > Die meisten Hersteller haben die Weiterentwicklung ihrer > 8-Bit-Kerne schon längst eingestellt. Von Atmel hört man diesbezüglich > auch nichts mehr. Hundertmal wiederholt machts nicht wahrer... Antimedial schrieb: > Die Cortex M sind inzwischen > so in der Industrie etabliert, dass es sie aufgrund der oben erwähnten > Produktlebenszyklen auch in 20 Jahren noch geben wird Ich hoffe es für Dich ;-) Antimedial schrieb: > Das spielt doch keine Rolle. Doch, tut es. Antimedial schrieb: > Wenn ich die gleiche Anwendung für weniger > Geld und weniger Aufwand besser wartbar in einem ARM-Controller lösen > könnte, Wenn, ja wenn, dann könnte... Chris D. schrieb: > Wir haben bspw. alles von AVR auf STM32 umgestellt, eben weil wir nur > eine Architektur pflegen und beherrschen müssen, Das leuchtet ein.
Moby schrieb: > Der kann da gern bleiben. Aber das wird von mir trotzdem mit 8-Bit > gesteuert... Die Hauptarbeit erledigt aber der Cortex. Moby schrieb: > Genau dafür langt 8-Bit dicke. Vielleicht. Vielleicht auch nicht. Ein Cortex geht immer. Und ist billiger und einfacher. Moby schrieb: > Hundertmal wiederholt machts nicht wahrer... Dann bring doch mal Gegenbeweise. Übrigens: Ein paar neue Devices pro Jahr heißt noch lange nicht, dass der Kern weiter entwickelt wird. Moby schrieb: > Ich hoffe es für Dich ;-) Wieso? Ich hänge nicht so emotional an einem Prozessorkern. Du offensichtlich schon. Moby schrieb: > Wenn, ja wenn, dann könnte... Tippfehler. Heißt natürlich kann. Habe ich ja schon oft gemacht. Das letzte Produkt hat insgesamt 4 ARM-Kerne und wird in 1000er Stückzahlen gebaut.
Antimedial schrieb: > Die Hauptarbeit erledigt aber der Cortex. Das ist auch ein wichtiger Trend: Wirklich leistungsfordernde Anwendungen als Modul zu kapseln. Ob in einem Display oder WLAN-Modul. Die Ansteuerung über einfache Schnittstellen dann aber wie gehabt in 8-Bit. Ich hab da z.B. ein RN171 von Roving Networks und mehrere XPorts fürs LAN in Verwendung. Antimedial schrieb: > Vielleicht. Vielleicht auch nicht. Sicher! Solange keine wirklichen Datenmassen erhoben werden- aber das ist bei den meisten Datenzulieferern fürs IoT ohnehin nicht der Fall. Antimedial schrieb: > Dann bring doch mal Gegenbeweise. Übrigens: Ein paar neue Devices pro > Jahr heißt noch lange nicht, dass der Kern weiter entwickelt wird. Letze Kernänderung war erst der XMega. Im übrigen, wer sagt denn, daß der Kern fortlaufend geändert gehört? Was erfolgreich etabliert ist und die Anforderungen der 8-Bit Welt erfüllt kann, sollte, muß so bleiben. Was nicht heißt daß alle Wünsche erfüllt sind...
>Diese "Industrie" hat in der Vergangenheit eben die falsche Entscheidung >für RX etc. getroffen...... Stimmt so nicht. Das hat mehrere Bereiche betroffen, ua auch weg. Erdbeben. RX sind ja nur ein Produkt-Bereich von Renesas. (ausserdem hat auch ST Verluste eingefahren) >Verfügbarkeit ist aber ein Killerkriterium in der Industrie. Da ist's kein Problem.
Antimedial schrieb: > Moby schrieb: >> Genau dafür langt 8-Bit dicke. > > Vielleicht. Vielleicht auch nicht. Ein Cortex geht immer. Und ist > billiger und einfacher. Hört doch auf euch selbst zu belügen. Der einzige Grund warum ST 8bitter auf den Markt gebracht hat IST der Preis.
Moby schrieb: > Das ist auch ein wichtiger Trend: Wirklich leistungsfordernde > Anwendungen als Modul zu kapseln. Ob in einem Display oder WLAN-Modul. Allein deshalb haben aber die Cortex schon eine höhere Verbreitung, wenn der 8-Bitter allenfalls als Coprozessor taugt. Moby schrieb: > Sicher! Solange keine wirklichen Datenmassen erhoben werden- aber das > ist bei den meisten Datenzulieferern fürs IoT ohnehin nicht der Fall. Eine vernünftige DMA braucht es aber schon. Die gibt es bei manchen 8-Bit-Controllern, bei Cortex sind sie aber Standard. Moby schrieb: > Letze Kernänderung war erst der XMega. Der XMega ist schon uralt. Moby schrieb: > Im übrigen, wer sagt denn, daß > der Kern fortlaufend geändert gehört? Muss nicht sein. Mein Argument war, dass die Weiterentwicklung des AVR eingestellt ist und Neuentwicklungen nur noch mit ARM-Kernen erfolgt. Und das hast du ja gerade nur bestätigt.
avr schrieb: > Hört doch auf euch selbst zu belügen. Der einzige Grund warum ST 8bitter > auf den Markt gebracht hat IST der Preis. Richtig. Und wann wurden sie auf dem Markt gebracht? Vor 20 Jahren. Da hat es ja noch gestimmt. Heute nicht mehr. Beachte: Billiger heißt im Hinblick auf Gesamtkosten, nicht nur der reine Bauteilpreis (obwohl der allein ja im Moment schon von 8-Bittern nicht mehr schlagbar ist).
Antimedial schrieb: > Im neuesten WLAN-Modul > von Atmel steckt ein M0+. Wobei mich da auch mal interessieren würde wieviel Leistung durch ineffiziente Hochsprachenprogrammierung verbraten wird ;-)
Antimedial schrieb: > dass die Weiterentwicklung des AVR > eingestellt ist Ach was. Neue AVRs kommen auch in Zukunft. Der bestehende Kern langt erstmal und ganz einfach für die meisten Belange! Du definierst offensichtlich fehlende Veränderung als Rückschritt... Dann schlag Dich mal weiter mit der Wartbarkeit Deines Codes rum ;-) Antimedial schrieb: > Der XMega ist schon uralt. Unsinn. Und DMA ist auch schon drin...
Moby schrieb: > Wobei mich da auch mal interessieren würde wieviel Leistung durch > ineffiziente Hochsprachenprogrammierung verbraten wird ;-) Deinen TCP/IP-Stack in Assembler will ich mal sehen. Moby schrieb: > Ach was. Neue AVRs kommen auch in Zukunft. Der bestehende Kern langt > erstmal und ganz einfach für die meisten Belange! Deine Belange != die meisten Belange. Moby schrieb: > Unsinn. Und DMA ist auch schon drin... Ich habe vor 6 Jahren schon mit XMEGA gearbeitet. Ja, DMA haben manche Typen, sind dafür auch extrem teuer. Einen 30-Cent-XMEGA mit DMA habe ich jedenfalls noch nicht gesehen.
Ach, übrigens, weil wir es vom WLAN-Modul schon hatten. Das kann man wohl auch mit eigener Software bespielen. Dein 8-Bit-Coprozessor wird also völlig überflüssig, weil das bisschen Datenschaufeln gleich vom Modul mit erledigt wird.
Antimedial schrieb: > Vor 20 Jahren. Da > hat es ja noch gestimmt. Heute nicht mehr. Klar. Du willst mir erzählen, dass es die STM8 Controller schon vor 20 Jahren gab... Antimedial schrieb: > Billiger heißt im Hinblick auf Gesamtkosten Richtig. Und in Stückzahlen kostet ein wenig Softwareaufwand (sofern er existiert) nur einmal. Wenn man mit Peripherie Bibliotheken programmiert gibt es zwischen 8bit und 32bit beim gleichen Hersteller auch keinen nennenswerten Unterschied mehr.
Antimedial schrieb: > Deine Belange != die meisten Belange. Tatsächlich? Oder wird Antimedial schon wieder ärgerlich? Antimedial schrieb: > Ja, DMA haben manche > Typen, sind dafür auch extrem teuer. Einen 30-Cent-XMEGA mit DMA habe > ich jedenfalls noch nicht gesehen. Die einen machst Du zu teuer, die anderen zu billig. Immer diese Übertreibungen!
Antimedial schrieb: > Einen 30-Cent-XMEGA mit DMA habe > ich jedenfalls noch nicht gesehen. Der Xmega spielt in einer anderen Liga. Er ist KEIN Ultra-Low-Cost µC. Er hat auch eine deutlich bessere Ausstattung als die µCs, die 30cent kosten. Zeig mir doch einen vergleichbaren Controller zur Xmega E Serie. Soviel Peripherie bekommt man für den Preis anderswo einfach nicht.
Antimedial schrieb: > Dein 8-Bit-Coprozessor wird > also völlig überflüssig, weil das bisschen Datenschaufeln gleich vom > Modul mit erledigt wird. Mein simpel programmierbarer 8-Bit MC spielt die erste Geige. Die laß ich mir doch nicht mit Deinen komplexen 32Bit Monstern ersetzen!
avr schrieb: > Klar. Du willst mir erzählen, dass es die STM8 Controller schon vor 20 > Jahren gab... So etwas in dem Dreh. Vielleicht auch nur 15. Sie stammen jedenfalls noch aus einer Ära, in der 8 Bit noch Stand der Technik war. avr schrieb: > Richtig. Und in Stückzahlen kostet ein wenig Softwareaufwand (sofern er > existiert) nur einmal. Wenn man mit Peripherie Bibliotheken programmiert > gibt es zwischen 8bit und 32bit beim gleichen Hersteller auch keinen > nennenswerten Unterschied mehr. Das kommt auf den Hersteller an. Atmel ist da wenig konsequent, auch in den ARM-Serien gibt es da starke Unterschiede. Bei ST geht es schon eher. Die Verwendung der gleichen Toolchain spart auch Kosten. Da ist es nur sinnvoll, in der gleichen Familie zu bleiben. Und das heißt M0 für kleine Projekte, M3 und M4 für größere. Die Frage ist auch, was man unter Stückzahlen versteht. In Deutschland eher 5-6 stellige Stückzahlen, da lohnt sich eine Optimierung auf den letzten Cent oft nicht. Ausnahme ist Automotive. Dort sind die Anforderungen aber inzwischen eh so hoch, dass man an 32 Bit kaum noch vorbei kommt. Moby schrieb: > Tatsächlich? Oder wird Antimedial schon wieder ärgerlich? Ja, tatsächlich. Die Welt dreht sich anders als du denkst. Moby schrieb: > Die einen machst Du zu teuer, die anderen zu billig. > Immer diese Übertreibungen! Nein. Ein STM32F0 kriegst du für 30-40 Cent in Stückzahlen. Selbst über den Distributor kann man in 4-Stelligen Stückzahlen schon weit unter 50 Cent kommen. Die kleinsten XMEGA kommen vielleicht gerade so annähernd in den Bereich, dann haben sie aber noch keine DMA und viel weniger Speicher.
avr schrieb: > Der Xmega spielt in einer anderen Liga. Er ist KEIN Ultra-Low-Cost µC. > Er hat auch eine deutlich bessere Ausstattung als die µCs, die 30cent > kosten. Zeig mir doch einen vergleichbaren Controller zur Xmega E Serie. > Soviel Peripherie bekommt man für den Preis anderswo einfach nicht. STM32F030C6T6 zum Beispiel. Deutlich mehr Peripherie, mehr Speicher und einiges günstiger. Moby schrieb: > Mein simpel programmierbarer 8-Bit MC spielt die erste Geige. Die laß > ich mir doch nicht mit Deinen komplexen 32Bit Monstern ersetzen! In der Industrie fliegt der aber raus, weil unnötig und nur Kostentreiber.
Antimedial schrieb: > Die kleinsten XMEGA kommen vielleicht gerade so annähernd > in den Bereich, dann haben sie aber noch keine DMA Die Xmega haben alle DMA. Antimedial schrieb: > Die Welt dreht sich anders als du denkst. Und ich glaube, Du drehst sie wie's Dir gerade passt ;-) Preise sind nicht unwichtig aber entscheiden auch nicht alles. Populäres war schon immer teurer.
Moby schrieb: > Die Xmega haben alle DMA. Gut, meinetwegen. Dafür ist die restliche Peripherie sehr mager. Moby schrieb: > Und ich glaube, Du drehst sie wie's Dir gerade passt ;-) Was nur zeigt, wie sehr du in deiner eigenen Welt gefangen bist. Moby schrieb: > Populäres war schon immer teurer. Das ist ein guter Witz. Es geht um Controller und nicht um iPhones. In der Industrie gibt es keine Fanboys, sondern Profis.
Antimedial schrieb: > Gut, meinetwegen. Danke. Wie großzügig. Antimedial schrieb: > Dafür ist die restliche Peripherie sehr mager. Z.B. bis zu 8 UARTS langen doch sicher? Die brauch ich besonders. Antimedial schrieb: > Was nur zeigt, wie sehr du in deiner eigenen Welt gefangen bist. Und Du in Deiner. In der entscheiden nur Preise... Antimedial schrieb: > Das ist ein guter Witz. Das ist Fakt. Deshalb kann Atmel auch etwas mehr nehmen, auch wenns nicht in Deinen Kopf passt ;-)
MCUA schrieb: >>Diese "Industrie" hat in der Vergangenheit eben die falsche Entscheidung >>für RX etc. getroffen...... > Stimmt so nicht. Das hat mehrere Bereiche betroffen, ua auch weg. > Erdbeben. > RX sind ja nur ein Produkt-Bereich von Renesas. Renesas hat einfach zu viele geerbte inkompatible uC/uP Familien im Programm das kann nicht profitabel sein. Und mit Erdbeben hatte dieser Verlust nichts zu tun. MCUA schrieb: > (ausserdem hat auch ST Verluste eingefahren) Stimmt daher haben wir NXP (erst 8051 und jetzt ARM).
Antimedial schrieb: > ... In > der Industrie gibt es keine Fanboys, sondern Profis. Klar, besonders auch hinsichtlich der Programmiersprache C.
Technodiskussion in Reinkultur, langweilig und für mich eher naiv. In reifen Märkten sind Alleinstellungsmerkmale sehr selten. Die Diskussion um Prozessor X oder Y ist meist müßig, Unterschiede sind mit der Lupe zu suchen. Ein (aber nur ein) Kriterium ist der wirtschaftliche Erfolg. Was nützt die (gefühlt) geilste Technologie wenn der Laden ständig am Rande der Pleite segelt? Hier mal ein paar Auszüge wie ich das über 10 Jahre Rückwärts bewerten würde. Finanzdaten Atmel. http://www.onvista.de/aktien/fundamental/ATMEL-CORP-Aktie-US0495131049 Hohe Verluste früher, hohe Gewinne heute, zahlt keine Dividende, die Aktie lebt also von der Hoffnung und ist volatil (400% Schwankung über 10 Jahre). Microchip: http://www.onvista.de/aktien/fundamental/Microchip-Technology-Aktie-US5950171042 Finanziell kerngesund, stabil und mit weniger schwankendem Kurs (100%/10 Jahre) stabile Dividende. Renesas: http://www.finanzen.net/aktien/Renesas_Electronics_1-Aktie Der Chart zeigt nur eines Finger weg. ST: http://www.onvista.de/aktien/STMICROELECTRONICS-N-V-Aktie-US8610121027 Kurs hat sich halbiert, aber http://www.onvista.de/aktien/fundamental/STMICROELECTRONICS-N-V-Aktie-US8610121027 stabiler Dividendenzahler hohe Gewinnerwartung. (übrigens mit einer Rendite von der jede Lebensversicherung heutzutage nur träumen kann. Das bei täglicher Kündigungsfrist - statt min 12 Jahre wg eingebildeter Steuerfreiheit -)
Antimedial schrieb: > Gut, meinetwegen. Dafür ist die restliche Peripherie sehr mager. Die Peripherie ist bei den Xmegas eher das Herausragende Merkmal. Bspw. E-Serie, die es in kleinen Stückzahlen schon unter einem Euro gib: 16x PWM (12x 128Mhz PWM) Deadtime Genator 8x Input Capture 2x 12bit DAC 16x 12bit diff. ADC 2x Analog Comp. 2x USART/SPI 1x SPI, I2C Temp. Sensor 2x LUT EEPROM, DMA, CRC, RTC Eventsystem
Moby schrieb: > Stefan schrieb: >> Probleme einfach wegdefinieren > > Nicht wegdefinieren sondern auf mobilen Displays als gelöst erachten... > Die Übertragung? Natürlich drahtlos. Und komme mir jetzt niemand mit > Video... Na, da würden sich unsere Kunden aus der Industrie aber so richtig freuen. Echtzeit und hochverfügbar? Na klar - zumindest solange, wie die Funkverbindung da oder das Android nicht mal wieder abgeschmiert ist. So etwas dürfte ich vermutlich nicht mal als schlechten Witz bei der Produktvorstellung bringen :-} Und warum kein Video? Selbstverständlich muss es in der Prozessüberwachung möglich sein, Echtzeitbilddaten vom Ort des Geschehens (Reaktor usw.) auf den Schirm zu holen. Tablet- und Smartphoneanbindung ist maximal eine Zugabe, aber keine ernsthafte Alternative zu einem direkt angesteuerten Screen. Na klar reicht für die meisten Anwendungen 8 Bit - das bestreite ich nicht. Aber: mit dem immer geringer werdenden preislichen Abstand zwischen 8 und 32 Bit treten halt wie bei uns Wartbarkeit (nur eine Prozessorfamilie für alle Fälle) und Verwendbarkeit des Codes in den Vordergrund. Die Stückzahl, ab der sich die explizite 8-Bit-Entwicklung außerhalb des Standards (ARM) lohnt, wird einfach von Jahr zu Jahr geringer. 8-Bitter werden nicht verschwinden, aber die Stückzahlen werden weiter zurückgehen. Bastlern kann das aber sowieso egal sein - AVRs wird es sicher noch einige Zeit geben :-)
Chris D. schrieb: > Tablet- und Smartphoneanbindung ist maximal eine Zugabe, aber keine > ernsthafte Alternative zu einem direkt angesteuerten Screen. Das wird schon noch, abwarten. Die Entwicklung geht in die Richtung, das direkt angebundene Display WIRD unwichtiger. Oder aber intelligenter- eine Richtung in die eDip & co. zeigt (hab so eins über Funk angebunden- zwar nur statische Grafiken, aber funktioniert so seit Jahren). Chris D. schrieb: > Selbstverständlich muss es in der > Prozessüberwachung möglich sein, Echtzeitbilddaten vom Ort des > Geschehens (Reaktor usw.) auf den Schirm zu holen. Klar gibts auch solche Anwendungen. Und da sind doch meist sowieso FPGAs am Werke. Spezialisierte Hardware also. Chris D. schrieb: > 8-Bitter werden nicht verschwinden, aber die Stückzahlen werden weiter > zurückgehen. Nun ja, das heißt es seit Jahren von 8051ern und RS232-Schnittstellen auch. Conrad/Reichelt haben ja selbst den Z80 noch... 2014!!! Mann o Mann.
Moby schrieb: > Chris D. schrieb: >> Selbstverständlich muss es in der >> Prozessüberwachung möglich sein, Echtzeitbilddaten vom Ort des >> Geschehens (Reaktor usw.) auf den Schirm zu holen. > > Klar gibts auch solche Anwendungen. Und da sind doch meist sowieso FPGAs > am Werke. Spezialisierte Hardware also. Nö, da setzen wir ganz normale Cortexe ein (STM32). Der Vorteil ist ja gerade, dass man diese enrome Bandbreite an Leistung zur Verfügung hat. Und bei Displayansteuerung ist 8-Bit eben einfach raus. > Chris D. schrieb: >> 8-Bitter werden nicht verschwinden, aber die Stückzahlen werden weiter >> zurückgehen. > > Nun ja, das heißt es seit Jahren von 8051ern und RS232-Schnittstellen > auch. > Conrad/Reichelt haben ja selbst den Z80 noch... 2014!!! Mann o Mann. Genau das sage ich doch. Was ist an "8-Bitter werden nicht verschwinden, aber die Stückzahlen werden weiter zurückgehen" denn unverständlich. Schau Dir einfach die aktuellen Stückzahlen von 8-Bittern und 32-Bittern an.
Der Markt teilt sich allenfalls neu auf. Kommt was hinzu, wird der Marktanteil fürs Bestehende kleiner. Manches verschwindet durch das Neue auch, weil die Neuerscheinung in allen Belangen besser ist. Aber nicht so bei AVR/PIC 8-Bit- da kann kommen was will ;-)
W.S. schrieb: > aber allein die Verfügbarkeit von Tools, die auch ein privater > Bastler einfach herunterladen und benutzen kann, ist ein Argument, was > ein ziemliches Gewicht hat Da möchte ich Dich gerne auf KPIT verweisen: GCC-Basis, kostenlos und sehr guter Code. Dies nur nebenbei zu Deiner Information. Wenn Du ein RX-Demoboard angeworfen hättest, würdest Du mit Deinen LPCs mehr ins Grübeln kommen :-) @MCUA Nenn mir doch bitte einen 'ordentlichen' Distributor.
m.n. schrieb: > Da möchte ich Dich gerne auf KPIT verweisen: Besten Dank, ich sehe mir das mal an. Moby schrieb: > Ist es nicht so, daß ein buntes TFT zunehmend unwichtiger wird? Hast du jemals wirklich Investgüter entwickelt? Ich hab da meine leisen Zweifel, daß du weißt, wovon du so fröhlich daher redest. Antimedial schrieb: > Wieso? Ich hänge nicht so emotional an einem Prozessorkern. Die meisten anderen Leute jedoch sehr wohl - wenngleich ein ernsthafter Entwickler sich in seinen strategischen Entscheidungen nicht davon (ver)leiten läßt. Moby schrieb: > Wobei mich da auch mal interessieren würde wieviel Leistung durch > ineffiziente Hochsprachenprogrammierung verbraten wird ;-) Mein Tip: heutzutage bereits extrem viel, Tendenz steigend. Man schaue sich nur mal hier in diesem Forum um. ------------ Ganz generell: Ich sehe sehr deutlich, daß die Cortexe bereits einige andere Architekturen plattgemacht haben und dies wird sich auch in der nächsten Zukunft weiter fortsetzen. Ganz egal, ob das eine oder andere Projekt auch mit einer kleineren oder älteren oder exotischeren Architektur ebenso realisierbar gewesen wäre. Der Zug geht also in Richtung Monokultur ab. Das ist so, obwohl es mir im Innersten ein Unbehagen verursacht, denn Monokulturen ware schon immer schlecht - obwohl sie in den Anfangsjahren die höchsten Erträge bringen. Jetzt und hier mit Zähnen und Klauen irgendeine ältere Architektur verteidigen zu wollen, wie es der Moby tut, ist nicht sinnvoll. Die Leute werden mit den Füßen abstimmen. Das Einzige, was da ein bremsendes Element ist, ist der Zustand in den Köpfen der künftigen Entwickler: Je dümmer sie werden, desto weniger werden sie geneigt sein, die immer umfänglicher werdenden Manuals selber durchzuackern, desto weniger werden sie in der Lage sein, die modernere Hardware überhaupt zu verstehen und desto eher werden sie sich nach ner simpleren Hardware sehnen, die ihrem Horizont entspricht - alternativ werden sie sich mach einer vom Hersteller gelieferten HAL sehnen, die ihnen das Sich Befassen mit der Hardware einfach abnimmt. So. Insgesamt sehe ich nicht wirklich hoffnungsfroh in die Zukunft. W.S.
W.S. schrieb: > irgendeine ältere Architektur > verteidigen zu wollen, wie es der Moby tut Nein, der Moby will keine ältere Architektur verteidigen sondern die einfachere, die für viele Problemstellungen (mehr als) ausreichende. Auch nicht "mit Zähnen und Klauen", sondern in der Überzeugung, daß die einfachere Lösung sich letztlich doch immer als die schnellere, billigere, robustere und die mit dem geringstem Aufwand erweisen wird. Gern wird das Alter einer Architektur als abwertendes Argument bemüht und seit längerem verfügbare, optimierte und ausgereifte MCs vorschnell und unberechtigt als veraltet disqualifiziert. Ich glaube, für jede Problemstellung gibt es ganz zeitlos eine optimale Lösung- und die ist für Millionen Anwendungen bis auf weiteres 8-bittig. Sehr wohl muß man aber natürlich die Mechanismen in der Industrie sehen: Hinsichtlich des Wettbewerbs über den Preis- als auch hinsichtlich ganz pragmatischer Erwägungen, wenn z.B. im High-End Bereich schon überall 32bittig gearbeitet wird man sich auch Low-End zweckmäßigerweise auf die gleiche Produktlinie beschränkt. Aber soll das letztlich der Hebel sein, mit fortlaufend komplizierteren Produkten zu arbeiten, immer "umfänglicher werdende Manuals ... durchzuackern" ? Nein. Wenn das nicht gleichzeitig von einer revolutionären Vereinfachung der Programmierung begleitet wird (die sich ja gerne der steigenden Leistungsfähigkeit der Chips bedienen mag), dann werden es 32- und Höherbittige niemals schaffen, sich über das Bedürfnis des Einsteigers und Otto Normalo Anwenders nach einfacher Verwendbarkeit technischer Produkte (wie es eben ein AVR bietet) hinwegzusetzen. Mancher Profi unterschätzt auch eines: Langjährig gelernt wird vieles einfacher- aber gerade wenn die Einstiegshürden immer höher würden ist keinem geholfen, langfristig auch und gerade der Industrie nicht. Und speziell was die Beurteilung von Einfachheit und intuitiver Benutzbarkeit anbetrifft gilt: Da ist der Einsteiger Profi, der Profi nur Laie!
Ich finde einfach die Verbissenheit lächerlich mit der hier persönliche Vorlieben und Zielsetzungen zur unumstößlichen Wahrheit überhöht werden. Persönliche Beleidigungen und pupertärer Schwanzlängenvergleich statt sachlicher Diskussion über individuelle Vor- UND Nachteile bei genau definierten Rahmenbedingungen. Sehr unterhaltsam aber oft auch sehr unwürdig. Ein Füllhorn für psychologische Feldstudien.
Moby schrieb: > Gern wird das Alter einer Architektur als abwertendes Argument bemüht > und seit längerem verfügbare, optimierte und ausgereifte MCs vorschnell > und unberechtigt als veraltet disqualifiziert. ARM (1986) ist 8 Jahre älter als AVR (1994) und trotzdem besser und einfacher :-)
Ich mach das jetzt so. Habe mir gestern bei Watterott einen RasPi B+ abgeholt. Vorhin angetestet, ja, löppt ganz nett. Davon nehme ich jetzt 7 für je eine Diode und einen Achten als Master an eigenem Switch, um einen Würfel/Zufallsgenerator zu bauen. Ich rätsele noch, wie ich Bluetooth dazunehme - vielleicht den Switch ersetzen. Aber Bluetooth ist auch wichtig.
Dirk K. schrieb: > RasPi B+ Auch wenn Dein Beitrag ironisch gemeint war :-) Der RasPi B+ ist billiger als die meisten uC Boards und die GPIO/SPI/I2C können unter RISCOS in BASIC/Assembler extrem einfach programmiert werden (also BASCOM-mäßig wer es mag). Zudem kann man Single-Task laufen lassen, damit werden unter RISCOS GPIO 20 MHz erreicht (unter Linux eher 20 kHz). Zudem ist der ARM-Assembler für die uC M0/M3 und den ARM11 im RasPi praktisch gleich (wer Assembler mag).
W.S. schrieb: > m.n. schrieb: >> Da möchte ich Dich gerne auf KPIT verweisen: > > Besten Dank, ich sehe mir das mal an. In der Regel werden die KPIT-Compiler in die HEW eingebunden. Bei mir ist es die frei verfügbare Version 4.09, die auf 64K limitiert ist. KPIT ist nicht limitiert und erzeugt sogar kürzeren Code. Beim Debuggen ist seit eh und je ein 'Instant Watch' möglich, mit dem man Variablen des laufenden Programmes anzeigen lassen kann: sehr angenehm. Die freien ARM-IDEs kennen nur 'watch', wenn der Prozessor steht. Auch die Peripherie dürfte Dir wegen der guten Strukturierung gefallen. Kein CMSIS-Gewurschtel, sondern direkter Zugriff bis auf Bits der IO-Register. Keine blöden 'Schiebereien', weil Bits diverser Kanäle in ein 32-Bit Register gepreßt wurden. Beispiel: EXDMAC0.EDMDR.BIT.DTE = 1; // starte transfer Kanal0 Oder für DMA-Kanal1 EXDMAC1.EDMDR.BIT.DTE = 1; // starte transfer Kanal1 Ein Blick ins Datenblatt (Hardware Manual) zeigt das Innenleben der RXe übersichtlich und detailliert. Nicht, dass ich Dich von NXP abbringen möchte, aber ein Blick zur Seite ist nie verkehrt. Bei den Cortex ist die SWD-Schnittstelle sehr angnehm, da nur wenige Leitungen notwendig sind. Ab RX63 (oder RX200) gibt es das FINE-Interface, das auch mit deutlich weniger Leitungen auskommt.
m.n. schrieb: > In der Regel werden die KPIT-Compiler in die HEW eingebunden. Bei mir > ist es die frei verfügbare Version 4.09, die auf 64K limitiert ist. Der freie NXP LPCXpresso Compiler hat 256k Limit. m.n. schrieb: > direkter Zugriff bis auf Bits der > IO-Register. Keine blöden 'Schiebereien', weil Bits diverser Kanäle in > ein 32-Bit Register gepreßt wurden. Das ist bei NXP ARM auch nicht erforderlich weil Bitbanding implementiert wurde: http://www.mikrocontroller.net/articles/ARM_Bitbanding
Dirk K. schrieb: > Ich rätsele noch, wie ich > Bluetooth dazunehme - vielleicht den Switch ersetzen. Aber Bluetooth ist > auch wichtig. http://www.youtube.com/watch?v=BakaFvUWiiI
@Lothar Mein Beitrag hatte sich an W.S. gerichtet, der sicherlich weiß, was ein LPC kann und was nicht und worauf er achtet, wenn er einen Vergleich anstellt. Die unsinnige Diskussion 'Wer ist der Schönste im ganzen Land' interessiert mich nicht.
Maze schrieb: > Im Grunde wirkliche Mini.Schaltungen, die in der Regel mit 1 oder 2 ADC > und einem bis 7 Pinouts auskommen. Ich würde an dieser Stelle Zuses Z Reihe in den Raum werfen. Ausgereifte Architektur, und dafür leistungsfähig genug. Ok, nicht alle haben einen integrierten A/D Wandler. http://de.wikipedia.org/wiki/Konrad_Zuse
>> direkter Zugriff bis auf Bits der >> IO-Register. Keine blöden 'Schiebereien', weil Bits diverser Kanäle in >> ein 32-Bit Register gepreßt wurden. >Das ist bei NXP ARM auch nicht erforderlich weil Bitbanding >implementiert wurde: Blödsinn. Das hat nichts mit Bitbanding zu tun. RX kann u.a. 16-bit-dsp-werte oder bis zu 32bit imm-werte im OPcode (max 8 Bytes) unterbringen. Such das mal bei ARM.
MCUA schrieb: > RX kann u.a. 16-bit-dsp-werte oder bis zu 32bit imm-werte im OPcode (max > 8 Bytes) unterbringen. Wie kann der RX 32-bit immediate im OPcode unterbringen, hat der 64-bit Opcodes? In jedem Fall sollte das dann 2 Zyklen dauern. Der ARM hat 32-bit Opcodes und 16-bit Opcodes (wegen der Codedichte). Für das Laden eines 32-bit immediate braucht man also 2 Opcodes (bzw. 2 Zyklen): MOVW R0, #0x1234 ; low-halfword MOVT R0, #0x8765 ; high-halfword Ich gebe zu das mit den 16-bit-dsp-werten verstehe ich nicht. Kannst Du mal ein RX-Codebeipiel dazu zeigen für was man das braucht (mit Kommentar)?
>hat der 64-bit Opcodes? ja, sagte ich doch oben. >OPcode (max 8 Bytes) also CISC. >Ich gebe zu das mit den 16-bit-dsp-werten verstehe ich nicht. dsp = displacement, steht im Datenblatt.
Ich zeige mal ein kurzes Code-Beispiel vom RX210. Man beachte das RTS :-)
Michael Knoelke schrieb: > Ich finde einfach die Verbissenheit lächerlich mit der hier > persönliche Vorlieben und Zielsetzungen zur unumstößlichen Wahrheit > überhöht werden. Weder verbissen noch Vorliebe. Ganz simpel Tatsache. Aber mit dem Vereinfachen bzw. Einfachhalten fremdeln viele Profis hier und bleiben lieber in ihrem Universum funkelnder Monstersterne. Aber Achtung, die leben nicht so lange... :-) > pupertärer Schwanzlängenvergleich Ganz großes Thema hier! > sachlicher Diskussion über individuelle Vor- UND Nachteile bei genau > definierten Rahmenbedingungen. Tja das Problem ist, daß die "Rahmenbedingungen" zu oft schlicht schwamming und nicht genau definierbar sind. Offenkundig ist nur eines: was weniger komplex ist. > Ein Füllhorn für psychologische Feldstudien ... ist jedes Forum. Der Unterhaltungsfaktor gehört auch dazu!
Moby schrieb: > Ganz simpel Tatsache. Ich bin nicht rechthaberisch. Ich HABE Recht .... Es wäre mal eine gute Sache eine gigantische Liste aus allen nur möglichen Kriterien zu erstellen die bei der Wahl des 'richtige' Rechenknechts eine Rolle spielen könnten. Geld, Zeit, Lust, Befähigung, vorhandenes Wissen und / oder Inventar, persönliche Quellen, zukunftsfähgkeit etc. pp. bis hin zum allerletzen absurdesten Argument. Das können wir dann alle drei mal die Woche in jedem 'bessere MCU' Thread durchkauen und mit einem abgestimmten Scoring eine Kennzahl erstellen. Bis dahin ist das alles nur heiße Luft und jede Meinung hängt im luftleeren Raum weil es gar keine Kriterien gibt das 'besser' zu bestimmen. Persönliche Unterstellungen über den Geisteszustand der andersdenkenden finde ich befremdlich. Wir solten alle sozialisiert genug sein um eigenes Verhalten zu hinterfragen und fremdes akzepteren zu können ohne gleich bockig mit dem Fuß aufzustammpfen.
Jetzt sei nicht immer so tolerant. Religion braucht Missionierungseifer. Und da es keine sachliche Ebene gibt, muss man sich eben gegenseitig den Schädel einschlagen und auf seine eigene Position beharren. Wäre ja noch schöner, fremden Argumenten gegenüber aufgeschlosssne zu sein.
Michael Knoelke schrieb: > weil es gar keine Kriterien gibt das 'besser' zu > bestimmen. Aber das architektonische 'Einfacher' ;-) Michael Knoelke schrieb: > Bis dahin ist das alles nur heiße Luft und jede Meinung hängt im > luftleeren Raum Ohne Praxiserfahrung schon- mit 'hängt' da nix Michael Knoelke schrieb: > ohne gleich bockig mit dem > Fuß aufzustammpfen Soll wohl heißen: Widerstand zu Profi's Meinung wird nicht geduldet. Leider sitzt mancher auf recht hohem Roß- wenn dieser schon nicht runterzuholen ist soll wenigstens weiter die Erde erzittern ;-)
Moby schrieb: > Michael Knoelke schrieb: >> Bis dahin ist das alles nur heiße Luft und jede Meinung hängt im >> luftleeren Raum > > Ohne Praxiserfahrung schon- mit 'hängt' da nix Das heißt, das Deine Erfahrung die Summe aller möglichen Erfahrungen ist? Interessante Wahrnehmung. Moby schrieb: > Leider sitzt mancher auf recht hohem Roß Ja, leider.
Dirk K. schrieb: > fremden Argumenten Blasphemie ! Werft den Purschen zu Poden ! Ich hab für solche Fälle immer einen mobilen Scheiterhaufen in der Tasche. Alles bekloppte hier. Wenigstens ich bin normal.
Michael Knoelke schrieb: > Das heißt, das Deine Erfahrung die Summe aller möglichen Erfahrungen > ist? SimplyAVR. Das ist für viele Projekte "die Summe aller möglichen Erfahrungen". Michael Knoelke schrieb: > Wenigstens ich bin normal. Na wenigstens einer.
Moby schrieb: > SimplyAVR. Das ist für viele Projekte "die Summe aller möglichen > Erfahrungen". Na, dann habe ich ja fast alles falsch gemacht im Leben. Danke das Du mir die Augen geöffnet hast. Der AVR ONE darf bleiben. Ist XMEGA ok, oder ist das auch Teufelswerk ? MPlab2, PICkit3, STM8Sdiscovery, Galep, FLIP, Silabs Programmer und alle anderen werde ich heute noch entsorgen. Mein aktuelles Projekt werde ich zu Grabe tragen. Wenn Atmel gewollt hätte das es Noise und Echo Canceling gibt hätten sie leistungsfähige DSP AVRs gebaut.
Ich hoffe dass nicht allzuviele Entwickler im deutschsprachigen Raum so denken wie Moby. Das ist ja schon fast fahrlässig! Ich würde da wirklich gerne die Hintergrundgeschichte kennen lernen...
Thread beobachten
Seitenaufteilung abschalten