Beiträge von Andy

Morgen früh geht´s los, wer Lust hat und ggf auch in der Nähe oder in Hannover ist, kann sich mal melden...

Ja, das mit dem Stromverbrauch ist so eine Sache....einerseits will man maximale (Sende)-Leistung, und andererseits darfs nix "kosten"
Am allermeisten bin ich ja auf diese Webserver-Geschichte gespannt
Wenn es dieses Zeugs vor 30 Jahren zu den Preisen von heute gegeben hätte, wäre ich sicher bei der Elektronik/Elektrotechnik geblieben und nicht zum Maschinenbau abgewandert^^. Wobei ich dort die ersten NC/CNC-Fräsmaschinen aus dem Schrott reanimiert und mit selbst geschnitzten Treiberkarten zum Laufen bekommen habe. Der Antriebs- "Computer" war ein Taschenrechner Sharp PC1401 mit sagenhaften 3534 Byte Speicher. Dieses Gerät hatte ich mit Basic/Assembler programmiert und über die eingebaute einfache TX/RX-serielle Schnittstelle an die NC-Maschine angekoppelt....
Heute zahlt man für einen briefmarkengroßen (wissen die Kiddies überhaupt noch, was Briefmarken sind) vollprogrammierbaren 32-Bit-Microcontroller mit WLAN gerade mal 3 Euro.
Egal, morgen geht´s zur Maker-Faire nach Hannover....sch*** auf das Wetter, fallen die Outdoor-Aktivitäten eben ins Wasser!

Zitat von Raupi

Was genau meinst du damit? Sollen die alle sich mit einem Access-Point verbinden?
Du kannst den Esp selbst als Access-Point konfigurieren. Dann können sich alle anderen Esp mit diesem connecten und du fragst nur den einen ab.

Ja, das mit dem AP weiß ich schon, und nein, jeder einzelne soll ein Server sein, der auch, wenn er mal etwas weiter entfernt ist, erreicht werden kann.
Ich suche jedenfalls ein System, welches autark funktioniert und erreichbar ist, auch im Fall, dass schlimmstenfalls alle anderen ESP ausgefallen sind.

Zitat von Raupi

Auf dem Nano läuft aber eigentlich nichts, weil ich nur die Datenleitungen des Seriell/Usb Converters abreife und die 3 Volt des Spannungsreglers.

ah, ok, das ist die Sache mit dem Leersketch im Arduino, davon hatte ich gelesen. Werde mal weiter googeln

Hi,
ich habe mal einige ESP8266-01 bestellt (testweise auch verschiedene FTDI), den "Saft" von 3.3V hole ich mir über ein Handy-Ladegerät mit MINI-USB-Buchse (5V/3.3V Spannungsregler) und löte das ganze Zeugs auf eine Lochrasterplatine als "Programmer". Ich habe auf einigen Webseiten gelesen, dass beim Programmieren des ESP8266 diverse Pins geschaltet/resettet werden müssen, das würde ich gerne einem Arduino, aber besser noch einem Attiny überlassen.
Wenn ich Schaltungen mit Tastern sehe, die in einer bestimmten Reihenfolge gedrückt/Jumper gesetzt werden müssen, und das ggf. mehrmals so lange bis "es funktioniert", dann frage ich mich ....lassen wir das besser

Zitat von Raupi

Ich selbst programmiere den ESP8266 mit einem Arduino Nano den ich auf ein Platine gelötet habe zusammen mit einem Levelshifter und einem 3,3 Volt Spannungsregler.

So hatte ich mir das letztendlich gedacht . Hast du dazu einen Link/Sketch für die Programmierung?
Programmer mit eingestecktem ESP8266 in USB-Port einstecken, Software ( mit Arduino-IDE? ) übertragen, LED am ESP8266 blinken "alles ok". ESP8266 vom Programmer abziehen und in Stand-alone-Platine stecken, läuft! Da frage ich mich, ob/warum es so ein Ding nicht fertig zu kaufen gibt...

Verwendung ESP8266:
Auf den ESP8266 soll ein Webserver laufen, zunächst sollen einfach nur einige Bytes an Daten "übers Netz" empfangen und diese Daten einige Zeit später auf Nachfrage wieder zurückgegeben werden.

Da wir hier ja im AutoIt-Forum sind, würde ich gerne als "Client" AutoIt verwenden. Hat das schon jemand gemacht? Mit Kommunikation AutoIt/Webserver hatte ich noch nicht viel zu tun, ich hoffe auf Links/Tips/Freaks hier im Forum
Ziel ist, mehrere (viele, ggf 50-100 verschiedene) ESP8266 in ein Interface zu bekommen. Stören die sich gegenseitig im WLAN? Ich gehe mal stark davon aus, aber "Versuch macht kluch"

