Python support?

[serg]

Hi siguy,

According to the source code this error is returned in three cases(assuming you don't use the w2k SUB-20 package
):
- Bad device handle passed to the function
- Memory allocation of ~20 bytes failed
- Win32 event creation failed

Does the subtool shows the same error, i.e SE_SETA (5)? If not, most likely you have the first case from the list above, check that the SUB-20 handle that you pass to the function is valid. What SUB-20 software package version do you use? What version of the target OS, 32/64 bit?

Let me know

[xol]

HI,
Let's pass to SUB-20 Tool and SUB-20 disconnected from target and MAX converter.
1. What SUB-20 model do you have?
2. What is the FW and Library version?
3. Where exactly are you looking for MDC and MDIO? Is it on 10pin header or on DB9 connector?
4. What settings do you provide to SUB-20 Tool and what buttons do you press? What happens from the tool side and what do you see on MDIO signals?

[siguy]

Turns out I had a signal integrity issue with flying leads to hookup SUB-20 to target MMD - twisting MDC with GND and MDIO with GND did the trick. Now, SUBTOOL is communicating with the target, so the SUB-20 is working good! Now just to compare my code with SUBTOOL's...

[siguy]

Hi xol and serg,

Thanks for jumping in to help!
1. SUB-20-B
2. FW = 0.3.0, Lib = ?
3. Using the 34pin header for MDIO0 channel, J6 for MDIO11
4. SUBTOOL works - but READs of different addresses need to have an ADDR command before each READ. FDI's USB-MPC did not require an ADDR command preceding... still debugging

OS = win7-64b, Python-32b, sub20.lib used is Win32 version. Latest downloaded SUB-20 software package (as of 5/13/2012)

Now I have both READ and WRITE working correctly through my Python GUI, but I'm seeing very slow performance. Previously, the same MMD target is accessed with the FDI box.
Here's some profiling I did using the timeit() Python function on 100 MDIO read accesses. For this case, I was just reading from a single address, so the SUB-20 is only seeing one READ call instead of a ADDR+READ set (from #4 above)

FDI: 7.51s (winXP-32b VM on Win7-64) - FDI driver is win32 only on XP and earlier
SUB: 32.02s (win7-64 native)

Commenting out the READ call in each case for FDI and SUB-20 shows the rest of the overhead:
SUB: 0.01s
FDI: 0.01s

Each MDIO DLL call takes 0.32s - does this line up with what you see on your end?
This seems very long compared to the FDI box (even though it is running in a slower non-native VM) at 0.0751s - translates to >4x difference!

I'm hoping this execution time is due to some bug in the way I load the DLL or call it in Python... if you have a way to profile SUBTOOL, what numbers do you see?

Thanks,
SIguy

[siguy]

The runtimes above were for 10,000 calls of read, not 100...

[siguy]

The slow runtimes with SUB-20 might be due to slower MDC @ 1.5MHz vs 4MHz with FDI.
Upgraded FW to 0.3.5 to enable CFP MSA mode and it works with SUBTOOL (32bit) @ 4MHz

However, my Python code that worked with FW 0.3.0, is now broken (both sub_mdio_xfer_ex() and sub_mdio45() versions are broken now):
1. sub_open() still returns a handle
2. any opcode returns errno=7 - bulk write failed
3. sub_get_product_id() returns blank string
4. sub_get_serial_number() returns blank string
5. will try sub_get_version() too next

Can I get a copy of the 0.3.0 FW so I can revert and figure out why?

Thanks,
SIguy

[serg]

What about sub-tool, does it work properly, i.e do you see correct serial number ? Can you try MDIO transferes by using Subtool?

[siguy]

Hi serg,

Yes, it works with SUBTOOL. What are the compatible DLL versions with FW 0.3.5? I'm using 32-bit software package and sub20.dll in the system32 folder

Thanks,
Joel

[siguy]

Is sub20.dll ver 1.26.0.0 compatible with FW=0.3.5?
I FLASHed the SUB-20 with C:\Program Files\SUB-20\firmware\SUB-20_0.3.5.inc, over the 0.3.0 it shipped with. Downloaded as SUB-20-120121-x32.exe
Also tried x64 version of the SUB-20 DLL with x64 Python and no difference from x32 behavior.

It appears to work in SUBTOOL, but DLL calls from Python vary:
1. sub_open returns a handle (seems valid)
2. all other sub_get_* calls return zero or empty strings
3. MDIO transfers return errno=7

My Python code (prior to FW 0.3.5 upgrade) worked with FW=0.3.0 and LIB=1.26.0.0 flawlessly, but is seems that DLL calls are not making it to the SUB20 now...

see log below:

mdio_sub_open: OK |errno= c_long(0)
sub20_handle = 94207728

==== XDIMAX.COM SUB-20 MDIO<->USB =====
=-- ID: --- Serial No: --= ...on SUB-20 MDIO ch 0
DLL: 0 . 0 . 0 . 0
DRV: 0 . 0 . 0 . 0
SUB: 0 . 0 . 0 . 0
=======================================
comms_setup: errno= 0
sub20_handle= 94207728
ADDR attempt: P= 1 D= 30 R= 3
mdio_rd: Bulk write failed |errno= 7 Returned: -1
READ attempt: P= 1 D= 30 R= 3
mdio_rd: Bulk write failed |errno= 7 Returned: -1

[serg]

Hi siguy,

The subtool app and your script(Python interpreter) are both using the same sub20.dll, located in the c:\windows\system32 directory unless you have several copies of this dll on your machine, so first, please make sure that there is only one sub20.dll on your system. Assuming you have only one sub20.dll and taking into account that the sub-tool is working properly, the problem is probably related to the Python interpreter or your script. Could you please send me the piece of your script which doesn't work, i.e for example sub_get_serial_number call ? I can verify if it works on one of our test machines.

int sub_get_serial_number( sub_handle hndl, char *buf, int sz)

The sub_get_serial_number function returns a status code. What status code it returns to your script ?

Let me know