To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 644
643  |  645
Subject: 
Re: useful battery program
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Wed, 12 Jan 2000 02:11:19 GMT
Viewed: 
1185 times
  
In lugnet.robotics.rcx.legos, Markus L. Noga writes:
Ben Jackson schrieb:
Here's a short program to display the battery voltage.

I was thinking about a configuration option to change the view button's
function, too, make it more of a monitor of sensor data. This would fit
in nicely.

Yes, the current behavior of displaying the return address for the interrupt
handler isn't very useful.  :-)  I was considering making it display battery
voltage.  It would be neat if some combination of VIEW and other buttons could
be used to do basic things like select sensor type and display mode for quick
debugging.

While writing this it occured to me that cls() would be more useful if it • also
cleared the dots in the number output area.  Does that sound like a good • idea?
I can submit the trivial diff if so...

Hmmm. Not sure. I had intended the text area to be available for user
programs while they run, so cls just clears that. lcd_clear() should be
used by the kernel to clear everything. I tend to think of the graphical
symbols as permanent or independent status displays.

I'm taking about the decimal points in the "text" area.  My battery program
uses dlcd_show(LCD_3_DOT) to make `8.7v'.  If you just hit RUN to stop it, you
end up with 'ST.OP' in the text area.  I think the decimal points should be
considered part of the text area.  I was wondering if cputs("9.6v") should
actually *use* them, but then cputs doesn't have a 1:1 mapping of input
character to output LCD digit.

A lot of people seem to need printf these days... I thought networking
and especially lnpd would alleviate the five-character situation
somewhat. A printf of less than 500 bytes code would be a nice
configuration option, I think, but anything larger is probably more of a
burden.

printf to conio or just for networking?  I've been thinking about writing
myself a library to display longer messages in the text area.  So something
like cputs("put\nme\ndown") cycles through cputs("put") cputs("me")
cputs("down") once a second.

Meanwhile I'm looking for lnpd to see if I can log some data for a program I'm
working on...

--Ben



Message has 1 Reply:
  Re: useful battery program
 
Ben Jackson schrieb: (...) Saved my life a couple of times, when LNP was locking up the system in an entirely incomprehensible way. (I'd really appreciate "Unreachable code" warnings sometimes... or maybe they scrolled away.) (...) How about this: a (...) (25 years ago, 12-Jan-00, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  Re: useful battery program
 
Ben Jackson schrieb: (...) Yes, this is a good idea. The system timer handler will probably become a C routine, anyway, as it does so many things now. It might as well check for low battery power and display it. I was thinking about a configuration (...) (25 years ago, 12-Jan-00, to lugnet.robotics.rcx.legos)

4 Messages in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR