Forum: Mikrocontroller und Digitale Elektronik Plattform für Gerät - Evaluierung


von Ocan (Gast)


Lesenswert?

Hallo zusammen,

Unsere Firma setzt aktuell ein Produkt ein, welches ersetzt werden soll. 
Nun suchen ich nach einer Platform welche unsere Anforderungen gut 
unterstützt.

Ich denke das es hier im Forum sicherlich viele Leute gibt die sich 
damit auskennen und ein Produkt empfehlen könnten. Es geht hier 
hauptsächlich um den Prozessor, der Rest ist zimlich simpel


Beschreibung:

Es handelt sich um ein Terminalgerät welches über Netzwerk mit einem 
Server kommunizieren soll, und zwar über einen Webservice mit 
http-request.

Es gibt hierbei einige wichtige Punkte

- Es muss per DHCP eine IP für das Terminal bezogen werden können, 
jedoch auch fix. Hierzu müsste das Terminal irgendwie per Broadcast 
auffindbar sein.
z.b. Lantronix kann das, auch wenn das Terminal eine falsche fixe IP hat

- Code updates müssen per Netzwerk möglich sein

- Es muss ein Display von mittlerer Grösse (zb. 640x480px) ansteuerbar 
sein, der Bildwechsel muss schnell möglic sein. Aktuell benutzen wir ein 
EA-DIP, das brauch gerne mal 2-3Sekunden um das Bild aufzubauen.

- Der Prozessor sollte am besten 2 x RS232 hardwaremässig bedienen 
können

- Es soll eine Weboberfläche auf dem Gerät zur Verfügung stehen

- Es braucht ca 25 I/O's

- Optional soll der Code fürs Betriebssystem und der Code für die 
Serielle Schnittstelle separat möglich sein, so das nicht jedesmal das 
komplette System geupdated werden muss.



Kennt jemand hier einen Prozessor welcher die nötigen Leistungen bringt, 
aber trotzdem ein gutes Preis-Leistungsverhältnis hat und nicht 
überdimensioniert ist.
Das Gerät soll als komplette Einheit auf einem Print gebaut werden - 
Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft und 
abgelehnt.


Hat jemand eine Idee?

Grüsse Ocan

von Rainer U. (r-u)


Lesenswert?

Ocan schrieb:
> Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft und
> abgelehnt.

Warum?

von Rene K. (xdraconix)


Lesenswert?

Rainer U. schrieb:
> Ocan schrieb:
>> Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft und
>> abgelehnt.
>
> Warum?

Ich verstehe das dann auch immer nicht, solange keine andere Alternative 
verfügbar ist, sollte das nicht abgelehnt sondern als "Plan B" immer 
noch weiter vorliegen. Aber nunja, komische Firmenphilosophie.


Zum Thema:

Da stellt sich mir die Frage: Welches System setzt ihr aktuell ein? 
Warum wird dieses System abgeschafft? Wo lagen die Schwächen?

von Marc H. (marchorby)


Lesenswert?

Ocan schrieb:
> über einen Webservice mit
> http-request

Schlecht! Nichts aus der Vergangenheit gelernt? Kommunikation muss 
verschlüsselt sein! Vor allem wenn der Nutzer über die Weboberfläche 
persönliche Daten eingibt!

von Ideengeber (Gast)


Lesenswert?

Ocan schrieb:
> Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft und
> abgelehnt.

Dann probier es halt mit einem maxi-PC.

