RN-Control 1.4 Mega32 Steuerung per PC?

[Neokortex]

Ich plane ein EeePc auf einen Roboter zu schrauben (habe noch "alte" Motoren die recht leistungsstark sind) zusammen mit einem Bleiakku und möchte das Baby in der Wohnung umherfahren lassen - für ein Haustier fehlt mir die Zeit :-D

Nun möchte ich den PC Nutzen, um komplexere Berechnungen wie Ortung usw. durchzuführen und den Controller für die Steuerung der Motoren und Anschluss bzw. Übermittlung der Sensoren.

Hier im Shop ist mir das RN-Control 1.4 Mega32 in's Auge gestossen, dass auch mit dem Ultraschall-Sensoren "leicht" umgehen kann und einen sehr guten Eindruck macht.

Ist das Board, so wie im Shop erhältlich, in der Lage mir an das Notebook die Messdaten per RS232 und/oder USB zu übertragen und "zeitgleich" die Befehle (für Motoren etc.) zu empfangen?

Wenn nein, was benötige ich zusätzlich für diese Aufgabenstellung noch?

[Willa]

Soweit ich weiss ist RS232 eine voll duplex schnittstelle. Wenn man im Microcontroller und auf dem PC einen Buffer einrichtet, dann sollte eigentlich nichts verloren gehen und eine Echtzeitkommunikation möglich sein. Allerdings weiß ich nicht was die Definition von "Echtzeit" offiziell ist. Du kannst mir der Kombination auf jeden Fall nix falsch machen, auch wenns am Ende doch nicht 1000 promille Echtzeit ist kannst du mit dem RN Control eigentlich alles machen. (btw.: ein Thread reicht übrigens in diesem Forum, manchmal dauern Antworten etwas, aber wenn die Frage freundlich gestellt ist kommt eigentlich immer eine Antwort)

[Neokortex]

Besten Dank für die hilfreiche Antwort.

Verstehe ich es dann auch richtig, dass RN-Control auch "während der Programmausführung" die Daten aus dem von Dir genannten Buffer _verwenden_ kann und somit auf die Befehle des Notebooks reagieren kann?

Mit Echtzeit habe ich vermutlich etwas hochgegriffen. Mit einer zeitlichen Verzögerung (kaum spürbar) kann ich leben. Ich will nur sicherstellen, dass ich im laufenden Betrieb des Programms in der RN-Unit noch weiterhin Daten per RS232/USB empfangen und halt senden kann bzw. mit diesen Daten arbeiten kann.

Was das Doppelposting betrifft, dachte ich mir im Notebook-Forum vielleicht fehl am Platz zu sein... ;-)

[Willa]

Dein Programm auf dem RN-Control wird ja immer eine sich wiederholende Schleife sein (do ... loop). Bei jedem Schleifendurchgang sendest du die Sensorwerte an den PC, der berechnet irgendwas, und danach liest du mit dem µC die Motorwerte vom PC ein. Sollte also kein Problem sein. Wenn du Pech hast, hast du eine Verzögerung von 1/500 sec (ganz grob geschätzt). Das merkt niemand, vor allem nicht bei einem fahrenden Roboter.

[Neokortex]

perfekt, dann werde ich mir das gute Stück mal bestellen.

Du solltest Provision einfordern ;-)

[Willa]

Allerdings :-k So oft wie ich das schon empfohlen habe.... :mrgreen:
Aber es ist eben ein gutes Teil was einem den Einstieg sehr erleichtert... Der Preis ist gerechtfertigt bei dem Ärger und der Zeit die es einem erspart. Ich habe auch damit angefangen und ich benutze es heute sehr gerne um Sachen schnell zu testen.

[Neokortex]

Genau mein Eindruck und es wird vermutlich wesentlich besser sein als meine alten C-Control (I+II).

Ich bin gespannt es zu bekommen und danke Dir für Deine Mühe! Hat mir sehr weitergehlofen.

[holzi]

Guten morgen
mit dem Wort Volldublex bin ich hier nicht ganz einverstanden. Das RN-Control gibt unter Bascom mit dem Print-Befehl die Daten an die RS232. Wird der Empfang mittels Interrupt gesteuert (Config Serialin = Buffered , Size = 10) ist es kein Volldublex, denn wird wärend mittels Print ein Wert ausgegeben und zur selben Zeit kommt ein Empfangsinterrupt, wird der zu sendene Teil abgebrochen.

Peter

[holzi]

Guten morgen
mit dem Wort Volldublex bin ich hier nicht ganz einverstanden. Das RN-Control gibt unter Bascom mit dem Print-Befehl die Daten an die RS232. Wird der Empfang mittels Interrupt gesteuert (Config Serialin = Buffered , Size = 10) ist es kein Volldublex, denn wird wärend mittels Print ein Wert ausgegeben und zur selben Zeit kommt ein Empfangsinterrupt, wird der zu sendene Teil abgebrochen.

Peter

[Willa]

Da hast du wohl recht, aber wenn einen Buffer benutzt wird (ohne irq), der alle x ms abgefragt wird, kann man es noch Fastvollduplex nennen... Vollduplex genug um diesen minimalen Unterschied nicht zu merken. Es ist eher eine Definitionsfrage, genau wie das Wort "Echtzeit".

Oho, laut wikipedia kann man das Verfahren wohl Zeitduplex nennen:


Zeitduplex (engl. time division duplex, TDD) wird z. B. im Mobilfunk angewendet. Hierbei nutzen Sende- und Empfangskanal die gleiche Frequenz sind aber zeitlich voneinander getrennt. Die Informationen werden mit Hilfe eines festgelegten Zeitgebers in kurzen Sequenzen zeitversetzt übertragen. Das Umschalten zwischen Sende- und Empfangsmodus geschieht so schnell, dass dem Nutzer die kurzzeitige Unterbrechung des Kanals nicht auffällt.