Re: Unable to download large files using FTP (resource problem)

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



The modern flash media (nothing to do with ARM), all handle the multiple
write problem in such a way that the effect on you, the user, is minimized.
The processor/OS have no idea what's going on behind their backs. If it's
an ATA Compact Flash card, for example, it's just handled on the card. It's
totally invisible to the OS code and driver. You don't know what location
in flash you're writing to; you're writing to a "file", which, in turn, maps
to some "sectors" in the filesystem. How those are implemented in flash is
handled by the card itself.

Paul T.

"Yerahmiela" <Yerahmiela@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F6655C4E-3711-49B5-847D-453700701B54@xxxxxxxxxxxxxxxx
That's good to hear. By modern device, I suppose you mean the ARM?
We aren't sure yet what specific flash card we'll use, but it will be a
NAND
flash card.

How can we be sure that our device / OS takes care of this issue?
We are not developing the drivers in our company. Is there anything we
should verify with the board manufacturer / driver writer?

Regards,
~Y.

"Paul G. Tobey [eMVP]" wrote:

No, that's the first I can recall hearing of that specific problem.
Don't
worry about the flash. If it's a modern device, you'll be tired of that
same old card and will throw it away and buy the latest version/capacity
before you run into a problem with too many writes. The flash cards all
handle moving things around so that the write limitations don't affect
you
too much.

Paul T.

"Yerahmiela" <Yerahmiela@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:83080A1D-27DF-4D58-B7CB-47DA5D4D034E@xxxxxxxxxxxxxxxx
Thanks.

I found out I can use a flag indicating to use an intermediate file
instead
of writing to the cache, when needed. This seemed to solve my problem
with
receiving large files over the FTP (which were previously saved to the
object
store) on the target.
My only concern is the number of "write" actions that are performed
during
this operation, since we will be using a Flash memory card and the
number
of
"write" (delete) operations over it is limited.

Do you happen to know what block size does the FTPGetFile function use
when
the INTERNET_FLAG_NEED_FILE is on, or if this should cause a problem?

Regards,
~Y.


"Paul G. Tobey [eMVP]" wrote:

You could check for a file called ceconfig.h in the \Windows folder.
That
will list the SYSGEN constants that were used to build the OS. I'm
not
sure
if that gets included in WM devices, but it does in generic Windows CE
devices.

Paul T.

"~Y." <~Y.@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7FC5BD10-C9BB-4CC1-B40F-827A6020C98B@xxxxxxxxxxxxxxxx
Hi Paul,

Thank you very much for your quick and informative response.

The FTP freeware was actually designed for an ARM board.

Though we will try to test the application on the target board
shortly,
I would like to know what component(s) we are missing on the
emulator
we
built.

Is there a way to see the components that are included in the
Windows
mobile
5.0 pocket PC?



"Paul G. Tobey [eMVP]" wrote:

Since you're the one building the emulator, I'd guess that it's
your
fault.
You found freeware FTP client applications to try to run on the
emulator,
but you didn't say what *platform* they were targeted for. Pocket
PC
would
be a likely answer and, if your OS isn't built with the same set of
components as Pocket PC, or if the installer for the freeware
clients
is
checking *specifically* for that particular platform, that would
cause
the
problem.

The basic fact is that emulators are piling so many network layers
on
top
of
one another that they are not really appropriate test platforms for
real
network programs. You verified that, generally, your code works on
the
emulator and that's better than I would have expected. Don't waste
much
time trying to make it work perfectly, as it never will and your
time
would
be better spent actually making the code run right on a real
device.

Paul T.

"Yerahmiela" <Yerahmiela@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:9C944FFF-B0F7-4C7D-9F76-923F7542C95F@xxxxxxxxxxxxxxxx
Hi all,

We are developing an emultor of an ARM board using winCE5.0 (with
the
platform builder).
I have implemented an FTP client in visual studio 2005, using the
wininet
library over this platform.

The client seems to be working fine over other emulators (such as
Windows
mobile 5.0 pocket PC).
It also works fine over our platform when transfering short
files.
(I
use
my
PC as the server).
But when I try to receive a larger file (over 1MB) with our
emulator,
the
FTP client gets stuck, and when pinging my PC from the emulator,
I
receive
the following error message:
PING transmit failed. error code: 11010,
which I saw is related to QOS and is a result of lack of
resources
(?).

I would like to know what is causing this problem (and how to fix
it,
of
course :) ).

Another little thing - I tried to execute some freeware FTP
clients
for
wince on our emulator (by copying the .CAB file, or running a
setup
over
my
PC and connecting through ActiveSync), but the emulator does not
recognize
these programs as winCE applications.
Is our emultor missing a component?

Thanks in advance, and have a great weekend,
~Y











.



Relevant Pages

  • OT/Drifting
    ... The bad news is my son bricked his trying to flash the OS and I did a ham ... It would be nice if they would port the Atari emulator to it for us. ... If you can control the meaning of words, ...
    (comp.sys.atari.8bit)
  • Re: Unable to download large files using FTP (resource problem)
    ... worry about the flash. ... I would like to know what componentwe are missing on the emulator ... but you didn't say what *platform* they were targeted for. ... I have implemented an FTP client in visual studio 2005, ...
    (microsoft.public.windowsce.app.development)
  • Re: Atari design group?
    ... In the dozen or so years I have been reading this group I have formed an opinion of what it would take to get them to purchase a revised Atari 8 bit. ... the next iteration would be to go the emulator route. ... You could do 40 mHz ARM with 512k flash and have everything but the variables in flash including anything Atari you wanted like OS and BASIC ROMS. ... That isn't a lot but it could get a minimal system going w/o having to add an external RAM. ...
    (comp.sys.atari.8bit)
  • Re: Recommendations for an Eprom Emulator
    ... As the probable Forth vendor for the Leburg EPROM emulator, ... Emulating Flash ...
    (comp.arch.embedded)
  • Re: Where did my memory go
    ... with only 512 KB visible from the emulated software? ... The emulated Saturn doesn't have any room to expand the address space, ... emulator, in other words, it would be HPGCC-only ram (but still a great ... the Saturn can only support a limited number of flash ...
    (comp.sys.hp48)