Eigenentwicklung RC Motorregler

[volkerS]

Hallo Zusammen,
auf Wunsch von Christoph (Regalbahner) habe ich jetzt noch mal Henrys Motorreglerentwicklung unter einem neuen Titel zusammengefasst.
Die technischen Daten:
Versorgungsspannung: 3,6 - 11V
(bei 3,6V (1 Lipo) oder 4,8V kann der Spannungsregler onboard entfallen.)
H-Brücke für den Motor (max. 1,8A)
softwareabhaenig:
RC Puls in (1 - 2 ms)
DCC
RC Puls seriell (Deltang)
Platinenabmessung (ohne Programmierstecker) 24x8mm

RC-seitig kann wahlweise eine SMD-Buchse zum direkten Stecken an einen Empfänger (incl. Versorgungsspannung fuer den Empfaenger) oder Litze angeloetet werden.
Auf der Platine ist der Anschluss zum Programmieren zu untenstehendem Programmiertool vorhanden. Nach Abschluss kann dieser abgetrennt werden.
Für spaetere Aenderungen der Software sind auf der Platine Testpads vorgesehen.
Zum Testen/Programmieren/Weiterentwickeln/Anpassen an eigene Vorstellungen braucht man 2 Hilfsmittel, bei RS erhaeltlich:
USB Basis-Adapter Toolstick
http://de.rs-online.com/web/p/entwicklu ... r/7570464/
Debug-Adapter Toolstick
http://de.rs-online.com/web/p/entwicklu ... r/7570468/
Die Entwicklungsssoftware und Compiler sind kostenlos.

Volker

[Henner (Henry)]

Die Platinen sollten in den naechsten Tagen ankommen. Da ich an dem Deltang Umsetzer zur Zeit nicht weiterarbeiten kann (ich warte auf Informationen), kann ich mich nochmal dem Fahrtregler widmen. Ich koennte einen weiteren Servoeingang (HW auf der Platine vorhanden) dazu benutzen, Geschwindigkeit und Fahrtrichtung auf 2 Kanaele zu legen. Damit wuerde ein Umschaltrelais entfallen. Kommentare/Anregungen dazu?
Regards

[Henner (Henry)]

Hier nun der Rest der Antworten aus dem Umsetzer Thread:
@Heizer: Die Versionen mit ein (Ein Kanal fuer Richtung und Geschwindigkeit) und zwei (Geschwindigkeit auf einem Kanal, Vorwaerts/Halt (Nothalt oder Feststellbremse auf dem zweiten Kanal) werde ich auf jeden Fall realisieren. Was waere das serielle Protokoll (I2C oder RS232)?
@Volker: Die Idee mit der Feststellbremse (Nothalt?) ist super. Werde ich auf jeden Fall implementieren. Das mit dem Bremsservo ueberlege ich mir noch. Eine Rampe ist jetzt schon eingebaut. Platinchen sollten wir aendern, wenn ein Prototyp laeuft.
Die Fahrreglerplatinchen sind noch in der Fertigung.
Regards

[ateshci]

@Henry
Ich bevorzuge wegen der Pololu-Motorsteller/Regler zusätzlich die Möglichkeit, serielles TTL-Signal auszugeben.
Nachtrag: Öhm, ich meine damit RS232-Protokoll

[Henner (Henry)]

@Henry
Ich bevorzuge wegen der Pololu-Motorsteller/Regler zusätzlich die Möglichkeit, serielles TTL-Signal auszugeben.
Nachtrag: Öhm, ich meine damit RS232-Protokoll

Jetzt hast Du mich verwirrt . Ansteuerung des Motorreglers mittels RS232 oder Ausgabe von was? Wie sieht das Gesamtsystem aus?
Regards

[Henner (Henry)]

Ich habe jetzt mit der Version des Motorreglers angefangen, die das PPM Signal auswertet. Damit ist wie beim DCC Konverter nur eine Steckverbindung zum Empfaenger erforderlich. Die Funktion wird auch aehnlich der DCC Version sein, mit der gleichen Knueppelbelegung. Diese Version braucht dann keinen DCC Dekoder mehr, sondern laeuft eigenstaendig. Damit hat man dann eine kleinere billigere Einheit, allerdings ohne all die Feinheiten, die ein DCC Dekoder bieten kann. Ob der Empfaenger mit RC oder WLAN arbeitet, ist egal. Allerdings habe ich bisher noch keine WLAN Empfaenger mit PPM Ausgang gesehen. Eleganter waere natuerlich ein RS232 Signal, aber dafuer gibt es leider noch keine "Norm".
Regards

[ateshci]

@Henry
Der Pololu lässt sich mit seriellen Telgrammen 8N1, wie sie jedes Microcontroller-UART auf TTL-Pegel ausgibt, ansteuern.
Als Beispiel in einer LGB-Stainz, wo die Strings von einem WLAN-Modul empfangen und durchgereicht werden. Die anderen Anschlüsse sind GPIOs desselben.

[Henner (Henry)]

Schon klar, aber wie sieht das Telegramm aus (ASCII/Binaer, feste Laenge, Pruefsumme etc.)? Wenn dort keine Norm vorhanden ist, muesste fuer jede Kombination eine spezielle SW geschrieben werden.
Regards

[ateshci]

Also 8N1 ist doch genau definiert:
1 Startbit, 8 Datenbits, kein Paritätsbit, 1 Stopbit = 10Bits pro Telegramm.
Der Inhalt: Kann man doch festlegen- Pololu kann ASCII oder Binär, ich benutze ASCII, weil auf der Senderseite mit Terminalprogrammen wie PUTTY oder TELNET gearbeitet wird und die tun sich mit ASCII leichter.
bps: Finger in den Wind halten und 9600 oder 19200 sagen. Mit 9600 oder 19200 haben doch alle µCs keine Probleme.

[Henner (Henry)]

Also 8N1 ist doch genau definiert:
1 Startbit, 8 Datenbits, kein Paritätsbit, 1 Stopbit = 10Bits pro Telegramm.
Der Inhalt: Kann man doch festlegen- Pololu kann ASCII oder Binär, ich benutze ASCII, weil auf der Senderseite mit Terminalprogrammen wie PUTTY oder TELNET gearbeitet wird und die tun sich mit ASCII leichter.
bps: Finger in den Wind halten und 9600 oder 19200 sagen. Mit 9600 oder 19200 haben doch alle µCs keine Probleme.

Wir reden konstant aneinander vorbei. Die Uebetragung eines einzelnen bytes mit Start/Stopbit/Baudrate ist nicht das Thema. Wie sieht der Inhalt aus und ist der "genormt"? Wenn ein Hersteller z.B. die Servostellung von Kanal 1 als 2 Byte binaer mit 10 bit und Kanalinformation als vordere Bits uebertraegt, sieht das voellig anders aus, als wenn er 3 Bytes ASCII sendet. Solange dies nicht einigermassen genormt ist, kann man eine Uebetragung nur fuer einen einzelnen Hersteller realisieren.
Regards