Hat jemand Infos zum "Stromsparmodus" des ESP8266? Einige 100mA saugen mir in einigen Stunden/Tagen meine LiPo-Akkus leer...

Hi,
Die Funktion StringInstr() sollte dir weiterhelfen.
Unter anderem in der deutschen Hilfe zu finden. Da sich deine Frage auf Zeichenketten/Strings bezieht, und in diesem Kapitel gerade mal auf 30 Funktionen verwiesen wird, wäre eine Internetsuche überflüssig gewesen.
Wobei mich interessiert, wieso du nichts gefunden hast: "autoit text in text finden" in google gibt StringInstr() als 2. Treffer...
"site:autoit.de text finden" in google sucht hier im Forum und listet reihenweise Threads mit diversen Lösungen.

Zitat von autoBert

10*1,5 = 25, wann wurde das neu festgelegt

Richtig ist (ungefähr), dass 10*1,5*1,5 = 25, vergrößert man B und H um je 1,5, vergrößert sich die Fläche auf Faktor 2,25

Wenn ich jetzt mal klugscheißern wollte würde ich feststellen, dass im ursprünglichen Script die Framerate auf 60FPS limitiert ist! Ohne diese Limitierung sind es ca. 80 FPS, einfach herauszufinden indem man _VSync_Wait() auskommentiert.
Wird jetzt das Fenster vergrößert ($iH und $iW = 512*1.5 ), verändert sich die Framerate von ca. 80 auf die von mir festgestellten 33-35FPS. Das wiederum ist ausschließlich auf die Laufzeit von _GDIPlus_GraphicsDrawImage() zurückzuführen (profiling FTW)!

Beim "Blitten" erreiche ich ohne Limitierung 750-760 FPS, bei Vergrößerung des Fensters auf B*2.5 und H*1.5 (Fläche vergrößert auf das 3.75-fache) werden 215 FPS erreicht, also genau die gleiche lineare Abhängigkeit der Laufzeit der Funktion von der Fenstergröße.

Deshalb sollte man sich bei der Programmierung im Hinblick auf Geschwindigkeit auch Gedanken machen, ob der gesamte Fensterinhalt "erneuert" werden sollte! Wenn ein (oder mehrere) "Sprites" im Fenster vor konstantem Hintergrund bewegt werden sollen, dann ist es wesentlich sinnvoller, statt eines "Backbuffers" des gesamten Fensterinhalts nur den aktuellen "Hintergrund" des Sprites (plus nächste Bewegungsänderung) zu sichern und diesen dann nach der Bewegung des Sprites wieder zu restaurieren. Mal angenommen, die Fenstergröße ist 300x300 und das einzelne Sprite 30x30 groß, dann ist der Geschwindigkeitsgewinn nur durch das "teilweise" Blitten ca. Faktor 100 (naja, zumindes irgendwas größer als 80 ) !
Natürlich ist die Verwaltung bei mehreren Sprites aufwendig und kostet entsprechend Laufzeit, daher ist irgendwann der Break-Even erreicht und der Overhead der Sprite-Verwaltung frisst den Zeitgewinn auf....Hier das Optimum zu finden ist der Job des Programmierers!

Anbei ein uraltes Script von mir, eine Demo was per "Blitten" so geht^^
Spirale-Donut-Mona-Lisa.zip

Hi,
in der vorliegenden Form erreichen beide Scripte auf meinem Laptop 60fps.

Vergrößere ich das Fenster im GDI+-Script auf das 1,5-fache, bricht die Framerate auf knapp die Hälfte zusammen, anders gesagt benötigt _GDIPlus_GraphicsDrawImage() statt 10ms nun 25...

Im GDI-Script kann ich aber machen was ich will, Fenstergröße und auch das Quadrat bis aufs 3-fache vergrößern ändert nichts an der konstanten Framerate von 60.

Ich würde wirklich gerne mal den GDI+Code sehen, ab und zu bin ich schon mit dem Debugger durch den Code einiger GDI+-Funktionen gepflügt, aber nach 1/2h rumgespringe durch den Speicher ohne wirkliches Ergebnis verlässt einen dann doch die Lust

....
Man könnte die Taster ja von außen drücken...

Danke erstmal für die Ideen...

Ich hatte an eine mehr oder weniger "interaktive" Darstellung gedacht. Ein Smilie (Durchmesser ca 20cm), der lacht, wenn ich lache, und der traurig guckt, wenn ich traurig gucke, und der mit einem Auge blinzelt, wenn ich das mache. Steuern wollte ich entweder mit Schaltern auf den Fingerspitzen oder in der Hosentasche.

Alternativ wäre ein Abstandsanzeiger "Du bist 1,6m von mir entfernt!", wobei die Entfernung per LED-Ziffern dargestellt wird. Oder als "Lauflicht", welches den Abstand anzeigt.Abstandsmessung funktioniert ausreichend genau per HC-SR04.

Genau so ist der Ablauf!
Deshalb sollte man auch darauf achten, so viele Daten wie möglich "lokal" also im Sinne von einem eng begrenzten Bereich zu bearbeiten.
Es bietet sich an, Daten entweder in sog. "Tiles" oder "Chunks" anzuordnen (idealerweise so groß, dass diese komplett in den L1-Cache passen!), um die Beschleunigung durch den Cache voll auszunutzen. Imho ist der Zugriff auf Daten im Lvl1-Cache 1 Takt, während aus dem RAM je nach Zugriffszeit der Chips mehrere Straftakte auflaufen!
Auch den eigentlichen Programmcode sollte man so lokal wie möglich halten, wildes Umhergespringe veranlaßt den Prozessor jedes mal die Sprungvorraussagen neu zu berechnen bzw. die Pipelines für die Befehlsfolgen neu zu füllen.

Btw. könntest du, um mal die Wirksamkeit des Caches zu demonstrieren, ein Beispiel schreiben, bei dem einzelne Bytes im Abstand von 65 Bytes gelesen (und geschrieben!!) werden!
Wieso gerade 65 Bytes? Weil die Cachelines bei modernen Prozessoren 64 Bytes lang sind und somit immer neu geladen werden müssen, da definitiv ein Sprung über die nächste Grenze geht! Wenn dann noch das Byte wieder zurück in den Speicher geschrieben wird, tritt der SuperGAU auf
Bei 513 Bytes kotzt auch der Lvl2-Cache, so kann man sein Programm locker um Faktor 10 verlangsamen, ohne Sleeps() einzubauen
Übrigens kann man sein eigenes Programm sehr einfach mit dem Task-Manager prüfen. Werden dort viele Cache-Misses angezeigt, sollte man aktiv werden^^

Hi zusammen,

am 28. und 29. Mai findet in Hannover die Maker Faire statt.
Wir (Mama,Papa und zwei "Kinder" (16+22)) werden wieder dabei sein, diesmal aber nicht "nur" als Zuschauer, sondern gewissermaßen "semi-aktiv"
Geplant sind T-Shirts, welche, ausgestattet mit bis zu 32 frei plazierbaren LEDs, um die Wette leuchten. Mehrfarbige und dafür entsprechend weniger LEDs wären eine Option, aber auch alles andere an Sensoren/Aktoren.
Und da sind eure Ideen gefragt!
Die Shirts können bedruckt werden (wir haben aufbügel- und farbig bedruckbare Folien), die LEDs sind als helle, einfarbige SMD-Bauteile befestigt auf der Innenseite der Shirts vorgesehen. Die Verkabelung erfolgt mit Edelstahl-Fädeldraht, die Shirts sollen incl. der "Elektronik" (natürlich ohne Batterie/LiPo) voll waschbar sein.
Angetrieben werden sollen die LEDs über einen Attiny45/85 und einige (SMD-)-8Bit oder 32Bit-Schieberegister bzw. Treiberchips.

Die Prototypen funktionieren schon, der Anwendung an sich fehlt noch ein "Kick". Lauflichter in diversen Varianten sind nicht so der Brüller (eine Frontalaufnahme von KITT/GALACTICA-Droiden mit Lauflicht wurden bereits diskutiert^^), aber ich denke drüber nach, die 4 Personen als "Kette" zu benutzen, verknüpft über Kontakte in den Handflächen

Also immer her mit BlingBling-Anwendungen / lustigen Blinklicht-Geschichten...

AMD A6-3400M APU (Laptop-Quadcore)

- einmal "normal" getaktet @1.4 Ghz
No Cache: 1180.726944
Cache: 398.540398
No Cache Check: true
Cache Check: tru

- getaktet @2.3 Ghz
No Cache: 682.7804259999999
Cache: 255.043579
No Cache Check: true
Cache Check: true

