First version for Linux and Mac OS

[OCS]

Originally Posted by stevenm

... 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.

Well, thanks to Joe I've just shortly ago got to my third test run with the improved tool which reads the device attributes, and I think I can explain the mystery in the simplest way possible: IOKit says both pipes are type #3, which is, surprise, an interrupt pipe (bulk would be #2). Actually I don't know whether there is access in libusb to these attributes at all?

Anyroad, if something is strange, it's that bulk does work somewhere (perhaps some concrete releases of libusb/underlying drivers are smart enough to silently change the access type if they find it does not match the pipe kind? Dunno.)

By the way, I'm glad to be able to say that my backend problems indeed were only in not knowing details of the device: far as one quick try could say, my backend seems to read the device all right now. So -- depending on how quickly will Joe be able to test -- the application should be out very soon. Actually, anyone daring enough to try can download it and play. If anyone does and it doesn't work -- which is well possible, without testing a small typo could cause that easily -- do please send me the application log (from Console, or you can run it from a Terminal window, if you prefer, in which case the log would stay there).

May I ask a few questions... well, to Steve or Mike or whomever who understands the device protocol:

First, I've got a configuration block of 15 bytes only... not sure whether it might be some artifact, or whether it can occur sometimes? The block looked like this:

44 15 58 02 F4 01 00 00 1E 00 28 00 5F 01 00

Further, there seems to be a strange inconsistence in that I can switch on/off primary, secondary, and P5V separately, but there seems not to be any way to enquire the current state? Even though the primary and secondary state could be probably determined indirectly from the voltage and current and perhaps also from the soft-LEDs 0x0200 and 0x0400, I see no way at all to enquire for the P5V state?

Also, perhaps I've just missed some important part of documentation, but I am not quite sure of the proper interpretation of

- LED_PS_ON / 0x0040
- ctxParams.lowTemp

Finally -- this is very definitely a question for Mike -- in the long run, I would very much like to allow firmware upload, too. Can you perhaps point me to some documentation where I would find the protocol, or would I ask too much?

(Oh, speaking of asking too much reminds me... please, Mike, could you publish the memory locations for P1900 2.8? Or are you perhaps just letting me know this gentle way I should buy me a 2140 instead asap? )

Thanks a lot,
OC

[stevenm]

Originally Posted by OCS

Well, thanks to Joe I've just shortly ago got to my third test run with the improved tool which reads the device attributes, and I think I can explain the mystery in the simplest way possible: IOKit says both pipes are type #3, which is, surprise, an interrupt pipe (bulk would be #2). Actually I don't know whether there is access in libusb to these attributes at all?

I believe libusb does provide these attributes, but I haven't really bothered checking. My sniffer said 'bulk or iso transfer' so I went with bulk. This is only my second libusb program, and I figured only having the transfer type wrong isn't so bad... I believe bulk mode works on some usb driver implementations. We've tried using two different kernels (but identical hardware) and I think the same versions of libusb.. one worked and one didn't. Good to know that switching to interrupt transfer is the right thing.

Originally Posted by OCS

May I ask a few questions... well, to Steve or Mike or whomever who understands the device protocol:

First, I've got a configuration block of 15 bytes only... not sure whether it might be some artifact, or whether it can occur sometimes? The block looked like this:

44 15 58 02 F4 01 00 00 1E 00 28 00 5F 01 00

I bet you are using old firmware. A good 44 15 reply should really be 21 bytes long. When I had older firmware (1.3? 1.4?) I sniffed out psumoni's 44 13 reply, which was 15 bytes in size, and seems to be an older version of 44 15. The extra 6 bytes specify ACPI delay, ACPI duration, and lowTemp. These didn't show up until 1.8 I think.. Update your firmware to 1.8.3 and the 44 15 reply should expand to 21 bytes.

Originally Posted by OCS

Further, there seems to be a strange inconsistence in that I can switch on/off primary, secondary, and P5V separately, but there seems not to be any way to enquire the current state? Even though the primary and secondary state could be probably determined indirectly from the voltage and current and perhaps also from the soft-LEDs 0x0200 and 0x0400, I see no way at all to enquire for the P5V state?

I haven't seen any way to get their state. I asked Mike about more commands and he directed me to the API, where I didn't see anything for this either.

Originally Posted by OCS

Also, perhaps I've just missed some important part of documentation, but I am not quite sure of the proper interpretation of
- LED_PS_ON / 0x0040
- ctxParams.lowTemp

LED_PS_ON is the same as the PS_ON light on PSUmoni. I can only assume it means the converter is running. lowTemp is the lower temperature limit below which the supply will not turn on. Components tend to have both a high and a low temperature extreme.

Originally Posted by OCS

Finally -- this is very definitely a question for Mike -- in the long run, I would very much like to allow firmware upload, too. Can you perhaps point me to some documentation where I would find the protocol, or would I ask too much?

Oh boy. You would need at least a bug-free Hexfile reader for that, and a knowledge of PICs. I don't know what kind of bootloader is used- did Mike use something standard (ingenia maybe?) or is this a custom bootloader? There aren't that many USB bootloaders so maybe you can try to dig through the internet and see which protocol matches what is sent. I am not messing with any flashing commands until I get a hexfile of the bootloader and find an ICSP connector on the board to resurrect the supply with an ICD2 when I brick it.

[OCS]

Originally Posted by stevenm

... My sniffer said 'bulk or iso transfer'

Hmmm, sounds suspicious... are you reasonably sure the sniffer's bug free?

This sounds like "bulk or isochronous" (in IOKit the latter'd be #1), and that just does not sound right. Not speaking of the fact they are interrupt -- it's proven by the fact your backend runs with interrupt all right (not speaking of mine, but I don't set up the transfer type, IOkit just uses whatever the pipe does support automatically).

I bet you are using old firmware

Could be; alas, Joe haven't run the "version" command which would -- hopefully -- return the release number

...The extra 6 bytes specify ACPI delay, ACPI duration, and lowTemp

Well I wonder. The packet was 44 15 58 02 F4 01 00 00 1E 00 28 00 5F 01 00, which looks like

- 10 minutes of shutdown delay (why not)
- 50 hours DMT (sounds reasonable)
- zero DLYON? Hmmm....
- just three seconds boot lockout? Suspicious! (Or did it perhaps not be in tenths of second previously? Who knows...)
- four seconds of shutdown lockout? Same as above...
- 11.27 low battery threshold sounds reasonable.

Update your firmware to 1.8.3

Joe, do you read?

I haven't seen any way to get their state. I asked Mike about more commands and he directed me to the API, where I didn't see anything for this either.

Sigh. Well guess I'll have to set up some GUI with three state buttons which includes not-known... I do hate such things, but seems it can't be dodged.

lowTemp is the lower temperature limit below which the supply will not turn on. Components tend to have both a high and a low temperature extreme.

Aha... pretty strange it's user-settable in this case :-O I've thought it would be something like the temperature threshold to run the fan, or something like that... Anyway, thanks a lot!

Oh boy. ... I am not messing with any flashing commands until I get a hexfile of the bootloader and find an ICSP connector on the board to resurrect the supply with an ICD2 when I brick it.

Quite; that's why I've asked Mike for help: I'm not too eager to play with that without at the very least proper docs either. On the other hand, I'd like our customers with Macs could upgrade the firmware without being forced to find a wintel

Thanks again and best,
OC

[OCS]

Oh, and one more question for Mike (or Steve, if you happen to know, of course): I am terribly sorry if this is documented somewhere (must have missed that), but what exactly is the "USB shutdown control" does, if I set the appropriate soft-jumper?

Supposing it sends some concrete code (to be catched by PSUmoni which then would go sleep)? Which code it is? Or is it implemented in a different way?

Thanks!

[OCS]

Oh, just in case someone interested before Joe's allowed to test

Hopefully the last alpha -- if it works well, the next release would be a complete beta, including a version check, help, and such amenities, published along with the sources -- can be downloaded from my site.

It should more or less fully support P2140 (with "new enough" firmware, alas it is, far as I know, nowhere documented which "new enough" means, but 1.8.3 should be definitely all right) -- including configuration settings, soft jumpers, etc.; it is not tested at all though. If there is a special USB command which should trigger sleep, it is not supported, for the reason it is not documented (or perhaps I've missed the documentation, see my previous question).

It does not support firmware upload either for obvious reasons (see the discussion above for details).

[Game_Ender]

Very cool OCS I will check this out when I get the chance.

[OCS]

The newest release, 1.3 beta, is available along with the sources.

Compared with the previous version, there are only slight improvements like something remotely similar to a help, verbose logs by default switched off, etc.

Unless someone finds a bug there (or unless some documentation occurs which would allow me e.g., to implement the USB shutdown -- see 05-22-2007 02:12 AM) I guess it would also be the final release for some time

[OCS]

Originally Posted by OCS

... Unless someone finds a bug there

Found one myself, completely harmless at the moment, but could raise its ugly head if the device ever sent more than 23 bytes (forgot to alloc a bigger buffer).

1.4 beta is fixed along with the sources

[Game_Ender]

OCS do you think it would be possible to give Steve a mention for reverse engineering the P2140 protcol and providing a reference implementation for OS X and Linux? I know you put a lot of work into making the Objective-C event loop compatible/IOKit api, but this would of never got off the ground without all of his hard work.

(Steve is to modest to ask for any himself, so I am going ahead ). Maybe he will even post his full name for yah.

(Sorry if I missed this in the source or the App, I am not on a OS X machine right now)

[OCS]

Originally Posted by Game_Ender

OCS do you think it would be possible to give Steve a mention... Sorry if I missed this in the source or the App

Seems so indeed?!?

"About PSUmoni" says, in my personal opinion, very explicitly:

USB P2140 Connector:
All the hard work by Steve, we just turned it to IOKit, bringing new bugs and problems

and have done that from the very first alpha. Also, there's another short one in "PSUmoni Help" (in beta releases):

... the information available were determined using reverse engineering by Steve ...

Not enough?

Of course, Steve, if you want me to change the mentions, replace "Steve" by any other name, use a different URL, add another one somewhere, or perhaps add e-mail or whatever, just let me know: there's no problem in that at all.

Originally Posted by Game_Ender

I know you put a lot of work into making the Objective-C event loop compatible/IOKit api

Not really, all summed up, just a few hours -- since, thanks to Steve, I more or less knew the protocol (and also thanks to the power of the Cocoa SDK), it has been very easy; almost all the time I just waited to get some test results (to be frank, I've been somewhat surprised that but for Joe alone, no Mac/P2140 user bothered to test even once; it's a nice contrast Steve, who though, as I understand, primarily uses Linux, did test for me: seems I almost could not have bothered for the P2140/Mac users ain't that interested in fact).

Originally Posted by Game_Ender

...but this would of never got off the ground without all of his hard work

Is there any reason to think that's a news for me? You have read e.g., my post of 05-18-2007 06:48 AM:

Originally Posted by OCS

... the great Steve's work actually was ... 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 ..., and I am extremely grateful to Steve he did ...

haven't you?

Well guess I'm just a bit continental this morning feeling touchy, terribly sorry for that... guess it'll be better when I get a shower and some breakfast