Extra uC für Bedienteil

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.

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.

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.

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ß

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.

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.

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.

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.

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.

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. ;-)

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?

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.

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 ;)

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.