Svenska ElektronikForumet

Vad var lösningen?
Vad gör "convert_filename()"?

Fungerar det? Eller fungerar det bara "bättre"?

En vild fundering...
Jobbar inte w-funktionen med 16-bitars ("wide") tecken (UTF-16) ?
Var lösningen att lägga till extra nulls på slutet?
Jag antar att eftersom w-funktionen jobbar med 16-bitars tecken,
så kommer den bara att "se" strängavsluts-nullet på varannat byte...

Kan det vara så enkelt att denna sträng-bearbetning inte lägger till EOL-märke? (alltså ett par NOLL)

Ganska vanligt fel i övrigt...

sodjan skrev:Vad var lösningen?
Vad gör "convert_filename()"?

Fungerar det? Eller fungerar det bara "bättre"?

En vild fundering...
Jobbar inte w-funktionen med 16-bitars ("wide") tecken (UTF-16) ?
Var lösningen att lägga till extra nulls på slutet?
Jag antar att eftersom w-funktionen jobbar med 16-bitars tecken,
så kommer den bara att "se" strängavsluts-nullet på varannat byte...

Kan vara så. "lösningen" just nu är att nolla bort början på strängen tills nästa körning så den inte innehåller något giltigt tecken från förra körningen. Vet inte hur det funkar om man kör längre filer. Men det känns inte rätt då det handlar om en kombo av antalet filer och filnamnen tillsammans.

Det blev skitstressigt i morse att försöka hosta igång detta innan flyget gick till Gbg. Men nu har vi lämnat in en första prototyp som klarar av minst 30-dagars loop-körande.

Vi fortsätter så klart arbetet med detta när vi kommer tillbaka. Men det känns skönt att det blev nått fungerande att visa upp idag iaf.

convert_filename();

Paddar vartannant tecken med en NULL för att wFSfopen ska få ett korrekt filnamn att arbeta med.

Kan ju iofs. vara det som strular nu när du nämnde UTF-16. Doh!

Den avslutar endast med att lägga till en extra NULL och borde så klart lägga till två.

Men samtidigt så händer detta problemet även när det är exakt antal tecken i strängen både före och efter bytet av fil.

Vid googling på wfsfopen så hittade jag :
http://svn.dr15.cnrs.fr/svn/electronici ... tem/FSIO.h

Där står bl.a :

Description:
This function opens a file with UTF16 input 'fileName' on PIC24/PIC32/dsPIC MCU's.
First, RAM in the dynamic heap or static array will be allocated to a
new FSFILE object. Then, the specified file name will be formatted to
ensure that it's in 8.3 format or LFN format.

Lite luddigt vad som avses med "...or LFN format". Varför "or" och vad är det som avgör det !?

När det gäller avslutande NULL så borde det finnas något generellt sätt som
dessa ska kodas i UTF-16, kan man tycka...

Om man kollar : http://en.wikipedia.org/wiki/Null-terminated_string så står det :

UTF-16 uses 2-byte integers and has to use arrays of such, ending with a 2-byte 0x0000 value.

Föreslår att du går tillbaka, dvs "back to the bones", dvs disablar allt du inte nödvändigt behöver, dvs LFN och UTF16, och börjar felsöka, lämpligen med en BP satt i GE-koden.
Samtidigt bör du nog skaffa dig en MIPS-assemblermanual, lämpligen från MIPS hemsida.

Ja, jag tänkte också på det, varför behöver man LFN och UTF16
i en sådan här applikation?

Nä, dålig design, vill jag påstå, behovet av LFN och UTF16 måste var oexisterande, och dessutom garanterat tillkrånglande.

Men va fan! Det var ju helvete vad ni skulle haka upp er på de långa filnamnen.

Det är exakt samma fel med eller utan långa filnamn!
Den går dessutom aldrig in i GE-interrupten när det hänger sig.

Nu får det vara så här tills nästa gång jag kommer åt utrustningen.

> Det är exakt samma fel med eller utan långa filnamn!

OK, jag kan ha missförstått något...
Jag tolkade det som att du alltid körde med *stöd för* långa filnamn.
D.v.s med "w" versionen av FSfopen !?

(Att dina filnamn inte *är* "långa" är ju mindre intressant...)