Hi Andrew,

    Basing time on the file creation time is a good idea - any idea how 
many files I can create with this FAT version?  I've seen some comments 
about a max of 256, but this seems a little restrictive.

Thanks,

Tony


andrew kelley wrote:
> On Sat, Dec 19, 2009 at 9:08 PM, Tony Vandiver
> <tony@traceelectronics.com> wrote:
>   
>> I'm trying to develop an RS-232 protocol sniffer that lets a DB9 cable
>> pass through my board and captures all the communication in both
>> directions.  I want to log all this data to an onboard USB flash drive,
>> and I'm having trouble coming to terms with something that happens in
>> the FAT implementation.  Essentially, around every 32K characters sent
>> (I'm buffering between 400 and 512 bytes per write), the library code
>> blocks for up to 1.2 seconds.  I've tracked it down to a call to
>> fsfwrite and then to flushdata, then to USBHostMSDSCSISectorWrite which
>> has this blocking code :
>>
>> while (!USBHostMSDTransferIsComplete( deviceAddress, &errorCode,
>> &byteCount ))
>> {
>>    USBTasks();
>> }
>>     
>
>   
>> So apparently, the library code just blocks while waiting for the mass
>> storage device to complete the data transfer.  Does anyone have a
>> suggestion about how to handle this?  I'm buffering the incoming
>> characters in interrupts so they don't get lost, but I was hoping to log
>> them to the drive with timestamps, and buffering the timestamp along
>> with every incoming character for 1 second gets pretty cumbersome in
>> terms of ram usage (especially at high monitored baud rates).
>>     
>
> Well perhaps you could insert a quick call in the loop there with
> USBTasks() that makes a call to your data check available code?
> You'll need two buffers ideally, one for outgoing to MSD, one for
> incoming from serial, then flop them around when MSD is done and when
> input buffer is full.
>
>   
>> I know I
>> can work around it for low data rates (I've been trying to think of a
>> relative timestamp that could just be a byte or two per character
>> instead of the whole date time), but I'm wondering if there are better
>> approaches than the Microchip library for this, and also whether anyone
>> has experienced this kind of time delay when logging to flash drives.
>>     
>
> Well in that regard, why not put a differential time stamp?
> IE:
> Start of file is start time
> Delta Time, direction, data length for sequence, data,
> repeat until end of capture
>
>   
>> Thanks,
>>
>> Tony
>>     
>
>
> HTH
> Andrew Kelley
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist