man trainiert mehrere Eingabemuster gemeinam mit enem jew. Ausgabemuster (Ziel), z.B
000
0
(training)

010
0
(training)

100
0
(training)

110
1
(training)


dadurch lernt das Netz, die verschiedenen Eingabemuster zuzuordnen.
Dabei werden nicht die Einzelmuster gespeichert, sondern die Neuronen verändern ihre innere Struktur für alle Muster gemeinsam:
sie bilden eine interne Variablen-Matrix aus internen Gewichten und Thresholds, die auf alles gemeinam passt.

gibt man nun ein
011
drückt man auf
(erkennen)
dann wurde dieses Muster bisher nicht trainiert, trotzdem wendet das Netz seine Matrix auf dieses Muster an und erzeugt ein Ergebnis, das irgendwie zu den bisherigen Mustern passt, möglicherweise wird es auch eine 1 sein, aber das muss man ausprobieren: es lässt sich nicht vorhersagen.

Als Inputschicht könnte man die obersten 9 Zeilen des html-Buttonpads verwenden, als Ausgabeschicht die unterste, 10.

Ich bin aber gestern abend/nacht auf eine Sache gestoßen, als ich ein einfaches meiner alten Netze auf den ESP8266 portieren wollte:

alle meine bisherigen MCUs konnten Multithreading (Lego NXT und Arduino Due), und beiden machte es nichts aus, wenn eine Funktion für eine Berechnung sehr lange gebraucht hat (Minuten bis Stunden).

Der ESP8266 kann aber überhaupt kein Multithreading, und er stürzt ab und rebootet, wenn eine Funktion den Prozessor länger als wenige (1-2) Sekunden komplett mit einer Berechnung belegt. Training aber kann mehrere Stunden dauern, und auch Auswertungen (Erkennen) zumindest mehrere Sekunden

Das zweite Problem lässt sich vielleicht (!) durch etliche delay(1) in der Trainingsfunktion kaschieren (weiß ich noch nicht),
aber Mutithreading ist unverzichtbar, wenn man im Betrieb das Gehirn (ich nenne es HAL) simultan Muster bearbeiten als auch Inputs, Steuerbuttons und das Display bedienen soll.
Würde man das alles Spagetticodemäßig hintereinander schreiben, wird es nicht nur unübersichtlich, sondern auch extrem langsam, weil dadurch die sehr schnellen Gehirnroutinen im Mikrosekunden-Bereich ausgebremst werden durch TFT-Anzeige- oder GPIO- und html-Abfrageroutinen, die man nur 1x pro Sekunde aktualisieren muss.
Ein dritter Grund, was gegen den ESP8266 spricht: er hat zu wenie GPIOs, um auch zusätzlich neben lokalen Pin-Buttons eine SD-Karte per SPI anzusprechen.

Der ESP8266 macht daher keinen Sinn als Basis für ein NN, zumindest bei meinen NN-Pogrammen, die ich bereits geschrieben habe.
Es müsste ein Arduino Due sein wie früher, der kann aber keinen Webserver aufbauen,
oder ein esp32 ,
denn nur diese beiden können derzeit Multithreading (Due Scheduler bzw. std::thread).

Da der Due wegen mangelndem html aber komplett rausfällt und wir auch kein Hardware-Buttonpad haben, bleibt nur mein ESP32 als einzige Basis (meiner hat ein Adafruit Feather HX8367 Display) , für die ich die NNs neu programmieren könnte.
Allerdings verwendet der ESP32 auch etwas andere wifi- und webserver libs als der esp8266.

Mir ist daher jetzt noch nicht klar, wie es weitergehen kann, und ob es Sinn macht, zunächst mit den esp8266-html-Buttons zweigleisig zu fahren, mit absolut ungewissem Ausgang...