I2C-Bus, analog <-> I2C

Ich stell zurzeit viele Fragen, weil ich als Anfänger noch ziemlich orientierungslos bin, was den richtigen Ansatz für mein Projekt betrifft. Ich möchte gern über folgenden Gedanken diskutieren und herausfinden, ob das mit akzeptablem Aufwand machbar ist. Sinn darin ist auch, etwas über Elektronik zu lernen.

Ich möchte gerne den PC per USB als Controller nutzen, damit ich mit den Ressourcen erstmal auf der sicheren Seite bin. Sämtliche angeschlossene Roboterkomponenten sollen über einen I2C-Bus laufen, konkret Servos und Sensoren. So könnte man die Anwendung beliebig und einfach erweitern.

Was wäre dafür eine geeignete Hardware, also das Interface USB <-> I2C?

Macht dieses Konzept Sinn, oder ist I2C zu langsam für max. 100 Komponenten, die alle irgendwas auf den Bus schreiben bzw. zur "gleichen" Zeit abgefragt werden?

Falls das alles kein Problem darstellt, ist eigentlich nur noch eine Frage offen. Da man auf dem Bus nur digital arbeiten kann, müssten Analogauswertungen in digitale Signale umgewandelt werden, also jeder analoge Sensor braucht eine eigene Elektronik, um am Bus teilnehmen zu können. Die Komponenten brauchen dann auch eindeutige IDs usw. Welches Tutorial könnt ihr mir empfehlen (auch Buch), um sowas zu basteln?

So far,

Ben

Die umsetzung USB-I2C sollte mit einem FT2232 gehen, wenn am PC die richte Software hat. Allerdings sind die FT.... micht gerade anfängerfreundlich zu löten. Das trift leider auf die meisten USB Chips zu.
Die einfache alternative einen fertigen USB-RS232 Converter dazwischen zu nehmen.

Als rs232-i2C eigent sich dann eine µC. Der kann dann auber auch gleich ein paar servos und den AD wandler mit erledigen. Erst wenn man mehr braucht sollte man die am i2C haben.

Ich denke du setzt die Ansprüche etwas zu hoch an.

Zumindest verstehe ich nicht wieso du einen Bus für max. 100(!!) Komponenten auslegen willst? Was ergibt das noch für einen Sinn? 3,4,5 Komponenten am I2C-Bus sind Okay. Meinetwegen auch noch 10, aber alles darüber ist in den meisten Fällen ein Fehldesign des Systems.

Diesen FT-irgendwas werd ich mir anschauen. Ich habe bisher nur erfolgreich Conradbausätze zusammengelötet, also ein bisschen Erfahrung ist schon da. Was ich nicht kann, lern ich eben :-)

Vom mC will ich weg, denn langfristig werden mir da die Ressourcen zu knapp, und es ist relativ umständlich zu programmieren. Ich will von Anfang an was generisches aufbauen, damit mich das später nicht mehr belastet und von der eigentlichen Problematik abhält. Ich würd gern wissen, ob es wie beschrieben Sinn macht und umsetzbar ist. Falls ja, würd ich sogar einen Fachkundigen engagieren, um mir die eine oder andere Schaltung dazu zu bauen.

Warum ist I2C nicht geeignet?
Ich hab mir die Spezifikation durchgelesen und würde behaupten, das ist sogar sehr gut geeignet. Theoretisch lassen sich damit 10Bit adressieren, also weit mehr als 100 Slaves. Die Geschwindigkeit ist auch enorm, wobei ich das alles nur als Laie beurteilen kann.

Was wäre denn aus deiner Sicht die bessere Methode?

Auch ne Nachteule? ;-)

So doll ist die Geschwindigkeit nicht, vor allem wenn da mehr Geräte dran hängen geht dan nicht mehr die volle Geschwindigkeit. Wie Schon gesagt, viel mehr als 10 macht selten Sinn, oft hat man weniger. Auch mit I2C muß man das auch nocht irgendwie Programmieren. Gerade Echtzeit Sachen gehen da am PC eher schwerer als mit einem µC.

