suche Microcontroller mit deutlich mehr als 50 I/O Ports

Hallo,

wie schon im Titel such ich für ein Projekt von mir einen µC mit mehr als 50 I/O Ports. Ich hab ne Menge Hardware anzusteuern und daher brauch ich viele viele Anschlüße. Den Mega128 hab ich mir schon angeschaut, der hat leider ein paar Ports zu wenig für meinen Geschmack (das ganze soll ja auch noch erweitert werden können). Außerdem verliehrt man gleich wieder ne Menge Ports für Programmierschnittstelle und Bus Systeme.

Da ich bisher nichts gefunden hab was mehr als die genannten Ports zur Verfügung stellt wende ich mich jetzt vertrauensvoll an euch in der Hoffenung dass vielleicht einer einen entsprechenden µC kennt.

viele Grüße
Hanno

z.B. der ATmega2560

hätte ich auch spontan vorgeschlagen..


bei viel hardware macht es sich dann ev. schon gut das über ein bus system zu machen...

kannst ja mal schreiben was es so an hardware ist

Ok dann wollen wir mal

2 Gleichstrommotoren (4 Signale jeweils 2PWM und 1 Enable ein Inkrementalgeber) = 8
2x4 Servos für die Arme = 8
3 Servos für den Hals/Kopf = 3
10 LEDs für die Batterieanzeige = 10
3-4 Taster = 4
weitere LED bzw. Laser = 3-5
AD Eingänge für Spannungsüberwachung = 2
AD Eingänge für Sensoren = 6
Sensoren US je 2 geplant 2-3 = ~6
Display = 6

das wäres so grob und natürlich soll es noch erweitert werden können.
Mit Bus systemen hab ich bisher noch nicht gearbeitet bzw. mich noch nicht heran getraut, da ich nicht weis wie ich die Controller miteinander kommunizieren lassen könnte.

Hallo!

@ HannoHupmann

Laut alter Regel "was nicht passt, wird passend gemacht" würde ich für Ansteuerung der 10 LED's für Baterieanzeige z.B. ein LM3914 verwenden.

Wenn es nicht extrem schnell seien muss, lässt sich durch Anwenden von Schieberegister zum Einlesen/Ausgeben von Daten die Anzahl nötigen Pins stark reduzieren.

Einziges Nachteil ist, das es mehr externer Hardware benötigt wird.

MfG

Wenns wirklich ein µC mit mehr Pins sein soll würd mir da spontan ein Infineon XE167 einfallen. Ist zwar ne ganze Ecke mächtiger als ein AVR, aber mit nem 144-Pin-Gehäuse sollte genug da sein.

Aber der Liste nach würde sich das alles schon mit 2560er machen lassen. Als Bus-System reicht hier dann auch der I2C. Und den in Gang kriegen ist auch kein so grosses Hexenwerk (eher Teufelswerk, wenns mal irgendwo hakt)

@PICture, genau deswegen dieser Thread, da mein Projekt gerade stagniert, wegen dieser Problematik. Bisher hab ich in dem Roboter zwei Mega32 am rattern, aber die kommunzizieren nicht miteinander und das möchte ich nicht. Die Idee war einen großen µC zu nehmen und sich die Busproblematik zu sparen. Dass eine 10 Segmentanzeige auch anders angesteuert werden kann, hab ich im Hinterkopf und wird auch sinnvoller sein.
Ein neues Board muss ich eh auslegen da können dann auch noch mehr Controller drauf.

Also immer her mit den Ideen :)

Also der AT90USB1287 hat schon mal 48 I/Os.
http://www.atmel.com/dyn/resources/p...ts/doc7593.pdf

Die Atmegas der ATmega1281/2561, ATmega640/1280/2560 haben 51 bzw 86 Programmable I/O Lines! Reicht Dir das??
Mächtiger geht ja nun wirklich nicht.
http://www.datasheetcatalog.org/data.../3055029_1.pdf

Mit ein wenig Geschick kann man auch eine Menge Ports einsparen. z.B.:
- Tasteneingaben über ADC & Widerstandsnetzwerk
- LCDs im 4Bit-Mode oder am I2C Betreiben
- Sämtliche zsätzlichen Steine/Sensoren am I2C betreiben
und und und

hi HannoHupmann,

für ein anderes Projekt habe ich einen kleinen (guten alten) 8 bit parallel-Bus aufgebaut.

Das gibt jede Menge freier Adressen.

Bild hier  

Schau doch mal da:

https://www.roboternetz.de/phpBB2/ze...rieb&start=154

Am Ende des oberen Drittels der Beitrag vom: 19.09.2008, 17:57


Statt des unidirektional arbeitenden 74..573 kannst Du auch den 74..245 verwenden. Der arbeitet auch bidirektional:
Einfacher (zu programmieren) ist es aber jeweils 8 Bit nur für Ein- oder Ausgabe zu definieren.

http://www.datasheetcatalog.org/data...1x649sy2py.pdf

Die Teile sollten auch in SMD verfügbar sein.


Das schöne an den Latches ist, daß sie die Daten zwischenspeichern und Du sie abrufen kannst, wann Du möchtest.

Mit nur 3 Bit (Adressen) & 8 Bit (Daten) könntest Du schon 15 (16) mal einen 8 Bit breiten parallelbus aufbauen.

Bei 4 Adressbits verfügst Du schon über 31 (32) 8 Bit breite Kanäle.


Der Schaltungsaufwand ist etwas höher und die Technologie stammt noch aus der "Computersteinzeit"; wie ich selber auch ](*,) , bietet aber auch ein paar Vorteile.

Du hast keinen Streß mit irgendwelchen Übertragungsprotokollen und die Datenübertragung ist auch nicht so strörungsanfällig wie bei seriellen Systemen.
Die Geschwindigkeit ist auch recht hoch, da bis zu 8 Bit parallel übertragen werden.


Inwieweit die neuen Bussysteme nun besser sind als mein "Dinosaurier" können andere hier besser beurteilen als ich. Ich kenne nur den Einen "en détail". Da lasse ich mich auch gerne belehren \:D/

Das System ist, sofern einmal verstanden, recht einfach aufzubauen und bei entsprechender Auslegung der Busadressen auch im nachhinein einfach zu erweitern.



Bin schon mal gespannt, was Du wieder "ausheckst" \:D/ \:D/


liebe Grüße,

Klingon77

@ HannoHupmann

Ich finde trotzdem die Lösung nur mit Schieberegister ohne Bus besser, weil sie keine Adressen und bei beliebiger Vergrösserung der Datenmenge keine zusätzliche Pins braucht. Man braucht immer für das Ausgeben nur 2 und das Einlesen nur 3 Pins.

MfG

hi,

wie gesagt, lasse ich mich da gerne belehren, da ich mich mit den "neuen" Systemen nicht auskenne O:)

liebe Grüße,

Klingon77

@ Klingon 77

Ich bin wegen Alter auch schon nicht mehr auf dem Laufendem und kenne die "neuen" Systeme auch nicht. :(

Ich habe bloss immer die Schieberegister benutzt um mit wenigsten Pins und einfachstem Programm auszukommen.

Von dir vorgestellte Variante ist viel schneller und man kann sofort an bestimmte Adresse Daten schicken. Ausser dem Endbenutzer, kann man nicht sagen, welche für bestimmte Anwendung besser ist.

Ich habe auch schon gelernt, dass nicht immer das "Neue" mit Sicherheit besser als das "Alte" ist... :)

MfG

Hallo,

Es gibt doch auch die ATXMEGA, die haben ein paar ports mehr.

Oder wie wärs mit nem Co-Controller über I2C?

Grüße

Waldichecker

Schon mal jemand mit diesem hier gearbeitet? ATmega2560 der hätte immerhin sage und schreibe 100Pins und damit 80 I/O Pins. Ich bin mir nur nicht sicher ob man den noch ohne weiteres programmieren kann wie z.B. nen Mega32. Es ist aber aus der gleichen Familie.

Bevor jemand fragt, es ist kein Problem diesen zu verlöten, dafür hab ich die Möglichkeiten.

Einfach das RN2560-Modul verwenden. Den verwend ich auch; ne ISP-Buchse ist drauf, ebenso auch noch USB und RS232.
Und es ist steckbar, also im Defektfall leicht zu tauschen.

(Selber ne Platine mit dem machen, geht zumindest bei mir nicht. Löten würde schon gehen, nur bei dem Pinabstand versagt der Drucker.)

wobei man sicher billiger kommt wenn man das selber baut..bei ebay gibt es oft adapterboards....zur not halt die von reichelt..die sind etwas teurer...aber 60€ muss das nich kosten..;)

wobei ich eh eine Platine bauen müsste auf die ich das Board mounte. Mal sehen was sich da machen lässt. Der Vorteil wäre halt, dass ich mir ums Layout nur noch weniger Gedanken machen muss und dann nur eine Platine basteln müsste als Hardwareanpassung.

Ich bin ein Freund von vernetzten Controllern. Nicht nur, weil man mehr Pins hat. Vor allem hat man echte Parallelverarbeitung, was bei zeitkritischen Sachen große Vorteile hat. Irgendwann ist der Punkt erreicht, wo mehr Pins an einem µC nicht mehr sinnvoll sind, weil nicht mehr genug Rechenleistung zur Ansteuerung bleibt.

