CPU Architektur in REG Modellen

[James_T_Kirk]

Hallo,

ich bereite gerade das Docker Image für die CAN-Kommunikation mit meiner Rotex Wärmepumpe vor. Soweit mir bekannt ist in den REG Modellen ja eine ARM CPU verbaut. Welche Architektur kommt hier zum Einsatz? ARMv8? Als 64 oder 32 bit?

Ähnliche Frage für den CAN Bus... Socketcan kompatibel? Oder Elm327?

Danke schonmal.

[StefanW]

Hallo,

die Architektur ist Cortex A9 MultiProzessor mit ARMv7 in 32 Bit, 4 Kerne, 1st und 2nd Level Cache. Es müsste alles laufen, was für Raspberry Pi 32 Bit kompiliert wurde.

CAN Unterstützung ist noch nicht entschieden, was den SW-Stck betrifft.

lg

Stefan

[Chris M.]

Nur 32 Bit?

Ich kenne mich bei ARM nicht so aus, aber bei x86 gibt es einige Features (gerade Richtung Virtualisierung / Docker) die erst mit 64 Bit freigeschaltet werden. Und der Kollege, der strickt gegen 64 Bit war, hat doch die Firma vor ein paar Jahren verlassen...
(Leichte Polemik mal weg: hat 32 Bit hier überhaupt eine Zukunft? Nicht dass man später nicht nur der OS aktualisieren muss, sondern auch noch von 32 -> 64 wechseln muss. Da das ziemlich Ärger machen wird, frage ich mich welche Strategie dahinter steckt)

[James_T_Kirk]

Danke, dann ist mein Raspi 2 als Testobjekt ja durchaus vergleichbar.
Für CAN setze ich Socketcan auf den Wunschzettel.

@Chris M.: Die neueren Raspis haben zwar 64bit fähige CPUs, das OS ist aber weiterhin 32bit. Da ist irgendwas mit Treibern. Wird hier vermutlich ähnlich sein. Solange nicht mehr als 4GB RAM adressiert werden müssen gibt es da keine Nachteile. Sehe ich hier sogar eher als Vorteile, weil dann die ganzen Raspi Docker Images laufen sollten.

[KNXer77]

Das wurde schon mehrmals im 'alten Forum' thematisiert, z.B. https://knx-user-forum.de/forum/support ... diskussion oder https://knx-user-forum.de/forum/support ... -vor/page2
also- nur Server im Desktop-Gehäuse kaufen.
Ich verstehe sowieso nicht, warum so ein Gerät unbedingt in einem Gehäuse mit 6TE zusammengepfercht werden muß.
wenn es denn mal lieferbar sein wird, kann man die Desktopgehäuse mittels Halterung auch flach in eine Verteilung schrauben (oder halt selbst eine Halterung bauen)
Das hat auch nichts mit der Adressierung von nur 4GB RAM zu tun, schließlich haben die meisten kleinen Server/Hutschienengeräte usw. nur max. 4GB.

[James_T_Kirk]

also- nur Server im Desktop-Gehäuse kaufen.
Ich verstehe sowieso nicht, warum so ein Gerät unbedingt in einem Gehäuse mit 6TE zusammengepfercht werden muß.

Ich sehe das für mich als Vorteil und nicht als Nachteil. Nur weil die CPU Architektur anders ist, heißt es nicht das es schlecht ist. Alles hat seinen Anwendungsfall, bei mir passt ein einzelnes Gerät mit integrierten Schnittstellen deutlich besser, mal abgesehen vom Preis. Für den Anwendungsfall wird die Performance auch mehr als genug sein. Das Wort gequetscht ist beim 2600er auch passend wenn ich mir anschaue was im Gehäuse steckt.

In meinem Fall habe ich eine gut ausgestattete Synology für dickere Container, damit muss ich den TW nicht belasten. Und zu Edomi... so toll es sein mag, ich möchte mich nicht in die Abhängigkeit einer One Man Show geben ohne verfügbare Sourcen und einem Image welches freundlich formuliert nahe seines MHD ist und ohne weiteren Schutz auskommt. Der TW kann doch nichts dafür wenn hier ein uralt compiler verwendet wird, der nicht auf ARM portiert wurde. Wenn sich gaert morgen entschließt das Thema fallen zu lassen steht man blöd da. Ist bei einem anderen (kostenpflichtigen) Projekt schon passiert, der Name ist mir gerade entfallen.

Meine Erwartung an den TW ist das er mittelfristig Logik, Schnittstellen und Visu mitliefert und ich nicht auf externe Projekte angewiesen bin (abgesehen von speziellen Dingen wie meiner Wärmepumpe). Aber wir schweifen vom Thema ab, darum ging es nicht in diesem Threead.

[Dragonos2000]

Und zu Edomi... so toll es sein mag, ich möchte mich nicht in die Abhängigkeit einer One Man Show geben ohne verfügbare Sourcen und einem Image welches freundlich formuliert nahe seines MHD ist und ohne weiteren Schutz auskommt. [...]Wenn sich gaert morgen entschließt das Thema fallen zu lassen steht man blöd da. Ist bei einem anderen (kostenpflichtigen) Projekt schon passiert, der Name ist mir gerade entfallen.

Das ist auch meine größte Sorge und bin da hin und her gerissen. Ich hab' schon Mal ne Menge Arbeit in den Sand gesetzt, weil das Community Projekt erst eingeschlafen und die One-Man Show dann untergegangen ist. Da habe ich nicht nochmal Lust drauf.

Lg
Jochen.

[StefanW]

Ich kenne mich bei ARM nicht so aus, aber bei x86 gibt es einige Features (gerade Richtung Virtualisierung / Docker) die erst mit 64 Bit freigeschaltet werden. Und der Kollege, der strickt gegen 64 Bit war, hat doch die Firma vor ein paar Jahren verlassen...

