How to write a ADC ,I2C,SPI driver in wince5.0 ?

hi,
We are planning to develop the following drivers for windowsCE5.0:
1,driver for built in ADC
2,driver for I2C to drive i2c DAC ie MAX5841
3,driver to support serial flash for the density of 4mb using
SPI(AT25F4096)
The drivers are for the samsungs s3sc2410 RISC
microprocessor.i searched in platformbuilder help and there seems to be
no sample code for these drivers? Since i am new to wince i am totally
lost...can anyone please tell me if there is some sample driver
available which i am missing out or if someone has worked on these
drivers please let me know how to develop them or where to find some
tutorial for this.....

Thankyou

Voidcoder
Fri Apr 07 02:29:02 CDT 2006

There is no any "driver standard" for those interfaces.
All is up to you, just go on with your own driver
design and imagination.


<kamali.srinivasan@gmail.com> wrote in message news:1144385702.696292.228320@i39g2000cwa.googlegroups.com...
> hi,
> We are planning to develop the following drivers for windowsCE5.0:
> 1,driver for built in ADC
> 2,driver for I2C to drive i2c DAC ie MAX5841
> 3,driver to support serial flash for the density of 4mb using
> SPI(AT25F4096)
> The drivers are for the samsungs s3sc2410 RISC
> microprocessor.i searched in platformbuilder help and there seems to be
> no sample code for these drivers? Since i am new to wince i am totally
> lost...can anyone please tell me if there is some sample driver
> available which i am missing out or if someone has worked on these
> drivers please let me know how to develop them or where to find some
> tutorial for this.....
>
> Thankyou
>

Mark
Fri Apr 07 02:49:57 CDT 2006

Technically, the I2C driver should be a Windows CE Bus driver.
However, since you are just getting familiar with CE and because you
have a relatively simple device on the I2C bus you may want to consider
just writing a simple DAC driver that also embodied the I2C driver
using the basic stream I/O driver interface. Search for XXX_Init,
XXX_DeInit,etc in Platform Builder help. I would suggest starting with
your ADC driver though since I'm guessing it will be the simplest
driver of them all.

The serial flash driver will be non-trivial since I'm guessing you are
going to want CE to be able to mount a file system on it. You will
need to implement an Flash Media Driver for the flash part and link
this to the Flash Abstraction Layer, the result of which can be used by
the TFAT or FAT file system to store data in. The Flash Media Driver
is non-trivial work to do and has some tricky power management and
serialization issues that need to be carefully considered. Platform
Builder has some help on this but the sample source is what you are
going to want to study.

Mark Moeller
Qualnetics Corp.

Janez
Fri Apr 07 06:01:24 CDT 2006

Hi,

Try to download "Windows CE 5.0 Embedded Development Labs" from
http://www.microsoft.com/downloads/details.aspx?FamilyID=9ba15efe-e10e-47ff-93bc-24474e5a1a38&DisplayLang=en

which includes "DrvWiz - Windows CE stream driver wizard".
This will help you to generate wince stream driver code.
For example:
Driver name: ADC
Location: "your platform driver folder\ADC_driver"
Driver Filename: ADC_driver

Just add code to interface your ADC HW and include driver to WinCE
image.
Interfacing your driver from application is done in same way as opening
serail porst:

hIopFile = CreateFile(TEXT("ADC1:"), // "special" file name
GENERIC_READ|GENERIC_WRITE, // desired access
FILE_SHARE_READ|FILE_SHARE_WRITE, // sharing mode
NULL, // security attributes (=NULL)
OPEN_ALWAYS, // creation disposition
FILE_ATTRIBUTE_NORMAL, // flags and attributes
NULL); // template file (ignored)


**********************

Janez L.






kamali.srinivasan@gmail.com wrote:
> hi,
> We are planning to develop the following drivers for windowsCE5.0:
> 1,driver for built in ADC
> 2,driver for I2C to drive i2c DAC ie MAX5841
> 3,driver to support serial flash for the density of 4mb using
> SPI(AT25F4096)
> The drivers are for the samsungs s3sc2410 RISC
> microprocessor.i searched in platformbuilder help and there seems to be
> no sample code for these drivers? Since i am new to wince i am totally
> lost...can anyone please tell me if there is some sample driver
> available which i am missing out or if someone has worked on these
> drivers please let me know how to develop them or where to find some
> tutorial for this.....
>
> Thankyou

Remi
Fri Apr 07 10:32:45 CDT 2006

