Gestern, also am 19.11.2024, erfolgte der Stoß: ab 17 Uhr war der Download möglich. Ist klar, das dauerte und die fast gelungene Install wurde zum abendlichen Feierabend abgebrochen. Heute morgen gings weiter und nach überschaubarer Zeit war sie auch fertig. Was nicht hieß, dass da irgendwas funktionierte! Nach dem Start wurde erst wieder kräftig geladen, dann sollte die persönliche Anmeldung erfolgen, was aber mehrfach nicht gelang. Im Verlauf des Nachmittags gelang es dann, was aber auch nichts nützte, denn was auch immer man aufrief, der Ladebalken drehte sich und das Meiste startete erst gar nicht. Die Gründe dafür waren schnell ausgemacht: extreme Überlastung der Microsoft-Server und die Grundkonzeption der Simul-Anlage.

Der "revolutionäre" Gedanke für diese neue Version des Simulators war, nicht wie bei bisherigen Versionen nahezu alles Benötigte auf die Festplatten der User zu laden, sondern dort nur eine eher schmale Grundinstall - so vielleicht 50 GB - anzulegen, und wenn sich dieser User dann für irgend'ne Mission entschieden hatte, dann sollte alles weitere Benötigte wie Daten für Landschaft, den Flieger, das Wetter, etc. "live" aus der Cloud geladen werden. Ohne Cloud nix Flusi. Und da nun fast die ganze Welt wusste, wann der Flusi24 in Betrieb gehen sollte, hängen die nun ALLE in den Leitungen und baggern die Microsoft-Cloud an.
Tolle Wurst: alles bezahlt, alles erfolgreich installiert, die Hardware-Voraussetzungen passen definitiv noch, aber es lässt sich kein Flieger laden und schon gar nicht mit dem im Himmel rum kratzen! Einigen soll es gelungen sein. Hängt wohl von Zufällen und Geduld ab, gepaart mit vieeeeeeel verbrachter Zeit.
Für den Neuen hatte ich den Alten gekillt, um Platz auf der M2-SSD zu bekommen und auch das Win11-System restauriert, will sagen: eine Reparatur/-Neuinstall - im Win-Speech: Windows zurücksetzen - ausgeführt. Alles Vorige weg, alles neu, und gettz ist Hängen im Schacht. Das kann ein laaaaaaaanger Hänger werden!
Grüße, picass

Zitat von: picass in Gestern um 10:42:04 CETUnd wenn Phyton und C viele Gemeinsamkeiten aufweisen sollten...

Viele Hochsprachen werden in der Syntax oberflächlich viele Ähnlichkeiten aufweisen.

Solange man vom Bauraum und dem Energieverbrauch nicht eingeschränkt ist, kommt man
mit Raspi, ESP32, ItzyBitzy, Arduino ... aufgrund der vielen fertig vorhandenen
Bibliotheken und Beispiele sicher schnell und ohne große Einarbeitung voran.

Wenn ich mal wieder länger Zeit habe, werde ich mich auch nochmal in CircuitPython vertiefen ;-)
https://circuitpython.org/

Zitat von: vloki in 19.11.2024, 10:57:02 CET"C" für einen 14K22 hätte kaum anders ausgesehen

Was die "richtige" Programmiersprache anbelangt, bin ich ganz sicher nicht im Besitz der reinen Lehre, sondern schlichtweg ein Suchender.
Hatte mich jahrelang um eine Entscheidung, Assembler zu verlassen und endlich eine Hochsprache zu erlernen versuchen, rum gedrückt. Mal ehrlich: bei dieser Suche hatte ich mich immer wieder an Beiträgen in der von mir hoch geschätzen "c't" und verschiedentlich auch der Schwester-Zeitschrift aus dem Heise-Verlag, der "make:" orientiert. Deren Redakteure propagierten seit Jahren schon MicroPhyton. Aber - wie schon erwähnt - waren das unterm Strich immer nur so Schnupper-Proben und aus meiner Sicht nichts Handfestes.
Nach Jahren des Zweifelns habe ich nun mit Gewalt den Knoten zu durchschlagen versucht. Die Anfänge lassen es für mich sinnvoll erscheinen, den Faden auch weiter zu verfolgen. Ich bitte um Verständnis, dass ich diesen Versuch auch fortführe, um nicht wieder in die Phase der Zweifel zurück zu fallen.
Wenn es denn mit MicroPhyton - oder wie im Moment eher mit Phyton - doch in die Nähe von "C" rückt, kann das ja keine schlechte Sache sein. Immerhin sind die vielen Klammern erst mal nicht nötig. Ihr seht, ich versuche, der Lage Positives abzugewinnen und endlich mal zu wissen, in welcher Richtung es weiter gehen könnte. Und wenn Phyton und C viele Gemeinsamkeiten aufweisen sollten, dann kann ja auch dein Script plötzlich wieder zu unerwarteten Ehren kommen, Volker.
Grüße, picass

