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...
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?
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.pdfhttp://www.ebay.de/itm/300980101037
Gibt es auch mit 8 E/As.
Maze schrieb:> PS: Ich möchte keinen Glaubenskrieg zwischen den Anhängern der> verschiedenen µC-Familien damit provozieren...
Dafür reicht bereits der Titel.:-)
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.
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 alleMSP430-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.
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:> 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
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? ;)
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. ;)
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
>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
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 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.
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 ?
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
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 ;-)
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 :-)
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/... .
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:
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:> 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.
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.
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 ;-)
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."..."
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!
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.
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 ;-)
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:> 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 ;-)
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.
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:> 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
@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.
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...
