Kleinserie: hardware für die M256 WIFI

[RolfD]

Scherzkeks

[SlyD]

Hallo,

ein paar Vorschläge dazu:
Die Steckverbinder von RP6-M32 und M256 könnte man doch einfach beide vorsehen und wahlweise bestückbar machen.
Also z.B. die AD Kanäle und I/Os der M32 und M256 so verschalten, dass man
entweder das eine oder das andere Modul anschließen kann (nicht beide gleichzeitig natürlich).
Da die M256 viel mehr Spezialfunktionen auf den Pins bereitstellt, eventuell noch ein paar Jumper / Steckbrücken oder
0 Ohm Widerstände wenn man etwas für das jeweils anders Modul umkonfigurieren muss.
Die I/O Steckverbinder von M32 und M256 sind grundsätzlich pinkompatibel (nur hat die M32 eben deutlich weniger Hardwaremodule und diese liegen nicht auf denselben Pins).
Eventuell kann man da mit ein paar Steckbrücken arbeiten und einen der I/O Steckverbinder für die M32 konfigurierbar machen.

Für die AD Kanäle könnte man den 14 poligen Steckverbinder der M256 und den 10 poligen der M32 nahe beieinander
positionieren. Dann kann man sogar die gleichen AD Kanäle auf beiden Modulen verwenden.


Lieber einen Steckverbinder der M256 weniger nutzen, dafür mit der M32 kompatibel machen.
Die anderen Steckverbinder der M256 kann man immer noch auf zusätzliche Experimentierplatinen verlegen und dort verwenden,
sagt ja niemand dass die allesamt auf EIN einziges Sensormodul geführt werden müssen



Was ihr mit dem USB Host anstellen wollt ist mir nicht so ganz klar.
Was genau soll daran denn angeschlossen werden?

Wie ja schon angeklungen ist, braucht man dafür eigentlich ein ausgewachsenes
Treiberframework und ein Betriebssystem wie Linux.
Für einfache Sachen wie USB Speichersticks und Joystick / Tastatur bekommt man das natürlich hin, aber glaubt bitte nicht,
dass man da einfach Bluetooth/WLAN Sticks/Webcams oder ähnlich komplexes benutzen könnte! Das war bis vor ein paar
Jahren schon mit einem ausgewachsenen Linux ein Problem dass ans laufen zu bekommen.

Die Transceiver Hardware ist das kleinste Problem dabei und der verwendete Prozessor/Rechenleistung spielt auch
keine Rolle solange kein Linux darauf läuft.

Nein, Speichersticks sind meiner Meinung nach nicht interessant. Da sind microSD Karten wie sie auf der M256
verwendet werden besser geeignet aufgrund extrem geringerem Software overhead und um Größenordnungen
geringerem Energiebedarf.


Es gibt übrigens sogar eine Software(!) HOST Lib für ATMEGAs die immerhin für 1.5MBit/s USB Geräte funktioniert und
noch nichtmal einen Transceiver benötigt:
https://instruct1.cit.cornell.edu/co...t23/index.html



Um damit mal rumzuspielen ist der USB Host sicher nutzbar, aber ich würde vorschlagen eure Zeit lieber in gute Sensorik und
sonstige Funktionen zu investieren und vielleicht das Modul mit M32 und M256 und ggf. auch M128 nutzbar zu gestalten.



Gruß,
SlyD

[fabqu]

Hi SlyD

das mit der Kompatibilität zur M32 versuche ich gerne umzusetzen!
Ich werds zumindest versuchen.

Mit dem Host: Ich fand, die Idee hört sich gut an, und z.B. eine Maus könnte man doch, denke ich, damit umsetzten bzw eben den Bot fernsteuern (soweit ich weiß schickt eine Maus nur einige bits, die dann eben Tastendruck, +/- x-Richtung und +/- y-Richtung enthalten).
Zumindest habe ich mal sowas in Assembler umgesetzt, ist aber auch schon einige Jahre her.

Ich mache mich mal an die zweifache Nutzung: M32 und M256


Danke dir!

[RolfD]

Eine Lasermaus als Ersatz für die Encoderscheiben wäre z.B. aber indoor mal was neues für den RP6... ich halte die Idee mit dem USB Host nach wie vor für gut... auch wenn ich Slyds bedenken zum Treiberframework teile und es nicht allein mit dem Kontroller getan ist. Ich weis nicht ob es einfachere Möglichkeiten gäbe, eine optische Maus anzuklemmen. Aber es geht auch nicht nur um Mäuse... BT is auch Thema... IRDA ... Eine Verbindung zu IFones hab ich auch schon gesehen... also Serial Emulation.. PDAs können das auch zum Teil... Das U in USB steht ja immerhin für Universal.... Dafür muss der USB Host wie auch der RMF12 für hohe Datenraten aber auch schnellstmöglich und effizient angeschlossen sein.. also mit INT. Ansonsten aber volle Zustimmung zu Slyds Beitrag.

