Habe ich gemacht!
Habe ich gemacht!
hab mir die videos angesehen, das unterschiedliche verhalten würde ich den unterschiedlichen "sender" apps zuschreiben. Übrigens, soviel ich weiss, blockiert ein delay wirklich alles...
gruß inka
leider nein, ich kenne den app-inventor nicht, aber das verhalten wird schon ein anderes sein als bei Ardroid...
gruß inka
Hallo fredyxx,
Das ist jetzt halt der Unterschied zwischen der Klötzchen-Programmierung und einer Programmiersprache!
Logisch machen beide Varianten das Selbe, die Wege sind aber unterschiedlich.
Über eine Programmiersprache kann man alles steuern und hat auch die Übersicht, was unmittelbar zusammengehört. Man kann also in deinem Fall die Teil-Texte zuerst in einem Puffer zusammensetzen und dann den gesamten Puffer ausgeben. Man weiss, dass zwischen dem ersten und dem zweiten Teil nicht etwa 10 Sekunden noch etwas anderes gemacht werden muss.
Bei der Klötzchen-Programmierung braucht man definierte Zustände, wenn so ein Klötzchen abgearbeitet ist. Dazu gehört halt auch, dass Sendepuffer sofort geschrieben werden. So ein einzelnes Klötzchen weiss nicht, wie es nach ihm weiter geht.
Ein weiterer Punkt ist noch, dass die Klötzchen-Geschichte langsam ist. Da ist für jedes Klötzchen zuerst einiges vorzubereiten und nach Beendigung wieder aufzuräumen. Zudem ist das meistens ein Interpreter.
In beiden Varianten muss zwischen den beiden Teil-String noch etwas gerechnet werden. Bei den Klötzchen fällt die Rechenzeit halt auf. Vermutlich ist bei beiden Varianten bei der Ausgabe eine Pause dazwischen, aber 1/10 Sekunde fällt nicht wirklich auf.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Hallo,
endlich habe ich die Ursache gefunden, die nichts mit AppInventor oder Klötzchen-Programmierung zu tun hat, und wenn man die Lösung kennt, primitiv ist!
In meiner ersten Frage seht ihr, dass ich beim Einlesen eines empfangenen Telegramms als Endezeichen ein \n erwarte.
Vom Tablet hatte ich gesendet:
Richtig ist aber:
Damit klappt nun alles super schnell und ich bin happy.
Trotzdem danke für eure Hilfeversuche.
vG
fredyxx
Immerhin hat es sich bestätigt, dass es ursächlich nicht, wie ursprünglich von dir vermutet, am Empfänger/dem Arduino liegt, sondern Sender-seitig.
Dass es der Sender-Programmiercode war, ist sicher gut, da solche Fehler beseitigt werden können.
(y)
Geändert von HaWe (27.02.2017 um 22:02 Uhr)
noch ein Hinweis zu der Klötzchen-Programmierung :
Diese bauen (fast) ausschließlich auf Interpretern auf, die einen mehr oder weniger vorverarbeiteten Zwischencode (oft Bytecode) erst noch während der Laufzeit in ausführbaren Code übersetzen müssen, bevor er dann ausgeführt werden kann.
Ich habe einmal verschiedene Benchmark-Tests zu diesen IDEs durchgeführt. Dabei hat sich bestätigt, dass viele(!) dieser Interpreter-Systeme (Klötzchen oder auch Text-Basiert) bis zu 100x langsamer sind als native Executables (per GCC oder clang).
Es gibt aber auch sehr viele Interpreter, die schlauer sind, z.B. der JIT-compiler ("Just-In-Time") von Java (C# Mono macht es ähnlich) - vereinfacht ausgedrückt: hier übersetzt der Compiler während des Interpreter-Betriebs häufig benutzte Teile des Codes in Executables, die dann genau so schnell sind wie C-compilierte executables.
Und tatsächlich haben Java-JIT- und C#-basierte Interpreter fast genaus so schnell abgeschnitten wie native Executables, wenn der Code öfter ausgeführt wurde - beim ersten Mal waren sie nur 1/10 so schnell.
Ältere oder einfachere Java-Compiler waren dagegen immer deutlich langsamer (1/20).
Gerade auf Androids laufen viele Apps per Java, auch mit JIT-Compilern.
Und gerade Klötzchen-Programmierung setzt ot auf Java auf, und daher kann es durchaus sein, dass nach ein paar Sekunden dein Klötzchen-Code schon ähnlich schnell ist wie "richtig" compilierter - dennoch muss man den Intepreter kennen bzw. testen, denn er kann möglicherweise auch dauerhaft z.B. nur 1/100 der erreichbaren Geschwindigkeit bringen.
Lesezeichen