NBC compilation problem (linux)

[slavkozn]

Hi,

i tried to package new svn version (526) and i go to problems:

Code: Select all

...
make -C NXT -f nbcunix.mak all
...
Compiling /home/slavko/projekty/svn/export/bricxcc-3.3+svn526/bricktools/NQCSerialWin.pas
Fatal: Can't find unit Windows used by NQCSerialWin
Fatal: Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled)
make[2]: *** [uNBCInterface.o] Error 1
make[2]: Leaving directory `/home/slavko/projekty/svn/export/bricxcc-3.3+svn526/NXT'
make[1]: *** [nbc] Error 2
...

Why is on Linux the NQCSerialWin file compiled?

[afanofosc]

I have checked in changes to a few of the makefiles to fix this problem. My apologies for not checking the Linux build sooner.

John Hansen

[slavkozn]

My apologies for not checking the Linux build sooner.

No problem, thanks

But it still fails, but with another mistake now (rev529):

Code: Select all

...
/usr/bin/make -f nexttool.mak
...
Compiling NeXTTool.dpr
NeXTTool.dpr(19,2) Note: APPTYPE is not supported by the target OS
Compiling NXT/uNXTConstants.pas
Compiling bricktools/uSpirit.pas
Fatal: Can't find unit uProgram used by uSpirit
Fatal: Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled)
make[1]: *** [nexttool] Error 1
...

the uProgram.pas exists under NXT directory. I am confused...

[afanofosc]

I think I have fixed the remaining problems with building nbc, nexttool, and my graphical utilities for linux (see toolsunix.mak). Please let me know if you still have trouble building anything.

John Hansen

[tcwan]

Hi John,

I think I have fixed the remaining problems with building nbc, nexttool, and my graphical utilities for linux (see toolsunix.mak). Please let me know if you still have trouble building anything.

John Hansen

What dependencies are needed for the Linux version of nexttool/GUI Next Tool? My preferred Linux distro is Fedora (currently Fedora 15).

AFAIK libusb-0.1.x implemented blocking I/O so it is not possible to poll for data from the NXT without sending any commands first.
If your tools are able to work with libusb 1.08 then nexttool would really be a cross-platform solution for Mac, Win & Linux.
Unfortunately I couldn't get libusb (0.1.x or 1.0x) working on Mac / Windows so those platforms are still reliant on the Fantom drivers.

[linusa]

AFAIK libusb-0.1.x implemented blocking I/O so it is not possible to poll for data from the NXT without sending any commands first.

That might be true, however I can't think of a situation where you want to do that (polling data from the NXT without sending any commands first). As I understand it, you can always only get data if you ask for it first. So this shouldn't be a problem. As long as you're using direct commands of course. For our MATLAB toolbox, we're using libusb-0.1.x on Linux and can apparently do everything we need and everything that is possible with PC<->NXT communication.

Unfortunately I couldn't get libusb (0.1.x or 1.0x) working on Mac / Windows so those platforms are still reliant on the Fantom drivers.

I myself couldn't get libusb 0.1.x to work from MATLAB with the NXT on Windows. The libusb demo examples in C++ worked. They also worked for other devices via MATLAB. And IIRC, there were C(++) apps using libusb-0.1.x on Windows that worked with the NXT. To add more strangeness: The whole thing via MATLAB once worked with a certain LeJOS firmware! And the same command sequence for libusb from MATLAB worked on Linux.

So there was indeed something very strange going on with libusb and Windows and certain conditions (i.e. calling libusb from MATLAB and trying to talk to an NXT).

On the other hand, NXT_Python (predecessor to nxt-python) was based on pyUSB, which in turn uses libusb. And even though I myself couldn't get it to run on Windows (but due to other Python related package problems), apparently other people could. Nowaday, nxt-python also has a Fantom backend. But still: Using libusb on Windows with the NXT is somehow possible!

[tcwan]

AFAIK libusb-0.1.x implemented blocking I/O so it is not possible to poll for data from the NXT without sending any commands first.

That might be true, however I can't think of a situation where you want to do that (polling data from the NXT without sending any commands first). As I understand it, you can always only get data if you ask for it first. So this shouldn't be a problem. As long as you're using direct commands of course. For our MATLAB toolbox, we're using libusb-0.1.x on Linux and can apparently do everything we need and everything that is possible with PC<->NXT communication.

That is fine if you're using strictly Direct Commands to communicate with the NXT.
ARMDEBUG (which uses different low level command packets) would work better if it can implement non-blocking reads; currently I had to work around this limitation.

I myself couldn't get libusb 0.1.x to work from MATLAB with the NXT on Windows. The libusb demo examples in C++ worked. They also worked for other devices via MATLAB. And IIRC, there were C(++) apps using libusb-0.1.x on Windows that worked with the NXT. To add more strangeness: The whole thing via MATLAB once worked with a certain LeJOS firmware! And the same command sequence for libusb from MATLAB worked on Linux.

So there was indeed something very strange going on with libusb and Windows and certain conditions (i.e. calling libusb from MATLAB and trying to talk to an NXT).

On the other hand, NXT_Python (predecessor to nxt-python) was based on pyUSB, which in turn uses libusb. And even though I myself couldn't get it to run on Windows (but due to other Python related package problems), apparently other people could. Nowaday, nxt-python also has a Fantom backend. But still: Using libusb on Windows with the NXT is somehow possible!

Well, the Fantom backend in nxt-python was Nicolas Schodet and my contribution because the alternatives didn't work

[slavkozn]

I think I have fixed the remaining problems with building nbc, nexttool...

compilation succesful I have no brick now, then i tested only showing help, bit all seems to work. Thanks! Only cosmetic problem reported by lintian (the debian package's quality tool) :

Code: Select all

spelling-error-in-binary usr/bin/nbc writeable writable

graphical utilities for linux (see toolsunix.mak).

Nice new! I will test it and i wil write feedback here.

My first look to toolsunix.mak is only cosmetic too, here "clean" is as first target , can you add target "all" with all requisities, to ensure that simple make invocation builds all targets, please?

[slavkozn]

my graphical utilities for linux (see toolsunix.mak). Please let me know if you still have trouble building anything.

hmm, i386 architecture hardcoded this is a problem for me on the amd64 system, the same problem was with nbc too some months ago.

another problem is with lover/uppercase letters in dpr names, for example, the bricxcc target depend on bricxcc.dpr, but file is named as BricxCC.dpr.