Sorry it it sounds dirty, but for 'simple' tasks such as ADC and master I2C,
you may also consider to include all necessary code in your application. For
instance you can create static libraries performing the needed tasks and and
link them to your 'noble' code.
Creating stream drivers to manage devices that will only be accessed by one
process and in a very specific way can be overkill sometimes.

Remi

<kamali.srinivasan@gmail.com> a écrit dans le message de news:
1144385702.696292.228320@i39g2000cwa.googlegroups.com...
> hi,
> We are planning to develop the following drivers for windowsCE5.0:
> 1,driver for built in ADC
> 2,driver for I2C to drive i2c DAC ie MAX5841
> 3,driver to support serial flash for the density of 4mb using
> SPI(AT25F4096)
> The drivers are for the samsungs s3sc2410 RISC
> microprocessor.i searched in platformbuilder help and there seems to be
> no sample code for these drivers? Since i am new to wince i am totally
> lost...can anyone please tell me if there is some sample driver
> available which i am missing out or if someone has worked on these
> drivers please let me know how to develop them or where to find some
> tutorial for this.....
>
> Thankyou
>

bluesphere
Fri Apr 07 16:33:40 CDT 2006

If you tie your I2C port to a single application
(or dedicated driver) it will be hard to add a future
application that shares the I2C bus. I'm surprised
that I2C and SPI drivers are not so taken into account.
A general I2C (SPI) driver is due. It would do bus
arbitration and manage several devices.Dedicated
drivers might be layered on top of that.
Make it once, reuse it forever.

"Remi de Gravelaine" <gravelaine at aton dash sys dot fr> wrote in message
news:%23$wzNilWGHA.1196@TK2MSFTNGP03.phx.gbl...
> Sorry it it sounds dirty, but for 'simple' tasks such as ADC and master
I2C,
> you may also consider to include all necessary code in your application.
For
> instance you can create static libraries performing the needed tasks and
and
> link them to your 'noble' code.
> Creating stream drivers to manage devices that will only be accessed by
one
> process and in a very specific way can be overkill sometimes.
>
> Remi
>
> <kamali.srinivasan@gmail.com> a écrit dans le message de news:
> 1144385702.696292.228320@i39g2000cwa.googlegroups.com...
> > hi,
> > We are planning to develop the following drivers for windowsCE5.0:
> > 1,driver for built in ADC
> > 2,driver for I2C to drive i2c DAC ie MAX5841
> > 3,driver to support serial flash for the density of 4mb using
> > SPI(AT25F4096)
> > The drivers are for the samsungs s3sc2410 RISC
> > microprocessor.i searched in platformbuilder help and there seems to be
> > no sample code for these drivers? Since i am new to wince i am totally
> > lost...can anyone please tell me if there is some sample driver
> > available which i am missing out or if someone has worked on these
> > drivers please let me know how to develop them or where to find some
> > tutorial for this.....
> >
> > Thankyou
> >
>
>

Remi
Sat Apr 08 04:41:34 CDT 2006

> If you tie your I2C port to a single application
> (or dedicated driver) it will be hard to add a future
> application that shares the I2C bus.

I agree. What I was trying to say is that *if* you have a vertical
application in which a *single slave* device has to be accessed through the
I2C, there is no need for a driver: a library or even a piece of code
(probably already existing) is enough.

> I'm surprised
> that I2C and SPI drivers are not so taken into account.
> A general I2C (SPI) driver is due. It would do bus
> arbitration and manage several devices.Dedicated
> drivers might be layered on top of that.

Hum. IMO, it's over-complicated and a MDD would have almost nothing really
useful to do. Managing devices is a task that belongs to the initiator and
arbitration is a really simple job, presumably involving a single critical
section. So all the interesting code would fall into the dedicated driver.
Of course, one can imagine some kind of bloated model involving a quantity
of C++ classes but its definitly not my cup of tea.
A sample (dedicated) driver exposing a few pre-defined IOControls would
however be an appreciated template.

Remi

bluesphere
Sun Apr 09 04:11:06 CDT 2006

I know you were referring to vertical applications. And i'm not
here to say what's right or what is wrong. Most of the time
what is best is the result of tradeoffs between time and money
(and whatever might be conditioning)

However if you spent some time in writing I2C support or whatever,
why reinvent the wheel the next time you need I2C? A library is ok,
but what about versioning? You may have different apps linked to
different versions of the same lib. Sooner or later this might break a
driver usage policy and make it inconsistent.

