I've been dithering with various ways of getting assorted I/O (Firstly A/D readings, but other plans are out there) into my PC and was looking for something I could control from the PC at a comparatively high level (VB calling a DLL not poking bits down a bus). I have a few parts to have a bash at 1-wire, but then saw this: http://www.devasys.com/usbi2cio.htm which was a USB to I2C adaptor (with a few extras), complete with drivers. Would this be a good route to choose, I managed to find a A/D chip with I2C in DILL so at lead I wouldn't have to cope with the hideously small packages for 1-wire chips.
if i were you i would look into the SM bus. its already built into the mobo and you can get chips with 32+ A/D lines built into them. the most common aplication is extra temp sensors. if your mobo doesnt have a SM header, you can tap into it at a bunch of places, like on a ram stick, ect... the site i found went offline but the archive is http://web.archive.org/web/20030204231521/http://www.madhacker.org/mbmsensors.htm maxim's SM ICs: http://www.maxim-ic.com/products/sensors/2_wire.cfm
The I2C and Smbus are roughly the same thingmm, but programming with the mobo's Smbus is a bit hairy afaik. I actually have a SMBUS temp sensor from a MAX1668 courtesy of Starkbuck3733T already, but was looking for a dew other applications.
Risky, its not *that* hairy! nothing like as hairy as finding out whats going on with USB. If you want the benefits of 1wire or I2C, you're going to have to learn how they work, once you know this programming is fairly straight forward (enless your under linux, then its VERY VERY VERY VERY FLAKEY with an eden, which have I2C headers, and you spend 9 + 1/2 hours writing your own kernel modifications because the people who designed linux seamed to forget an inportant part of the evolution of hte computer is that hardware improves. BSD worked first time for me, windows is of course perfect.) With I2C, its fairly straight forward to use, once you've got your head round how the bus works (really simple pillips have some documentation somewere on their site) its just great! I would advise against visual basic, simply because its not designed for this type of thing, and you will make more hassel for yourself if you try to use it! C/C#-unmanaged/C++ much easy to do stuff like this in. If you only want one analouge channel, you can just hook a ADC to the parrallel port. The LPT is soo often overlooked, its great, 8 bi-directional data lines, 4 control (bi) and 5 status (in) lines. Again thou, VB is really the wrong language for stuff like this (its just not what its designed for!
This might be the route in the future and would be a cool approach, but I'm no C* coder, and thus I was keen to buy something where someone else has coded an API for me. Looking at the doc for that kit: http://www.devasys.com/download/UsbI2cIo/API_Users_Guide.pdf you can see I wouldn't had to get involved with USB theory at all, but should be able to play directly with whatever I've got hooked up on I2C. Maybe if I got anywhere with the hardware I could consider coding for the system's own SMBUS but I think that's a bit further down the line.
when you've got a serial bus like USB, talking to another serail bus, I2C, anyone who says you won't have nyquest problems, is what is technically known as a lieing son-of-a-appleenthusiast. The problem comes with how data lines up, and this effects your timing, but there are lots of things USB lets you do to accomodate this (requesting bus time in regular "windows" where the USB is dedicated to your one device (endpoint)) Remeber USB can only talk to one device at once, and theres a lot of "background" chatter. So you should always have a sufficent level of understanding before programming with anything that relies on it. The biggest piss-take in this deptartment are the USB -> RS-232 convertors, this can course you so many sleepless nights of bug fixing, only to find out the convertor been used is fundimentally flawed. What i'm trying to say is you need a basic understanding of all the stuff your using, if you want to be able to know what's causing it to go wrong. for something as simple as I2C, you'd save yourself a lot of money, and get a useful "computer-life-skill" if you learnt C, its REALLY NOT HARD. Thats why everyone uses it! If it was hard and played games with your mind, only strange people lurking in poorly light rooms at the back of computer science departments would use it Once you've got your head round C, theres only 2 important ideas you have to learn about, kernel or User mode and How the SMBus works! (the latter is REALLY simple).
Well if am am learning another language it would have to be C# as that's the flavour of the month in these parts and thus very useful on the CV even if you're not going to need it for the job It does look as if there's going to be a bit of a learning cliff though. For windows there's a lack of resource unless you're willing to pay.
well it depends if you've been doing OO (Object Orientated) programming in VB. its REALLY not hard, you just learn, variables should be typed, objects in .net, { } are a real timesaver = is assign, == is equality, === is identitcally equal to. the ONLY thing i've seen that confuses newbs is == in IF statements, if you did if (foobar=1) { } foobar gets set to 1, so that will always get executed. its a MUCH nicer language, and with c# its a RAD. C is mostly used for device drivers which is a very advanced topic not because of the language, because of the fact if you slip, you bring down the OS, not so much of a problem on NT (plenty of great free tools to help you). But you shouldn't need to fiddle with those for a long time
