|
|
| |
In lugnet.robotics.rcx.nqc, Dennis Clark wrote:
> Hello with a query from the past...
Funny I'm tripping over this just today...
> I used MacNQC for ages on other computers but I find now that I can't
> write a program out to an RCX 1.0 brick using MacNQC 3.04 or 4.05b. I
> can send the firmware with no problem but when I try to download a
> program I get a "communications error" type of message every time. This
The most weird thing happened to me today on my iMac - I've only dug out the old
Mindstorms stuff last weekend and went through reviving cybermaster and
Spybotics - and guess what, the RCX and IR Tower failed me as well. I have
finally managed to download a simple program again after reloading the firmware
_twice_ to an old 1.0 RCX (it's the 2.0 firmware, though).
Comms seem to work now, but for sake of completeness I have just loaded a second
RCX.
Strikingly, both seemed to require a reload of the firmware first but still want
to be talked to as an RCX rather than RCX 2.
> is with either the USB tower or a regular serial tower through a
> USB/serial dongle. I'm using a 1.33GHz G4 running Tiger 10.4.6. Has
> anyone else seen this and know what critical step that I'm missing?
Can't say really - one major problem with MacNQC seems to be that it is still a
Rosetta application - a UB build would be nice to come by but apparently not
much is happening about MacNQC anymore.
I've tried two USB towers and a serial w/ dongle now (it _had_ to work as
Spybotics and cybermaster talk just fine) - before firmware refresh -> no use.
After firmware refresh -> all fine.
I'll have an eye on it, the kids are keeping me busy to program their models
(I'll have to show them the ways anytime soon).
Regards,
Jerry
|
|
| |
I have updated the earlier NQC patch and uploaded two additional patches.
Patch 1 - Update of the NQC USB and TCP Patch
http://sourceforge.net/tracker/?func=detail&aid=2639763&group_id=68600&atid=521778
* Updated for compatibility with gcc 4.4.x
* Removed the DESTDIR patch for the Makefile (moved to another patch)
Patch 2 - Support Makefile Variables DESTDIR and TOOLPREFIX
http://sourceforge.net/tracker/?func=detail&aid=2833299&group_id=68600&atid=521778
* Added support for the Makefile variables DESTDIR and TOOLPREFIX,
enhancing compatibility with distro packaging tools
Patch 3 - Enable Setting a Default Port Name in a Configuration File
http://sourceforge.net/tracker/?func=detail&aid=2833359&group_id=68600&atid=521778
* If no port is specified on the command line (the "-S" argument) and if
the environment variable RCX_PORT is not defined, NQC on Linux will then
check for a default device name in the following configuration files (in
order):
1) ~/.rcx/device.conf
2) /etc/rcx/device.conf
These configuration files are designed to be compatible with Bibo, as
patches have been created for Bibo to allow it to process port names that
are specified in the NQC format. Due to limitations with environment
variables, there is a need to have an alternate means for specifying a
default port.
Thank you,
Matthew
--------------------------------------------
Matthew Sheets <mesheets@hotSPAMMERmail.com> wrote in message
news:KGBJK3.IBu@lugnet.com...
For those interested, I have posted a patch to SourceForge for NQC at
http://sourceforge.net/tracker/index.php?func=detail&aid=2639763&group_id=68600&atid=521778 .
This patch includes several changes, most of which are related to Linux,
though portions may be of use to other platforms.
* Removed the dependency of <LegoUSB/legousbtower.h> when building with USB
support for Linux
* Set some properties so that they can be set from the "make" command line
instead of modifying the Makefile, facilitating easier package creation
(including DEFAULT_SERIAL_NAME and DEFAULT_USB_NAME).
* Now that the Lego USB tower driver is included in the kernel, the device
is typically either /dev/legousbtower0 or /dev/usb/legousbtower0. The code
files have been updated to reflect these names.
* If the NQC "-S" argument is in the format "usb[:<device>]" (e.g.
usb:/dev/lego0), the program will use /dev/lego0 as the USB device; if the
"-S" argument is simply "usb" then the program will check for the presence
of DEFAULT_USB_NAME, /dev/legousbtower0, or /dev/usb/legousbtower
* A "tcp" option has been added as an option to the "-S" argument,
performing communication over a TCP connection instead of a serial or USB IR
device. This facilitates the use of NQC with programs such as BrickEmu, an
RCX emulator (see http://hoenicke.ath.cx/rcx/brickemu.html ). The full
option format is "tcp[:<host>[:<port>]]" If port is not provided, the
program will default to the "magic" Lego port of 50637, and if the host is
not provided, the program will default to localhost.
I hope that some of this might be useful for a future release. If there is
a future release, I would also like to propose that the source archive be
packaged more GNU-style, in that the root of the archive would only contain
a single folder named in the format $PACKAGE-$VERSION (e.g. nqc-3.1r7). All
the source content would then be under this folder, easing some package
management tasks for certain distributions.
Thank you,
Matthew
|
|
| |
Hello with a query from the past...
I used MacNQC for ages on other computers but I find now that I can't
write a program out to an RCX 1.0 brick using MacNQC 3.04 or 4.05b. I
can send the firmware with no problem but when I try to download a
program I get a "communications error" type of message every time. This
is with either the USB tower or a regular serial tower through a
USB/serial dongle. I'm using a 1.33GHz G4 running Tiger 10.4.6. Has
anyone else seen this and know what critical step that I'm missing?
I've posted to LUGNET, but it takes forever for a non-member's post to
show up there apparently, so I'm taking a stab at the robot crew at
large here. Any ideas?
thanks,
DLC
|
|
| |
For those interested, I have posted a patch to SourceForge for NQC at
http://sourceforge.net/tracker/index.php?func=detail&aid=2639763&group_id=68600&atid=521778 .
This patch includes several changes, most of which are related to Linux,
though portions may be of use to other platforms.
* Removed the dependency of <LegoUSB/legousbtower.h> when building with USB
support for Linux
* Set some properties so that they can be set from the "make" command line
instead of modifying the Makefile, facilitating easier package creation
(including DEFAULT_SERIAL_NAME and DEFAULT_USB_NAME).
* Now that the Lego USB tower driver is included in the kernel, the device
is typically either /dev/legousbtower0 or /dev/usb/legousbtower0. The code
files have been updated to reflect these names.
* If the NQC "-S" argument is in the format "usb[:<device>]" (e.g.
usb:/dev/lego0), the program will use /dev/lego0 as the USB device; if the
"-S" argument is simply "usb" then the program will check for the presence
of DEFAULT_USB_NAME, /dev/legousbtower0, or /dev/usb/legousbtower
* A "tcp" option has been added as an option to the "-S" argument,
performing communication over a TCP connection instead of a serial or USB IR
device. This facilitates the use of NQC with programs such as BrickEmu, an
RCX emulator (see http://hoenicke.ath.cx/rcx/brickemu.html ). The full
option format is "tcp[:<host>[:<port>]]" If port is not provided, the
program will default to the "magic" Lego port of 50637, and if the host is
not provided, the program will default to localhost.
I hope that some of this might be useful for a future release. If there is
a future release, I would also like to propose that the source archive be
packaged more GNU-style, in that the root of the archive would only contain
a single folder named in the format $PACKAGE-$VERSION (e.g. nqc-3.1r7). All
the source content would then be under this folder, easing some package
management tasks for certain distributions.
Thank you,
Matthew
|
|
| |
In lugnet.robotics.rcx.nqc, Iain Hendry wrote:
>
> Um... I'm sorry, planes flying overhead. :) I literally am on the cusp of
> understanding programming; I just learned what an array was at our last rtl
> event. :)
What I said had less to do with programming as it had to do with understanding
your new Linux-based PC. Do you know how to use Linux from a command prompt?
Can you open a terminal window on your eeePC and type "gcc" and see what
happens?
I googled a bit and it looks like eeePC uses a Xandros 4 distribution. Googling
"Xandros NQC" makes it look like there could be a package available in the
Xandros distro for NQC. You'd need to install that package. From my googling
it appeared that people have had to install gcc manually before they could build
packages from source code.
Send me an email if you want me to send you an already compiled NQC executable
that you can try out on your eeePC.
John Hansen
|
|
| |
In lugnet.robotics.rcx.nqc, John Hansen wrote:
> Normally people build NQC from sourcecode for Linux platforms so there has not
> been a binary release for Linux in the past. Does the eeePC include all the
> standard GNU development tools such as yacc, flex, and GCC? If it does then you
> can probably build NQC yourself after downloading the sourcecode from the NQC
> website
>
> http://bricxcc.sourceforge.net/nqc/
>
> If it doesn't include those tools perhaps they can be added via download? If
> not, I could build you a binary for an x86 architecture (which I believe is what
> the eeePC uses).
Um... I'm sorry, planes flying overhead. :) I literally am on the cusp of
understanding programming; I just learned what an array was at our last rtl
event. :)
-Iain
|
|
| |
In lugnet.robotics.rcx.nqc, Iain Hendry wrote:
> No, the eeePC runs Linux, with a custom-designed interface over top by ASUS.
> So, I was wondering if NQC is available for Linux.
Normally people build NQC from sourcecode for Linux platforms so there has not
been a binary release for Linux in the past. Does the eeePC include all the
standard GNU development tools such as yacc, flex, and GCC? If it does then you
can probably build NQC yourself after downloading the sourcecode from the NQC
website
http://bricxcc.sourceforge.net/nqc/
If it doesn't include those tools perhaps they can be added via download? If
not, I could build you a binary for an x86 architecture (which I believe is what
the eeePC uses).
John Hansen
|
|
| |
In lugnet.robotics.rcx.nqc, Jetro de Chateau wrote:
> Is it Windows based? If so, have you tried installing BricxCC?
Hi Jetro,
No, the eeePC runs Linux, with a custom-designed interface over top by ASUS.
So, I was wondering if NQC is available for Linux.
-Iain
|
|
| |
In lugnet.robotics.rcx.nqc, Iain Hendry wrote:
> Hi all,
>
> I have an ASUS eeePC, and was wondering if anyone knew of a way to get NQC onto
> it so I could program my RCX with it?
>
> Thanks!
>
> -Iain
Is it Windows based? If so, have you tried installing BricxCC?
Jetro
|
|
|