Wenn man schon so viele Geräte zusammen am PC haben will, dann schon besser auf USB oder LAN Basis. Wobei USB mit so viel Mäusen auch schon mal Probleme machen kann....

Mit I2C lassen sich zwar sehr viele Geräte anschließen, das stimmt...
Aber mir stellt sich die Frage in wie weit diese vielen Geräte überhaupt Sinn machen...

Man kann natürlich 10 I2C-A/D-Wandler, 3 I2C-EEPROMs und nochmal 5 I2C-Servosteuerungen an einen Bus hängen. Man könnte das aber genausogut mit einem einzigen Microcontroller lösen.
Und genau da liegt der Punkt auf den ich raus will.
Wer so viele Geräte an einem Bus betreibt hat einen schweren Denkfehler im System. Dann hat man nämlich genau das oben beschriebene nicht beachtet.

Zitat:

---

Zitat von Besserwessi

So doll ist die Geschwindigkeit nicht, vor allem wenn da mehr Geräte dran hängen geht dan nicht mehr die volle Geschwindigkeit. Wie Schon gesagt, viel mehr als 10 macht selten Sinn, oft hat man weniger. Auch mit I2C muß man das auch nocht irgendwie Programmieren. Gerade Echtzeit Sachen gehen da am PC eher schwerer als mit einem µC.

---

Echtzeit brauche ich beim Controller nicht. Wenn ich z.b. PWM brauche, dann erzeuge ich das einfach dort, wo es benötigt wird, nämlich beim Servo. Per I2C will ich nur Stellkommandos schicken und Feedback bekommen. Das darf asynchron sein. Außerdem müsste ich im Falle von vielen Komponenten mit mehreren mC arbeiten, das ist mir dann wirklich zu umständlich.

Zitat:

---

Zitat von Besserwessi

Wenn man schon so viele Geräte zusammen am PC haben will, dann schon besser auf USB oder LAN Basis. Wobei USB mit so viel Mäusen auch schon mal Probleme machen kann....

---

LAN würde mir auch gefallen, aber m.E. ist das zuviel Overhead. Oder ist das so einfach wie I2C? Ich muss nur kurze Strecken überbrücken.

Eine Alternative wäre CAN. Allerdings kenne ich da den Aufwand auch nicht. Gibt's ein USB-CAN-Interface?

Zitat:

---

Zitat von Foooob

Man kann natürlich 10 I2C-A/D-Wandler, 3 I2C-EEPROMs und nochmal 5 I2C-Servosteuerungen an einen Bus hängen. Man könnte das aber genausogut mit einem einzigen Microcontroller lösen.
Und genau da liegt der Punkt auf den ich raus will.
Wer so viele Geräte an einem Bus betreibt hat einen schweren Denkfehler im System. Dann hat man nämlich genau das oben beschriebene nicht beachtet.

---

Was genau ist denn daran fehlerhaft? Es ist einfach eine andere Architektur in meinem Augen. Bei meiner Anwendung bräuchte ich dann mehrere mC, die sich auch noch untereinander verständigen müssten. Der PC erscheint mir als mC in diesem Fall am sinnvollsten.

Ich würde mich freuen, wenn du mir nochmal genauer erklären könntest, wo bei mir der Denkfehler liegt. Denn ich bin Anfänger auf dem Gebiet der Elektronik. Als Softwareentwickler sehe ich das als modulares System, für das ich jederzeit weitere Module/Plugins entwickeln und anschließen kann. Vielleicht ist auch einfach nur die Wahl des Bus' falsch?

Hi Ben,

Zitat:

---

Zitat von Normalo

... als Anfänger ... über folgenden Gedanken diskutieren ...

---

Zitat:

---

Zitat von Normalo

... also ein bisschen Erfahrung ist schon da ...

---

Darfs vielleicht ein bisschen mehr sein?

Zitat:

---

Zitat von Normalo

... Ich hab mir die Spezifikation durchgelesen und würde behaupten, das ist sogar sehr gut geeignet ...

---

Dann ist doch alles in Ordnung. Also hinsetzen und machen. Vielleicht sind die anderen blos zu ängstlich.

Zitat:

---

Zitat von Normalo