Wenn du z.B. die DC-Motoren auf bestimmte Positionen oder Geschwindigkeiten regeln willst, packst du die Funktion in nen separaten µC, der dann nur diese Regelung macht. Der Hauptcontroller gibt dann bloß den Startbefehl, und hat dann Zeit für andere Aufgaben.

Auch für die Servos würde ich nen eigenen µC nehmen, da auch der 2560 nicht so viele Hardware-PWM-Kanäle hast, wie du brauchst.


Eine mögliche Einteilung:

Der "Motor-Controller"
2 Gleichstrommotoren (4 Signale jeweils 2PWM und 1 Enable ein Inkrementalgeber) = 8

Der "Servo-Controller"
2x4 Servos für die Arme = 8
3 Servos für den Hals/Kopf = 3

Der "Haupt-Controller" und User-Interface
10 LEDs für die Batterieanzeige = 10
3-4 Taster = 4
weitere LED bzw. Laser = 3-5
Display = 6

Der "Sensor-Controller"
AD Eingänge für Spannungsüberwachung = 2
AD Eingänge für Sensoren = 6
Sensoren US je 2 geplant 2-3 = ~6

Ich hab nur noch NIE mit Vernetzung gearbeitet und wüsste nicht wie ich die Daten zwischen den Prozessoren austauschen soll. D.h. da fehlts mir einfach an KnowHow und daher favorisierte ich bisher die 1 Controller Lösung.#

Abgesehen davon würde mir eine andere Aufteilung besser gefallen. Ich brauch wegen der LiPo Akkus eine absolut zuverlässige Motorabschaltung wenn die in den unteren Bereich kommen. Daher würde ich diesen Part dem Motor Controller zuschieben.

Hm, würde so spontan nen Paket PCFxxxx vorschlagen also I²C I/Os, wehren dann halt die beiden I²C pins + eine Interuptleitung z.b. wen du die taster dran nutzt dann brauchste nicht ständig auslesen, LEDs kannst auch dran nutzen das Display auch bis auf die Steuerleitungen.

Rest dann an den µC jedenfalls ist dass dan pinsparend und du kannst dann noch den i²C bus für Erweiterungen herausführen, und besser als die oben genannten Schieberegister.

Bei so vielen Aufgaben wird die Aufteilung auf 2-4 µCs sinnvoll sein. Bei einem großen µC hat man leicht das Problem, dass irgendwelche Hardwarefunktionen doch den gleichen Pin benötigen.
Außerdem wird es bei einem µC schon schwierig das ganze so zu programmieren, dass die Reaktionszeit auf alle Interrupts kurz genug bleibt. Die Servokontrolle ist ja schon etwas Zeitkritisch.

Wenn man die Komumnikation einmal fertig hat, ist I2C als Bus nicht so schwer und auch gut erweiterbar.

Bei der Ansteutung von LEDs und tastern könnt man noch einigers an Pins sparen wenn es sein muß.

Nachdem sich jetzt so viele für eine Lösung mit mehreren µC ausgesprochen würde ich gerne weiter auf diese Lösung eingehen:

Zitat:

---

Wenn man die Komumnikation einmal fertig hat, ist I2C als Bus nicht so schwer und auch gut erweiterbar.

---

Damit spricht Besserwessi auch gleich an wo das Problem von meiner Seite aus liegt. Wie bekomm ich eine vernünftige, bidirektionale Kommunikation mehrer Controller hin?

Jemand Anleitungen oder Ideen?

in welcher sprache möchtest du das ganze denn realisieren?

Hallo,

da gibt es viele Möglichkeiten, je nach dem wie kreativ du sein willst ;)
I2C ist multimasterfähig, d.h. dass jeder Teilnehmer selbst aktiv eine Übertragung starten kann. Der Nachteil eines solchen Ansatzes ist, dass evtl. timingkritische Aufgaben darauf warten müssen, bis der Bus frei ist.
Eine andere Möglichkeit wäre z. Bsp. ein Ringbus via UART oder SPI, was gewisse Timinggarantien zulassen würde.
Oder du wählst eine zentralisierte Architektur, verdrahtest alles via SPI sternförmig und hast einen Master der die einzelnen Teilenehmer anpollt/befehligt.
Es gibt auch die Möglichkeit, all das zu kombinieren und für mehrere Bussysteme parallel zu verwenden, etwa einmal I2C für weniger zeitkritische Aufgaben oder für allgemeine Steuerbefehle, und dann SPI oder evtl. ein 4/8-Bit-Bus für Übertragungen hoher Priorität/größerer Datenmengen.
Je nach Realisierung wäre es etwa auch möglich zu sagen, dass dieser "breite" Bus kontinuierlich Steuerbefehle für die ganze Mechanik in einem definierten Paketformat transferiert, die ein Master-Controller generiert und dann von den einzelnen Slaves umgesetzt werden. Der Master könnte dann selbst kompliziertere Berechnungen anstellen ohne noch auf das IO-Timing zu achten.
Man könnte dieses Konzept dann sogar noch weiter treiben, indem man dem Master selbst die zu berechnenden Zielkoordinaten etc. via I2C zusendet, die ein zentraler Controller etwa über Funk bekommen hat. Dieser zentrale Controller könnte etwa verschiedene Sensoren auswerten (oder die Auswertungsergebnisse via I2C abholen ...), auf die Batteriespannung achten, mit einer Echtzeituhr reden, den Displaycontroller instruieren etc.

