To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.handyboardOpen lugnet.robotics.handyboard in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Handy Board / 7017
7016  |  7018
Subject: 
Re: Time available during 1 kHz system interrupt?
Newsgroups: 
lugnet.robotics.handyboard
Date: 
Tue, 2 Nov 1999 17:15:37 GMT
Original-From: 
Christopher Prosser <cprosser@#nomorespam#acm.org>
Viewed: 
3381 times
  
The controls are spread across a couple of files, mainly in libhb.c we get

/*
  pulse width modulation control:
  if off, all motors run at full speed
  if on,  speed bytes are used to determine motor speed
*/
void system_pwm_on() {bit_set(0x39, 0b00000100);}
void system_pwm_off() {bit_clear(0x39, 0b00000100);}

/*
  printing to the LCD
  WARNING:  printf's will wedge once the print buffer becomes full
    if system printing is disabled  */
void system_print_on() {bit_set(0x39, 0b00000001);}
void system_print_off() {bit_clear(0x39, 0b00000001);}


in r22_ir.c
void ir_transmit_on();
void ir_transmit_off();
void ir_receive_off();
void ir_receive_on();

encoders.c enables and disables encodes.

Note: I'm not sure if these completely disable the code at the asm level.

In regards to what happens if you exceed 1ms, the pcode.asm has the
following comment:
System interrupt performs the following tasks:
*
*     0.  sets up for next interrupt
*     1.  increment system time
*     2.  decrement "process_ticks".  If zero, pokes
*  BRN (branch never) into pcode_run loop, so that
*  current process exits.
*     3.  deals with LCD print.
*     4.  does PWM stuff.
*     5.  does shaft encoder stuff.

A quick read of pcode.asm dictates that memory location 0x39 is a set of bit
flags for all the functions you can control. bit_clear(0x39, 0x00) will turn
everything off. Here are the bit definitions

PRINTBUFFER EQU %00000001
IRDECODE EQU %00000010
PWM  EQU %00000100
SHAFTENCODER EQU %00001000


-chris

----- Original Message -----
From: Bruce Moore <bamoore@bloomington.in.us>
To: <handyboard@media.mit.edu>
Sent: Tuesday, November 02, 1999 4:47 AM
Subject: Re: Time available during 1 kHz system interrupt?


> Interesting discussion but it raises a few more questions.
> 
> Are there any (bad) side effects when user code that is inserted in the • ISR
> takes longer to execute than the 1 msec interrupt cycle.  From experience
> it appears that the ISR runs on the next interrupt following the • completion
> of the current cycle.  The only thing I noticed is that the PWM routines
> don't always calculate their next transition correctly but i figure that
> there are plenty of other things that are going on that I'm not watching
> (and that may eventually bite me).
> 
> Chris:  How do you turn off the things like IR and quad shaft decoding to
> get rid of the little overhead.
> 
> 
> ----------
> > From: Christopher Prosser <cprosser@acm.org>
> > To: Greg Starr <starr@unm.edu>; handyboard@media.mit.edu
> > Subject: Re: Time available during 1 kHz system interrupt?
> > Date: Monday, November 01, 1999 8:48 PM
> > 
> > Hi Greg,
> >   It all depends. Various features of the HB can be turned on and off to
> > change the amount of work done in the main ISR. By default the code uses
> > 300ms to execute. The file lib_hb.c provides the following:
> > 
> > /********************************/
> > /*** System Interrupt Control ***/
> > /********************************/
> > 
> > /*
> > 
> >     These functions allow you to turn on and off various features
> >     controlled by the system interrupt routines.  The more features
> >     you turn off, the faster your code will run.
> > 
> >     On reset, the features have the following state:
> >        pulse width modulation ON
> >        infrared decoding      ON
> >        LCD printing           ON
> >        quad shaft decoding    OFF
> >        IR tranmission       OFF
> > 
> >     This uses approx. 30% of total CPU time.
> > 
> >     Approximate benchmarks:
> > 
> > x    Feature  % of CPU
> >     -------  --------
> >     PWM       3
> >     IR decode     11
> >     LCD printing (active)   8
> >     LCD printing (inactive) 1
> >     quad shaft decode     5
> >     IR transmission     1
> > 
> > */
> > 
> > 
> > 
> > -chris prosser
> > 
> > 
> > ----- Original Message -----
> > From: Greg Starr <starr@unm.edu>
> > To: <handyboard@media.mit.edu>
> > Sent: Monday, November 01, 1999 7:19 AM
> > Subject: Time available during 1 kHz system interrupt?
> > 
> > 
> > > Does anyone know the approximate amount of time available for user
> > > assembler programs which "add on" to the existing 1 kHz HB interrupt?
> > > 
> > > Another way of stating that is...how much time is used by the 1kHz HB • ISR
> > code?
> > > 
> > > --greg
> > > 
> > > *****************************************************************
> > > * Greg Starr, Professor                                         *
> > > * Department of Mechanical Engineering        ph (505) 277-6298 *
> > > * University of New Mexico, Albuquerque NM 87131   FAX 277-1571 *
> > > * email- starr@unm.edu  WWW- http://www.me.unm.edu/~starr/      *
> > > *****************************************************************
> > > 
> > > 
> 



Message is in Reply To:
  Re: Time available during 1 kHz system interrupt?
 
Interesting discussion but it raises a few more questions. Are there any (bad) side effects when user code that is inserted in the ISR takes longer to execute than the 1 msec interrupt cycle. From experience it appears that the ISR runs on the next (...) (27 years ago, 2-Nov-99, to lugnet.robotics.handyboard)

3 Messages in This Thread:


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

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