Kleinserie: hardware für die M256 WIFI

[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

[Dirk]

@Fabian & alle:
Ich habe mir mal über Steckerbelegungen für zwei Wannenstecker auf der neuen Platine Gedanken gemacht. Damit soll die Verbindung zu ADC- und I/O-Ports der µC-Platinen (M32, M128 und M256) hergestellt werden (also für alles, was NICHT I2C heißt!).

Das sind dann 2 10-polige Stecker, die wir auf die Hinterkante setzen müßten.
Einer (ADC) für die ADC-Portpins (Linienfolger ...) und einer (I/O) für sonstige (digitale) I/O-Portpins.

Die beiden Stecker können so genutzt werden, dass ...
... der ADC-Stecker mit den beiden ADC-Steckern auf der M32 und M128 und mit dem ADC_IO2/CMP-Stecker der M256 1:1 verbunden werden kann und ...
... der I/O-Stecker mit den I/O-Port-Steckern auf der M32 und M128 und mit einem beliebigen (!!) Stecker IO_PWM/T0/T1, IO_PWM/T2/T3, UART_SPI1/T5 oder UART_SPI2/T4 verbunden werden kann.

Dabei sind 5 ADC- und 7 sonstige I/O-Portpins von JEDER der 3 Platinen (M32, M128, M256) auf der neuen Platine nutzbar. Das müßte für unsere Zwecke eigentlich reichen und ist für die Besitzer von jeder der 3 µC-Platinen attraktiv (also nicht nur für M256-Besitzer!).

Vielleicht hilft es dir ..., vielleicht bist du aber auch schon weiter, dann nichts für ungut!

Tabelle im Anhang!

[fabqu]

Ist ja super!
Danke dir!!!

Welche 5 ADCs wollen wir denn nehmen?
wir haben:
3-5 CNY70
Taster
NE555 ( )
Batterie
2x SnakeVision
2 Spannungsteiler habe ich als Platzfüller reingestellt, die kann man mit allem möglichen bestücken (z.B. 68kOhm für LDRs... )

Mein Vorschlag:
3 CNY70, Batterie, und die vier Taster.

Man könnte ja noch zusätzlich den 14poligen ADC-Stecker der M256 drauf machen (wenn platz ist) für den rest???

Zu den IOs:
einen für die CNY70
einen für die Stromversorgung der Servos
einen für den Beeper
einen um das SnakeVision abzuschalten und einen für den Taster der SnakeVision
???

[Dirk]

Vorschlag:

5 ADCs:
Z.B.: Batterie dauerhaft, 3 CNY70, 4 Taster
Als Option mit Anschluß des ADC_IO1-Steckers der M256 (+ 8 ADCs): 2..4 weitere CNY70, 2x Snake Vision, 2x weitere analoge Sensoren (oder 1x NE555).

7 I/Os:
Z.B.: 1x CNY70 (PWM-fähig), 1x Power Servos, 1x Beeper (8-Bit-Timer-Output), 2x Snake Vision, 2x Bumper hinten (o.ä.)
Was ist mit den 4 LEDs? Steuerst du die anders an, oder brauchen wir da auch I/O-Ports?

[fabqu]

Momentan ist ja der PCA9685 16fach Treiber eingebaut, der steuert momentan 8 Servos an, 4 LEDs und hat dann noch vier weitere IOs, die momenatn nur als Pin rausgeführt sind.