Ich vermute mal du wirst hier jede Menge "nützliche Vorschläge" bekommen
und am Ende kannst du dich nicht für den richtigen entscheiden :(

Bist du eigentlich nicht in der Lage sowas selber zu entscheiden,
weil du hier ein Pflichtenheft posten musst :(

Bist du BWL'er?

von Der Andere (Gast)


Lesenswert?

Ocan schrieb:
> der Rest ist zimlich simpel

Diese Aussage ist schon der Garant, das das das nächste "Botnet of 
Things" ("BOT" statt "IOT") wird.

von Ocan (Gast)


Lesenswert?

W

Rene K. schrieb:
> Rainer U. schrieb:
>> Ocan schrieb:
>>> Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft und
>>> abgelehnt.
>>
>> Warum?
Ein mini-pc ist immer noch sehr gross, teuer, und oftmals 
überdimensioniert.
Wir haben andere Applikationen wo ein customized Embedded-PC zum Einsatz 
kommt, aber auch von der Leistung gebraucht wird.
Die Vorgabe ist zwingend ein Einplatinen-Terminal. Ebenfalls soll 
hiermit verhindert werden das Hardware fremdgekauft werden kann.


> Ich verstehe das dann auch immer nicht, solange keine andere Alternative
> verfügbar ist, sollte das nicht abgelehnt sondern als "Plan B" immer
> noch weiter vorliegen. Aber nunja, komische Firmenphilosophie.
>
> Zum Thema:
>
> Da stellt sich mir die Frage: Welches System setzt ihr aktuell ein?
> Warum wird dieses System abgeschafft? Wo lagen die Schwächen?

Aktuell wird ein Print mit einem Lantronix Matchport (für Display und 
IO) sowie seperat ein Lantronix UDS für den RS232 (2x Baud 115200) in 
einem Gehäuse verbaut.

Die Schwächen sind das bei selbst kleinsten kurzen Netzwerkunterbrüchen 
die komplette Kommunikation zerbricht.
Mit http(s) kann die Kommunikation um vieles verkleinert werden, da das 
Terminal die RS232 Geräte lokal ansteuern kann, und nur deren 
"Ergebnisse" an den Server mitteilen.

Hat man aktuell zb. 30 Geräte im Einsatz, gibt das insgesamt 90 
virtuelle Comports am Hauptrechner, dessen Leistung muss reichen um alle 
Schnittstellen zu bedienen.

Die kommunikation soll schon verschlüsselt werden, dies ist jedoch nicht 
eine top priorität. Die Geräte lesen nur Seriennummern von Datenträgern 
aus (keine Benutzerinteraktionen) und werden in einem eigenen Netz 
betrieben welches nicht von aussen erreichbar ist.

von Rene K. (xdraconix)


Lesenswert?

Na dann empfehle ich einfach mal einen STM32F7. Dieser hat mehrere UART, 
LAN und mehr als ausreichend Leistung für ein TFT und sonstige IOs.

Ein eigenes Programm muss für diese Geräte ja sowieso geschrieben 
werden, genauso wieder Netz-Stack. Das ist ja auch nicht die Frage 
gewesen.

von Felix F. (wiesel8)


Lesenswert?

Wie wärs mit einem SOM (z.B. von Phytec)? Oder gleich einem Raspberry 
Pi?
Da könnt ihr dann alles auf einem Linux einrichten wie ihr wollt.

mfg

von Rene K. (xdraconix)


Lesenswert?

Felix F. schrieb:
> Wie wärs mit einem SOM (z.B. von Phytec)? Oder gleich einem Raspberry
> Pi?

Das wäre ja das vernünftigste. Sticht sich aber halt mit der 
Anforderung:


Ocan schrieb:
> Ebenfalls soll
> hiermit verhindert werden das Hardware fremdgekauft werden kann.

von Der Siebenschläfer (Gast)


Lesenswert?

Moin,

Wollt ihr ein RTOS system oder doch lieber LINUX?

Wieveil RAM / Flash braucht ihr in zukunft?

RaspberyPi CM (computer Module)
IMX28 / IMX6 (muss ja nicht gleich der quadcore sein)

ggf hat Graz und Fricke ja was passendes. ggf muss man da dan noch die 
IOs irgendwie durch z.B. nen I2C extender nachrüsten.

Linux hätte den vorteil, das HTML5 sich sehr einfach umsetzen lassen 
würde. z.B. mit QT.

von STK500-Besitzer (Gast)


Lesenswert?

Ocan schrieb:
> - Es muss per DHCP eine IP für das Terminal bezogen werden können,
> jedoch auch fix. Hierzu müsste das Terminal irgendwie per Broadcast
> auffindbar sein.
> z.b. Lantronix kann das, auch wenn das Terminal eine falsche fixe IP hat
DHCP, PING, ARP...

> - Code updates müssen per Netzwerk möglich sein
Bootloader gibt es in Hülle und Fülle
>
> - Es muss ein Display von mittlerer Grösse (zb. 640x480px) ansteuerbar
> sein, der Bildwechsel muss schnell möglic sein. Aktuell benutzen wir ein
> EA-DIP, das brauch gerne mal 2-3Sekunden um das Bild aufzubauen.

Es gibt diverse ARM-Controller mit integriertem Display-Treiber

> - Der Prozessor sollte am besten 2 x RS232 hardwaremässig bedienen
> können

s.o.

> - Es soll eine Weboberfläche auf dem Gerät zur Verfügung stehen
> - Es braucht ca 25 I/O's

Schon mal über ein Customboard nachgedacht, das speziell für eure 
Anwendung entwickelt wird?
Wir haben sowas im Rahmen einer Masterarbeit erstellen lassen (und den 
Master dann gleich eingestellt).

von Guest (Gast)


Lesenswert?

Ich würde auch einen STM32F7 vorschlagen, wenn es mehr Leistung sein 
soll auch einen ARM Cortex-A, da gibt es genug Auswahl.

Von der Softwareseite könntet ihr einfach alles von SEGGER beziehen, da 
bekommt ihr alles von IDE/Compiler, über Debug Probe bis hin zu RTOS, 
Middleware wie IP/Stack, SSL, usw.:
https://www.segger.com/products/rtos/embos/
https://www.segger.com/products/development-tools/embedded-studio/
https://www.segger.com/products/rtos-embedded-software/
https://www.segger.com/products/debug-probes/j-link/
https://www.segger.com/products/production/flasher/models/flasher-pro/

von Frank K. (fchk)


Lesenswert?

Weiterer Vorschlag:

http://www.microchip.com/design-centers/32-bit/architecture/pic32mz-da-family/

Microchip liefert alles erforderliche an Software, um diese Teile 
einsetzen zu können. Da muss nicht unbedingt extern was dazugekauft 
werden.

fchk

von Tom (Gast)


Lesenswert?

Aber MLAB-X und GFX ist jetzt nicht so toll zum arbeiten. Dann echt 
lieber die Sachen von SEGGER, da funktioniert wenigstens alles out of 
the box. Ist aber natürlich immer die Frage, ob man lieber Arbeitszeit 
oder Geld investiert.

von Rene K. (xdraconix)


Lesenswert?

Tom schrieb:
> Aber MLAB-X und GFX ist jetzt nicht so toll zum arbeiten. Dann
> echt
> lieber die Sachen von SEGGER, da funktioniert wenigstens alles out of
> the box. Ist aber natürlich immer die Frage, ob man lieber Arbeitszeit
> oder Geld investiert.

Naja, das habe ich bei Projekten mit SEGGER auch schon anders erlebt - 
gerade was die Middleware angeht. Man muss sich da immer eines vor Augen 
halten: Alle kochen bloß mit Wasser, bei manchen ist das Wasser aber 
eben teurer als bei anderen.

Ich persönlich würde SEGGER nicht mehr empfehlen, aber ist ja immer 
Geschmackssache.

von Guest (Gast)


Lesenswert?

Echt? Welche Probleme hattest du denn bzw. mit welchem Produkt?

"Alle kochen bloß mit Wasser" würde ich nicht sagen, weil es da schon 
große Unterschiede gibt, was Softwarequalität, Support, Usability, usw. 
angeht.

von Operator S. (smkr)


Lesenswert?

Rene K. schrieb:
> Felix F. schrieb:
>> Wie wärs mit einem SOM (z.B. von Phytec)? Oder gleich einem Raspberry
>> Pi?
>
> Das wäre ja das vernünftigste. Sticht sich aber halt mit der
> Anforderung:
>
> Ocan schrieb:
>> Ebenfalls soll
>> hiermit verhindert werden das Hardware fremdgekauft werden kann.

Inwiefern wäre ein SOM schlechter geschützt als ein Mikrocontroller? Bei 
der fremdgekauftern Hardware geht es wohl nur darum, dass nicht einer 
die Harddisk kopieren kann und dann einen normalen PC kauft.
Bei einem SOM muss man genauso wie beim uC das ganze drum herum noch 
machen. Da nützt es dem Kunden nichts wenn er das SOM kauft und kein 
Baseboard hat. Bzw. wenn ein SOM dieses Risiko besitzt, dann besitzt es 
der uC auch.

Ich würde aus diesen Anforderungen auf jeden Fall ein SOM oder CoM in 
betracht ziehen. Kontron, Phytec, Toradex, Variscite, etc. um nur ein 
paar wenige zu nennen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ocan schrieb:

> - Es soll eine Weboberfläche auf dem Gerät zur Verfügung stehen

> Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft
> und abgelehnt.

Diese beiden Punkte bekommst Du mit einem Einplatinen-µC ohne OS nicht 
in Einklang.

Ocan schrieb:
> Ein mini-pc ist immer noch sehr gross, teuer, und oftmals
> überdimensioniert.

Der Wunsch, eine Weboberfläche zu bieten, ist mit dieser Aussage nicht 
kompatibel. Ist Dir ein Raspberry Pi tatsächlich zu überdimensioniert?

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Frank K. schrieb:
> Microchip liefert alles erforderliche an Software, um diese Teile
> einsetzen zu können.

Auch den Browser? Der TO will eine Weboberfläche auf dem Display laufen 
lassen. Haben das hier alle überlesen?

von Alex W. (Gast)


Lesenswert?

Frank M. schrieb:
> Auch den Browser? Der TO will eine Weboberfläche auf dem Display laufen
> lassen. Haben das hier alle überlesen?

Das hätte ich auch überlesen!

von Rene K. (xdraconix)


Lesenswert?

Frank M. schrieb:
> Auch den Browser? Der TO will eine Weboberfläche auf dem Display laufen
> lassen. Haben das hier alle überlesen?

Ich denke vielmehr er will das das Gerät über eine Weboberfläche 
erreichbar ist oder? Er will auf dem Display keine Webseite anzeigen, 
zumindest habe ich da nichts dahingehend gelesen, und macht auch nicht 
wirklich Sinn. Da das Gerät keine Inputs (Knöppe, Touch, etc...) haben 
soll.

Ocan schrieb:
> Die Geräte lesen nur Seriennummern von Datenträgern
> aus (keine Benutzerinteraktionen)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Rene K. schrieb:
> Ich denke vielmehr er will das das Gerät über eine Weboberfläche
> erreichbar ist oder?

Das sehe ich anders:

Ocan schrieb:
> Es handelt sich um ein Terminalgerät welches über Netzwerk mit einem
> Server kommunizieren soll, und zwar über einen Webservice mit
> http-request.
...
> - Es soll eine Weboberfläche auf dem Gerät zur Verfügung stehen

Es soll ein Terminal sein, welches über http mit einem Server 
kommuniziert. Die Weboberfläche soll auf dem Gerät selbst zur Verfügung 
stehen.

Ich halte das Konzept für unausgegoren. Ich würde das Terminal und das 
Steuergerät mit seinen IOs komplett trennen. Das eine ist für mich ein 
Raspberry-PI oder Android-Gerät, das andere ist für mich ein lan-fähiger 
µC auf einer Platine - meinetwegen mit einem Webserver, aber keinesfalls 
mit einem Browser.

: Bearbeitet durch Moderator
von Rene K. (xdraconix)


Lesenswert?

Ja die Aussagen sind sehr wage, gebe ich zu.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.