Pearl DPF "fastoff" Firmware

irimi · Mar 29th 2012

superelchi wrote:

Vorteil dieser neuer Version wäre nämlich, dass man selbst die Firmware modifizieren könnte: fastoff und eigenes Bild ließen sich sicherlich einbauen ... man muss sich "nur mal" in die Sourcen einarbeiten .

Da bin ich grad dabei.

Habe mal selber reingeschaut, eigentlich muss man kein großer C-Programmierer sein, um den BSOH zu modifizieren, bzw. sogar eine Grafik reinzupasten:
In main.c / Funktion umain() gibt es u.a. die Aufrufe:

Code

clrscreen(RGB565(0, 0, 70)); // hier kann man die Hintergrundfarbe modifizieren
print_splash(); // und diese Funktion modifieren
void print_splash(void) __banked
{
__idata char codes[3];
disp_home();
rawputc(0x11); print_padded(PAD_WIDTH "\022"); rawputc(0x05); putsc("\n|");
print_padded(PAD_WIDTH " USB display"); putsc("|\n|");
print_padded(PAD_WIDTH " version:" STRING(BUILD_ID)); putsc("|\n|");
print_padded(PAD_WIDTH " by hackfin@section5.ch"); putsc("|\n");
rawputc(0x1a); print_padded(PAD_WIDTH "\022"); rawputc(0x03); putsc("\n\n");
putsc("LCD: " STRING(_INTERNAL_TAG) " (compatible)\n");
putsc("Detecting flash...");
flash_detect(codes);
putsc("\n");
flash_print_size(codes);
putsc("\n\n\nPress MENU for config mode");
}

Display More

Wenn man eine Grafik in den BSOH reinpasten will, muss man nur schauen wie clrscreen() funktioniert:
Anstelle von einzelnen col Wertes könnte man ein array nehmen, welches die Bilddaten im RGB16/RGB565 Format enthält zB const unsigned short g_splashgfx[] = {...}

Das sollte es gewesen sein, jetzt muss man "nur noch" (haha, siehe meinen vorhergehenden Eintrag) die modifizerte FW flashen können ...

superelchi · Mar 29th 2012

irimi wrote:

Also nochmal die Frage, gibt es hier jemanden der erfolgreich mit restore.py flashen konnte ?

Ja. Ich.

irimi wrote:

Habe mal selber reingeschaut, eigentlich muss man kein großer C-Programmierer sein, um den BSOH zu modifizieren, bzw. sogar eine Grafik reinzupasten:

Na dann viel Vergnügen. Dann sind wir wieder bei den Pinguinen. Was machst du, wenn jemand gern ein anderes Bild hätte? Soll der das dann auch - ganz easy - "reinpasten"? Oder machst du einen Änderungsdienst auf?

BTW: schon mal 8051 Assembler programmiert? Schon mit den diversen 8051 Memory Models, Adressierungsarten, Bank-Switching, AX206 Speicheraufbau, SDCC Eigenheiten, etc. beschäftigt? Code, den man modifizieren will, sollte man nämlich erst mal verstehen.

Gruß
superelchi

irimi · Mar 29th 2012

superelchi wrote:

Na dann viel Vergnügen. Dann sind wir wieder bei den Pinguinen. Was machst du, wenn jemand gern ein anderes Bild hätte? Soll der das dann auch - ganz easy - "reinpasten"? Oder machst du einen Änderungsdienst auf?

Zugegeben, eine Lösung bei der ich ein default Image im USB flash drive definiere, welches ich jederzeit austauschen ist natürlich schöner, aber wie du schon schreibst ist das nicht trivial und mal eben schnell gemacht.

Aber als erste einfache Lösung, wenn jemand unbedingt sein eigenens Image haben will , muss man halt selber compilieren, selbst die FW flashen muss man eh.
Mir persönlich reicht das, die saubere Lösung ist aber klar vorzuziehen !

BTW: Ja, verdammt ist schon bald 20 Jahre her, dass ich mit dem 8051 gearbeitet habe

superelchi · Mar 29th 2012

irimi wrote:

Mir persönlich reicht das, die saubere Lösung ist aber klar vorzuziehen !

Okay, hast recht. Doch wo ist dabei der Vorteil gegenüber der vorhandenen, gepatchten Version? Ist doch eher ein Rückschritt.
Deshalb bin ich dran das etwas umfangreicher zu machen. Hab schon eine zusätzliche Schrift eingebaut (die ich ohne Lupe lesen kann) und sitze momentan an einem schöneren Menü. Dann ist der Grundstock da um so Sachen wie eigener Splash-Screen, Änderung der USB-Serial, etc. einzubauen.

irimi wrote:

BTW: Ja, verdammt ist schon bald 20 Jahre her, dass ich mit dem 8051 gearbeitet habe

Jetzt wo ich so drüber nachdenke- ist bei mir noch ein bisschen länger. Und war nur der 8048.

BTW: dein Problem mit der restore.py: ich mach das immer direkt im fw-Verzeichnis, also

Code

cd fw
sudo libhid-detach-device 1908:3318
sudo python restore.py ../src/current.bin -f

Vielleicht liegt es daran?

Gruß
superelchi

irimi · Mar 29th 2012

superelchi wrote:

Deshalb bin ich dran das etwas umfangreicher zu machen. Hab schon eine zusätzliche Schrift eingebaut (die ich ohne Lupe lesen kann) und sitze momentan an einem schöneren Menü. Dann ist der Grundstock da um so Sachen wie eigener Splash-Screen, Änderung der USB-Serial, etc. einzubauen.

BTW: dein Problem mit der restore.py: ich mach das immer direkt im fw-Verzeichnis, also

Code

cd fw

sudo libhid-detach-device 1908:3318

sudo python restore.py ../src/current.bin -f

Vielleicht liegt es daran?

Gruß
superelchi

Display More

Hallo superelchi,

das klingt ja höchst interessant mit deinen Änderungen und bin gespannt was du da noch aufbohrst. Mir fehlt leider momentan Zeit und Muße da so tief einzusteigen, bis auf meinen Quick & Dirty Vorschlag.

Vielen Dank auch für den Tipp es mal so zu versuchen, aber leider kein Unterschied und gleiche Fehlermeldung,
Habe es übrigens auf 2 verschiedenen Ubuntu Systemen versucht, unterschiedlich HW - einmal 32bit und ein 64bit System.

Könntest du eventuell einen fulldump der neuen Firmware zur Verfügung stellen ?
Diese ließe sich dann vielleicht mit ProgSPI flashen und man kann eventuell Rückschlüsse daraus ziehen, wie man gleich ein solchen bin File erzeugt, das von ProSPI akzeptiert wird !?

Nicht schön aber dann kriege ich die FW hoffentlich auf mein DPF., Könnte mir vorstellen, dass viele das Problem haben .... ?

Grüße,
irimi

superelchi · Mar 30th 2012

irimi wrote:

Vielen Dank auch für den Tipp es mal so zu versuchen, aber leider kein Unterschied und gleiche Fehlermeldung,
Habe es übrigens auf 2 verschiedenen Ubuntu Systemen versucht, unterschiedlich HW - einmal 32bit und ein 64bit System.

Beim mir läufts auf zwei Ubuntus. 1 x 10.04 (da ist sogar noch libhid in den Repos) und 1 x 11.04. Mal ganz vorsichtig gefragt: du verwendest hoffentlich nicht das Schrott USB-Kabel, das bei dem Display dabei ist?
Funktioniert libhid-detach-device auch einwandfrei?
Zieh mal das Display ab und mach ein

Code

ls /dev/hidraw*

Dann Display dran und in Bootloader-Mode versetzen. Paar Sekunden warten (der HID-Treiber braucht ein bisschen). Nochmal den Befehl von oben. Jetzt sollte da ein "hidraw" mehr sein (bei mit "/dev/hidraw5"). Jetzt

Code

sudo libhid-detach-device 1908:3318

dann sollte das neue "hidraw" wieder weg sein.

irimi wrote:

Könntest du eventuell einen fulldump der neuen Firmware zur Verfügung stellen ?
Diese ließe sich dann vielleicht mit ProgSPI flashen und man kann eventuell Rückschlüsse daraus ziehen, wie man gleich ein solchen bin File erzeugt, das von ProSPI akzeptiert wird !?

