First version for Linux and Mac OS

[stevenm]

Hello.

Over the past few days I've been reverse-engineering the P2140's USB protocol. I threw together the following simple program for talking to the supply. It should work on Linux and Mac OS X using libusb (http://libusb.sourceforge.net).

Please be advised that this is not the official Carnetix software and that it can contain all sorts of bugs/problems/etc. I've tried my best, but if the program destroys your power supply, computer, car, house, etc, I am not responsible for it. That said, I *think* it is correct, and any feedback you may have is appreciated. The program is released under the BSD license.

Enjoy, and good luck!

Here is the link:
http://wam.umd.edu/~stevenm/carnetix.html

EDIT: You will also probably want to upgrade your supply to firmware 1.8 or above (I'm using 1.8.3) for everything to work properly. Polling the basic readings may work with old firmware, but you likely need FW 1.8 for reading/writing the parameters and turning the individual outputs on and off. I couldn't find the link to this firmware on the Carnetix web site (I also didn't look too hard ), but there appears to be a zip file in here:
http://carnetix.com/firmware/

I think it's called P2140V1.8.3.zip and there's a PDF on how to upgrade the firmware. I believe you need to set a jumper before PSUmoni will let you update it.

Steve

[OCS]

Great, thanks!

May I ask which Mac you have tested it with? I am somewhat concerned that there seemed to be some problems with libusb/Intel yesteryear

http://lists.apple.com/archives/darw.../msg00013.html

and since the darwin.c in libusb seems to be last updated 4/17/05, they perhaps may persist...

[stevenm]

I've noticed a problem on some installations with the USB code. For some reason, some machines can read the values fine, while the USB code won't work on others.

I've traced the problem to the transfer type. I've been using USB bulk transfer, but on two of my systems, it only works when I use interrupt transfer instead. Ah well... strange. I have put version 0.2 on the site, in case someone has run into this issue. It is probably a problem only on some kernels or USB controllers.. if anyone is experiencing this issue, I suggest using ver 0.2.

Steve

[stevenm]

Originally Posted by OCS

Great, thanks!

May I ask which Mac you have tested it with? I am somewhat concerned that there seemed to be some problems with libusb/Intel yesteryear

http://lists.apple.com/archives/darw.../msg00013.html

and since the darwin.c in libusb seems to be last updated 4/17/05, they perhaps may persist...

I believe it was an Intel MacBook. I can check with my friend later to see exactly what it was. I can also try to test it on an Intel Mac Mini. I just tried it on an intel mac mini on linux, and discovered that bulk transfers didn't work.. hence the switch to interrupt transfers. I can try it from Mac OS as well, if it has the C compiler installed.

[stevenm]

We just tested on intel mac mini (OS X) using libusb from darwin ports and it worked. We used ctxapi-0.2 and libusb 0.12 I think.

[OCS]

OK, thanks a big lot!

I've tried to rewrite the entrails into IOKit anyway, would be much cleaner, and took just about two hours... I'm waiting for test results (myself I've got just a P1900, so joesan has to test for me ), we'll see...

(Well if any other body wants to test on his Mac meantime, the Terminal-based test tool is here -- it's kind of the same as the consolemon example, just Mac-native... and at the moment I have no idea at all whether it works or not It should run as-is both on Intel and PPC, no compiling or installing anything needed. Should connect to the device, and understand commands "version", "values", and "config" (and "quit"), that's all for the moment. If anybody tries, do please send me a copy of the result to ocs@ocs.cz. I'll prepare the GUI when I know this does work all right.)

[OCS]

(Writing the previous message, I've got an idea... if you happen to test the 2140test and it does not write out anything, try please 2140test-1.zip -- it is a bit more aggresive with its outputs )

[Game_Ender]

No offense but why did you a rewrite? It might be "cleaner" from a purest prespective but its not from a software engineering one. I am very interested to know why mainting a seperate backend for Mac is better? libusb is very small dependency and it allows all three platforms (or 2 in this case) to share the same code base and bug hunting efforts. By essentially duplicating Steve's work you will introduce new bugs and lessen the number of people who could find them for you. Of course with just libusb we might get Mac specific bugs as well, its just less than if there was a whole seperate Mac version. It not the end of the world for a project such as this, but I still find all such forks odd.

If by chance you like C++ better, I perfer it as well but in the case the API is so simple stickting to something like C allows easy use from many other programing languages like D, Java, Python, OjbectiveC/C++ or Ruby. C++ is unfortunaetly harder to wrap in that respect.

Despite all that "why did you throw away our code" talk up there I am curious to see the source of your implementation.

[OCS]

Originally Posted by Game_Ender

No offense but why did you a rewrite? It might be "cleaner" from a purest prespective but its not from a software engineering one. I am very interested to know why mainting a seperate backend for Mac is better?

Number of reasons, actually.

First, it's just not done on Mac to force the user to have to install this or that before he can run an app -- in this case, libusb. Any app should be completely self-contained if possible.

Sure, one can embed libusb into the app etc., but if all this is summed up, the effort would be on par with writing new, clean, native back-end. Have you checked the sources? They are pretty simple; the great Steve's work actually was not to write them -- anybody could repeat that in no time flat -- but to find the protocol and concrete values needed. Once this is known, the rest is very easy (but to find out the protocol without proper docs must have been a drudgery I did not want to undertake -- been there, done that, fed up pretty much --, and I am extremely grateful to Steve he did. Also I cannot refrain from sadly pointing out I've asked Mike for this kind of documentation some time ago, but in vain).

The final straw was the pattern Steve decided to use. Of course it's in the eye of the beholder etc., but myself, I fear I very much dislike the write-something-and-then-wait-for-answer approach. With it, you either have to set up a really very short timeout, which may cause problems when the device for any sweet reason is somewhat lazy answering, or you get your main thread event loop clogged, or most probably both. Or you have to go multithreading with all the ugly consequences. Myself, I very much favour the event loop approach, when you just add an appropriate event source to the loop so that it waits on a semaphore to report whenever any input comes, and write out commands without waiting for anything.... Agreed, it's kind of difficult with libusb; child's play though with IOKit.

Anyroad, although it's for Mike to decide, I kind of feel this is getting a bit too technical and off-topic for this forum? If you have any suggestions, perhaps you might rather want to e-mail me (ocs@ocs.cz)?

[stevenm]

Tried the mac programs on mac os, got the following output:
Last login: Fri May 18 12:49:36 on ttyp2
/Users/steve/Desktop/2140test; exit
Welcome to Darwin!
wombat:~ steve$ /Users/steve/Desktop/2140test; exit
found a Carnetix device vendor id=1240 (0x4d8), device id=11 (0xb), release #0, 1 configs
opened successfully
set configuration 1 successfully
! ERROR -536870206 (e00002c2) "invalid argument" at /Users/ocs/Temporary/2140.test/2140test.m:191
logout
[Process completed]


Last login: Fri May 18 12:49:58 on ttyp1
Welcome to Darwin!
wombat:~ steve$ /Users/steve/Desktop/2140test-1; exit
found a Carnetix device vendor id=1240 (0x4d8), device id=11 (0xb), release #0, 1 configs
opened successfully
set configuration 1 successfully
! ERROR -536870206 (e00002c2) "invalid argument" at /Users/ocs/Temporary/2140.test/2140test.m:221
logout
[Process completed]


I don't know why, but that happens... the libusb version still works I think, so the supply is alive.. I will be going home for the weekend and the supply (and the mac) is staying at the lab, so I cannot do any more testing until next week. Anyways, hope you get your hands on a unit of your own soon.

Good luck
Steve