gnupic: Thread: Re: [gnupic] [PIC] piklab now supports ICD2 and PICkit 2 programmer under Linux

> Nicolas Hadacek has released piklab 0.4.1.
>
> The website is http://piklab.sourceforge.net/.

Hi Xiaofan,

Thanks for posting this announcement. My ancient PicStart+ finally died
after nearly 10 years of service (RIP), so I upgraded to an ICD2. (I also
bought the dsPICDEM 1.1 eval board!). The bad news is that piklab is a KDE
app and it's a pain in the ass to build KDE apps on Fedora. But I managed
to finally figure it out, so maybe someone else can benefit.

I've recently upgraded from FC3 to FC4, and my system is an Athlon64.

Like with pikdev, when I configure piklab I get this error when I
./configure:

...
checking for KDE... libraries /usr/lib, headers /usr/include/kde
checking if UIC has KDE plugins available... no
configure: error: you need to install kdelibs first.


Now, this is a lie, because kdelibs and kdelibs-devel are both installed.
After searching around on google, I found you can get around this
./configure bug by editing the ./configure script and changing the line

from:

  if test -f actest.cpp && grep klineedit actest.cpp > /dev/null; then

to:

  if test -f actest.cpp && grep KLineEdit actest.cpp > /dev/null; then

This is on line 29856. I found the solution here:
http://www.skepticats.com/linlog/entries/2005/08/14_1024/

This gets me through the configure script. But now, "make" gives this error:

Making all in devices
make[3]: Entering directory `/home/scott/tars/piklab-0.4.1/src/devices'
/bin/sh ../../libtool --silent --mode=link --tag=CXX g++ 
-Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W
-Wpointer-arith -Wwrite-strings -O2 -Wformat-security
-Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common   
-o xml_to_data_device  xml_device_parser.o
../../src/xml_to_data/libxmltodata.la ../../src/devices/libmisc.la
-lkdecore -lusb
g++: /usr/lib/libidn.so: No such file or directory

This isn't a lie, because on 64bit machines this library is located in
/usr/lib64/ ! So reading between the lines and picking up a hint here and
there I deduced you need to actually configure like this:

./configure --enable-libsuffix=64 --with-qt-dir=/usr/lib64/qt-3.3/
--with-qt-libraries=/usr/lib64/qt-3.3/lib/

Success! I can now configure. But compiling is another story. There are
thousands of QT warnings and one piklab error. Line 324 of
DirectPrgConfigWidget.cpp reads:

Direct::ConfigWidget::ConfigWidget(QWidget *parent)
  : ProgConfigWidget(Device::User::DirectProgrammer, parent,
"direct_prog_config_widget")

But should be:

Direct::ConfigWidget::ConfigWidget(QWidget *parent)
  : ProgConfigWidget(Device::User::DirectProgrammer, parent,
"direct_prog_config_widget")

After this fix I *finally* built a KDE app on an Fedora Distribution!
Piklab does indeed run too. However I did have to run as root to allow
connection:

Connecting ICD2 Programmer on USB Port with device 10F200...
  Incorrect firmware loaded.
Could not find firmware file "ICD07??????.hex" in directory ".".

So at this point, I believe that I'm now ready to connect to my
development PCBs and do some real work. Finally!

Scott

> -----Original Message-----
> From: Scott Dattalo ####@####.####
> Sent: Thursday, February 16, 2006 2:34 PM
> To: ####@####.####
>
> ./configure --enable-libsuffix=64 --with-qt-dir=/usr/lib64/qt-3.3/
> --with-qt-libraries=/usr/lib64/qt-3.3/lib/

I think I am doing similar things on FC4 (32bit) and I will post
my build experience under FC4 when I am back home with my Linux
computer. My main test platform is Ubuntu 5.10 (based
on Debian). Last time I tested piklab 0.2 and I have some
problems with FC4 when connecting to ICD2 with USB. Serial
connection was better in FC4.

> After this fix I *finally* built a KDE app on an Fedora Distribution!
> Piklab does indeed run too. However I did have to run as root to allow
> connection:
> 
> Connecting ICD2 Programmer on USB Port with device 10F200...
>   Incorrect firmware loaded.
> Could not find firmware file "ICD07??????.hex" in directory ".".
> 
> So at this point, I believe that I'm now ready to connect to my
> development PCBs and do some real work. Finally!

Nicolas has posted the simple hotplug scripts for ICD2 
(based on Mark Rage's PICkit 1/2 hotplug scripts) in his website.
With that hotplug script, you should be able to run piklab
as normal user. Hopefully your 64-bit FC4 also support
usb hotplug.

As for the firmware, I copy the ICD2 firmware from
MPLAB installation (C:\Program Files\Microchip\MPLAB IDE\ICD2
with MPLAB 7.x) and point piklab to that location.

I've tested piklab-0.4 and 0.4.1 with PICkit 2 and ICD2
(USB connection) using quite some PICs and piklab works quite 
well under Ubuntu 5.10.


Regards,
Xiaofan

On 2/16/06, Scott Dattalo ####@####.#### wrote:
> Thanks for posting this announcement. My ancient PicStart+ finally died
> after nearly 10 years of service (RIP), so I upgraded to an ICD2. (I also
> bought the dsPICDEM 1.1 eval board!). The bad news is that piklab is a KDE
> app and it's a pain in the ass to build KDE apps on Fedora. But I managed
> to finally figure it out, so maybe someone else can benefit.
>
> I've recently upgraded from FC3 to FC4, and my system is an Athlon64.
>
> Like with pikdev, when I configure piklab I get this error when I
> ./configure:
>
> ...
> checking for KDE... libraries /usr/lib, headers /usr/include/kde
> checking if UIC has KDE plugins available... no
> configure: error: you need to install kdelibs first.
>
>
> Now, this is a lie, because kdelibs and kdelibs-devel are both installed.
> After searching around on google, I found you can get around this
> ./configure bug by editing the ./configure script and changing the line
>
> from:
>
>   if test -f actest.cpp && grep klineedit actest.cpp > /dev/null; then
>
> to:
>
>   if test -f actest.cpp && grep KLineEdit actest.cpp > /dev/null; then
>
> This is on line 29856. I found the solution here:
> http://www.skepticats.com/linlog/entries/2005/08/14_1024/
>
> This gets me through the configure script. But now, "make" gives this error:
>
> Making all in devices
> make[3]: Entering directory `/home/scott/tars/piklab-0.4.1/src/devices'
> /bin/sh ../../libtool --silent --mode=link --tag=CXX g++
> -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500
> -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W
> -Wpointer-arith -Wwrite-strings -O2 -Wformat-security
> -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common
> -o xml_to_data_device  xml_device_parser.o
> ../../src/xml_to_data/libxmltodata.la ../../src/devices/libmisc.la
> -lkdecore -lusb
> g++: /usr/lib/libidn.so: No such file or directory
>
> This isn't a lie, because on 64bit machines this library is located in
> /usr/lib64/ ! So reading between the lines and picking up a hint here and
> there I deduced you need to actually configure like this:
>
> ./configure --enable-libsuffix=64 --with-qt-dir=/usr/lib64/qt-3.3/
> --with-qt-libraries=/usr/lib64/qt-3.3/lib/
>
> Success! I can now configure. But compiling is another story. There are
> thousands of QT warnings and one piklab error. Line 324 of
> DirectPrgConfigWidget.cpp reads:
>
> Direct::ConfigWidget::ConfigWidget(QWidget *parent)
>   : ProgConfigWidget(Device::User::DirectProgrammer, parent,
> "direct_prog_config_widget")
>
> But should be:
>
> Direct::ConfigWidget::ConfigWidget(QWidget *parent)
>   : ProgConfigWidget(Device::User::DirectProgrammer, parent,
> "direct_prog_config_widget")
>
> After this fix I *finally* built a KDE app on an Fedora Distribution!
> Piklab does indeed run too. However I did have to run as root to allow
> connection:

Hi Scott,

My 32-bit FC4 building process is much easier. I only need to do one thing:
export QTDIR=/usr/lib/qt-3.3

Other than this, there is nothing to change for FC4. Could you check
again with this change and your 64-bit lab fix?

It is also recommemded to use --enable-debug=full so that quite some
useful debug message can be shown under the GUI and the command
line piklab-prog tool.

