I2C on ITX

M

Michael Culley

Guest
I have a VIA EPIA M board which has an I2C port on it. I sent an email to
via asking for developer info for this port. They sent me an exe that is
meant to work with it but it is just a command line tool. I sent an email
asking for info and they said that there was no info available. Anyone have
an ideas, can I trap the calls of the exe to see what port it calls?

Thanks,
Michael Culley

--
Michael Culley
 
"Michael Culley" <mculleyNOSPAM@optushome.com.au> wrote in message
news:belf3q$6kvrm$1@ID-180780.news.uni-berlin.de...
I have a VIA EPIA M board which has an I2C port on it. I sent an email to
via asking for developer info for this port. They sent me an exe that is
meant to work with it but it is just a command line tool. I sent an email
asking for info and they said that there was no info available. Anyone
have
an ideas, can I trap the calls of the exe to see what port it calls?
You will probably have to find out what chipset the motherboard uses and
then track down the data sheet. Once you have succeeded in doing that, you
might be lucky and find a windows API that will handle the dirty stuff for
you. If no API exists, its off to kernal land to write a driver, which I
believe is quite easy these days if you have the right tools. It might pay
to see what .NET has to offer too, I;m not quite sure how this framework
works yet but currently learning. Looks like it has potential.
 
On Fri, 11 Jul 2003 14:41:20 +1000, "Michael Culley"
<mculleyNOSPAM@optushome.com.au> wrote:

I have a VIA EPIA M board which has an I2C port on it. I sent an email to
via asking for developer info for this port. They sent me an exe that is
meant to work with it but it is just a command line tool. I sent an email
asking for info and they said that there was no info available. Anyone have
an ideas, can I trap the calls of the exe to see what port it calls?
that port is another name for SMbus used for Bios comunication between
some hardware like monitoring chip for temps, voltages & Rpm of fans.
it is 2-way serial 8bit bus; for example Bios tells thru it to Clock
generator about CPU frequency, Vcore adjustments & so on...
Can be also used with propper program & external microcontroller to
change or reprogram certain functions of some hardware on the MoBo or
read some data (like temps) from external LCD microcontrolled gadget
or so...

-- Regards, SPAJKY
- http://freeweb.siol.net/jerman55/HP/Spajky.htm
Celly-III OC-ed "Tualatin on BX-Slot1-MoBo!"
E-mail AntiSpam: remove ##
 
that port is another name for SMbus used for Bios comunication between
some hardware like monitoring chip for temps, voltages & Rpm of fans.
it is 2-way serial 8bit bus; for example Bios tells thru it to Clock
generator about CPU frequency, Vcore adjustments & so on...
Can be also used with propper program & external microcontroller to
change or reprogram certain functions of some hardware on the MoBo or
read some data (like temps) from external LCD microcontrolled gadget
or so...

It looks like the chip is a VT1211. I couldn't find a datasheet on the
internet but I've sent via an email requesting the sheet. They have been
pretty good with responses before.
 
"Michael Culley" <mculleyNOSPAM@optushome.com.au> wrote in message
news:3f0e7b6e$0$31278$afc38c87@news.optusnet.com.au...
Andy,

Thanks, excellent idea that I should have thought of :)

It might pay
to see what .NET has to offer too, I;m not quite sure how this framework
works yet but currently learning. Looks like it has potential.

That just happens to be what I am using, however I doubt there would be
something that lo-level in dotnet. Me thinks C will be needed.
I think you can still do low level stuff in C++ in .NET, it is unmanaged
thought. I assume it will run as native code rather than the .NET
intermediate language. I may have to look into how they do driver (kernal
level) development in .NET!
 
I think you can still do low level stuff in C++ in .NET, it is unmanaged
thought. I assume it will run as native code rather than the .NET
intermediate language. I may have to look into how they do driver (kernal
level) development in .NET!
From what I can tell C++ is basically the same in .net. The big difference
is that you have the option of using the framework.

--
Michael Culley
 
"Michael Culley" <mculleyNOSPAM@optushome.com.au> wrote in message
news:bev5si$9bd0q$1@ID-180780.news.uni-berlin.de...
I think you can still do low level stuff in C++ in .NET, it is unmanaged
thought. I assume it will run as native code rather than the .NET
intermediate language. I may have to look into how they do driver
(kernal
level) development in .NET!

From what I can tell C++ is basically the same in .net. The big difference
is that you have the option of using the framework.
The difference is whether the compiler produces Intermediate Language (.NET
framework) or native code. If using the former, i think you will be strictly
limited in the datatypes you can use. I assume that the way to create
drivers is to bypass the .NET framework, but i am only guessing here. DDK in
the MSDN will answer all questions!! ;-)
 

Welcome to EDABoard.com

Sponsor

Back
Top