[Umfrage] Standalone/OnDevice Lösung

[borg]

cortex-a8

 

Ich bin mir nicht sicher ob der einen FBAS/Video Ausgang zusaetzlich oder konfigurierbar hat. Mein Wunsch waere, dass wenn so eine Moeglichkeit besteht, zumindest die Anschluesse/Kontakte verfuegbar/zugaenglich waeren.

 

Ich weiß nicht genau was FBAS ist, ich kanns aber im Datenblatt von der CPU nicht finden.

 

In Variante 1+2 wird sehr wahrscheinlich ein Allwinner A10s zum Einsatz kommen: http://en.wikipedia.org/wiki/Allwinner_A1X

 

In Variante 3 gibt es mehr Wahlmöglichkeiten (mehr Platz), aber man würde wahrscheinlich den A20 nehmen.

[borg]

Also hat der Master-Brick in Variante 1+2 eine andere Arbeitsweise als unter V3. V3 wäre quasi: am "RaspPi" sind die Bricks per USB angeschlossen und kommunizieren darüber ? In V1+2 geht es über Board2Board also SPI ?

Genau.

 

Du kannst auf das RED Brick z.B. auch direkt einen Stepper Brick setzen ohne einen Master dazwischen zu machen. Das RED Brick ist in Variante 1+2 ein Ersatz für den Master Brick.

[Nic]

Aha, verstehe, darum werden die Extensions nicht unterstützt. Der Master ist in V1+2 arbeitslos

 

Wenn wir einen Chibi-Ersatz anbieten, werden wir diesen natürlich auch kompatibel zum RED Brick machen.

Ok, ansonsten haben wir keine Möglichkeit der kabellosen Übertragung zu verteilten Stacks.

 

PS: Lötkolben meint das hier http://www.elv.de/controller.aspx?cid=758&detail=10&detail2=31

[Loetkolben]

Also hat der Master-Brick in Variante 1+2 eine andere Arbeitsweise als unter V3. V3 wäre quasi: am "RaspPi" sind die Bricks per USB angeschlossen und kommunizieren darüber ? In V1+2 geht es über Board2Board also SPI ?

 

Ja, so verstehe ich das auch. Man koennte aber fuer Variante 1+2 mit einem USB Kabel via "USB-Host <-> USB-Masterbick-Anschluss" kommunizieren. In diesem Fall waeren die Board-to-Board Stecker "nur" noch stromfuehrende Verbinder. Wie oben gesagt, nicht huebsch aber als Alternative zusaetzlich machbar.

 

Der Loetkolben

[remotecontrol]

Schon viel passiert hier in dem Thread...

 

Der Formfaktor war für mich immer ein plus von Tinkerforge, darum bin ich für Variante 1: klein und kompakt und vom Preis noch im Bastelrahmen. HDMI würde ich nicht brauchen.

 

Variante 3 steht etwas in Konkurrenz zu anderen embedded boards, welche aufgrund hoher Stückzahlen günstiger verkauft werden. Für mein dual-core Cubieboard habe ich mit Versand 55€ bezahlt, da ist noch Luft für Master und Step-Down...

 

Aber: ginge Variante 1 auch mit dual-core?

 

Ich fasse für mich mal zusammen:

* es ist ein ARM basiertes Linux, evtl. ist das Raspi Repo voll nutzbar

* d.h. es kann fast jede Software verwendet werden, die dort verfügbar ist

* die Kommunikation mit den Brick(lets) ist etwas schneller als per USB oder gar per Wifi-Extension (was ein weiterer Vorteil gegenüber anderen embedded boards wäre)

* und passende Gehäuse mit Platz für viele Bricklets gibt es auch 

 

[borg]

Aber: ginge Variante 1 auch mit dual-core?

Dafür haben wir leider nicht genug Platz.

[remotecontrol]

Schade, aber wenn ich das vorher richtig gelesen habe ist die anvisierte singe-core CPU merklich schneller als die vom Raspi, das wäre auch schon ein Vorteil.

[raphael_vogel]

Du kannst auf das RED Brick z.B. auch direkt einen Stepper Brick setzen ohne einen Master dazwischen zu machen. Das RED Brick ist in Variante 1+2 ein Ersatz für den Master Brick.

 

Versteh ich jetzt nicht: An RED kann ich doch in Variante 1 keine Bricklets anschließen. Daher kann doch RED kein Ersatz für den Master sein.

Für Sensor/Aktor Schaltungen, also wenn ich z.B. bei einer bestimmten Temperatur den Ventilator anschalten will, brauch ich dann also RED, Master, Temperatur Bricklet und Relais Brickelt.

 

Andere Frage: Wenn der Master dann nur noch dazu da ist die Anschlüsse für die Bricklets bereitzustellen, muss der dann noch so teuer sein oder könnte man dann nicht einen abgespeckten Master machen der nur für RED die Brickelt Anschlüsse bereitstellt?

[borg]

Du kannst auf das RED Brick z.B. auch direkt einen Stepper Brick setzen ohne einen Master dazwischen zu machen. Das RED Brick ist in Variante 1+2 ein Ersatz für den Master Brick.

 

Versteh ich jetzt nicht: An RED kann ich doch in Variante 1 keine Bricklets anschließen. Daher kann doch RED kein Ersatz für den Master sein.

Er hat keine Bricklet Ports in Variante 1+2, aber er arbeitet als Master eines Stacks .

 

Andere Frage: Wenn der Master dann nur noch dazu da ist die Anschlüsse für die Bricklets bereitzustellen, muss der dann noch so teuer sein oder könnte man dann nicht einen abgespeckten Master machen der nur für RED die Brickelt Anschlüsse bereitstellt?

Öh, vielleicht könnte man 1€ sparen indem man den kleineren Microcontroller nimmt, das lohnt sich aber schon auf Grund der Fixkosten nicht befürchte ich.

[Loetkolben]

Aber: ginge Variante 1 auch mit dual-core?

Dafür haben wir leider nicht genug Platz.

 

Achtung Werbung: 

 

embedded world - Exhibition&Conference  25. - 27. Februar 2014 Nuernberg

 

 

Vielleicht ist da was zu finden. ;-)

 

 

Der Loetkolben

[borg]

Wir haben da viel Zeit mit verbracht nach Prozessoren zu suchen und haben einen guten Überblick. So einfach ist das aber alles nicht. Wir hätten z.B. gerne eine CPU von TI mit Package on Package genommen. Da hat die CPU dann oben drauf nochmal Pads auf die man direkt den RAM löten kann. Das hätte uns natürlich viel Platz gespart.

 

Leider hat TI kein Interesse daran uns sowas zu verkaufen... Man hat da bei den "kleinen" vierstelligen Stückzahlen die wir anstreben leider keine riesige Auswahl.

[remotecontrol]

Ich hab mal Euren Wikipedia-Link angeschaut bzgl. der Allwinner CPU: der A10s und der A23 hätten die gleiche Größe von 14x14mm. Reicht das von den Anschlüssen her dennoch nicht oder ist diese (recht neue CPU), dann doch zu teuer?

[borg]

Der A23 hat kein integriertes HDMI (evtl. nicht so schlimm) und Allwinner hat bisher keinerlei Source Code für den A23 veröffentlicht. Es gibt auch keine Entwicklungsboards o.ä. auf die wir aufsetzen könnten.

 

Wenn wir jetzt ein fertiges Board mit dem Prozessor hier hätten, hätten wir keine Chance darauf ein Linux zu booten.

 

http://linux-sunxi.org/A23:

No code for either U-Boot or the kernel has been made available. Allwinner is once again in violation of the GPLv2. No livesuite tool has been made available either, and the devices with android have a fully locked down android installed. The A23 is currently, for all intents and purposes, a closed platform.

 

 

Edit: Wenn er HDMI hätte und Allwinner die Sourcen veröffentlicht hätte, wäre der A23 eine sehr gute Alternative!

[benatweb]

Erstmal alle Achtung, ein Linux auf 4x4cm (ein Viertel von einem Raspberry Pi!) ist schon nicht von schlechten Eltern

 

Zwei Fragen:

 

1. Stellt der RED-Brick auf seinem Mini-USB Anschluss für den Host-Computer eine serielle Konsole bereit? Also ich schließe ihn an meinen Computer an und kann dann via picocom o.ä. ein Terminal auf dem RED-Linux öffnen?

 

2. Ist es theoretisch möglich eine Platine zu basteln, die ich auf die Board-to-Board Connectoren des RED-Bricks stecke und auf der GPIOs, SPI und Co. des A10 (halt eben die, die im Connector verbunden sind) auf Stiftleisten verfügbar gemacht werden? Und wäre das dann auch von Programmen auf dem RED-Linux so direkt ansprechbar oder müsste man da noch Entwicklungsarbeit reinstecken, bis das funktionieren würde?

 

Edit: Nicht vom Stack genutzte zusätzliche GPIOs des A10 irgendwo auf dem RED auf irgendeinem Mini-Frickel-Connector verfügbar zu machen, würde bei Variante 1 sicher nicht noch funktionieren, korrekt?

[batti]

1. Stellt der RED-Brick auf seinem Mini-USB Anschluss für den Host-Computer eine serielle Konsole bereit? Also ich schließe ihn an meinen Computer an und kann dann via picocom o.ä. ein Terminal auf dem RED-Linux öffnen?

So ist es gedacht.

 

2. Ist es theoretisch möglich eine Platine zu basteln, die ich auf die Board-to-Board Connectoren des RED-Bricks stecke und auf der GPIOs, SPI und Co. des A10 (halt eben die, die im Connector verbunden sind) auf Stiftleisten verfügbar gemacht werden? Und wäre das dann auch von Programmen auf dem RED-Linux so direkt ansprechbar oder müsste man da noch Entwicklungsarbeit reinstecken, bis das funktionieren würde?

Das wäre machbar. Dann müsste vermutlich nur unser SPI Treiber lahmgelegt werden, damit dieser die nicht nutzt. Für den A10s habe ich schon mit Python Bindings gespielt die GPIO setzen konnten.

 

Edit: Nicht vom Stack genutzte zusätzliche GPIOs des A10 irgendwo auf dem RED auf irgendeinem Mini-Frickel-Connector verfügbar zu machen, würde bei Variante 1 sicher nicht noch funktionieren, korrekt?

Wir wollen versuchen ein paar GPIOs über ein Flex-Kabel nach draußen zu legen. Ob das klappt wird sich beim Routing zeigen.

[benatweb]

Cool

[Unexpected]

Hallo zusammen,

 

und erst einmal klasse das TF sich so ausführlich mit den Fragen, Ideen etc. der Community beschäftigt. 

 

Meine favorisiere Variante wäre wie anscheint von vielen auch die Nummer 1.

Aus meiner Sicht passt die erste Variante am Besten in das Konzept der schon bestehen TF Hardware. Die Größe ist genau richtig, passt gut in vorhandene Stapel.

Auch der Preis ist aus meiner Sicht in Ordnung.

Ich möchte auf keinen Fall, die "Eier legende Wollmilchsau", denn die würde zum einen sehr teuer werden und zum anderen gibt es meiner Meinung nach für V2 und V3 bereits Boards die günstiger sind und sich dann ähnlich gut/schlecht einbinden lassen.

Mir fehlte bis dato eigentlich "nur" (ich weis das nicht einfach) ein Brick etc. der die TF Hardware vom PC unabhängig macht. Und genaus diese "Lücke" würde die Variante 1 schließen!

Zusätzlich noch mit einer sehr schönen Handhabung und einfachen Bedienung die Programme auf den Brick zu Laden und auszuführen!

 

Klasse Konzept wie ich finde!

 

Gruß

Unex

[luxor]

Mal eine Doofe Frage bei Version eins. Die CPU hat doch sicher LAN oder?

So wie das Bild ausschaut passt nur der Stecker nicht auf das Board oder?

Wie wäre es einfach einen Bricklets Stecker (sicher ein anderen Stecker damit man da nichts verstecken kann) zu nehmen und die LAN Dose per Kabel ans Board zu hängen.

 

EDIT: Sehe grade das LAN immer ein eigener Chip ist. Schade

[batti]

Hallo luxor,

 