... Wenn ich z.b. PWM brauche, dann erzeuge ich das einfach dort, wo es benötigt wird, nämlich beim Servo ...

---

Zitat:

---

Zitat von Normalo

... Vom mC will ich weg, denn langfristig werden mir da die Ressourcen zu knapp, und es ist relativ umständlich zu programmieren ...

---

Das finde ich gut. Schreib mal bitte, wie Du das machst - wir sind hier sicher viele, die sehr lernbegierig sind. Und vielleicht gibt es bei irgendeinem noch unbekannten Lieferanten dieses schicke SPIC (self programming IC) von dem wir alle träumen.

Es gibt zwar eine Menge verschiedener Ics für I2C, aber die sind doch oft recht starr. Man hat zum Beispiel je IC einen sehr kleinen Addressbereich, kann also in der Regel höchstens 8 gleiche (oft sogar weniger) anschließen. Auch für das Beispiel Servo per PWM steuern wüßte ich keinen andenen passenden I2C Chip außer einem µC. Man wird also gerade wenn man I2C verwendet dazu übergehn müssen mehrere µC zu benutzen.

Die verlagerung des ganzen Progrmmes auf den PC hat auch probleme. Wenn esum die Hardwareansteuerung geht hilft einem das Betreibssystem eigentlich eher wenig, sondern kann eigentlich nur stören.

Hier weht ja ein ziemlich rauher Wind...
Zur Auswahl des Buses sind noch weitere Faktoren entscheidend, zB die Entfernung zwischen den Geräten. Mit I2C kommt man nur einige zig cm weit oder verliert Geschwindigkeit bzw. erhöht die Fehlerrate. Wenn Du mehr als hundert Komponenten hast könnte der Signallaufweg bereits zu weit sein. Erklär doch mal, was Du alles anschließen willst und ob zeitkritische Komponenten darunter sind. Denn dafür ist der PC ohnehin ungeeignet. Außerdem bringt er weitere Probleme mit sich...
I2C ist nicht wirklich schnell aber immerhin recht sicher. Wenn Du einen Master hast, der zeitunkitsche Komponenten abfragen soll, dann kann das gehen. Allerdings nur bei "kleinen" Entfernungen und wenn EMVRichtlinien berücksichtigt werden, sonst kann es schnell Probleme geben.
Bei so vielen Slaves ist es nahezuz wangsläufig, dass sie recht weit auseinander liegen. Dafür gibt es bessere Bussysteme wie zB CAN oder LIN oder sonstwas. Eine weitere Variante ist RS485. Die isst für weite Strecken und bis zu 128Teilnehmern, wenn ich nicht irre, aber leider recht langsam.
DIeses Thema ist sehr umfangreich und wenn Du etwas derart komplexes aufbauen willst, dann solltest Du Dich intensiv mit Bussystemen, Kommunikation, Mikrocontrollern und Schnittstellen auseinander setzen, denn hier im Forum hat kaum einer den Überblick über Deine gesamten Anforderungen und kann Dir somit wohl nur grobe Ratschläge geben.
Du brauchst also auch ADWandler. Es gibt solche mit unterschiedlichen seriellen Protokollen, auch I2C. Bevor Du sie benutzen kannst, musst Du jedem eine Adresse einprogrammieren, weil die eingestellte Standartadresse nicht mit den anderen 99kompatibel ist. Allerdings hat man nicht immer 10Bit zu Auswahl, was bereits Probleme erzeugen kann. Auch hier gilt wieder: EMV beachten!
Mit CAN oder Lin wird alles gleich wieder etwas komplizierter, weil es weniger eigenständige Komponenten gibt (zB ADCs). An einem CAN-Bus hängen normalerweise µCs, die dieses Protokoll verstehen. Du wirst also wahrscheinlich nicht um die µC Programmierung herumkommen.
Als Beispiel kannst Du Dir die Kommunikation im Auto ansehen. Da hängen teils über hundert µCs zusammen. Das ist dann übrigens kein Architektur- bzw Denkfehler, sondern geht ganz einfach nicht anders...
Gruß

ein i2c geht auch via druckerport