Fulldump.py bringt da leider nix. Da kommt die selbe Datei raus wie die, die du programmiert hast. Nur mit ganz vielen 0FFH auf 2 MB aufgeblasen. Ich nehme an, dass ProgSPI sich den Header anschaut und was bestimmtes erwartet. Kriegen wir schon noch raus.

Gruß
superelchi

irimi · Mar 30th 2012

superelchi wrote:

Beim mir läufts auf zwei Ubuntus. 1 x 10.04 (da ist sogar noch libhid in den Repos) und 1 x 11.04. Mal ganz vorsichtig gefragt: du verwendest hoffentlich nicht das Schrott USB-Kabel, das bei dem Display dabei ist?
Funktioniert libhid-detach-device auch einwandfrei?
Zieh mal das Display ab und mach ein

ls /dev/hidraw*

Dann Display dran und in Bootloader-Mode versetzen. Paar Sekunden warten (der HID-Treiber braucht ein bisschen). Nochmal den Befehl von oben. Jetzt sollte da ein "hidraw" mehr sein (bei mit "/dev/hidraw5"). Jetzt

sudo libhid-detach-device 1908:3318

dann sollte das neue "hidraw" wieder weg sein.

Display More

Ne,ne , Kabel, Hub usw. kommen nicht in Frage, habe es jetzt nochmal mit meinem Notebook mit USB3.0 versucht - wieder dieses "Temporary Unavailable " Problem. Schon komisch , bisher nie Probleme gehabt , auch nicht mit dem alten hackit.py.
Auch mit dem detachen wie erwartet, hidraw komt und geht wie erwartet. Allerdings: alle meine Rechner haben Ubuntu 11.10 ! Aber selbst hackfin/Strubi schreibt

Quote

For some reason, there are sometimes too many timeouts on the pearl DPFs.

Habe da noch eine Idee - ist aber etwas aufwendiger.

Das mit dem Fulldump habe ich befürchtet . Ja, dürfte sich herausfinden lassen, wie man das macht.

Ach, noch zu meiner "Quick & Dirty" Funktion: habe mal ein kleines Konverter Script geschrieben, was ein entsprechendes C-Array erzeugt.
Solch ein Array kann je nach Auflösung recht groß werden, was vielleicht mein Compilieren/Linken der FW Probleme machen könnte.

Zusätzlich kann man den DPF direkt per USB mit Bildern befüllen (alles unter Python), wenn man mal eben schnell eine Grafik auf dem DPF testen will.
Zu finden unter:
dpflib.py

superelchi · Mar 31st 2012

irimi wrote:

Zusätzlich kann man den DPF direkt per USB mit Bildern befüllen (alles unter Python), wenn man mal eben schnell eine Grafik auf dem DPF testen will.
Zu finden unter:
dpflib.py

Kannte ich noch garnicht. Cool.
Hatte schon überlegt, wie ich das Startbild am einfachsten auf das Display kriege. Ein Programm, das die libpdf.a von hackfin benutzt ist meine Meinung nach nicht so das Gelbe vom Ei für einen "normalen" Anwender. So mit Kompilieren und so...
Wenn ich das richtig verstehe, brauchts nur die dpflib.py für den Zugriff aufs Display? Wenn ich nen neuen Befehle wie "set splashimage" in die Firmware reinbaue, könnte man dann doch ein einfaches Download-Programm mit der dpflib.py basteln, oder?

irimi wrote:

Auch mit dem detachen wie erwartet, hidraw komt und geht wie erwartet. Allerdings: alle meine Rechner haben Ubuntu 11.10 ! Aber selbst hackfin/Strubi schreibt
Zitat
For some reason, there are sometimes too many timeouts on the pearl DPFs.

Nur komisch, dass es mit hackit.py, ProgSPI und wohl auch dpflib.py geht? Okay - Bootloader-Modus gibts nur in der neuen libdpf von hackfin oder ProgSPI - aber beide laden dieselbe Lib aufs Display für die Übertragung. [Am Kopf kratz].
Bin zwar momentan tief in der Menüerstellung der Firmware, aber ich glaube, das Problem mit ProgSPI ist wirklich wichtig. Mal sehn ob ich nicht erst mal versuche das zu Fixen. Hab ja von hackfin Developer-Zugriff auf das dpf-ax Projekt bekommen.Wenn ich was rausfinde, stell ichs direkt im Projekt bei sourceforge ein. Mit meinen Erweiterungen (Font/Menü/etc.) dauerts noch etwas (ja, ja, die Zeit...).

