Re: Do I always need an SDK in order to build drivers?



Are you using Windows CE 6? If so, CE 6.0 comes with an ARM emulator, great for testing.

Your USB scanner driver is built on top of the USB Stack. The USB Stack itself takes care of any hardware specifics, so your USB Scanner Driver is generic for all platforms. This means that a version compiled for ARM should work on all ARM platforms. No need to recompile against the device SDK every time. This is of course assuming (as you already stated) the target kernels have all necessary components in there.


Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.

minorguy wrote:
I’ve a built a USB scanner driver for Windows CE 5.0. I develop using a standard CEPC system with x86 processor. The driver works fine and we’ve even deployed it to a customer who is using it in an ARM system and that works OK. For that case, I had the customer export an SDK from Platform Builder and send it to me. Then I installed the SDK and built our scanner driver for that ARM platform. I have no way to test an ARM version of our driver yet, but fortunately it worked for them when they tried it.

So the policy I use for now is to request an SDK from each customer who wants to use our driver. But the number of requests is increasing and it will get too time-consuming to keep asking for SDKs and building our driver against each one. Can I just build our driver once for each of the different processor types x86, ARM, and MIPS and then give those out to everyone? It would seem that I can’t build unless I have at least one SDK for each type (and I don’t have a one for MIPS yet). But can I be reasonably sure that if I build an ARM version or our driver against one system’s SDK that it will work on a different ARM system? This is assuming that the BSP includes the components that I need, which in my case is USB host support. What's the normal way for handling this?

My second question is, do you know of a way that I can set up some sort of generic ARM system for testing? I have set up a CEPC for development and testing, but that only requires a standard x86 PC. Is there some similar hardware for ARM and MIPS that is recommended as a standard development platform?

Sorry for the naïve questions, but I haven’t had enough time to focus on Windows CE aside from just getting our driver to work on it with as little effort as possible. So there’s a lot I don’t know yet.

Thanks!

.



Relevant Pages

  • Re: USB mass storage and ARM cache coherency
    ... hence the ARM implementation of update_mmu_cachedoesn't flush ... before writing to a page cache page. ... The driver fix is as simple as calling a flush_dcache_pageand I've ... The only exception was an IDE ...
    (Linux-Kernel)
  • Re: USB mass storage and ARM cache coherency
    ... hence the ARM implementation of update_mmu_cachedoesn't flush ... the D-cache. ... Forget about PG_arch_1 and always do the flush? ... The driver fix is as simple as calling a flush_dcache_pageand I've ...
    (Linux-Kernel)
  • Do I always need an SDK in order to build drivers?
    ... I’ve a built a USB scanner driver for Windows CE 5.0. ... I had the customer export an SDK from Platform Builder and ... ARM platform. ... processor types x86, ARM, and MIPS and then give those out to everyone? ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [RFC] [PATCH -mm] ASIC3 driver
    ... driver will fial to compile on at least arm. ... I recall it does not include arm, ... ASIC3 driver - v3. ... * Copyright 2001 Compaq Computer Corporation. ...
    (Linux-Kernel)
  • Re: [PATCHSET] block: fix PIO cache coherency bug
    ... kernel page is the responsbility of the driver, syncing user page is ... Your understanding of the problem on ARM remains fundamentally flawed. ... accepting a read/write flag to note if we wrote to a vm page? ...
    (Linux-Kernel)