Hardware-Fragen zur Multi-IO

[Dirk]

Hi inka,

zu der doppelten belegung der I/Os habe ich so meine eigene theorie entwickelt, hauptsächlich der Inputs: Wenn ich z.b. am pin 8 des JP_IO die bumper der multiIO hab und gleichzeitig den input meines HC-SR04, erkenne ich doch an der art des signals woher der kommt - jumper nur einmal, SR04 immer wieder. Und das gleichzeitig mit dem empfang des US- signals die eine LED an der bumperplatine blinkt? Stört mich wenig...

Da du ja mit der M32 arbeitest, wurde im RN-Wissen Artikel empfohlen, den linken Bumper an Pin 8 von J_IO zu legen. Damit wäre der Bumper über PD6 auszulesen.
Da du den ICP-Pin (= PD6) ja jetzt wohl für deinen Ultraschall-Entfernungssensor brauchst, würde ich den linken Bumper auf einen anderen IO der M32 legen.
Je nachdem was du sonst noch nutzt, würde ich empfehlen:
a) PC7 (= Pin 1 von J_IO), wenn du DCF77 nicht nutzt
b) PC6 (= Pin 4 von J_IO), wenn du das Snake-Modul nicht nutzt
c) PC3 (= Pin 5 von J_IO), wenn du den Buzzer nicht nutzt

In der RP6Control_MultiIO.h must du dann den Portpin für den linken Bumper:

#define IO_MULTIIO_BUMPER_L_IN			IO_PD6	// IO-Mxxx: I/O
#define IO_MULTIIO_BUMPER_L_DDR			DDRD
#define IO_MULTIIO_BUMPER_L_PIN			PIND
#define IO_MULTIIO_BUMPER_L_PORT		PORTD

... anpassen.
..._L_IN wird dann IO_PCx und die anderen 3 Definitionen bekommen als letzten Buchstaben ein "C" anstelle von "D".

Warum sollte man nicht ZWEI Ausgänge (Ultraschallsensor + Bumper) zusammen an einen Input führen?
--> Es könnte passieren, dass die beiden Ausgänge gegeneinander arbeiten und zerstört werden!!!
(Dass das hier nicht passiert, liegt an der Verschaltung der Bumper: Dank fabqu Glück gehabt!)

[TrainMen]

Hi Dirk,
es geht hier nicht um die Suche nach freien Ports und deren Zuweisung. Es geht darum das die Platine die inka gebaut hat aus meiner sicht keinen Sinn ergibt. Du meintest ja WOW, was ist daran WOW ? Die Doppelbelegung die diskutiert wurde kann nicht funktionieren, Du meinest sogar das es nur Glück (Verschaltung) war ist das kein Schaden entstanden ist. Also welchen Sinn macht die Platine ? Lassen wir mal aussen vor das der Zugang leichter ist.

[Dirk]

Hi TrainMen,

in diesem Thread geht es um Hardwarefragen zur MultiIO.

Einen Zusammenhang zwischen der Doppelbelegung eines Pins und dem "Höherlegen" der Anschluss-Pins der MultiIO durch eine Hardware-Konstruktion sehe ich nicht. Ich habe aktuell auf das Thema "Doppelbelegung eines Pins" geantwortet.

Mein Punkt:
1. Die Lösung von inka, eine bessere Erreichbarkeit der MultiIO-Anschlüsse zu konstruieren, finde ich GUT.
2. Eine Zusammenführung von 2 digitalen Ausgängen an einem Eingang finde ich SCHLECHT.

Ok?

[TrainMen]

in diesem Thread geht es um Hardwarefragen zur MultiIO.

manchmal lässt sich das aber schlecht trennen.

und Inka hat das komplette Paket vorgestellt, Doppelbelegung und Höherlegen und Du hast WOW gebrüllt zum Paket. Aber egal ich habe mich eben nur gewundert warum gerade DU WOW sagst obwohl das Paket eben so Müll ist. Ich dachte ich habe irgendwas schon wieder nicht verstanden. Deine Punkte sind natürlich OK

ich ersetze mal Müll gegen so als Paket nicht anwendbar, die bessere Erreichbarkeit ist ja gegeben.

[inka]

Hi Dirk,

a) PC7 (= Pin 1 von J_IO), wenn du DCF77 nicht nutzt

habe es jetzt auf PC7 geändert...

Warum sollte man nicht ZWEI Ausgänge (Ultraschallsensor + Bumper) zusammen an einen Input führen?
--> Es könnte passieren, dass die beiden Ausgänge gegeneinander arbeiten und zerstört werden!!!
(Dass das hier nicht passiert, liegt an der Verschaltung der Bumper: Dank fabqu Glück gehabt!)

vielen dank für die änderungsvorschläge, es würde mich noch in diesem konkreten fall interessieren in welcher richtung der schaden gegangen wäre wenn fabqu nicht gut und gründlich gearbeitet hätte:

a) hc-sr04

oder

