Mahlzeit, Ich mache mir grade Gedanken um die Verteilung der Aufgaben eines Projekts. Und zwar denk ich darüber nach die Hardware so aufzuteilen , dass das LCD + Bedieneinheit einen eigenen uC bekommt der dann ber Twi mit dem "Haupt-uC" kommuniziert. Da wollte ich interessehalber mal fragen wie ihr das so Handhabt. Momentan besteht mein Haupt-uC aus einem atmega 8 und die Pins sind zu 70% belegt. Mit einem extra uC für die Bedieneinheit würd ich mir ja reserven zurückhalten.
>Da wollte ich interessehalber mal fragen wie ihr das so Handhabt.
Ich nehme EINEN grösseren Controller.
Gralor schrieb: > Und zwar denk ich darüber nach die Hardware so aufzuteilen , dass das > LCD + Bedieneinheit einen eigenen uC bekommt der dann ber Twi mit dem > "Haupt-uC" kommuniziert. Das würde ich auch so machen, wobei TWI Geschmackssache ist.
Die Frage ist, ob es evtl. nicht günstiger ist, UART zu nehmen, um dedizierte Master und Slaves zu vermeiden. Ein TWI Slave kann zwar die Aufmerksamkeit des Masters anfordern, das ist aber komplizierter als z.B. UART, bei der die MC einfach per TXD und RXD verbunden sind. So kann der 'Hauptrechner' dem Bedienteil Dinge senden und das Bedienteil dem Hauptrechner, ohne grosse Klimmzüge zu machen. UART lässt sich evtl. auch an längere Leitungen anpassen.
:
Bearbeitet durch User
Gralor schrieb: > Und zwar denk ich darüber nach die Hardware so aufzuteilen , dass das > LCD + Bedieneinheit einen eigenen uC bekommt der dann ber Twi mit dem > "Haupt-uC" kommuniziert. Das macht nur dann irgendeinen Sinn, wenn "Haupt-µC" und Bedienteil aus irgendeinem Grund räumlich getrennt sein müssen, was allerdings je nach konkretem Projekt durchaus mal vorkommen kann. Ansonsten nimmt man einfach einen größeren Controller mit entsprechend mehr Pins.
Noch was. TWI hat von Hause aus erstmal keinerlei Fehlererkennung, geschweige denn Korrektur. Du kannst dir also in gestörter Umgebung schnell mal einen Fehlimpuls einfangen, der spassige Sachen auf dem TWI verursacht. Wenn du bei UART bspw. eine Prüfsumme oder ganz simpel Parity benutzt, ist das schon deutlich sicherer.
Ich verschalte grundsätzlich nur 14-polige miteinander, da kann ich monatelang an der Kommunikation tüfteln, lerne immer noch etwas dazu und erlebe so manche Überraschung - Spaß ohne Ende.
@ Matthias Irgendwie mit Th. Stilla verwandt? Der hat auch immer dediziert und dezidiert verwechselt.
Ja das ist meistens sinnvoll, weil Du damit a) weniger Drähte zum Bedienteil brauchst und b) damit eine saubere Schnittstelle machen kannst TWI, sprich I²C ist eine gute Lösung für den Fall dass beide Teile im gleichen Gehäuse sind, für externe Leitungen ist das nicht wirklich geeignet. Ich würde das per UART machen, mit einem einfachen textbasierten Protokoll. Dann kannst Du auch, wenn eine der beiden Komponenten noch nicht fertig ist, die jeweils andere per simplen Terminalprogramm testen. Plus ein solches Protokoll, welches zum Beispiel mit einem Buchstaben beginnt und dann durch Leerzeichen getrennte Zahlen als Daten hat, gefolgt von einem Wagenrücklauf, synchronisiert sich sehr einfach von selbst und enthält selbst genügend Redundanz um Fehler mit hoher Wahrscheinlichkeit selbst zu finden. Plus man kann ja noch das Paritätsbit einschalten. Übrigens ging man früher oft einen anderen Weg und hat den Mikrocontroller gerne in das Bedienteil gelegt. Von da aus ging dann ein Bus und Einzelleitungen zur Hardware.
Christian Berger schrieb: > Ich würde das per UART machen, mit einem einfachen textbasierten > Protokoll. Dann kannst Du auch, wenn eine der beiden Komponenten noch > nicht fertig ist, die jeweils andere per simplen Terminalprogramm > testen. Zum einen ist per UART sehr sinnvoll, sobald ein bißchen mehr 'Strippe' zwischen Bedienteil und Steuerung liegt, und zum anderen entlastet das eigenständige Bedienteil die Steuerung. Per Sende-Puffer muß die Steuerung nicht auf die Ausgaben warten. Ferner kann das Bedienteil auch separat weiterentwickelt werden: mehr Taster+Schalter, andere Displays (erst LCD, später TFT), ...
Vielen Dank für eure Antworten. über UART habe ich auch schon nachgedacht, bin aber zu dem Entschluss gekommen das ganze doch über TWI zu machen, da ich bereits zwei Bauteil auf der Platte habe die ebenfalls mit TWI/I2C angesprochen werden. Wenn ich jetzt nuch UART dazu nehme dann verbrauche ich ja wieder zwei Pins ;-) Ja TWI ist etwas umständlicher was die erregung der Aufmerksamkeit des Masters angeht, aber entweder reglel ich das über ein Ausgang zu dem INT2-Pin des Masters (eher nicht) oder aber kann ich das TWI ja auch als MultiMaster laufen lassen. Das Bedienteil würde auch nur dann Daten an en Haupt-uC senden wenn sich etwas in den Grundeinstellungen geändert hat. (Logisch ;-) ) Aber herrlich zu sehen wie unterschiedlich dies bewerkstelligt wird . :-) Gruß
>Das Bedienteil würde auch nur dann Daten an en Haupt-uC senden wenn sich >etwas in den Grundeinstellungen geändert hat. Ich würde es bei allen Änderungen irgendwelcher Einstellungen senden lassen, nicht nur bei Änderungen der Grundeinstellungen. Ansonsten: Der Empfehlung einiger anderer Leute hier, das Problem möglichst mit einem (der Aufgabe gewachsenen) Controller zu lösen, kann ich mich nur anschließen.
>aber kann ich das TWI ja auch als >MultiMaster laufen lassen. Ja, mach mal.
LostInMusic schrieb: > Ansonsten: Der Empfehlung einiger anderer Leute hier, das Problem > möglichst mit einem (der Aufgabe gewachsenen) Controller zu lösen, > kann ich mich nur anschließen. Es kommt immer drauf an ... Ein aufgeteiltes System kann nicht nur die Aufgaben trennen, sondern so kann der Controller der das Display steuert auch eine gewisse Redundanz darstellen und somit das Hauptsystem überwachen. Beispiel: Angenommen ich möchte für eine Brutkammer die Heizung steuern. Hier kann ich nicht nur die Bedienung und das Display steuern, sondern auch batteriegepuffert das eigentliche Steuerungssystem überwachen. Sicher, auf Stromausfall kann ich das auch mit einem µC, aber so kann ich das gesamte Steuerungssystem zusätzlich mit einem Sicherheitsrechner versehen. In allen unseren Fahrzeugen ist auch ein Überwachungsrechner eingebaut und das hat sicher einen Sinn.
Tatsächlich mache ich das ab und an ähnlich, also Bedienteil mit LCD einen eigenen Controller spenden. Das liegt aber daran, dass ich mir das standardisiert habe und ich mittels UART so idR meine anderen Controller ganz einfach auslesen kann bzw. Werte ändern kann. Normaler Weise jedoch verwende auch ich nur einen Controller, der dann alles macht. Ist der Atmega8 zu klein wird halt der nächst größere in Betracht gezogen.
holger schrieb: >>aber kann ich das TWI ja auch als >>MultiMaster laufen lassen. > > Ja, mach mal. Dem schliesse ich mich an. Wieso fragst du eigentlich, wenn du keine gutgemeinten Ratschläge hören willst? I²C im Auto ist Blödsinn. Dann nimm lieber gleich CAN. Christian O. schrieb: > Wenn ich jetzt nuch UART dazu nehme dann verbrauche ich ja wieder zwei > Pins ;-) Na und? Für gesparte Pins gibts kein Geld zurück.
:
Bearbeitet durch User
Christian O. schrieb: > Aber herrlich zu sehen wie unterschiedlich dies bewerkstelligt wird . Das liegt aber auch daran, dass Du nicht sagst, wieweit Bedienteil und restliche Elektronik voneinander entfernt liegen. Zwischen 5 cm und 5 m besteht ein erheblicher Unterschied. Zu TWI: Dir ist schon bewußt, dass sich dieser Bus auch aufhängen kann?
Wer Ende 2014 für ein neues Projekt, offensichtlich im Hobbybereich, den ATmega8 verwendet, hat sich schlecht informiert und vorbereitet; er wird auf dem jetzt eingeschlagenen Weg sein blaues Wunder erleben.
Kommt vor allem auf die Prozessorlast an, wenn dein display 50 msl pro Sekunde refresht werden muss, wuerde ich einen extra Kontroller nehmen, wenn nur 3 leds blinken, reicht einer.
Guten Morgen allerseits. Bleibt mal locker jungs ich habe eine Frage aus interesse daran wie andere es handhaben gestellt. Ich weiss dass ich bei weitem kein Profi bin und ich bin auch noch nicht ganz in der Lage den späteren Aufwand einzuschätzen. Dies ist das erste Projekt dass ich mache welches überhaupt ein Bus-System verwendet. Aber ich denke mir, dass ich die Erfahrungen noch sammeln werde. Um die gestellte Frage zu beantworten: Bedieneinheit und Steuerung sollen sich im gleichen Gehäuse befinden. Nicht weit voneinander weg. @LostinMusic Ja stimmt es ist doch besser alle änderungen der Einstellungen der Steuerung mitzuteilen. @Mathias Sch. Ich frage weil es mich interessierte wie andere es machen. Es gab hier ja nun argumente in beide richtungen. Ok bei der Sache mit dem TWI sind sich eig. alle einig, da werde ich noch drüber nachdenken. Da ich ja jetzt aufteilen möchte fallen ja die Datenleitungen zu Bedienteil und LCD weg und da tun mir die beiden extra Pins nicht weh, das stimmt. :-D Geld zurück für nicht gebrauchte pins wäre seltsam aber ein guter Service.. spass beiseite.. momentan geht es mir nur darum ein paar reserven zu haben, da ich bestimmt nochmal die ein oder andere Erweiterung hinzufügen möchte. (Was allerdings auch wieder für einen grösseren uC spricht.) @Ghostbuster Magst du deine Aussage nochmal erklären? Wieso ist ein Atmega8 im Jahr 2014 nicht mehr Zeitgemäß wenn er die gewünschte Arbeit bewerkstelligen kann?
Ghostbuster schrieb: > Wer Ende 2014 für ein neues Projekt, offensichtlich im Hobbybereich, den > ATmega8 verwendet, hat sich schlecht informiert und vorbereitet; er wird > auf dem jetzt eingeschlagenen Weg sein blaues Wunder erleben. Das muss man einfach ganz zitieren! Es liegt offensichtlich (neben dem ollen Ding) noch ein ganz anderes Problem vor. Der TO hat ein Projekt begonnen, dass ihm entweder über den Kopf wächst, weil er immer mehr rein gepackt hat oder er hat es schon von Anfang an nicht richtig geplant. Zunächst muss man sich doch Gedanken über Ein- und Ausgaben machen und dann über die Bauteile selbst. Wie kommunizieren sie oder sollen sie kommunizieren? Aber das ist so ein typischer Anfängerfehler und ich mache auch heute noch (auch in 10 Jahren werde ich mich wohl noch als Anfänger sehen) manchmal einfach drauf los. Nur bei größeren Sachen plane ich. Das habe ich alles hier im Forum gelernt, mal mit gezielten Fragen und häufig durch mitlesen. @TO Also lieber TO, noch mal von vorn und alles genau planen. Es dürfen auch ein paar Pins über bleiben, falls irgendwann doch mal ein alternativer Sensor benutzt werden soll, der dann ein Pin mehr braucht. Immer gleich mit raus führen.
Ghostbuster schrieb: > Wer Ende 2014 für ein neues Projekt, offensichtlich im > Hobbybereich, den > ATmega8 verwendet, hat sich schlecht informiert und vorbereitet; er wird > auf dem jetzt eingeschlagenen Weg sein blaues Wunder erleben. Naja, sooo schlecht ist der Atmega8 nun auch wieder nicht und viele im Internet zu findende Tutorials orientieren sich an diesem. Ich denke aber auch, dass nicht der Atmega8 das Problem des TOs ist, es ist wohl eher, wie schon gesagt wurde, die Planung des Projektes das Problem. Aber das ist ein ganz normaler, typischer, "Anfängerfehler". Letztes Wort in Anführungszeichen da dieser Fehler auch von durchaus erfahrenen Entwicklern begangen wird, vor allem wenn man Betriebsblind wird "Ach das Problem, das mach ich mal eben mit…". Schon sehr oft erlebt.
>wenn er die gewünschte Arbeit bewerkstelligen kann?
Kann er eben nicht, sonst müssten jetzt nicht Pins gespart werden.
Ich hätte das Beste genommen, was ich mir (schmerzfrei) leisten kann,
in diesem Fall also wohl den 1284; die ca. 4 EUR mehr (Reichelt) machen
sich in kürzester Zeit bezahlt.
Ghostbuster schrieb: > Wer Ende 2014 für ein neues Projekt, offensichtlich im Hobbybereich, den > ATmega8 verwendet, hat sich schlecht informiert und vorbereitet; er wird > auf dem jetzt eingeschlagenen Weg sein blaues Wunder erleben. Ghostbuster schrieb: > Ich hätte das Beste genommen, was ich mir (schmerzfrei) leisten kann, > in diesem Fall also wohl den 1284; die ca. 4 EUR mehr (Reichelt) machen > sich in kürzester Zeit bezahlt. Soll man auf diese unqualifizierten Äußerungen noch eingehen? Wenn ja, dann nur mit einem ARM Cortex-M4. Ohne FPU bekomme ich beim Programmieren Atemnot ;-)
> Wenn ja, dann nur mit einem ARM Cortex-M4. > Ohne FPU bekomme ich beim Programmieren Atemnot >Soll man auf diese unqualifizierten Äußerungen noch eingehen? Ganz meine Meinung.
Michael Köhler schrieb: > Naja, sooo schlecht ist der Atmega8 nun auch wieder nicht und viele im > Internet zu findende Tutorials orientieren sich an diesem. Die Tutorials orientieren sich am ATmega8, weil sie genau so alt sind wie der ATmega8, nicht weil der ATmega8 - aus heutiger Sicht - so toll ist. Keiner hat Zeit und Lust, ein ausgewachsenes Tutorial auf z.B. ATmega48/88/168/328 umzuschreiben. Der Einsteiger bleibt, verständlicherweise, erst mal bei dem μC, der ihm durch das Tutorial vertraut ist.
Konrad S. schrieb: > Der Einsteiger bleibt, > verständlicherweise, erst mal bei dem μC, der ihm durch das Tutorial > vertraut ist. Das ist ja alles richtig, aber dann braucht man auch nicht über "verteilte Systeme" nach zu denken, wenn man nicht mal den Umstieg auf ein 328 schafft. Es gibt extra eine Appnote, die die Unterschiede zwischen dem 8ter und den neueren µC's behandeln.
Diese Auftrennung in Bedienteil, Anzeigeteil und eigentliche Steuerung
hat einige Vorteile:
Auftrennung des Projekts in übersehbare und kontrollierbare Teile. Da
kommt es dann nicht vor, dass mehrere interrupts um die Wette
verschachtelt sind. Ein eventueller Fehler lässt sich da auch leichter
auf eine der Baugruppen eingrenzen.
Verwendbarkeit einzelner Baugruppen für mehrere Projekte. Meine 3-1/2
stellige Anzeige mit I2C Schnittstelle ist z.B. mehrmals anwendbar und
ist relativ leicht bei einem andren Projekt einsetzbar. Ein PC hat doch
auch eine getrennte Tastatur und andre getrennte Peripherieeinheiten.
Bei zeitkritischen Projekten, z.B. einem DDS-Generator wird der
zeitkritische Teil (DDS-Schleife) von Teilprogrammen entlastet. Die den
Ablauf störenden ints werden auf externe Einheiten verlagert.
Eine Auftrennung in Leistungsteil und Steuerungsteil ist bei Steuerungen
eigentlich Standardtechnik.
Bei Serienfertigung wäre die Aufteilung unwirtschaftlich, für
Einzelarbeit erhöht die Aufteilung die Zahl der Erfolgserlebnisse ("Die
Anzeige geht schon") und erleichtert spätere updates.
:
Bearbeitet durch User
F. Fo schrieb: > Das ist ja alles richtig, aber dann braucht man auch nicht über > "verteilte Systeme" nach zu denken, wenn man nicht mal den Umstieg auf > ein 328 schafft. Kommt Zeit, kommt ATmega 328. ;-) > Es gibt extra eine Appnote, die die Unterschiede zwischen dem 8ter und > den neueren µC's behandeln. Die hier? AVR094: Replacing ATmega8 by ATmega88 httw://www.atmel.com/images/doc2553.pdf Peter R. schrieb: > Da > kommt es dann nicht vor, dass mehrere interrupts um die Wette > verschachtelt sind. Die Kommunikation wird auch mit Interrupts laufen. Was aber, meiner Meinung nach, kein Argument gegen Aufteilung ist. (Allerdings auch keines dafür ;-)
Konrad S. schrieb: > Die hier? > AVR094: Replacing ATmega8 by ATmega88 > httw://www.atmel.com/images/doc2553.pdf Die war es wohl. Hab ich auch noch irgendwo auf dem Rechner. Mein Sohn brauchte auch den ATmega8 in der Schule. Habe noch ein paar von den Dingern, aber werde die sicher nie benutzen. Für das aufteilen bin ich auch, weil es gleich mehrere Vorteile (im privaten Bereich) hat. Peter R. schrieb: > Verwendbarkeit einzelner Baugruppen für mehrere Projekte. Das wäre nur einer der Vorteile. Im industriellen Bereich, dessen bin ich mir sicher, wird es eh darauf hinaus laufen immer spezialisiertere µC's zu bauen/benutzen und die Aufgaben zu verteilen. Aber das hier zu erläutern und meine Gründe für diese Annahme zu nennen, würde den Rahmen diesen Sonntages sprengen.
> dann braucht man auch nicht über "verteilte Systeme" nach zu denken, wenn > man nicht mal den Umstieg auf ein 328 schafft. So ist es. Wobei anzumerken bleibt, dass ein 28-poliger die Ausgangsbegründung, dass die Pins knapp werden, ja nicht auflöst. Ein Umstieg aber von ATmega8 auf einen, nur als Beispiel, 1284 ist geradezu ein Kinderspiel verglichen mit > TWI als MultiMaster. Wenn der TO allerdings Letzteres üben will, dann nur zu. Ich wünsche ihm ehrlich von ganzem Herzen viel Glück (er wird es brauchen können).
F. Fo schrieb: > Für das aufteilen bin ich auch, weil es gleich mehrere Vorteile (im > privaten Bereich) hat. Lustigerweise habe ich auch gerade so eine "Aufteilung": Ein ATtiny2313 steuert eine vierstellige LED-Siebensegmentanzeige. Der µC ist dabei mit eine der kostengünstigsten Lösungen, weil der Bauteilebedarf sehr gering ist. Als Bonus gibt es noch jede Menge "Dekodier-Intelligenz" und Komfortfunktionen für die Anzeige, z.B. Helligkeitsstufen, Blinken, Cursor und was noch so in die 2kByte 'reingeht.
Konrad S. schrieb: > Die Tutorials orientieren sich am ATmega8, weil sie genau so alt sind > wie der ATmega8, nicht weil der ATmega8 - aus heutiger Sicht - so toll > ist. Keiner hat Zeit und Lust, ein ausgewachsenes Tutorial auf z.B. > ATmega48/88/168/328 umzuschreiben. Der Einsteiger bleibt, > verständlicherweise, erst mal bei dem μC, der ihm durch das Tutorial > vertraut ist. Dann bin ich doch mal auf die Erklärung gespannt warum der Atmega8 immer noch nicht abgekündigt ist von Atmel.
Wegen der Tutorials? ;-) Spaß beiseite. Solange noch Geld mit bestehendem verdient wird, was hier wohl der Fall ist, lässt man es laufen.
Konrad S. schrieb: > Die Kommunikation wird auch mit Interrupts laufen. Was aber, meiner > Meinung nach, kein Argument gegen Aufteilung ist. Das ist Geschmackssache und manchmal auch eine Frage der Anforderungen. Wenn z.B. das Bedienteil LED oder Displays per Multiplexing bedient, ist es besser, so etwas in Interrupts zu machen und die (langsame) Kommunikation in der Hauptschleife, damit die Anzeige nicht flackert. Das hängt aber von vielen Faktoren und vor allem der gewählten Hardware Strategie ab.
F. Fo schrieb: > Spaß beiseite. Solange noch Geld mit bestehendem verdient wird, was hier > wohl der Fall ist, lässt man es laufen. Eben, und in vielen Fällen reicht ja auch der Atmega8. Deshalb ist es schlicht Quatsch zu sagen, der Atmega8 ist veraltet.
Nein Michael, das kann man durchaus sagen, denn er hat ja seine Nachfolger. Die haben auch alle etwas mehr drin. Natürlich funktioniert er weiterhin. Die Empfehlung ging ja in die Richtung, dass der TO sein Konzept nochmal neu planen sollte und dabei drüber nachdenken soll, ob er noch diesen alten µC einsetzen will, wo es kompatible Typen (die auch billiger sind, ganz nebenbei), die wesentlich moderner sind, gibt.
Gralor schrieb: > Da wollte ich interessehalber mal fragen wie ihr das so Handhabt. Ich nutze auch teils verteilte uC. Hab z.B. einen Midi-Controller gebaut, der einen separaten uC nutzt, um die 8 Encoder auszuwerten. Der Haupt-uC ist auch via TWI angebunden. Das Abfragen der Werte funktioniert einwandfrei, und der Controller ist ohne großen Aufwand auf 16 und mehr Encoder erweiterbar. Für die paar €, die ein uC kostet, mache ich mir keinen Knoten ins Hirn, um das alles in einem uC unterzubringen.
F. Fo schrieb: > Nein Michael, das kann man durchaus sagen, denn er hat ja seine > Nachfolger. Die haben auch alle etwas mehr drin. Aber wenn ich das nicht brauche für meine Anwendung, was bringt es mir dann? Der Atmega8 hat auch heute noch seine Berechtigung, klar gibt es Nachfolger und die sind auch nicht schlecht, können auch mehr als der Atmega8. Das heißt aber nicht, dass der Atmega8 veraltet ist.
Mal ganz im Vertrauen, Michael, bist du mit dem MEGA8 verheiratet? Es scheint eine Hassliebe zu sein, denn der erste, der den Begriff veraltet benutzte, warst du selbst.
Michael Köhler schrieb: > Das heißt aber nicht, dass der Atmega8 veraltet ist. Er ist veraltet. Ein Atmega88 kann alles, was auch ein ATmega8 kann. Und er kann noch einiges mehr - bei Pinkompatibilität. Okay, Du könntest jetzt sagen: "Brauch ich nicht". Aber auch für die "Brauch-ich-nicht"-Argumentierer hab ich was: Ein ATmega88 braucht weniger Strom. Warum braucht der ATmega8 mehr Strom? Weil er veraltet ist. ;-)
:
Bearbeitet durch Moderator
Ich glaube das eigentliche Thema geht allmählich verloren. :-D Mal davon abgesehen ob der Atmega8 veraltet ist oder nicht (letzendlich ja jedem sein Bier) geht es doch eigentlich darum wie die meisten es handhaben wenn die Anwendung etwas grösser wird. Entweder nimmt man dann einen größeren uC oder man verteilt die Aufgaben auf mehrere uCs. Ich persönlich bin ein Freund von aufteilen der Aufgaben auf mehrere Komponente/Module (was wohl aber daran geschuldet ist dass ich aus der Industrie komme).
STRG F schrieb: > Mal ganz im Vertrauen, Michael, bist du mit dem MEGA8 verheiratet? Es > scheint eine Hassliebe zu sein, denn der erste, der den Begriff veraltet > benutzte, warst du selbst. Nein bin ich nicht. Aber ich hab kein Problem damit das Kind beim Namen zu nennen ;) Frank M. schrieb: > Er ist veraltet. Ein Atmega88 kann alles, was auch ein ATmega8 kann. > Und er kann noch einiges mehr - bei Pinkompatibilität. Und da stellt sich die Frage warum Atmel den Atmega8 noch heute baut? Könnte ja auch sagen, dass der Atmega8 nicht mehr gebaut wird und als Nachfolger der Atmega88 und Co angeboten wird. Also, warum hier zwei Produkte ins Rennen schicken, von dem eines veraltet ist?
Pinkompatibilität bedeutet aber nicht codekompatibilität geschweige denn kompatible hexfiles.... Für neuen code sollte man also die neuen nehmen. Aber oft will man -sowohl im privaten als auch im kommerziellen bereich- nur ein bestehendes hexfile laden, da macht der alte sinn!
Michael Köhler schrieb: > Und da stellt sich die Frage warum Atmel den Atmega8 noch heute baut? 2 Gründe: a) "Ersatzteil" für bestehende Alt-Installationen. b) Angebot vorhalten für die Michaels auf dieser Welt, die sich von alten Zöpfen einfach nicht lösen können bzw. wollen. Und davon gibt es beliebig viele.
c) für solche wie mich Seit neun Jahren verwende ich für eine Kleinstserie den ATmega16, und ich werde den Teufel tun, auch nur das Geringste daran zu ändern, solange für den keine Liebhaberpreise verlangt werden - "never change a winning team", und sei der Aufwand noch so klein. Für eine Neuentwicklung aber? - Das ist eine ganz andere Frage.
Im Übrigen ist das hier, wie man früher sagte, "ein Streit um Kaisers Bart."
Frank M. schrieb: > b) Angebot vorhalten für die Michaels auf dieser Welt, die sich von > alten Zöpfen einfach nicht lösen können bzw. wollen. Und davon > gibt es beliebig viele. Aber was hat Atmel davon? Gibt genug Beispiel auf der Welt wo das nicht gemacht wird. Atmel könnte sich schlicht hinstellen und sagen "Ab heute gibts keinen Atmega8 mehr sondern nur noch den Atmega88." Macht Atmel aber nicht und ich glaube nicht, dass Atmel das wegen der Kundenbindung nicht macht. Nur mal so nebenbei: Ich hab noch nie einen Atmega8 irgendwo eingebaut. Also nicht so vorschnell Dinge implizieren. Mein erster AVR war ein Atmega88PA, zur Zeit spiel ich mit dem Atmega328 und Atmega32 privat daheim ;)
Jetzt bin ich aber neugierig: wenn Sie ohnehin nur mit den neueren Typen arbeiten, warum kaprizieren Sie sich hier so auf den ATmega8? Um die Diskussion zu beleben?
Wo kapriziere ich denn? Ich frage doch nur warum Atmel den Atmega8 weiterhin im Programm hält wenn doch z.B. der Atmega88 viel besser ist? Und meine Meinung ist halt nur, dass ich denke der Atmega8 hat seine Daseinsberechtigung auch noch heute da er weiterhin von Atmel produziert wird.
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.