@oberallgeier
Ich erkenne in deinem Beitrag nur Sarkasmus, nichts themenspezifisch hilfreiches.

@Besserwessi
Das OS (Windows, Linux) muss ja nichts in Echtzeit produzieren, da das die einzelnen Komponenten selbst machen sollen. Sicher kann es passieren, dass das OS die ein oder andere Sekunde hängt und damit der Roboter stillsteht, aber das ist vernachlässigbar, sonst würden ressourcenlastige 3D-Spiele auch nicht sauber laufen. Abhilfe wäre aber durch ein Echtzeitlinux gegeben, falls es doch notwendig werden würde.

@Gock
Ich habe grob die Umsetzung eines großen humanoiden Roboters im geistigen Auge und will bei einem Arm anfangen, Schulter- und Ellenbogengelenk zuerst. D.h. es gibt erstmal einige Servos zu steuern, deren Position, Stromaufnahme etc. ich auslesen will. Vonnöten sind ein paar PWMs und A/D-Wandler, und natürlich die Software, die ein paar bestimmte Bewegungsprofile kennt und abspulen sowie auf Eingangssignale (z.b. erhöhte Stromaufnahme) reagieren kann.

Da ich aus Ressourcen- und Handhabungsgründen einen mC je Arm/Bein wählen würde, müssten diese Bewegungsprofile von einem weiteren mC gesteuert werden, der pausenlos den aktuellen Zustand aller Arme/Beine abfragt und reagiert.

Aus meiner Sicht, und soweit ich die Main-Unit 2.0 kenne, ist der mC für einen Arm schon ausgelastet, falls es überhaupt möglich ist, das mit einem mC zu machen. Dieser mC hat nur 2 PWM-Ausgänge. Andere mC haben mehr Power. Allerdings wären dann auch bei einem mC je Arm viele Ressourcen (Ports) ungenutzt.

Wie kann man denn die Kommunikation zwischen mC umsetzen?

Hab ich denn die Möglichkeit, AD-Wandler oder PWM-Generatoren mit I2C-Interface selbst zu basteln? Vielleicht existiert ja irgendwo ein Tutorial dafür. Ich habe leider keins gefunden.

Zitat:

---

Zitat von magic33

ein i2c geht auch via druckerport

---

Danke sehr :-) Allerdings mag ich bei USB bleiben, da die anderen üblichen Ports auf neueren Rechnern nicht mehr vorhanden sind.

usb to lpt 8,5euro reichelt
und den kann man dan steuern wie man will
4ports raus +8Datenports +4 ports in
sowie 1x Ack open drain für SPI

und das tollste
es gibt in allen sprachen C,asm,Basic,PYTHON eine unterstützung

Ich denke du wirst wohl für einige Gelenke immer einen µC brauchen der
die Steuerung des selbigen und die Kommunikation mit dem Master übernimmt. Da es sich bei deinem Projekt um eine sehr große Anzahl von Aktoren handelt werden da auch zwangsläufig Störungen auf dem I2C Bus die Folge sein. Ich würde da auch eher zu Can Bus raten da dieser dafür geradezu prädestiniert ist. Aber da Can -Controller Area Network- bedeutet das, das du um Controller nicht herumkommen wirst. Das hat aber auch seine Vorteile; wenn du erstmal ein Gelenk mit einem µC hinbekommen hast inklusive Software werden die restlichen ein Kinderspiel werden.
Die Master Steuerung würde bei diesem Lösungsvorschlag der PC darstellen da er das Can System Steuern kann. Ich kann dir aus Berufserfahrung sagen das Steuerungsprozesse in Idustriebetrieben und Anlagen immer über Bussysteme mit Controllern an den Endpunkten gelöst werden. Als andere Systeme fallen mir da noch Device Net, Ether Cat, Profibus, AS Interface, und Feldbus ein. Kannst ja mal schauen was die so für Vor und Nachteile haben. Aber so ein System selber zu entwickeln ist wirklich nicht ohne....

MfG

Neutro

Neutro

