Kleinserie: hardware für die M256 WIFI

[fabqu]

Dann haue ich (so als Schmankerl für die M256-ler) den dicken ADC-Stecker der M256 drauf. Sind nochmal 8 ADCs.

Mir fällt leider auch gerade keine neue Idee ein... Ich könnte noch die 8 Servos der M32 reinpacken, die brauchen nicht wirklich Platz. nur wer braucht 16 Servos zum Ansteuern???

Grüße

- - - Aktualisiert - - -

Was haltet ihr von einem CAN-Bus? Für alle Automitiv-Freunde...
Ist halt soweit ich weiß alles andere als Trivial.
Der MCP2515 würde das machen, aber es bräuchte - wenn ich das richtig gesehen habe - noch einiges dazu.

[Dirk]

@Fabian:

Linienfolger:
Die Widerstände 68 und 15 Ohm sind die Vorwiderstände der LEDs in den CNY70 und sind unbedingt erforderlich.

CAN-Bus wäre schon ne feine Sache ...
So ganz viel braucht man hardwaremäßig nicht: Den MCP2515, evtl. den MCP2551-Treiber, Quarz, den SPI-Anschluß (MOSI, MISO, SCK), einen I/O für INT, einen für CS und Reset, Vogelfutter und evtl. ne CAN-Buchse, die natürlich auch Platz wegnimmt. Softwaremäßig weiss ich nicht, ob und wie einfach das ist ...

Bei der Gelegenheit fällt mir ein:
GPS braucht ja einen UART (RX/TX). Einen freien Hardware-UART gibt es nur noch auf der M128 (PD2/3 an Stecker I/O,- leider passt nur RXD zu der Pinbelegung auf der M256, TXD sitzt woanders) und auf der M256 (PD2/3 an Stecker UART_SPI1/T5 und PH0/1 an Stecker UART_SPI2/T4). Damit kann man bei diesen beiden Platinen die entsprechenden Pins mit RX/TX auf der neuen Platine verbinden. Für die M32 (da scheint es ja auch User zu geben, die interessiert sind!) müßte man RX/TX des GPS-Moduls auf einen 2-poligen Stecker am li. Platinenrand legen, von dem aus die M32-Besitzer eine Verbindung zu ihrem PROG_UART-Stecker herstellen können.

[fabqu]

Die Widerstände sind drin und richtig beschriftet.

Zum CAN: Müsste man sich überlegen. Ist schon nicht wenig Hardware... Ich würde es wirklich nur reinsetzen, wenn es jemand wirklich möchte und vor allem WEIß, wie man dafür ne Software bastelt!!! Und das dann natürlich auch macht Ansonsten ist das nur Platzverschwendung.

Zum GPS: Ich hätte momentan der Einfachheit halber einen 3poligen Stecker (Rx, Tx, GND) an die linke Platinenseite gemacht. Dann kann das jeder selbst entscheiden, wie er das ding anschließt. Einen 10poligen, wie ich ihn jetzt habe, werde ich weider raus nehmen. Das nimmt mir zu viel platz weg.
Wenn man das GPS (einmalig) einstellen will, dann kann man dafür vielleicht einfach diese drei Pins nehmen.

Grüße

- - - Aktualisiert - - -

Was ist denn mit den 220 Ohm-Widerständen zwischen dem Servo/LED-Treiber und den Servo-Eingängen???
Brauchen wir die denn???
Zwischen uC und Servo hatte ich auch nie Widerstände.

[Dirk]

@Fabian:
Ja, das mit dem 3-poligen Stecker ist eine sehr gute Lösung (und die einzige für RP6 Base und M32).

Zusätzlich wäre es für die M256 und M128 User eine optimale Lösung, wenn man TX des GPS-Moduls (Pin 4) über einen Jumper mit Pin 8 (RXD) des I/O-Steckers auf der neuen Platine (verbunden dann über Flachkabel mit M128: PD2, mit M256 an einem der UART_SPI-Stecker: PD2 oder PH0) verbinden würde. Dann braucht es keine externe Kabelverbindung bei diesen beiden Plattformen. Dann können DIESE User das GPS ohne loses Kabel (möchte ich immer möglichst vermeiden... ) nutzen.

Für die Konfiguration des GPS-Moduls KANN man RX des GPS-Moduls (Pin 5) über den Mittelabgriff des Spannungsteilers R39/40 genauso auch über einen Jumper mit Pin 6 (TXD) des I/O-Steckers auf deiner Platine (liegt dann an M256: PD3 oder PH1 je nach UART_SPI-Stecker) verbinden. Für die M128 müßte man RX des GPS mit Pin 7 des I/O-Steckers verbinden, das müßte man also über einen Jumper anpassen (wenn man will).

Letztlich braucht man aber nur TX des GPS-Moduls für die volle GPS-Funktion, also die Verbindung zu Pin 8 (RXD) des I/O-Steckers.

Das mit den 220 Ohm-Widerständen in der Servoleitung ist ganz sinnvoll: Einerseits als Schutzfunktion vor Kurzschluss, andererseits lassen sich direkt normale 20mA-LEDs anschließen. Vielleicht nutzt das ja jemand sogar eher als Servos.

