Raspberry Pi & Delphi noch jemand?

[Codehunter]

Zitat von Mavarik:

Aber ich könnte mir vorstellen, dass die CE einen Linux Arm 32 Bit Compiler bekommt.
Und der "richtige" Compiler (64 Bit Intel) nur in der Enterprise enthalten ist.

Richtig und das wäre für den RPi und verwandte Platinchen völlig ausreichend. Nur darum ging es ja hier im Thread. Sowas könnte ja nicht nur Delphi voran bringen sondern auch den RPi.

Zitat von Mavarik:

Ich gehe mal davon aus, das EMBT erstmal "Sachen" Integriert, die mehr Geld oder mehr zahlende Kunden bringen.

Das haben sie ja auch immer wieder demonstriert. Vielleicht ist das kurzfristig lukrativ. Langfristig wäre es aber cleverer, Delphi weniger als Produkt und mehr als Ökosystem zu betrachten.

Das musste Microsoft auch schon auf die harte Tour beim Windows CE/Mobile lernen. Vom Betriebssystem bis zur Entwicklungsumgebung wurde alles teuer verkauft. Heute ist Win Mobile Geschichte und bringt keinen Cent mehr ein. Google verschenkte sowohl Android als auch Studio, ist Weltmarktführer mit ~ 80% Marktanteil und verdient sich dumm und dämlich am Store.

Das nur mal so als Denkanstoß in Richtung Emba

[himitsu]

Zitat von Rollo62:

Ich war eigentlich schon 150% bei RasPi, was mich dann aber von einem
Versuch damit wieder zurückgeworfen hat war eine Info das Broadcom keine neue CPU mehr dafür rausbringen wird.
...
Nun gut, man kann sagen wenn RasPi ausstirbt wird es den nächsten geben, und man kann das schnell anpassen.
Wie sehr Ihr das Thema für euche Projekte ?

Nunja, im RPi4 ist ja immernoch/wieder ein Broadcom (BCM2711) drin.
Und es gibt von mehreren Konkurenten Alternativen mit einem verblüffend ähnlichen Layout der Anschlüsse und des GPIO (ASUS Tinker), womit ein Austausch weniger Probleme bereiten würde.

Nur der Lattepanda ... naja, der ist schon bissl teuer, hat ein anderes Anschlusskonzept, und mit dem selben Innenleben und mehr Speicher gibt es wesentlich günstigere NichtbastelminiPCs, welche man um eine günstige USB-IO-Karte erweitern kann (Minisforum usw.)
oder der Rock Pi X bzw. ROCK64, ebenfalls mit Intels X5-Z83.
Und wer gern mit Netzwerken, Routern usw. spielt, aber keinen GPIO benötigt, da klingt der NanoPI doch ganz nett.
Leider die einzigen echten Alternativen, so lange Embarcadero das Hirn an der richtigen Stelle fehlt Delphi nicht in Lage ist, um weitere "verbreitete" Plattformen richtig/überhaupt zu unterstützen.
Ich mag vielleicht auch bissl sauer sein, dass ich ausversehn Android-Geräte mit Intel-CPU besitze.

Rasperry mit Windows IoT klingt erstmal toll, aber IoT und Delphi vertragen sind nicht ,
Rasperry mit Android wäre denkbar, aber ein paar Vorteile des Raspian (oder anderer "richtiger" Linuxoide) gehen verloren.
HTML5-Builder (Delphi for PHP usw.) ... naja, das Webzeug läuft zwar praktisch überall, aber nutzt jemand richtig/vorwiegend diesen Teil der Delphi-Familie?

Man hat ja nun schonwieder Linux im Programm (viel zu spät, abgesehn von Kylix), aber so man lange dort nicht auch für ARM kompilieren kann,
ist man mit Delphi für Kleingeräte auf iOS/Android oder eben auf die Intel-CPU angewiesen.

Ach ja, Rasperry Pi mit Wine ... grundsätzlich lassen sich einfachere Delphi-Programme dort betreiben, auch wenn es ein paar kleinere Hindernisse gibt, vor allem sobald z.B. neuere WinAPI verwendet wurden, oder z.B. die Darstellung von DevExpress leidet auch hier und da etwas und bei den verwendeten Fonts muß man etwas aufpassen, da die Standardfonts von Delphi (Verschiedene über all die Jahre) in Wine/Rasperry standardmäßig fehlen und somit sich die Anzeige/Länge ändert.

