K8055 USB command set?


I have the K8055 I/O board (verified functional on Windows) and am very happy with it.

Since my main computers are Mac OS X, I’m attempting to write a USB driver for the board for OS X.

I knokw I could take the route of disassembling the library file, but that’s a bit dirty, and probably not according to the license agreement.

The Linux software available gives a few hints, but it’s terribly generic (read all, write all), while I wish to build a driver that offers at least the same functionality as the Windows library offers.

So, my question to you is: Is there anywhere I can get a list of the known commands of the PIC, and the parameters (number of and meaning) for each command ?

Kind regards,

Ok, I’ll talk to myself a bit then :slight_smile:

I found another post where Velleman support points to the source of the DLL (a Pascal file - K8055DM.pas). What I see in there is what appears to be that there are only two functions implemented by the PIC - “read everything” and “write everything”.

It would be nice (and definitely not a waste of my time :wink:) if Velleman support could verify that this is in fact how it is.

buf_tx = { 1, ?, ?, ?, ?, ?, value, … } -> Debounce time 1
buf_tx = { 2, ?, ?, ?, ?, ?, ?, value, … } -> Debounce time 2
buf_tx = { 3, … } -> reset counter 1
buf_tx = { 4, … } -> reset counter 2
buf_tx = { 5, value_of_digital_out, value_of_analogue_out_1, value_of_analogue_out_2, … } -> Set all outputs
buf_rx = { value_of_digital_inputs , board_id ? , value_of_analogue_ch_1, value_of_analogue_ch_2 ,counter_1_lsb, counter_1_msb, counter_2_lsb, counter_2_msb, … } <- read from inputs in one sweep

These are my findings, are they correct ?


It seems that you have correctly interpreted the DLL source code.
You are right, the second byte in the buf_rx is the board ID (value 1 to 4).

Thank you :slight_smile:

One more thing - when input data on the K8055 changes (analogue or digital), does it create an interrupt, or do I have to keep a timed thread reading the board every 10ms ? (If it creates an interrupt, kernel time won’t be wasted reading the same stuff over and over :slight_smile: )

Thanks again.

Sorry, no interrupt generated.
So - the timer is the only solution for the moment…