irimi wrote:

Ach, noch zu meiner "Quick & Dirty" Funktion: habe mal ein kleines Konverter Script geschrieben, was ein entsprechendes C-Array erzeugt.
Solch ein Array kann je nach Auflösung recht groß werden, was vielleicht mein Compilieren/Linken der FW Probleme machen könnte.

Das Bild würde ich als Resource in die Firmware einbinden. Schau mal in die Makefile und compile.py, wie die "font4x8.bin" eingebunden wird. Dafür bräuchte es eine Datei, die schon die richtige Orientierung/Auflösung hat und im RGB565 Format vorliegt. Also für die momentan unterstützten Displays wären das drei Dateien: 128x128 Pixel, 240x320 Pixel (Portait) und 320x240 Pixel (Landscape). Dann ne einfache Routine, die die Resource aus dem SPI-Flash ließt und direkt aufs Display haut - das wäre wirklich Quick&Dirty.

Gruß
superelchi

irimi · Mar 31st 2012

superelchi wrote:

Hatte schon überlegt, wie ich das Startbild am einfachsten auf das Display kriege. Ein Programm, das die libpdf.a von hackfin benutzt ist meine Meinung nach nicht so das Gelbe vom Ei für einen "normalen" Anwender. So mit Kompilieren und so...
Wenn ich das richtig verstehe, brauchts nur die dpflib.py für den Zugriff aufs Display? Wenn ich nen neuen Befehle wie "set splashimage" in die Firmware reinbaue, könnte man dann doch ein einfaches Download-Programm mit der dpflib.py basteln, oder?

Hat auch Nachteile: es muss noch die Python Image Library (PIL) und pyusb 0.4 nachinstalliert werden. Außerdem ist die notwendige Wandlung nach rgb565 rechenintensiv, was auf kleinen System schon im Sekundenbereich liegen kann - auf meinem Router an dem ich das Display ebenfalls verwende geht es gerade so.
Vorteil ist aber, dass man von dieser libdpf.a unabhängig ist.
Der Download mit dpflib.py geht übrigens schon zB

Code

python ./dpflib.py [Grafikdatei.png|jpg]

.

Die Grafik kann kann größer als 320x240 sein - wird dann runterskaliert (allerdings noch absolut)

Quote

Hab ja von hackfin Developer-Zugriff auf das dpf-ax Projekt bekommen

Cool - da kommen noch spannende Zeiten

Quote

Das Bild würde ich als Resource in die Firmware einbinden.

Wenn du stattdessen ein bin File erzeugen willst, die Zeile 396-414 ändern in

Code

[(r565.append((p[0] & 0xf8) |((p[1] & 0xe0) >> 5 )),r565.append(((p[1] & 0x1c) << 3)|((p[2] & 0xf8) >> 3)) ) for p in rgbdata]
import struct
f = open("./RGB565.bin", "wb")
for short in r565:
bindata = struct.pack("h",short)
f.write(bindata)
f.close()

Ergänzung: die Skalierung kann man bereits als Parameter übergeben ("dpflib.py help") zeigt wie.

superelchi · Mar 31st 2012

irimi wrote:

Hat auch Nachteile: es muss noch die Python Image Library (PIL) und pyusb 0.4 nachinstalliert werden

Rechne das mal gegen die Nachteile von dpflib.a auf.
Ist mir allemal lieber, einem Otto-Normalnutzer zuzumuten ein paar Standard-Libs nachzuinstallieren, statt ihn die dpflib.a kompilieren zu lassen.

irimi wrote:

Die Grafik kann kann größer als 320x240 sein - wird dann runterskaliert (allerdings noch absolut)

Könne man da nicht was mit ImageMagick machen?

BTW: hab schon rausgefunden warum ProgSPI die Firmware nicht mag. Das Programm ist zwar so doof, dass es eine Firmware mit falschen CRCs programmiert (die dann auf dem Display natürlich nicht läuft) aber wenn sich der Header der Jumptable nicht an der richtigen Stelle befindet weigert es sich.