b) m32?

zum schluss möchte ich hier noch ein paar worte in eigener sache verlieren:

ich gehöre sicher zu denen, die hier im forum mehr fragen stellen als sie antworten geben können. Auch aus diesem grund habe ich mir vorgenommen, wenn es mir gelingt ein problem - entweder gegeben, oder selbstgestellte aufgabe - einigermassen für mich befriedigend zu lösen, es hier zur verfügung zu stellen. Das vermisse ich immer noch im allgemeinem im forum, dass tut - ausser ausnahmen - kaum jemand hier....

Eigene lösungen zu presentieren ist aber immer mit dem risiko verbunden fehler zu machen.

Das gehe ich gerne ein weil dadurch evtl. ein anderer vor gleichen fehlern evtl. bewahrt wird. Ich bin immer bereit über meine fehler zu diskutieren (naja, mal mehr, mal weniger) um zu einer guten lösung zu kommen. Auch auch bin bereit kritik für fehler einzustecken, sie darf aber m.e. nach nicht den bereich des konstruktiven verlassen und unsachlich werden.

Aber - so oder so - ich bin von meinem vorsatz überzeugt und werde auch in zukunft hier nicht nur fragen stellen, sondern von zeit zu zeit - davon ausgehend, dass es anderen evtl. ähnlich geht - auf meine probleme und ideen mit meinem RP6 und damit verbundene lösungen (und fehler) eingehen. Ein paar haben sicher schon davon profitiert und das sollte sich nicht ändern...

weiterhin viel spass mit dem Rp6 - denn das soll es ja machen...

[Dirk]

Hi inka,

es würde mich noch in diesem konkreten fall interessieren in welcher richtung der schaden gegangen wäre wenn fabqu nicht gut und gründlich gearbeitet hätte:
a) hc-sr04
oder
b) m32?

Wenn die Bumper ohne Reihenwiderstand (R23/24) auf der Bumper-Platine nach VCC oder GND durchschalten würden, wäre der Ausgang des hc-sr04 u.U. zerstört worden. Die M32 hätte keinen Schaden genommen, weil sie ja an diesem "flotten Dreier" nur mit einem Eingang beteiligt war und der geht nicht so schnell kaputt.

[inka]

a) PC7 (= Pin 1 von J_IO), wenn du DCF77 nicht nutzt

In der RP6Control_MultiIO.h habe ich nun den Portpin für den linken Bumper so geändert:

#define IO_MULTIIO_BUMPER_L_IN            IO_PC7    // IO-Mxxx: I/O
#define IO_MULTIIO_BUMPER_L_DDR            DDRC
#define IO_MULTIIO_BUMPER_L_PIN            PINC
#define IO_MULTIIO_BUMPER_L_PORT        PORTC

und mich zunächst gewundert, dass mit der selftest 3 der multiIO nur den rechten bumper beim betätigen im display anzeigt. nach dem kompilieren war der schreck wieder vorbei - alles lief...

in der konsequenz müsste ich jetzt - nach der änderung - aber ALLE programme, in denen die RP6Control_MultiIO.h inkludiert ist neu kompileren, oder?

[Dirk]

Hi inka,

in der konsequenz müsste ich jetzt - nach der änderung - aber ALLE programme, in denen die RP6Control_MultiIO.h inkludiert ist neu kompileren, oder?

Ja genau, leider ...

[TrainMen]

Hi inka,
ist es dir wirklich noch möglich nur eine Lib zu haben ?
Bei mir geht das gar nicht mehr, bei den vielen Änderungen. Ich habe die Libs der MIO alle direkt in meinen Projektverzeichnis. Die der Base und M32 sind in den Verzeichnissen des RP6. Wenn das Projekt fertig ist bekommt es neben dem Namen noch eine Nummer, die Nummer bekommt auch die geänderte Lib. Im Programm selbst ist Beschrieben welche Änderungen gegenüber dem Original gemacht wurden. So lässt sich schnell der entsprechende Zustand herstellen.

[inka]

hi TrainMen,

ist es dir wirklich noch möglich nur eine Lib zu haben ?

ja, es geht. Wir verfolgen aber offensichtlich bei den um- und ausbauten des RP6 einen unterschiedlichen ansatz. Ich habe nicht so viele änderungen, versuche nur einen optimal ausgestatteten roboter zu bauen. Und die versuche, die dazu erforderlich sind beschränken sich auf die multiIO, eine EXP und ein paar steckbretter. Vieles spielt sich aber auch "außerhalb" des RP6, wie z.b. die IR-bake oder die ladestation...

Wenn das Projekt fertig ist bekommt es neben dem Namen noch eine Nummer, die Nummer bekommt auch die geänderte Lib. Im Programm selbst ist Beschrieben welche Änderungen gegenüber dem Original gemacht wurden. So lässt sich schnell der entsprechende Zustand herstellen.

Tja - ich wiederhole mich - schade, dass so keiner von den projekten was mitbekommt...