Hi fabqu & TrainMen:
habe ich aus der MultiIO gelernt, das dieses viele Rumgejumpere eher zur totalen Verwirrung führt, vor allem bei denen, die nicht so sehr wie wir hier mitdiskutieren.Leute,Ich finde dieses Rumgejumpere eher vorteilhaft.
ein einfaches Pro & Contra Jumper würde der Sache -denke ich- nicht gerecht.
Wie finde ...
SINNVOLL ->
- Jumper zum Akti-(Deakti-)vieren von (nicht gebrauchten oder Strom-fressenden) Funktionen inkl. ihrer Stromversorgung
- Jumper zur (I2C-)Adressenanpassung (um Adress-Doppelungen im System zu verhindern oder mehrere identische I2C-Bausteine am selben Bus zu nutzen)
- Jumper zur Auswahl der Haupt-Stromversorgungs-Variante
- ...
WENIGER SINNVOLL ->
- Jumper zum Verteilen von zu wenigen I/O-Ports auf zu viele fest installierte Funktionen
- Jumper da, wo es auch Steckverbindungen gibt
- Jumper, um eine Platine allzu "universell" und für zu viele Anwendungsfälle auszulegen
- ...
Bei der MultiIO fand ich gut, dass alle RP6-Prozessor-Platinen (Base, M32, M128, M256 WiFi) durch entsprechende Jumperung nahezu gleich gut nutzbar waren.
Wenn wir es jetzt mit einer rein über I2C gekoppelten Platine zu tun haben (d.h. OHNE Nutzung von I/O- und ADC-Ports der RP6-Prozessor-Platinen), braucht man diese Anpassung sicher nicht, ABER:
Man braucht eine gejumperte INT-Verteilung (INT1..3, INTU) über den XBUS, damit alle RP6-uC-Platinen auch über INT auf rasche Anfragen einzelner I2C-Bausteine auf der neuen Platine reagieren können.
[Anmerkung: Unabhängig von der Jumperei fände ich es weiterhin gut, wenn alle RP6-Prozessor-Platinen (s.o.) wieder nutzbar wären.]
Also:
Jumper ja, wenn es die Funktion erfordert, und nur da, wo man ein Bauteil nicht sowieso durch einen Stecker abtrennen kann.
- - - Aktualisiert - - -
@RolfD:
Ja, das sehe ich auch als Hauptfrage.Die Frage ist letztlich, reicht eine Portemulation ala PCF um damit die meisten Shields ansteuern zu können oder funktionieren dann nur ein paar wenige weil z.B. AD/DA Leitungen, PWM oder IRQs nicht vernünftig nachbaubar sind.
Wenn ich mich (als Hardware-Entwickler) damit beschäftigen müßte (da beneide ich fabqu eher nicht), würde ich mir nicht die zig Shields ansehen, die es für Arduino gibt, sondern ich würde mir die Verbindungen des ATMega 328P mit dem Arduino-Sockel auflisten. Dabei wäre bei den ADCs wohl nur wichtig, Differenz-Eingänge richtig anzuordnen. Bei den I/O-Ports wären die "Sonderfunktionen" (Interrupt-fähig, serieller Port, ICP, PWM, ...) zu beachten.
Wenn man die Pin-Funktionen des Arduino-uC-328P möglichst gut am richtigen Sockel-Pin "kopiert", d.h. eine möglichst identische Pin-Funktion des RP6-Prozessors sucht, dann müßten die allermeisten Shields zu betreiben sein. Im Idealfall sogar alle, wenn man das 3,3V/5V "Problem" löst und spezielle Addon-Boards (mit ISP-Verbindung ...) nicht berücksichtigt.
Was die Zahl der möglichen Shields stark reduziert, wäre eine I/O-Port "Emulation" durch einen I2C-Portexpander. Eingeschränkt gilt das evtl. auch für ADC-Ports.
[Randbemerkung: Wenn wir das so machen würden, bekäme man wieder das "Multi-Jumper-Problem" der MultiIO: Wenn man die Base, M32, M128 und M256 WiFi nutzen will, geht das zwecks Anpassung an den Arduino-Sockel nur mit unterschiedlichen Konfigurationen!]
Lesezeichen