multitasking problem

Started by gvartani June 18, 2005
Yes, Com3 was the problem and it no longer is - thanks. I
successfully switched to Com1 while keeping both tasks running. I
was originally running Com3 at 1200 baud rate. However, my pulse
size from PulseOut is something I am re-calculating at each do-loop
in my control law every four seconds. It goes from max to min
allowable depending on how far off track my robot it. I am glad I
didn't have to use additional hardware to do this.
The only thing I need to do now is to have the GPS send wire
disconnected from pin2 every time I want to download a modified
version of the program to the chip.
- Gerald

--- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
> --- In basicx@basi..., "gvartani" <gvartani@c...> wrote:
> > I am using the routine provided by Basicx folks at the following
> > website:
> > It is called
> Unfortunately, that is a problem.
> The referenced code uses Com3 which uses a "software UART" (as
> opposed to Com1 which uses a hardware UART). All UARTs rely on
> precise timing in order to properly transmit and receive
> characters. Software UARTs, in particular, require that the
> processor be allowed to service interrupts regularly so that the
> software can sample the input line and change the output line at
> right times. Consequently, when you're using Com3 you can't
> any other operations that disable interrupts for more than about
> of the bit time. Many of the BasicX I/O routines that implement
> precise timing (e.g. PulseIn(), PulseOut(), etc.) disable
> in order to obtain the required precision.
> If you're running the port at 19,200 baud, one bit time is about
> 52uS. That means that you can't, for example, call PulseOut() to
> generate a pulse longer than about 12uS or you risk garbling the
> serial data coming or going. If you can do so, it would help to
> reduce the speed of COM3. At 1200 baud, for example, a bit time
> about 830uS. At that speed you could tolerate periods of 200uS or
> so with interrupts disabled.
> Depending on what else you're trying to do, you may be able to
> switch to Com1. Using the hardware UART still requires interrupts
> to be serviced but the processor only needs to service the
> UART for incoming characters every 10 bit times. Outgoing
> characters from a hardware UART will never be affected by having
> interrupts disabled.
> An alternate strategy is to off-load the pulse generation to
> external hardware. This can be done using a "one shot" like the
> 74HC123 or even the ubiquitous 555 timer. Depending on how
> the timing and width of your pulses must be and the minimum
> you may also be able to generate the required pulses in software
> using PutPin().
> Don