|
|
| |
Re: Power Functions:
There is an older thread on the topic of Power Functions at [
http://news.lugnet.com/general/?n=54443&t=i&v=a ] which includes links to
some BrickOS-based code for Power Functions. Be sure to follow the thread
to the end, as some of the links mentioned earlier on no longer work. The
current working link is [ http://www.bong69.com/pages/software.php ] (scroll
to the bottom of that page). Note that this code also disables/enables
interrupts.
Re: Interrupts
The LDCC patch, which Mark Riley wrote to output DCC waveforms over the
motor outputs, also disables interrupts, as DCC requires very precise
timings. Since creating the rollup release noted earlier [
http://news.lugnet.com/robotics/rcx/legos/?n=4057 ], which is itself based
on Jochen's Bibo release, I haven't tried running LDCC without disabling the
interrupts, but based on Jochen's description, I'll have to give that a try.
As a side note, LDCC has also been integrated into pbForth [
http://news.lugnet.com/robotics/rcx/?n=2297 ].
LDCC Links
* http://news.lugnet.com/org/ca/rtltoronto/?n=14996
* http://home.surewest.net/markril/lego/dcc/
Cheers,
Matthew
|
|
| |
I don't normally bump things, but this has been unanswered for over two weeks,
so I think it deserves it. I really can't believe that rotation sensors would be
this broken, and yet, I can't see anything wrong with my code. It really is
odd...
|
|
| |
Hello Yann,
2010/6/15 Yann Vernier <yann@algonet.se>:
>
> I've recently mucked about with the Power Functions protocol, and got a proof of
> concept running on the RCX using brickOS. The main problem is that it's quite
> timing sensitive, so this code only worked reliably with interrupts disabled
> (looking at the oscilloscope).
>
> The sample code is at http://www.algonet.se/~yann/powerfunctions.c
>
> The timing requirements are probably more lax in reality (PF protocol spec cites
> ranges like 316-526us for a 0 bit), but my code was thrown off by whole periods
> (of the 38kHz modulation signal) as other interrupts occurred.
I really would prefer to see the interrupt code running to disabling
all interrupts for several milliseconds, loosing several ticks and
disabling all sensors during this time.
Did you apply one of my performance patches to brickOS? IIRC, the
current release of brickOS still has a busy waiting loop in the sensor
interrupt, which explains why you get corrupt timings. The patches
are at
http://hoenicke.ath.cx/rcx/brickOS.html
You can also use my simulator brickemu to get some statistics about
maximal run-time of interrupts. It shouldn't be too difficult to add
debugging output to the 8-bit timer to get cycle exact information of
when the registers are set. You can also debug your code with
brickemu by adding printf in your code.
It looks hard to get the interrupts fast enough, though. According to
my statistics, the timer interrupt in bibo can take up to 1031 cycles,
i.e 65 us, which is still more than the period of your timer. On
average it runs in only half the time, so you should not loose so many
cycles that your signal is distorted beyond recognition.
Regards,
Jochen
|
|
| |
In lugnet.robotics.rcx.legos, Carl Troein wrote:
> Another thing: We should have a good asm implementation of the Power
> Functions protocol. I've ordered the Emerald Night collection so soon
> I'll have some power functions parts and a reason to control them
> with BrickOS. Hopefully that will lead to something.
I've recently mucked about with the Power Functions protocol, and got a proof of
concept running on the RCX using brickOS. The main problem is that it's quite
timing sensitive, so this code only worked reliably with interrupts disabled
(looking at the oscilloscope).
The sample code is at http://www.algonet.se/~yann/powerfunctions.c
The timing requirements are probably more lax in reality (PF protocol spec cites
ranges like 316-526us for a 0 bit), but my code was thrown off by whole periods
(of the 38kHz modulation signal) as other interrupts occurred.
|
|
| |
Hi,
I've tried using the latest BrickOS and the latest BIBO with patches (from here:
http://sourceforge.net/tracker/?func=detail&aid=2858992&group_id=58151&atid=486699
), both with the same result. I don't know if nobody's really used a rotation
sensor in 4 years (unlikely), or if my code just fails (likely), but every time
I run it, the kernel crashes when using the rotation sensor the SECOND TIME
AROUND (NOT THE FIRST TIME). The code in its entirety is posted below (it's for
a slightly modified version of the Plotter from the Ultimate Builders' Set):
#include <dmotor.h>
#include <dsensor.h>
#include <unistd.h>
#include <conio.h>
#include <lnp.h>
int charpos;
int line;
#define PAPER_WIDTH 10
#define PAPER_HEIGHT 13
void fosrotate(int drotations){ // Counts rotations using the Fibre Optic
System, which actually works rather well as a rotation sensor.
unsigned int rotations = 0;
while(rotations<drotations){
while(SENSOR_2!=0xFFC0){
}
rotations += 1;
while(SENSOR_2>0x9000){
}
rotations += 1;
}
}
void up(int x){ // Paper down x/16 teeth (no typo - pen goes up paper)
ds_rotation_on(&SENSOR_1);
ds_rotation_set(&SENSOR_1,0);
msleep(100);
motor_b_speed(MAX_SPEED);
motor_b_dir(rev);
while(ROTATION_1>-x){
msleep(100);
lcd_number(ROTATION_1,sign,e0);
}
motor_b_dir(brake);
ds_rotation_off(&SENSOR_1);
}
void down(int x){ // Paper up x/16 teeth (no typo - pen goes down paper)
ds_rotation_on(&SENSOR_1);
ds_rotation_set(&SENSOR_1,0);
msleep(100);
motor_b_speed(MAX_SPEED);
motor_b_dir(fwd);
while(ROTATION_1<x){
msleep(100);
lcd_number(ROTATION_1,sign,e0);
}
motor_b_dir(brake);
ds_rotation_off(&SENSOR_1);
}
void left(int x){ // Pen left x/16
motor_c_dir(rev);
fosrotate(x);
motor_c_dir(brake);
}
void right(int x){ // Pen right x/16 teeth
motor_c_dir(fwd);
fosrotate(x);
motor_c_dir(brake);
}
void pup(){
motor_a_dir(fwd);
sleep(7);
motor_a_dir(brake);
}
void pdown(){
motor_a_dir(rev);
sleep(12);
motor_a_dir(brake);
}
void cr(){
// Carriage to far left
motor_c_speed(MAX_SPEED);
motor_c_dir(rev);
msleep(500);
while(!TOUCH_3){
msleep(100);
}
// Carriage to print position (2 teeth right)
// motor_c_dir(fwd);
// fosrotate(32);
// motor_c_dir(brake);
right(32);
charpos = 0;
}
void lf(){
// Feed paper for a whole rotation of the output axle (24 * 16)
// ds_rotation_set(&SENSOR_1,0);
// ds_rotation_on(&SENSOR_1);
// motor_b_speed(MAX_SPEED);
// motor_b_dir(fwd);
// while(ROTATION_1<384){
// msleep(100);
// }
// motor_b_dir(brake);
down(100);
line += 1;
if(line > PAPER_HEIGHT){
cputc_native_user(CHAR_P, CHAR_C, CHAR_L, CHAR_A);
cputc_native_5(CHAR_4);
while(getchar() != KEY_VIEW){
}
line = 0;
lf();
}
}
void draw_a_letter(char letter){
if(letter == 10){ // LF
lf();
return;
}
if(letter == 13){ // CR
cr();
return;
}
if(letter == 'A'){
pdown();
down(80);
up(80);
right(40);
down(40);
left(50);
right(50);
down(40);
pup();
up(80);
right(10);
return;
}
}
void addr_handler_1(const unsigned char *data, unsigned char length, unsigned
char src)
{
int i;
for(i=0;i<length;++i){ // Print
draw_a_letter(data[i]);
}
}
int main(){
line = 0;
ds_active(&SENSOR_1);
ds_active(&SENSOR_2);
ds_passive(&SENSOR_3);
// Do initial Penup, CRLF
pup();
cr();
lf();
// Wait for message from PC
lnp_addressing_set_handler (0, addr_handler_1);
while(!shutdown_requested())
msleep(1000);
return 0;
}
I send the letter "A" from the computer and it receives fine. However, when
running the first down(80); instruction, the screen usually shows around 105
(note the lcd_number debug statements) and it completely freezes, with the motor
still running - only taking the battery out and redownloading the kernel will
get it back to normal. Note that this is the second time down(int x) has been
called - the initial CRLF (the LF in particular) calls down(100).
It seems to me that the code to set the rotation sensor's value to 0 doesn't
actually work, and instead freezes the kernel. Anyone else got any clues?
Thanks in advance for any help,
Muzer (Murray Colpman).
|
|
| |
Hello,
I have inherited a hand-me-down RIS kit with a functional RCX unit that
I would like to learn to use and put to a purpose.
I would like to build a system whereas the RCX is setup to press buttons
on controllers (think remote control units) to operate other devices.
I am completely new to mindstorms programming (this RIS kit was my first
exposure).
Other than the mechanical considerations, I and not sure how to proceed
with development on the software side.
I basically would like to the RCX to be in standby until it receives a
signal via the IR tower to "push button 1" which would cause the RCX to
go through the motions then wait for another command. Think a piano
keyboard with a RCX "crane" to find and press the different keys as
directed.
For my development environment, I am using Debian Etch which provides
pre-built packages for BrickOS and LNP. I was able to load th BrickOS
firmware and try out a few of the sample programs (hello world, bumper
robot) etc. These were helpful to determine if the RCX and other parts
were still functional but they are very trivial examples compared to
what I would like to accomplish.
Are there any existing BrickOS examples out there (links) to something
similar to what I would like to do that I can work from?
Also, would it be better to create simple RCX programs to do a
load-and-run operation for each individual button press operation or to
create a single master program that always lives on the RCX and waits
for keyword instructions via the IR tower.
Any suggestions, help, and pointers would be greatly appreciated. I
have found more dead web links than anything else trying to figure this
out on my own. It seems that 10 years is "before recorded history" on
the Internet, given the copyright date on the Mindstorms RIS box is 1998...
|
|
| |
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
|
|
|