Gruß
superelchi

irimi · Mar 31st 2012

superelchi wrote:

Könne man da nicht was mit ImageMagick machen?

Nicht notwenig, kann alles die PIL, läßt sich schnell ändern, wen man es relativ oder anderes haben will.
Und wie bereits oben noch ergänzt, kann man die Skalierung bereits als Parameter übergeben - einfach mal "dpflib.py help" eingeben.

superelchi · Mar 31st 2012

Alles klar.
Mit Python hab ich nur cut&paste Erfahrung.

Gruß
superelchi

superelchi · Apr 1st 2012

So, programmieren der 0.2er Version mit ProgSPI geht jetzt.
Änderungen sind in http://dpf-ax.svn.sourceforge.net/ drin.
Im Anhang fertige FW-Versionen fürs Pearl.

Gruß
superelchi

superelchi · Apr 2nd 2012

Hier noch was für die, bei denen es kein libhid gibt.

Shell-Script

#!/bin/sh
#
# hiddetach
#
# Simple HID detach code for AX206 based DPF hardware in bootloader mode
#
# 2012/04/02 superelchi
# First version
#
#
if [ `id -u` -ne 0 ]; then
echo "$0: You must be root to do this.">&2
exit 1
fi
dirlist=$(find -L /sys/bus/usb/devices -maxdepth 1 -type d)
for d in $dirlist ; do
if [ -e ${d}/product ] ; then
grep -q BL206 ${d}/product
if [ $? -eq 0 ] ; then
id=${d##*/}:1.0
if [ -e /sys/bus/usb/drivers/usbhid/${id} ] ; then
echo -n "Detaching dpf at ${id}..."
echo -n $id > /sys/bus/usb/drivers/usbhid/unbind
echo " done."
else
echo "$0: info - dpf at ${id} is already detached."
fi
exit 0
fi
fi
done
echo "$0: warning - no dpf in bootloader mode found."

Display More

Das Skript ist ein Ersatz für libhid-detach-device.
Ab dem nächsten commit auch in die Projekt-Sourcen zu finden.

Gruß
superelchi

irimi · Apr 4th 2012

superelchi wrote:

So, programmieren der 0.2er Version mit ProgSPI geht jetzt.
Änderungen sind in http://dpf-ax.svn.sourceforge.net/ drin.

Gruß
superelchi

Bin erst jetzt dazu gekommen, funktioniert super, auch der libhid Ersatz .
Habe festgestellt dass mein dpflib.py Script nicht kompatibel zur neuen Firmware ist - Ursache ist klar, muss es aber noch modifizieren.

Außerdem habe ich ein wenig was beim Flash-Problem unter Linux/Python herausgefunden:
- Problem tritt bei mir nur beim flashen per Bootloader auf
- Timeouts in der dpflib hochsetzen bringt nichts
- mit der neuen FW ist leicht zu erkennen, dass gleich nach dem ersten Befehl der Full Erase Flash Sequence "fllash_cmd(h, SPM_RES, 1, 0);" das Display offensichtlich einen Reset durchführt.

Leider kann ich es nicht genau sehen da wireshark plötzlich keine Bulk Messages mehr mittraced (ging aber schonmal) . Jedenfalls wird die FW gestartet, damit das Flash nicht gelöscht ! Wenn man das nicht mitgekommt und nochmal das Script startet, begeht die FW Selbstmord und löscht sich selbst .
Mein Verdacht: eventuell sind unterschiedliche Bootloaderversionen drauf, die ihre Eigenarten haben. Man müsste mal den Flashspeicher an der Stelle auslesen und vergleichen.

Grüße, irimi

superelchi · Apr 4th 2012

irimi wrote:

- mit der neuen FW ist leicht zu erkennen, dass gleich nach dem ersten Befehl der Full Erase Flash Sequence "fllash_cmd(h, SPM_RES, 1, 0);" das Display offensichtlich einen Reset durchführt.

Was für einen Flash-Chip hast du denn im Display? Vielleicht passen die Erase, etc. Befehle einfach nicht zu deinem Flash?

Gruß
superelchi

irimi · Apr 5th 2012

superelchi wrote:

Was für einen Flash-Chip hast du denn im Display? Vielleicht passen die Erase, etc. Befehle einfach nicht zu deinem Flash?

Hab zu hause nicht so einen kleinen Schraubendreher zur Hand, aber würde zur BL Theorie passen.

Meine letzten genannten Analysen kann man vergessen, da war irgendwie der Wurm drin, keine Ahnung warum es immer einen Reset gab.
Bin jetzt mal mit dem Debugger + Wireshark dran gegangen und es verhält sich so:

Code

flash_cmd(h, SPM_RES, 1, 0);
flash_cmd(h, SPM_WRSR, 2, 0); // clr status
flash_cmd(h, SPM_WREN, 1, 0);
flash_cmd(h, SPM_FLASH_BE, 1, 0);

werden erfolgreich ausgeführt und vom DPF immer mit OK quittiert.

Aber anschließend gibs Probleme bei Abfrage des Flashstatus - über bootloader.c / flash_status_hid() / spilib_process() wird aufgerufen:

Code

error = transmit(h, umsg);
if (umsg->u.spi.rnum > 0 && error >= 0) {
error = usb_rawread(h->dev.udev, out, 64);
}
if (error < 0) perror("Reading USB");
else error = 0;
return error;

Der Transmit ist noch erfolgreich, aber beim usb_rawread() gibt es nach 4s eine Fehlermeldung, hierzu der Trace:

Code

No. Time Source Destination Protocol Length Info
1 0.000000 host 4.1 USB 72 URB_INTERRUPT out
Frame 1: 72 bytes on wire (576 bits), 72 bytes captured (576 bits)
USB URB
URB id: 0xffff8800a6b16e40
URB type: URB_SUBMIT ('S')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x01, Direction: OUT
0... .... = Direction: OUT (0)
.000 0001 = Endpoint value: 1
Device: 4
URB bus id: 5
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1333621527
URB usec: 617005
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 8
Data length [bytes]: 8
[Response in: 2]
Leftover Capture Data: 0810bf1111010105
No. Time Source Destination Protocol Length Info
2 0.000101 4.1 host USB 64 URB_INTERRUPT out
Frame 2: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
USB URB
URB id: 0xffff8800a6b16e40
URB type: URB_COMPLETE ('C')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x01, Direction: OUT
0... .... = Direction: OUT (0)
.000 0001 = Endpoint value: 1
Device: 4
URB bus id: 5
Device setup request: not relevant ('-')
Data: not present ('>')
URB sec: 1333621527
URB usec: 617106
URB status: Success (0)
URB length [bytes]: 8
Data length [bytes]: 0
[Request in: 1]
[Time from request: 0.000101000 seconds]
No. Time Source Destination Protocol Length Info
3 16.684956 host 4.1 USB 64 URB_INTERRUPT in
Frame 3: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
USB URB
URB id: 0xffff8800cc594180
URB type: URB_SUBMIT ('S')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x81, Direction: IN
1... .... = Direction: IN (1)
.000 0001 = Endpoint value: 1
Device: 4
URB bus id: 5
Device setup request: not relevant ('-')
Data: not present ('<')
URB sec: 1333621544
URB usec: 301961
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 64
Data length [bytes]: 0
[Response in: 4]
No. Time Source Destination Protocol Length Info
4 20.686914 4.1 host USB 64 URB_INTERRUPT in
Frame 4: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
USB URB
URB id: 0xffff8800cc594180
URB type: URB_COMPLETE ('C')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x81, Direction: IN
1... .... = Direction: IN (1)
.000 0001 = Endpoint value: 1
Device: 4
URB bus id: 5
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1333621548
URB usec: 303919
URB status: No such file or directory (-ENOENT) (-2)
URB length [bytes]: 0
Data length [bytes]: 0
[Request in: 3]
[Time from request: 4.001958000 seconds]

Display More

Das interessante: diesen Vorgang kann ich beliebig oft wiederholen, ohne einen weiteren detach machen zu müssen - ABER der Flashspeicher bleibt ungerührt, nichts wird gelöscht.

Muss ich wohl doch mal den Flashbaustein anschauen - aber erst nach Ostern, fahre ein paar Tage weg.

Pearl DPF "fastoff" Firmware

Share

Tags