Kleinserie: hardware für die M256 WIFI

[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?

[RolfD]

Stepper finde ich gut, Motörchen zum basteln dafür finden sich in jedem FloppyLW, Festplatte oder Drucker. Eine richtige Stepperplatine wird das aber nicht ersetzen aber zum ausprobieren und erste Schritte sicher ne Idee.
Problematisch wirds warscheinlich bei den vielen verschiedenen Arten von Ansteuerungen für Stepper.

Die "8 Servos der M32" sind rein Softwarepwm getrieben und belegen die normalen IO Leitungen der M32.

Man kann die sicherlich auch auf das IO Board führen, Servostecker muss man ja nicht zwangsläufig nur für Servos nutzen.... Ich sehe die Dinger vor allem als Single IO port mit GND und +, und man kann sie einfach mit einer Steckerleiste abgreifen wenn man mehrere Ports braucht. Man verschwendet halt nur etwas Platz im Vergleich zu einem (10-pol)Wannenstecker wenn man so viele freie + und GND Pins hat. 8 io Leitungen mit Versorgung belegen 10 Lötaugen, als Servo-Stecker ausgeführt dann gleich 24. Elektrisch tut sich das mal garnix...
Allerdings denke ich, das die M32 Ports besser so angeschlossen würden, so das sie die anderen Funktionen des Boards auch steuern können. Also IRQ Eingänge usw.

Eigentlich brauchen wir mal eine Map, die auflistet welcher Port von welcher M auf welche Funktion des Boards geht.
Also sowas:
| m32 | m128 | m256 | board
|Porta1|Porta1|Portb1| LED1
usw..
Dann erkennt man - entgegen den Schaltplänen - auch einfach, welche Dinge von wo aus nutzbar sind...
Ich hab da schon längst den Durchblick verloren.

LG Rolf

[fabqu]

Hi! Dirk hat das mal alles für uns gemacht

Ich habe momentan einen ADC-Stecker (10polig) drauf, einen IO-Stecker (10polig) und den dicken ADC-Stecker der M256.
Momentan sind davon belegt:

ADC_M256_14polig:
- SankeVision L und R
- Zwei beliebige Spannungsteiler

ADC 10polig:
- ADC_batterie
- Taster oder wahlweise NE555

IO 10polig:
Hier kann man stets wählen, ob man feste IOs nimmt, ob man den ULN2803 benutzt, oder ob man selbst etwas an dem IO anstöpselt
- Beeper (Pin 5, da hier von M256 PG5 oder PB4 liegen)
- Snake-Vision wird durch ULN2803 an Pin 4 Schaltbar

Natürlich fehlt hier noch das ein oder andere (Bumper, Sharps, CNY70) aber hier bin ich noch am probieren, wie man das sinnvoll machen kann, da alleine für die drei genannten 7 ADCs (2 sharps, 5 CNYs) und 3-4 IOs (CNY an/aus, 2 Bumper, Sharps an/aus) benötigt werden. Das ist ne ganze Menge... vor allem, wenn man alles noch wählbar halten möchte.

[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

[SlyD]

Es ist weder software mäßig kompliziert, noch hardwaren mässig schwer, USB zu nutzen.
http://www.obdev.at/products/vusb/projects-de.html

Eine Library ähnlicher Bauart habe ich doch oben selbst gepostet.
Das ist aber wie dort schon gesagt auch nur für HID (und ähnlich einfache Sachen) nutzbar.
Mit "man braucht Linux" meinte ich die Ansteuerung von den wirklich interessanten Geräte die es für USB gibt.

wenn es Dir immer nur um Minimalismus und 3-Zeiler geht, und du alles kritisierst was ich darüber hinaus anrege.

Ich stelle doch nur in Frage ob es den Aufwand rechtfertigt wenn es die gewünschten Funktionen auch für normale Schnittstellen wie UART/SPI gibt wo man sich den USB Overhead komplett erspart.

Lass uns das hier abschließen

Jup. Schluss für heute, jetzt erstmal Abendessen


Bis dann,
SlyD