Danke, muss ich mal ausprobieren, ich arbeite noch mit dem c18, der ist offenbar noch ANSI 89 kompatibel.

XC8 v2.46

welchen C-Compiler hast Du da genommen? Ich habe irgendwie in Erinnerung, das meiner (c18) mit "float" Probleme hatte.

oder für einen 25K22
(Ich hoffe der C Compiler rechnet nicht schlechter als der Python)

Zitat von: picass in 18.11.2024, 15:38:58 CETdas sind die Kombi aus dem µC ,,Raspberry Pi Pico" und Python.

"C" für einen 14K22 hätte kaum anders ausgesehen

Zitat von: PICkel in 18.11.2024, 19:50:05 CET@picass:
Das (mit mikroBasic) kompilierte Testprogramm belegt incl. Wertezuweisungen gerademal 261 Flash-Speicherplätze. Soviel zum Thema "Gleitkomma und 8Bit". In ASM hätte ich das allerdings nie lauffähig bekommen.

Ob mit MikroBasic oder Python....., vermute mal, dass der Platzbedarf sich da wenig unterscheidet. Was die Geschwindigkeit anbelangt, könnte man auch zu einem 32-bit-PIC greifen. Einen solchen hatte ich ja auch schon mal mit MM-Basic ans Laufen bekommen, den PIC MX 170F256B-50I/SP. Dieser 32-Bitter wäre bestimmt auch eine gute Lösung gewesen. Nur hatte ich das Basic-Programmieren danach nicht weiter verfolgt. Und ja - an dieser in einem anderen Fred teil-vorgestellten Formel hatte ich mir unter Assembler die Zähne ausgebissen. Vielleicht hätte es irgendwann ja geklappt, aber den Zeitaufwand dafür war ich nicht mehr bereit, zu investieren. Ich gestatte mir die  Ansicht, dass es Quatsch ist, Räder immer wieder aufs Neue erfinden zu müssen. Stattdessen halte ich es für eine gute und akzeptierte Arbeitsweise, geschaffene Kulturgüter - dazu zählen für mich auch Programmiersprachen und z.B. aufwendige Bibliotheken für die Verbindung von µCs und Sensoren - fertig wie sie sind zu nehmen und zu benutzen. Is klar, ein Hinweis auf die Quelle oder den Urheber darf und sollte schon sein.

MicroPhyton ist - wenn ich das richtig verstanden haben - eine gegenüber Python noch etwas vereinfachte Sprache. Und Python wäre ein Prog auf Grundlage von "C". Mal schauen, ob mir der Einstieg gelingen wird. Da gabs zunächst mal Überraschendes für mich. Gleich 3 Sonderhefte über Programmieren von µCs habe ich angesammmelt, das Älteste von 2022 und auch ein Brandaktuelles. Alle geben vor, u.a. einen Einstieg in Progr. mit MicoPython zu bieten. Tun sie aber nicht, das sind irgendwie Mogelpackungen. Tatsächlich stellen sie ausführlich die Hardware z.B. des Pi Pico vor und dann werden Progr.-Schnipsel aus wenigen Zeilgen eingestreut, mit welchen sich diverse Sensoren oder Anzeige-Displays in Betrieb nehmen lassen. Für mich sieht das so aus, als ob Journalisten sich die Datenblätter diverser Sensoren genommen und die dortigen Prog-Schnipsel dann zu einem "Sonderheft über Programmieren" verarbeitet hätten. Versucht mans derart, stellt man verblüfft fest, dass über die Programmiersprache selbst nahezu nichts geboten wird. Es wird dauern, sich da rein zu arbeiten, mal schauen, was wird.

Danke für deine Wünsche, auch von mir einen Daumen fürs Mutmachen.
Grüße, picass

@picass:
Na dann wünsche ich Dir viel Erfolg beim Programmieren mit Python und dem RasPi!
Assembler für PICs tue ich mir auch nur im absoluten Ausnahmefall an. Aber um bei Deinem Gleitkommaarithmetik- Beispiel aus der Rubrik "PIC-Assembler Arithmetik" vom 17.11.24 zu bleiben:
Der Ausdruck: 45726,23 / 17891,82 wird von einem "popeligen" PIC12F683 @4MHz in weniger als 1ms berechnet. (Die Zeit zwischen den beiden NOP-Befehlen.)
Das (mit mikroBasic) kompilierte Testprogramm belegt incl. Wertezuweisungen gerademal 261 Flash-Speicherplätze. Soviel zum Thema "Gleitkomma und 8Bit". In ASM hätte ich das allerdings nie lauffähig bekommen.
Natürlich sind fertige Bibliotheken für diverse externe Komponenten (BOSCH-Sensor) eine extreme Erleichterung bei der Programmierung und ein guter Grund zum Systemwechsel.
In diesem Sinne: Gutes Gelingen!

PICkel