[Codehunter]

Hatte Emba vor nicht allzu langer Zeit sogar selbst mit Delphi for IoT geworben?

Ich glaube, die Marketingabteilung hatte hier nur das neueste Buzzword aufgeschnappt. Alles was Delphi aktuell hat ist konzeptionell so eine Art "IoT machen die anderen, wir greifen nur die Daten ab".

Eine native Delphi-Anwendung auf einem IoT-Device kann ich mir aktuell nur mit einem der teureren Raspi-Alternativen auf x86-Atom-Basis vorstellen. Da könnte man dann ein Linux drauf laufen lassen und ein Delphi-Enterprise-Kompilat ausführen.

Das verleitet mich doch glatt zu einem Autovergleich: Man kaufe je einen fabrikneuen Ferrari und Opel Corsa, schraube aus dem Ferrari den Motor raus und bastle ihn in den Corsa. Zwar hängt dann wegen der Frontlastigkeit das Hinterteil in der Luft, macht aber erstmal nix, denn Dank Frontantrieb bewegt sich die Kreatur irgendwie. Im Stadtverkehr wird man zwar vom Serien-Corsa überholt, aber egal. Hauptsache auf der Viertelmeile brennt die Piste.

[Daniel]

Habt Ihr mal einen Blick in das Get-It Repository geworfen?
Die IoT-Plattform, die Delphi adressiert, ist Android. Dafür gibt es auch reichlich Materialien, Code, Komponenten.
Klar gibt es eine Unzahl weiterer Plattformen, ich wüsste allerdings kein Entwicklungswerkzeug, welches ALLE seriös adressieren könnte. In meinen Augen kann das bei der Dynamik, die da herrscht, auch kein sinnvolles Ziel sein.

[himitsu]

Ich weiß, das IoT im Namen von Windows ... halt quasi sowas wie WinRT, wem dieser Name noch etwas sagt.

Jupp, im Delphi geht es um die Verbindungen zu Geräten im Bereich IoT.
Und bei Microsoft um das Betriebssystem, für kleinere Computer auf ARM-Basis, für diesen Bereich.

Lazarus?



Wie gesagt, viele Kleinsgeräte basieren heutzutage nunmal auf ARM und irgendeinem Linux-artigen OS.
Selbst Android und iOS nutzen intern ein Linux Unix und meistens auch mit einem ARM, also sooo fremd sind für Delphi Linux und ARM nun auch nicht.
Gut, dass dort oftmals immer mehr Speicher verbaut wird und damit die wachsenden Delphi-Kompilate ausgleichen würde.

[Codehunter]

Ach DESWEGEN hieß der Ford damal Taunus! Weil man damit nur im Taunus fahren konnte

Also IMHO ist das Label "IoT" bei Delphi eine Mogelpackung. Android ist kein IoT-OS sondern dediziert als Mobil-OS entworfen worden. Wenn man es jetzt dazu vergewohltätigt, dann doch eher als Notlösung weil man Anwendung X nicht anders zum Laufen kriegt.

Vom Energieverbrauch mal ganz abgesehen. Eine FMX-Anwendung auf Android verbrät schon einiges. IoT-Geräte sollen doch vorallem sparsam sein.

[oldjoe]

ich entwickle nun seit über 30 Jahren und seit Delphi 1; vorher mit C unter Unix, als es noch Turbo Pascal gab.
sry, aber das ist schon erstaunlich, wie ihr hier alles mögliche in einen Topf werft.

Die Suche nach der "eierlegenden Wollmilchsau" sollte man sich abschminken - weil sie einfach keinen Sinn macht.
Zu "LibreOffice": man sollte berücksichtigen, dass es ein gewaltiger Unterschied ist, ob man sich im Businesssektor, im privaten Bereich oder lediglich im Umfeld von "Basteleien" bewegt.