LG Rolf

[SlyD]

Eine Lasermaus als Ersatz für die Encoderscheiben wäre z.B. aber indoor mal was neues für den RP6...

Das ist jedenfalls schon öfters hier diskutiert worden (und wird glaube ich irgendwo sogar in der Anleitung vorgeschlagen) - kann mich nicht mehr erinnern ob das auch mal wer umgesetzt hatte, aber ist gut möglich.
Man kann viele der Sensoren in Mäusen auch ohne USB ansteuern - die kann man sogar einzeln kaufen bei Bedarf

BT is auch Thema... IRDA ...

Geht ebenfalls alles ohne USB.
BT Module haben fast alle eine serielle Schnittstelle.
IRDA geht auch mit nem UART und einem entsprechenden Chip dafür.

Mit dem Host: Ich fand, die Idee hört sich gut an, und z.B. eine Maus könnte man doch, denke ich, damit umsetzten bzw eben den Bot fernsteuern

Naja Du kannst auch die Maus an Deinem PC nutzen und die Befehle per WLAN übertragen - aber das wäre ja zu einfach

MfG,
SlyD

[RolfD]

@Slyd..
klar geht das auch irgendwie alles anders... es gibt für alles irgendwelche Chips... aber eine genormte Schnittstelle .. preiswerte Dongels... ich finde das sind schon gute Argumente.
Du kennst sicher das ISO-OSI Modell und USB ist nun mal eine gängige, definierte Phys-Layer Schicht auf der man gut und einfach aufbauen kann. Es wäre aber auch das hier selten angesprochene CAN oder sonst was möglich... wenns dafür Anwendung gäbe ausser Autotachos zu frisieren...
Ich mag propietäres Gefummel nicht sonderlich - vor allem wenns zum Selbstzweck wird.
Sowas ist kaum portierbar und bleibt immer in den Anfängen stecken weil Synergieen fehlen.
Leider stehe ich mit der Sichtweise nur recht alleine, was RP6 Vorhaben angeht... hab ich zumindest oft das Gefühl wenn ich hier poste.
LG Rolf

Ach ja und das mit der Maus per WLAN hab ich aus gesundheitlichen Gründen überlesen... mein Blutdruck is schon hoch genug

[Dirk]

@Fabian:

1. Die CNY70-Schaltung hatte ich vor längerem für einen anderen Bot aufgebaut. Da war sie ok. Müßte also passen, habe sie aber schon lange nicht mehr ausprobiert.

2. Ich würde mich auch dafür aussprechen, alle Funktionen der neuen Platine über Wannenstecker an der Hinterkante der Platine an die µC-Platinen M32/M128/M256 anzudocken. Das macht es den meisten Nutzern einfach, die Funktionen zu nutzen. Leider gibt es keine für alle 3 Platinen identische Pinbelegung, so dass man mindestens 2 Stecker-Belegungen und/oder Jumper zur Belegungsänderung braucht für ADC-Kanäle und andere Portpins.

3. Mit ist noch eingefallen: Wenn jeder auf der Platine das bestücken/aufstecken soll, was er braucht, dann wäre es ja keine gute Idee, die 3,3V von der Kompassplatine zu nehmen, weil man die dann ja zwangsläufig braucht, wenn man z.B. den 3,3V-I2C-Bus nutzen will. Gibt es da vielleicht noch eine andere Option?

[SlyD]

@Rolf
> Du kennst sicher das ISO-OSI Modell

Ich habe schon embedded Geräte mit Linux und ARM CPU entwickelt, an Linux Kerneltreibern rumgeschraubt und mit professionellen
Roboterplattformen gearbeitet bzw. entwickele gerade selbst an einer (nicht für AREXX).
Aktuell muss ich einen BLDC Motorcontroller mit ARM Cortex-M, CAN Bus und allem drum und dran entwickeln.
Also so ein ganz kleines bisschen Ahnung habe ich wohl


> und USB ist nun mal eine gängige, definierte Phys-Layer Schicht

Nur bewegen wir uns hier im low-power embedded Bereich.
Da ist es völlig normal und üblich sowas direkt ohne solchen völlig unnötigen und energie-ineffizienten
Overhead wie bei USB anzusteuern.
Man spart sich dadurch jede menge Aufwand und Kopfschmerzen.
USB vereinfacht für Mikrocontroller gar nichts - ganz im Gegenteil

