|
|
| |
Recently, I stumbled across an article in JOT discussing the compilation of
.NET assemblies into programs for the Lego MindStorms RCX. As I didn't see
a project name or project URL in the article, I initially had some trouble
tracking it down, but a few blog and forum posts seemed to help get me
pointed in the right direction. From those, I was able to track down the
project page for Visual Storms.
Unfortunately, though, I was not able to download the Visual Storms and
Sharp Storms files. While the CLIFileRW project on Codeplex is still
accessible, the Visual Storms and Sharp Storms pages no longer appear to be
online. I was able to view the download pages for Visual Storms and Sharp
Storms via archive.org, but the files could not be downloaded. I also
attempted to contact the three individuals listed in the article, but the
only one I heard back from said he no longer had the source.
If anyone still has these files and can either point me to a download
location or email them to me, I would *greatly* appreciate it.
Thank you,
Matthew
[Jot]
Article - http://www.jot.fm/issues/issue_2004_02/article2.pdf
[Posts]
Blog -
http://www.alexthissen.nl/blogs/main/archive/2004/06/04/visual-and-sharp-storms.aspx
Another Blog -
http://weblogs.asp.net/fmarguerie/archive/2003/04/24/6044.aspx
Robotics4.NET Blog -
http://compass.di.unipi.it/CS/blogs/robotics4.net/archive/2004/10/06/158.aspx
Forum Posting - http://www.artima.com/forums/flat.jsp?forum=152&thread=28901
[Project Page]
Visual Storms -
http://medialab.di.unipi.it/Project/visualstorms/index.html.en
[Codeplex]
CLIFileRW - http://www.codeplex.com/clifilerw
[Archive.org]
Visual Storms -
http://web.archive.org/web/20070208030329/http://dotnet.di.unipi.it/MultipleContentView.aspx?code=161
Sharp Storms -
http://web.archive.org/web/20070208175252/http://dotnet.di.unipi.it/MultipleContentView.aspx?code=106
|
|
| |
Hi,
In lugnet.robotics.rcx.legos, Matthew Sheets wrote:
> While working on Bibo, I observed some unexpected differences between GCC
> 3.4.6 and gcc 4.4.1. Specifically, one of the XS Lisp demo programs that is
> fine when built with 3.4.6 is too large (section .bss not within region ram)
> when built with 4.4.1. The only change was the compiler version being used.
> The optimization argument was -Os (optimize for size) and the binutils
> version was 2.16.1.
>
> Interestingly, bibo.srec and three of the four libraries are smaller when
> built using 3.4.6 (libfloat.a is the same size either way), but if there is
> a difference in the size of the demo programs, those built using 4.4.1 are
> usually smaller (memtest.lx is the only exception here).
>
> Below is a chart listing what I found. Column 1 is the comparison, 2 is
> the 3.4.6-built size, 3 is the 4.4.1-built size, and 4 is the file name.
>
> Ver 3.4.6 4.4.1 File
> ========================
> (3) 35892 - 38496 - bibo.srec (~2.6k)
>
> (3) 10018 - 10470 - libc.a (452)
> (3) 2774 - 3002 - libc++.a
> (-) 9576 - 9576 - libfloat.a (228)
> (3) 5320 - 6448 - libmint.a (1128)
>
> (-) 278 - 278 - c++.lx
> (4) 548 - 520 - cpu.lx
> (4) 392 - 370 - dccthrottle.lx
> (-) 90 - 90 - helloworld.lx
> (-) 202 - 202 - helloworld_lnp.lx
> (4) 372 - 340 - linetrack.lx
> (3) 228 - 234 - memtest.lx
> (-) 78 - 78 - robots.lx
> (4) 262 - 250 - rover.lx
> (-) 144 - 144 - sound.lx
> (4) 4230 - 4198 - trailerbot.lx
>
> (chart best view with a fixed-width font)
>
> Anyway, I thought this was interesting enough to pass along.
> Observations/comments welcome....
I would just like to add that this matches my experiences, although using some
4.0 version of GCC at that time: I wasn't able to produce working programs (not
even sure about BrickOS kernel) using any GCC version newer than 3.4.6. This is
also the reason why I never ever upgraded (and, thus far, also don't intend to
do so unless someone comes up with a solution) the gcc-h8300-hms packages in
Debian to a new GCC version.
Best,
Michael
|
|
| |
I've been asked if I could make the patch collection updates available as a
full-distribution release. Actually, I can't say that I blame that request.
Most of the changes have already been covered in prior lugnet postings under
the "BrickOS Patches and Development" thread (which technically became a
"Bibo Patches and Development" thread), but I will try to provide a
higher-level overview here (the numbers are based on the patch numbers).
These patches are applied to the Bibo firmware posted at
http://hoenicke.ath.cx/rcx/bibo.html. Several of these patches were
originally written for a variety of differing BrickOS versions, but (where
appropriate) they have been adapted and applied to Bibo.
* 00 - Configuration updates for Cygwin
* (01-05 - gcc 3.3, highmem, performance, Makefile, and tcpcomm patches
needed for BrickOS but already incorporated into Bibo)
* 06 - Signedness patch for dealing with newer gcc's (based on Carl
Troein's work)
* 07 - Allow makelx to handle longer file names (based on a pending
SourceForge patch)
* 08 - Update entrypoint specification to the S9 record for Lego.NET (based
on a pending SourceForge patch)
* 09 - Address compatibility issues in non-Linux/Cygwin environments (based
on a pending SourceForge patch)
* 10 - Serial port init fix for Mac OS X (based on a pending SourceForge
patch)
* 11 - LDCC incorporated into the kernel (based on Mark Riley's work)
* 12 - LNP printf capabilities (based on a version by Brown.edu)
* 13 - lnpmsg communication utility (started out based on Mike LeSauvage's
work)
* 14 - Miscellaneous patches included with xsLisp (based on Taiichi Yuasa's
work)
* 15 - doxygen updates (based on Carl Troein's work)
* 16 - Start of a major reworking of code under the util folder to
eliminate duplicate code
* 17 - Contributor info
* 18 - Standardize the command-line arguments and the command-line argument
processing for the host utilities
* 19 - Update and reorganization of LDCC
* 20 - Linux error/warning fixes (Carl Troein)
* 21 - Bibo patches (Dr. Jochen Hoenicke)
* 22 - Make kexeci's argv argument type more generic
* 23 - Incorporated some code and ideas from http://lnphost.sf.net/
* 24 - Update serial IR tower keepalive functionality
* 25 - Cleanup the util subdirectory
* 26 - Update Makefiles and changed cross-compiler optimization flag to -Os
(space)
* 27 - Made the "View" button functionality a configurable option
* 28 - Lisp for the RCX (based on Taiichi Yuasa's mod of BrickOS 0.2.6.10
at http://www.xslisp.com/)
* 29 - Improved the internal handling of connection types in rcx_comm
* 30 - Runtime-configurable timeout properties for host utilities
* 31 - Support NQC-style device name conventions
* 32 - Check a config file in the user's home directory for a default TTY
to use
* 33 - IR communication and hacked-on (e.g. Bluetooth) communication
* 34 - Config file cleanup removed entries for CONF_* #defines that do not
exist
* 35 - Remove CONF_ASCII dependencies, reducing kernel size, and enhancing
CONF_CONIO
* 36 - Check /etc/rcx/device.conf for a default TTY
* 37 - Reset the automatic shutoff timer if the Lego remote is used while
no programs are running (based on some tips from Dr. Hoenicke)
* 38 - Initialize the IR carrier frequency in the firmware fastloader
* 39 - Updated support for Linux
* 40 - Include the Debian toolprefix for the H8/300 toolchain in the config
list
* 41 - Support for building Esterel programs (in support of work by Martin
Richard and Xavier Fornari)
* 42 - Enabled specifying whether rcx_init() starts the Keepalive timer
After applying these patches, the following changes were made:
* Removed directory util/firmdl (no longer used)
* Removed directory util/dll-src (no longer used)
* Renamed program firmdl3 to firmdl (now that the directory of the same
name has been removed)
This release is available for download at the following URL:
http://sf.net/tracker/?func=detail&aid=2858992&group_id=58151&atid=486699
Enjoy,
Matthew
|
|
| |
The Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699
has been updated.
New for this update are patches 41 and 42.
41: Makefiles and the Esterel Synchronous Programming Language - The
makefiles were updated to support building Esterel source files for the RCX.
More information and links to the Esterel software required for building is
available at http://www.emn.fr/x-info/lego/. Five sample/demo programs
listed on this site have been included in an "esterel" folder in the bibo
distribution (make will only attempt to build these programs if the Esterel
compiler is found).
Also, when doing a "make && make install" on the bibo source, the installed
makefile may be used to build program source files by running "make -f
/path/to/installed/makefile SOURCES=demo.strl" (or demo.c, demo.cpp, demo.s,
demo.S); alternatively, you may run "make -f /path/to/installed/makefile
PROGRAMS=demo.lx" and make will attempt to build the corresponding code
file.
NOTE: While Esterel supports the CPUTS command, this requires that ASCII
support be enabled in Bibo. ASCII support is now disabled by default due to
(1) the size required for its support and (2) the fact that CONIO was
updated to make it easier to output characters to the display without the
size bloat of ASCII support. Some Esterel-generated programs can be quite
large, so space can be at a particular premium when using Esterel. Ideally,
Esterel could be updated to support some of the CONIO functions.
42: RCX Comm - Updated debug output. Modified rcx_init to allow specifying
whether or not to start the IR tower Keepalive handler (this setting does
not have any effect if the device does not require Keepalive functionality).
Thanks,
Matthew
|
|
| |
While working on Bibo, I observed some unexpected differences between GCC
3.4.6 and gcc 4.4.1. Specifically, one of the XS Lisp demo programs that is
fine when built with 3.4.6 is too large (section .bss not within region ram)
when built with 4.4.1. The only change was the compiler version being used.
The optimization argument was -Os (optimize for size) and the binutils
version was 2.16.1.
Interestingly, bibo.srec and three of the four libraries are smaller when
built using 3.4.6 (libfloat.a is the same size either way), but if there is
a difference in the size of the demo programs, those built using 4.4.1 are
usually smaller (memtest.lx is the only exception here).
Below is a chart listing what I found. Column 1 is the comparison, 2 is
the 3.4.6-built size, 3 is the 4.4.1-built size, and 4 is the file name.
Ver 3.4.6 4.4.1 File
========================
(3) 35892 - 38496 - bibo.srec (~2.6k)
(3) 10018 - 10470 - libc.a (452)
(3) 2774 - 3002 - libc++.a
(-) 9576 - 9576 - libfloat.a (228)
(3) 5320 - 6448 - libmint.a (1128)
(-) 278 - 278 - c++.lx
(4) 548 - 520 - cpu.lx
(4) 392 - 370 - dccthrottle.lx
(-) 90 - 90 - helloworld.lx
(-) 202 - 202 - helloworld_lnp.lx
(4) 372 - 340 - linetrack.lx
(3) 228 - 234 - memtest.lx
(-) 78 - 78 - robots.lx
(4) 262 - 250 - rover.lx
(-) 144 - 144 - sound.lx
(4) 4230 - 4198 - trailerbot.lx
(chart best view with a fixed-width font)
Anyway, I thought this was interesting enough to pass along.
Observations/comments welcome....
Matthew
|
|
| |
The Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699
has been updated.
There is just one minor Bibo-specific update this time, patch 40.
40: H8/300 TOOLPREFIX - This patch comes from Debian, where
"h8300-hitachi-coff-" is added to the list of potential H8/300 toolprefixes.
The larger update this time is a set of patches for NQC running on Linux.
Included in these patches is a patch that corresponds with Bibo patches 32
and 36, which enables Bibo to read a default tty device name from a
configuration file. This same capability has now been extended to NQC.
More details on the NQC patches are available here -
http://news.lugnet.com/robotics/rcx/nqc/?n=1900
Matthew
|
|
| |
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
|
|
| |
In lugnet.robotics.nxt, Ralph Hempel wrote:
> Jordan Bradford wrote:
> > I have Windows 7 RC on my netbook and I can't get the NXT software (version 1.1)
> > to install. It hangs when the installer presents its progress bars and starts
> > copying files off the CD.
> >
> > Does the 2.0 software work with Windows 7?
> >
> > By the way, RIS 2.0 installs in Windows 7 but it has problems with the USB
> > tower.
>
> Is this the 64 bit driver issue coming up - again?
>
> Ralph
It's 32-bit Win7.
|
|
| |
Jordan Bradford wrote:
> I have Windows 7 RC on my netbook and I can't get the NXT software (version 1.1)
> to install. It hangs when the installer presents its progress bars and starts
> copying files off the CD.
>
> Does the 2.0 software work with Windows 7?
>
> By the way, RIS 2.0 installs in Windows 7 but it has problems with the USB
> tower.
Is this the 64 bit driver issue coming up - again?
Ralph
|
|
| |
I have Windows 7 RC on my netbook and I can't get the NXT software (version 1.1)
to install. It hangs when the installer presents its progress bars and starts
copying files off the CD.
Does the 2.0 software work with Windows 7?
By the way, RIS 2.0 installs in Windows 7 but it has problems with the USB
tower.
|
|
| |
The Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699
has been updated.
New for this update are patches 36 through 39.
36: RCX tty config file - Extends patch 32 so that /etc/rcx/device.conf will
also be checked for a default tty. The precedence order is first, the
RCXTTY environment variable; second, ~/.rcx/device.conf; third,
/etc/rcx/device.conf.
37: Automatic Shutoff Timer - Reset the automatic shutoff timer if the Lego
remote is used in direct mode (when no programs are running).
38: Firmware Fastloader - Added code to initialize the IR carrier frequency.
39: Linux Patches - As some of you may already know, I have been using
Cygwin. I am currently working to get a Linux-based BrickOS/Bibo
environment up and running, and though that Linux environment is not yet
fully functional, this patch is needed to help some of the earlier patches
run under Linux.
A word of thanks goes to Dr. Jochen Hoenicke for his assistance in answering
questions; any errors are mine. :-)
Matthew
|
|
| |
> I saw a "WeDo 2 Puppet" project on the Scratch website that specifically
> mentions the use of the tilt senso so I suppose it must be possible to use
> sensors as well.
>
> "The scratch project uses the tilt sensor to decide when they spin"
>
> Jetro
You are correct---there is a tilt sensor and a distance sensor value
available in the sensor value block. These get shown even if the
motor blocks are not being shown, so I don't know why I missed them before.
The values are 0 if no WeDo sensors are connected to the computer.
Kevin Karplus
|
|
| |
In lugnet.robotics.rcx, Kevin Karplus wrote:
> So far as I can see from the Scratch interface, there is control of
> one motor, but no sensors. (There are sensors via the ScratchBoard,
> but not through the WeDo interface.)
>
> I don't have the WeDo hardware, so have not investigated further.
>
> Kevin Karplus
I saw a "WeDo 2 Puppet" project on the Scratch website that specifically
mentions the use of the tilt senso so I suppose it must be possible to use
sensors as well.
"The scratch project uses the tilt sensor to decide when they spin"
Jetro
|
|
| |
So far as I can see from the Scratch interface, there is control of
one motor, but no sensors. (There are sensors via the ScratchBoard,
but not through the WeDo interface.)
I don't have the WeDo hardware, so have not investigated further.
Kevin Karplus
|
|
| |
In lugnet.robotics.rcx, Kevin Karplus wrote:
> The Scratch Programming laguage (http://scratch.mit.edu) now includes
> blocks for controlling WeDo motors.
>
> Kevin Karplus
Thanks. From the description I get the impression you can use 1 motor and 1
sensor at a time. Can anyone confirm this?
Jetro
|
|
| |
The Scratch Programming laguage (http://scratch.mit.edu) now includes
blocks for controlling WeDo motors.
Kevin Karplus
|
|
| |
Jetro de Chateau wrote:
> I saw the WeDo sensors and hub available separately on LEGO Education website
> the other day and I started wondering if I could use them for anything... No one
> appears to have tried or managed to use the hub without the official software
> until now and I'm not about to pay money for an application I'm not really going
> to use so I started thinking if the sensors might be used separately.
I have sucessfully written a third party app that will let you
drive the WeDo from your Windows machine. Linux will be supported
fairly easily once I get the driver relinked, Mac when I get a
Mac for development :-)
Contact me offlist if interested.
Ralph
|
|
| |
I saw the WeDo sensors and hub available separately on LEGO Education website
the other day and I started wondering if I could use them for anything... No one
appears to have tried or managed to use the hub without the official software
until now and I'm not about to pay money for an application I'm not really going
to use so I started thinking if the sensors might be used separately.
Since the PF motors can quite easily be used together with the RCX if you use
the conversion cable (PF to 9V) I was wondering if the same would be true of the
sensors (proximity and tilt). I imagine the sensors must be relatively simple
things (PF protocol, low price) so I imagine the give an analogue signal.
Does anyone have any of these sensors and if so can they confirm they can be
used with the RCX? The might be a nice extension to the RCX.
Jetro
|
|
| |
The Bibo Patch Rollup Collection posted to SourceForge at
http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699
has been updated.
New for this update are patches 25 through 35.
25: Cleanup in the util subdirectory
- Updated lnpmsg to more cleanly handle and process command-line arguments
- Removed in mkimg that is a duplicate of code in srecload
- Updated some Makefile cross targets
26: Updated makefiles
- Changed the existing TOOLPREFIX to CROSSTOOLPREFIX, then used TOOLPREFIX
for the host tools (needed when creating packages that must be targeted to,
for example, a 486 processor)
- Moved some target definitions to Makefile.user, since it is shared by
both Makefile.dist and Bibo's make process. This also reduced Makefile
dependencies across SUBDIRS (util, lib, include, kernel, demo, doc). Some
individual subdirs can now be removed from the SUBDIRS assignment statement
in the main Makefile and the rest of the project will still build
successfully.
- Updates related to util/host, as it seems to be stabilizing. Some items
in util/Makefile.sub have been moved to util/host/Makefile.sub, since the
code now resides there
- Removed the need to set PROGRAMS when building *.lx files. Building %.c
/ %.cpp / %.s / %.S will now look for a make variable by the name of "%_SRC"
to determine if additional object files need to be built.
- Changed the cross-compiler optimization from -O2 to -Os (space)
27: Configuration #defines
- Added a CONF_VIEW_BUTTON define based on Taiichi Yuasa's modification,
allowing exclusion of the information display normally provided when
pressing the RCX View button. The primary reason for adding this
configuration define is enable building a smaller kernel.
- Added a configuration define needed in one of the demo programs in case
CONF_RCX_MESSAGE is not defined.
28: Merged XS Lisp - http://www.xslisp.com/
- A few of the above patches were in preparation for this update
- Was originally based on BrickOS 0.2.6.10
- Is not an addition to the kernel but instead can be used to build *.lx
files that can be downloaded to the RCX. The generated *.lx programs are
large, so a smaller kernel is needed.
- Supports both an IR-link mode and an autonomous mode (IR features were
updated to use rcx_comm)
- Added better support for building from Makefiles
- For the full detail on XS, please see the file xs/README and or visit
the website. Note that information on the website refers to files such as
xs, xs0, xs1, xs2, etc. When merged with Bibo, the numeric suffixes were
replace with more descriptive text, and xs/README reflects this
modification.
- A list of suggested configurations to disable is also included in
xs/README. Any other recommendations or suggestions here would be
appreciated.
29: RCX Communication
- Created a tty struct to replace the existing FILEDESCR and tty_type_t
that get passed around in host-based programs.
- Replaced the fast/slow options in the host utilities with support for
specifying a baud rate at run-time.
30: RCX Communication Timeout for Host Utilities
- Timeout value in milliseconds can now be specified at run-time instead
of being a build-time #define. This is useful when switching between a
low-latency, local IR tower and a TCP connection over the Internet (e.g.
using the uplink and downlink features added to ir-server) with a higher
latency.
31: TTY Device Names
- Added support for interpreting NQC-style port name strings of the format
"<device type>:<device name>". This format was already being used by the
TCP and NQC Bibo additions and was extended to include "serial:" and "usb:".
Backwards compatibility with existing conventions has been maintained.
32: Read Default TTY from a Config File
- Added support for reading the default tty device name from a
configuration file ("~/.rcx/tty.conf"). This essentially fulfills the same
purpose as the RCXTTY environment variable, but without some of the
limitations of environment variables. I am hoping to be able to add this
support to NQC, too.
33: IR Communication and Hacked-on (e.g. Bluetooth) Communication
- Attempted to provide an easier starting point for those using
communication hacks such as the bluetooth hack
~ Ability to set the baud rate
~ Ability to turn of echo handling
- Created configuration #defines to allow setting defaults for
~ Baud rate
~ IR Carrier enabled/disabled
~ Transmit echo/no echo
- Replaced slow/fast (2400/4800 bps) options with the ability to select a
baud rate
- Firmware downloads at 2400 bps can now also be completed without sending
the complement bytes (previously, this option was only available for "fast"
4800 baud)
- Enabled setting the communication timeout value at run-time. This is
useful, for example, when switching between a low-latency serial connection
and a higher-latency TCP-based connection.
- Improved the keepalive functionality for serial IR towers
- Moved help text for standard rcx_comm options to the rcx_comm header
file
** IMPORTANT CHANGE NOTE: Parity for all baud rates is now "odd"
34: Config File Cleanup
- Removed #define entries for configurations that no longer exist
- Removed RCX-only #define entries from the host configuration file
35: Remove CONF_ASCII Dependencies
- Currently, if CONF_PROGRAM is defined CONF_ASCII must also be defined.
This patch reduces the CONF_PROGRAM dependency level from CONF_ASCII to
CONF_CONIO, reducing the size of the kernel needed for program support.
- Created #defines for each of the entries in CONF_ASCII's
ASCII-to-CONIO-mask lookup table
- With those #defines, CONF_ASCII is no longer needed for displaying
static strings. (The small hex lookup table included by CONF_CONIO is still
present there.) Functions that are variants of cputc_native*, cpuc_hex*, or
cputw may be used to write to the display. For example, cputs("Lego") may
now be written as cputc_native_user(CHAR_L, CHAR_e, CHAR_g, CHAR_o). While
it's a little longer statement to type, it does help toward reducing kernel
size. ;-)
- All demo programs were able updated to eliminate the need for
CONF_ASCII.
- For dynamically generated strings, CONF_ASCII will still be required.
XS utilizes CONF_ASCII features for the XS functions that mirror the cputs
andcputc C functions (puts and putc), but due to the large size of XS, this
patch just limits the cputs/cputc functionality if CONF_ASCII is disabled
(puts will output "ASCII" and putc will display a '-' in the specified
position).
Thanks,
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
|
|
|