Die eingangs gestellte Frage lässt sich beantworten durch googlen nach "usb i2C".
Allerdings befürchte ich, dass Du für das Problem schon einen Schritt zu weit gegangen bist. Dass es sich dabei nicht um ein Anfängerprojekt handelt und Du durch dieses ziemlich komplexe Thema nicht nebenbei etwas über Elektronik lernst, sei mal dahin gestellt.
Du solltest Dir zu allererst im Klaren darüber sein, welche Funktionen Du überhaupt implementieren willst und von welchem Element diese ausgeführt werden sollen (vielleicht weißt Du das ja schon...).
Wird die Greifhand geregelt und was soll sie regeln? Der PC? Dann brauchst Du einen sehr schnellen Bus, der eventuell nur solche Regelsignale verarbeitet. Außerdem ist USB ungeeignet weil nicht echtzeitfähig, unabhängig von Windows oder Linux. Dafür brauchst Du eine Controllerkarte im Rechner. Deren Leistungsfähigkeit legt die meisten Dinge festgelegt.
Willst Du nur steuern, dann wird das relativ diletantisch aussehen, vor allem, wenn das Ding mal laufen soll...
Wenn Du in jedes Gliedmaß einen µC einbauen willst, warum reicht es dann nicht, jeden µC an den Bus zu hängen und die Sensoren dann an diesen sternförmig? Und das sollen dann immernoch 100 sein?
Welche Aufgaben sollen diese übernehmen? Nur Daten auf Abfrage weiterleiten? Wieviele Daten kommen da zusammen? Wie groß ist die Regelfrequenz, wie hoch die Auflösung? Wiegroß also der Traffic auf dem Bus? Wie groß ist die maximale Zeitdilatanz?
Kann man den Traffic verringern? Benutzt man lieber 2 Busse, einen für Regelungsdaten und den anderen für Steuerungen?
Oder wilst Du nur eine ganz einfache Steuerung, die die Hand öffnen und schließen kann, vom PC gesteuert? Dann sollte man vielleicht nicht von humanoiden Roboter sprechen, denn ein solcher kann laufen.
Und wie geht man dieses Problem am besten klein an und baut darauf auf?
Sicherlich wird Dir hier geholfen werden, wenn man merkt, dass Du keine Luftschlösser bauen willst.
Gruß

Zitat:

---

Zitat von Normalo

Zitat:

---

Zitat von Foooob

Man kann natürlich 10 I2C-A/D-Wandler, 3 I2C-EEPROMs und nochmal 5 I2C-Servosteuerungen an einen Bus hängen. Man könnte das aber genausogut mit einem einzigen Microcontroller lösen.
Und genau da liegt der Punkt auf den ich raus will.
Wer so viele Geräte an einem Bus betreibt hat einen schweren Denkfehler im System. Dann hat man nämlich genau das oben beschriebene nicht beachtet.

---

Was genau ist denn daran fehlerhaft? Es ist einfach eine andere Architektur in meinem Augen. Bei meiner Anwendung bräuchte ich dann mehrere mC, die sich auch noch untereinander verständigen müssten. Der PC erscheint mir als mC in diesem Fall am sinnvollsten.

Ich würde mich freuen, wenn du mir nochmal genauer erklären könntest, wo bei mir der Denkfehler liegt. Denn ich bin Anfänger auf dem Gebiet der Elektronik. Als Softwareentwickler sehe ich das als modulares System, für das ich jederzeit weitere Module/Plugins entwickeln und anschließen kann. Vielleicht ist auch einfach nur die Wahl des Bus' falsch?

---

Ohne mir jetzt die anderen Posts durchgelesen zu haben (Doppelantwort...)...

Als Softwareentwickler verstehe ich dein Denken schon und kann es auch nachvollziehen. In der Software sind modulare Systeme erstrebenswert.

Hardwaremäßig sieht das (meiner Meinung nach) anders aus. Hier heist die Lösung meist System-on-a-chip. Also möglichst viel auf einen IC bringen. Dieser Trend ist nicht nur in der Industrie ein fester Bestandteil (man stelle sich einmal ein Handy mit 50 ICs vor...) sondern hat auch im Hobbybereich zahlreiche Vorteile:

• * Geringerer Platzverbrauch (~ Faktor 20)
  * Geringerer Stromverbrauch (~ Faktor 100)
  * Geringerer Schaltungsaufwand (über 30 Chips zu verdrahten ist enorm fehleranfällig)
  * Entlastung von Bussystemen
  * Weeeesentlich billiger (spezielle I2C-Chips sind oft nicht gerade preiswert)
  * usw.

Du kannst auch in einem IC eine Modularisierung der Komponenten erreichen bzw. das ist schon gegeben. Du kannst die Module wie ADC, EEPROM, PWM etc. ja völlig entkoppelt voneinander verwenden. GENAU das Selbe wie wenn du die Arbeit auf x ICs verteilst, nur mit den oben genannten Vorteilen.
Ein µC macht dann einfach die Arbeit von x diskreten ICs, hat jedoch nur eine I2C-Adresse. Da du das Protokoll ja völlig frei schreiben kannst kannst du auch bestimmen welche Befehle ADC, PWM, etc. de-/aktivieren.

Die Erweiterungsfähigkeit ist nach wie vor gegeben, sogar besser. Du hast dadurch mehr I2C Adressen zur Auswahl. Brauchst du ein spezielles Feature aktivierst du es einfach im µC, ist er bereits ausgelastet baust du den nächst-größeren der Familie ein und fertig.

So betrachtet ist auch mein Architekturvorschlag eine Aneinanderreihung von Controllern, die halt dann nur eine einzige Aufgabe bewältigen können.

Ich finde F4obs Darstellung macht's etwas einfacher für mein Verständnis. Das Problem bei den mir bekannten Controllern sehe ich in den für meinen Fall unzureichenden Schnittstellen. Die C-Control z.b. kann nur zwei Servos ansteuern, dafür hat sie zuviele Digitalports. Am Beispiel der Armsteuerung ist dieser Chip die falsche Wahl. Andere Controller sind ähnlich.

Ich bin beim Stöbern auf einen ausführlichen Beitrag zum CAN-Bus gestoßen. Ist ja das Gleiche in Grün, aber dann muss ich mir keine Sorgen mehr um die Zuverlässigkeit und Geschwindigkeit machen. Sicher ist das vor allem für einen Elektronikneuling schwieriger umzusetzen als I2C, wie Neutro sagt.

Ich grab halt immernoch in der Theorie rum und les Spezifikationen. Leider fehlt mir der richtige Einstiegspunkt. Tutorials zum Herstellen eines CAN-Geräts finde ich nicht im Netz. Vorschläge zu Büchern lassen sich leider schlecht beurteilen, bevor man sie kauft. Und ich glaube einfach, dass ich nicht weiterkomme, wenn ich mit analoger (?) Elektronik anfange. Einen Schaltplan kann ich mit wenig Unterstützung umsetzen. Vielleicht kennt ihr da was.

Zitat:

---

Zitat von Normalo

So betrachtet ist auch mein Architekturvorschlag eine Aneinanderreihung von Controllern, die halt dann nur eine einzige Aufgabe bewältigen können.

---

Wäre natürlich eine Möglichkeit. Aber das ist wie wenn man für jeden Zweck ein eigenes Auto kauft, anstatt gleich auf einen Combi/Allrounder zu greifen.

Zitat:

---

Zitat von Normalo

Ich finde F4obs Darstellung macht's etwas einfacher für mein Verständnis. Das Problem bei den mir bekannten Controllern sehe ich in den für meinen Fall unzureichenden Schnittstellen. Die C-Control z.b. kann nur zwei Servos ansteuern, dafür hat sie zuviele Digitalports.
Am Beispiel der Armsteuerung ist dieser Chip die falsche Wahl. Andere Controller sind ähnlich.

---

Mo-mo-ment...die C-Control ist kein Microcontroller, sondern ein Embedded System Device, was auf einem AVR aufbaut! Der AVR ist der eigentliche Mikrocontroller, und der meistert mehr als 2 Servos spielend.

Du hast auch noch nicht den µC genannt, den du einsetzen willst. Ein System aus mehreren 8 Bittern kann ich noch stellenweise nachvollziehen. Wenn du aber schon planst x Devices an einen Bus zu hängen würde ich gleich zu einem 32 Bitter greifen. Die sind derart leistungsstark, dass einer von denen i.d.R. ausreicht.

