problem adding custom programmer definition

[ashwinm]

Hi there,
first of all thanks for this program, especially for making it open-source friendly.

I tried using it with a custom parallel-port programmer that I built myself, and was wondering how to set the custom programmer parameters. Here's what I did:

1. I created an ".ini" file with the same syntax as I would for WinPIC
2. In the "interface" tab of WxPIC, I specified a custom LPT programmer in the "Interface Type" drop down list, and navigated to my custom interface file below it.
3. Now when I start WxPIC, I get an error message with the following error: "XML parsing error: 'syntax error' at line 1".
4. In the "Messages" tab, I see the following line: "Error in PIC_HW_Init: Cannot read definition file "C:\Program Files\WxPic\interfaces\myprog.ini"." (myprog.ini being my custom file)

My OS is Windows Vista Home Basic. I have tested my ini file with WinPIC and found it to work on a 16F84 board that I have.

Is this error because you've shifted to an xml format for custom programmers, from the ini format of WinPIC? If so, where could I get some info on the format of this xml file? Or is there some other issue?

If it helps, these are the contents of my ini file:
-----------------------------------------------------
[Info]
Purpose=MyProg

[ProgrammerControlLines]
DataIn=bsy
OkButton=nc
VppOnOff=D1
VddOnOff=nc
Connect=nc
ClockOut=D2
DataOut=D3
DataOutWhileReading=1
PullMclrDown=nc
ClkEnable=nc
OutEnable=nc
RedLed=nc
GreenLed=nc
----------------------------------------

Thanks
- Ashwin

[admin]

:oops: :oops: :oops: You are right. I found that using a ini file through the Window library was not portable. And I don't like to write non-portable code without strong justification. I did not either want to develop a specific code to read an ini file. So I choose to transform the ini file in an xml file. But I forgot to update the help. To be honest I had completly forgot that change!

Try the following file this should be better :?

Code: Select all

<programmer-control-lines
DataIn="bsy"
OkButton="nc"
VppOnOff="D1"
VddOnOff="nc"
Connect="nc"
ClockOut="D2"
DataOut="D3"
DataOutWhileReading="1"
PullMclrDown="nc"
ClkEnable="nc"
OutEnable="nc"
RedLed="nc"
GreenLed="nc"
/>

Though I didn't try the parallel interface (I haven't one). Tell me if you have any other issue...

P.S.: The corresponding problem report is #0000013

[ashwinm]

Hi,
thanks for the reply. Doing as you suggested removed the error message, however the port appears to not work. These are the steps I followed:

1. In the Options tab, I set "Port access already granted before start"
2. In an Administrator command prompt, I gave this command: AllowIo.exe /a "c:\Program Files\WxPic\WxPic.exe"
3. WxPic now opens without the xml error; however, it is unable to initialize the interface. When I try manually toggling the interface lines and probing the signal, I see no result. Also, I get the "Windows fooled around with the LPT port bits" error message in the Messages tab.

I followed the above steps because these are what worked with WinPIC. Do you suggest a different method to allow WxPIC to access the port? Or perhaps there're more issues with the xml file..

I would like to help debug this and make it work, so do let me know if you need me to do any tests on this (perhaps there is a debug flag/switch to wxpic?) I'm not averse to looking into the source either :-)

I noted the following points as well, perhaps you're already aware of these:
1. In selecting the ini interface file, the file filter in the file selection dialog is fixed at "*.ini" instead of "*.xml", and there is no option for "all files" either.
2. Even if I browse to some directory for the ini file, WxPic still tries to pick up the file from c:\program files\wxpic\interfaces.

Thanks
- Ashwin

[admin]

1. In the Options tab, I set "Port access already granted before start"
2. In an Administrator command prompt, I gave this command: AllowIo.exe /a "c:\Program Files\WxPic\WxPic.exe"
3. WxPic now opens without the xml error; however, it is unable to initialize the interface. When I try manually toggling the interface lines and probing the signal, I see no result. Also, I get the "Windows fooled around with the LPT port bits" error message in the Messages tab.

I followed the above steps because these are what worked with WinPIC. Do you suggest a different method to allow WxPIC to access the port? Or perhaps there're more issues with the xml file..

I have never tried this method.
The only configuration I tried with parallel port is to choose the "Use SMPORT" as driver selection. To work without an installation of the driver this requires to run WinPic in an administrator account.
Though it seems your method gives the same result as mine: "Windows fooled around with the LPT port bits" :lol:
So it seems that's rather a good thing. You got access to the port :!:

I think to remember I succeeded to get rid of this error by setting the following parameter in the registry: ;)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parport\Parameters] "DisableWarmPoll"=dword:00000000