However I still have some problems with USB connections under FC4
with 2.6.14 kernel.

Regards,
Xiaofan

> Hi Scott,
>
> My 32-bit FC4 building process is much easier. I only need to do one
> thing:
> export QTDIR=/usr/lib/qt-3.3
>
> Other than this, there is nothing to change for FC4. Could you check
> again with this change and your 64-bit lab fix?

Hi Xiaofan,

This is insufficient for the 64-bit build. I get this error:

checking for Qt... configure: error: Qt (>= Qt 3.1 (20021021)) (headers
and libraries) not found. Please check your installation!

> It is also recommemded to use --enable-debug=full so that quite some
> useful debug message can be shown under the GUI and the command
> line piklab-prog tool.

I'll turn on debugging and recompile.


> However I still have some problems with USB connections under FC4
> with 2.6.14 kernel.

I'm using 2.6.11...

Scott

On 2/16/06, Scott Dattalo ####@####.#### wrote:
> > It is also recommemded to use --enable-debug=full so that quite some
> > useful debug message can be shown under the GUI and the command
> > line piklab-prog tool.
>
> I'll turn on debugging and recompile.

for your information "--enable-debug=full" is useful to get
information in case of a program crash. You should also use the
"-debug" option of piklab-prog or the equivalent option in piklab
config dialog for displaying debug messages using piklab...

Nicolas

> From: Scott Dattalo ####@####.####
> Sent: Thursday, February 16, 2006 2:34 PM
>
> Thanks for posting this announcement. My ancient PicStart+ 
> finally died after nearly 10 years of service (RIP), so I 
> upgraded to an ICD2. (I also bought the dsPICDEM 1.1 eval 
> board!).

Just want to point out that Scott has already been working
on porting gpsim to dsPIC. He has posted the progress in
Microchip Forum dsPIC section. 

Hopefully piklab/ICD2 will work with quite some dsPICs. Some
of the dsPICs should be supported but I have not tested any 
dsPICs yet with piklab. I will do it soon with a 30F2010
using ICD2.

Regards,
Xiaofan

>
>> From: Scott Dattalo ####@####.####
>> Sent: Thursday, February 16, 2006 2:34 PM
>>
>> Thanks for posting this announcement. My ancient PicStart+
>> finally died after nearly 10 years of service (RIP), so I
>> upgraded to an ICD2. (I also bought the dsPICDEM 1.1 eval
>> board!).
>
> Just want to point out that Scott has already been working
> on porting gpsim to dsPIC. He has posted the progress in
> Microchip Forum dsPIC section.

I'd also like to point out that you shouldn't get too excited yet...

At the moment I'm writing regression tests to test the p18f extended
instructions that I just added. After that I'm going to have to address
some gui issues; the latest version of gtk is finally deprecating some of
the old gtk API that gpsim currently uses. As a result, the source browser
text is getting mangled. The good news is that I've been redesign this
code over the last few months (if you click on the menu item
edit->preferences, this brings up a mini-source browser window that is
built using the new gtk API)


> Hopefully piklab/ICD2 will work with quite some dsPICs. Some
> of the dsPICs should be supported but I have not tested any
> dsPICs yet with piklab. I will do it soon with a 30F2010
> using ICD2.

At one time, gpsim supported the ICD (but this code has not been
maintained). Now that I have an ICD2, I'll probably look into what it
takes to add support for it.

Scott

On 2/17/06, Scott Dattalo ####@####.#### wrote:
>
> > Hopefully piklab/ICD2 will work with quite some dsPICs. Some
> > of the dsPICs should be supported but I have not tested any
> > dsPICs yet with piklab. I will do it soon with a 30F2010
> > using ICD2.
>
> At one time, gpsim supported the ICD (but this code has not been
> maintained). Now that I have an ICD2, I'll probably look into what it
> takes to add support for it.
>

Nicolas is working on ICD2 debugging under Linux with piklab for the
16F device. Currently it is partially working.

By the way, the tests on PICkit 2 shows that piklab supports most of
the baseline and mid-range PICs supported by Microchip PICkit 2
firmware version 1.10. It only has some minor bugs with the handling
of OSCCAL value.

Regards,
Xiaofan