mfG
Markus

Eine bidirektionals Kommunikation ist schon etwas aufwendiger. Man kann die Aufgabe aber oft so aufteilen, dass man im wesentlichen mit unidirektionaler Kommunaikation auskommt, und auch mit eher niedriger Datenrate.

Ein Controller der die Servos und DC motoren steuert braicht kaum was zurückmelden. Die paar weniger Daten die mal in andere Richtung gehen, kann man dann auch per Pollng abhohlen, also ohne Multimaster.

@dremler, am liebsten in C oder Assembler wobei ich glaub ich gerade fitter in C bin.

@Besserwessi, die Motoren müssen auf jedenfall ihre Geschwindigkeit zurück liefern und die möglichst kontinuierlich. Zudem den Ladezustand der Batterie, falls diese kritisch wird.

Der Servocontroller muss in der Tat gar nichts zurück geben sondern einfach machen. Anders sieht es da schon wieder bei den Sensoren aus. Die müssten Quasi in direkter Verbindung mit dem Master bleiben.

Soweit so gut in der Theorie, die ist in der Tat nicht so kompliziert, aber wie würde man sowas in Code umsetzen? Da hakt es dann meistens bei mir.

Für arr-gcc findest du nen Code von mir für die I2C-Slaves im Wiki. Damit werden die Slaves ähnlich wie ein I2C-EEPROM angesteuert. Also hat man quasi ein dualport-RAM, auf das beide Controller zugreifen können. Für den Master findet man haufenweise libs, ich bevorzuge die von P. Fleury.

EDIT: ich seh gerade, dass im Wiki noch eine etwas ältere Version steht. Hier der neuste Stand:
http://home.edvsz.fh-osnabrueck.de/u...r/twislave.zip

Hallo!

@ HannoHupmann

Ich habe damit zwar keine Erfahrung, aber denke, dass es für Erstellung eines gesamtes Programms kein Unterschied gibt, mit wieviel µC's es realisiert wird.

Ich stelle mir das einfach so vor, das der Haupt µC ein Hauptprogramm ausführen wird und fast alle Unterprogramme werden in den untergeordneten µC's untergebracht und vom Haupt µC in festgelegter Reihenfolge per ein Bus (z.B. I2C) aufgerufen.

So wie ich das sehe, irgendwann wird es dazu kommen, dass mit einem µC, nicht nur wegen zu wenig I/O Ports, nicht mehr gehen wird immer kompliziertere Roboter zu steuern.

Ich habe in der Elektronik mit Röhren angefangen und heute programmiere ich µC's. Ich kann mir nicht vorstellen, dass ich heute eine Steurung eines Botes mit Röhren realisieren könnte. Das Leben ist leider brutal und man muss viel Sachen zum ersten mal machen... :)

MfG

@PICTure ich weis ich weis und ich hab mich auch schon in viele neue Gebiete eingearbeitet. Aber aus diesen Erfahrungen hab ich gelernt, dass es sinnvoller ist sich erst mal umzusehen ob es nicht schon jemand gemacht hat. Ich hab nicht den Anspruch das Rad für mich neu zu erfinden.

Daher Zielt meine Frage jetzt auch auf Codebeispiele ab, den die Theorie ist soweit klar, jetzt gehts an die praktische Umsetzung. Wenn ich weis wie das zu Lösen ist mach ich mich an den Entwurf der Schaltungen

Hallo!

@ HannoHupmann

Das mit praktisch ausprobierten Mustern stimmt, aber leider als Entwickler muss man oft etwas "erfinden" um sein Projekt nach eigener Vorstellung zu realisieren.

Ich wünsche dir wirklich viel Erfolg in Realisierung deinen Plänen und hoffe, dass du etwas brauchbares und für dich adaptierbares findest. :)

MfG