I suppose you know that you must be careful when modifying the registry...
This change will disable the periodic polling of the port by Windows. This means that if you don't set it back to 1 and plug on the LPT port a plug and play printer it won't be recognized. This may not be critical especially if you have a USB printer...

I would like to help debug this and make it work, so do let me know if you need me to do any tests on this (perhaps there is a debug flag/switch to wxpic?) I'm not averse to looking into the source either :-)

Thanks. But if you don't succeed with that tip, I will try myself to setup my LPT port (I have not enough time to do it this evening)

I noted the following points as well, perhaps you're already aware of these:
1. In selecting the ini interface file, the file filter in the file selection dialog is fixed at "*.ini" instead of "*.xml", and there is no option for "all files" either.
2. Even if I browse to some directory for the ini file, WxPic still tries to pick up the file from c:\program files\wxpic\interfaces.

I found those 2 points painful when I tested your file yesterday and I already have listed those 2 issues in the bug report #000013 I wrote yesterday.
The first one is due to the change of file type that I did incompletly.
The second one is inherited from WinPic (I think the contrainst is indicated somewhere in the help and also in the dialog title)

Philippe

[ashwinm]

Hi Philippe,
I guess you meant to set DisableWarmPoll to "1", not "0" ;-)

Anyway, I've tried that too, and it didnt work :-(

In WinPic, the smport and porttalk options never worked for me, even running as admin. The only thing that worked was to set "port access already granted" and to use allowio (as I described earlier).

In WxPic too, the smport and porttalk options dont work (admin and non-admin mode); unfortunately allowio does not work either :-(

- Ashwin

[admin]

Yes
You are right it's 1 to disable.

Did you try to reboot the PC? I am not sure this is taken into account immediately.
Normally when WxPic detects that Windows modifies the port this should mean that the access to the port is successful. So I am not sure the problem is on WxPic side.
The failure to use the drivers is strange too.

Though WxPic may have some problems too. On my PC no error is reported (except that I have no programmer). So I have tried to change the data out pin with your parameter file and I saw no change of the D3 pin of my LPT port. I will investigate this issue in case it could be linked to your problem. I'll tell you the result of my investigations...

[ashwinm]

Hi,
yes, I did reboot after the registry change, but no effect.

- Ashwin

[admin]

After checking step by step the call to SMPORT without finding any error I realized that I had counted the pins from the wrong side. In fact it works correctly: I can modify D3 with the data, D2 with the clock and D1 with VPP. If I shortcut Busy to D3, WxPic tells me that the interface is initialized (see picture below)

Another verification I made: I set DisableWarmPoll to 0 and I got back (but not immediately) the error "Window fooled around...". Nevertheless, I can work some time without the error (the polling does not seem too frequent)

When you say that SMPort does not work for you what do you mean exactly? What is the error message, if any?

When checking the code step by step I saw that the PortTalk selection is not effective. It does exactly the same as SMPORT.

Now I'll try the mode you are using to see if it works on my PC.

To be continued...

[admin]

AllowIO works too. WxPic succeeds to command and poll the port in the "Port access already granted before start". BUT I check step by step what WxPic does and I saw that it is still using SmPort in that case :!:
And at this time I don't how my porting can be the cause of that. In fact the code is:

Code: Select all

bool PicHw_UpdateLptCtrlBits(void)
{
if( PicHw_fUseSmallPort && (LPT_io_address>0) )
  { SmallPort.WriteByte(LPT_io_address+2, PicHw_wLptCtrlBits & 0x0F);
    // Don't set bit 4 in this register, its the "centronics interrupt enable bit"
    return true;
  }
else
  { _tcscpy(PicHw_sz255LastError, _("Illegal LPT port address"));
    return false;
  }
}


And I verified with SVN by comparing the current file version and the very first version that was imported from WinPic sources, that not a single character has been changed in this area.
It seems that your only choice is to use SmPort when you access a parallel port :(
I will go deeper in the source code to understand better how that works and if the error is somewhere else.

[admin]

I understand better what happens. The use of PortTalk or AllowIo is dependant of the definition of the symbol USE_PORTTALK. But when it is defined, the code refers to code that is not present in the WinPic code package. Searching the net for the missing code I found that the problem was known

// ! Due to copyright issues with PortTalk/AllowIO, !
// ! the new functions are located in a separate module !
// ! called AllowIoWrapper.cpp, which can NOT be distributed !
// ! without Craig Peacock's permission ! Search the net for !
// ! the "allowio.c" soucecode if you feel the need to know !
// ! what all this is about ;-) !

I will try to understand how PortTalk works to replace the missing code. But it may take some time...