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
Ocan schrieb: > Lösungsvorschläge wie "nimm einen mini-PC" haben wir bereits geprüft und > abgelehnt. Warum?
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?
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!
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?
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.
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.
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.
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
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.
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.
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).
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/
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
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.
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.
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.
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.
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
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?
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!
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)
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.