- untertaktet @350 Mhz
No Cache: 4248.2123169999995
Cache: 814.006177
No Cache Check: true
Cache Check: true

was auffällt ist, das je höher der Prozessor getaktet ist, der Cache weniger zur Beschleunigung beiträgt! Jedenfalls bei meinem Prozessor.
Anders herum im Vergleich zu voll übertaktetem Prozessor (2300 vs 350Mhz)
Mit einem Sechtel an Takt läuft der Code mit Cache-Beschleunigung relativ gesehen nur 3x so langsam!!!
Je Takt ist das doppelt so "schnell" wie ein voll übertakteter Prozessor!

Einfach ausgedrückt, je weniger Prozessortakt, desto besser die Cache-Performance bzw. desto deutlicher der "Gewinn" durch den Cache! Genau aus diesem Grund wurden anno Tobak überhaupt Prozessorcaches erfunden

Zitat von Xorianator

Angenommen er würde die Daten in den Cache über die Zeile, statt über die Spalte pre-fetchen, so hätten wir absolut 0 Zeitgewinn gegenüber dem gezeigten Beispiel.

naja, genau darum geht es ja^^

Ein schönes Beispiel ist eine 32-Bit-Bitmap mit einzelnen Pixeln, welche ja bekanntermaßen aus den 4 Farbkomponenten BGRA bestehen. Wieso das so ist, wird immer das sahnige Geheimnis der Entwickler bleiben, genauso hätte man 4 einzelne Bitmaps mit jeweils den einzelnen Farb-Komponenten zusammenpacken können.
Für jeden Farbfilter wäre diese Variante ein Traum, jeden Farbkanal einzeln bearbeiten ist ungleich schneller, man hat 4x so viele Farbinformationen im Cache wie mit der BRGA-Variante! Und das alles mit dem Hintergedanken von Multithreading....Statt bei FullHD 4 mal (je Farbkanal) durch 2MegaPixel zu rennen, bleibt man lokal je Thread in 500MB (je Farbe). Gerade relativ kleine Caches profitieren enorm!
Bleibt zu erwähnen, dass ich genau dieses schon programmiert habe. Aufwendige Filter um Faktor 2-3 zu beschleunigen ist keine Kunst, wenn man "nur" die Ausgangsdaten ins "richtige" Format bringt!
Btw. machen genau das auch hochoptimierte Bibliotheken, nicht nur zur Bildbearbeitung!

"Früher" habe ich mich auch noch für prefetching interessiert, also das vorausschauende Laden von Speicher in den Cache, bin aber schnell auf den Trichter gekommen, dass das bei neueren Prozessoren kontraproduktiv ist

Daher bin ich ein großer Fan des Intel-Compilers, nichts ist besser als eine Software, die WEISS, wie man einen (Intel-)Prozessor RICHTIG anspricht, so das dessen volle Leistungsfähigkeit ausgenutzt wird. Und Leistung kostet, was solls

Hi,
sehr schönes Beispiel der von mir schon zig-fach angesprochenen SoA (Structure of Arrays) vs. AoS (Array of Structures) - "Problematik" (cache pollution).
Einfach mal AoS SoA in google eingeben zeigt div. Anwendungsbeispiele von Beschleunigungen bis zu Faktor 4-5, nur weil bspw. in einer Schleife über Array [ i ][j] anstatt über Array[j] [ i ] iteriert wird.
Übrigens sind aktuelle (Intel-)Compiler in der Lage, dahingehend zu optimieren..., die Zeiten, um aus Schei** Gold zu machen, sind also angebrochen. Wieso "Programmierer" diese imho elementaren Grundlagen von "Programmierung" nicht beherrschen bzw. nicht berücksichtigen (können) darf sich jeder selbst überlegen.

Wieso das bei Autoit nicht funktioniert ist auch klar. Die Verarbeitung/Initialisierung eines Arrays erfolgt nicht in einer wie in anderen Sprachen definierten Struct mit fest zugewiesenem Speicherbereich, sondern über Zeiger auf die einzelnen Elemente. Ich persönlich liebe diese den Datentyp "Variant", wird dadurch doch das schnelle und einfache Programmieren unterstützt. Auf Kosten der Geschwindigkeit, aber das nehme ich gern in Kauf!
Weiterhin ist der Overhead des Interpreters so hoch, dass einige eingesparte Prozessortakte pro Befehl völlig im Grundrauschen der Ausführung verschwinden.
Siehe Beispiele von mir bzgl. optimiertem Sieb des Eratosthenes im µ-It zur Primzahlermittlung. Der 1:1 von AutoIt nach PowerBasic übersetzte Code läuft dort mit Faktor 5 schneller als der ursprüngliche Code. In AutoIt läuft der "schnellere" Algorithmus ca. 3x LANGSAMER, weil der Interpreter 20 Zeilen mehr Code in der Schleife verarbeiten muss....

