Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
End Users
Pocket PCActiveSyncMultimediaEBooksWirelessSmartPhones
Developers
Windows MobileSmartPhonesWinCE ProgrammingVB for WinCEVC++ for WinCEPlatform BuilderTest Tools
PocketPC DirectoryFree SoftwareWeb Resources
Related Topics
PalmMobile PhonesMore Topics ...

Pocket PC Forum / Developers / WinCE Programming / February 2010

Tip: Looking for answers? Try searching our database.

RAM or ROM directories

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Tommaso - 30 Jan 2010 15:22 GMT
Hi,
In my OS Design I've compression enabled and RAM and ROM file system.
I'm new to CE and it's not clear to me  which dirs are placed in RAM and
which in ROM.
If I copy files to \Windows or \Temp dirs: it takes quite long and after
power off on they're lost. As it takes long I could say "these dirs are in
flash mem" but as they're lost I should say the opposite. Unless it's due to
compression and the dir I see are a mix of ram and flash?

If I copy files to \NandFlash dir: it takes about the same but after power
off on files remain.

Regards
Tommaso
Paul G. Tobey [eMVP] - 30 Jan 2010 16:05 GMT
When you use RAM&ROM, \windows is a combination of the files buillt into the
OS image (files listed in your BIB files for the build), and whatever you
copy to the overlayed RAM filesystem.  It's all either permanently present
(ROM), or non-persistent (RAM).  There is no persistent filesystem there.

It seems like, if you designed this OS, you should understand what parts of
the filesystem are persistent and which are not.  After all, you're the one
who set that all up.

Paul T.

> Hi,
> In my OS Design I've compression enabled and RAM and ROM file system.
[quoted text clipped - 11 lines]
> Regards
> Tommaso
Tommaso - 30 Jan 2010 19:21 GMT
Hi,
I've got an evaluation board with a BSP already present and a list of steps
to make the OS Design, so I didn't design that by my own.
What about the time taken to make a copy (about 2 secs for 1MB on an ARM
600mhz)?

> When you use RAM&ROM, \windows is a combination of the files buillt into the
> OS image (files listed in your BIB files for the build), and whatever you
[quoted text clipped - 24 lines]
>
> .
Paul G. Tobey [eMVP] - 31 Jan 2010 21:35 GMT
That will depend on the type of RAM/flash, how the RAM/flash is interfaced,
the code in the driver and potentially the code in the BSP itself.  Flash
writing is an I/O-bound  process, so the speed of the processor probably has
little to do with it.  RAM writing is, I think, largely processor bound.  It
doesn't seem wildly outrageous to me, depending on the source of the copy
which you didn't tell us, that you'd get that sort of speed.  You could give
us some more information and maybe someone has a parallel experience to
compare.  600MHz would be faster than any production processor I've used in
the ARM line.

Paul T.

> Hi,
> I've got an evaluation board with a BSP already present and a list of
[quoted text clipped - 40 lines]
>>
>> .
Tommaso - 01 Feb 2010 08:46 GMT
Hi,
I simply copied by Copy & Paste, for example from \Temp\myfile to
\Windows\myfile. If I try with a simple C appl via fopen,fread and fwrite, I
see it be slow until memory pages are only reserved but not used, and very
fast then.
I mean, If I read twice a 10MB files (very larger than any cache) to the
same buffer, the first time it'0s slow and the 2nd very fast.
I don't know how WinCE implements Copy & Paste

> That will depend on the type of RAM/flash, how the RAM/flash is interfaced,
> the code in the driver and potentially the code in the BSP itself.  Flash
[quoted text clipped - 54 lines]
>
> .
Paul G. Tobey [eMVP] - 01 Feb 2010 14:56 GMT
There is no copy and paste at the filesystem level.  If you copy a file and
paste the file in the filesystem somewhere, a CopyFile() call is almost
certainly what happens behind the scenes.  Explorer is doing that.  Windows
CE isn't going to do something fancy for that kind of an operation.  What are
the numbers?  Fast and slow don't mean anything.  How much RAM do you have
devoted to the RAM filesystem?  If Windows CE is having to move the program
RAM/filesystem RAM boundary around while you're doing this, I have no doubt
that will slow it down...

Paul T.

> Hi,
> I simply copied by Copy & Paste, for example from \Temp\myfile to
[quoted text clipped - 63 lines]
> >
> > .
Tommaso - 02 Feb 2010 07:42 GMT
Hi, I've 30Mbytes free in the RAM file system, ARM 600Mhz DDR 166Mhz: it
takes around 1sec for copying 1MByte.
Tommaso

> There is no copy and paste at the filesystem level.  If you copy a file and
> paste the file in the filesystem somewhere, a CopyFile() call is almost
[quoted text clipped - 74 lines]
> > >
> > > .
Paul G. Tobey [eMVP] - 02 Feb 2010 23:59 GMT
OK, so I think to get real information, you'll have to verify the exact time
to complete the copy.  I have whipped up a program to create a file, copy it,
and calculate how long it took.  On my development machine with a very fast
hard disk, it was about 10-12ms.  Don't have a Windows CE device with RAM
filesystem enabled to try, but give it a try yourself and let us know what
results you get (note that I didn't create a method to get the data, other
than the debugger, so you'll have to enhance it for CE a bit).

While you're at it, tell us some more information about this build:

Windows CE version?
DEBUG or RETAIL build?
if RETAIL build, is the BSP outputting RETAIL messages?
if DEBUG build, are you connected to Platform Builder for kernel debug,
RELFSD directory access?

Paul T.

-----

// copyspeed.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include "windows.h"

#define    SOURCE_FILE _T( "\\testfile.txt" )
#define DESTINATION_FILE _T( "\\testdestination.txt" )

char _16bytes[] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A',
'B', 'C', 'D', 'E', 'F' };

int _tmain(int argc, _TCHAR* argv[])
{
    // Create a 1MB file.
    HANDLE    hf = CreateFile(  SOURCE_FILE, GENERIC_READ | GENERIC_WRITE, 0,
        NULL, CREATE_ALWAYS, 0, NULL );

    // Write the data.
    for ( long i = 0; i < 1024*16*4; i++ )
    {
        DWORD    count;
        WriteFile( hf, &_16bytes[0], 16, &count, NULL );
    }

    // Close the file.
    CloseHandle( hf );

    // Delete the target file.
    DeleteFile( DESTINATION_FILE );

    // Copy the file, after counting the ticks.
    DWORD    startTick = GetTickCount();

    CopyFile( SOURCE_FILE, DESTINATION_FILE, FALSE );

    DWORD    endTick = GetTickCount();

    DWORD    ticks = endTick - startTick;

    return 0;
}
Tommaso - 03 Feb 2010 09:24 GMT
Hi,
I tried, it takes several secs to create the file, then it takes a variable
time from 300 to 800 ticks.
I have WinCE 6.0, RETAIL build, I can see RETAIL msg.
I dont' know what RELFSD directory access exactly is, sorry.
Thanks

> OK, so I think to get real information, you'll have to verify the exact time
> to complete the copy.  I have whipped up a program to create a file, copy it,
[quoted text clipped - 59 lines]
>     return 0;
> }
Paul G. Tobey [eMVP] - 03 Feb 2010 15:39 GMT
That's longer than I would expect, but not outrageously long, I think.  10x
what the desktop can do seems pretty reasonable.  This is 30x to 80x.  You
were NOT running the code in the debugger, right?  That might really slow
things down.

RelFSD is a driver that you can put in your OS, typically just a DEBUG
build, that makes the flat release folder on the Platform Builder computer
appear as a folder on the device. This allows you to modify, for example, a
driver, compile it on the PB computer, then get the device to load it, all
without regenerating nk.bin and reflashing the device.  Because it appears in
the filesystem, I wanted to be sure you weren't using it.

If it were me, at this point I'd evaluate how important this is.  How often
does this happen on the device when it's running in the field?  Can I change
how other code works to minimize the effect of this or reduce its frequency.  
If RAM filesystem is slow and flash is actually faster (which seems
impossible), can't I change what I'm doing to use the faster media?  If none
of that is possible, I guess that a support incident with MS is the next
step.  I don't see anything else that you could be doing "wrong" (minor
improvements might be possible depending on how your processor talks to the
RAM and what settings are configured for that).

Paul T.

> Hi,
> I tried, it takes several secs to create the file, then it takes a variable
[quoted text clipped - 66 lines]
> >     return 0;
> > }
Tommaso - 08 Feb 2010 15:23 GMT
Hi,
I'm not running the code on the debug. I'm not using RelFSD.
I was testing the copy of file just to have an idea of what I could expect
in terms of performance by my DDR, supposing that the WinCE CopyFile was very
optimized. But I was wrong. It's not a big problem for my appl itself, as I
will do differently. At the end I became just curious to understand why
CopyFile is slow.
Thanks
Tommaso

> That's longer than I would expect, but not outrageously long, I think.  10x
> what the desktop can do seems pretty reasonable.  This is 30x to 80x.  You
[quoted text clipped - 90 lines]
> > >     return 0;
> > > }
Paul G. Tobey [eMVP] - 08 Feb 2010 16:09 GMT
I don't think it makes sense to say "I want CopyFile to be optimized".  How?  
All it can do is read the input file and write the output file.  I guess that
you could build your own version that might be fractionally faster than the
default, but this has to work with all filesystems on any Windows CE device
that can run the standard shell, so the amount of fooling around to get that
extra 5-10% performance is pretty limited.

Paul T.

> Hi,
> I'm not running the code on the debug. I'm not using RelFSD.
[quoted text clipped - 100 lines]
> > > >     return 0;
> > > > }
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.