Svenska ElektronikForumet

Håller på med Microchips filsystems rutiner med FAT32 på ett SDHC-kort.

Detta är inget allvarligt problem men har ställt till det med några timmars desperat felsökning.

Detta är upplägget:
Data loggas på en Pic32 och detta sparas i sin tur i en fil. Varje fil innehåller 24timmar data. Efter 24 timmars loggande så skall filen stängas för redigering och sedan skapas en ny fil för nästkommande dag. ex:
dag1.txt, dag2.txt, dag3.txt osv...

Även en informationsfil finns där jag lagrar information om hur många samplingar som gjorts med mera. Som uppdateras varje gång en ny fil skall skapas. Denna filen har givits namnet "File information.txt", alltså ett ganska långt filnamn.

Problemet är att jag inte kan göra filnamn som innehåller siffror som är av en viss längd.

t.ex. så funkar namnen:
D1 till D30 utan problem. Men INTE Day_1.txt till Day_2.txt eller inte ens D1.txt till D30.txt.

Alltså om filnamnen bli för långa och innehåller siffror så funkar det inte.

Det som händer när det "inte funkar" är att systemet helt enkelt slutar göra timer-interrupts och lämnar således filen öppen.
Detta sker på helt olika filnamn ibland funkar det mellan D1.txt fram till D6.txt och ibland från D1.txt till D14.txt. Men ju längre filnamn jag väljer desto tidigare hänger den sig. Har jag filnamnet "Loop_day_1.txt" så hänger den sig direkt då den försöker skapa filen.

Detta är koden som skapar filnamnet och sedan försöker öppna denne:¨

Hur är loop_filename_string definierad?

Oj, oj, oj! Det lär ju räcka till. Men har du verkligen råd med 512 byte till ett filnamn?
Du kanske får slut på stackutrymme eller så om du har fler så generöst tilltagna variabler? Det ger i all fall väldigt skumma fel.

Varje filnamn kan ju vara 256 tecken långt. Och om dessa ska paddas med 0x00 på varannat tecken så blir det ju i värsta fall närmare 512 totalt.

Det finns massor med minne kvar.

Även om detta är en lång sträng så funkar det mer än bra för andra filnamn som inte innehåller siffror, som jag sa "File information.txt" funkar utan några som helst problem.

Säker på att det inte är underscore som ställer till det?

Löser väl inte ditt problem, men...

> Varje filnamn kan ju vara 256 tecken långt.

Kan det verkligen det?
I *din* applikation?
Varför behöver du så låga filnamn?

The long filename system allows a maximum length of 255 UTF-16 characters, including spaces and non-alphanumeric characters (excluding the following characters, which have special meaning within the command interpreter or the operating system kernel: \ / : * ? " < > |).

Detta plus ett avslutande NULL på strängen blir 256.

Jag ser hellre till att jag klarar av långa filnamn redan från början än att efterhand sitta och ändra runt i all kod allt eftersom funktioner och filnamn ökar.

Svara på frågan istället...
Behöver du/kommer du att använda 255/256 teckens filnamn ??
Att bara allokera utrymme på en microkontroller utifrån någon
specifikation som i grunden är tänkt för en hetl annan plattform
är lite slappt och dålig design.

> Jag ser hellre till att jag klarar av långa filnamn...

Vad är "långt" för dig i detta sammanhang? För mig är 25-30 tecken "långt".
Speciellt med tanke på att det är en microcontroller applikation.

Kommer ditt citat från dokumentationen för MC's FAT32 rutiner?
Eller från någon FAT32 dokumentation från (t.ex) Microsoft?

Från http://ww1.microchip.com/downloads/en/a ... 01045b.pdf :
"Implementing File I/O Functions Using Microchip’s Memory Disk Drive File System Library"

Parameters
filename – A NULL terminated char string specifying the filename. This string must be stored in RAM.
The filename must be less than 8 characters, followed by a radix (.), followed by an extension
containing three or lesser characters. The filename cannot contain any directory or drive letter
information.

Är det de rutiner som beskrivs i den app noten som du använder?

Nu så verkar vissa av dina filnamn sm "inte funkar" vara kortare än så, men jag
skulle nog ändå minska ned variabeln så att den inte i onödan är större än vad
rutinerna i alla fall accepterar...

Hur sätter du ihop filnamnet, det låter som om du får en felaktigt sträng när du lägger ihop strängarna. Har du skrivit ut strängen i ascii för att kolla att den är vad du tror den är?

JA, jag behöver långa filnamn.

För det andra, det går utan problem att spara filer med långa filnamn.
För det tredje, stödjer man FAT32 så stödjer man långa filnamn.

Detta handlar om antalet filer i den aktuella mappen i kombination med filnamnet i sig som inte får innehålla något tecken 0-9.

SeniorLemuren skrev:Hur sätter du ihop filnamnet, det låter som om du får en felaktigt sträng när du lägger ihop strängarna. Har du skrivit ut strängen i ascii för att kolla att den är vad du tror den är?

Strängen är korrekt formaterad med avslutande NULL.
Har även gjort en egen funktion konvertera både int's till strängar och en egen funktion för att "NULL-padda" filnamnen.

Är det bara jag som reagerar på att de "icke fungerande" filnamnen har två punkter i sig?

Eller vänta nu, betyder inte fetstilen att det är ett filnamn?

Heter filerna "Day_1.txt till Day_2.txt" eller "Day_1.txt", "Day_2.txt", "Day_3.txt" osv?

Eftersom han även skriver att "Loop_day_1.txt" hänger sig direkt, så verkar det
ju mer vara ett formateringsproblem där även "till" har blivit i fetstil av misstag.
Men visst, *lite* otydligt är det kanske...

Sen så är det hela lite slarvigt med saknade referenser till använda
verktyg o.s.v. Och det var aldrig något svar kring om den app.note som
jag länkade till handlar om det använda verktyget eller inte. Slappt...

Å andra sidan så länkas det till denna app.note från en sida där även PIC32 nämns:
http://www.microchip.com/stellent/idcpl ... e=en537999
Jag hittar vid en snabb sökning inget annat liknande verktyg till PIC32.
Så frågan är, är denna app.note för det aktuella verktyget i tråden?
Och alltså är frågan fortfarande om det stycke som jag citerade är rellevant eller inte...

Och, det saknas fortfarande källhänvisning till det där om "long filenames". Jag hittar
det på Wikipedia, men det betyder ju ingentingting för det aktuella vektyget. Det finns
ingen anledning till att en specifik implementering måste stödja 255 tecken långa
filnamn, speciellt inte på en microcontroller.

Om det vore jag, skulle jag korta ner variablen för filnamn och se vad som händer...