Piklab

Stefan: the reporter is using 0.21.11 which is supported by piklab.

I tested gpsim 0.21.11 with sdcc 2.6.0 and evrything seems to work...

I have uninstalled the Gpsim package version 0.20.14 from my computer, and
compiled the version 0.22.0 myself. Now, piklab can use (and autodect)
gpsim as programmer device.

Please update your gpsim to 0.22.0 !

Oh, i was wrong. this gettimeofday is normal for an application in KDE.
Nothing misterious, as i thought.

Wow! An "strace piklab" brought this on the daylight:
gettimeofday({1172531729, 247331}, NULL) = 0
gettimeofday({1172531729, 247408}, NULL) = 0
gettimeofday({1172531729, 247483}, NULL) = 0
gettimeofday({1172531729, 247559}, NULL) = 0
gettimeofday({1172531729, 247632}, NULL) = 0
gettimeofday({1172531729, 247709}, NULL) = 0
gettimeofday({1172531729, 247785}, NULL) = 0
gettimeofday({1172531729, 247862}, NULL) = 0
gettimeofday({1172531729, 247944}, NULL) = 0
gettimeofday({1172531729, 248021}, NULL) = 0
gettimeofday({1172531729, 248097}, NULL) = 0
gettimeofday({1172531729, 248173}, NULL) = 0
gettimeofday({1172531729, 248249}, NULL) = 0
gettimeofday({1172531729, 248321}, NULL) = 0
gettimeofday({1172531729, 248400}, NULL) = 0
gettimeofday({1172531729, 248478}, NULL) = 0
gettimeofday({1172531729, 248555}, NULL) = 0
gettimeofday({1172531729, 248641}, NULL) = 0
gettimeofday({1172531729, 248727}, NULL) = 0
gettimeofday({1172531729, 248805}, NULL) = 0
gettimeofday({1172531729, 248886}, NULL) = 0
gettimeofday({1172531729, 248963}, NULL) = 0
gettimeofday({1172531729, 249052}, NULL) = 0
gettimeofday({1172531729, 249130}, NULL) = 0
gettimeofday({1172531729, 249203}, NULL) = 0

Piklab reads continusly gettimeofday. That is really strange in my
opinion. No wonder, why the timing with the programmers will not work
correctly.

I have now updated to the newest gputils and SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3
#4543 (Feb 26 2007) (UNIX)

I have still this message "Could not detect supported devices for "GPSim".
Please check
installation.", when i try to press the "play" button for gpsim. Should i
"strace" it?

Stefan: now I see you're using sdcc 2.5.0 so it's normal you need to add
the header...

Sorry i meant i have added -Wl-r to the linker script in toolchain sdcc.

Ok. I have added the wc-r to the linker tab of sdcc.
I have seen, that the binary of sdcc was successfully detected by piklab.
The paths of the header files of toolchain sdcc is:
/usr/share/gputils/header/

The path of the linker script directory is: /usr/share/gputils/lkr/

I have changed them to /usr/share/sdcc/lib/pic16 but changed them back,
because it was not working.

Maybe i should update sdcc to the newest version from svn, because there
were some changes made in the last week.


sdcc -mpic14 -p16f873 -V -I/home/stefan/piklab-0.13.3/test/sdcc/
-Wl-oblinker.hex -Wl-m -Wl-ainhx32 blinker.c
Processor: 16f873
message: using default linker script "/usr/share/gputils/lkr/16f873.lkr"
error: linker script has no definition that matches the type of section
"data_blinker"
+ "/usr/bin/sdcpp" -nostdinc -Wall -std=c99 -DSDCC=1
-I"/home/stefan/piklab-0.13.3/test/sdcc/" -DSDCC_MODEL_SMALL -DSDCC_pic14
-D__pic14 -I"/usr/bin/../share/sdcc/include/pic14"
-I"/usr/share/sdcc/include/pic14" -I"/usr/bin/../share/sdcc/include"
-I"/usr/share/sdcc/include" "blinker.c"
+ "/usr/bin/gpasm" -c "blinker.asm"
+ "/usr/bin/gplink" -o blinker.ihx "blinker.o" -oblinker.hex -m -ainhx32
*** Beendet mit Status: 1 ***

Stefan: if you are using sdcc 2.6.0, you shouldn't need to use the header
file (it should be correctly installed somewhere). Could you check the
toolchain configuration for "sdcc" and check that the directories are
correctly detected.

For the second problem, it's a bug in sdcc and the solution is documented
here:
http://piklab.sourceforge.net/wiki/index.php/Problem_with_sdcc

Othewise not sure about the initial problem and the crash you experienced.
I'll investigate.

Nicolas

Ok, i have tested a bit more with svn rev1920 . Other compiler like Jal
won't accept the asm file with a message: can compile only files with
extention *.jal

That is as expected and very nice!
Then i tried to compile /sdcc/blinker.c with sdcc. That worked not,
because piklab or sdcc expected a file named pic16f873.h in the folder
/sdcc there was a file named sdcc250_pic16f873.h which i renamed to
pic16f873.h