The general driver i was talking about is not a MDD one, though. It's a
MDD one turned upside down. It only handles the I2C common
support. Application drivers like ADC, DAC, EEPROM, RTC,
RADIO FM control (interesting code) rely on that.

You mentioned CRITICAL SECTIONS. Do you think it is possible
to use them to lock IoControl accesses instead of MUTEXES?
(thread issue?) I always wondered.


"Remi de Gravelaine" <gravelaine at aton dash sys dot fr> wrote in message
news:OFOZxCvWGHA.3864@TK2MSFTNGP04.phx.gbl...
> > If you tie your I2C port to a single application
> > (or dedicated driver) it will be hard to add a future
> > application that shares the I2C bus.
>
> I agree. What I was trying to say is that *if* you have a vertical
> application in which a *single slave* device has to be accessed through
the
> I2C, there is no need for a driver: a library or even a piece of code
> (probably already existing) is enough.
>
> > I'm surprised
> > that I2C and SPI drivers are not so taken into account.
> > A general I2C (SPI) driver is due. It would do bus
> > arbitration and manage several devices.Dedicated
> > drivers might be layered on top of that.
>
> Hum. IMO, it's over-complicated and a MDD would have almost nothing really
> useful to do. Managing devices is a task that belongs to the initiator and
> arbitration is a really simple job, presumably involving a single critical
> section. So all the interesting code would fall into the dedicated driver.
> Of course, one can imagine some kind of bloated model involving a quantity
> of C++ classes but its definitly not my cup of tea.
> A sample (dedicated) driver exposing a few pre-defined IOControls would
> however be an appreciated template.
>
> Remi
>
>

Remi
Sun Apr 09 11:18:34 CDT 2006

Well, first of all, sorry Kamali for using your thread for our discussion.

Bluesphere: sorry too: I didn't catch what your general I2C driver was
supposed to do.
I am sceptical though, because I hardly see how genericity can be achieved
when it comes to act on I2C signals. I come from the industrial PC world and
I had to write various I2C routines to deal with hardwares as different as
PC parallel ports (yes, you can carve SDA and SCK signals with that!), Intel
chipsets' SMBus, STPC I2C, custom made I2C, etc. For each hardware, I had to
reinvent at least a part of the wheel...

To be honest, I must also say that I never had to manage more than one
device for a given I2C bus. It is probably a specificity of the x86 world,
where I2C is not the prefered bus for interfacing devices, and I easily
understand that the needs are differents for pin-struggled ARM-based
devices. Here, I completely agree with you: a driver is the best solution.

In streams drivers, I always used CriticalSections without trouble. I
suppose this is OK because these drivers are hosted by the 'device' process
and because caller processes are thunked into this unique process space.
Mutexes must be used when the code can be accessed by different processes.

Have a nice day.
Remi

bluesphere
Mon Apr 10 16:49:11 CDT 2006

I agree with you when you say that I2C is not so spread. I2C still belongs
to electronics (not so close to users) and it cannot be compared to USB, PCI
devices that even users can handle (plugging them in) From a computer
science point of view though i would choose a general solution because it's
reusable (am i lazy? ;)


"Remi de Gravelaine" <gravelaine at aton dash sys dot fr> wrote in message
news:uirkFF$WGHA.4768@TK2MSFTNGP05.phx.gbl...
> Well, first of all, sorry Kamali for using your thread for our discussion.
>
> Bluesphere: sorry too: I didn't catch what your general I2C driver was
> supposed to do.
> I am sceptical though, because I hardly see how genericity can be achieved
> when it comes to act on I2C signals. I come from the industrial PC world
and
> I had to write various I2C routines to deal with hardwares as different as
> PC parallel ports (yes, you can carve SDA and SCK signals with that!),
Intel
> chipsets' SMBus, STPC I2C, custom made I2C, etc. For each hardware, I had
to
> reinvent at least a part of the wheel...
>
> To be honest, I must also say that I never had to manage more than one
> device for a given I2C bus. It is probably a specificity of the x86 world,
> where I2C is not the prefered bus for interfacing devices, and I easily
> understand that the needs are differents for pin-struggled ARM-based
> devices. Here, I completely agree with you: a driver is the best solution.
>
> In streams drivers, I always used CriticalSections without trouble. I
> suppose this is OK because these drivers are hosted by the 'device'
process
> and because caller processes are thunked into this unique process space.
> Mutexes must be used when the code can be accessed by different processes.
>
> Have a nice day.
> Remi
>
>