zur GLEICHZEITIG problematik lässt sich auch folgendes anmerken das der i2C Chip's interupt ausgänge besitzen die auch zur meldung herangezogen werden könnne
wir in der modell world betereiben 15.000 PCF8574 gleichzeitig
die mittels PCA95xx an diversen Pc's hängen und es Rappelt maximal 10mal pro tag bei ca 800-1000 zügen
einfache rechnung buss mit 300kbit/s
300.000 /32bit (4Byte) =>9000 Bausteine pro sec tehorie
in der praxis nicht mehrr als 500 anfragen pro sec an die bausteine
das reicht aber auch aus

bei der initialisierung des busses werden jede stunde ein speedtest mit 2eeprom am entferntesten ende ca 50m kabel gefahren und der speed festgelegt! warumm fragen müsst ihr die freaks die da fummeln!

Zitat:

---

Zitat von Foooob

Mo-mo-ment...die C-Control ist kein Microcontroller, sondern ein Embedded System Device, was auf einem AVR aufbaut! Der AVR ist der eigentliche Mikrocontroller, und der meistert mehr als 2 Servos spielend.

---

Hab ich richtig verstanden, dass man z.b. über die Digitalports PWM generieren kann, indem man den Wert zwischen 0 und 1 mit Hilfe eines Timers wechselt? So wären auf meinem mC (Main Unit 2.0) mind. 16 Servos ansteuerbar. Oder geht das nur über die DA-Ausgänge?

Ist dieser Timer als eigener Thread zu betrachten? Was passiert bei Ausführung von interrupt-basierendem zeitintensiven Programmteil; wird da der Timer pausiert?

Ich finde bei Conrad leider keine mC-Chips. Gesicht habe ich nach "Microcontroller" und "AVR". Unter welchem Suchbegriff werd ich da fündig?

@magic33
das mit dem i2c über parallel muss ich mir mal merken...
da ich ferade für den parallelport einen bidirektionelnen pegelwandler baue, damit ich mit spi-teilen sprechen kann.

@normalo
nun musste ich glatt 7 mal rauf und wieder runter scrollen um diese agressiven töne dieser diskussion zu verstehen.

also mal in meinen worten:
den c-control kenne ich nicht... aber
vor zwei jahren... etwa... habe ich bei conrad dieses atmega-systemboard gekauft. gleichzeitig habe ich auch im internet noch weiter gesucht.

als ich dann dieses atmega dings hatte , war ich sehr häppy... aber nachdem ich laut anleitung eine LED zum leuchten brachte, war mir klar, dass die software, die ich für ein C-control schreiben würde.. auch nur auf diesem laufen würde.

also .. um das mal auf den pukt zu bringen:
mit ner c-control oder ähnlichem machste genau das, was die für dich vorgesehenm haben.. im internen code ... und für jede neue schaltung brauchste wieder so einen teueren conrad chip.


nun makl zu den fakten:

Zitat:

---

Ist dieser Timer als eigener Thread

---

ja .. bei einem richtigen atmel laufen die timer eigentlich vor sich hin...


ausser in gewissen schlafmodi

das sind halt integrierte hardwaretimer, die man per software trimmen kann

also
viel glück dann

Zitat:

---

Zitat von kolisson

nun musste ich glatt 7 mal rauf und wieder runter scrollen um diese agressiven töne dieser diskussion zu verstehen.

---

Hm, Agression hab ich nicht bemerkt.

Zitat:

---

Zitat von kolisson

[...]dass die software, die ich für ein C-control schreiben würde.. auch nur auf diesem laufen würde.

---

Dazu kann ich noch nichts sagen, da ich den Chip bisher nur mit Basic programmiert habe und da sicher eine dicke Abstraktionsschicht druntersteckt. Aber soviel ich weiß, kann man da auch mit Assembler ran, zumindest bei der C-Control 2, und ich spekuliere mal, dass sich der Befehlssatz unter den Chips nicht so sehr unterscheidet.

Zitat:

---

Zitat von kolisson

