Projekt NodeSP verbessert, Vorträge ergänzt

epvpn
kln 3 years ago
parent 7ae9fa32ad
commit b9c820b857
  1. 29
      content/projekt/NodeSP.md
  2. 10
      content/vortrag/Go.md
  3. 7
      content/vortrag/Godot.md
  4. 8
      content/vortrag/Kicad.md
  5. 8
      content/vortrag/LPWAN.md
  6. 9
      content/vortrag/Vue.js.md

@ -43,6 +43,9 @@ können.
+ Für die Meßwerte sollen keine Vorinformationen vorliegen (d.h. beliebige
Daten sollen verarbeitet werden können).
+ Neben der Fourier-Transformation soll auch die Inverse berechnet werden
können.
<br/>
<br/>
@ -55,13 +58,19 @@ So wird die Korrektheit der Implementierung verifiziert.
Nachdem in meinem Vergleichsfeld ein 'schnellster' Algorithmus ermittelt ist (es liegen mehrere
10er-Potenzen - in [µs] gemessen - zwischen den verschiedenen Implementierungen), habe ich diesen
in 'native' ESP32 umgeschrieben (für mathematisch Interessierte: http://www.katjaas.nl/home/home.html).
Es zeigt sich, daß die aktuelle Kombination VSC/PlatformIO/Xtensa-Debugger
in 'native' ESP32 umgeschrieben (für mathematisch Interessierte: http://www.katjaas.nl/home/home.html).
Zunächst gilt es, die Parameterübergabe zu klären, d.h. welche Parameter werden in welchen Registern
übergeben. Dann muß man die Dokumentation zur Inline-Assembly des GCC zusammensuchen und last (but not
least) muß natürlich der Assembler-Guide "Xtensa® Instruction Set Architecture (ISA) Reference Manual"
durchgearbeitet werden (https://0x04.net/~mwk/doc/xtensa.pdf).
Im praktischen Teil zeigt sich, daß die aktuelle Kombination VSC/PlatformIO/Xtensa-Debugger
noch reichlich 'buggy' ist. Beim Single-Stepping durch den Code kommt es immer wieder zum 'Rausfliegen'
(Rücksprung in die übergeordnete Funktion). Außerdem klappt es mit dem Disassemblieren häufig nicht so
recht, d.h. Opcodes werden falsch gelesen bzw. an 'falschen' Adressen mit der Disassembly begonnen
(erkennbar häufig an der komplett sinnfreien Bedeutung des Codes, gelegentlich auch an eingefügten
.byte-Instruktionen - die hier eigentlich nichts verloren haben ...).
Trotz dieser Widrigkeiten habe ich schließlich eine funktionierende Version realisiert.
Ergebnis:
@ -72,7 +81,7 @@ Kopfkratzen bin ich zu folgenden Erkenntnissen gelangt:
+ Der limitierende Faktor ist vermutlich der Speicherzugriff. Der ESP32 hat keinen Cache, d.h. alle
Speicherzugriffe bremsen unmittelbar. Bei größeren Meßwertmengen schlägt das überproportional durch
(Speicherzugriffe von C<->Assembler sind aufgrund der leistungsfähigen Befehle des 'Instruction Sets'
gleich schnell).
gleich schnell, d.h. der Compiler wählt bereits die optimalen Befehle).
+ Moderne Prozessoren (ESP32 gemäß Doku eine 'post-RISC Architecture') haben sehr leistungsfähige
Befehle & vergleichsweise viele Register (hier 16 'universelle' in einem Registerfile von 64 und
@ -114,8 +123,8 @@ Da ich alle meine Projekte bis dato auf NodeMCUs (& esp-idf Framework) realisier
ein passendes Modul ('sampling') in 'C' erstellt werden, die Scriptanbindung Richtung Lua gibt es
gratis dazu (bei sachgerechter Anwendung ... ;-).
Im Ergebnis kann man mit 44.6 kHz Daten sampeln (separate FreeRTOS Task, runtergebremst damit die
CPUs nicht komplett monopolisiert werden ...). Als Blockgröße habe ich
Im Ergebnis kann man mit 44.6 kHz Daten sampeln (separate FreeRTOS Task, runtergebremst damit der
belegte Core nicht komplett monopolisiert wird ...). Als Blockgröße habe ich
2048 Meßwerte gewählt. Das Mikrofon leistet 50 Hz bis 20kHz lt. Datenblatt, d.h. ein Teil der
Frequenzen kann unten & oben verworfen werden.
@ -124,6 +133,16 @@ Datenerfassung(Blockgröße) -> FFT -> Binning(10 St.). Das Sampeln wird in Lua
(aus zwei wechselseitig genutzten Ergebnispuffern à 10 'Bins') werden per Timertask in Lua ausgelesen
und an die LED-Kette ausgegeben.
Für die Verifizierung der Funktion habe ich zunächst mit folgender Webseite Testtöne mit definierter
Frequenz erzeugt: http://onlinetonegenerator.com/432Hz.html .
Leider zeigt sich, das die generierten Töne niedriger und vor allem der hohen Frequenzen nicht 'laut'
genug sind.
Es trifft sich glücklich, das wir im Space von hacKNology einen Funktionsgenerator zur Verfügung haben.
Wenn wir den direkt auf den ADC schalten (ohne Mikro), können wir mit der Einstellung 2,2Vpp Testsignale
für den ganzen Bereich sauber generieren (überflüssig, zu sagen, das wir den Funktionsgenerator
seinerseits vorab mittels Oszi überprüft haben ... ;).
Ein paar Meßergebnisse:
Die Aufnahme der Meßwerte benötigt ca. 45ms, das Umrechnen per FFT ca. 0,8 ms!
(Umso sinnfreier die Umsetzung in ESP32-Assembler ...).

@ -0,0 +1,10 @@
---
title: Einführung in Go (Technikcamp Bodensee 2019)
author: xperimental
lecturer: xperimental
difficulty: Einfach
date: 2019-08-03
---
Hier zum Vortrag:
https://media.ccc.de/v/camp19-85-einfhrung-in-go

@ -0,0 +1,7 @@
---
title: Spontanvortrag 'Einführung in die Game-Engine Godot anhand des Hackathon-Siegers Meatball-Massacre'
author: xperimental, vespasian
lecturer: xperimental
difficulty: Mittel
date: 2019-11-25
---

@ -0,0 +1,8 @@
---
title: Einführung in KiCAD (Technikcamp Bodensee 2019)
author: nerdyscout
lecturer: nerdyscout
difficulty: Einfach
date: 2019-08-02
---

@ -0,0 +1,8 @@
---
title: LPWAN (Low Power Wide Area Network) - Ein Überblick (Technikcamp Bodensee 2019)
author: nico
lecturer: nico
difficulty: Einfach
date: 2019-08-02
---

@ -0,0 +1,9 @@
---
title: Praktische Einführung in moderne Webapps mit Vue.JS
author: vespasian
lecturer: vespasian
difficulty: Mittel
date: 2020-02-10
---
[Tutorial Sources](https://git.hacknology.de/Vespasian/vue-tutorial-hackerspace)
Loading…
Cancel
Save