Voraussetzungen eines µC um UART / I2C / ICSP zu können

[Thomas R. (redturtle)]

Hallo,

ich habe eine Liste von verwendeten Mikroprozessoren und möchte 
entscheiden können, ob ich die Prozessoren vereinheitlichen kann. Bei 
manchen wird I2C verwendet, bei anderen UART, und bei wenigen noch ICSP. 
Am besten wäre es, wenn nur noch ein Protokoll verwendet werden würde.
Welche Voraussetzungen müssen bei einem µC gegeben sein, um I2C  UART  
ICSP zu können? Ist jeder Controller geeignet für UART, oder gibt es 
Einschränkungen?

Ist es nicht im Prinzip so, dass der Controller bloß den 
Protokoll-typischen Spannungsbereich aushalten muss? Ob ein Kanal/Pin 
jetzt für Clock oder Daten zuständig ist, ist doch nebensächlich, weil 
doch programmiert werden kann, was an jedem Pin für ein Signal rausgeht, 
oder?

VG
Thomas

[Karl H. (kbuchegg)]

Thomas R. schrieb:

> Protokoll-typischen Spannungsbereich aushalten muss? Ob ein Kanal/Pin
> jetzt für Clock oder Daten zuständig ist, ist doch nebensächlich, weil
> doch programmiert werden kann, was an jedem Pin für ein Signal rausgeht,
> oder?

Jein.

Auch wenn es im Grunde korrekt ist, dass man zur Not auch all diese 
Dinge in Software nachbilden kann, ist es doch in der Praxis um ein 
gutes Stück einfacher, wenn der µC für die jeweilige Kommunikationsform 
entsprechende Hardware eingebaut hat. Alleine dadurch, dass man sich vom 
Problem eines korrekten Timings entkoppelt, spart man sich des öfteren 
einiges an Kopfkratzen.

Um ein (zugegeben etwas absurdes) Beispiel zu geben:
Im Prinzip kann eine Sekretärin in ein Telefon mit den richtigen 
Frequenzen reinpfeifen, um ein Fax zu übertragen. In der Praxis ist es 
aber sinnvoll, diese Tätigkeit der speziellen Hardware 'Fax-Gerät' zu 
überlassen, auch wenn dieses auch nichts anderes tut, als in die 
Telefonleitung reinzupfeifen. So gesehen wäre der kleinste gemeinsame 
Nenner um das Kommunikationsmedium FAX zu benutzen eine Telefonleitung 
und jemand der pfeift bzw. zuhört.

[Thomas R. (redturtle)]

Also ist es so, dass man dann das verwendet, was der Controller bereits 
hardwaretechnisch kann.

Mal angenommen, alle Protokolle können das, was sie erreichen sollen: 
Maschinen steuern und Daten an einen Slave senden. Dann würde man doch 
nach Eigenschaften wie
- Programmieraufwand / -komplexität
- Fehleranfälligkeit (Strecke <20 cm)
- Geschwindigkeit
gehen, oder?

Das spricht mMn zumindest für UART, weil es simpel ist und im Gegensatz 
zu I2C nicht nur mit halber Leistung arbeitet (Richtungswechsel)...

Wie groß ist der Aufwand, bei Tausch eines µC den Code von I2C auf UART 
oder andersherum umzuschreiben? Oder ist ISCP noch eine sinnvolle 
Alternative?

[Udo S. (urschmitt)]

Thomas R. schrieb:
> Wie groß ist der Aufwand, bei Tausch eines µC den Code von I2C auf UART
> oder andersherum umzuschreiben?

Das macht doch in den wenigsten Fällen Sinn. I2C ist ein Busprotokoll 
mit einem Master und mindestnes einem(vielen) Slave(s).
UART ist eine Point to Point Verbindung von 2 Teilnehmern und dafür voll 
duplex.

[Kaj (Gast)]

Udo Schmitt schrieb:
> UART ist eine Point to Point Verbindung von 2 Teilnehmern und dafür voll
> duplex.

Noch nie das ccTalk-Protokoll angeschaut, was? :P
http://www.craneps.com/en/files/download/1249

UART ist "einfach" nur ein Stueck Hardware (Universal Asynchronous 
serial Receiver and Transmitter).
Welches Protokoll (ob Point to Point oder ein Bus wie bei ccTalk) damit 
umgesetzt wird steht auf nem ganz anderen Papier.

Gruesse

[TX (Gast)]

Karl Heinz schrieb:
> Um ein (zugegeben etwas absurdes) Beispiel zu geben:
> Im Prinzip kann eine Sekretärin in ein Telefon mit den richtigen
> Frequenzen reinpfeifen, um ein Fax zu übertragen. In der Praxis ist es
> aber sinnvoll, diese Tätigkeit der speziellen Hardware 'Fax-Gerät' zu
> überlassen, auch wenn dieses auch nichts anderes tut, als in die
> Telefonleitung reinzupfeifen. So gesehen wäre der kleinste gemeinsame
> Nenner um das Kommunikationsmedium FAX zu benutzen eine Telefonleitung
> und jemand der pfeift bzw. zuhört.

Genial :)! Sehr schönes Beispiel!

[Udo S. (urschmitt)]

Kaj schrieb:
> Noch nie das ccTalk-Protokoll angeschaut, was? :P
> http://www.craneps.com/en/files/download/1249

Dann sage mir doch mal wieviele % der µCs deren UART-Schnittstelle (ist 
das für dich Erbsenzähler jetzt besser ausgedrückt, wie nennst du sie 
denn korrekt?) ein Bus protokoll nutzen.
Tatsache ist daß die serielle Schnittstelle typischerweise als das 
benutzt wird als das sie ursprünglich gedacht wurde nämlich als duplex 
Punkt zu Punkt Verbindung und zwar aus gutem Grund.
Man kann natürlich auch mit einem traktor zum Bäcker fahren.

Aber wenn du alles so viel besser weisst, warum antwortest du dann nicht 
Thomas R... ich bin gespannt.