Ich liebe Delphi. Aber sobald es um Netzwerk-Schnittstellen bis hin zu Web geht, ist es in meinen Augen schon relativ schwach oder es fallen Kosten im Nachgang an, die mit einer anderen Lösung nicht entstehen (Thema UniGui und Delphi IoT). Aber es darf sich auch gern jeder äußern, welche tolle Projekte er mit DelphiPHP, DelphiHtml usw. gemacht hat.
Doch, ich habe ein größeres erstellt mit Delphi Web-Komponenten - mit dem Ergebnis, dass IPv6 nicht unterstützt wurde, die Server-dcu nicht im Quellcode vorlag und alles mit SSL der Horror war. Indy war keine Alternative. Das Projekt konnte ich dann einstampfen - ich weiß, wovon ich rede.
Sorry, aber vieles davon kann man unter Linux mit einer Batch oder anderen einfachen Lösungen abdecken, womit man sich mit Delphi in diesem Bereich herumquält.

Cross-compilieren: Hat sich schon mal jemand mit Handy-Apps, also dem ARM-Emulator beschäftigt? Wenn da jemand sagt, dass das Spaß macht, wie lange das dauert, bis die Applikation mal im Emulator startet, dann werde ich ihm schlichtweg nicht glauben.

Wo aber Delphi mmn. richtig stark ist, ist in der IDE und in der Erstellung von nativen Routinen und da möge niemand behaupten, dass C um so viel schneller sei. Die erzeugten Binaries von Delphi sind sehr performant, aber man muss eben auch etwas dafür tun und nicht einfach nur auf HighLevel Programme erstellen.
In meinen Augen hat alles (Python, Delphi, VB/C#.net usw.) seine Berechtigung, aber nur "EINES" für Alles verwenden zu wollen, halte ich für grundverkehrt.

Ja, Delphi compilierte Binaries für Raspberry hört sich interessant sehr an. Ich würde da aber den Weg gehen und erst mal eruieren, welche Schnittstellen man zwischen Delphi und bspw. Python aufbauen kann, um die Stärken und bereits existierenden Scripts unter Delphi mitnutzen zu können. Unter Windows macht es bspw. richtig Spaß, wenn man Delphi mit Javascript koppelt.

[Codehunter]

@oldjoe: Da hast du 100% Recht! Ich habe manchmal den Eindruck, wenn vom "IoT" geredet wird, dann meinen manche Leute eine Art Tablet, das nur irgendwie an die Wand genagelt wird.

Wenn ich von IoT rede, dann meine ich z.B. für ein kleines dörfliches Freibad mit dem Raspi realisiert habe: Ein Temperaturfühler in der Umwälzanlage zum Erfassen der Wassertemperatur und Übermittlung an die Webseite. Auf dem Webserver läuft PHP, da war REST einfach gebaut. Auf dem Raspi musste ich mich mühsam in Python einarbeiten. Was frustrierend ist wenn man für so was simples etliche Tage braucht und genau weiß, man wäre mit Delphi in 2 oder 3 Stunden fertig gewesen. Nur wozu soll ich auf dem Raspi Android installieren, eine FMX-Anwendung programmieren, wenn die Kiste doch headless laufen soll? Dafür bräuchte ich einen ARM-ELF-Compiler, damit ich ein simples Konsolenprogramm erzeugen kann. Also genau das, was Delphi Enterprise für x86-64 mitbringt.

Der ARM-Compiler ist ja IMHO eigentlich gar keiner von Emba sondern der von Google. Und ja, ich finde das USB- bzw. Remote-Debugging mit Android auch eine ziemlich zähe Angelegenheit.

[Stevie]

Zitat von Codehunter:

Der ARM-Compiler ist ja IMHO eigentlich gar keiner von Emba

Doch, ist er.

[TurboMagic]

Das Compiler Frontent müsste wohl von EMBT sein, da die wissen, wie Delphi zu parsen ist etc.
Aber das Backend? War das nicht LLVM bei den neueren Compilern?
Und sollte die Schnittstelle zwischen Frontend und Backend bei den neueren Compilern
nicht immer dieselbe sein?

Das Problem ist halt, dass nicht nur ein passender Compiler benötigt wird, sondern auch eine
auf das Zielbetriebssystem angepasste RTL.