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
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.
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?
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.
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
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!
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.
Bitte 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.