Hallo alle zusammen, ich hätte eine Frage zu Mikrocontrollern. Ich habe damals das Thema Mikrocontroller mit AVRs angefangen und habe in meine Tools viel Zeit und Geld investiert. Für mein erstes Projekt habe ich ein ATmega32u4 verwendet. Bei Conrad kostet so ein Ding knapp 10 Euro. Ich wollte in Kürze mit STM32 anfangen und habe gesehen, dass die Dinger wesentlich günstiger und leistungsstärker als die AVRs sind. Wieso verwendet man noch eigentlich 8-Bit Controller, wo doch die Leistungsstärkeren Controller günstiger zu bekommen sind? Hat das einen bestimmten Grund? LG
NaGo schrieb: > . Wieso verwendet man > noch eigentlich 8-Bit Controller, wo doch die Leistungsstärkeren > Controller günstiger zu bekommen sind? Hat das einen bestimmten Grund? Zu früh - morgen ist Freitag. 0 Troll-Punkte :-)
> Bei Conrad kostet so ein Ding knapp 10 Euro. Und bei Digikey nur 3,55€. Und wenn du als Großkunde gleich 100.000 abnimmst kriegst du die wahrscheinlich von Microchip zum Freundschaftspreis. > Wieso verwendet man noch eigentlich 8-Bit Controller, wo doch die > Leistungsstärkeren Controller günstiger zu bekommen sind? Hat das einen > bestimmten Grund? Weil die Leistung ausreicht, weil man bereits eine funktionierende Toolchain hat, weil man sich mit 8-Bittern besser auskennt, weil bereits existierender Code für 8-Bitter entwickelt wurde und eine Portierung weitaus teurer wäre, weil 16-/32-Bitter komplexer sind usw. usw.
NaGo schrieb: > Bei Conrad kostet so ein Ding knapp 10 Euro. Das ist ein sehr hoher Preis für den Controller. Bei Digikey liegt der so um die 3,50€ und ein STM32F103 so bei 4,50€. Das sind aber natürlich alles Preise die man noch um ein vielfaches unterbieten kann wenn man bei ebay oder so schaut (hat dann aber auch nicht die Garantie, Originalteile zu kriegen). > STM32 anfangen und habe gesehen, dass die Dinger wesentlich > günstiger und leistungsstärker als die AVRs sind. Wieso verwendet man > noch eigentlich 8-Bit Controller, wo doch die Leistungsstärkeren > Controller günstiger zu bekommen sind? Hat das einen bestimmten Grund? Es gibt ein paar Gründe, auch wenn die mit der Zeit immer weniger werden. Die Atmegas laufen z.b. auch auf 5V (gibt afaik aber auch STM mit 5V-toleranten Pins) und sind allgemein "robuster". Ein großes Plus für den Bastler ist auch, dass es die älteren Atmega in DIP-Packages gibt (die xmega leider nicht). Allgemein gilt für alle 8-bit Controller, dass sie einfach simpler aufgebaut sind und sich üblicherweise auch mit wenigen Zeilen Assembly schon ein lauffähiges Programm mit Peripherals ergibt. Das kann man auf ARM z.B. schon so gut wie vergessen. Viel mehr fällt mir aber eigentlich auch nicht ein. Sobald man Rechenleistung braucht, wird man wohl einen "großen" nehmen müssen. Für viele Projekte reicht aber dann eben auch ein 8-bit Controller der mal eben vom Breadboard ohne externen Quartz/Oszillator und mit wenigen Zeilen Code läuft.
:
Bearbeitet durch User
Die Schwall-Runde scheint trotzdem eröffnet zu sein :-) nur zu :-)
Dieter F. schrieb: > Zu früh - morgen ist Freitag. > > 0 Troll-Punkte :-) Mmmhhhhh.....alles klar. Der Pointler schrieb: > Und bei Digikey nur 3,55€. Und wenn du als Großkunde gleich 100.000 > abnimmst kriegst du die wahrscheinlich von Microchip zum > Freundschaftspreis. Das hätte ich vielleicht dazu schreiben sollen. Ich meine, warum sollte man es als PRIVATPERSON kaufen, wenn doch leistungsstärkere Controller sehr günstig zu erwerben sind? Das mit den Großkunden ist mir schon klar. Der Pointler schrieb: > Weil die Leistung ausreicht, weil man bereits eine funktionierende > Toolchain hat, weil man sich mit 8-Bittern besser auskennt, weil bereits > existierender Code für 8-Bitter entwickelt wurde und eine Portierung > weitaus teurer wäre, weil 16-/32-Bitter komplexer sind usw. usw. 1. Leistung reicht aus -> Ja, da hast du recht. Bisher hat sie mir gereicht. 2. Sind denn die 16/32 Bitter den so viel schwerer zu verstehen? Wie vorhin geschrieben. Ich habe mit der Einarbeitung noch nicht angefangen. Felix U. schrieb: > Das sind aber natürlich > alles Preise die man noch um ein vielfaches unterbieten kann wenn man > bei ebay oder so schaut (hat dann aber auch nicht die Garantie, > Originalteile zu kriegen). Ebay werde ich wohl nicht bevorzugen. Das ist mir doch zu riskant.
NaGo schrieb: > Sind denn die 16/32 Bitter den so viel schwerer zu verstehen? kommt drauf an auf welchem Level. Du kannst auch für 32-bitter Arduino-mäßig Sachen zusammenklicken oder mit Software-Frameworks der Hersteller arbeiten (guck dir mal STM32CubeMX an). ARM Assembly ist aber halt schon eine andere Hausnummer als 8-bit AVR, logischerweise.
Ich kann hier jetzt nur für mich sprechen, aber ich verwende die 8-bit AVRs sehr gerne weil sie ziemlich simpel aufgebaut und für meine (Hobby-)Zwecke (Sensor-/Messsteuerungen/Fahrradtelemetrie) noch vollkommen ausreichend sind. Zudem sind die meisten davon relativ günstig zu bekommen. Conrad ist in dieser Hinsicht für mich kein Maßstab, dort finde ich sie (eigentlich fast alles) überteuert. Und ein ATmega32U4 ist im Vergleich zu anderen AVRs ja schon sehr speziell, weil er USB mit an Bord hat. Was den kommerziellen Bereich angeht: Kann ich nicht viel zu sagen, ich kann mir allerdings vorstellen, dass es selbst in 2017 noch genügend Fälle gibt, in denen ein AVR völlig ausreichend und noch günstiger als ein ARM-basierter Mikrocontroller ist.
H.Joachim S. schrieb: > Das ist eigentlich immer ein grober Fehler. Ich verstehe worauf du hinaus willst. Der Vorteil ist bei mir, der Laden ist um die Ecke. Wenn ich was brauche, kann ich einfach da hin. Ich war halt nur überrascht, das manche Controller von wie STM32 für knapp 50 Cent zu bekommen sind, wobei einige AVR mega teuer sind. Was für tolles Wortspiel :) LG
Das Problem entspannt sich im Lauf der Zeit (wenn man seinen Hamstervorrat der üblichen Teile aufgebaut hat). Und fast nie ist es wirklich so eilig, dass ich da direkt hinfahren würde (sind auch nur 8km). Nebenbei: oft genug stand ich da auch vor leerem Lager, online-Abfrage gabs noch nicht. Ich meide den Laden inzwischen konsequent, Vertrauen auf Lebenszeit verspielt. edit: Zur eigentlichen Frage: ja, ich setze auch noch viele 8bitter ein. Tinys oder kleine PICs. Gibt so viele Problemchen, die sich damit klein und schnell erledigen lassen (vor wenigen Jahren wäre niemand auf die Idee gekommen, einen Blinker mit einem MC aufzubauen :-) Braucht es Rechenpower, umfangreiche on-chip-hardware/Konnektivität, gehts zum STM32. 16bit-Prozessoren benutze ich gar nicht, XMEGAs auch nicht (wofür die eigentlich gut sein sollen, konnte mir auch noch keiner erklären)
:
Bearbeitet durch User
NaGo schrieb: > > Ich meine, warum sollte > man es als PRIVATPERSON kaufen, wenn doch leistungsstärkere Controller > sehr günstig zu erwerben sind? Wen interressiert denn, ob der neue µC leistungsfähiger ist, wenn schon der alte nur 10% der Zeit gearbeitet und den Rest der Zeit Däumchen gedreht hat? Hab ich irgendwas davon, wenn sich das auf 5% zu 95% ändert? > 2. Sind denn die 16/32 Bitter den so viel schwerer zu verstehen? Wie > vorhin geschrieben. Ich habe mit der Einarbeitung noch nicht angefangen. Dann versuch es einfach mal. Dann wirst du sehen, was es für ein riesiger Vorteil ist, wenn man die Toolchain und etwaige Abstractionlayer schon kennt und sich auf deren Funktion verlassen kann.
Manchmal ist auch der Energieverbrauch entscheidend, werfe ich mal ein...
Ab und zu sind mir die 5V Pegel von so nem Arduino Nano ganz lieb.
Natürlich sind die 8 Bitter noch zeitgemäß und oft auch ausreichend. Aber wenn man etwas mehr möchte wie mehr Speicher, schnelle Grafik oder integrierten Ethernet Controller dann bieten die 32 Bitter mehr. Jetzt ist es aber vermessen zu denken mal eben eine neue Toolchain/Entwicklungsumgebung zu installieren und das bisher gelernte einfach auf das Neue anzuwenden und fertig zu sein. Man muss sich da reinarbeiten und lernt neue Fallstricke kennen. Deshalb macht es Sinn auch Anwendungen die man mit 8 Bittern erschlagen könnte als Übung mit 32 Bittern und der neuen Umgebung zu realisieren. Natürlich solange man es sich leisten kann und nicht irgendwelche Kostenargumente darüber stehen. Beim großen C gibt es die LPC zu akzeptablen Preisen, die sind hier leider nur bei den großen Distris zu bekommen.
Wir setzen je nach Projekt-Anforderungen 8-Bit 8051 z.B. EFM8 oder 32-Bit ARM z.B. LPC ein. Grade bei integriertem ADC DAC sind die 8051 noch immer besser wegen der robusteren Fertigung. Bei AVR gibt es aber keinerlei Vorteile mehr gegenüber ARM schon gar nicht beim Preis. Über den Preis war immer das Hauptargument bei PIC und PIC32 aber der MIPS Kern war halt eine Fehlentscheidung.
Felix U. schrieb: > kommt drauf an auf welchem Level. Du kannst auch für 32-bitter > Arduino-mäßig Sachen zusammenklicken oder mit Software-Frameworks der > Hersteller arbeiten (guck dir mal STM32CubeMX an). ARM Assembly ist aber > halt schon eine andere Hausnummer als 8-bit AVR, logischerweise. Lass mich raten: Beruflich bringt diese Arduino-mäßige zusammenklicken höchstwahrscheinlich nicht viel oder? Habe mir vorhin ein Video dazu angeschaut. Das ganze erinnert mich ein wenig an die PSoCs. LG
NaGo schrieb: > Für mein erstes Projekt habe ich ein ATmega32u4 verwendet. Bei Conrad > kostet so ein Ding knapp 10 Euro. I > ... > Hat das einen bestimmten Grund? Ja, sonst würde es nicht so sein. Conrad verkauft seine ATmega32u4 doch auch für 10€ und anscheindend gibt es genug Käufer dafür, obwohl es komplett bestückte Boards mit diesem Prozessor direkt aus China als Einzelstück incl. Porto für 3.20€ gibt. Conrad scheint der Meinung zu sein, dass sie trotz des Preises genug davon verkaufen und die betreffenden Kunden werden ihren Grund haben, warum sie dafür das Dreifache hinblättern. Frag dich selbst ...
8Bitter sind solange zeitgemäß wie sie die Aufgaben erledigen die gestellt sind. Das sind auf unabsehbare Zeit mehr als genug. Für gewöhnlich sollte man diese doch auf einfachstmögliche Art erledigen. Gehäusevielfalt, Robustheit und viel flexiblere Spannungsversorgung bis 5V sind mir persönlich als Bastler da allemal mehr wert als die Flexibilität ausgefeilter 32-Bit Features- die, sofern überhaupt von Nutzen, erstmal beherrscht werden wollen.
Lothar schrieb: > Bei AVR gibt es aber keinerlei Vorteile mehr gegenüber ARM Doch. Ich kenne sie. Ich brauche viel weniger Zeit für sie. Und sie tun es genauso.
NaGo schrieb: > Dieter F. schrieb: >> Zu früh - morgen ist Freitag. >> >> 0 Troll-Punkte :-) > > Mmmhhhhh.....alles klar. > > Der Pointler schrieb: >> Und bei Digikey nur 3,55€. Und wenn du als Großkunde gleich 100.000 >> abnimmst kriegst du die wahrscheinlich von Microchip zum >> Freundschaftspreis. > > Das hätte ich vielleicht dazu schreiben sollen. Ich meine, warum sollte > man es als PRIVATPERSON kaufen, wenn doch leistungsstärkere Controller > sehr günstig zu erwerben sind? Das mit den Großkunden ist mir schon > klar. Wer für ein Bastelprojekt die Preisscheere beim Controller ansetzt spart am falschen Ende. Viel wichtiger als der Controller ist die Toolchain und dass man damit umgehen kann. Und dass man damit Spass hat - das ist schießlich das Ziel der Bastelei. Mir persönlich ist das Arbeiten mit vertrauten Werkzeugen deshalb durchaus ein paar € wert. Da sollte man sich von "modern" oder "Bittigkeit" nicht zu sehr beeinflussen lassen.
Ich verwende die 8-Bitter ebenfalls sehr gerne. Konkretes Projekt: einfache Motorsteuerung mit zwei Endschaltern und IRMP. Umgesetzt auf einem Tiny24 (Der Lag noch im "Lager"). Der Knirps wird an 5V und GND gehängt, hat ausreichend viele I/O und der Speicher von 2k hat mit 97% Füllgrad (ohne Optimierungen ...) so gerade gepasst. Das 14-Beinige IC kann ich nun schnell auf Lochraster häkeln und fertig ist die Laube. Warum sollte ich für sowas einen ARM einsetzen? Für eine eigenständige Smart-Home-Zentrale mit buntem Touchi LCD macht ein ARM und Programmierung in höheren Sprachen, villeicht sogar Task mehr sinn. Hängt eben alles von der Anwendung ab.
Ich weiß nicht, warum soviel Aufhebens um den Preis gemacht wird, eine Platine besteht doch nicht nur aus dem MC allein. In meinen Schaltungen ist der MC bei weitem nicht das teuerste Bauteil, sondern geht völlig in dem anderen Kleinzeug unter. Die AVRs sind recht einfach zu durchschauen, obwohl manchmal die fehlenden Interruptlevel Kopfzerbrechen bereiten. Beim 8051 sieht man schön, daß sich die Entwickler noch bei allem was gedacht haben. Die Architektur ist schnörkellos und enthält alles wichtige. Der Befehlssatz ist richtig elegant, da macht es sogar Spaß, ihn in Assembler zu programmieren. Ich hab 1993 den AT89C2051 in einem Projekt eingesetzt und der ist immer noch gut beschaffbar. Es gibt also noch reichlich Großabnehmer, die ihn einsetzen. Atmel hat ja später den schnelleren AT89LP4052 entwickelt, aber der hat sich nicht mehr so durchsetzen können. Die höhere Rechenleistung wurde einfach nicht gebraucht. Pech hatte ich dagegen mit den 8051 von Philips/NXP, die wurden fast alle eingestampft. Als Nachfolger hatte ich dann für den P89C668 den AT89C51RE2 eindesigned und dann ging die Fab in Rousset pleite, die ihn herstellte.
H.Joachim S. schrieb: > Das ist eigentlich immer ein grober Fehler. Unverzeilich! Für den Geldbeutel zumindest :-)
Peter D. schrieb: > Ich weiß nicht, warum soviel Aufhebens um den Preis gemacht wird, eine > Platine besteht doch nicht nur aus dem MC allein. In meinen Schaltungen > ist der MC bei weitem nicht das teuerste Bauteil, sondern geht völlig in > dem anderen Kleinzeug unter. Moderne 8-Bitter besitzen oft Zusatzfunktionen, die ich dann nicht extra realisieren muss. Zudem ist zum Beispiel für ein 18-poliges Gehäuse das Layout deutlich kleiner und einfacher, als bei einem 64-poligem Gehäuse. Zudem habe ich beim 8-Bitter die Chance, jedes einzelne Bit zu kennen. Im Gegensatz zu oft nur zusammengeklickten Programmen arbeiten die Geräte deutlich stabiler, was besonders bei Störungen sehr positiv auffällt.
Mein VW Golf ist in die Jahre gekommen, soll ich mir jetzt einen neuen Audi Q7 kaufen? Fahren kann ich und der Audi Q7 hat auch 22 Zoll Felgen statt 16 beim VW Golf... Juhuuu, endlich Freitag ;-)
samy schrieb: > Moderne 8-Bitter besitzen oft Zusatzfunktionen, die ich dann nicht extra > realisieren muss. Haben ARMs auch. Gibt mehrere ... > Zudem ist zum Beispiel für ein 18-poliges Gehäuse das > Layout deutlich kleiner und einfacher, als bei einem 64-poligem Gehäuse. Also LPC832M (SO 8) dem ATmega128 (TQFP 64) vorziehen. ... Lothar schrieb: > bei PIC und > PIC32 aber der MIPS Kern war halt eine Fehlentscheidung. PIC32M = MIPS PIC32C = Core - also ARM (Aus den ATMEL SAM) Und ich finde die PIC32MZ richtig gut! Gruß Jobst
:
Bearbeitet durch User
Ein AVR ist ein stueck einfacher wie ein Arm. Und ich habe den Anspruch, dass meine Software fehlerfrei laeuft. Denn die muss jahrelang durchlaufen. Das wird schwierig mit Frameworks, die man zusammenclickt.
Das hat viele Gründe. Nostalgie, Erfahrung mit 8-Bittern, gefühlte Sicherheit, Lust an der Herausforderung ein Programm klein genug zu bekommen, große Community, Teile habt man es im Lager, wurde immer schon so gemacht... Aus technischer Sicht ist es schlicht egal, beide Typen können die Aufgabe erledigen. Ich denke, wenn sich am Preis nichts tut, dann hole ich mir das leistungsfähigere System, selbst wenn ich die Leistung nicht benötige. Haben ist besser als Brauchen. ;)
Lothar schrieb:
> aber der MIPS Kern war halt eine Fehlentscheidung.
Verstehe ich auch nicht.
Juhu, Wochenende ist eingeleitet, und das schon am Donnerstag. Perfekt!
Leroy M. schrieb: > Nostalgie, Die neuesten Generationen besitzen Eigenschaften, von dehnen man früher nur träumen konnte. Was ist daran nostalgisch? Leroy M. schrieb: > Erfahrung mit 8-Bittern, Fast richtig, Erfahrungen auch (!) mit 8-Bittern. Leroy M. schrieb: > gefühlte Sicherheit, Falsch, im EMV-Labor lässt es sich auch normengerecht nachweisen. Leroy M. schrieb: > Lust an der > Herausforderung ein Programm klein genug zu bekommen, Nein, sondern pure Geldgier: geringerer Aufwand = höherer Gewinn Leroy M. schrieb: > große Community, Fast richtig, auch große Community. Leroy M. schrieb: > Teile habt man es im Lager, Lager = RS oder Farnell, somit alle (!) Varianten im Lager. Leroy M. schrieb: > wurde immer schon so gemacht Nein, es findet bei allen Varianten eine ständige Anpassung an die veränderten Eigenschaften statt.
Bei 16/32-Bittern kann es sein dass ein Programm bzw. Daten im Speicher immer an geradzahligen Adressen liegen müssen. Das kommt daher weil der 16/32-Bit-Bus immer das ganze Wort lesen will beim Speicherzugriff. Das macht soweit ich weiss immer der Compiler - der sorgt dafür dass eventuell NOPs eingefügt werden. Für Bastler ist das natürlich etwas ungünstig :-) Daher die 8-Bitter, die haben soetwas nicht. Dazu noch der übersichtliche Adressraum nebst Busleitungen usw.
Pete K. schrieb: > Mein VW Golf ist in die Jahre gekommen, soll ich mir jetzt einen neuen > Audi Q7 kaufen? Fahren kann ich und der Audi Q7 hat auch 22 Zoll Felgen > statt 16 beim VW Golf... Wenn der Q7 auch die hälfte des Golf kostet...... /Ironie könnte hinkommen, wenn man den Q7 TDI gegen den e-Golf vergleicht ;-) /Ironie off
Für jemanden der neu anfängt und keine Millionenabsätze hat gibt es keinen vernünftigen Grund 8-Bitter zu nehmen. (Und selbst das Argument bröckelt. Ein kleiner CortexM0 kostet keine 0,60€) 32 Bit-Arm sind eine Ecke komplizierter, aber das ist nix was man nicht in einer Woche erlernen kann. Alteingesessene haben klar einen Vorteil mit 8-Bittern wg. der Erfahrung. Viele Tricks und kniffe die man da erlernt hat sind auf 32-Bit Plattformen aber nutzlos. Als ich nach 10 Jahren 8-bittern das erste mal einen ARM programmieren musste hats mich auch innerlich erstmal gesträubt. Heute würd ich aber keinen 8-bitter nutzen wenn es sich irgendwie vermeiden lässt. Alle Argumente von Gehäusegröße und Stromverbrauch stammen von Unwissen. Es gibt Arm mit 12-Pin SOIC die man wunderbar auch als Hobbyist verwenden kann. Mit 0,20€ Adapterplatine auch mit Steckbrett. Die Low Power Modelle brauchen Active <3mW und Idle 40µW Wenn man den Stromverbrauch der µC vergleicht muss man das natürlich bei der gleichen CPU-Taktung machen (Bzw. ggf. geringer, nachdem man bei 32 bit häufig weniger Schritte braucht). 48MHz Arm mit 8MHz Attiny zu vergleichen ist natürlich blödsinn. Auch die Software-frameworks sind kein muss. Zumindest Funktionen wie UART, SPI, I2C kriegt man auch so hin. gibt aber keinen Vernünfigen grund sich die treiber selber zu schnitzen, wenn man nicht grad MISRA-Konform arbeiten muss. Selbst dann kauft man sich eher MISRA-Konforme treiber von extern ein, als sich selber damit auseinander zu setzen. Wenn ich einen µC verwende will ich eine Bestimme Aufgabe erfüllen. Rausfinden wie die Treiber funktionieren zahlt mir der Kunde nicht..
hänschen schrieb: > Bei 16/32-Bittern kann es sein dass ein Programm bzw. Daten im Speicher > immer an geradzahligen Adressen liegen müssen. Und bei 8-Bittern kann es sein, daß die Bits alle in einem Byte liegen müssen. Immer wieder ein dramatisches Problem ;-)
samy schrieb: > Leroy M. schrieb: >> Nostalgie, > > Die neuesten Generationen besitzen Eigenschaften, von dehnen man früher > nur träumen konnte. Was ist daran nostalgisch? > Natürlich, moderne Kutschen haben auch Gummibereifung, von der man früher nur träumen konnte. ;) > > Leroy M. schrieb: >> Erfahrung mit 8-Bittern, > > Fast richtig, Erfahrungen auch (!) mit 8-Bittern. > Schaden sicherlich nicht. Aber deswegen muss man nicht auf Erfahrung mit 32-Bittern verzichten. > > Leroy M. schrieb: >> gefühlte Sicherheit, > > Falsch, im EMV-Labor lässt es sich auch normengerecht nachweisen. > Gemeint war eher die gefühlte Sicherheit im Umgang mit den Controllern. > > Leroy M. schrieb: >> Lust an der >> Herausforderung ein Programm klein genug zu bekommen, > > Nein, sondern pure Geldgier: geringerer Aufwand = höherer Gewinn > Entfällt im privaten Bereich, insbesondere wenn das Chinamodul gleich viel kostet. Im geschäftlichen Bereich ist das selbstverständlich so. Da zählt jeder Zehntelcent. > > Leroy M. schrieb: >> große Community, > > Fast richtig, auch große Community. > Ich denke die "8-Bitter-Community" ist die Stärkste. Im Bereich der "Maker", Hobbyisten, Bastler und Beginner. > > Leroy M. schrieb: >> Teile habt man es im Lager, > > Lager = RS oder Farnell, somit alle (!) Varianten im Lager. > Sicher, man kann alles kaufen, wenn man es muss. > > Leroy M. schrieb: >> wurde immer schon so gemacht > > Nein, es findet bei allen Varianten eine ständige Anpassung an die > veränderten Eigenschaften statt. Ein mal Atmel, immer Atmel. Die Fanboys haben da so ihre Präferenzen, habe ich gehört. :D Aber im Ernst, der Mensch neigt dazu funktionierende Prozesse zu wiederholen, selbst wenn sie Optimierungspotential haben. Lieber einen Weg gehen, der zwar beschwerlich ist, aber zum Ziel führt, als eine ggf. einfachere Alternative zu suchen und das Risiko zu tragen, keinen Erfolg zu haben. Das ist nicht mal verwerflich und eigentlich eine sinnvolle Strategie. Zumindest aus evolutioneller Sicht, in der das Risiko keinen Erfolg zu haben gleichbedeutend war mit der eigenen Entfernung aus dem Genpool. Ich will 8-Bitter nicht schlecht machen, sie haben durchaus ihre Berechtigung. Sonst würden sie nicht mehr produziert. Aber im Hobbybereich sind sie quasi immer ersetzbar mit den größeren Brüdern. Man kann sie natürlich trotzdem einsetzen, aus mannigfaltigen Gründen, man muss es aber nicht. Die gleiche Diskussion hätte man auch vor einigen Jahr(zehnt)en auch um Röhren vs. Transistoren führen können.
Bei uns war letztens einfach nur der Platzfaktor entscheidend. Auf eine bestehende Platine musste ein Mikrocontroller + Peripherie erweitert werden, da war nur Platz für einen 8-Bitter im SO-8 Package.
hänschen schrieb: > Bei 16/32-Bittern kann es sein dass ein Programm bzw. Daten im Speicher > immer an geradzahligen Adressen liegen müssen. Dieses Problem ist bei mir in fast 10 Jahren ARM-Entwicklung noch nie als Problem aufgetaucht. Gruß, Stefan
Was mir bei vielen ARM mißfällt, daß die keine vernünftige UART haben, sondern nur diesen 16550-kompatiblen Mist. D.h. RS-485 mit 9bit für die Adressierung geht damit nicht.
Peter D. schrieb: > Was mir bei vielen ARM mißfällt, daß die keine vernünftige UART > haben, > sondern nur diesen 16550-kompatiblen Mist. > D.h. RS-485 mit 9bit für die Adressierung geht damit nicht. Mein STM32 kann 9Bit; Seite 1014, RM0090
1 | Bit 12 M: Word length |
2 | This bit determines the word length. It is set or cleared by software. |
3 | 0: 1 Start bit, 8 Data bits, n Stop bit |
4 | 1: 1 Start bit, 9 Data bits, n Stop bit |
5 | Note: The M bit must not be modified during a data transfer (both transmission and reception) |
Peter D. schrieb: > Was mir bei vielen ARM mißfällt, daß die keine vernünftige UART haben, > sondern nur diesen 16550-kompatiblen Mist. > D.h. RS-485 mit 9bit für die Adressierung geht damit nicht. Also der STM32 hat das (kopiert aus Ref.Man STM32F2xx): * Programmable data word length (8 or 9 bits) Das Einzige, was der nicht kann, ist ein Interrupt NUR dann, wenn das 9.Bit gesetzt ist (wie das meiner Erinnerung nach die 8051-kompatiblen teilweise konnten). das 9.Bit empfangen ist aber kein Problem. Eher schon, dass es zu viele Einstellmöglichkeiten gibt ... Gruß, Stefan
Peter D. schrieb: > Was mir bei vielen ARM mißfällt, daß die keine vernünftige UART haben, > sondern nur diesen 16550-kompatiblen Mist. > D.h. RS-485 mit 9bit für die Adressierung geht damit nicht. Was hat DAS denn mit ARM zu tun, hmm? Das ist Peripherie, und liegt in der Verantwortung des Controllerherstellers, und hat mit dem Prozessorkern NICHTS, aber auch gar nichts zu tun. Das ist wie: Meine Fernbedienung hat keinen "Menü" Button, deswegen sind Varta Batterien allgemein Blödsinng (weil halt die Fernbedienung von einer Varta-Batterie betrieben wird). Auf diesem Niveau bewegt sich diese Kritik. Der Prozessorkern ist für viele Projekte - abgesehen von der Performance - relativ egal. Für mich (PIC12-PIC32 Nutzer) ist der einzige Unterschied die Rechenperformance und der Compiler. Und das, obwohl die Kerne der Controller nicht unterschiedlicher sein könnten :-)
Hallo Fabian, > Es gibt Arm mit 12-Pin SOIC die man wunderbar auch als Hobbyist > verwenden kann. Mit 0,20€ Adapterplatine auch mit Steckbrett. Welche sind das? > Selbst dann kauft man sich eher MISRA-Konforme treiber von extern > ein, als sich selber damit auseinander zu setzen. Ich schreibe jetzt mal aus Sicht des Hobbyisten, für den eine solche Variante weg fällt, da unbezahlbar. Also doch selber Treiber schreiben oder darauf hoffen das eine Gemeinschaft das schon getan hat. Und das ist eben der Vorteil der 8-Bit-µPCs: da gibt es seit Jahrzehnten für praktisch alles Codebeispiele. Und es wird täglich mehr und das trotz deutlich leistungsfähiger 32-Bit-µPCs. rhf
Peter D. schrieb: > Was mir bei vielen ARM mißfällt, daß die keine vernünftige UART haben, > sondern nur diesen 16550-kompatiblen Mist. > D.h. RS-485 mit 9bit für die Adressierung geht damit nicht. Das ein moderner uC keine Protokolle aus den 90ern unterstützt sollte verschmerzbar sein. EtherCAT oder CANopen haben RS485 geräte weitgehend ersetzt. Von da ist das ein sterbender Markt. Wenn man es unbedingt braucht nimmt man eben einen 8-Bitter. Wg. einen antiken Sonderfall würde ich aber nicht generell auf 8 Bit umsteigen..
Fabian F. schrieb: > Das ein moderner uC keine Protokolle aus den 90ern unterstützt sollte > verschmerzbar sein. > EtherCAT oder CANopen haben RS485 geräte weitgehend ersetzt. Von da ist > das ein sterbender Markt. Bravo! Dann brauchst Du ja kein RSxxx, SPI oder IIC mehr.
>> D.h. RS-485 mit 9bit für die Adressierung geht damit nicht. > Das ein moderner uC keine Protokolle aus den 90ern unterstützt sollte > verschmerzbar sein. Noe, verschmerzbar ist das nicht. Ist naemlich ein Industriestandard ausserhalb der Konsumelektronik. Aber deshalb gibt es durchaus auch ARMs die das koennen. Es gibt eine andere Sache die bei modernen Controllern manchmal bloed ist. Und das ist der Verlust an Syncronizitaet zwischen IO und Core. Olaf
Fabian F. schrieb: > EtherCAT oder CANopen haben RS485 geräte weitgehend ersetzt. Von da ist > das ein sterbender Markt. Ich halte ProfiBUS jetzt nicht wirklich für "am Sterben". ProfiNET, EtherCAT und wie sie alle heißen sind im Anlagenbau zwar vereinzelt vorhanden, aber nicht unbedingt üblich.
Roland F. schrieb: > Hallo Fabian, > >> Es gibt Arm mit 12-Pin SOIC die man wunderbar auch als Hobbyist >> verwenden kann. Mit 0,20€ Adapterplatine auch mit Steckbrett. > > Welche sind das? Microchip AtSAMD09/10 NXP LPC1112FD20 (So20) STM32L011De (TSSOP16) > > Ich schreibe jetzt mal aus Sicht des Hobbyisten, für den eine solche > Variante weg fällt, da unbezahlbar. Also doch selber Treiber schreiben > oder darauf hoffen das eine Gemeinschaft das schon getan hat. > Und das ist eben der Vorteil der 8-Bit-µPCs: da gibt es seit Jahrzehnten > für praktisch alles Codebeispiele. Und es wird täglich mehr und das > trotz deutlich leistungsfähiger 32-Bit-µPCs. Als Hobbyist nehm ich die kostenlosen Treiber von Atmel/STM/NXP &Co die decken die komplette Peripherie ab. m.n schrieb: >Bravo! Dann brauchst Du ja kein RSxxx, SPI oder IIC mehr. So ein Blodsinn. SPI und i2c sind für kommunikation auf der Platine, und da gibt es auch keine "moderneren" alternativen. RS485 ist ein externer Bus. Leroy M. (mayl) schrieb: >Ich halte ProfiBUS jetzt nicht wirklich für "am Sterben". Bei uns schon. Unsere Kunden Fragen nach USB, Ethernet, und CANopen. Rs485 haben wir schon seit über 3 Jahren nicht mehr verkauft. Viele Geräte unterstützen noch Profibus, aber eben auch neuere Standards. Ich glaube kaum das ein CNC oder Netzteilhersteller heute noch ein neues Gerät entwickeln würde, dass nur Profibus kann.
:
Bearbeitet durch User
Leroy M. schrieb: > Ein mal Atmel, immer Atmel. Wie gesagt, 1993 war der AT89C2051 wirklich ein super MC, viele haben damit überhaupt erstmal MC-Luft geschnuppert. Die PIC-Leute hatten zu der Zeit nur die teuren Chips mit UV-Löschfenster oder nen Mülleimer neben dem Arbeitstisch für die vielen verbrannten OTPs. Leroy M. schrieb: > Lieber einen Weg gehen, der zwar beschwerlich ist, aber zum Ziel führt, > als eine ggf. einfachere Alternative zu suchen und das Risiko zu tragen, > keinen Erfolg zu haben. Das Gegenteil ist der Fall, etwas neues ist deutlich beschwerlicher, als eine eingespielte Toolchain. Daher braucht der Umstieg erstmal einen triftigen Grund, z.B. daß die Leistung der bisherigen MCs nicht mehr ausreicht. Und da hapert es noch bei uns an einer Killerapplikation, die den Umstieg zwingend machen würde. Das Risiko kann eine zusätzliche Rolle spielen, wenn die Deadline drückt. Und auch das Risiko, daß die neue Platine beim EMV-Test erstmal durchfallen kann. Wir setzen zunehmend auch den LPC1768 ein. Es gibt allerdings nichts vergleichbares, was ähnlich einfach dem kostenlosen AVR-Studio ist (installieren und läuft). Daher mußte ein kommerzielles Produkt (IAR) mit floating license gekauft werden.
:
Bearbeitet durch User
Peter D. schrieb: > Wir setzen zunehmend auch den LPC1768 ein. Es gibt allerdings nichts > vergleichbares, was ähnlich einfach dem kostenlosen AVR-Studio ist > (installieren und läuft). LPC/MCUXpresso?
Johannes S. schrieb: > Peter D. schrieb: >> Wir setzen zunehmend auch den LPC1768 ein. Es gibt allerdings nichts >> vergleichbares, was ähnlich einfach dem kostenlosen AVR-Studio ist >> (installieren und läuft). > > LPC/MCUXpresso? Ist eine Krankheit die IDE. Noch nie so eine miese Eclipse-Verhackstückelung gesehen. Wobei IAR auch nur marginal besser ist... Verglichen mit der STM/Atmel IDE ein Trauerspiel.
sehe ich nicht so, vor allem das Debuggen funktioniert damit ad hoc. Eclipse IDEs an sich sind gewöhnungsbedürftig. Einige wichtige Funktionen sind da in ein QuickStart Fenster gepackt worden, das hat mir anfangs einiges an suchen erspart. Einziger Nachteil ist das die IDE nur für LPC und Kinetis gemacht ist.
Johannes S. schrieb: > sehe ich nicht so, vor allem das Debuggen funktioniert damit ad hoc. Ad Hoc? Ich hatte das zweifelhafte vergnügen mit einem LPC1758 zu arbeiten. Das Feedback des Debuggers tendiert stark gegen 0. Weder erkennt der das ein Debugger angeschlossen wurde, noch gibt's brauchbare Infos warum das Debuggen heut mal wieder nicht geht. Alles was der Vermag zu sagen ist: "02: Failed on connect 02: Failed on connect Could not connect to core. 31: No connection to emulator device " Würde man anhand dieser Fehlermeldung drauf kommen, dass VCC des Targets falsch ist? Abgesehen davon ist auch nicht hilfreich, dass die Dokumentation von NXP doch er sub par ist. > Eclipse IDEs an sich sind gewöhnungsbedürftig. Die STM IDE ist auch eclipse-Basiert und läuft 1A Abgesehen davon kommt man bei der IDE auch schnell an die Grenze wo es nicht mehr kostenlos ist.
:
Bearbeitet durch User
Fabian F. schrieb: > Würde man anhand dieser Fehlermeldung drauf kommen, dass VCC des Targets > falsch ist? Wenn die Spannung falsch ist läuft doch das Target nicht. Was man falsch machen kann ist VTarget nicht an den Debugger anzuschliessen, die versorgt da üblicherweise die Treiber und damit stellen sich die Pegel automatisch passend ein. Fabian F. schrieb: > Abgesehen davon kommt man bei der IDE auch schnell an die Grenze wo es > nicht mehr kostenlos ist. Falls du ein Codesize Limit meinst: gibt es nicht mehr in MCUX. Geld ausgeben muss man nur für die den erweiterten Debugsupport mit Trace und mehr ITM Features oder wenn man gerne mit NXP telefonieren möchte.
Ohman schrieb: > Auf eine bestehende Platine musste ein Mikrocontroller + Peripherie > erweitert werden, da war nur Platz für einen 8-Bitter im SO-8 Package. Ein TSSOP14 (z.B. STM32L011D3) ist in etwa genau so groß. QFN32 sogar noch etwas kleiner (rein vom Package).
hänschen schrieb: > Bei 16/32-Bittern kann es sein dass ein Programm bzw. Daten im Speicher > immer an geradzahligen Adressen liegen müssen. Bei den AVRs müssen die Daten auch immer auf den geraden Byte-Adressen des 16-Bit breiten Flashs beginnen. 680x0 ist es allerdings egal. Leroy M. schrieb: > Gemeint war eher die gefühlte Sicherheit im Umgang mit den Controllern. Das ist aber eigentlich ehr ein Trugschluss. Was machst Du, wenn Dein 8-Bitter einen Bug im Programm hat, obwohl Du die Sicherheit gefühlt hast? Leroy M. schrieb: >> Nein, es findet bei allen Varianten eine ständige Anpassung an die >> veränderten Eigenschaften statt. > > Ein mal Atmel, immer Atmel. Die veränderte Eigenschaft bei Atmel ist, dass sie an Microchip verkauft wurden. Ohman schrieb: > Bei uns war letztens einfach nur der Platzfaktor entscheidend. Auf eine > bestehende Platine musste ein Mikrocontroller + Peripherie erweitert > werden, da war nur Platz für einen 8-Bitter im SO-8 Package. Stimmt. 32-Bitter im SO-8 Package sind viel zu groß. Gruß Jobst
:
Bearbeitet durch User
Jobst M. schrieb: > Bei den AVRs müssen die Daten auch immer auf den geraden Byte-Adressen > des 16-Bit breiten Flashs beginnen. Nicht die Daten. Nur der Code.
A. K. schrieb: > Jobst M. schrieb: >> Bei den AVRs müssen die Daten auch immer auf den geraden Byte-Adressen >> des 16-Bit breiten Flashs beginnen. > > Nicht die Daten. Nur der Code. Dann zeig mir mal den Trick, wie Du sie an ungeraden Adressen beginnen lässt. Und ein Byte vorweg schreiben gilt nicht. Das sind ja auch schon Daten. Gruß Jobst
Jobst M. schrieb: > Dann zeig mir mal den Trick, wie Du sie an ungeraden Adressen beginnen > lässt. Und ein Byte vorweg schreiben gilt nicht. Das sind ja auch schon > Daten. 3 Interpretationen: Daten an einer ungerade Adresse beginnen lassen zu können interpretierte ich als eine Frage von Alignment-Restriktion beim Zugriff auf Daten, die grösser als ein Byte sind, also beispielsweise C "int" Daten. Die AVR Cores haben dies nicht, 68000 hingegen schon. Dass man ein ROM weder bei AVR noch bei 68000 an einer ungeraden Adresse beginnen lassen kann (ohne üble Verrenkungen) liegt an 16 Bit breiten ROMs. Eine Eigenschaft, die beide Architekturen teilen. Auch bei 68000 fangen ROMs (und RAMs) an einer geraden Adresse an, d.h. vor einem Byte an einer ungeraden Adresse ist immer ein Byte an einer geraden Adresse. Eine wieder andere Interpretation betrifft die Programmiersprache. Da Atmels Assembler im ROM mit Wortadressen rechnet, ist es nicht möglich, in diesem Assembler Daten an einer ungeraden Adresse beginnen zu lassen. Aber das ist nur eine Einschränkung dieses Assemblers. Beim GNU Assembler dürfte das kein Problem darstellen, da darin ROM-Adressen in Bytes gerechnet werden.
:
Bearbeitet durch User
Hi! Im Hobby bin ich schon seit einigen Jahren komplett von AVR auf ARM umgestiegen und würde auch nie mehr zurückwechseln. Selbst einfache Schaltungen realisiere ich nur noch mit ARM. Spielt keine Rolle ob die Leistung gebraucht wird oder nicht. Eine komplette Leiterplatte mit bestücktem CortexM3, stiftleiste, USB-Buchse, LEDs, Spannungsregler usw. kostet weniger als 2 Euro. Das Programmiergerät kostet ebenfalls nur soviel wie eing Glas Bier und kann Debuggen. Bei AVR blecht man für die gleiche Funktionalität zig Euro. Da ich alles in C programmiere ist Komplexität irrelevant. Ich progge das ding schließlich nicht in ASM.
A. K. schrieb: > Dass man ein ROM weder bei AVR noch bei 68000 an einer ungerade Adresse > beginnen lassen Nein, das meine ich nicht. Beim 68k könnte man in einem Bereich auf den oberen 8 Bit (Datenbus) ROM und auf den unteren 8 Bit RAM anschnuddeln. RAM wäre dann auf geraden Adressen, ROM auf ungeraden. Wäre aber nur sinnvoll, wenn es unbedingt 8-Bit Bausteine sein sollen. Man spart sich dann eine Leitung aus dem Adressdecoder. Und der Bereich taugt selbstverständlich nicht für Programmcode. Größere 68k (ab 68030?) können auch Programmcode von ungeraden Byteadressen aus dem 32 bittigen Speicher holen. Der 16 bittige Befehl kann also im obersten Byte der einen und im untersten Byte der nächsten 32-Bit Adresse liegen. A. K. schrieb: > Beim GNU > Assembler dürfte das kein Problem darstellen, da darin ROM-Adressen in > Bytes gerechnet werden. Das ist egal. Ob Daten am ROM-Anfang beginnen (uncool, weil die AVR-CPU dort startet) oder nach irgendeinem Befehl: Die nächste Byte-Adresse ist gerade. Und der Flashspeicher kann auch nur gerade mit 16-Bit Worten beschrieben werden. Natürlich kannst Du eine ungerade Anzahl an Bytes ungelesen links liegen lassen oder vorweg schreiben, aber der Datenbereich beginnt auf einer geraden Byte-Adresse. Gruß Jobst
Jobst M. schrieb: > A. K. schrieb: >> Jobst M. schrieb: >>> Bei den AVRs müssen die Daten auch immer auf den geraden Byte-Adressen >>> des 16-Bit breiten Flashs beginnen. >> >> Nicht die Daten. Nur der Code. > > Dann zeig mir mal den Trick, wie Du sie an ungeraden Adressen beginnen > lässt. Und ein Byte vorweg schreiben gilt nicht. Das sind ja auch schon > Daten. Völlig Offtopic. Seid ihr bald fertig mit der Haarspalterei? lg Heiner
Jobst M. schrieb: > Beim 68k könnte man in einem Bereich auf den oberen 8 Bit (Datenbus) ROM > und auf den unteren 8 Bit RAM anschnuddeln. Könnte Atmel auch machen. Aus unerfindlichem Grund haben sie allerdings bisher keinen solchen Controller rausgebracht. ;-)
Peter D. schrieb: > Wir setzen zunehmend auch den LPC1768 ein. Es gibt allerdings nichts > vergleichbares, was ähnlich einfach dem kostenlosen AVR-Studio ist > (installieren und läuft). Daher mußte ein kommerzielles Produkt (IAR) > mit floating license gekauft werden. Schon mal Atollic TrueStudio angeschaut?
Fabian F. schrieb: > Alle Argumente von Gehäusegröße und Stromverbrauch stammen von Unwissen. > Es gibt Arm mit 12-Pin SOIC die man wunderbar auch als Hobbyist > verwenden kann. Mit 0,20€ Adapterplatine auch mit Steckbrett. > Die Low Power Modelle brauchen Active <3mW und Idle 40µW Ein Hauptvorteil der 8-bit µCs ist, dass diese meist auch mit 5V betrieben werden können. Weniger wegen Logikbausteinen, sondern vielmehr weil man sich dadurch Pegelwandler, Mosfet-Treiber u.dgl. sparen kann.
Ich bin bei diesem Thema eigentlich auch sehr zwiegespalten. Ich bin um 2002/2003 in die Mikrocontroller-Welt eingestiegen und damals erschienen mit die 8 bit uCs richtig cool. Wenn ich mich aber heute so umsehe und dann denke, was wäre wenn...also ehrlich gesagt denke ich, heute würde ich mich kaum noch für 8 bit entscheiden. Alle Aufgaben, die ich bisher so hatte, konnten 8 bit uCs bewerkstelligen, 16/32 bit uCs können das aber auch und nicht selten tun die sich dabei weniger schwer, so zumindest mein Eindruck. Ich denke, es gibt kaum eine Aufgabe bei der man sagen kann: Hey, genau der uC xyz ist dafür prädestiniert. Meist ist es ja so, dass man den Wald vor lauter Bäumen nicht mehr sieht, sprich für die gestellte Aufgabe ist meist ne ganze Kiste von uCs geeignet sie zu bewältigen und es fällt schwer ein Kritierium zu finden weshalb man diesen oder jenen uC ausschließen kann.
Für ein privates Projekt habe ich ein Stm32f040 genutzt. Das ganze war eine Ansteuerung für rgb LEDs. Der stm war wie dafür gemacht. Ich nutze eine 3 Kanal 12 Bit Hardware pwm mit ausreichender Frequenz. Desweiteren nutze ich noch den 12bit adc und uart für rs485. Das ganze hätte ich auch mit einen attiny realisieren können, was aber umständlicher und teuer geworden wäre... Mouser: Stm32f030f4p6 100 Stück 0,757€ Attiny85-20pu 100stück 0,876€
Tobi schrieb: > Stm32f030f4p6 100 Stück 0,757€ > Attiny85-20pu 100stück 0,876€ Und jetzt hast Du jeweils 100 Stück davon gekauft, weil Du einen einzigen STM32F040 brauchtest? Nicht sehr clever!
Das war ein Projekt wo ich 100 mC brauchte. Hatte mich auch erst vertippt und sollte stm32f030 heißen und nicht stm32f040. Das war auch nur ein Beispiel, warum ich ein 32 bitter ein 8er vorgezogen habe. Die Programmierung des stm32f0 war auch Recht simpel und nicht ganz so aufwendig wie bei den größeren stm32.
Fabian F. schrieb: > Unsere Kunden Fragen nach USB, Ethernet, und CANopen. > Rs485 haben wir schon seit über 3 Jahren nicht mehr verkauft. Unsere Kunden fragen i.d.R. nicht nach technischen Details, sondern nur nach Funktionalität und den Kosten. Insbesondere in Hinsicht auf Letzteres macht es einen Unterschied, ob der Elektriker in einem Bestandsgebäude 30 CAT7-Kabel ziehen muß oder nur zwei Klingeldrähte. Von der arg begrenzten Reichweite des Ethernet gar nicht zu reden. RS485 hat durchaus noch seine Berechtigung.
Tobi schrieb: > Für ein privates Projekt habe ich ein Stm32f040 genutzt. > Das ganze war eine Ansteuerung für rgb LEDs. > Der stm war wie dafür gemacht. > Ich nutze eine 3 Kanal 12 Bit Hardware pwm mit ausreichender Frequenz. > Stm32f030f4p6 100 Stück 0,757€ Das wäre auch billiger gegangen. Den STM8S103F3P6 gibts im Zehnerpack für €3,33 inclusive Versand aus China. Also für weniger als die Hälfte. Der hat auch 3 PWM-Kanäle bis 16 Bit Auflösung und eignet sich so prima, um eine RGB-LED anzusteuern [1]. Und er ist - Überraschung - ein 8-Bitter. [1] Beitrag "RGB Moodlight mit STM8"
Ich habe nur 10 Stück für 4,67€ gefunden, was immer noch 30ct günstiger ist und mich zum Schluss 30€ gespart hätte. Ich habe aber den Vertriebsweg eBay nicht in Betracht gezogen. Natürlich hätte der stm8 für mein Projekt vollkommen ausgereicht aber es hat auch ein wenig Bequemlichkeit (Vorkenntnisse mit den stm32) und ein schon vorhandener programmer hereingespielt.
Die 8 Bit µCs haben schon noch ein paar Vorteile. Teils ist das einfach auch nur die Erfahrung der Programmierer und die passende Peripherie (und sei es auch nur ein 5 V Ausgang). Die Caches / Waitstates der ARMs machen es schwer die Laufzeit genau vorher zu sagen, d.h. Verzögerungen über die Laufzeit sind oft nicht mehr genau. Das war bei den 8 Bittern ggf. auch nicht die schönste Methode, kann aber für kurze Zeiten sehr effektiv sein - einer der wenigen Gründe auch noch mal in ASM zu programmieren. Für extreme Bedingungen wie Space oder hohe Temperaturen wird es ggf. auch einfacher passende 8 Bitter zu finden. Sinnvoll die die 8 Bitter auch eher bei den kleinen Modellen mit vielleicht 1-2 kB - da sind dann bei relevanten Stückzahlen die Preise von der Tendenz auch kleiner. Die 8 Bitter mit 32 kB (oder gar mehr) sind dagegen eher Abwegig weil oft teurer (viel speicher beim eher groben Prozess kostet halt).
Für die meisten Anwender - auch hier! - ist es völlig egal, ob der Chip 4, 8, 16, 32 oder 64 Bit hat. Kaum jemand nutzt die sich ergebenen Eigenschaften, weil erforderlich, aus. Die kleinen Bastelobjekte lassen sich mit allen gängigen uC lösen. Es geht also nur um den "Geschmack" des Einzelnen. Und über Geschmack läßt sich streiten, was wir bei den 8 vs 32 Threads immer wieder erleben. In der Industrie ist es ähnlich, nur gibt es andere Kriterien: bei Massenprodukten muss der Chip billig billig billig sein.
bloeder thread schrieb: > Für die meisten Anwender - auch hier! - ist es völlig egal, ob der > Chip > 4, 8, 16, 32 oder 64 Bit hat. Kaum jemand nutzt die sich ergebenen > Eigenschaften, weil erforderlich, aus. Na ja, bei 8bit und 20MHz kommt man bei rechenintensiveren Sachen (z.b. FFT) irgendwann an die Grenze.
Schreiber schrieb: > Na ja, bei 8bit und 20MHz kommt man bei rechenintensiveren Sachen (z.b. > FFT) irgendwann an die Grenze. da würde auch keiner Fragen wieso man noch 8 bitter nimmt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.