mit ner c-control oder ähnlichem machste genau das, was die für dich vorgesehenm haben.. im internen code ... und für jede neue schaltung brauchste wieder so einen teueren conrad chip.

---

Genau das scheint mir nach wochenlanger Recherche inzwischen auch so. Ich tendiere dazu, ein paar mC zu kaufen und die Schaltung drumherum auf einem Steckbrett so hinzustöpseln, wie ich sie brauche. Dafür hab ich gleich mal mit 32 Bit-Chips geliebäugelt. Laut Wiki sind die nicht viel teurer als 16Bitter.

Zitat:

---

Zitat von kolisson

ja .. bei einem richtigen atmel laufen die timer eigentlich vor sich hin...

---

Und was machen sie, wenn per Interrupt oder in einem anderen Thread eine zeitgefräßige Routine anläuft? Stehen die Timer dann? Welche Priorität haben die?

ja nun .. zunächst zu den timern:

es sind hardwaretimer ... also glatt so, als hätte man extrene zähler und würde sie dann über nen port abfragen..
die laufen also munter weiter.. bis .. wenn man will.. ein int bei überlauf ausgelöst wird..

ob man nun 16 oder32 bit braucht... muss man selber entscheiden..
die 8 bit atmega.. kann man z.b. auch in einer art basic programmieren.. es nennt sich bascom...

bei den conrad dingen ist halt der interpreter fest eingebrannt.. bei den mit bascom (oder eben AVR-studio in assembler) programmierten kann man die chips einfach irgendwo kaufen und sein proggi reinschiessen.

gruss klaus

Zitat:

---

Zitat von Normalo

Zitat:

---

Zitat von kolisson

mit ner c-control oder ähnlichem machste genau das, was die für dich vorgesehenm haben.. im internen code ... und für jede neue schaltung brauchste wieder so einen teueren conrad chip.

---

Genau das scheint mir nach wochenlanger Recherche inzwischen auch so. Ich tendiere dazu, ein paar mC zu kaufen und die Schaltung drumherum auf einem Steckbrett so hinzustöpseln, wie ich sie brauche. Dafür hab ich gleich mal mit 32 Bit-Chips geliebäugelt. Laut Wiki sind die nicht viel teurer als 16Bitter.

---

32 sind zwar leistungsfähiger, aber aufwändiger im Umgang, einfach weil sie doch komplexer sind und mehr können. Das ist auch der Grund warum hier fast alle nur 8 Bitter verwenden, um nicht mit Kanonen auf Spatzen zu schießen.

Zitat:

---

Zitat von Normalo

Zitat:

---

Zitat von kolisson

ja .. bei einem richtigen atmel laufen die timer eigentlich vor sich hin...

---

Und was machen sie, wenn per Interrupt oder in einem anderen Thread eine zeitgefräßige Routine anläuft? Stehen die Timer dann? Welche Priorität haben die?

---

Was ist ein "richtiger" Atmel?

Timer sind Hardwaremodule, die unabhängig von der CPU/ALU laufen und nur bei Bedarf (Interrupts) ein Signal an diese durchgeben.

Zeitgefräßige Interrupts sind so ziemlich die Totsünden in der Hardwareprogrammieren. Sowas immer vermeiden. Immer! Die Frage was bei soetwas passiert sollte sich daher auch erst gar nicht stellen.

Es gibt festgelegte Prioritäten aller Interrupts. Bei kleinen µC sind diese fix eingestellt, bei den größeren kann man sie u.U. frei wählen. Steht dann alles im Datenblatt.

Die 32 Biter sind nicht unbedingt teuerer, aber die Programmiertools (Adapter, Software und Compiler) schon. Das wirst Du kaum unter ein paar hundert Euro bekommen und OpenSource ist mir kaum bekannt. AUßerdem ist es garnicht einfach, an die Grenzen der AVRs zu stoßen, da muss man sich schon mühe geben...
Wenn während einer ISR (InterrupptServiceRoutine) ein weiterer IRQ kommt, dann wird dieser gespeichert und anschließend abgearbeitet. Kommt noch einer, bleibt er unberücksichtigt.
Gruß