Accessing the SMBus through a Via 82C686

I am trying to talk to a device in an embedded PC that is on the
SMBus. The SMBus controller is a VT82C686.

I have never done driver development in Windows before so I'm a bit
unsure of how to proceed. I've read the relevant sections in the
Windows DDK and the questions and answers on usenet.

The DDK example appears to be for writing a driver for a SMBus
controller, rather than talking to an existing third-party driver. As
the Microsoft-written drivers won't work with the Via chipset, I'm
assuming the information I need will be from Via rather than MS.

The DDK confused me. Can I just write a user-space application to
talk to the SMBus controller, and have that pass on information? Does
anybody know where information on using the Via driver is?

Many thanks for any help.

Stephen.

Cody
Wed Sep 22 19:52:23 CDT 2004

SMBUS on an embedded pc ... that sounds like a familar project to me.
I can't go into too much of what I have done due to NDA, but what you
may find is that you will be lacking the bus driver for the Via chipset.
( I mention this as I spent alot of time on a wild goose chase only to
find that the vendor ( Via ) didn't provide the bus driver.)

On top of the non-existing bus driver you will want to write your own
custom class driver. The example smbus driver in the ddk a bunch
of over kill and almost more confusion than what it is worth. So the
short is don't get to tied up trying to figure this one out.

You may want to look at a generic port driver which shows how you can
use Ioctl to communcate between user space and your driver. I don't
know what you have in mind, but this is a pretty slick way to communicate.

I realize this is pretty brief but I hope it helps. Feel free to
drop me a line if you have some specific questions.

Cody

Stephen Bridges wrote:
> I am trying to talk to a device in an embedded PC that is on the
> SMBus. The SMBus controller is a VT82C686.
>
> I have never done driver development in Windows before so I'm a bit
> unsure of how to proceed. I've read the relevant sections in the
> Windows DDK and the questions and answers on usenet.
>
> The DDK example appears to be for writing a driver for a SMBus
> controller, rather than talking to an existing third-party driver. As
> the Microsoft-written drivers won't work with the Via chipset, I'm
> assuming the information I need will be from Via rather than MS.
>
> The DDK confused me. Can I just write a user-space application to
> talk to the SMBus controller, and have that pass on information? Does
> anybody know where information on using the Via driver is?
>
> Many thanks for any help.
>
> Stephen.

stephen
Sat Sep 25 11:26:33 CDT 2004

> On top of the non-existing bus driver you will want to write your own
> custom class driver. The example smbus driver in the ddk a bunch
> of over kill and almost more confusion than what it is worth. So the
> short is don't get to tied up trying to figure this one out.

I still haven't worked out what the SMBus example that MS provide is
supposed to *do*.

> You may want to look at a generic port driver which shows how you can
> use Ioctl to communcate between user space and your driver. I don't
> know what you have in mind, but this is a pretty slick way to communicate.

I was hoping to use this exact method, but unfortunately my low level
Windows programming is non-existant. Is there any literature you
could recommend?

> I realize this is pretty brief but I hope it helps. Feel free to
> drop me a line if you have some specific questions.

After looking in depth at the embedded board and the SMBus
specification, we've discovered that the board checks for a battery
charger, which, by SMBus definition, can only appear at a certain
address range. The charger we will be using (LTC1760) will indeed be
at this address. So currently I am waiting for the charging board to
be created so we can see if the BIOS detects it and provides it to the
OS. In that case it may simply be readable by the Battery API in
Windows, although whether it will detect the two batteries the charger
is controlling seperately or not is another matter.

Cody
Sat Sep 25 18:53:21 CDT 2004

Stephen Bridges wrote:
>>On top of the non-existing bus driver you will want to write your own
>>custom class driver. The example smbus driver in the ddk a bunch
>>of over kill and almost more confusion than what it is worth. So the
>>short is don't get to tied up trying to figure this one out.
>
>
> I still haven't worked out what the SMBus example that MS provide is
> supposed to *do*.

The smbbatt example illustrates how you can create your own class driver
which manages both a battery and charger connected to the smbus. I call
this example confusing due to the over lap of the battery functionality
in conjunction with the smbus functionality.
>
>
>>You may want to look at a generic port driver which shows how you can
>>use Ioctl to communcate between user space and your driver. I don't
>>know what you have in mind, but this is a pretty slick way to communicate.
>
>
> I was hoping to use this exact method, but unfortunately my low level
> Windows programming is non-existant. Is there any literature you
> could recommend?

The winhec website has a great deal of online resources for driver
development. In addition Walter Oney's Programming the Microsoft
Windows Driver Model, Second Edition is a wonderful book on the subject.

>
>
>>I realize this is pretty brief but I hope it helps. Feel free to
>>drop me a line if you have some specific questions.
>
>
> After looking in depth at the embedded board and the SMBus
> specification, we've discovered that the board checks for a battery
> charger, which, by SMBus definition, can only appear at a certain
> address range. The charger we will be using (LTC1760) will indeed be
> at this address. So currently I am waiting for the charging board to
> be created so we can see if the BIOS detects it and provides it to the
> OS. In that case it may simply be readable by the Battery API in
> Windows, although whether it will detect the two batteries the charger
> is controlling seperately or not is another matter.

If I read this correctly you are saying the bios pools the smbus on
initialization for devices. If you are lucky the battery api will
"magically" work for you; and in this case congrads! However I have a
feeling that you may need to provide the glue logic between the bios and
the battery api.

Note - if you are building a battery/charger system the smbbatt example
in the ddk would be an excellent starting point if you do need to
develop your own custom battery management system.

Cody

stephen
Mon Sep 27 08:37:17 CDT 2004

Cody Tews <tews@ieee.org> wrote in message news:<#BAHXr1oEHA.400@TK2MSFTNGP10.phx.gbl>...

> > I still haven't worked out what the SMBus example that MS provide is
> > supposed to *do*.
>
> The smbbatt example illustrates how you can create your own class driver
> which manages both a battery and charger connected to the smbus. I call
> this example confusing due to the over lap of the battery functionality
> in conjunction with the smbus functionality.

Ahh, there did seem like some overkill there for what is supposed to
be quite simple. I was worried it was due to the PnP support that WDM
requires.

> The winhec website has a great deal of online resources for driver
> development. In addition Walter Oney's Programming the Microsoft
> Windows Driver Model, Second Edition is a wonderful book on the subject.

Thanks.

> If I read this correctly you are saying the bios pools the smbus on
> initialization for devices. If you are lucky the battery api will
> "magically" work for you; and in this case congrads! However I have a
> feeling that you may need to provide the glue logic between the bios and
> the battery api.

This is what the BIOS *apparently* does. We won't know until we get
the actual charger board at some point. I'm hoping the battery API
will link in automatically, but I don't know how it will recognise the
charger - which is connected to TWO batteries. AH well.

> Note - if you are building a battery/charger system the smbbatt example
> in the ddk would be an excellent starting point if you do need to
> develop your own custom battery management system.

Well, I'm not trying to manage it, just poll the battery charges.

Stephen
> Cody