after a new compile attempt from me compile Log shows:
sdcc -mpic14 -p16f873 -V -I/home/stefan/piklab-0.13.3/test/sdcc/
-Wl-oblinker.hex -Wl-m -Wl-ainhx32 blinker.c
Processor: 16f873
message: using default linker script "/usr/share/gputils/lkr/16f873.lkr"
error: linker script has no definition that matches the type of section
"data_blinker"
+ "/usr/bin/sdcpp" -nostdinc -Wall -std=c99 -DSDCC=1
-I"/home/stefan/piklab-0.13.3/test/sdcc/" -DSDCC_MODEL_SMALL -DSDCC_pic14
-D__pic14 -I"/usr/bin/../share/sdcc/include/pic14"
-I"/usr/share/sdcc/include/pic14" -I"/usr/bin/../share/sdcc/include"
-I"/usr/share/sdcc/include" "blinker.c"
+ "/usr/bin/gpasm" -c "blinker.asm"
+ "/usr/bin/gplink" -o blinker.ihx "blinker.o" -oblinker.hex -m -ainhx32
*** Beendet mit Status: 1 ***

I have no clue what went wrong, but i like the new integrated console! :-)

confirmed with piklab 13.3 and svn1920. Maybe i make something completly
wrong, because i have no knowlege how to use gpsim in the normal way. I
have opened the program blink.asm in the test directory of piklab. Then i
pressed on the button compile and piklab crashed.

It crashed here with the output on the commandline:
Failed to open device
ScimInputContextPlugin()
Uh oh.. can't write data..
ASSERT: "p" in tool_group.cpp (73)
KCrash: Application 'piklab' crashing...

I have:
stefan@cipy:~$ sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.5.0 #1020 (Jan 4 2006) (UNIX)
stefan@cipy:~$ gpsim -v
gpsim - the GNUPIC simulator
version: 0.20.14
gpsim> processor list
generic_pic 14bit_pic 12bit_pic 16bit_pic
pic12c508 pic12c509 pic16c84 pic16cr83
pic16cr84 pic16f83 pic16f84 pic16c54
pic16c55 pic16c61 pic16c71 pic16c712
pic16c716 pic16c62 pic16c62a pic16cr62
pic16c63 pic16c64 pic16c64a pic16cr64
pic16c65a pic16c65 pic16c72 pic16c73
pic16c74 pic16f627 pic16f628 pic16f873
pic16f874 pic16f877 pic17c7xx pic17c75x
pic17c752 pic17c756 pic17c756a pic17c762
pic17c766 pic18cxx2 pic18c2x2 pic18c242
pic18c252 pic18c442 pic18c452

can't attach a file here, so i copy the output of the backtrace directly.

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 570)]
[KCrash handler]
#6 0x080e4bfe in Compile::Data::operator= (this=0x2c) at
generic_tool.h:51
#7 0x080e0086 in Compile::Process::init (this=0x0, data=@0xbfd9c6b4,
manager=0x86e1390) at compile.cpp:89
#8 0x0810f67d in Tool::Group::createCompileProcess (this=0x86383a8,
data=@0xbfd9c6b4, manager=0x86e1390) at tool_group.cpp:74
#9 0x080e015a in Compile::Manager::setup (this=0x86e1390,
category=Tool::Assembler) at compile.cpp:345
#10 0x080e2031 in Compile::Manager::setupAssemble (this=0x86e1390)
at compile.cpp:387
#11 0x080e2b51 in Compile::Manager::prepareAction (this=0x86e1390)
at compile.cpp:429
#12 0x080e2d31 in Compile::Manager::start (this=0x86e1390) at
compile.cpp:451
#13 0x080e6f4f in Compile::Manager::qt_invoke (this=0x86e1390, _id=2,
_o=0xbfd9c838) at compile.moc.cpp:332
#14 0x412cc051 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#15 0x4165f432 in QSignal::signal () from /usr/lib/libqt-mt.so.3
#16 0x412e97c8 in QSignal::activate () from /usr/lib/libqt-mt.so.3
#17 0x412f12b8 in QSingleShotTimer::event () from /usr/lib/libqt-mt.so.3
#18 0x41261f3e in QApplication::internalNotify () from
/usr/lib/libqt-mt.so.3
#19 0x4126213a in QApplication::notify () from /usr/lib/libqt-mt.so.3
#20 0x40e67d7d in KApplication::notify () from /usr/lib/libkdecore.so.4
#21 0x081a837d in QApplication::sendEvent (receiver=0x86c32e8,
event=0xbfd9cba8) at qapplication.h:520
#22 0x4125392b in QEventLoop::activateTimers () from
/usr/lib/libqt-mt.so.3
#23 0x41206f67 in QEventLoop::processEvents () from
/usr/lib/libqt-mt.so.3
#24 0x4127aa2f in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#25 0x4127a952 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#26 0x41260a4d in QApplication::exec () from /usr/lib/libqt-mt.so.3
#27 0x080824de in main (argc=1, argv=0xbfd9cea4) at main.cpp:35

hum weird I don't see how sdcc can affect gpsim detection.

Could you attach the output of "gpsim -i" and of the commands "version"
and "processor list"?