[RolfD]

CAN wird auf der alten C-Control II von Conrad wie auch auf der C-Control PRO Unit Mega 128 CAN unterstützt - allerdings sind immer noch externe Beschaltungen nötig. Vor allem eine Übertragerdrossel, so ähnlich wie sie auch lange bei Ethernet verwendet wurde.
http://www.conrad.de/ce/de/product/1...8-Pins-1-mit-5
http://www.cc2net.de/
Aber ich glaube ehrlich gesagt nicht, das jemand pysisch den RP6 mit CAN in Verbindung bringt, da CAN quasi nur in der (Automobil)industrie als Steuerbus Standard gilt. So viel mehr an Software ist das auch nicht, was man da bräuchte. Immerhin sind auch die Mega-Prozessoren auch für Automotive Anwendungen entwickelt worden. Slyd hat da doch etwas übertrieben was den Aufwand für CAN und USB mit den angeblichen 5 Softwarelayern angeht aber Sinnvoll ... ist CAN auf dem RP6 trotzdem nicht. Es gibt kaum CAN-Taugliche Endgeräte.. im Gegensatzt zu USB... Also CAN weg lassen.
LG Rolf

[Dirk]

Sehe ich auch so!

Außerdem gibt es ja, wie Rolf schon geschrieben hat, die C-Control Pro Unit Mega 128 CAN (CONRAD 197989) inzwischen mit CAN. Wer das unbedingt braucht, könnte auf dem RP6 also die M128 Platine als Basis dafür benutzen.

[Dirk]

@Fabian:

Auch wenn ich nerve ...:

Wieviel Platz ist denn noch auf der Platine?

Mir kam gerade der Gedanke, ob wohl noch eine Schrittmotor-Steuerung mit L297/L298 a la http://www.shop.robotikhardware.de/s...roducts_id=208 draufpassen würde?

Hätte jemand Interesse daran?

[SlyD]

Hallo,

CAN ... externe Beschaltungen nötig ... Vor allem eine Übertragerdrossel,

Nein das ist kein Übertrager.
Ausser Transceiver und der Terminierung ist (für Hobby Anwender) nichts notwendig.

Aber ich glaube ehrlich gesagt nicht, das jemand pysisch den RP6 mit CAN in Verbindung bringt,

Ist für kostengünstige Sachen auch nicht sinnvoll da halt zusätzlicher Hardwareaufwand / Platz pro Knoten und benötigt
auch deutlich mehr Energie als z.B. I2C.
Für den I2C Bus gibts viel viel mehr schöne einfach zu verwendende standard Chips.
Gilt ähnlich für SPI und UART.

Slyd hat da doch etwas übertrieben was den Aufwand für CAN und USB mit den angeblichen 5 Softwarelayern angeht aber Sinnvoll ...
LG Rolf

Halt stopp ich habe da von USB geredet und nicht von CAN. CAN nutzen ist deutlich einfacher - in den CAN Controllern wird das meiste in Hardware erledigt!
Und bitte nicht jedes Wort (5 Layer) das ich hier schreibe gleich auf die Goldwaage legen.
5 Layer ist halt die standard Aufteilung, das war nur Beispielhaft - wieviele es genau sind ändert nix an der Kernaussage das es unnützer Overhead ist

MfG,
SlyD

[RolfD]

@Slyd

...gleich auf die Goldwaage legen...

Dito.
Aber bitte auch folgendes.. man kann ein I2C oder UART Treiber als 3-Zeiler schreiben. Geb ich dir recht.
Der RP6 ic2 Treiber sieht entsprechend übel aus und die UART Routinen sind auch nur halbherzig IRQ gesteuert.
Man kann aber sowas z.B. auch als Interrupt driven und mit FIFOs machen... deshalb hat man noch lange keinen unnützen Overhead ala 5 Layer.
Wir diskutieren hier aneinander vorbei, wenn es Dir immer nur um Minimalismus und 3-Zeiler geht, und du alles kritisierst was ich darüber hinaus anrege.
Ich kann auch 3-Zeiler schreiben aber darum gehts hier nicht!

Es ist weder software mäßig kompliziert, noch hardwaren mässig schwer, USB zu nutzen.
http://www.obdev.at/products/vusb/projects-de.html
Es ist dafür auch kein Linux oder wahnsins Overhead nötig - man kann ihn betreiben wenn man möchte aber das gilt auch für jedes andere Protokoll.
Lass uns das hier abschließen, es bringt nix wenn wir in einem Projekt Grundsatzdiskussionen führen, die bestenfalls in den FreeRTOS Thread gehören.
I2C als in-system-kommunikation und USB als Anbindung nach aussen /zum spielen wie ein steppertreiber widerspricht sich nicht.
LG Rolf

[inka]

Ich könnte noch die 8 Servos der M32 reinpacken, die brauchen nicht wirklich Platz. nur wer braucht 16 Servos zum Ansteuern???

wo sind die denn auf der M32?