der A10S hat LAN unterstütung. Es wird aber noch ein externes IC benötigt welches das PHY stellt.Einfach mit einem Kabel nach außen führen ist es leider nicht getan.

 

Grüße,

 

Bastian

[BorgelMorgel]

Ich habe den Link zum geplanten Prozessor studiert und gesehen das bei Connectivity ein CAN-Bus aufgeführt ist (A10 only). Wir es dann möglich sein das auch zu nutzen bei den Varianten?

 

Ist es evtl. geplant das es ein CAN-Bricklet geben wird?

 

Wir nutzen die TF Module viel und sind richtig zufrieden. Da es aber meist Fahrzeuganwendungen sind, wäre CAN wirklich eine schöne Ergänzung die vieles vereinfacht.

[batti]

Für das 4x4cm Brick planen wir aus Platzgründen mit dem A10s.

Dieser ist nur 14x14mm groß anstatt 19x19mm wie beim A10 oder A20.

Wenn ich nicht irgendetwas übersehen habe, dann hat der A10s kein CAN.

 

Bezüglich CAN haben wir ein paar Anfragen, allerdings nicht so viele wie für andere Produkte. Neben dem Aufwand eine CAN Extension zu entwickeln (bei der die Zahl der Nutzer dann fraglich ist) stehen wir vor dem Problem, dass wir verschiedene CAN Geräte hier haben müssten um die Kompatibilität zu testen. Aus diesen Gründen haben wir bisher noch keine CAN Extension entwickelt.

[Nic]

RED V1:

* Könnte der USB-Host und HDMI-Port jeweils als Mini-USB bzw. Mini-HDMI ausgelegt werden, damit u.a. eine RS-232 da noch raufpasst (vorausgesetzt der Chip unterstützt das ?

* Andere entfernte Funk-Stacks, mit denen im Verbund kabellos kommuniziert werden soll, können wir alternativ über einen WIFI-Stick im USB-Host lösen ?

* Anschluss der Bricklets: Also wie immer über die Bricks, wobei der Master quasi nur als Bricklet-Hub fungiert ?

 

[batti]

* Könnte der USB-Host und HDMI-Port jeweils als Mini-USB bzw. Mini-HDMI ausgelegt werden, damit u.a. eine RS-232 da noch raufpasst (vorausgesetzt der Chip unterstützt das ?

RS232 mit der Standardbuchse ist deutlich zu groß. Auch ein Pin Header würde Eng, da HDMI bereits in der Micro HDMI Ausführung geplant ist.

USB Host möchten wir gerne als USB A lassen, da man ja sonst für alles Adapter benötigt (Beispiel Wifi Stick)

 

* Andere entfernte Funk-Stacks, mit denen im Verbund kabellos kommuniziert werden soll, können wir alternativ über einen WIFI-Stick im USB-Host lösen ?

Korrekt

 

Anschluss der Bricklets: Also wie immer über die Bricks, wobei der Master quasi nur als Bricklet-Hub fungiert ?

Richtig.

[raphael_vogel]

Als Vorteile von RED Variante 1 gegenüber einer RasPi Lösung sehen ich:

1) Kleiner

2) Hoffentlich weniger Stromverbrauch (RasPi zieht je nach Belastung 400-700mA)

3) Die Beschränkung auf 1000 Nachrichten pro Sekunde wird aufgehoben, da nun über Board to Board SPI kommuniziert wird.

 

Liege ich mit 2) und 3) richtig?

[Nic]

Das wäre machbar. Dann müsste vermutlich nur unser SPI Treiber lahmgelegt werden,

Heißt das entweder nur GPIO oder nur Stack-SPI ansprechbar ? Aber nie beides gleichzeitig verwendbar in meiner Anwendung ?

Wir wollen versuchen ein paar GPIOs über ein Flex-Kabel nach draußen zu legen

Wäre das für die RS232 auch möglich, ev. wäre eine RS232 universeller als GPIOs ?

Hmh, alternativ könnte man einen USB-RS232 von FTDI in den USB-Host stecken, aber da könnte schon ein WIFI-Stick stecken, was mich zur letzte Frage treibt:

Wieviel Strom liefert der USB-Host max, den Standard von 500mA ?