Klar wenn sowieso Linux auf nem Gerät läuft und USB Hosts im Chipset enthalten sind ist das gut.
Aber sonst? Ne...fasst man freiwillig höchstens mit der Kneifzange an.


Gerade sowas wie IRDA - das ist dasselbe wie UART mit ein paar einfachsten Hilfsschaltungen dahinter (die es fertig als billigen Chip
von diversen Herstellern gibt).
Du würdest da also mit USB einen extremen Aufwand betreiben um letztendlich doch wieder ein UART zu haben
Bei Bluetooth ists dasselbe Spielchen wenn man eh SPP o.ä. nutzen möchte.


> CAN:

MCP2515 ist DIE standard Lösung dafür - Software gibts für den AVR auch schon fertig.
CAN per USB an nem Mikrocontroller? Äääh.... ich klink mich dann mal aus, das wird mir zu abgefahren



@Dirk:

Gibt es da vielleicht noch eine andere Option?

3.3V wäre zumindest auf der M256 vorhanden und kann auf dem 6 poligen WLAN ADC Stecker abgegriffen werden.
Da ist ein 800mA Regler auf der Platine - da geht also noch was.

MfG,
SlyD

[RolfD]

@Slyd

Nur bewegen wir uns hier im low-power embedded Bereich.
Da ist es völlig normal und üblich sowas direkt ohne solchen völlig unnötigen und energie-ineffizienten
Overhead wie bei USB anzusteuern.

Richtig... aber muss das zwangsläufig immer so sein bzw. bleiben ?

Die Anforderungen wachsen bekanntlich mit den Möglichkeiten, welche widerum durch die Fähigkeiten begrenzt und durch Inovation erweitert werden. Wenn man deiner Argumentation folgt, könnte man auch überspitzt sagen, es war unnötig nach dem 8080 ein 80(1|2|3|4)86er, den pentium, und folgende zu entwickeln. Teure Großrechner gabs schließlich damals schon und im low end Bereich muss man eben akzeptieren wenns mal nich so schnell oder propietär zu geht.
Nein der Argumentation kann ich nicht folgen... und es ist auch in erster Linie eine Knowhow Frage.. und keine Geld Frage. Auch ein Zusammenhang, der immer hier wieder aufkocht. Wir sind hier schließlich großen Teils von bereits fertig entwickelten Chips, Schaltplänen und Mini-boards abhängig... deren Effizienz anderswo bereits bewiesen ist. Manchmal ist es ganz gut, auch mal über den eigenen Tellerrand zu schauen. Es hilft u.a. auch beim neu gruppieren von Vorurteilen und festgefahrenen Meinungen. (wobei ich niemandem hier direkt auch Defizite diesbezüglich unterstellen möchte, ich warne nur vor dieser Sichtweise.)

Slyd und ich diskutieren da zwischendurch öfter drüber.. und sind dabei vermutlich näher einer Meinung als viele denken. Aber lasst uns wieder zurück zum Projekt gehen.
LG Rolf

[SlyD]

Hallo,

grundsätzlich ist Abstraktion eine gute Sache.
Bei Hardware aber nur bei Anwendungen wo es auch Sinn macht.

es war unnötig nach dem 8080 ein 80(1|2|3|4)86er, den pentium, und folgende zu entwickeln.

Na also der Vergleich passt rein gar nicht.
Die schnelleren Prozessoren sind dazu notwendig MEHR Daten schneller verarbeiten zu können.

Aber wenn ich nur eine 100kBit/s (oder ähnlich) Datenverbindung zu einem ganz bestimmten Gerät brauche(!!!) für
dass ich sowieso einen eigenen Treiber für meine Hardware schreiben muss, dann muss
ich die Daten nicht erst über eine 12MBit/s USB Verbindung (mit zusätzlicher externer Hardware wohlgemerkt) leiten und
durch 5 Software Abstraktionschichten jagen.
Das ist INEFFIZIENT und erhöht die Kosten, den Energiebedarf und den Entwicklungsaufwand

Ein Gerät per SPI/UART ansteuern ist im günstigsten fall mit 3 Zeilen Code für alles inklusive erledigt.
Bei USB hätte man für den gleichen simplen Transfer allerdings gleich viele tausend Zeilen,
benötigt zusätzliche externe Hardware, kostet jede menge Rechenzeit, Energie und verursacht immensen Entwicklungsaufwand.

Alles um letztendlich doch wieder nur ein putc(char c) zu haben

und sind dabei vermutlich näher einer Meinung als viele denken.
Aber lasst uns wieder zurück zum Projekt gehen.

Jep hier sind wir schonmal einer Meinung
/Offtopic Ende.


MfG,
SlyD