Hi,
i need to know the limitation imposed by windows(XP and 7) in the extent of information query.
thanks in advance
Can you be a lot more clear? WHAT information query? About what, where, when, why?
The title of your post says “SMBUS” something… As general information, I can tell you that through Windows 7 the Windows OS basically considers the SMBUS to be something that’s handled by the BIOS. There is no standard Windows 7 (or XP) bus driver for the SMBUS.
Please feel free to follow-up if you have specific questions,
Peter
OSR
Some years ago I actually got to talk to someone who had designed the
interface for their device. He chose the SMBus because “I could put the
logic in an FPGA and didn’t need any complicated PCI interface circuitry”.
The SMBus is tempting to designers because it looks easy to interface to,
but again, this is the hardware designer bias; they are not responsible
for the fact that it is nearly impossible to write a driver to these
devices for a large set of reasons. In fact, he considered it an excuse
used by incompetent programmers. His responsibility ended when he could
show the device worked on a standalone dedicated machine, and OS
interfacing was someone else’s responsibility.
joe
Can you be a lot more clear? WHAT information query? About what, where,
when, why?The title of your post says “SMBUS” something… As general information, I
can tell you that through Windows 7 the Windows OS basically considers the
SMBUS to be something that’s handled by the BIOS. There is no standard
Windows 7 (or XP) bus driver for the SMBUS.Please feel free to follow-up if you have specific questions,
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
This was long ago… and then come ARM tablets and Win8. PCI cores cost
money. Hardware engineers are expensive, driver writers are cheap.
– pa
On 11-May-2012 00:52, xxxxx@flounder.com wrote:
Some years ago I actually got to talk to someone who had designed the
interface for their device. He chose the SMBus because “I could put the
logic in an FPGA and didn’t need any complicated PCI interface circuitry”.
The SMBus is tempting to designers because it looks easy to interface to,
but again, this is the hardware designer bias; they are not responsible
for the fact that it is nearly impossible to write a driver to these
devices for a large set of reasons. In fact, he considered it an excuse
used by incompetent programmers. His responsibility ended when he could
show the device worked on a standalone dedicated machine, and OS
interfacing was someone else’s responsibility.
joe
> The SMBus is tempting to designers because it looks easy to interface to,
I don’t think there are any standard ways to extend SMBus wiring beyound the motherboard.
So, the SMBus hardware must be either a) soldered to the motherboard or b) proprietary motherboard add-ons from the same vendor.
In both cases, this is not a problem to write ACPI methods for the device in the BIOS code, and then use them from Windows using ACPI/WMI interface.
No driver needed at all - SMBus is slow, and the WMI performance is OK for it.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
What do I need to read to do this? I have a (potential) project which
needs just this sort of solution. I assume I need to track down the
ACPI spec, and read up on WMI; what else should I know in order to make
some SMBus devices (on the motherboard) available to applications in
Windows (XP and later)?
TIA,
–mkj
On 5/11/2012 12:34 PM, Maxim S. Shatskih wrote:
> The SMBus is tempting to designers because it looks easy to interface to,
I don’t think there are any standard ways to extend SMBus wiring beyound the motherboard.
So, the SMBus hardware must be either a) soldered to the motherboard or b) proprietary motherboard add-ons from the same vendor.
In both cases, this is not a problem to write ACPI methods for the device in the BIOS code, and then use them from Windows using ACPI/WMI interface.
No driver needed at all - SMBus is slow, and the WMI performance is OK for it.
–
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
Start reading with IOCTL_ACPI_EVAL_METHOD maybe.
The spec (or at least ACPI ASL code samples) is maybe also a must.
I cannot tell you what is the doc on ACPI-to-WMI bindings which will allow you to write no drivers for an ACPI device, but they should exist I think (ask Jake Oshins 
). At least some machines are claimed to support WMI fans and voltage probes by ACPI table alone, without a proprietary driver.
Or, you can go the way Asus uses for their fan/voltage/temperature stuff, and write the driver for it (like Asus’s AsAcpi.sys), which will sit on top of the simple ACPI devnode (like Asus’s ATK0110) and expose custom IOCTLs to user mode (like to AsusProbe applet).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Michael Jones” wrote in message news:xxxxx@ntdev…
> What do I need to read to do this? I have a (potential) project which
> needs just this sort of solution. I assume I need to track down the
> ACPI spec, and read up on WMI; what else should I know in order to make
> some SMBus devices (on the motherboard) available to applications in
> Windows (XP and later)?
>
> TIA,
>
> --mkj
>
> On 5/11/2012 12:34 PM, Maxim S. Shatskih wrote:
>>> The SMBus is tempting to designers because it looks easy to interface to,
>>
>> I don’t think there are any standard ways to extend SMBus wiring beyound the motherboard.
>>
>> So, the SMBus hardware must be either a) soldered to the motherboard or b) proprietary motherboard add-ons from the same vendor.
>>
>> In both cases, this is not a problem to write ACPI methods for the device in the BIOS code, and then use them from Windows using ACPI/WMI interface.
>>
>> No driver needed at all - SMBus is slow, and the WMI performance is OK for it.
>>
>
> –
>
> //
> // Michael K. Jones
> // Stone Hill Consulting, LLC
> // http://www.stonehill.com
> //
>
Here are the ACPI-to-WMI bindings docs:
http://msdn.microsoft.com/en-us/windows/hardware/gg463463
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
The context was embedded systems. And there was no BIOS code written.
The programmer was simply ex[ected to make it work. And yes, there were
serveral devices soldered to the motherboard.
joe
> The SMBus is tempting to designers because it looks easy to interface
> to,I don’t think there are any standard ways to extend SMBus wiring beyound
the motherboard.So, the SMBus hardware must be either a) soldered to the motherboard or b)
proprietary motherboard add-ons from the same vendor.In both cases, this is not a problem to write ACPI methods for the device
in the BIOS code, and then use them from Windows using ACPI/WMI interface.No driver needed at all - SMBus is slow, and the WMI performance is OK for
it.–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Sorry, should have been more explicit: it’s a PC-on-a-VME-board, so it
does have a BIOS and it is running Windows. They want to add several
bits of hardware to the board (temp. sensor, voltage sensor, watchdog
timer, and some of the ID chip which I haven’t seen the spec for yet),
all of which will sit on the SMBus. And they have a BIOS source
license; hence my interest in what is required to get this to work.
Cheers,
–mkj
On 5/11/2012 12:59 PM, xxxxx@flounder.com wrote:
The context was embedded systems. And there was no BIOS code written.
The programmer was simply ex[ected to make it work. And yes, there were
serveral devices soldered to the motherboard.
joe>> The SMBus is tempting to designers because it looks easy to interface
>> to,
>
> I don’t think there are any standard ways to extend SMBus wiring beyound
> the motherboard.
>
> So, the SMBus hardware must be either a) soldered to the motherboard or b)
> proprietary motherboard add-ons from the same vendor.
>
> In both cases, this is not a problem to write ACPI methods for the device
> in the BIOS code, and then use them from Windows using ACPI/WMI interface.
>
> No driver needed at all - SMBus is slow, and the WMI performance is OK for
> it.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
Perhaps skip the BIOS approach and write a driver for the SMBUS host that’s bound to already be part of the PCH?
Peter
OSR
Possibly; I need to find out what else is currently on on the SMBus, and
what (if anything) the current BIOS is doing with it. I would assume
that, if I go the driver route, I would need to change the BIOS to not
muck with the SMBus…
–mkj
On 5/11/2012 3:13 PM, xxxxx@osr.com wrote:
Perhaps skip the BIOS approach and write a driver for the SMBUS host that’s bound to already be part of the PCH?
Peter
OSR
–
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
It’s polite to at least check
It’s actually possible for multiple masters to be on the bus at the same time… so that’s a good thing. And there IS an interlock bit (if the BIOS firmware uses it) in the standard Intel PCH implementation that’s designed to help prevent multiple sources from trying to party on the controller simultaneously… despite having done tons of SMBUS-related stuff over the past few years, I’ve never played with the synchronization bit, so can’t really say if it works as advertised.
This sort of approach would be good for an embedded system, or for a prototype… I’m not sure you’d want to be shipping a general-purpose solution that does this. But IIRC, you’re focused on an embedded system for this, right?
Peter
OSR
Well, sort of. These new SMBus devices are indeed for a special version
of the board for a particular customer. However, I have no idea what
THEY are going to do with it, and I fully expect the company which makes
these things to make this version generally available.
So, while the market is small, I still need to treat it like a
general-purpose product (to the extent that’s possible and makes sense).
If there’s just no reasonable way to get there, then we’ll need to
constrain the solution; that’s why I was excited about Max’s post
(writing ACPI methods in the BIOS, and using WMI to access them without
having to write a driver).
–mkj
On 5/11/2012 3:52 PM, xxxxx@osr.com wrote:
It’s polite to at least check
It’s actually possible for multiple masters to be on the bus at the same time… so that’s a good thing. And there IS an interlock bit (if the BIOS firmware uses it) in the standard Intel PCH implementation that’s designed to help prevent multiple sources from trying to party on the controller simultaneously… despite having done tons of SMBUS-related stuff over the past few years, I’ve never played with the synchronization bit, so can’t really say if it works as advertised.
This sort of approach would be good for an embedded system, or for a prototype… I’m not sure you’d want to be shipping a general-purpose solution that does this. But IIRC, you’re focused on an embedded system for this, right?
Peter
OSR
–
//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________
Ah. So, the problem is… The SMBUS host controller is usually loaded with NODRV associated with it. Nothing really prevents you from writing a proper driver for it, but obviously the upper edge of that driver will be entirely defined by you. And, of course, nothing prevents some OTHER dude with a similar idea who wants to support an SMBUS device on the same system from trying to write HIS own driver for the SMBUS host controller. And, obviously, only one of you can have your driver installed at a time.
ANYhow… You see the issue.
The BIOS methods are a tad annoying, but once you’ve written a couple and gotten them to work, it’s a pretty reasonable approach… It *is* kinda high overhead. So, it’d be cool assuming you don’t want anything remotely resembling high throughput (relative to SMBUS speed).
Peter
OSR
Hi,
I am new to this field… This is what i got it from my guide… i need to look into these 3 things
- SmartBus interface on standard Laptop computers / or COM Express Modules.
- SMBus protocols ? complete list of queries available.
- SMBus protocols ? list of queries supported by Windows ( XP and Win 7)
Currently we have two types of interfaces in our systems ? (1) Standard PC SMBus interface and (2) A proprietary I2C interface through a dedicated FPGA.
The first option is cost effective and simple, however there may be limitations posed by Windows in the extent of information query.
The second option allows the ultrasound application to bypass Window and access the SMBus directly, providing complete control. However it has added cost and complexity.
For our Value product, we are proposing option 1, but need to understand if the limitations posed by Windows are acceptable.
For this, we could try to find more details on the SMBus protocol support by Windows and compare it with the full set of the SMBus protocol.
This will be extremely useful information to decide on Option1 or 2.
i have no idea regarding this,so please help me to get these information.
Thank you all.
> For this, we could try to find more details on the SMBus protocol support by Windows
Windows does not support SMBus. Period.
MS’s people here on this forum told us several times that Windows design decision is that SMBus should be ruled by the BIOS and not by the OS.
SMBus devices are soldered to the motherboard, and are the essential part of it. So, only the MB/laptop vendor can introduce them. This vendor also has the power over BIOS and its ACPI table, and is free to expose the SMBus devices this way.
I’ve never heard about “SmartBus on laptops”, and the Google search for “SmartBus” provides with the residential automation systems and not PC ecosystem stuff. Probably there is no such thing as “SmartBus on laptops”.
Once again: the Windows-provided way is to describe all SMBus devices in the BIOS’s ACPI table. Then you can either a) expose it as a custom ACPI devnode like Asus does for ATK0110 and write your own ACPI-based driver for it like AsAcpi.sys with user apps talking to it via IOCTLs or b) write the ACPI table chapters on your device in WMI-compatible way, this will get rid of the custom driver and allow to access these devices trivially from .NET or even VBScript in user mode.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com