Searching \ for 'Debugging PIC'S ( one possible Solution !? )' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Debugging PIC'S ( one possible Solution !? )'.

Truncated match.
PICList Thread
'Debugging PIC'S ( one possible Solution !? )'
1999\03\24@114759 by Stefan Sczekalla-Waldschmidt

flavicon
face
Hi,

While wrinting the software for an PIC based speed-controller to control
a series-wound motor I did run into the problem :

        Hey, what is the controller doing now ??

My first Idea was to use some LED, later I wrote a "send-only-RS-232"
sub, for sending some Status to the PC.

The "send-only" approach become a problem when I started to use the
Timer interrupt for some cyclic events ( where RS-232 timing got upset )
in the PIC.

On the other hand - using Quick Basic I got problems with baudrates
higher than 9k6.

Here is how I soluted both problems.

Because of having enough pins left I decided to use a Maxim 3100
SPI <-> RS-232 Converter-UART. SPI needs up to 4 Pins.
With the PIC now I can send syncronous data to the MAX 3100 and the
transmission is interruptable.

As benefit, the MAX3100 can send easyly with upto 115.2 kBaud. But Here
starts the Problem with Quick Basic.

After doing some search I found two things.

a.)     fossil/qb - a quickbasic4.5 Library which allowes to access a
       fossil driver   API using quick-basic.

b. )    adf-14? - a fossil compatible driver which is Win95 aware and
       supports virtual ports with everything your com-hardware
       allowes.

while fossil/qb was written especially to be used with X00.sys -
a driver written by Ray Gewinn ( possibly type mismatch in name ), it
also runs with adf ( also sharware ) with minor flaws ( baudrate need
to be preset before executing and using of quickbasic ).

Now I can transmit status informations from PIC to PC and use
Quickbasic in a Win95 Dos-Session to do what I want with them.

At the moment I don't use any data transfer from PC -> PIC but this
should be no problem either.

Comments ?

Kind regards,

       Stefan Sczekalla-Waldschmidt
       spam_OUTsswTakeThisOuTspamoikossw.de

1999\03\24@130156 by Gerhard Fiedler

picon face
At 17:50 03/24/99 +0100, Stefan Sczekalla-Waldschmidt wrote:
>While wrinting the software for an PIC based speed-controller to control
>a series-wound motor I did run into the problem :
>
>         Hey, what is the controller doing now ??
>
>My first Idea was to use some LED, later I wrote a "send-only-RS-232"
>sub, for sending some Status to the PC.
[...]
>Now I can transmit status informations from PIC to PC and use
>Quickbasic in a Win95 Dos-Session to do what I want with them.

in the debugging phase i usually use plain (short) text and a terminal.
it's just easier and faster, and what i send out is not very well-defined,
it changes with the debugging needs.

ge

1999\03\25@021235 by w. v. ooijen / f. hanneman

picon face
My 16x84 prorammer can use the RB6 and RB7 pins (which are connected
to the programmer anyway) as serial in and out to the PC (which is
connected
serially to the programmer).
Wouter.

----------
{Quote hidden}

well-defined,
> it changes with the debugging needs.
>
> ge

1999\03\25@052302 by Stefan Sczekalla-Waldschmidt

flavicon
face
Gerhard Fiedler wrote:
>
> in the debugging phase i usually use plain (short) text and a terminal.
> it's just easier and faster, and what i send out is not very well-defined,
> it changes with the debugging needs.
>

The same here, but what if your data isn't plain ASCII and you like
to see the contents of some registers ?? The advantage is that I can
do some processing ( e.g. the conversion to ASCII ) to the data
I receive - and sending just one byte to the PC costs abt. 1605S @ 4MHz.

Using a synchronus protokoll has also the advantage that it could
be interrupted by the ISR without mixing up the timing.

Kind regards,

       Stefan

1999\03\25@151123 by John Payson

flavicon
face
|Using a synchronus protokoll has also the advantage that it could
|be interrupted by the ISR without mixing up the timing.

I often try to set my ISR's to reasonably nice data rates (remember
that the PC can be programmed for any baud rate 115200/n) and then
just clock out a bit on each interrupt.  Often my interrupt code
will look basically like this:

       bsf     OUTPUT
       btfss   shifter2,7
        bcf    OUTPUT
       bsf     C
       rrf     shifter1,f
       rrf     shifter2,f

To output a character, simply (with interrupts disabled) put the char-
acter into shifter1 and clear bit 7 of shifter2.  Note that you must
be careful to wait until all the data is sent before trying to send
the next character.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...