| |
First off, I'd like to say that I had ZERO problems installing, building,
and testing BrickOS on my PC. That's even with the BrickOS name change
release and the pre-built Hitachi tools. You guys do good work!
There are a few issues I have come across while fiddling around with BrickOS
which the maintainers of BrickOS might consider fixing.
1. The code in the makefiles to set BRICKOS_ROOT only works when you run
make from the BrickOS root. If you try to do a make from the demo
subdirectory, for instance, then BRICKOS_ROOT is always an empty string
(cygwin v1.3.12 & W2K) which results in incorrect library and include paths.
There is a line in the primary Makefile in the BrickOS root which sets
BRICKOS_ROOT. Makefiles in the subdirectories do not benefit from this
line. This is because the statements in Makefile.common
ifndef BRICKOS_ROOT
# export BRICKOS_ROOT=$(shell pwd | sed -e "s/brickos.*/brickos/")/
# export BRICKOS_ROOT=$(shell pwd | sed -e "s/brickos.*/brickos/i")/
# export BRICKOS_ROOT=$(shell pwd | sed -e
"s/\(.*\)\(brickos.*\)\\/.*/\1\2/$(SED_SFLAG)")/
endif
are commented out. Uncommenting the last of the three export statements
fixes this problem in my setup. Alternatively, users must set it manually.
2. Using the pre-built Hitachi tools requires renaming them with a -hitachi
added to the filenames. This is because of an odd bit of code in
Makefile.common:
#
# WindowsNT/Cygnwin, test against several values:
#
ifneq (,$(findstring $(OSTYPE),cygwin32 cygwin CYGWIN_NT-4.0 CYGWIN_NT-5.0
CYGWIN_NT-5.1 WindowsNT Windows_NT))
# NT
TOOLPREFIX=h8300-hms-
SED_SFLAG=i
endif
#
# 2001.01.16 - Paolo Masetti <paolo.masetti@itlug.org>
#
# - Added definition for Cygwin 1.1
#
# Cygwin 1.1
#
ifneq (,$(findstring $(OSTYPE),CYGWIN_NT-4.0 CYGWIN_NT-5.0 CYGWIN_NT-5.1))
TOOLPREFIX=h8300-hitachi-hms-
SED_SFLAG=i
endif
The ifneq checks here seem to overlap unnecessarily. The second ifneq check
will change TOOLPREFIX even though the first check already matched one of
the four strings checked in the second one. My OSTYPE is set to
CYGWIN_NT-5.0 because that's what uname returns on my PC. Can someone
either explain the reasoning behind the second check or get rid of it? The
first of the two TOOLPREFIX settings would work with the pre-built Hitachi
tools without requiring that they be renamed. The existing naming
discrepencies which exist between the pre-built Hitachi tools and a manual
build of the cross compiler should be rectified in the BrickOS makefiles.
3. The makefiles do not correctly determine a cygwin environment running on
Win98 (probably not Win95 and WinME also). On Win98 Rick Bonari reports
that uname returns CYGWIN-98-4.10. Attempting to follow the cygwin
installation instructions (which claim to work with Win9x) results in the
makefiles thinking it is a Linux configuration (with lots of problems as a
result). Additional OSTYPE strings need to be added to the makefiles.
4. The makefiles in the demo directories below the BrickOS root are written
in a manner which requires that they live below the BrickOS root (i.e., they
use relative paths to get to Makefile.common and for the system library and
include paths). A more flexible configuration would set BRICKOS_ROOT
(either via a line in the Makefile or as an external environment setting) to
the correct path and use $(BRICKOS_ROOT) instead of ../ or ../../ for all
the paths that refer to system stuff (Makefile.common, library, and include
paths). That way, users of BrickOS can model their own makefiles directly
after the demo makefiles even though their own code may reside in an
entirely different directory tree.
5. On a Win32 system with a cygwin install it is extremely easy to use
BrickOS without ever entering a unix shell. All that is required is putting
the cygwin bin directory on the PATH, along with the directory containing
the hitachi tools. Setting BRICKOS_ROOT as an environment variable at the
normal Win32 command prompt also simplifies things considerably. Setting
OSTYPE to cygwin32 also simplifies things (when running with the pre-built
Hitachi tools). Describing how to use BrickOS with cygwin but doing
everything at a standard command prompt would (imho) attract many more users
to BrickOS because it removes the Unix mystique.
6. From a BricxCC perspective, it would be extremely nice if the BrickOS
firmware would respond to some of the standard firmware op-codes (like Ping,
for instance). That would make it possible for BricxCC (without
modification) to search for and find an RCX with the BrickOS firmware
installed. The more op-codes BrickOS supports the more BricxCC can
immediately provide diagnostic interaction with an RCX running BrickOS.
Anyway, those are a few ideas/comments/suggestions from this happy BrickOS
user. Keep up the good work!
John Hansen
http://members.aol.com/johnbinder/bricxcc.htm
|
|
Message has 1 Reply:
 | | Re: BrickOS issues
|
| (...) The brickOS team thanks you for mentioning this. It is our goal to continue to simplify this experience. We always enjoy hearing that we are making progress. (...) We hear you and have addressed some of them... (...) This is intentional for (...) (22 years ago, 23-Oct-02, to lugnet.robotics.rcx.legos)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
