tasmota-webserial-esptool 6.4.0 → 6.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/workflows/build_upload.yml +8 -5
- package/.github/workflows/ci.yml +3 -3
- package/CHANGELOG_CHIP_VARIANT.md +169 -0
- package/CHIP_VARIANT_SUPPORT.md +170 -0
- package/IMPLEMENTATION_SUMMARY.md +232 -0
- package/css/style.css +1 -0
- package/dist/const.d.ts +9 -0
- package/dist/const.js +28 -9
- package/dist/esp_loader.d.ts +20 -0
- package/dist/esp_loader.js +107 -12
- package/dist/index.js +1 -0
- package/dist/stubs/esp32c5.json +4 -4
- package/dist/stubs/esp32p4r3.json +8 -0
- package/dist/stubs/index.d.ts +1 -1
- package/dist/stubs/index.js +8 -2
- package/dist/web/esp32c5-mcj52-K1.js +1 -0
- package/dist/web/esp32p4r3-Cle9QJmZ.js +1 -0
- package/dist/web/index.js +1 -1
- package/index.html +13 -0
- package/js/modules/esp32c5-mcj52-K1.js +1 -0
- package/js/modules/esp32p4r3-Cle9QJmZ.js +1 -0
- package/js/modules/esptool.js +1 -1
- package/js/script.js +23 -0
- package/package.json +1 -1
- package/src/const.ts +35 -9
- package/src/esp_loader.ts +152 -12
- package/src/index.ts +2 -0
- package/src/stubs/esp32c5.json +4 -4
- package/src/stubs/esp32p4r3.json +8 -0
- package/src/stubs/index.ts +10 -2
- package/tsconfig.json +2 -1
- package/dist/web/esp32c5-C8uE-s4t.js +0 -1
- package/js/modules/esp32c5-C8uE-s4t.js +0 -1
|
@@ -12,8 +12,11 @@ concurrency:
|
|
|
12
12
|
jobs:
|
|
13
13
|
build:
|
|
14
14
|
runs-on: ubuntu-latest
|
|
15
|
+
permissions:
|
|
16
|
+
contents: write
|
|
17
|
+
id-token: write # required to use OIDC
|
|
15
18
|
steps:
|
|
16
|
-
- uses: actions/checkout@
|
|
19
|
+
- uses: actions/checkout@v6
|
|
17
20
|
- name: Remove old files and folders
|
|
18
21
|
run: |
|
|
19
22
|
rm -rf package-lock.json
|
|
@@ -21,7 +24,7 @@ jobs:
|
|
|
21
24
|
rm -rf js/modules
|
|
22
25
|
mkdir js/modules
|
|
23
26
|
- name: install node v20
|
|
24
|
-
uses: actions/setup-node@
|
|
27
|
+
uses: actions/setup-node@v6
|
|
25
28
|
with:
|
|
26
29
|
node-version: 20
|
|
27
30
|
- name: Install Yarn with NPM
|
|
@@ -40,11 +43,11 @@ jobs:
|
|
|
40
43
|
mv js/modules/index.js js/modules/esptool.js
|
|
41
44
|
#ls js/modules/
|
|
42
45
|
- name: Commit Distribution Files
|
|
43
|
-
uses: stefanzweifel/git-auto-commit-action@
|
|
46
|
+
uses: stefanzweifel/git-auto-commit-action@v7
|
|
44
47
|
with:
|
|
45
48
|
commit_message: "Github Action: Updated dist files"
|
|
46
49
|
- name: Publish to NPM registry
|
|
47
|
-
uses: JS-DevTools/npm-publish@
|
|
50
|
+
uses: JS-DevTools/npm-publish@v4
|
|
48
51
|
with:
|
|
49
52
|
registry: https://registry.npmjs.org/
|
|
50
53
|
token: ${{ secrets.NPM_TOKEN }}
|
|
@@ -52,7 +55,7 @@ jobs:
|
|
|
52
55
|
- name: Setup Pages
|
|
53
56
|
uses: actions/configure-pages@v5
|
|
54
57
|
- name: Upload artifact
|
|
55
|
-
uses: actions/upload-pages-artifact@
|
|
58
|
+
uses: actions/upload-pages-artifact@v4
|
|
56
59
|
with:
|
|
57
60
|
path: "."
|
|
58
61
|
|
package/.github/workflows/ci.yml
CHANGED
|
@@ -12,9 +12,9 @@ jobs:
|
|
|
12
12
|
runs-on: ubuntu-latest
|
|
13
13
|
|
|
14
14
|
steps:
|
|
15
|
-
- uses: actions/checkout@
|
|
15
|
+
- uses: actions/checkout@v6
|
|
16
16
|
- name: Use Node.js
|
|
17
|
-
uses: actions/setup-node@
|
|
17
|
+
uses: actions/setup-node@v6
|
|
18
18
|
with:
|
|
19
19
|
node-version: 20
|
|
20
20
|
- name: Remove old package-lock.json
|
|
@@ -25,6 +25,6 @@ jobs:
|
|
|
25
25
|
- run: script/build
|
|
26
26
|
- run: npm exec -- prettier --check src
|
|
27
27
|
- name: Commit changed files
|
|
28
|
-
uses: stefanzweifel/git-auto-commit-action@
|
|
28
|
+
uses: stefanzweifel/git-auto-commit-action@v7
|
|
29
29
|
with:
|
|
30
30
|
commit_message: "Github Action: Updated files"
|
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
# Changelog: Chip Variant Support
|
|
2
|
+
|
|
3
|
+
## Änderungen in WebSerial_ESPTool
|
|
4
|
+
|
|
5
|
+
### Neue Features
|
|
6
|
+
|
|
7
|
+
#### 1. `chipVariant` Feld in ESPLoader
|
|
8
|
+
- Neues öffentliches Feld: `chipVariant: string | null`
|
|
9
|
+
- Wird automatisch bei der Chip-Erkennung gesetzt
|
|
10
|
+
- Für ESP32-P4: `"rev0"` (Revision < 300) oder `"rev300"` (Revision >= 300)
|
|
11
|
+
- Für alle anderen Chips: `null`
|
|
12
|
+
|
|
13
|
+
#### 2. Erweiterte ESP32-P4 Erkennung
|
|
14
|
+
- Revision wird aus eFuses gelesen (EFUSE_BLOCK1)
|
|
15
|
+
- Funktioniert sowohl bei IMAGE_CHIP_ID als auch Magic Value Erkennung
|
|
16
|
+
- Logging der erkannten Variante im Debug-Modus
|
|
17
|
+
|
|
18
|
+
### Geänderte Dateien
|
|
19
|
+
|
|
20
|
+
- `src/esp_loader.ts`:
|
|
21
|
+
- Hinzugefügt: `chipVariant: string | null` Feld
|
|
22
|
+
- Erweitert: `detectChip()` Methode setzt chipVariant für ESP32-P4
|
|
23
|
+
- Erweitert: Logging für bessere Nachvollziehbarkeit
|
|
24
|
+
|
|
25
|
+
### API-Änderungen
|
|
26
|
+
|
|
27
|
+
```typescript
|
|
28
|
+
// Vorher
|
|
29
|
+
const esploader = new ESPLoader(port, logger);
|
|
30
|
+
await esploader.initialize();
|
|
31
|
+
console.log(esploader.chipName); // "ESP32-P4"
|
|
32
|
+
console.log(esploader.chipRevision); // 300
|
|
33
|
+
|
|
34
|
+
// Nachher (zusätzlich)
|
|
35
|
+
console.log(esploader.chipVariant); // "rev300"
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
### Abwärtskompatibilität
|
|
39
|
+
|
|
40
|
+
✅ Vollständig abwärtskompatibel
|
|
41
|
+
- Bestehendes Code funktioniert unverändert
|
|
42
|
+
- Neues Feld ist optional und kann ignoriert werden
|
|
43
|
+
- Keine Breaking Changes
|
|
44
|
+
|
|
45
|
+
## Änderungen in esp-web-tools
|
|
46
|
+
|
|
47
|
+
### Neue Features
|
|
48
|
+
|
|
49
|
+
#### 1. `chipVariant` Support in Manifesten
|
|
50
|
+
- Neues optionales Feld in `Build` Interface: `chipVariant?: string`
|
|
51
|
+
- Ermöglicht spezifische Firmware-Builds für verschiedene Chip-Varianten
|
|
52
|
+
- Intelligente Matching-Logik mit Fallback-Unterstützung
|
|
53
|
+
|
|
54
|
+
#### 2. Erweiterte Build-Auswahl
|
|
55
|
+
- Priorisiert Builds mit passendem `chipVariant`
|
|
56
|
+
- Fallback auf Builds ohne `chipVariant` Angabe
|
|
57
|
+
- Bessere Fehlermeldungen mit Varianten-Information
|
|
58
|
+
|
|
59
|
+
### Geänderte Dateien
|
|
60
|
+
|
|
61
|
+
- `src/const.ts`:
|
|
62
|
+
- Erweitert: `Build` Interface mit `chipVariant?: string`
|
|
63
|
+
- Erweitert: `BaseFlashState` Interface mit `chipVariant?: string | null`
|
|
64
|
+
|
|
65
|
+
- `src/flash.ts`:
|
|
66
|
+
- Erweitert: Build-Matching-Logik berücksichtigt chipVariant
|
|
67
|
+
- Erweitert: Fehlermeldungen zeigen chipVariant an
|
|
68
|
+
- Erweitert: Initialisierungsmeldung zeigt chipVariant an
|
|
69
|
+
|
|
70
|
+
- `README.md`:
|
|
71
|
+
- Hinzugefügt: Dokumentation für Chip Variant Support
|
|
72
|
+
- Hinzugefügt: Beispiel für P4-Varianten
|
|
73
|
+
|
|
74
|
+
### Manifest-Beispiel
|
|
75
|
+
|
|
76
|
+
```json
|
|
77
|
+
{
|
|
78
|
+
"name": "My Firmware",
|
|
79
|
+
"version": "1.0.0",
|
|
80
|
+
"builds": [
|
|
81
|
+
{
|
|
82
|
+
"chipFamily": "ESP32-P4",
|
|
83
|
+
"chipVariant": "rev0",
|
|
84
|
+
"parts": [...]
|
|
85
|
+
},
|
|
86
|
+
{
|
|
87
|
+
"chipFamily": "ESP32-P4",
|
|
88
|
+
"chipVariant": "rev300",
|
|
89
|
+
"parts": [...]
|
|
90
|
+
}
|
|
91
|
+
]
|
|
92
|
+
}
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
### Abwärtskompatibilität
|
|
96
|
+
|
|
97
|
+
✅ Vollständig abwärtskompatibel
|
|
98
|
+
- Bestehende Manifeste ohne `chipVariant` funktionieren weiterhin
|
|
99
|
+
- `chipVariant` ist optional
|
|
100
|
+
- Keine Breaking Changes
|
|
101
|
+
|
|
102
|
+
## Testing
|
|
103
|
+
|
|
104
|
+
### Build-Tests
|
|
105
|
+
- ✅ WebSerial_ESPTool kompiliert erfolgreich
|
|
106
|
+
- ✅ esp-web-tools kompiliert erfolgreich
|
|
107
|
+
- ✅ Keine TypeScript-Fehler
|
|
108
|
+
- ✅ Keine Linting-Fehler
|
|
109
|
+
|
|
110
|
+
### Funktionale Tests (empfohlen)
|
|
111
|
+
- [ ] Test mit ESP32-P4 Rev. 0 Hardware
|
|
112
|
+
- [ ] Test mit ESP32-P4 Rev. 300 Hardware
|
|
113
|
+
- [ ] Test mit Manifest mit chipVariant
|
|
114
|
+
- [ ] Test mit Manifest ohne chipVariant (Fallback)
|
|
115
|
+
- [ ] Test mit anderen ESP32-Chips (sollte chipVariant = null sein)
|
|
116
|
+
|
|
117
|
+
## Deployment
|
|
118
|
+
|
|
119
|
+
### WebSerial_ESPTool
|
|
120
|
+
1. Version in `package.json` erhöhen
|
|
121
|
+
2. `npm run prepublishOnly` ausführen
|
|
122
|
+
3. `npm publish` ausführen
|
|
123
|
+
|
|
124
|
+
### esp-web-tools
|
|
125
|
+
1. Warten bis neue WebSerial_ESPTool Version verfügbar ist
|
|
126
|
+
2. `package.json` aktualisieren: `"tasmota-webserial-esptool": "^6.5.0"` (oder höher)
|
|
127
|
+
3. Version in `package.json` erhöhen
|
|
128
|
+
4. `npm install`
|
|
129
|
+
5. `npm run prepublishOnly` ausführen
|
|
130
|
+
6. `npm publish` ausführen
|
|
131
|
+
|
|
132
|
+
## Dokumentation
|
|
133
|
+
|
|
134
|
+
- ✅ `CHIP_VARIANT_SUPPORT.md` - Vollständige technische Dokumentation
|
|
135
|
+
- ✅ `manifest-example-p4-variants.json` - Beispiel-Manifest
|
|
136
|
+
- ✅ `README.md` (esp-web-tools) - Kurze Anleitung
|
|
137
|
+
- ✅ `CHANGELOG_CHIP_VARIANT.md` - Diese Datei
|
|
138
|
+
|
|
139
|
+
## Verwendungsbeispiele
|
|
140
|
+
|
|
141
|
+
### Szenario 1: Separate Builds für jede Variante
|
|
142
|
+
```json
|
|
143
|
+
{
|
|
144
|
+
"builds": [
|
|
145
|
+
{ "chipFamily": "ESP32-P4", "chipVariant": "rev0", "parts": [...] },
|
|
146
|
+
{ "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] }
|
|
147
|
+
]
|
|
148
|
+
}
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
### Szenario 2: Ein Build für alle Varianten
|
|
152
|
+
```json
|
|
153
|
+
{
|
|
154
|
+
"builds": [
|
|
155
|
+
{ "chipFamily": "ESP32-P4", "parts": [...] }
|
|
156
|
+
]
|
|
157
|
+
}
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
### Szenario 3: Spezifischer Build + Fallback
|
|
161
|
+
```json
|
|
162
|
+
{
|
|
163
|
+
"builds": [
|
|
164
|
+
{ "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] },
|
|
165
|
+
{ "chipFamily": "ESP32-P4", "parts": [...] }
|
|
166
|
+
]
|
|
167
|
+
}
|
|
168
|
+
```
|
|
169
|
+
Rev300 verwendet ersten Build, Rev0 verwendet zweiten Build (Fallback).
|
|
@@ -0,0 +1,170 @@
|
|
|
1
|
+
# ESP32-P4 Chip Variant Support
|
|
2
|
+
|
|
3
|
+
## Übersicht
|
|
4
|
+
|
|
5
|
+
Die beiden Projekte unterstützen jetzt die Unterscheidung zwischen verschiedenen ESP32-P4 Varianten über das neue `chipVariant` Feld.
|
|
6
|
+
|
|
7
|
+
## WebSerial_ESPTool
|
|
8
|
+
|
|
9
|
+
### Änderungen
|
|
10
|
+
|
|
11
|
+
Das `ESPLoader` Objekt hat jetzt ein neues Feld:
|
|
12
|
+
- `chipVariant: string | null` - Identifiziert die Chip-Variante
|
|
13
|
+
|
|
14
|
+
### ESP32-P4 Varianten
|
|
15
|
+
|
|
16
|
+
Für ESP32-P4 Chips werden folgende Varianten erkannt:
|
|
17
|
+
- `"rev0"` - ESP32-P4 Revision < 300 (ältere Versionen)
|
|
18
|
+
- `"rev300"` - ESP32-P4 Revision >= 300 (neuere Versionen)
|
|
19
|
+
|
|
20
|
+
Die Erkennung erfolgt automatisch basierend auf der Chip-Revision, die aus den eFuses gelesen wird.
|
|
21
|
+
|
|
22
|
+
### Beispiel
|
|
23
|
+
|
|
24
|
+
```typescript
|
|
25
|
+
const esploader = new ESPLoader(port, logger);
|
|
26
|
+
await esploader.initialize();
|
|
27
|
+
|
|
28
|
+
console.log(esploader.chipName); // "ESP32-P4"
|
|
29
|
+
console.log(esploader.chipFamily); // CHIP_FAMILY_ESP32P4
|
|
30
|
+
console.log(esploader.chipRevision); // z.B. 0 oder 300
|
|
31
|
+
console.log(esploader.chipVariant); // "rev0" oder "rev300"
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## esp-web-tools
|
|
35
|
+
|
|
36
|
+
### Änderungen
|
|
37
|
+
|
|
38
|
+
#### Manifest Format
|
|
39
|
+
|
|
40
|
+
Das `Build` Interface unterstützt jetzt ein optionales `chipVariant` Feld:
|
|
41
|
+
|
|
42
|
+
```typescript
|
|
43
|
+
interface Build {
|
|
44
|
+
chipFamily: "ESP32-P4" | ...;
|
|
45
|
+
chipVariant?: string; // NEU
|
|
46
|
+
parts: { path: string; offset: number; }[];
|
|
47
|
+
}
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
#### Flash State
|
|
51
|
+
|
|
52
|
+
Der `FlashState` enthält jetzt auch die `chipVariant` Information:
|
|
53
|
+
|
|
54
|
+
```typescript
|
|
55
|
+
interface BaseFlashState {
|
|
56
|
+
chipFamily?: "ESP32-P4" | ...;
|
|
57
|
+
chipVariant?: string | null; // NEU
|
|
58
|
+
// ...
|
|
59
|
+
}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### Manifest Beispiel
|
|
63
|
+
|
|
64
|
+
Hier ist ein Beispiel-Manifest, das verschiedene Firmware-Builds für die zwei P4-Varianten bereitstellt:
|
|
65
|
+
|
|
66
|
+
```json
|
|
67
|
+
{
|
|
68
|
+
"name": "My ESP32-P4 Firmware",
|
|
69
|
+
"version": "1.0.0",
|
|
70
|
+
"builds": [
|
|
71
|
+
{
|
|
72
|
+
"chipFamily": "ESP32-P4",
|
|
73
|
+
"chipVariant": "rev0",
|
|
74
|
+
"parts": [
|
|
75
|
+
{ "path": "bootloader_rev0.bin", "offset": 0 },
|
|
76
|
+
{ "path": "partition-table.bin", "offset": 32768 },
|
|
77
|
+
{ "path": "firmware_rev0.bin", "offset": 65536 }
|
|
78
|
+
]
|
|
79
|
+
},
|
|
80
|
+
{
|
|
81
|
+
"chipFamily": "ESP32-P4",
|
|
82
|
+
"chipVariant": "rev300",
|
|
83
|
+
"parts": [
|
|
84
|
+
{ "path": "bootloader_rev300.bin", "offset": 0 },
|
|
85
|
+
{ "path": "partition-table.bin", "offset": 32768 },
|
|
86
|
+
{ "path": "firmware_rev300.bin", "offset": 65536 }
|
|
87
|
+
]
|
|
88
|
+
},
|
|
89
|
+
{
|
|
90
|
+
"chipFamily": "ESP32-S3",
|
|
91
|
+
"parts": [
|
|
92
|
+
{ "path": "bootloader_s3.bin", "offset": 0 },
|
|
93
|
+
{ "path": "partition-table.bin", "offset": 32768 },
|
|
94
|
+
{ "path": "firmware_s3.bin", "offset": 65536 }
|
|
95
|
+
]
|
|
96
|
+
}
|
|
97
|
+
]
|
|
98
|
+
}
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
### Matching-Logik
|
|
102
|
+
|
|
103
|
+
Die Firmware-Auswahl funktioniert wie folgt:
|
|
104
|
+
|
|
105
|
+
1. **Wenn `chipVariant` im Build angegeben ist**: Der Build wird nur verwendet, wenn sowohl `chipFamily` als auch `chipVariant` übereinstimmen.
|
|
106
|
+
|
|
107
|
+
2. **Wenn `chipVariant` im Build NICHT angegeben ist**: Der Build wird für alle Varianten dieser `chipFamily` verwendet (Fallback).
|
|
108
|
+
|
|
109
|
+
#### Beispiele
|
|
110
|
+
|
|
111
|
+
**Szenario 1: Spezifische Builds für jede Variante**
|
|
112
|
+
```json
|
|
113
|
+
{
|
|
114
|
+
"builds": [
|
|
115
|
+
{ "chipFamily": "ESP32-P4", "chipVariant": "rev0", "parts": [...] },
|
|
116
|
+
{ "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] }
|
|
117
|
+
]
|
|
118
|
+
}
|
|
119
|
+
```
|
|
120
|
+
- ESP32-P4 rev0 → verwendet ersten Build
|
|
121
|
+
- ESP32-P4 rev300 → verwendet zweiten Build
|
|
122
|
+
|
|
123
|
+
**Szenario 2: Ein Build für alle Varianten**
|
|
124
|
+
```json
|
|
125
|
+
{
|
|
126
|
+
"builds": [
|
|
127
|
+
{ "chipFamily": "ESP32-P4", "parts": [...] }
|
|
128
|
+
]
|
|
129
|
+
}
|
|
130
|
+
```
|
|
131
|
+
- ESP32-P4 rev0 → verwendet den Build
|
|
132
|
+
- ESP32-P4 rev300 → verwendet den Build
|
|
133
|
+
|
|
134
|
+
**Szenario 3: Spezifischer Build + Fallback**
|
|
135
|
+
```json
|
|
136
|
+
{
|
|
137
|
+
"builds": [
|
|
138
|
+
{ "chipFamily": "ESP32-P4", "chipVariant": "rev300", "parts": [...] },
|
|
139
|
+
{ "chipFamily": "ESP32-P4", "parts": [...] }
|
|
140
|
+
]
|
|
141
|
+
}
|
|
142
|
+
```
|
|
143
|
+
- ESP32-P4 rev0 → verwendet zweiten Build (Fallback)
|
|
144
|
+
- ESP32-P4 rev300 → verwendet ersten Build (spezifisch)
|
|
145
|
+
|
|
146
|
+
## Abwärtskompatibilität
|
|
147
|
+
|
|
148
|
+
Alle Änderungen sind vollständig abwärtskompatibel:
|
|
149
|
+
|
|
150
|
+
- Bestehende Manifeste ohne `chipVariant` funktionieren weiterhin
|
|
151
|
+
- Das `chipVariant` Feld ist optional
|
|
152
|
+
- Für alle Chips außer ESP32-P4 ist `chipVariant` `null`
|
|
153
|
+
|
|
154
|
+
## Technische Details
|
|
155
|
+
|
|
156
|
+
### Chip-Erkennung
|
|
157
|
+
|
|
158
|
+
Die ESP32-P4 Revision wird aus den eFuses gelesen (EFUSE_BLOCK1):
|
|
159
|
+
- Minor Revision: Bits [3:0]
|
|
160
|
+
- Major Revision: Bit [23] << 2 | Bits [5:4]
|
|
161
|
+
- Revision = Major * 100 + Minor
|
|
162
|
+
|
|
163
|
+
### Erkennungsmethoden
|
|
164
|
+
|
|
165
|
+
ESP32-P4 kann auf zwei Arten erkannt werden:
|
|
166
|
+
|
|
167
|
+
1. **IMAGE_CHIP_ID** (Rev. 300+): Verwendet `GET_SECURITY_INFO` Kommando
|
|
168
|
+
2. **Magic Value** (Rev. < 300): Liest Magic-Wert aus Register
|
|
169
|
+
|
|
170
|
+
In beiden Fällen wird die Revision gelesen und die entsprechende Variante gesetzt.
|
|
@@ -0,0 +1,232 @@
|
|
|
1
|
+
# Implementation Summary: ESP32-P4 Chip Variant Support
|
|
2
|
+
|
|
3
|
+
## ✅ Erfolgreich implementiert
|
|
4
|
+
|
|
5
|
+
### Ziel
|
|
6
|
+
Unterscheidung zwischen ESP32-P4 Revision 0 und Revision 300, damit esp-web-tools separate Manifeste für beide Varianten bereitstellen kann.
|
|
7
|
+
|
|
8
|
+
## Implementierte Änderungen
|
|
9
|
+
|
|
10
|
+
### 1. WebSerial_ESPTool
|
|
11
|
+
|
|
12
|
+
**Datei: `src/esp_loader.ts`**
|
|
13
|
+
|
|
14
|
+
#### Neues Feld:
|
|
15
|
+
```typescript
|
|
16
|
+
chipVariant: string | null = null;
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
#### Erweiterte Chip-Erkennung:
|
|
20
|
+
- Bei IMAGE_CHIP_ID Erkennung (Rev. 300+):
|
|
21
|
+
- Revision wird aus eFuses gelesen
|
|
22
|
+
- `chipVariant` wird auf `"rev300"` oder `"rev0"` gesetzt
|
|
23
|
+
|
|
24
|
+
- Bei Magic Value Erkennung (Rev. < 300):
|
|
25
|
+
- Revision wird aus eFuses gelesen
|
|
26
|
+
- `chipVariant` wird auf `"rev300"` oder `"rev0"` gesetzt
|
|
27
|
+
|
|
28
|
+
#### Revision-Berechnung:
|
|
29
|
+
```typescript
|
|
30
|
+
// Aus EFUSE_BLOCK1 (Word 2):
|
|
31
|
+
const minorRev = word2 & 0x0f;
|
|
32
|
+
const majorRev = (((word2 >> 23) & 1) << 2) | ((word2 >> 4) & 0x03);
|
|
33
|
+
const revision = majorRev * 100 + minorRev;
|
|
34
|
+
|
|
35
|
+
// Variante setzen:
|
|
36
|
+
if (revision >= 300) {
|
|
37
|
+
chipVariant = "rev300";
|
|
38
|
+
} else {
|
|
39
|
+
chipVariant = "rev0";
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### 2. esp-web-tools
|
|
44
|
+
|
|
45
|
+
**Datei: `src/const.ts`**
|
|
46
|
+
|
|
47
|
+
#### Erweitertes Build Interface:
|
|
48
|
+
```typescript
|
|
49
|
+
export interface Build {
|
|
50
|
+
chipFamily: "ESP32-P4" | ...;
|
|
51
|
+
chipVariant?: string; // NEU - optional
|
|
52
|
+
parts: { path: string; offset: number; }[];
|
|
53
|
+
}
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
#### Erweitertes FlashState Interface:
|
|
57
|
+
```typescript
|
|
58
|
+
export interface BaseFlashState {
|
|
59
|
+
chipFamily?: Build["chipFamily"] | "Unknown Chip";
|
|
60
|
+
chipVariant?: string | null; // NEU
|
|
61
|
+
// ...
|
|
62
|
+
}
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
**Datei: `src/flash.ts`**
|
|
66
|
+
|
|
67
|
+
#### Erweiterte Build-Auswahl:
|
|
68
|
+
```typescript
|
|
69
|
+
build = manifest.builds.find((b) => {
|
|
70
|
+
// Match chipFamily
|
|
71
|
+
if (b.chipFamily !== chipFamily) {
|
|
72
|
+
return false;
|
|
73
|
+
}
|
|
74
|
+
// Wenn Build chipVariant spezifiziert, muss es matchen
|
|
75
|
+
if (b.chipVariant !== undefined) {
|
|
76
|
+
return b.chipVariant === chipVariant;
|
|
77
|
+
}
|
|
78
|
+
// Ohne chipVariant: Match für alle Varianten
|
|
79
|
+
return true;
|
|
80
|
+
});
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
#### Verbesserte Meldungen:
|
|
84
|
+
- Initialisierung zeigt chipVariant an
|
|
85
|
+
- Fehlermeldungen enthalten chipVariant-Info
|
|
86
|
+
|
|
87
|
+
**Datei: `README.md`**
|
|
88
|
+
- Dokumentation für Chip Variant Support hinzugefügt
|
|
89
|
+
- Beispiel für P4-Varianten
|
|
90
|
+
|
|
91
|
+
## Verwendung
|
|
92
|
+
|
|
93
|
+
### Manifest mit spezifischen Builds:
|
|
94
|
+
```json
|
|
95
|
+
{
|
|
96
|
+
"name": "My Firmware",
|
|
97
|
+
"version": "1.0.0",
|
|
98
|
+
"builds": [
|
|
99
|
+
{
|
|
100
|
+
"chipFamily": "ESP32-P4",
|
|
101
|
+
"chipVariant": "rev0",
|
|
102
|
+
"parts": [
|
|
103
|
+
{ "path": "firmware_p4_old.bin", "offset": 0 }
|
|
104
|
+
]
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"chipFamily": "ESP32-P4",
|
|
108
|
+
"chipVariant": "rev300",
|
|
109
|
+
"parts": [
|
|
110
|
+
{ "path": "firmware_p4_new.bin", "offset": 0 }
|
|
111
|
+
]
|
|
112
|
+
}
|
|
113
|
+
]
|
|
114
|
+
}
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
### Manifest mit Fallback:
|
|
118
|
+
```json
|
|
119
|
+
{
|
|
120
|
+
"builds": [
|
|
121
|
+
{
|
|
122
|
+
"chipFamily": "ESP32-P4",
|
|
123
|
+
"chipVariant": "rev300",
|
|
124
|
+
"parts": [...]
|
|
125
|
+
},
|
|
126
|
+
{
|
|
127
|
+
"chipFamily": "ESP32-P4",
|
|
128
|
+
"parts": [...] // Fallback für rev0
|
|
129
|
+
}
|
|
130
|
+
]
|
|
131
|
+
}
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
## Build-Status
|
|
135
|
+
|
|
136
|
+
✅ **WebSerial_ESPTool**: Kompiliert erfolgreich
|
|
137
|
+
✅ **esp-web-tools**: Kompiliert erfolgreich
|
|
138
|
+
✅ **TypeScript**: Keine Fehler
|
|
139
|
+
✅ **Abwärtskompatibilität**: Vollständig gewährleistet
|
|
140
|
+
|
|
141
|
+
## Nächste Schritte
|
|
142
|
+
|
|
143
|
+
### Für Deployment:
|
|
144
|
+
|
|
145
|
+
1. **WebSerial_ESPTool**:
|
|
146
|
+
```bash
|
|
147
|
+
cd WebSerial_ESPTool
|
|
148
|
+
# Version in package.json erhöhen (z.B. 6.5.0)
|
|
149
|
+
npm run prepublishOnly
|
|
150
|
+
npm publish
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
2. **esp-web-tools**:
|
|
154
|
+
```bash
|
|
155
|
+
cd esp-web-tools
|
|
156
|
+
# package.json aktualisieren: "tasmota-webserial-esptool": "^6.5.0"
|
|
157
|
+
npm install
|
|
158
|
+
# Version in package.json erhöhen (z.B. 8.2.0)
|
|
159
|
+
npm run prepublishOnly
|
|
160
|
+
npm publish
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
### Für Testing:
|
|
164
|
+
|
|
165
|
+
1. **Hardware-Tests**:
|
|
166
|
+
- Test mit ESP32-P4 Rev. 0 Hardware
|
|
167
|
+
- Test mit ESP32-P4 Rev. 300 Hardware
|
|
168
|
+
- Verifizierung der korrekten Varianten-Erkennung
|
|
169
|
+
|
|
170
|
+
2. **Manifest-Tests**:
|
|
171
|
+
- Test mit chipVariant-spezifischen Builds
|
|
172
|
+
- Test mit Fallback-Builds
|
|
173
|
+
- Test mit gemischten Manifesten
|
|
174
|
+
|
|
175
|
+
## Dokumentation
|
|
176
|
+
|
|
177
|
+
Erstellt:
|
|
178
|
+
- ✅ `CHIP_VARIANT_SUPPORT.md` - Vollständige technische Dokumentation
|
|
179
|
+
- ✅ `CHANGELOG_CHIP_VARIANT.md` - Detaillierte Änderungsliste
|
|
180
|
+
- ✅ `IMPLEMENTATION_SUMMARY.md` - Diese Datei
|
|
181
|
+
- ✅ `manifest-example-p4-variants.json` - Beispiel-Manifest
|
|
182
|
+
- ✅ README.md Update in esp-web-tools
|
|
183
|
+
|
|
184
|
+
## Technische Details
|
|
185
|
+
|
|
186
|
+
### Chip-Erkennung Flow:
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
1. ESPLoader.initialize()
|
|
190
|
+
↓
|
|
191
|
+
2. detectChip()
|
|
192
|
+
↓
|
|
193
|
+
3a. Versuche GET_SECURITY_INFO (IMAGE_CHIP_ID)
|
|
194
|
+
→ Erfolg: chipId = 18 (ESP32-P4)
|
|
195
|
+
→ getChipRevision() → chipVariant setzen
|
|
196
|
+
|
|
197
|
+
3b. Fallback: Magic Value Detection
|
|
198
|
+
→ chipMagicValue = 0x0, 0x7039ad9, oder 0x0addbad0
|
|
199
|
+
→ getChipRevision() → chipVariant setzen
|
|
200
|
+
|
|
201
|
+
4. chipVariant ist nun "rev0" oder "rev300"
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
### Manifest Matching Flow:
|
|
205
|
+
|
|
206
|
+
```
|
|
207
|
+
1. Chip erkannt: chipFamily = "ESP32-P4", chipVariant = "rev300"
|
|
208
|
+
↓
|
|
209
|
+
2. Durchsuche manifest.builds[]
|
|
210
|
+
↓
|
|
211
|
+
3. Für jeden Build:
|
|
212
|
+
- chipFamily muss matchen
|
|
213
|
+
- Wenn Build.chipVariant definiert: muss exakt matchen
|
|
214
|
+
- Wenn Build.chipVariant undefined: immer Match
|
|
215
|
+
↓
|
|
216
|
+
4. Ersten passenden Build verwenden
|
|
217
|
+
```
|
|
218
|
+
|
|
219
|
+
## Vorteile
|
|
220
|
+
|
|
221
|
+
1. **Flexibilität**: Manifeste können spezifische oder generische Builds anbieten
|
|
222
|
+
2. **Abwärtskompatibilität**: Bestehende Manifeste funktionieren unverändert
|
|
223
|
+
3. **Zukunftssicher**: Erweiterbar für weitere Chip-Varianten
|
|
224
|
+
4. **Transparent**: Variante wird dem Benutzer angezeigt
|
|
225
|
+
5. **Robust**: Fallback-Mechanismus verhindert Fehler
|
|
226
|
+
|
|
227
|
+
## Getestet
|
|
228
|
+
|
|
229
|
+
- ✅ TypeScript Kompilierung
|
|
230
|
+
- ✅ Build-Prozess
|
|
231
|
+
- ✅ Keine Diagnostics-Fehler
|
|
232
|
+
- ⏳ Hardware-Tests (ausstehend)
|
package/css/style.css
CHANGED
package/dist/const.d.ts
CHANGED
|
@@ -146,6 +146,7 @@ export declare const ESP32H2_UART_DATE_REG_ADDR = 1610612860;
|
|
|
146
146
|
export declare const ESP32H2_BOOTLOADER_FLASH_OFFSET = 0;
|
|
147
147
|
export declare const ESP32P4_SPI_REG_BASE = 1342754816;
|
|
148
148
|
export declare const ESP32P4_BASEFUSEADDR = 1343410176;
|
|
149
|
+
export declare const ESP32P4_EFUSE_BLOCK1_ADDR: number;
|
|
149
150
|
export declare const ESP32P4_MACFUSEADDR: number;
|
|
150
151
|
export declare const ESP32P4_SPI_USR_OFFS = 24;
|
|
151
152
|
export declare const ESP32P4_SPI_USR1_OFFS = 28;
|
|
@@ -182,6 +183,13 @@ export declare const CHIP_FAMILY_ESP32C61 = 207969;
|
|
|
182
183
|
export declare const CHIP_FAMILY_ESP32H2 = 12914;
|
|
183
184
|
export declare const CHIP_FAMILY_ESP32P4 = 12928;
|
|
184
185
|
export type ChipFamily = typeof CHIP_FAMILY_ESP8266 | typeof CHIP_FAMILY_ESP32 | typeof CHIP_FAMILY_ESP32S2 | typeof CHIP_FAMILY_ESP32S3 | typeof CHIP_FAMILY_ESP32C2 | typeof CHIP_FAMILY_ESP32C3 | typeof CHIP_FAMILY_ESP32C5 | typeof CHIP_FAMILY_ESP32C6 | typeof CHIP_FAMILY_ESP32C61 | typeof CHIP_FAMILY_ESP32H2 | typeof CHIP_FAMILY_ESP32P4;
|
|
186
|
+
interface ChipIdInfo {
|
|
187
|
+
name: string;
|
|
188
|
+
family: ChipFamily;
|
|
189
|
+
}
|
|
190
|
+
export declare const CHIP_ID_TO_INFO: {
|
|
191
|
+
[chipId: number]: ChipIdInfo;
|
|
192
|
+
};
|
|
185
193
|
interface ChipInfo {
|
|
186
194
|
[magicValue: number]: {
|
|
187
195
|
name: string;
|
|
@@ -204,6 +212,7 @@ export declare const ESP_SPI_SET_PARAMS = 11;
|
|
|
204
212
|
export declare const ESP_SPI_ATTACH = 13;
|
|
205
213
|
export declare const ESP_CHANGE_BAUDRATE = 15;
|
|
206
214
|
export declare const ESP_SPI_FLASH_MD5 = 19;
|
|
215
|
+
export declare const ESP_GET_SECURITY_INFO = 20;
|
|
207
216
|
export declare const ESP_CHECKSUM_MAGIC = 239;
|
|
208
217
|
export declare const ESP_FLASH_DEFL_BEGIN = 16;
|
|
209
218
|
export declare const ESP_FLASH_DEFL_DATA = 17;
|