Wenn ich "schnell" programmieren möchte, suche ich den "inner loop" und schreibe diesen in Assembler (oder jeder anderen Compilersprache) und rufe per DllCall() diese optimierten Routinen auf. Und da merkt man schon bei relativ kleinen Berechnungen bspw. einfachen Filtern (Grafiken mit Full HD ~ 2.1 Megapixel) den Einfluss des Cache, wenn man die Schleife statt von 0 bis Ende, nun von Ende bis 0 läuft. Die im Speicher stehende Bitmap ist nämlich "Bottom-up", d.h. das letzte Pixel steht an der ersten Speicherstelle.

Noch krasser lässt sich der Einfluss des Cache bei Zugriff auf un(mis)aligned Speicherstellen beobachten, da schiebt der Prozessor bzw. Cachecontroller Straftakte ein, von Zugriffen von Bereichen, die sich über die Cacheline-Grenzen bewegen, ganz zu schweigen.

Mittlerweile wird die Hardware an das Unvermögen der Programmierer/Programmiersprachen/Bibliotheken angepasst, neuere Prozessoren "bestrafen" un(mis)aligned Zugriffe nicht mehr, da wird "einfach" für jeden "dämlichen" Zugriff ein Szenario fest verdrahtet, fertig ist die Laube. Der Prozessor wird größer/teurer/energiehungriger, was solls...

Wen das Thema interessiert, der sollte google quälen mit "agner fog cache optimization"

Naja, sobald in einem "anderen" Format bzw. Codepage gespeichert wird, ist das doch relativ schnuppe. Wichtig ist, was mit Autoit eingelesen und dann entsprechend umgewandelt wird!
Poste eine Beispiel-Notepad-Ini, und dann sehen wir weiter...

Hi,
Umlaute funktionieren bei mir einwandfrei...

#include <Array.au3>
IniWrite("test.ini","testsectionäöü","testkeyäöü","testvalueäöü")


$b=IniReadSectionNames ( "test.ini" )
_arraydisplay($b)


$a=iniread("test.ini","testsectionäöü","testkeyäöü","default")
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'Selection:' & @CRLF & '$a' & @CRLF & @CRLF & 'Return:' & @CRLF & $a) ;### Debug MSGBOX

Ich vermute, das Geruckel der GDI-Version hat genau mit der von Mars bereits festgestellten Round() / int() - Problematik zu tun, an den FPS kann es eigentlich nicht liegen. Das Geruckel tritt bei GDI hauptsächlich an den "engen" Wendepunkten der Bewegung auf, bei annähernd gradliniger Bewegung geben sich beide Varianten imho nichts!
Ich habe mal beide Scripte parallel laufen lassen, der Unterschied an den Wendepunkten ist wirklich frappierend. Nicht zu vernachlässigen, dass D2D nicht einige Prozent schneller ist, sondern im vorliegenden Beispiel Faktor 3-5!

#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <Array.au3>


Global $test[3] = ["AAAAAAAAAAAAAAAAAAA", "BBBBBBBBBBBBBBBBBBBB", "CCCCCCCCCCCCCCCCCCCCCCCCC"]


$Form1_1 = GUICreate("Form1", 583, 716, 192, 124)
For $i = 0 To 2
	$test[$i] = GUICtrlCreateRadio($test[$i], 40 + $i * 50, 20, 100, 40, 40, BitOR($GUI_SS_DEFAULT_RADIO, $BS_PUSHLIKE))
Next


GUISetState(@SW_SHOW)


While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit


	EndSwitch
WEnd

Fällt dir was auf?

Seeeehr geschmeidig!
Tearing und ruckeln ist vollständig weg, Geschwindigkeit vorher 10-12ms, jetzt 4-5ms, also ca. Faktor 2.5 schneller als GDI. Aber das wäre mir ziemlich egal, Hauptsache das Geruckel ist jetzt weg!

Hi,
funktioniert einwandfrei!
Allerdings habe ich (egal ob round() oder int() ) einen Effekt, der Tearing ziemlich nahe kommt. Wahrscheinlich hat das aber eher mit der Beispielfunktion zu tun.