Docker läuft auch mit 32 Bit auf dem ARM.

Womöglich geht nicht jedes fancy Virtualisierungsfeature, aber das ist hier auch nicht gefordert. Schließlich setzt Docker auf Standard-Linux-Befehlen auf, die es für noch lange für 32 Bit geben wird.

...hat 32 Bit hier überhaupt eine Zukunft? Nicht dass man später nicht nur der OS aktualisieren muss, sondern auch noch von 32 -> 64 wechseln muss. Da das ziemlich Ärger machen wird, frage ich mich welche Strategie dahinter steckt)

Es geht um die simple Beschaffbarkeit. In so einem REG-Modul hat man - bei gegebener Interfacedichte - erheblich weniger Platz für ein CPU-Modul als man glaubt. Und wir haben am Weltmarkt das am meisten leistungsfähige Modul beschafft, dass sich von den Außenabmessungen hier einbauen läßt (und auch das dreifache üblicher Module kostet, weil dessen Fertigung durch Chip-auf-Chip gebonde so teuer ist). In 64 Bit gab es nichts, was reingepasst hätte bzw. es hätte einen soclehn Mega-Umentwicklung notwendig gemacht, die wir uns nicht leisten können und auch der Markt nicht hergibt.

Zudem waren die verfügbaren 64 Bit Module in der Hauptsache für Smartphone und andere Wearables vorgesehen, mit High-End-Grafik und kaum serielle Schnittstellen, das war auch so nicht effizient, für hochperformante Grafikeinheiten zu bezahlen.

Wir sind in der Home-Automation nicht bei den Smartphones mit einem Milliardenmarkt, wo man sich die Chips passend schnizt und backen läßt, sondern in einem beschränkten Nischenmarkt, da muss man sehen, wie man hinkommt.

Wie wir an unserem Sanierungsverfahren sehen, haben uns die Entwicklungskosten auf Dauer eines guten Teils unserer Liquiditätsreserven beraubt, so dass wir dann wegen z.B. der Bauteilkrise in einen Engpass geraten.


Kurz: Es gab weder eine von der Baugröße her passende Auswahl an 64 Bit Modulen noch konnten wir umfangreichere Entwicklungskosten dafür bereitstellen und im übrigen mussten wir auch fertig werden, schließlich warten eine Reihe von Kunden seit 2016 auf das Gerät. Es war schon eine Zumutung von uns für diese Kunden, dass wir uns entschieden haben, das fertige Gerät einzustampfen und auf das neue, erheblich leistungsfähigere, 32 Bit Modul umzurüsten, weil Ihnen das in den nächstren zehn Jahren mehr bringt, sie aber noch ein halbes Jahr drauf warten mussten.

Hätten wir das nun mit einer kompletten und viel aufwändigeren Umentwicklung auf ein 64 Bit Modul gemacht, würden uns die Kunden längst die Haut in Streifen schneiden.

Ich persönlich glaube, dass 32 Bit noch für zehn bis 15 Jahre eine normale Zukunft hat. im industriellen Bereich, im Bereich der Haushaltsgeräte usw. ohnehin und es deshalb auch entsprechende Betriebssysteme und Tools gibt. Wer nicht daran glaubt, kann auf die anderen Produktlinien der Timberwolf Server 2400 bis 2600 zugreifen.


lg

Stefan

[Judas_z]

In diesem Punkt stimme ich dne Vorrednern zu. 32 Bit wird mit an Sicherheit grenzender Wahrscheindlichkeit noch geraume Zeit existieren.
Solange nicht mehr als 4 GB Arbeitsspeicher adressiert werden müssen, gibt es auch wenig Gründe auf 64 Bit zu Wechseln.
Das prominenteste Beispiel ist vermutlich der Raspberry. Kaum ein Gerät wir öfter für verschiedenste Zwecke eingesetzt. Zumindest in den meisten Technik affinen Haushalten.
Obwohl zumindest die CPU des PI3 (evtl auch pi 2, aber davon habe ich atm keine griffbereit) 64 bit unterstützen würden, basiert das OS immernoch auf 32 bit (warum auch nicht, der ist weit von 4 GB RAM aufwärts entfernt).
Das gewählte CPU Modul war schlicht und ergreifend mit Abstand das schnellste, dass wir in die Reg Versionen des Timberwolf integrieren konnten (schaut euch doch mal an was die Konkurrenz verbaut). Wir Entwickler sind immernoch begeistert was die Performance außerhalb der Benchmarks betrifft (also die gefühlten Geschwindigkeit).
Wer Sorgen bezüglich der Zukunft der 32 bit Architektur hat kann ja immernoch aus der Desktop Serie wählen.
64 Bit gibt es schon ewig. Angefangen sich wirklich durchzusetzen hat es sich erst, als man zumindest als technischer Entusiast mehr als 4 GB RAM leisten konnte (mein erstes 64 bit System lief noch unter Windwos ME 32 bit und da blieb es auch). Trotzdem hat sich das bei Geräten unter 4 GB RAM die letzten 10-15 Jahre noch nicht wirklich durchgesetzt. Warum auch?
Ich bin mir sicher, dass 32 bit auch teislweise dank dem Raspberry und zahlloser anderer Hardware noch einmal mindestens diesen Zeitraum noch einmal überleben wird. Zumindest im Bereich der industriellen Hardware. Solange ein Mixer oder was auch immer nicht mehr als 4 GB Arbeitsspeicher brauchen wird, gibt es auch schlicht und ergreifend keinen wirklich kritischen Punkt, an dem das geändert werden müsste.