Searching \ for 'flow' 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/index.htm?key=flow
Search entire site for: 'flow'.

No exact or substring matches. trying for part
PICList Thread
'Check for page overflow (was Re: Dealing with 16C5'
1996\10\02@211407 by Steve Hardy

flavicon
face
> From: Ray Gardiner <spam_OUTrayTakeThisOuTspamNETSPACE.NET.AU>
>
> [cut]
> 3. I have found that it pays to ALWAYS inspect the *.LST output
>    from the assembler to check for page crossing on tables etc.
> [cut]

One can automate this inspection by using the 'error' directive e.g.
my favourite technique goes like this:


PAGESIZE equ    100h            ; Page size for the processor
PAGEMASK equ    10000h-PAGESIZE ; Mask for address bits which indicate page

; Define a few macros...
table   macro   reg
       movlw   high ($+4)
       movwf   pclath
       movf    reg,w
       addwf   pcl,f
first   =       $
       endm

endtab  macro
       if      (($-1) & PAGEMASK) != (first & PAGEMASK)
       error   'Table page boundary overflow'
       endif

; Now use the macros in open code...
       movlw   1
       movwf   jumpindex
       call    foobar
       ...
foobar  table   jumpindex       ; jumpindex reg contains a value 0, 1, 2 etc.
       dt      4,2,77,4,5      ; The table entries (as retlw's etc)
       endtab



The endtab macro ensures that the actual table does not cross a page
boundary.  If it does, your assembly fails and you can manually resolve
the problem by shifting the table to another location.

As shown, the above works for the 16CXX devices with which I am very familiar.
The 16C5X parts may require additional restrictions which should be codified
in the macros.

Regards,
SJH
Canberra, Australia

1996\10\02@213304 by fastfwd

face
flavicon
face
Steve Hardy <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> One can automate this inspection by using the 'error' directive
> ....
> The endtab macro ensures that the actual table does not cross a page
> boundary.  If it does, your assembly fails and you can manually
> resolve the problem by shifting the table to another location.

Steve:

You can take the process one step further with a WHILE in your
start-of-table macro that automatically inserts NOPs until the
table-start address and table-end address are on the same page... No
manual intervention necessary (unless you run out of code-space and
need to re-order your subroutines or whatever).

-Andy

Andrew Warren - fastfwdspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499


'stack overflow error in MpLab'
1997\05\05@041114 by FrankT
picon face
For those guys who followed my story on the interrupt problems I had,
here's the next chapter.
After a few mails to the piclist and some great help I came up with the
next piece of code.

void __INT(void)
{
       if(PIR1.SSPIF)
       {
               PIR1.SSPIF = FALSE;             // Clear I2C interrupt flag
               INTCON.GIE = FALSE;             // Global interrupt enabled
               save_context;
               I2C_InterruptServiceRoutine();  // decode I2C message
Transmit or receive
               restore_context;
               INTCON.GIE = TRUE;              // Global interrupt enabled

       }
       else if(PIR1.CCP1IF)
       {
               PIR1.CCP1IF = FALSE;            // Clear compare interrupt
flag
               INTCON.GIE = FALSE;             // Global interrupt
disabled
               save_context;
               if (DBS_LaserMode == LAS_MAIN_ON_STATE) // switch of/on
pulse generation
               {
                       LaserFreqOut = ~LaserFreqOut;           // PULSE
GENERATION
               }
               restore_context;
               INTCON.GIE = TRUE;              // Global interrupt enabled

       }
       else if(INTCON.T0IF)
       {
               INTCON.T0IF = FALSE;
               INTCON.GIE = FALSE;             // Global interrupt
disabled
               save_context;
               TMR_InterruptServiceRoutine();  // SYSTEM TIMER
               restore_context;
               INTCON.GIE = TRUE;              // Global interrupt enabled
       }
       return;
}

The problem now is that I receive a Stack overflow error from Mplab when
the timer is generating very fast interrupts, generating pulses from 2kHz
works fine. Once I increase the value the Stack overflow error is displayed



Frank Temmerman

__________________________________________________________________
One fool can ask more questions than all the scientists in teh world can
answer
__________________________________________________________________

1997\05\05@044508 by tjaart

flavicon
face
FrankT wrote:
>
> For those guys who followed my story on the interrupt problems I had,
> here's the next chapter.
> After a few mails to the piclist and some great help I came up with the
> next piece of code.
>
> void __INT(void)
> {
>         if(PIR1.SSPIF)
>         {
>                 PIR1.SSPIF = FALSE;             // Clear I2C interrupt flag

You must save the context (W, Status, and a wealth of other mysterious
MPLABC
variables) first. Here you are going to run into trouble. The include
files for
the various parts in MPLABC do not all contain context saving code. You
cannot
(probably cannot) do this yourself because you don't know how the
compiler uses
these variables.

I ran into this problem with the '74. The support I received from
Microchip stank.
I mailed every Mchip guy from my distributor to every FAE I could find,
but have
still not received ANY constructive feedback after 8 months. What I did
receive was
a whole lot of rethoric about Mchip policy to not update their software
products too
often. They claim the customers would rather sit with malfunctioning
software than
download updates all the time. Geez, don't you just hate PR?

I received a working header file from a guy (not connected to Mchip) on
this list,
but had to promise him I wouldn't mail it to the list or mention his
name. I will
respect that.

What I can suggest, is that you mail a request for a header file with a
working
version of the context saving for your PIC to this list. I'm sure the
Good Samaritan
who helped me will also help you.

If you still don't get help, I will mail him a request on your behalf.

For any prospecting MPLABC buyers out there, I have this piece of advice
:
*****************************************************************************
*** Don't buy MPLABC until Microchip has the competency to offer
support  ***
*****************************************************************************

This may take until next millenium by the looks of it. :(

--
Friendly Regards

Tjaart van der Walt
.....tjaartKILLspamspam.....wasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\05\05@074928 by Andrew Warren
face
flavicon
face
FrankT <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

{Quote hidden}

Frank:

You need to do a few things here...

First, the "save_context code must be THE VERY FIRST thing you do,
right at the start of the __INT() functionm, and the
"restore_context"code must be the very LAST thing you do, just
before the "return".

You didn't mention hether you were using MPC, MPLAB-C, or some other
compiler; some compilers will automatically generate the save/restore
code for you if they know that you're writing an interrupt-service
routine (and they'll also ensure that the "return" is properly
compiled to a "RETFIE" instruction, not a "RETURN").

Second, there's no need for the "INTCON.GIE = FALSE" instructions;
the GIE bit is cleared automatically by the PIC's interrupt hardware.

Third, you MUST NOT set the GIE bit to TRUE within your interrupt
routine; that's what's causing your stack overflow errors.  The
"RETFIE" at the end of your routine will automatically set the GIE
bit true when it returns to your main code.

Other than those three things, your code is fine.

-Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\05\06@122547 by Vishram sarurkar

flavicon
face
On Mon, 5 May 1997, FrankT wrote:
> __________________________________________________________________
> One fool can ask more questions than all the scientists in teh world can
> answer
> __________________________________________________________________
>

Wow !!!! if he can ask so many questions then, i must say he's a genius
not a fool !!!

regards...
vishram.
               +------------------------------------------+
               |            Vishram A. Sarurkar           |
               |           ^^^^^^^^^^^^^^^^^^^^^          |
               |     another hobbyist turned researcher   |
               |   slogging @ Indian Institute of Science |
               |               -----------                |
               |    e-mail:@spam@vishKILLspamspamisu.iisc.ernet.in.        |
               |    Phone:+91 (080) 3092487.              |
               +------------------------------------------+


'PID Temperature Controller for SMD reflow oven'
1997\09\01@134434 by David W. Duley
picon face
In a message dated 97-08-30 08:57:16 EDT, you write:

<<
Hi,

I'm investigating using a cheap toaster oven as a SMD reflow oven
for prototype boards.

The idea is to use a PIC in provide an accurate temperature controller,
possibly providing a programmable temperature profile capability.

Does anybody have any pointers to examples of PICs being used to
accurately measure temperatures in the range 200 - 300 degrees C.

Initially I plan to use the PIC as a temperature switch. ie; turn
off the heater element once a preset temperature is reached.

The 2nd phase is to actully control the temperature via a PID
control system. This should allow for the temperature profiling
feature.

If I get is to work, then it should be a useful project for quite a
few piclist subscribers.

Thanks,

Peter. >>
Peter,
Having been down this road many times,  It is never cost effective to build
your own setpoint controller.  Omega has single setpoint controllers that
will accept many different types of input (RTD, many thermocouple types
etc...).  All you will have to add is a large solid state relay to switch
power to the elements.
Omega carries them for around $100.  I don't know about you but I would have
a hard time developing one for less.

Dave Duley
V.P. DreiTek Inc.

1997\09\02@125709 by lilel

flavicon
face
> From:   Peter Homann[SMTP:KILLspampeterhKILLspamspamADACEL.COM.AU]

> I'm investigating using a cheap toaster oven as a SMD reflow oven
> for prototype boards.
>
> The idea is to use a PIC in provide an accurate temperature
> controller, possibly providing a programmable temperature profile
> capability.

I just designed a new toaster oven with a PIC at the heart of the
controller.  The requirement was for cheap, not for accurate, so I
cut a lot of corners on accuracy.    All the PIC is really doing is
analog comparing the thermistor voltage to a potentiometer voltage.

However, using a simple thermistor for feedback gives about +/- 5 C
temperature control, with a very simple non-PID control algorithm.
That's probably as good as you'll need.

I used a 16C620 and two of the analog comparators.  One analog
comparator is hooked to a FENWALL GEC series glass body thermistor,
400Kohms cold.  This thermistor is in parallel with a  68K resistor
which gioves a more linear response.  The FENWALL GEC series is good
to about 300 C, plenty for soldering.   I read the comparator once a
second and let it decide whether to turn on the elements.

You'll want more sophistication if you're doing ramping and PID.

You don't have to read the actual cavity temperature either.
Position the thermistor about 1/2 cm away from one of the interior
metal walls of the toaster oven.  It will read a lower temperature
than the interior, but will track very consistently and respond very
quickly.  This trick works for thermistors of lower temperature
ratings.

Don't bother trying to use a thermocouple unless you need +/- 4C
accuracy and are willing to spend $30 US to get it.

To implement real PID you'd need to go up to one of the parts that
have a real analog input

Let me know how you progress!

-- Lawrence Lile

Download AutoCad blocks for electrical drafting at:
http://members.sockets.net/~llile/index.htm

1997\09\02@132138 by lilel

flavicon
face
>
>  I'm investigating using a cheap toaster oven as a SMD reflow oven
>  for prototype boards.

> Peter,
> Having been down this road many times,  It is never cost effective
> to build your own setpoint controller.

Correct.  It is only worth it to design your own setpoint controller
if you want to learn more about PICS by doing so, or if you are
designing something that will be used over and over, or if you have
lots of time and don't have $100.

Info on Fenwall Thermistors can be obtained from

Fenwall Electronics
450 Fortune Boulevard
Milford MA  01757-1745 USA
508-478-6000 voice

I don't know a URL.


-- Lawrence Lile

Download AutoCad blocks for electrical drafting at:
http://members.sockets.net/~llile/index.htm

'PID Temperature Controller for SMD reflow oven and'
1997\09\02@135938 by Pioneer Microsystems

flavicon
face
Lawrence Lile wrote:

> > From:   Peter Homann[SMTP:RemoveMEpeterhTakeThisOuTspamADACEL.COM.AU]
>
> > I'm investigating using a cheap toaster oven as a SMD reflow oven
> > for prototype boards.
> >
> > The idea is to use a PIC in provide an accurate temperature
> > controller, possibly providing a programmable temperature profile
> > capability.
>
> I just designed a new toaster oven with a PIC at the heart of the
> controller.  The requirement was for cheap, not for accurate, so I
> cut a lot of corners on accuracy.    All the PIC is really doing is
> analog comparing the thermistor voltage to a potentiometer voltage.
> etcettera..

Lawrence! I am truly impressed with the toaster! Does Microchip know
that you ripped off their ultimate design that they had in that ad
campaign for a while?  Just joking.. everything should have a PIC in
it.  I haven't figured out how to get them into common hand tools yet..

Back on PID, I have just finished a motor speed controller using PID and
PWM on a '73.  It was a little squirley for a while, but worked out in
the end.  Post script, I bought one of the books that Andrew suggested a
while back, "Controller tuning and control loop performance' by David W.
St. Clair, 302-731-4699.  Andy truly uncovered a jewel, this book has
nothing on programming it, but getting PID to work in the field might be
described as black majic sometimes, and this book puts it all in
practical measurable terms.

But back on programmin PID, I managed to stay in the 8 bit domain, by
reading motor voltage and command setting, taking the difference for
error, and driving a single ended switch circuit with the PWM output.  I
implemented P, I, PI, and ramp limit (accel decel limit).  I didn't do D
term, as it is rarely needed or used.  The terms are, in the briefest of
review,

P term: the product of the error and a constant:  Use a pot on an input
to allow adjustment.  P term has no internal knowledge of the last
state, and makes it's output calculation based upon each new pass.  If
the loop gain reaches or exceeds 1, the output device will oscillate.
For this reason, the gain must be reduced to a marginal value.  P term
is conceptually incapable of reaching the setpoint, steady state, as if
you ever reached it, the error is zero, and suddenly the output is back
to zero.  It can only ever achieve a percentage, say 80%, of the true
setpoint ( and still be stable).  Just a side note, since I didn't use a
full bridge, and thus didn't use signed math, when the error goes
nagative (indicating slow down) I could do no more than slam to 0 for a
while and let inertia pull the spped down.  True high spped servo
controllers are going to use the full bridge and signed word math.

I term: The I term is a memory function.  I is for integral and as
predicted it integrates the error.  The longer the error is large, the
harder the I term acts to counter the error.  I prefer to think of the
term as the seek term.  Many books have complex units that indicate a
reset time, etc., but I simplify by using TMR0 to count off a time
period, which is pot adjustable, and when the timer kicks it off, you
execute the addition or subtraction of some constant.  I is nice, as you
can achiev your true setpoint within a fine error.  The drawback is that
it will windup, a case where an error will build up an extra output
effort, but when the disturbance passes, the device tends to surge
forward ( or temp peaks hard, or whatever).  My client seemed to
associate this term with torque (I dunno) because if he held the shaft,
it fought to overcome the disturbance.  He liked that.

PI: It is best to combine PI, as I implemented it you just add the two
terms.  For tuning the system properly, I refer you to the book above.
This tends to combine the best features of all of the terms above.

My customer wanted a rate of change limit.  Take care to apply the limit
at the right point in the software.  If you limit the final command
value going to the PWM register, then the I term goes nuts while the
thing is coming up to speed.  It wasn't pretty.  Limit the ramp or rate
of change to the command input.  For any step change, let the internal
command register bleed up or down to the actual conmmand value.  This
way the PID loop can achieve the true speed all of the way along the
ramp.

I cannot post the code, as it belongs to my customer now.  But there is
my two cents, if anyone wants to try out any of my approaches, just mail
private and I can impart the finer details.  Or mail public if you think
people may benefit.

Chris Eddy
Pioneer Microsystems, Inc
Pittsburgh, PA 15106
http://www.nb.net/~ceddy

1997\09\02@143124 by Martin R. Green

picon face
OK, I finally have to ask...

What's PID?

Ignorantly yours,
Martin R. Green
spamBeGoneelimarspamBeGonespambigfoot.com

----------
From:   Lawrence Lile[SMTP:TakeThisOuTlilelEraseMEspamspam_OUTtoastmaster.com]
Sent:   Tuesday, September 02, 1997 7:53 AM
To:     RemoveMEPICLISTspamTakeThisOuTmitvma.mit.edu
Subject:        Re: PID Temperature Controller for SMD reflow oven

> From:   Peter Homann[SMTP:peterhEraseMEspam.....ADACEL.COM.AU]

> I'm investigating using a cheap toaster oven as a SMD reflow oven
> for prototype boards.
>
> The idea is to use a PIC in provide an accurate temperature
> controller, possibly providing a programmable temperature profile
> capability.

I just designed a new toaster oven with a PIC at the heart of the
controller.  The requirement was for cheap, not for accurate, so I
cut a lot of corners on accuracy.    All the PIC is really doing is
analog comparing the thermistor voltage to a potentiometer voltage.

However, using a simple thermistor for feedback gives about +/- 5 C
temperature control, with a very simple non-PID control algorithm.
That's probably as good as you'll need.

I used a 16C620 and two of the analog comparators.  One analog
comparator is hooked to a FENWALL GEC series glass body thermistor,
400Kohms cold.  This thermistor is in parallel with a  68K resistor
which gioves a more linear response.  The FENWALL GEC series is good
to about 300 C, plenty for soldering.   I read the comparator once a
second and let it decide whether to turn on the elements.

You'll want more sophistication if you're doing ramping and PID.

You don't have to read the actual cavity temperature either.
Position the thermistor about 1/2 cm away from one of the interior
metal walls of the toaster oven.  It will read a lower temperature
than the interior, but will track very consistently and respond very
quickly.  This trick works for thermistors of lower temperature
ratings.

Don't bother trying to use a thermocouple unless you need +/- 4C
accuracy and are willing to spend $30 US to get it.

To implement real PID you'd need to go up to one of the parts that
have a real analog input

Let me know how you progress!

-- Lawrence Lile

Download AutoCad blocks for electrical drafting at:
http://members.sockets.net/~llile/index.htm

1997\09\03@170518 by Eric van Es

flavicon
face
Pioneer Microsystems wrote:

>I implemented P, I, PI, and ramp limit (accel decel limit).  I didn't do D
> term, as it is rarely needed or used.  The terms are, in the briefest of
> review,
>
>
> I term: The I term is a memory function.  I is for integral and as
> predicted it integrates the error.  The longer the error is large, the
> harder the I term acts to counter the error.  I prefer to think of the
> term as the seek term.  Many books have complex units that indicate a
> reset time, etc., but I simplify by using TMR0 to count off a time
> period, which is pot adjustable, and when the timer kicks it off, you
> execute the addition or subtraction of some constant.  I is nice, as you
> can achiev your true setpoint within a fine error.  The drawback is that
> it will windup, a case where an error will build up an extra output
> effort, but when the disturbance passes, the device tends to surge
> forward ( or temp peaks hard, or whatever).  My client seemed to
> associate this term with torque (I dunno) because if he held the shaft,
> it fought to overcome the disturbance.  He liked that.
>From what I know from my control systems knowledge (very fresh - one of
my current subjects), one should be wary of the Integral control. It
tends to become unstable.
Advantages: Increases the systems type number - thus removing
steady-state error.
>
> PI: It is best to combine PI, as I implemented it you just add the two
> terms.  For tuning the system properly, I refer you to the book above.
> This tends to combine the best features of all of the terms above.
"PI" gives you what "I" gives you, but with (much?) better stability.
>
> Chris Eddy
> Pioneer Microsystems, Inc
> Pittsburgh, PA 15106
> http://www.nb.net/~ceddy

--
Eric van Es               | Cape Town, South Africa
EraseMEvanesspamilink.nis.za | http://www.nis.za/~vanes
LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
http://www.nis.za/~vanes/accom.htm

1997\09\03@170527 by Eric van Es

flavicon
face
Martin R. Green wrote:
>
> OK, I finally have to ask...
>
> What's PID?
>
> Ignorantly yours,
> Martin R. Green
> RemoveMEelimarEraseMEspamEraseMEbigfoot.com
>
Wow! Big thing to explain!

What it is: A summing amp (if you like) with and proportional, integral
and derivative input. It adds them to obtain the desired effect.

Note: PID is feedback control! It is a controller that conditions your
input to the plant, moter, etc.

P: Output is proportional to the input. Basically an amplifier.
I: Integrates the output of the system's error and applies a signal that
will (theoretically) remedy this.
D: Output is proportional to the rate of change of the error on the
output of the system.

This really is a major field of study - actually impossible to explain
by e-mail! Maybe you could take a short course on control systems!

Sorry I can't help more! AND I stand corrected on all of the above!
--
Eric van Es               | Cape Town, South Africa
RemoveMEvanesspam_OUTspamKILLspamilink.nis.za | http://www.nis.za/~vanes
LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
http://www.nis.za/~vanes/accom.htm

1997\09\04@003805 by tjaart

flavicon
face
Eric van Es wrote:
>
> Wow! Big thing to explain!
>
> What it is: A summing amp (if you like) with and proportional, integral
> and derivative input. It adds them to obtain the desired effect.
>
> Note: PID is feedback control! It is a controller that conditions your
> input to the plant, moter, etc.
>
> P: Output is proportional to the input. Basically an amplifier.
I'm sure you mean 'proportional to the error' ?

> I: Integrates the output of the system's error and applies a signal that
> will (theoretically) remedy this.
> D: Output is proportional to the rate of change of the error on the
> output of the system.

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartTakeThisOuTspamspamwasp.co.za
________________________________________________________
|        WASP International   http://wasp.co.za          |
|   R&D Engineer : GSM peripheral services development   |
|Vehicle tracking | Telemetry systems | GSM data transfer|
|Voice : +27-(0)11-622-8686  |  Fax : +27-(0)11-622-8973 |
|             WGS-84 : 26010.52'S 28006.19'E             |
|________________________________________________________|

1997\09\04@013009 by Peter Homann

picon face
Eric van Es wrote:
{Quote hidden}

Have a look at these 2 articles. They give a very good intro discription
of analog and digital PIDs.

http://www.mcjournal.com/main/back/tutorial.htm

http://www.mcjournal.com/main/tutser2.htm


Enjoy.


Peter.
--
Peter Homann   email: RemoveMEpeterhKILLspamspamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925
http://www.adacel.com.au     Australian Software Engineering Excellence

1997\09\04@094111 by Martin R. Green

picon face
Thanks for the reply, I had begun to figure this out from the thread.  I
can see how this would be useful anywhere there is a response time lag,
such as in motion control, due to inertia, and in temperature control, due
to the time required for the temperature to respond to heat input.  I guess
anywhere you would like the controlled system to respond quickly when there
is a gross error, and more gently as the error difference narrows.

Again, thanks for the response.  I found the thread very interesting, but
that TLA was bugging me.


CIAO - Martin R. Green
elimarSTOPspamspamspam_OUTbigfoot.com

----------
From:   Eric van Es[SMTP:spamBeGonevanesSTOPspamspamEraseMEILINK.NIS.ZA]
Sent:   Wednesday, September 03, 1997 3:56 PM
To:     KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU
Subject:        Re: PID Temperature Controller for SMD reflow oven

Martin R. Green wrote:
>
> OK, I finally have to ask...
>
> What's PID?
>
> Ignorantly yours,
> Martin R. Green
> EraseMEelimarspamEraseMEbigfoot.com
>
Wow! Big thing to explain!

What it is: A summing amp (if you like) with and proportional, integral
and derivative input. It adds them to obtain the desired effect.

Note: PID is feedback control! It is a controller that conditions your
input to the plant, moter, etc.

P: Output is proportional to the input. Basically an amplifier.
I: Integrates the output of the system's error and applies a signal that
will (theoretically) remedy this.
D: Output is proportional to the rate of change of the error on the
output of the system.

This really is a major field of study - actually impossible to explain
by e-mail! Maybe you could take a short course on control systems!

Sorry I can't help more! AND I stand corrected on all of the above!
--
Eric van Es               | Cape Town, South Africa
@spam@vanes@spam@spamspam_OUTilink.nis.za | http://www.nis.za/~vanes
LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
http://www.nis.za/~vanes/accom.htm

1997\09\04@123559 by Engineering Department

flavicon
face
< From: Peter Homann >
<Snip>
> Have a look at these 2 articles. They give a very good intro discription
> of analog and digital PIDs.
>
> http://www.mcjournal.com/main/back/tutorial.htm
>
> http://www.mcjournal.com/main/tutser2.htm

Alas, these are password protected URLs.
Without the password they're not accessable.

Cheers,

Win Wiencke
Image Logic Corporation

1997\09\04@124228 by Sean Breheny

face picon face
At 12:24 PM 9/4/97 -0400, you wrote:
>< From: Peter Homann >
><Snip>
>> Have a look at these 2 articles. They give a very good intro discription
>> of analog and digital PIDs.
>>
>> www.mcjournal.com/main/back/tutorial.htm
>>
>> http://www.mcjournal.com/main/tutser2.htm
>
>Alas, these are password protected URLs.
>Without the password they're not accessable.
>
>Cheers,
>
>Win Wiencke
>Image Logic Corporation
>

Not only are they password protected, but if you go to http://www.mcjournal.com
and register for a username and password, it then gives you the error "401
URL not Found" on both of these URLS, even with a valid username and password.

Sean

Sean Breheny,KA3YXM
Electrical Engineering Student

1997\09\04@183051 by Matt Bonner

flavicon
face
Sean Breheny wrote:
>
> >> www.mcjournal.com/main/back/tutorial.htm
> >> http://www.mcjournal.com/main/tutser2.htm
> >
> >Alas, these are password protected URLs.
> >Without the password they're not accessable.
> Not only are they password protected, but if you go to http://www.mcjournal.com
> and register for a username and password, it then gives you the error "401
> URL not Found" on both of these URLS, even with a valid username and password.
I didn't have a problem.  Try hitting "register" from
       http://www.mcjournal.com/index.html
--Matt

1997\09\04@195852 by Sean Breheny

face picon face
At 04:23 PM 9/4/97 -0600, you wrote:
>Sean Breheny wrote:
>>
>> >> www.mcjournal.com/main/back/tutorial.htm
>> >> http://www.mcjournal.com/main/tutser2.htm
>> >
>> >Alas, these are password protected URLs.
>> >Without the password they're not accessable.
>> Not only are they password protected, but if you go to http://www.mcjournal.com
>> and register for a username and password, it then gives you the error "401
>> URL not Found" on both of these URLS, even with a valid username and
password.
>I didn't have a problem.  Try hitting "register" from
>        http://www.mcjournal.com/index.html
>--Matt
>

That's odd, now I try them and the second one works but not the first. I
got my password from register in the first place.

Sean

Sean Breheny,KA3YXM
Electrical Engineering Student

1997\09\04@211635 by Martin R. Green

picon face
Try http://www.mcjournal.com/main/back1/tutorial.htm.  they seem to be moving
stuff about at will.


CIAO - Martin R. Green
spamBeGoneelimarspamKILLspambigfoot.com


----------
From:   Sean Breheny[SMTP:.....shb7spam_OUTspamCORNELL.EDU]
Sent:   Thursday, September 04, 1997 7:57 PM
To:     TakeThisOuTPICLIST.....spamTakeThisOuTmitvma.mit.edu
Subject:        Re: PID Temperature Controller for SMD reflow oven

At 04:23 PM 9/4/97 -0600, you wrote:
>Sean Breheny wrote:
>>
>> >> www.mcjournal.com/main/back/tutorial.htm
>> >> http://www.mcjournal.com/main/tutser2.htm
>> >
>> >Alas, these are password protected URLs.
>> >Without the password they're not accessable.
>> Not only are they password protected, but if you go to http://www.mcjournal.com
>> and register for a username and password, it then gives you the error "401
>> URL not Found" on both of these URLS, even with a valid username and
password.
>I didn't have a problem.  Try hitting "register" from
>        http://www.mcjournal.com/index.html
>--Matt
>

That's odd, now I try them and the second one works but not the first. I
got my password from register in the first place.

Sean

Sean Breheny,KA3YXM
Electrical Engineering Student

1997\09\05@113950 by Engineering Department

flavicon
face
< From: Matt Bonner>

<talking about our troubles signing on to read the following articles>

> > >> www.mcjournal.com/main/back/tutorial.htm
> > >> http://www.mcjournal.com/main/tutser2.htm
> > >
> I didn't have a problem [signing on].  Try hitting "register" from
>         http://www.mcjournal.com/index.html

Thanks Matt,

Musta been sunspots, but I signed on fine this time!

Cheers,

Win Wiencke
Image Logic Corporation
TakeThisOuTImageLogicKILLspamspamspamibm.net

'PICMaster Stack overflow : solution'
1997\09\18@090359 by tjaart

flavicon
face
Hi to all the fellow PICMaster users!

My problem turned out to be a faulty PAL on the emulator POD.
The FAE replaced it on site in a few hours. Cudos to Christof!

I didn't let him go without printing him copies of the Scenix
specs and the article to go with it... <VVBG>

Someone told me about a company who had to throw away 2500 OTP
16C74A's Yeehaw! We'll surface a national road with it one day!

--
Friendly Regards

Tjaart van der Walt
.....tjaartspamRemoveMEwasp.co.za
________________________________________________________
|        WASP International   http://wasp.co.za          |
|   R&D Engineer : GSM peripheral services development   |
|Vehicle tracking | Telemetry systems | GSM data transfer|
|Voice : +27-(0)11-622-8686  |  Fax : +27-(0)11-622-8973 |
|             WGS-84 : 26010.52'S 28006.19'E             |
|________________________________________________________|

'Stack Overflow on 17c42'
1997\09\27@025523 by durandj

flavicon
face
I'm suffering from stack overflows on a 17c42 (I put a check of STKAVL
in my RTCC Timer Interrupt handler and I output an error code on a 7
segment display when detected).  BUT, I've done a thorough analysis of
my software and there is no way I should be overflowing the 16 word
stack.  I'm using three timer interrupts (RTCC, Timer 1/2, and Timer 3)
plus the Port B interrupt on change (although no port B pins are
changing when this occurs), and I'm not enabling interrupts in any of my
interrupt handlers (GLINTD remains set until the RETFIE at the end of my
handlers)

As I understand the spec sheet, an interrupt and a call each use one
word of the 16 word stack.  There isn't anything else that affects the
stack is there?   Also a "pending" interrupt (one asserted while
interrupts are disabled) does not use any stack - the corresponding
interrupt request bit is merely set - correct?  I've tallied the max
stack usage of all my routines and I should be using at most 10 slots.
The other thing that's puzzling is that the time between reset and when
the overflow occurs varies.  Given the nature of my software (a timer
application), its execution should be very deterministic.  I would
expect this stack overflow to be repeatable and to see a pattern in its
timing.  I think I'm missing something.  Any thoughts?

1997\09\27@094618 by Andrew Warren

face
flavicon
face
Jim Durand <RemoveMEdurandjspamspamBeGonegte.net> wrote:

> I'm suffering from stack overflows on a 17c42 .... BUT, I've done
> a thorough analysis of my software and there is no way I should be
> overflowing the 16 word stack.

   Nevertheless, Jim, you ARE overflowing it... So your analysis
   must not have been thorough ENOUGH.

> As I understand the spec sheet, an interrupt and a call each use one
> word of the 16 word stack.

   Correct.

> There isn't anything else that affects the stack is there?

   No.

> Also a "pending" interrupt (one asserted while interrupts are
> disabled) does not use any stack - the corresponding interrupt
> request bit is merely set - correct?

   Correct.

> I've tallied the max stack usage of all my routines and I should
> be using at most 10 slots. ....  I think I'm missing something. Any
> thoughts?

   Well... Obviously, your software isn't doing what you intend.

   Do you perform any direct writes to the Program Counter?
   Perhaps there's a bug in one of them and you're accidentally
   pointing the PC at a subroutine call.

   Do you have an emulator?  If so, I can suggest some debugging
   techniques that should help you isolate the problem pretty
   quickly... Let me know.

   -Andy

=== Meet other PICLIST members at the Embedded Systems Conference:
=== 6:30 pm on Wednesday, 1 October, at Bytecraft Limited's booth.
===
=== For more information on the Embedded Systems Conference,
=== see: http://www.embedsyscon.com/

=== Andrew Warren - spamBeGonefastfwd@spam@spamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499


'flowchart for a clock-calendar I2C'
1997\12\19@153609 by Ivano BONASSINA
flavicon
face
I should plan a lot of time to realize an ASM code for PIC 16F84 realizing a ''simple''
Clock calendar with LED display (6) HH:MM:SS or GG:MM:AA with some alarms
every 30 minutes. My question is:
I have to look in the  DS1202 external I2C clock calendar every how many millisecond and
when? And if I ask the DS1202 ( or PCF 8583 ) during a changing of second, how can I prevent the problem? Is better to use a 50hz clock to sincronize the look in the DS 1202?
Someone can help me with a flow of the program?
Thanks in advance.
TakeThisOuTBonassinspamspamtin.it

1997\12\20@142835 by Nigel Goodwin

flavicon
picon face
In message <01BD0CC6.311A3160EraseMEspamMilano38-15.tin.it>, Ivano BONASSINA
<RemoveMEbonassinEraseMEspamspam_OUTTIN.IT> writes
>I should plan a lot of time to realize an ASM code for PIC 16F84 realizing a
>''simple''
>Clock calendar with LED display (6) HH:MM:SS or GG:MM:AA with some alarms
>every 30 minutes. My question is:
>I have to look in the  DS1202 external I2C clock calendar every how many
>millisecond and
>when? And if I ask the DS1202 ( or PCF 8583 ) during a changing of second, how
>can I prevent the problem? Is better to use a 50hz clock to sincronize the look
>in the DS 1202?
>Someone can help me with a flow of the program?
>Thanks in advance.
>@spam@BonassinRemoveMEspamEraseMEtin.it

The PCF8583 can be set to give a pulse on one of the pins every second,
feed that into one of the PIC pins and use that to initiate the reading
routine. If you do just continually read the chip, it doesn't matter if
you read during a change of seconds - the time will be corrected at the
next read, so will never be more than a fraction of a second wrong.

--

Nigel.

       /--------------------------------------------------------------\
       | Nigel Goodwin   | Internet : EraseMEnigelgspam@spam@lpilsley.demon.co.uk     |
       | Lower Pilsley   | Web Page : http://www.lpilsley.demon.co.uk |
       | Chesterfield    |                                            |
       | England         |                                            |
       \--------------------------------------------------------------/

'Liquid pressure and flow transducers.'
1997\12\23@134511 by Humberto Bonasso

flavicon
face
Hi everybody,

   Have any of you been working with electronic liquid pressure and flow
sensors ?

   I'm developing a project with those parts and I'm interested to know
where to find the best prices (for me, not the supplier +ACE-). As I live in
Italy, the supplier has to accept mail orders and foreign customers.

   The devices I've found until now suitable for my needs are those from
Farnell: a gauge pressure sensor by Honeywell, range 0-100 PSI, price 17.49
pounds and  a rather nice water flow sensor manufactured by UCC that gives
752 pulses/litre in the range 0-25 litres for 32.20 pounds.

   Thanks to all for your help and ...  BUON  NATALE.


'Help! (16f84) Can't read POT and limit overflow to'
1998\01\04@144527 by PHXSYS
picon face
Hello

This is a sample of a program that is not working. I want to read a
potentiometer and display the results via LED s. The program displays the
results, but the overflow does not work. The LED display 255, then appear to
roll over. It should read a max of 250. I have tried 8 variations without
success. Could someone please tell me what I am missing. I can sleep when I
can't solve a problem.

Thank you

Nichole

#INCLUDE <16C84REG.H>
            TITLE "MEASURE POT ON LED, SHOW OVERFLOW=250"
            LIST P = 16F84
;            FILE NAME POTCAL8.ASM
;            Clock = 4MHz -> 1 instruction takes 1us
;
PULSE1          equ    0Ch              ; pulse time high CNTR
PULSE2          equ    0Dh              ; pulse time high CNTR
HB              equ    0EH              ; Heart Beat High
BUTC            equ    0FH              ; button loop cntr
PULSE1S         equ    10h              ; pulse time high STORE
PULSE2S         equ    11h              ; pulse time high STORE
DELAY1          equ    12h              ; 1 ms count
DELAY2          equ    13h              ; # ms /4 of low time
DATAPRT         equ    14H              ; data port
CTRLPRT         equ    15H              ; control port
BUT1FLG         equ    16H              ; button 1 pressed flag
BUT2FLG         equ    17H              ; button 2 pressed flag
BUT1CNT         equ    18H              ; button 1 COUNTER
BUT2CNT         equ    19H              ; button 2 COUNTER
PULSE1PS1       equ    1Ah              ; pulse time high STORE
PULSE2PS1       equ    1Bh              ; pulse time high STORE
PULSE1PS2       equ    1Ch              ; pulse time high STORE
PULSE2PS2       equ    1Dh              ; pulse time high STORE
;********************************************************************
;*******************************;
;       MAIN ENTRY POINT        ;
;*******************************;
       ORG 0X000
       GOTO START
;*******************************;
;    INTERRUPT SERVICE CODE     ;
;*******************************;
       ORG 0X004
       RETFIE                  ;return from interrupt
;*******************************;
;       SETUP PORTS Etc.        ;
;*******************************;
START
       MOVLW  B'10000111'
       OPTION                  ;set up the OPTION,Disable Bpullup
;
       MOVLW  B'00000000'
       MOVWF  0BH              ;Set up the INTCON register
;
       MOVLW  B'00000000'
       TRIS   PORTA            ;setup port A BITs 0-3 as OUTPUT
       MOVWF  PORTA            ;clear port A
       MOVLW  B'00000000'
       TRIS   PORTB            ;setup port B BITs 0-1 as output
                               ;*******************************;
                               ;       FIRST  SERVO            ;
                               ;*******************************;
BEGIN   MOVFW  PULSE1S          ;LOAD Pulse Store
       MOVWF  PULSE1           ;LOAD Pulse DISPLAY
       MOVWF  PORTB            ;DISPLAY PULSE1 8 LED=COUNT IN b'
                               ;***********************************;
                               ; READ POTS B0-B1                   ;
                               ;***********************************;
       MOVLW  B'00000000'
       TRIS   PORTA            ;setup port A BITs 0-1 as output
       CLRF   PULSE1S          ;Clear previous value
CAP_C   BSF    PORTA,0          ;START CAPACITOR CHARGE
       NOP                     ;Time to charge
       MOVLW  b'11111111'      ;Set PortA,0 to input
       TRIS   PORTA            ;Teach portA
MEAS1   CLRWDT
       BTFSS  PORTA,0          ;Test A0 skip if 1
       RETURN                  ;
       INCFSZ PULSE1S,F        ;Inc pulse1s skip if 0
       GOTO   MEAS1            ;
       MOVLW  0FAH             ;LOAD MAX PULSE=250
       SUBWF  PULSE1S, w       ;Subtract current value from it
       BTFSS  STATUS, C        ;If carry = 1, result is positive
       GOTO   BEGIN            ;No it is not -> goto down
       MOVLW  0FAH             ;Load Maximum Pulse Width
       MOVWF  PULSE1S          ;Store it in the position Value location
FINAL   GOTO   BEGIN            ;restart the MAIN Programme loop
                               ;*********************************;
                               ;      DUNO HOW WE GOT HERE       ;
                               ;*********************************;
ERROR_  SLEEP                   ;
       END                     ;The End

1998\01\04@151723 by Andrew Warren

face
flavicon
face
PHXSYS <@spam@PHXSYSspam_OUTspam.....aol.com> wrote:

{Quote hidden}

Nichole:

The PIC will only reach the first "MOVLW 0FAH" when PULSE1S is
incremented fropm 255 to 0... If PULSE1S is less than or equal to 255
when PORTA:0 goes low, the RETURN will be taken and your "limit to
250" code won't even be executed.

Now... When the "limit" code IS executed, PULSE1S will always be equal
to 0, so the SUBWF (which subtracts 250 from PULSE1S) will always be
negative, and the GOTO BEGIN will always be taken.

Basically, your code is badly broken.

If I were writing it, I'd do something like this:

       MOVLW   250         ;Start at 250 (we'll be counting down).
       MOVWF   PULSE1S     ;

   CAP_C:

       BSF     PORTA,0     ;Charge the cap.
       NOP                 ;

       MOVLW   11111111B   ;Stop charging and prepare to time the
       TRIS    PORTA       ;discharge.

   MEAS1:

       CLRWDT              ;Reset the watchdog timer.

       BTFSS   PORTA,0     ;If the cap has discharged, jump to
       GOTO    CLEANUP     ;CLEANUP.

       DECFSZ  PULSE1S     ;Otherwise, decrement PULSE1S.
       GOTO    MEAS1       ;If PULSE1S has not yet reached 0,
                           ;loop back.

   ; At this point, we've either looped 250 times, or the cap
   ; has discharged.  Either way, PULSE1S = 250 - [number of loops].

       MOVF    PULSE1S,W   ;PULSE1S = 250 - PULSE1S.
       SUBLW   250         ;
       MOVWF   PULSE1S     ;

       RETURN              ;Return with PULSE1S = number of loops,
                           ;limited to a maximum of 250.

-Andy

P.S.  Note that the last four lines of my suggested code are
     different from what I sent you in private e-mail... Please
     disregard that earlier response.

=== Andrew Warren - spamBeGonefastfwdEraseMEspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\01\06@103656 by PHXSYS

picon face
Andy,

Thank you for the help. I am a beginner as you can tell. You were absolutely
right about the holes in my program. I slapped myself. I tried your suggested
code modification and was still not able to make it work. I must be
overlooking something. I wasn't really sure of what to do with the " goto
cleanup". I have checked my hardware and its ok. The program you suggested
just returned the 250 overflow value. My original program counted and
displayed via leds, but the overflow didn't work. If you have time could you
take another look.

Nichole

Your code suggestions:

   MOVLW   250         ;Start at 250 (we'll be counting down).
       MOVWF   PULSE1S     ;

   CAP_C:

       BSF     PORTA,0     ;Charge the cap.
       NOP                 ;

       MOVLW   11111111B   ;Stop charging and prepare to time the
       TRIS    PORTA       ;discharge.

   MEAS1:

       CLRWDT              ;Reset the watchdog timer.

       BTFSS   PORTA,0     ;If the cap has discharged, jump to
       GOTO    CLEANUP     ;CLEANUP.

       DECFSZ  PULSE1S     ;Otherwise, decrement PULSE1S.
       GOTO    MEAS1       ;If PULSE1S has not yet reached 0,
                           ;loop back.

   ; At this point, we've either looped 250 times, or the cap
   ; has discharged.  Either way, PULSE1S = 250 - [number of loops].

       MOVF    PULSE1S,W   ;PULSE1S = 250 - PULSE1S.
       SUBLW   250         ;
       MOVWF   PULSE1S     ;

       RETURN              ;Return with PULSE1S = number of loops,
                           ;limited to a maximum of 250.

1998\01\06@121023 by Andrew Warren

face
flavicon
face
PHXSYS <PICLISTspamBeGonespamMITVMA.MIT.EDU> wrote:

> I tried your suggested code modification and was still not able to
> make it work. I must be overlooking something. I wasn't really
> sure of what to do with the " goto cleanup".

   Hi, Nichole.

   Sorry... I must have left out the label when I typed up that
   code.  The "CLEANUP" label should appear just before the "MOVF
   PULSE1S,W" line (right after the two line of comments).

> I have checked my hardware and its ok. The program you suggested
> just returned the 250 overflow value.

   How long does it take for the capacitor to discharge in your
   circuit?  At 4 MHz, the value in PULSE1S will be equal to 1 count
   per 6 microseconds... So if the cap takes longer than 1.5
   milliseconds to discharge, that PULSE1S value will be 250.

   -Andy

=== Andrew Warren - RemoveMEfastfwd@spam@spamspamBeGoneix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

'RainFlow'
1998\01\22@175334 by TONY NIXON 54964

flavicon
picon face
Has any one got any info or links on how to implement, (understand),
rain flow analysis.


TIA
Tony

For the beginner....
PicNPoke Multimedia 16F84 Simulator Assembler, and Tutorial.
Now with PicNPlay circuit simulator.
Plus animated Address Mode Tutor.

http://www.dontronics.com/picnpoke.html

1998\01\24@050553 by Michael S. Hagberg

flavicon
face
if you are looking for a rain gauge, try this link.
this device puts out one pulse per .01" of rain fall

http://www.davisnet.com/davis/prodsearch.asp?cat=18

michael



{Original Message removed}


'Stack Underflow causes Purple Plague to Sweep the '
1998\04\09@124815 by lilel
flavicon
face
So, what happens in a real part if there is a stack underflow???

It's not too hard to write a dud piece of code that calls a
subroutine but for some reason never comes back.  One method of
writing such evil and dastardly code is to put a GOTO inside a
subroutine that points outside the subroutine.  The code never
executes the RETURN or RETLW statement.  (Don't ever try this at
home.)


In a simulator, this will eventually give you an error message.  Call
such a subroutine 8 times and you've exceeded the eight level stack
in a PIC.    What happens in the real part?  Does it reboot?  Does it
go off into LaLa land and begin executing uninitialized code?  Does
it chug merrily along?  Does it ignite a global  epedemic of Purple
Plague?



Best Regards,

Lawrence Lile

1998\04\09@133249 by ERIC SCHLAEPFER

flavicon
face
Hi,


The stack on the PIC is an arrangement of 8 registers and one stack pointer.
After a reset, the stack looks like this:

1. (empty)     <-  (the stack pointer points here)
2. (empty)
3. (empty)
4. (empty)
5. (empty)
6. (empty)
7. (empty)
8. (empty)

When a CALL is executed, the current Program Counter value, maybe call it A, is
pushed on the stack like this:

1.  A
2. (empty)     <-  Stack Pointer
3. (empty)
4. (empty)
5. (empty)
6. (empty)
7. (empty)
8. (empty)

"A" overwrites the value at the current stack pointer location; since it is
empty the push is OK. The stack pointer is then incremented to the next slot.

Let's say that we have pushed 7 times, so the stack looks like this:

1. A
2. B
3. C
4. D
5. E
6. F
7. G
8. (empty)     <- Stack Pointer

If we push one more time, the stack pointer goes to zero again, like this:

1. A           <- SP
2. B
3. C
4. D
5. E
6. F
7. G
8. H

Another push *overwrites* the first item, and increments the SP to slot 2.

1. I
2. B           <- SP
3. C
4. D
5. E
6. F
7. G
8. H

When the stack is popped, the SP is decremented. If it is already at zero, it
loops around and goes back to 8, because the whole deal is a circular buffer. If
you keep popping until you pop the first slot, you get the 9th push instead of
the first push. (I.E., you get "I" instead of "A.")

Now remember that the 9th subroutine probably has a RETURN in it, which returns
you to the 8th item, and so on all the way down the stack again. In other words,
the PIC goes crazy and runs around and around in circles 'till you pull the
plug.

Later,

Eric



______________________________ Reply Separator _________________________________
Subject: Stack Underflow causes Purple Plague to Sweep the Nation
Author:  Lawrence Lile <.....lilel@spam@spamEraseMEtoastmaster.com> at INTERNET
Date:    4/9/98 11:46 AM


So, what happens in a real part if there is a stack underflow???

It's not too hard to write a dud piece of code that calls a
subroutine but for some reason never comes back.  One method of
writing such evil and dastardly code is to put a GOTO inside a
subroutine that points outside the subroutine.  The code never
executes the RETURN or RETLW statement.  (Don't ever try this at
home.)


In a simulator, this will eventually give you an error message.  Call
such a subroutine 8 times and you've exceeded the eight level stack in
a PIC.    What happens in the real part?  Does it reboot?  Does it go
off into LaLa land and begin executing uninitialized code?  Does it
chug merrily along?  Does it ignite a global  epedemic of Purple
Plague?



Best Regards,

Lawrence Lile

1998\04\09@133249 by ERIC SCHLAEPFER

flavicon
face
Hi,


The stack on the PIC is an arrangement of 8 registers and one stack pointer.
After a reset, the stack looks like this:

1. (empty)     <-  (the stack pointer points here)
2. (empty)
3. (empty)
4. (empty)
5. (empty)
6. (empty)
7. (empty)
8. (empty)

When a CALL is executed, the current Program Counter value, maybe call it A, is
pushed on the stack like this:

1.  A
2. (empty)     <-  Stack Pointer
3. (empty)
4. (empty)
5. (empty)
6. (empty)
7. (empty)
8. (empty)

"A" overwrites the value at the current stack pointer location; since it is
empty the push is OK. The stack pointer is then incremented to the next slot.

Let's say that we have pushed 7 times, so the stack looks like this:

1. A
2. B
3. C
4. D
5. E
6. F
7. G
8. (empty)     <- Stack Pointer

If we push one more time, the stack pointer goes to zero again, like this:

1. A           <- SP
2. B
3. C
4. D
5. E
6. F
7. G
8. H

Another push *overwrites* the first item, and increments the SP to slot 2.

1. I
2. B           <- SP
3. C
4. D
5. E
6. F
7. G
8. H

When the stack is popped, the SP is decremented. If it is already at zero, it
loops around and goes back to 8, because the whole deal is a circular buffer. If
you keep popping until you pop the first slot, you get the 9th push instead of
the first push. (I.E., you get "I" instead of "A.")

Now remember that the 9th subroutine probably has a RETURN in it, which returns
you to the 8th item, and so on all the way down the stack again. In other words,
the PIC goes crazy and runs around and around in circles 'till you pull the
plug.

Later,

Eric



______________________________ Reply Separator _________________________________
Subject: Stack Underflow causes Purple Plague to Sweep the Nation
Author:  Lawrence Lile <.....lilelRemoveMEspamtoastmaster.com> at INTERNET
Date:    4/9/98 11:46 AM


So, what happens in a real part if there is a stack underflow???

It's not too hard to write a dud piece of code that calls a
subroutine but for some reason never comes back.  One method of
writing such evil and dastardly code is to put a GOTO inside a
subroutine that points outside the subroutine.  The code never
executes the RETURN or RETLW statement.  (Don't ever try this at
home.)


In a simulator, this will eventually give you an error message.  Call
such a subroutine 8 times and you've exceeded the eight level stack in
a PIC.    What happens in the real part?  Does it reboot?  Does it go
off into LaLa land and begin executing uninitialized code?  Does it
chug merrily along?  Does it ignite a global  epedemic of Purple
Plague?



Best Regards,

Lawrence Lile

1998\04\09@133707 by lilel

flavicon
face
 So, what happens in a real part if there is a stack underflow???

 It's not too hard to write a dud piece of code that calls a
 subroutine but for some reason never comes back.  One method of
 writing such evil and dastardly code is to put a GOTO inside a
 subroutine that points outside the subroutine.  The code never
 executes the RETURN or RETLW statement.  (Don't ever try this at
 home.)


 In a simulator, this will eventually give you an error message.
Call
 such a subroutine 8 times and you've exceeded the eight level stack
 in a PIC.    What happens in the real part?  Does it reboot? Does
it
 go off into LaLa land and begin executing uninitialized code?  Does
 it chug merrily along?  Does it ignite a global epedemic of Purple
 Plague?



 Best Regards,

 Lawrence Lile
Best Regards,

Lawrence Lile

1998\04\09@133848 by Harrison Cooper

flavicon
face
               Well...how about this in order to avoid the plague.  In
a routine you might expect to cause this, don't reset the watchdog
timer.  Then it will automatically reset.  I would suspect the stack
would just have the last address continued to be written in the top of
the stack forever.

                               ----------
                               From:  Lawrence Lile
[SMTP:.....lilelSTOPspamspam@spam@toastmaster.com]
                               Sent:  Thursday, April 09, 1998 5:46 AM
                               To:  PICLISTEraseMEspam@spam@MITVMA.MIT.EDU
                               Subject:  Stack Underflow causes Purple
Plague to Sweep the Nation

                       So, what happens in a real part if there is a
stack underflow???

                       It's not too hard to write a dud piece of code
that calls a
                       subroutine but for some reason never comes back.
One method of
                       writing such evil and dastardly code is to put a
GOTO inside a
                       subroutine that points outside the subroutine.
The code never
                       executes the RETURN or RETLW statement.  (Don't
ever try this at
                       home.)


                       In a simulator, this will eventually give you an
error message.  Call
                       such a subroutine 8 times and you've exceeded
the eight level stack
                       in a PIC.    What happens in the real part?
Does it reboot?  Does it
                       go off into LaLa land and begin executing
uninitialized code?  Does
                       it chug merrily along?  Does it ignite a global
epedemic of Purple
                       Plague?



                       Best Regards,

                       Lawrence Lile

'(Fwd) Re: Stack Underflow causes Purple Plague to '
1998\04\09@134917 by lilel

flavicon
face
Forwarded message:
From:     Self <TM_FS1/LILEL>
To: ERIC SCHLAEPFER <RemoveMEeric.schlaepferspamspamBeGoneAUTODESK.COM>
Subject: Re: Stack Underflow causes Purple Plague to Sweep the Nation
Reply-to: spamBeGonelilelKILLspamspam@spam@toastmaster.com
Date: Thu, 9 Apr 1998 12:45:43 CST

Eric wrote:



> Now remember that the 9th subroutine probably has a RETURN in it,
> which returns you to the 8th item, and so on all the way down the
> stack again. In other words, the PIC goes crazy and runs around and
> around in circles 'till you pull the plug.

Hmmm - this is why they tell you to never put a CLRWDT in a
subroutine - because if there was a stack underflow and the PIC
didn't see a CLRWDT in a long while the unit would reboot.

The subroutine I wrote (Geez, I have to admit this in public) is a
timing routine that waits 1.0 seconds.  It's not interrupt driven
code, the whole PIC waits around until it gets done incrementing a
few registers in a counting loop.  Thus it needs to have a CLRWDT in
the loop.

At the same time it is polling a pushbutton.  This is where the Stack
Underflow problem came from.  If the routine sensed the pushbutton,
it executed a GOTO, left the subroutine forever.  Press the button
eight times and BINGO, the PIC freaks out!

I've rewritten it to execute a RETURN when it senses the button push,
then re-check the state of the button.

Is there a better way?

-- Lawrence Lile

Download AutoCad blocks for electrical drafting at:
http://members.sockets.net/~llile/index.htm

'Stack Underflow causes Purple Plague to Sweep'
1998\04\09@141919 by ERIC SCHLAEPFER

flavicon
face
    >Hmmm - this is why they tell you to never put a CLRWDT in a
    >subroutine - because if there was a stack underflow and the PIC
    >didn't see a CLRWDT in a long while the unit would reboot.

    I think so. It is also forces you to limit the size of your
    subroutines depending on the watchdog reset delay. (Is this good or
    bad?)

    >The subroutine I wrote (Geez, I have to admit this in public) is a
    >timing routine that waits 1.0 seconds.  It's not interrupt driven
    >code, the whole PIC waits around until it gets done incrementing a
    >few registers in a counting loop.  Thus it needs to have a CLRWDT in
    >the loop.

    >At the same time it is polling a pushbutton.  This is where the Stack
    >Underflow problem came from.  If the routine sensed the pushbutton,
    >it executed a GOTO, left the subroutine forever.  Press the button
    >eight times and BINGO, the PIC freaks out!

    >I've rewritten it to execute a RETURN when it senses the button push,
    >then re-check the state of the button.

    >Is there a better way?

    You could set a flag in the subroutine that blasts out of the loop
    when you return. You could even return the status of the button in the
    working register with a RETLW. Of course, you loop code probably
    wouldn't like W to be messed with.

    Later,

    Eric




______________________________ Reply Separator _________________________________
Subject: (Fwd) Re: Stack Underflow causes Purple Plague to Sweep the
Author:  Lawrence Lile <lilelspam_OUTspam@spam@toastmaster.com> at INTERNET
Date:    4/9/98 12:48 PM


Forwarded message:
From:     Self <TM_FS1/LILEL>
To: ERIC SCHLAEPFER <spamBeGoneeric.schlaepfer@spam@spamAUTODESK.COM>
Subject: Re: Stack Underflow causes Purple Plague to Sweep the Nation
Reply-to: RemoveMElilelEraseMEspamKILLspamtoastmaster.com
Date: Thu, 9 Apr 1998 12:45:43 CST

Eric wrote:



> Now remember that the 9th subroutine probably has a RETURN in it,
> which returns you to the 8th item, and so on all the way down the
> stack again. In other words, the PIC goes crazy and runs around and
> around in circles 'till you pull the plug.

Hmmm - this is why they tell you to never put a CLRWDT in a
subroutine - because if there was a stack underflow and the PIC
didn't see a CLRWDT in a long while the unit would reboot.

The subroutine I wrote (Geez, I have to admit this in public) is a
timing routine that waits 1.0 seconds.  It's not interrupt driven
code, the whole PIC waits around until it gets done incrementing a
few registers in a counting loop.  Thus it needs to have a CLRWDT in
the loop.

At the same time it is polling a pushbutton.  This is where the Stack
Underflow problem came from.  If the routine sensed the pushbutton,
it executed a GOTO, left the subroutine forever.  Press the button
eight times and BINGO, the PIC freaks out!

I've rewritten it to execute a RETURN when it senses the button push,
then re-check the state of the button.

Is there a better way?

-- Lawrence Lile

Download AutoCad blocks for electrical drafting at:
http://members.sockets.net/~llile/index.htm

1998\04\09@141919 by ERIC SCHLAEPFER

flavicon
face
    >Hmmm - this is why they tell you to never put a CLRWDT in a
    >subroutine - because if there was a stack underflow and the PIC
    >didn't see a CLRWDT in a long while the unit would reboot.

    I think so. It is also forces you to limit the size of your
    subroutines depending on the watchdog reset delay. (Is this good or
    bad?)

    >The subroutine I wrote (Geez, I have to admit this in public) is a
    >timing routine that waits 1.0 seconds.  It's not interrupt driven
    >code, the whole PIC waits around until it gets done incrementing a
    >few registers in a counting loop.  Thus it needs to have a CLRWDT in
    >the loop.

    >At the same time it is polling a pushbutton.  This is where the Stack
    >Underflow problem came from.  If the routine sensed the pushbutton,
    >it executed a GOTO, left the subroutine forever.  Press the button
    >eight times and BINGO, the PIC freaks out!

    >I've rewritten it to execute a RETURN when it senses the button push,
    >then re-check the state of the button.

    >Is there a better way?

    You could set a flag in the subroutine that blasts out of the loop
    when you return. You could even return the status of the button in the
    working register with a RETLW. Of course, you loop code probably
    wouldn't like W to be messed with.

    Later,

    Eric




______________________________ Reply Separator _________________________________
Subject: (Fwd) Re: Stack Underflow causes Purple Plague to Sweep the
Author:  Lawrence Lile <spamBeGonelilelspam_OUTspamRemoveMEtoastmaster.com> at INTERNET
Date:    4/9/98 12:48 PM


Forwarded message:
From:     Self <TM_FS1/LILEL>
To: ERIC SCHLAEPFER <.....eric.schlaepferspamRemoveMEAUTODESK.COM>
Subject: Re: Stack Underflow causes Purple Plague to Sweep the Nation
Reply-to: lilelspam@spam@toastmaster.com
Date: Thu, 9 Apr 1998 12:45:43 CST

Eric wrote:



> Now remember that the 9th subroutine probably has a RETURN in it,
> which returns you to the 8th item, and so on all the way down the
> stack again. In other words, the PIC goes crazy and runs around and
> around in circles 'till you pull the plug.

Hmmm - this is why they tell you to never put a CLRWDT in a
subroutine - because if there was a stack underflow and the PIC
didn't see a CLRWDT in a long while the unit would reboot.

The subroutine I wrote (Geez, I have to admit this in public) is a
timing routine that waits 1.0 seconds.  It's not interrupt driven
code, the whole PIC waits around until it gets done incrementing a
few registers in a counting loop.  Thus it needs to have a CLRWDT in
the loop.

At the same time it is polling a pushbutton.  This is where the Stack
Underflow problem came from.  If the routine sensed the pushbutton,
it executed a GOTO, left the subroutine forever.  Press the button
eight times and BINGO, the PIC freaks out!

I've rewritten it to execute a RETURN when it senses the button push,
then re-check the state of the button.

Is there a better way?

-- Lawrence Lile

Download AutoCad blocks for electrical drafting at:
http://members.sockets.net/~llile/index.htm

1998\04\09@145323 by lilel

flavicon
face
Sorry for sending duplicate messages to the list.

>   So, what happens in a real part if there is a stack underflow???

I found another possible way stack underflows can occur.

I have some lookup tables, with 16 values in them

LOOKUP
        ADDWF PCL,F
        RETLW 0
        RETLW  1
        RETLW  2
ETC.ETC......
        RETLW 15

What happens if I enter such a table with a number greater than 15?
This is unlikely.  I was worried this could happen, so I put

GOTO ERRORHANDLER  after the 16th value in the table.  At least we'd
goto someplace under control.

Mistake!  This causes a stack underflow.  I've placed a GOTO $ at the
end of the subroutine now.  It keeps branching back to itself  (GOTO
$ is like SELF GOTO SELF) until it generates a watchdog timeout.
Then we are back to a controlled state.   Presumably  a watchdog
timeout clears the stack, No?

Otherwise, we're back to Purple Plague........

Best Regards,

Lawrence Lile

'(Fwd) Re: Stack Underflow causes Purple Plague to '
1998\04\09@145725 by lilel

flavicon
face
Harrison wrote:

>   I've done this sort o f thing.  Set a flag in a register
> to inidcate the button is pushed.  Exit from the subroutine.  Check
> the flag in the register.  Does this make sense? If not, let me know

Makes a LOTTA sense.

I wish I knew a good way to time something for several seconds, doing
nothing else, without having a CLRWDT inside a subroutine.  No GOTO's
inside subroutines that point to the outside, and no CLRWDT's, would
be a good rule to follow.

'Stack Underflow Causes Purple Plague'
1998\04\09@214035 by Mike Keitz

picon face
On Thu, 9 Apr 1998 13:51:49 +0000 Lawrence Lile <EraseMElilelRemoveMEspamSTOPspamtoastmaster.com>
writes:

>I have some lookup tables, with 16 values in them
>
>LOOKUP
>         ADDWF PCL,F
>         RETLW 0
>         RETLW  1
>         RETLW  2
>ETC.ETC......

>What happens if I enter such a table with a number greater than 15?
>This is unlikely.  I was worried this could happen, so I put
>
>GOTO ERRORHANDLER  after the 16th value in the table.  At least we'd
>goto someplace under control.

The goto will only execute if you enter with W=17.  If W is greater than
17, the program will go to whatever code is after the table.  Even worse,
think of what happens if W=0xFF!  The ADDWF PCL,F instruction will
execute indefinitely.  If you're uncertain that W will be in range,
perhaps the best fix is to check the value of W before exectuing the
computed goto.  For tables with a length of a power of 2, it is real
simple to just ANDLW the potentially troublesome high bits of W to zero.

Good bombproof coding should also set up PCLATH (if applicable) before
every table access as well.  Checking the value before launching into the
table will fix anything but a hardware malfunction that alters W.  In
that case, all bets ar off what the PIC will do.  Hopefully your
strategically-placed clrwdt won't execute.

[...]
>Then we are back to a controlled state.   Presumably  a watchdog
>timeout clears the stack, No?

The stack is never cleared by any sort of reset.  It doesn't have to be
cleared.  The pointer can just roll over and over, making the stack more
like a circle than a line.  A CALL or interrupt will store data and move
the pointer forward one.  The next RETURN will move the pointer back one
and recall the address that was last pushed. Wherever it starts, after 8
pushes the pointer is back where it started.

Going back to the top of your program and restarting it, whether by WDT
or a direct GOTO will make any data in the stack irrelevant.  The entire
tree of calls will be done over again, storing the proper return
addresses wherever the pointer starts from.  So if you want to crash and
restart everything after an unrecoverable error, just disable interrupts
and goto 0.  This simulates a hardware reset fairly well.

There shouldn't be any need to do this though, the program needs to be
bug-free to have much chance of working.


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

'Stack Underflow causes Purple Plague to Sweep'
1998\04\10@082255 by paulb

flavicon
face
ERIC SCHLAEPFER wrote, himself quoting Lawrence Lile:

>> Hmmm - this is why they tell you to never put a CLRWDT in a
>> subroutine - because if there was a stack underflow and the PIC
>> didn't see a CLRWDT in a long while the unit would reboot.

> I think so. It is also forces you to limit the size of your
> subroutines depending on the watchdog reset delay. (Is this good or
> bad?)

 No to the first, thence no to the second.  "They" might suggest you do
not put CLRWDT instructions in subroutines, and "they" may not.  If the
WDT times out, the stack pointer is reset (in fact, the only way of
doing it) along with the PC, but this has nothing to do with stack
overflow or underflow.

 The reason espoused for *not* putting CLRWDT in subroutines is simply
the recommendation that the instruction only appear in the code *once*.
This in turn is a "rule" to avoid the instruction appearing at so many
points in the code that an accidental terminal loop has a significant
probability of including a CLRWDT.

 So long as this rationale is understood, variations may be made.  If
in this case, you have a timing and input loop (much) longer than the
WDT period, then so be it.  You insert a single CLRWDT immediately
before the end of the outmost loop so that the WDT is reset just often
enough not to time out.  If this subroutine is always called at least as
often as the WDT period, then no other CLRWDT is required and there is
no problem.  If there is an alternate path within the main program loop,
then this will also need to contain a CLRWDT, possibly in an alternate
subroutine.

 As long as the routines containing the CLRWDT are few and simple
enough to be reckoned reliable, this should not be a problem.

 As to a "busy waiting" loop, these generally should have a single
return with a status returned in either W or a flag location, usually
zero (the loop index) or a keyvalue.

 Cheers,
       Paul B.


'MAF Mass Air Flow sensor interface (automotive)'
1998\07\27@145509 by
picon face
Hi everyone,

I want to take an autmotive type Mass Air Flow  (MAF) sensor and interface it
with a pic 16F84 or a stampII. I want to implement this on a vehicle that has
no MAF . I know a MAF sensor uses a hot wire anemometer which measures the
current required to keep the wire at a stable temperature. The output is  0-5
v representative of the mas air flow. I am not sure if the MAF itself provides
the logic to sustain a stable temperature is in the MAF electronics or
controlloed by the on board ECM. The MAF connection is 5 or 6 wires unlike the
3 wire MAP sensors. I would like to interface and use the MAF 0-5v signal. So
I need a stand alone system.

Does anyone know how to interface with this sensor or point me to a source.
That would be great help.

Thanks in advance.

Jon

1998\07\27@163637 by Bob Blick

face
flavicon
face
Hi Jon,

Is this for a Ford? I just bought one, and have the factory manuals
coming. Maybe there will be some useful information there($300, ther
better be!).

Cheers,
Bob

1998\07\27@205015 by Bruce Turrentine

picon face
Jon
Ford uses a MAF that is self contained. Inputs are gnd & Vbat. The output is a
isolated ground and the analog voltage signal. I wish I could be more specific
but someone is currently borrowing my book. It is important to select a sensor
that is reasonably sized for the CFM of the engine. An oversized sensor will
have poor resolution at low flow. A MAF that is too small will limit the
engines WOT performance. IE: bigger is not always better.
Hope this helps,
Bruce


'Mass Airflow Sensors'
1998\08\04@213200 by Jason Tuendemann
flavicon
face
   Does anyone have any info or contacts for mass airflow sensors for use
on combustion engines. I know the basic theory of how they work but any more
info would help.

Thanks
Jason.

'seek flow chart software'
1998\08\08@101558 by Yves.Heilig

flavicon
face
Somebody can it indicate to me who I can find a software of flow chart for
Win95.

Thank you
Yves

'Flow chart software'
1998\08\10@131412 by Jason Wolfson

flavicon
face
look at http://www.smartdraw.com
seems to work great and has a downloadable free trial version....
just spent all morning with it....


Jason Wolfson

'Problem with continues dataflow via usart'
1998\08\28@185305 by RemcoB

picon face
part 0 3023 bytes
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>Hi everybody,</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>I'm working on a project with a large amount of
pic's in a peer to peer network configuration.</FONT></DIV>
<DIV><FONT size=2>Each station has to recieve compute and send all the data at
the 'same' time.</FONT></DIV>
<DIV><FONT color=#000000 size=2>To do so I use a serial recieve interupt, which
move the data to a small buffer.</FONT></DIV>
<DIV><FONT color=#000000 size=2>Each program cycle I get a byte out the recieve
buffer, compute it and send the byte away.</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>Everything works perfect except when I send a
large amount of data via the bus with no pause between the bytes, then I am
loosing a byte ones in the x thousand bytes. I checked my buffers timing etc,
but it seems to be all okay. </FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>When I use a little delay now and then in the transmision { 2
ms after 1000 bytes written } it works fine.</FONT></DIV>
<DIV><FONT size=2>I discovered that the frequency in wich the fault occured
depended on the caps that I used with my crystal. </FONT><FONT size=2>When I use
a single oscillator for all my stations, it all works fine. </FONT></DIV>
<DIV><FONT size=2>So I made seperate high precision oscillators for each station
and reduceded the fault so only one byte in the several hundreds of thousands is
lost. </FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Apart from the bytes that gets lost some others gets
corrupted, dispite the parity check.</FONT></DIV>
<DIV><FONT size=2>There does not occure a single parity or framing
error.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2>Has anyone any ideas on what is causing the problem, I'm
getting very tired off this problem.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#000000 size=2>Thanx,</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Remco Brenninkmeijer</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV></BODY></HTML>

</x-html>

1998\08\28@225643 by Chip Weller

flavicon
face
 Without seeing your code and knowing more about the system topology here
are my thoughts (which you probably have had):

 I am going to assume you have a daisy chain system, each PIC received from
its "upstream" device and sends to its "downstream" device. Each PIC would
be running the same software (at least as far as the communications). Each
PIC will send the character just processed on downstream and the grab the
next character in. (If I am wrong about this assumption, ignore the rest of
this message.)

 The UART is probably running in ASYNC mode (?). Async mode of course is
really synchronous with 16x the internal bit clock. Since each PIC is not
delaying between characters at all each UART is continuously sending "start
bit, data bits, [optional parity,] stop bit(s), start bit, data bits, ...".

 Now assume PIC1 is sending to PIC2 while running about 0.005% (50ppm)
faster than PIC2 is. This means after about 10000 bits (1000 bytes of serial
data) data is off by 1/2 a bit, which is about where the system will miss
the start bit. This provides about the correct error rate, so that would be
the problem I would try to fix.

 About framing errors check the errata sheets for your device. I think
there are known problems with this feature on some chips. As far as the
parity is concerned my first impression would be your parity generation and
checking may be at fault, since that must be implemented in software.

 So how do you fix this problem? First I would plan on sending 8-bit data
(no parity). Once each n (256?) bytes I would transmit using 9-bit data
sending an extra stop-bit. This would allow the fast/slow combination PICs
in the transmission chain to resync since all receiving PICs would always
receive using 8-bit data. Note if 9-bit data is desired a slight
modification would be to delay between sending two bytes. This is slightly
complicated since the TX shift register is double buffered, you have to wait
for the TX shift register to empty, not just the buffer. This can be checked
using the TRMT flag instead of the TXIF flag. However the big problem is
there is no way to generate an interrupt on the TRMT flag change. Another
fix, which would only apply if there is one and only one originator of all
transactions, would be to run that device's Baud RATE clock at say 1% slower
than the rest. This would result an extra bit clocks between bytes sent.

 Now if you are implementing a "token ring" approach to your protocol where
the packet continuously travels the ring of PICs the approach is to create
the gaps dynamically using a double buffer. This would get rather complex
and the timing messy, but I think it could be done. The idea would be to
have maybe 1 PIC insert a gap by buffering a byte of data once every n bytes
(or maybe when the token reaches it.) There would have to be a gap in the
input data at some point to allow the buffering PIC to unload it's extra
byte before it needs to grab another one. Hopefully you are not doing this.

BTW: many people on the PICLIST don't do HTML messages, you should send it
plain text.

Chip Weller
   {Original Message removed}

1998\08\29@090251 by Chip Weller

flavicon
face
I previously wrote:


>  Without seeing your code and knowing more about the system topology here
>are my thoughts (which you probably have had):
>
>  I am going to assume you have a daisy chain system, each PIC received
from
{Quote hidden}

serial
{Quote hidden}

wait
>for the TX shift register to empty, not just the buffer. This can be
checked
>using the TRMT flag instead of the TXIF flag. However the big problem is
>there is no way to generate an interrupt on the TRMT flag change. Another
>fix, which would only apply if there is one and only one originator of all
>transactions, would be to run that device's Baud RATE clock at say 1%
slower
>than the rest. This would result an extra bit clocks between bytes sent.

> <snipped a bunch of stuff.>

Sorry about the above advice, it was late here when I wrote it. Some
problems withe the above:
1. If the system is a true ring using 9-bit on the orginator will cause it
to drop incoming data which is only 8-bit.
2. Assuming a simple double buffering system each PIC would be able to
absorb a fair amount of extra bit space. This condition woudl occur if it
takes longer to process the first character than later characters. It may
take much longer extra time delays than I proposed above, more on the order
of 1 characters worth.

I thought some more about my analysis of the problem and I think I was on
the wrong track. If I was implmenting a hardware UART I would start
searching for the next start bit directly after detecting the stop bit
(dropping the last 1/4 to 1/2 of the stop bit). Allowing shorter input data
elements than the size of the output data element would solve the start bit
overrun condition. If Microchip did this (anyone on the list known internals
of the USART?) then your system would have have the above described problem,
but a different one. With continous data transmission a faster PIC could
still overrun internal double buffering and your software FIFOs in the
system.

Assuming no software FIFO you should be able to send about 20K characters
before overrunning the double buffering on the TSR using a 50 ppm crystal
(assuming correct oscilator and such). Assuming a 10 ppm crystal/oscilator
this drop rate does match your "high precision oscillators" statement and is
probably at least 1 order of magnitude lower error rate than expected from
the stop/start bit conflict. This also may explain the lack of any framing
errors and possibly any overrun errors (the overrun could occur in your
software loop, instead of in the hardware).

This is more likely to be your problem than what I first guessed. The
solution is to somehow slow the data xmit rate by a few fractions of a
percent at the orginal source of the data by adding gaps between output
bytes, either every byte or every few bytes.

Chip Weller


'Flowcharting 101/PIC'
1998\11\26@001022 by Steve Tomes
flavicon
face
I need to be able to express my design not only to myself but to others in
an organized way. A through understanding of accepted flowcharting
practices is something I lack and need to fix..fast!!!

Looking for URL/html....set me straight!!???????????

1998\11\26@003225 by James Cameron

flavicon
face
Steve Tomes wrote:
> A through understanding of accepted flowcharting
> practices is something I lack and need to fix..fast!!!

I haven't seen any web reference; though I have not looked.
Check AltaVista or Yahoo.

However, the rules of flowcharting that I use are;

1) there is only one START and one STOP,
2) lines must never cross,
3) rectangles mean actions, only one exit,
4) diamonds mean yes/no decisions, can have one entrance and only two
exits,
5) any container can be broken down further into another diagram if more
detail is required.

The most common fault I have seen in flowcharting is a failure to adopt
the same level of detail across the chart.  If you have one rectangle
which goes to bit level detail and another which is not, then you are
creating a conflict that makes it harder to understand.

Also, think of a flowchart as software, not as hardware.  I think there
is no real sense in showing hardware on a flowchart, unless it is done
in a way that is non-intrusive, such as colour shaded dotted lines or
something.

--
James Cameron                                      (RemoveMEcameronKILLspamspamTakeThisOuTstl.dec.com)

OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.

"Specialisation is for insects." -- Robert Heinlein.

1998\11\26@100339 by Petar Ristanovic

flavicon
face
Steve Tomes wrote:
>
> I need to be able to express my design not only to myself but to others in
> an organized way. A through understanding of accepted flowcharting
> practices is something I lack and need to fix..fast!!!
>
> Looking for URL/html....set me straight!!???????????

Hi,

  Please visit the:

  http://www.RistanCASE.ch

  There is one Windows IDE "Development Assistant for C"
  (Supports Hi-Tech PIC Compiler directly) with Editor,
  Flow Chart, Browser, Call Hierarchy Graph, Make Generator,
  Tool integration, Interface to Debuggers and Version
  Control Systems, soon with Software Metrics...

Sincerely,
Petar Ristanovic

1998\11\27@151023 by Morgan Olsson

picon face
At 09:50 1998-11-26 +0100, Petar Ristanovic wrote:
{Quote hidden}

Looks nice!
I just don«t get what is the limitation of the free version??
And how much do the full cost?

/Morgan
       Morgan Olsson                   ph  +46(0)414 70741
       MORGANS REGLERTEKNIK            fax +46(0)414 70331
       H€LLEKS           (in A-Z letters: "HALLEKAS")
       SE-277 35 KIVIK, SWEDEN               spamBeGonemrtspam@spam@iname.com
___________________________________________________________

1998\11\28@045917 by Petar Ristanovic

flavicon
face
Morgan Olsson wrote:
>
> Looks nice!
> I just don4t get what is the limitation of the free version??
> And how much do the full cost?
>
> /Morgan
>         Morgan Olsson                   ph  +46(0)414 70741
>         MORGANS REGLERTEKNIK            fax +46(0)414 70331
>         HDLLEKES           (in A-Z letters: "HALLEKAS")
>         SE-277 35 KIVIK, SWEDEN               RemoveMEmrtspam_OUTspaminame.com
> ___________________________________________________________

Hello,

  The demo version can save files up to 4 KB, Browse and Graphs shows
  limited views.

  "Development Assistant for C" for the PIC compiler costs 330.00 USD,
  Internet delivery also possible for 299.00 USD, payment VISA and
Amex.

Regards,
Petar Ristanovic
----------------------------------------------------------------------
  Petar Ristanovic                       Tel. ++ 41 (0)1 883 35 70
  RistanCASE GmbH                        Fax  ++ 41 (0)1 883 35 74
  Zielackerstrasse 19                   email ristanspamspamRistanCASE.ch
  CH-8304 Wallisellen                WEB: http://www.RistanCASE.ch
----------------------------------------------------------------------


'Air volume flow meter suggestions?'
1998\12\21@132054 by Jon Nicoll
flavicon
face
Hi there
       I'm getting interested in the idea of making an system to
measure the volume of air breathed by a subject. This is likely to have
a PIC in there somewhere, obviously! ;-). I thought I'd ask for previous
experience on this august forum...

I'm somewhat familiar with ways of measuring air speed - am I right in
guessing that the sensible way to measure breathed air would be to
measure the air speed across a known area and integrate etc? I guess the
problems involved in this include:

- relatively low air speed. Also you need to keep the pressure 'normal',
ie I don't want to have to breathe through a narrow tube
- keeping the flow of air uniform across any such cross-section, so that
the speed measurement is a true indication of the volume passing.
Methods of keeping flow laminar? or just calibrate it for innacuracies
somehow...
- discriminating between breathing in and breathing out. Ideally I'd
like to be able to do this automatically (two sensors, detect which
changes first to give the direction?) - otherwise just a valve to make
breathed out air go an  alternate route.
- doing the integrating etc.

As you can probably see, I've only just started thinking of this, but if
anyone has any experience to pass on or pointers to sources of
information, that'd be great, thanks.

       Cheers
       jon Nicoll

1998\12\21@142835 by Keith M. Wheeler

flavicon
face
Jon,

I have no idea if you can find one acceptable for your purposes,
but I would look into automotive-style "hot wire" air mass
sensors.

-Keith Wheeler
ARMA Design                             http://www.ARMAnet.com/

At 06:20 PM 12/21/98 -0000, Jon Nicoll wrote:
>Hi there
>        I'm getting interested in the idea of making an system to
>measure the volume of air breathed by a subject. This is likely to have
>a PIC in there somewhere, obviously! ;-). I thought I'd ask for previous
>experience on this august forum...
>

1998\12\21@155511 by paulb

flavicon
face
Jon Nicoll wrote:

> I'm getting interested in the idea of making an system to measure the
> volume of air breathed by a subject.

 Three methods in common use:

1} Propeller drives optical chopper.  Pony spirometer and others.

2} Pressure differential measured across restriction.  Restriction
consists of multiple planes of mesh for laminar flow.  Welch-Allyn use
this with, I think, a 68HC05.

3} Hot wire, either single or double (records direction and self-
compensates).  Various manufacturers.

> I thought I'd ask for previous experience on this august forum...

 Whoa!  It's December ;-)

> I'm somewhat familiar with ways of measuring air speed - am I right in
> guessing that the sensible way to measure breathed air would be to
> measure the air speed across a known area and integrate etc?

 Integrate flow, yes.

> - relatively low air speed. Also you need to keep the pressure
> 'normal', ie I don't want to have to breathe through a narrow tube

 Sensors have to be accurately scaled for the job.

> - keeping the flow of air uniform across any such cross-section, so
> that the speed measurement is a true indication of the volume passing.
> Methods of keeping flow laminar? or just calibrate it for inacuracies
> somehow...

 (Multiple) mesh planes.

> - discriminating between breathing in and breathing out. Ideally I'd
> like to be able to do this automatically (two sensors, detect which
> changes first to give the direction?)

 Only the single hot wire gives no direction indication.

> - otherwise just a valve to make breathed out air go an alternate
> route.

 Forget it; too complex.

> - doing the integrating etc.

 Use a microprocessor.
--
 Cheers,
       Paul B.

'Air Flow Metering'
1998\12\21@233828 by Keith Schrader P.E.

flavicon
face
Jon

as has been mentioned there are many ways to monitor air flow but one that
comes to mind and will give you the directional data you desire is use two
thermister beads in tandem and tie them into a wheatstone bridge.  What
happens is one will cool faster than the other and unbalence the bridge.
This system can be setup to be extremlly sensitive.

Keith


'PIC FLOWCHARTING PROGRAM?'
1999\02\03@142004 by PDRUNEN
picon face
Hi PIC LISTER,

After spending 2 1/2 weeks solid at 40 + hours a week flowcharting a 3870 line
PIC 16C73 program, I am wandering if there are any automatic flowcharting
resources available?

This would make an interest project and I bet folks like me would purchase
them.

Paul

1999\02\03@142232 by Harrison Cooper

flavicon
face
I usually flow chart as I go...that way you can see potential bugs before
they bite

1999\02\03@153726 by Lyons, Russell M.

flavicon
face
Well,

This sparks another of many great ideas to be entered into the
"I wish I had time to do that " list.

If you write the code first, then want a flowchart couldn't a
semi-intelligent
search routine go through the .ASM file and pick up the labels, goto, call
and decision
making opcodes and come back with some kinda program flow?
Sounds feasible?

And the reverse of this, flowchart first - program generated from flow
chart,
falls into the marketable product category.

Russ L

{Quote hidden}

1999\02\03@154956 by Gerhard Fiedler

picon face
At 15:24 02/03/99 -0500, Lyons, Russell M. wrote:
>And the reverse of this, flowchart first - program generated from flow
>chart,
>falls into the marketable product category.

there are already some products out there which do this. probably none with
a configuration for the pic, but probably at least some of them are
configurable. i think visio can be configured to generate code from the
flowcharts, i'm not sure though.

ge

1999\02\03@155618 by Gerhard Fiedler

picon face
At 15:24 02/03/99 -0500, Lyons, Russell M. wrote:
>And the reverse of this, flowchart first - program generated from flow
>chart,
>falls into the marketable product category.

there are already some products out there which do this. probably none with
a configuration for the pic, but probably at least some of them are
configurable. i think visio can be configured to generate code from the
flowcharts, i'm not sure though.

ge

PS on a second thought: in this case, why not use a compiler (c or other)?
if you really want to, you can use it as a flowchart type thing only, use
only branching and subroutine calling (and not all the various c
specialties) and write all your code as inline assembler. or write c
programs... :-) i've never seen the use for a flow chart with a reasonably
well designed (and written) c program.

1999\02\03@160459 by Harrison Cooper

flavicon
face
oh wait....here we go.  I am currently evaluating a program called STATECAD.
Its a flowchart type thing, and wouldn't ya know it, one of the output
formats is C !!  I'm using it for verilog, but hey....maybe if its ansii C,
it can be preprocessed for targeting a PIC.

Its NOT a hobbyist type price ($1500 or so), but they do give an unlimited
30 day eval.  Cool huh?

http://www.statecad.com

1999\02\03@175204 by PDRUNEN

picon face
In a message dated 99-02-03 14:22:29 EST, you write:

<< I usually flow chart as I go...that way you can see potential bugs before
they bite
 >>

Yep!  That is the way I do it to.  But most of the time as a consultant you
are
given an existing device, existing product specification and new improvements
or wish list as well as a hex file to work with (sometimes not too).  No other
information is available because the other consultant did not give it to them.
he had been in the same boat.

Paul

1999\02\04@171652 by Larry G. Nelson Sr.

flavicon
face
When I was a student at WPI they had a flow charter program that would read
your FORTRAN source code and create a Flowchart on this idea. It was
somewhat stupid but you could then create a better flowchart and use that
output as a guide to be sure you got everything.


At 03:24 PM 2/3/99 -0500, you wrote:
{Quote hidden}

Larry G. Nelson Sr.
RemoveMEL.NelsonRemoveMEspamEraseMEieee.org
http://www.ultranet.com/~nr

'[OT] Kelly Flowers..or anyone else at Allen-Bradle'
1999\02\05@083746 by Harrison Cooper

flavicon
face
sorry all for the post, but I seemed to have lost Kelly's email address.  Or
if anyone else at Allen-Bradley is on here, please email back to me ASAP!!!
KILLspamhcooperspamspamBeGonees.com


'having stock overflow problem'
1999\04\28@195237 by engelec
picon face
part 0 639 bytes content-type:application/x-unknown-content-type-asm_auto_file;I am not good at interrupts so I know I am not using it
right attached code is just a simple 8 LED's back and forward
based on table lookup. I will appreciate if some one can
point me why I am having stock overflow. interrupt routine
has retfie call has retlw when I do stepping I do not see
any stock overflow but when I run it picmaster will halt
after stock overflow any help will highly appreciated.

Andre.

Content-Type: application/x-unknown-content-type-asm_auto_file;
name="74atest.asm"
Content-Disposition: inline;
filename="74atest.asm"

Attachment converted: wonderland:74atest.asm (????/----) (0002EBA9)

'having stack overflow problem'
1999\04\28@211228 by mwestfal

flavicon
face
> I am not good at interrupts so I know I am not using it
> right attached code is just a simple 8 LED's back and forward
> based on table lookup.



Hi, Andre

I think I would handle a table that big like this:

       movf    OFFSET,W    ; get offset
       movwf   SCRATCH     ; and save it
       movlw   LOW TABLE   ; get low bits of table address
       addwf   SCRATCH,F   ; add to saved offset
       movlw   HIGH TABLE  ; get page number of table address
       skpnc               ; did adding offset to table cross page boundary?
       addlw   1           ; yes, add 1 to table page address
       movwf   PCLATH      ; set page number
       movf    SCRATCH,W   ; get table address+offset
       call    TABLE       ; and go get it!


Then do your table like this:
(note MOVWF instead of ADDWF)

TABLE   movwf   PCL
       retlw  0x01
       retlw  0x02
       retlw  0x04

       (etc)


--

-------------------------------------------------------------------------------
Mike Westfall N6KUY
xyzzyspamspamacm.org
RemoveMEmwestfalspamBeGonespamRemoveMEodc.net
http://www.odc.net/~mwestfal/mike.html
Linux religious dogma: "The Gates of Hell shall not prevail."
-------------------------------------------------------------------------------


'=?iso-8859-7?Q?=5B=CF=D4=5D_Flowchart_Program?='
1999\05\16@060733 by Lalakis Parafyadas
picon face
part 0 16 bytes
</x-html>

1999\05\16@161553 by Troy P.

picon face
This is the software that I use.  Its not free but it is about the
best.  All you do is write sentences explaining the process, click a
button and you have a flowchart.  It is great.
http://www.spss.com/software/allclear/

Lalakis Parafyadas wrote:

> Hey! I need a program (prefferably shareware) that can be used to
> create flowcharts (ASM flowcharts as well). Thanks in advance, Argiris

1999\05\16@184058 by Vincent Deno

flavicon
face
Try SmartDraw... you can download a fully functional demo of it.
Additional libraries can also be obtained.  It's not too bad depending on
what you're looking for.

It can be found at:  http://www.smartdraw.com

-Vincent Deno

On Sun, 16 May 1999, Troy P. wrote:

{Quote hidden}

'FLOWCHART FOR PIC [MIGUEL]'
1999\05\20@182426 by WF AUTOMACAO

flavicon
face
Hi there

       In +-15 days, we will have disponible an prototype software
version that creates PIC16F84 assembly source code from a FLOWCHART
graphics!

       At moment, without TIMER and INTERRUPTS...

       It will be BETA test!

       Let me know if you will be interested!

       Thanks!

       Miguel and Drayton

1999\05\20@183510 by Larry Fostano

picon face
In a message dated 5/20/99 5:24:42 PM EST, KILLspamwfspamBeGonespamAMBIENTE.COM.BR writes:

<<
>>
Very interested , how and when do i get a chance to use this beta?

1999\05\20@183726 by engelec

picon face
Miguel and Drayton ,

I liked the idea of using flow chart code generations.
I am interested to see it.


Andre.



WF AUTOMACAO wrote:

{Quote hidden}

1999\05\20@191905 by Fernando Santos

flavicon
face
Ola Miguel
Optima ideia, gostava de testar se possivel

Um abrago
Feranando


WF AUTOMACAO escreveu:

{Quote hidden}

1999\05\20@192527 by wf

flavicon
face
Seu nome foi registrado! Assim que pronta a vers‹o Beta, vamos lhe mandar
para avalia‹o!

(OBS: Sem TIMERS e INTERRUPTS)

Miguel

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

1999\05\20@200702 by Vic Lopez

flavicon
face
yeah!! Bring it on!!
-----Original Message-----
From: Larry Fostano <spamBeGoneOscarr7272spamAOL.COM>
To: spam_OUTPICLISTSTOPspamspamMITVMA.MIT.EDU <RemoveMEPICLISTspamspamMITVMA.MIT.EDU>
Date: Thursday, May 20, 1999 4:40 PM
Subject: Re: FLOWCHART FOR PIC [MIGUEL]


>In a message dated 5/20/99 5:24:42 PM EST, TakeThisOuTwfspamspamRemoveMEAMBIENTE.COM.BR writes:
>
><<
> >>
>Very interested , how and when do i get a chance to use this beta?
>
>

1999\05\21@023756 by Jamil J. Weatherbee

flavicon
face
?? +/- 15 Days
Web Address, I've been working on some similar concepts.


On Thu, 20 May 1999, WF AUTOMACAO wrote:

{Quote hidden}

1999\05\21@030320 by Graeme Odgers

flavicon
face
At 07:19  20/05/99 -0700, you wrote:

Hello Miguel,

Sign me up as a beta tester its sounds veeerrry interesting.

Regards,
Graeme Odgers

{Quote hidden}

1999\05\21@032408 by Peter Homann

picon face
Hi,

I am interested in being a Beta tester.

Thanks,

Peter.
---
Peter Homann    Email:  KILLspampeterhspamspamspam_OUTadacel.com.au
Adacel Technologies Ltd _/_/_/ _/_/_/ _/ Phone:   +61 3 9596 2991
250 Bay St, Brighton   _/  _/   _/   _/  Fax:     +61 3 9596 2960
Victoria  3186        _/_/_/   _/   _/   Home:    +61 3 9555 5603
AUSTRALIA            _/  _/   _/   _/_/_/Mobile:      0414-494578
------------------------------------------------------------------------


|  {Original Message removed}

1999\05\21@034107 by g.daniel.invent.design

flavicon
face
I volunteer to *test* the final version.

1999\05\21@052322 by Fontana Pasquale

flavicon
face
YES
I'm very interested!!!
Also  for any other emulator-simulator for
12cXXX.
Thanks
Pasquale

WF AUTOMACAO ha scritto:

{Quote hidden}

1999\05\21@072755 by Anbar

flavicon
face
Ola Miguel
Gostaria se possivel conhecer e testar tambem seu Beta
Sem Mais
Luis Fernando

-----Mensagem original-----
De: wf <wfRemoveMEspamAMBIENTE.COM.BR>
Para: EraseMEPICLISTSTOPspamspamRemoveMEMITVMA.MIT.EDU <spam_OUTPICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU>
Data: Quinta-feira, 20 de Maio de 1999 16:23
Assunto: Re: FLOWCHART FOR PIC [MIGUEL]


Seu nome foi registrado! Assim que pronta a versco Beta, vamos lhe mandar
para avaliagco!

(OBS: Sem TIMERS e INTERRUPTS)

Miguel

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

1999\05\21@091542 by Aidi Moubhij

flavicon
face
I'm very interested , I like to get the beta software.

At 07:19 PM 5/20/99 -0700, you wrote:
>Hi there
>
>        In +-15 days, we will have disponible an prototype software
>version that creates PIC16F84 assembly source code from a FLOWCHART
>graphics!
>
>        At moment, without TIMER and INTERRUPTS...
>
>        It will be BETA test!
>
>        Let me know if you will be interested!
>
>        Thanks!
>
>        Miguel and Drayton
>
Aidi Moubhij

spamaidi.....spamspammjr.com

'Final software (was Re: FLOWCHART FOR PIC [MIGUEL]'
1999\05\21@141402 by Eric Smith

flavicon
face
> I volunteer to *test* the final version.

If it's like most software, you'll be waiting a long time for that.

When's the *final* version of Windows due out?  :-)

'FLOWCHART FOR PIC [MIGUEL]'
1999\05\21@150208 by Sibert, Steve

flavicon
face
I'd like one too please!

Thanks!

Steve Sibert

-----Original Message-----
From: WF AUTOMACAO [wfspam_OUTspam@spam@AMBIENTE.COM.BR]
Sent: Thursday, May 20, 1999 8:19 PM
To: .....PICLISTspamspam.....MITVMA.MIT.EDU
Subject: FLOWCHART FOR PIC [MIGUEL]


Hi there

       In +-15 days, we will have disponible an prototype software
version that creates PIC16F84 assembly source code from a FLOWCHART
graphics!

       At moment, without TIMER and INTERRUPTS...

       It will be BETA test!

       Let me know if you will be interested!

       Thanks!

       Miguel and Drayton

1999\05\21@152839 by Jeff Webster

picon face
WF AUTOMACAO wrote:
>
> Hi there
>
>         In +-15 days, we will have disponible an prototype software
> version that creates PIC16F84 assembly source code from a FLOWCHART
> graphics!
>
>         At moment, without TIMER and INTERRUPTS...
>
>         It will be BETA test!
>
>         Let me know if you will be interested!
>
>         Thanks!
>
>         Miguel and Drayton
I wouild also be interested in testing for you.
Jeff Webster

'RV: Re: FLOWCHART FOR PIC [MIGUEL]'
1999\05\21@170640 by Marcos Migliorini

flavicon
face
Me too !
Thanks
Marcos Migliorini
----- Mensaje original -----
De: Peter Homann <peterhKILLspamspamEraseMEADACEL.COM.AU>
Para: <EraseMEPICLIST@spam@spam@spam@MITVMA.MIT.EDU>
Enviado: Viernes, 21 de Mayo de 1999 04:42 a.m.
Asunto: Re: FLOWCHART FOR PIC [MIGUEL]


{Quote hidden}

> |  {Original Message removed}

1999\05\21@230702 by Jim Paul

picon face
I too would be interested in trying this softwarefor you.
Please send me a copy.

                                                           Thanks and
Regards,


Jim

{Original Message removed}

'FLOWCHART FOR PIC [MIGUEL]'
1999\05\22@203614 by lucy

flavicon
face
hi,

I too would be interested in trying this softwarefor you.
Please send me a copy.

lucy

spamBeGonelucyRemoveMEspamEraseME371.net

>
> >>
> >>
>  |  {Original Message removed}

1999\05\23@211329 by PDRUNEN

picon face
I need something that goes the other way, that is, will take PIC code and
create a flowchart.  It could be like a graphic interface to smartdraw or
CLEAR 4.0.

I had to manual take a 5000 line PIC program into flowchart format and I put
about 2.5 man-months (160hr/month) into it.  It would have been nice to have
a PIC to flowchart generator.

With the PIC only having 32 inst it should be a nice project for someone.

Paul

1999\05\23@211537 by Jamil J. Weatherbee

flavicon
face
in that time you could of probably written the software yourself.


On Sun, 23 May 1999 RemoveMEPDRUNENKILLspamspamRemoveMEAOL.COM wrote:

{Quote hidden}

'Final software (was Re: FLOWCHART FOR PIC [MIGUEL]'
1999\05\24@043208 by Tom Handley

picon face
At 06:12 PM 5/21/99 -0000, Eric Smith wrote:
>If it's like most software, you'll be waiting a long time for that.
>
>When's the *final* version of Windows due out?  :-)

  o/~ In the year 2525. If mankind is still alive... o/~

  Sorry for the [OT] but it's spring in Oregon, the rain has stopped
for a day or few, there's this strange bright light to the South, I'm
working in my garden, and I'm confused... Like transplants, when the
sun comes out, we need to go outside and be `hardened'. ;-)

  - Tom

'FLOWCHART FOR PIC [MIGUEL]'
1999\05\24@092916 by k Robert E SSgt

flavicon
face
gimmie gimmie gimmie gimmie!!!!!    ;-)

-Robb

-----Original Message-----
From: WF AUTOMACAO [TakeThisOuTwfspamAMBIENTE.COM.BR]
Sent: Thursday, May 20, 1999 8:19 PM
To: spamBeGonePICLISTKILLspamspamTakeThisOuTMITVMA.MIT.EDU
Subject: FLOWCHART FOR PIC [MIGUEL]


Hi there

       In +-15 days, we will have disponible an prototype software
version that creates PIC16F84 assembly source code from a FLOWCHART
graphics!

       At moment, without TIMER and INTERRUPTS...

       It will be BETA test!

       Let me know if you will be interested!

       Thanks!

       Miguel and Drayton

1999\05\24@133353 by Alvaro Deibe Diaz

flavicon
face
Me too, please!

>
>Hi there
>
>        In +-15 days, we will have disponible an prototype software
>version that creates PIC16F84 assembly source code from a FLOWCHART
>graphics!
>
>        At moment, without TIMER and INTERRUPTS...
>
>        It will be BETA test!
>
>        Let me know if you will be interested!
>
>        Thanks!
>
>        Miguel and Drayton
>

1999\05\24@140513 by mike

picon face
I would be interested in doing beta testing

Mike

--- Alvaro Deibe Diaz <EraseMEadeibe.....spamKILLspamCDF.UDC.ES> wrote:
{Quote hidden}

_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

1999\05\25@002625 by Pablo De Leon

picon face
I like to be your beta tester.

Atte: Pablo De Leon
spampdeleonspambigfoot.com

1999\05\26@184248 by D'hondt Jean-Paul

flavicon
face
Please include me too

on4bdjSTOPspamspamPANDORA.BE
-----Oorspronkelijk bericht-----
Van: WF AUTOMACAO <wfSTOPspamspamKILLspamAMBIENTE.COM.BR>
Aan: @spam@PICLIST.....spamspamMITVMA.MIT.EDU <spamPICLIST.....spam.....MITVMA.MIT.EDU>
Datum: vrijdag 21 mei 1999 0:24
Onderwerp: FLOWCHART FOR PIC [MIGUEL]


{Quote hidden}


'FLOWCHART FOR PIC [MIGUEL]'
1999\06\03@094741 by FONTANA Pasquale
flavicon
face
YES
I'm very interested!!!
Also  for any other emulator-simulator for
12cXXX.
Thanks
Pasquale

WF AUTOMACAO ha scritto:

{Quote hidden}

1999\06\03@213053 by Donald Kihenja

picon face
----- Original Message -----
From: FONTANA Pasquale <llfonta.....spamTIN.IT>
To: <KILLspamPICLISTspam_OUTspamMITVMA.MIT.EDU>
Sent: Thursday, June 03, 1999 10:49 AM
Subject: Re: FLOWCHART FOR PIC [MIGUEL]


YES
I'm very interested too! Thanks for the offer.
Thanks
Donald


WF AUTOMACAO ha scritto:

Hi there

        In +-15 days, we will have disponible an prototype software
version that creates PIC16F84 assembly source code from a FLOWCHART
graphics!

        At moment, without TIMER and INTERRUPTS...

        It will be BETA test!

        Let me know if you will be interested!

        Thanks!

        Miguel and Drayton

1999\06\16@191654 by wf

flavicon
face
       Hi there,

       The Flowchart for PIC16F84 is on the following address for download...

       http://www.blusoft.org.br/wf/pic.zip

       It's an academic work, and your comments will be important for my studen
t
to put in his academic report!  The author is Drayton.

       Your suggestions and critics will be great for this Software, and don't
forget, it's an academic work, it's no free of bugs!

       There is no help! We did this, because we want to know if the software i
s
easy to understand...

       Let me know if you authorize to publish your comments!

       Thanks!

       Miguel

       PS: e-mail for spam_OUTwfspamTakeThisOuTambiente.com.br and .....drayton.....spamRemoveMEinf.furb.rct-sc.br

       (  ) Yes, i authorize to publish your comments

'FLOWCHART FOR WINDOWS'
1999\06\16@192322 by - KITS EDUCACIONAIS NACIONAIS

flavicon
face
Hi there,

       The Flowchart for PIC16F84 is on the following address for download...

       http://www.blusoft.org.br/wf/pic.zip

       It's an academic work, and your comments will be important for my studen
t
to put in his academic report!  The author is Drayton.

       Your suggestions and critics will be great for this Software, and don't
forget, it's an academic work, it's no free of bugs!

       There is no help! We did this, because we want to know if the software i
s
easy to understand...

       Let me know if you authorize to publish your comments!

       Thanks!

       Miguel

       PS: e-mail for spam_OUTwfTakeThisOuTspamEraseMEambiente.com.br and EraseMEdraytonspamBeGonespamKILLspaminf.furb.rct-sc.br

       (  ) Yes, i authorize to publish your comments


'Fuel Flow Sensor'
1999\11\04@090046 by John Mullan
flavicon
face
I stumbled across a PIC related page that mentions a "fuel sensor" by Radionics. I am unable to find this beast on the Internet. Does anybody know of this or similar device that will send pulses as fuel flows through the line???? Thanks John Mullan ----------------------------------------------------
If you have ICQ you can message me. My ICQ#:9459480
Or visit my Personal ICQ Homepage: http://members.icq.com/9459480
My current status is:
If you don't have ICQ you can page me through my Personal Communication Center: http://wwp.icq.com/9459480 (go there and try it!)
Or
You can send me a regular e-mail to my EmailExpress address: 9459480@pager.icq.com
If you want to add me to your Contact List click Add Me
Download ICQ at http://www.icq.com/
Include your ICQ details in YOUR e-mail signature: http://www.icq.com/emailsig.html
John Mullan

1999\11\04@121300 by Keelan Lightfoot

flavicon
face
I was bored, so I searched it out.

I eventually searched Altavista for "liquid flow sensor" and found a bunch
of wrong things, and a few good things.

http://www.mcmillancompany.com/products/101.htm

I don't know if it will blow up with something flammable, but by the looks
of it, it is designed to be safe. I would ask them, anyway.

It doesn't provide pulses for it's output, but rater a 0-5v signal,
corresponding to a 0-100% flow.

They provide a few other flow sensors -- high pressure, Teflon coated
innards some that provide pulsed output, etc. Have a look at:

http://www.mcmillancompany.com/products.htm

Also, just found this, and it looks like this could be a _great_ help. Just
put in all your specs, click search, and it lists all that look like they
might be what you want.

http://www.designinfo.com/scripts/makeframe.dll?Url=http%3A//http://www.designinfo.
com/help/Flow.html

- Keelan Lightfoot

>I stumbled across a PIC related page that mentions a "fuel sensor" by Radionics
.
>
>I am unable to find this beast on the Internet.
>
>Does anybody know of this or similar device that will send pulses as fuel
>flows through the line????

1999\11\04@130150 by Don Hyde

flavicon
face
> >I stumbled across a PIC related page that mentions a "fuel sensor" by
> Radionics.
> >
> >I am unable to find this beast on the Internet.
> >
> >Does anybody know of this or similar device that will send pulses as fuel
> >flows through the line????
       [Don Hyde]
       Here's a link to a guy who makes a cool instrument package for
experimental airplanes.  He publishes a separate price for his sensor, which
I believe is the same one that's used in some production airplanes, and is
FAA-certified for aircraft use.  It's expensive, of course, it says
"airplane".  It may be the "Radionics" unit you're looking for.

       http://rkymtn.com/rm00021.htm

1999\11\04@223822 by John Mullan

flavicon
face
Well, I found a few things, but this site give me the best stuff.

http://www.oztechnics.com.au/car.htm

I just need to find out if they sell the flow sensors seperately.

Also, the fuel injection consumption method they describe is perfect.

Thanks for everyone's response.

John mullan.

1999\11\05@211631 by Brian Kraut

picon face
I don't know about that one, but I do know that Floscan is one of te leaders in fuel flow measuring. Don't have their number handy. John Mullan wrote: > I stumbled across a PIC related page that mentions a "fuel sensor" by Radionic s. > > I am unable to find this beast on the Internet. > > Does anybody know of this or similar device that will send pulses as fuel flow s through the line???? > > Thanks > > John Mullan > > > > > > > ----------------------------------------------------
> If you have ICQ you can message me. My ICQ#:9459480
> Or visit my Personal ICQ Homepage: http://members.icq.com/9459480
> My current status is:
> If you don't have ICQ you can page me through > my Personal Communication Center: http://wwp.icq.com/9459480 (go there and try it!)
> Or
> You can send me a regular e-mail to my EmailExpress address: 9459480@pager.icq .com
> If you want to add me to your Contact List click Add Me
> Download ICQ at http://www.icq.com/
> Include your ICQ details in YOUR e-mail signature: http://www.icq.com/emailsig.html
> John Mullan
> >


'HITECH PICC - Linker error - Fixup overflow in exp'
2000\01\10@035509 by Michael Killeen
flavicon
face
Hello

I am getting the following linker errors when using  the HITECH PICC
compiler

kbd.obj:46:Fixup overflow in expression (loc 0x2390 (0x234E+66), size
1,value 0x19B) (error)


Can anyone relate the line number in the .obj file or other information back
to the source code ?

or

Does anyone have a list of typical code examples that cause this error ?
(the error description is not so clear in the manual)

Thank you
Regards
Michael

2000\01\10@132205 by Andrew E. Kalman

picon face
Re:
>Hello
>
>I am getting the following linker errors when using  the HITECH PICC
>compiler
>
>kbd.obj:46:Fixup overflow in expression (loc 0x2390 (0x234E+66), size
>1,value 0x19B) (error)

These are tough to understand - but there is a FAQ on Hi-Tech's web site
that addresses this exact issue ...


______________________________________
 Andrew E. Kalman, Ph.D.   RemoveMEaekspamBeGonespamspamnetcom.com


'Flow chart for Graphic LCD to PIC interface.'
2000\02\24@170930 by smerchock, Steve
flavicon
face
part 0 1223 bytes
<P><FONT SIZE=2>Friends,</FONT>
<BR><FONT SIZE=2>I am having some problems getting my LCD (&quot;AND1391&quot;=128x128)</FONT>
<BR><FONT SIZE=2>to work with my PIC. I'm not sure what the proper process is</FONT>
<BR><FONT SIZE=2>to get the darn thing to show something. Does anybody know or have, a</FONT>
<BR><FONT SIZE=2>flow chart of the events required to use a graphic LCD? I would </FONT>
<BR><FONT SIZE=2>appreciate any and all help. Thanks in advance!!</FONT>
</P>
<BR>

<P><FONT SIZE=2>Best regards,</FONT>
<BR><FONT SIZE=2>Steve</FONT>
</P>
<BR>

<P><FONT SIZE=2>Steven Kosmerchock</FONT>
<BR><FONT SIZE=2>Father/Student/Engineering Technician</FONT>
<BR><FONT SIZE=2>http://www.geocities.com/researchtriangle/lab/6584 </FONT>
</P>

<P><FONT SIZE=2>&quot;Great spirits have always encountered violent </FONT>
<BR><FONT SIZE=2>oppposition from mediocre minds.&quot;--A.Einstein</FONT>
</P>

</BODY>
</HTML>
</x-html>


'*.asm to flow'
2000\04\02@205232 by Gordon Varney
flavicon
face
Does anyone out there know of a program that will read my *.asm file and
give me a flow chart?

I believe this would be a great tool, for double checking the operation of
our source code.

Gordon Varney


'How to know it there a current is flowing...'
2000\05\15@211250 by Gabriel Caffese
flavicon
face
Hello,

       I need to know if a small current, that falls between 0.2ma and 3ma,
flows over a pair of copper wires of printed circuit boards.
       Those printed circuit boards cannot be touched, and I cannot insert
any standard measurement equipment, because there is no available space as
to do that.
       The only way (I think) , is to use something like a Hall effect
transistor, wich can be hardly put (but can at last), below the printed
circuit boards that are being inserted.
       So, I would like to know if someone has ever done something like
this before, and, if I am on the right way, and this can be done.

           Hope to receive news from you !!!!

2000\05\15@214203 by Chris Eddy

flavicon
face
The copper traces have a small but measureable resistance.  Try measuring a
voltage drop across them in circuit.  Watch out, cause if you change the plating
or copper thickness on the board, that resistance may change.  How accurate do
you need to be?

Chris Eddy

Gabriel Caffese wrote:

> Hello,
>
>         I need to know if a small current, that falls between 0.2ma and 3ma,
> flows over a pair of copper wires of printed circuit boards.

2000\05\16@022147 by Vasile Surducan

flavicon
face
On 15 May 00, at 21:56, Gabriel Caffese wrote:

> Hello,
>
>         I need to know if a small current, that falls between 0.2ma and 3ma,
> flows over a pair of copper wires of printed circuit boards.

  It's important to know: it's a DC, AC or pulse current ? the method
would be slightly different ... The simplest solution is to find the end
of the circuit and to insert a resistor in circuit . Next with a scope
you'll find everything... BTW what is this ''martian'' un-touch-able
circuit?

  Vasile


{Quote hidden}

*********************************************
Surducan Vasile, engineer
mail: @spam@vasilespamspaml30.itim-cj.ro
URL: http://www.geocities.com/vsurducan
*********************************************

'[OT] [EE] Current is Flowing'
2000\05\16@101531 by Mark Peterson

flavicon
face
>From:    Gabriel Caffese <TakeThisOuTgabrielsdiKILLspamspam@spam@IMPSAT1.COM.AR>
>Subject: How to know it there a current is flowing...
>

>Hello,
>
>        I need to know if a small current, that falls between 0.2ma and
3ma,
>flows over a pair of copper wires of printed circuit boards.
>        Those printed circuit boards cannot be touched, and I cannot
insert
>any standard measurement equipment, because there is no available space as
>to do that.
>        The only way (I think) , is to use something like a Hall effect
>transistor, wich can be hardly put (but can at last), below the printed
>circuit boards that are being inserted.
>        So, I would like to know if someone has ever done something like
>this before, and, if I am on the right way, and this can be done.
>
>            Hope to receive news from you !!!!

You could use a Hall effect, either open loop or closed loop.  In open
loop, the amplified output of a Hall element is directly used as the
measurement value.  Offset and drift are determined by the Hall element and
the amplifier.  These sensors have low price but also have low sensitivity.
For closed loop, the Hall voltage developed across the sensor, that is
placed in the gap of a magnetic core that surrounds one of your conductors,
is highly amplified and the amplifier's output current then flows through a
compensation coil wound on the same magnetic core.  It generates a magnetic
field that has the same amplitude but opposite direction as the field due
to current flow in the monitored conductor.  The result is that the
magnetic flux in the core is compensated to zero.  Closed loop sensors are
more sensitive and precise, but they also require more cost and effort to
implement.

Another option is the use of a magnetoresistive sensor.  These are devices
that have ferromagnetic materials deposited as thin films in narrow strips
while in a magnetic field.  The resistance of this material varies in
relation to the magnitude of a magnetic field they are placed in.  They are
usually used in a bridge arangement and offer good sensitivity.  Their
linearity is not very high so the same compensation principle used with the
closed loop Hall sensors should be used with these.

Mark P

'[OT] [EE] Reply to "Is Current Flowing?"'
2000\05\16@110835 by Mark Peterson

flavicon
face
>From:    Gabriel Caffese <.....gabrielsdiRemoveMEspamIMPSAT1.COM.AR>
>Subject: How to know if there a current is flowing...
>

>I need to know if a small current, that falls between 0.2ma and 3ma,
>flows over a pair of copper wires of printed circuit boards.
>Those printed circuit boards cannot be touched, and I cannot insert
>any standard measurement equipment, because there is no available space as
>to do that.
>The only way (I think) , is to use something like a Hall effect
>transistor, wich can be hardly put (but can at last), below the printed
>circuit boards that are being inserted.

You could use a Hall effect, either open loop or closed loop.  In open
loop, the amplified output of a Hall element is directly used as the
measurement value.  Offset and drift are determined by the Hall element and
the amplifier.  These sensors have low price but also have low sensitivity.
For closed loop, the Hall voltage developed across the sensor, that is
placed in the gap of a magnetic core that surrounds one of your conductors,
is highly amplified and the amplifier's output current then flows through a
compensation coil wound on the same magnetic core.  It generates a magnetic
field that has the same amplitude but opposite direction as the field due
to current flow in the monitored conductor.  The result is that the
magnetic flux in the core is compensated to zero.  Closed loop sensors are
more sensitive and precise, but they also require more cost and effort to
implement.

Another option is the use of a magnetoresistive sensor.  These are devices
that have ferromagnetic materials deposited as thin films in narrow strips
while in a magnetic field.  The resistance of this material varies in
relation to the magnitude of a magnetic field they are placed in.  They are
usually used in a bridge arangement and offer good sensitivity.  Their
linearity is not very high so the same compensation principle used with the
closed loop Hall sensors should be used with these.

Mark P

2000\05\16@113624 by Mark Peterson

flavicon
face
You could use a Hall effect, either open loop or closed loop.  In open
loop, the amplified output of a Hall element is directly used as the
measurement value.  Offset and drift are determined by the Hall element and
the amplifier.  These sensors have low price but also have low sensitivity.
For closed loop, the Hall voltage developed across the sensor, that is
placed in the gap of a magnetic core that surrounds one of your conductors,
is highly amplified and the amplifier's output current then flows through a
compensation coil wound on the same magnetic core.  It generates a magnetic
field that has the same amplitude but opposite direction as the field due
to current flow in the monitored conductor.  The result is that the
magnetic flux in the core is compensated to zero.  Closed loop sensors are
more sensitive and precise, but they also require more cost and effort to
implement.

Another option is the use of a magnetoresistive sensor.  These are devices
that have ferromagnetic materials deposited as thin films in narrow strips
while in a magnetic field.  The resistance of this material varies in
relation to the magnitude of a magnetic field they are placed in.  They are
usually used in a bridge arangement and offer good sensitivity.  Their
linearity is not very high so the same compensation principle used with the
closed loop Hall sensors should be used with these.

Mark P

'[OT] [EE] Current is Flowing'
2000\05\16@115723 by jamesnewton

face picon face
Mark, Thank you very much for replying to this post and adding the correct
tags in the subject line. Well Done! It is a great boost to the moral of
your hard working admins to know that at least some people are listing, care
about the list, and are willing to take a few moments to do what it best for
it.

---
James Newton (PICList Admin #3)
KILLspamjamesnewtonspamTakeThisOuTpiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}


'[PICLIST] UARTless & Interruptless RS232 flow cont'
2000\07\01@231554 by Keelan Lightfoot
flavicon
face
I am trying to implement rs-232 communication on a UARTless pic (16F84 --
surprise, surprise :). I have the code created to send and recieve data via
any pin, and that works fine, the problem now is flow control... It's for an
LCD serializer, and I need the PC to stop talking when I'm busy working with
the LCD module... I can twiddle with CTS, but apparently, the 16550 UART
(and derivitaves thereof) sends 8 bytes even after the CTS line has been
cleared... (the 8250 is apparently not guilty of this crime)

My serial code is of the non-interrupt-driven variety.

How can I make this work? I have tried different thoughts like using a small
FIFO, etc., but none of these seem to want to work... I'm stuck... Is it
something I'm not thinking about, or is it not possible, or what?

I don't wanna use the 'solution' of telling my computer that it's 16550 is
actually an 8250, I wanna have this work with any computer...

Any suggestions?

Thanks in advance :)
- Keelan Lightfoot

2000\07\02@001159 by Dan Welch - W6DFW

flavicon
face
At 09:13 PM 7/1/00 -0600, you wrote:
Configure your PC for Xon/Xoff flow control you then  send an Xoff, (Ctl
S), to stop the data flow and a Xon, (Ctl Q), to restart the data flow.

-Dan TakeThisOuTw6dfwspamspam_OUTqsl.net

{Quote hidden}

- Dan       Email: RemoveMEdanspamspamSTOPspambyonics.com

See the GST-1 Converter for Earthmate GPS units at:
http://www.byonics.com/gst-1

2000\07\02@034135 by Keelan Lightfoot

flavicon
face
What about the byte the PC is sending while i'm sending the Xoff byte?
Wouldn't it be lost, or does the PC resend that possibly lost byte the next
time it receives an Xon?

- Keelan

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

-- snip --

> - Dan       Email: .....danEraseMEspambyonics.com
>
>See the GST-1 Converter for Earthmate GPS units at:
> http://www.byonics.com/gst-1

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

'[OT]: UARTless & Interruptless RS232 flow control'
2000\07\02@090415 by Bob Ammerman

picon face
Maybe this will do it:

1: Maintain  a buffer that has room for about 10 characters.

2: When receiving, as soon as you get a character immediately drop CTS.

3: The PC will continue to send for a bit. Receive those characters and put
them in the local buffer. Note that the 16550 will send the characters one
right after the other, so if more than a few bit times go by without seeing
a start bit then you know no more bytes will be coming.

4: Process the characters in the buffer.

5: Raise RTS.

6: Go back to step 2.

Bob Ammerman
RAm Systems
(high performance, high function, low-level software)

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\02@092947 by Dan Welch - W6DFW

flavicon
face
At 01:40 AM 7/2/00 -0600, you wrote:
>What about the byte the PC is sending while i'm sending the Xoff byte?


The P.C. will not resend the byte, if there was a byte in transit when you
sent out the Xoff you will need to receive it or ignore it as the case may be.

Your code should be written so that you acquire input data
during the time that you are sending data, (E.G. between
sending bits you receive bits).  If you are doing this then
you won't loose anything.  This is one argument for
interrupt driven comm but it is certainly possible to structure your code
so as to send and receive at th same time.

{Quote hidden}

- Dan       Email: RemoveMEdanRemoveMEspamRemoveMEbyonics.com

See the GST-1 Converter for Earthmate GPS units at:
http://www.byonics.com/gst-1

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\02@114242 by w. v. ooijen / f. hanneman

picon face
I always use a full-echo protocol for communication between a PC and a PIC:
PC sends a char, and must wait until it has received the echo before
sending the next char. PIC sends only on request, a special char is
reserved to ask to PIC to send its next char. Note that the PIC must send
something, so when it has nothing it must send a dummy char. When the PC
has not received a response for 1 second it is allowed to retry (happends
almost never).
Wouter

----------
> From: Keelan Lightfoot <keelanKILLspamspamspamMAIL.BZZZZZZ.COM>
> To: spam_OUTPICLIST@spam@spamMITVMA.MIT.EDU
> Subject: UARTless & Interruptless RS232 flow control
> Date: Sunday, July 02, 2000 05:13
>
> I am trying to implement rs-232 communication on a UARTless pic (16F84 --
> surprise, surprise :). I have the code created to send and recieve data
via
> any pin, and that works fine, the problem now is flow control... It's for
an
> LCD serializer, and I need the PC to stop talking when I'm busy working
with
> the LCD module... I can twiddle with CTS, but apparently, the 16550 UART
> (and derivitaves thereof) sends 8 bytes even after the CTS line has been
> cleared... (the 8250 is apparently not guilty of this crime)
>
> My serial code is of the non-interrupt-driven variety.
>
> How can I make this work? I have tried different thoughts like using a
small
> FIFO, etc., but none of these seem to want to work... I'm stuck... Is it
> something I'm not thinking about, or is it not possible, or what?
>
> I don't wanna use the 'solution' of telling my computer that it's 16550
is
> actually an 8250, I wanna have this work with any computer...
>
> Any suggestions?
>
> Thanks in advance :)
> - Keelan Lightfoot

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\02@145403 by Peter L. Peres

picon face
imho, fix your protocol on the transmit side so it throttles data after
certain characters. Terminal driver code has been doing this since
teletypes ruled the earth. Sending CTS to the computer becomes a problem
because the 16550 has FIFOs that are 16+1 (for the THR) long. You probably
can't store 17 bytes in the PIC. If you can, then do. Else tell users to
go into control panel->serial->settings (advanced I think) and set the Tx
FIFO threshold low for that port. That and CTS will probably fix it, you
still need a 2 deep FIFO on the PIC.

LCDs are controlled SO much better from the parallel port...

Peter

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\03@151111 by briang

flavicon
face
In-Reply-To: <TakeThisOuT1249614865-1892829spam_OUTspammail.bzzzzzz.com>

Keelan Lightfoot <KILLspamkeelan.....spamTakeThisOuTMAIL.BZZZZZZ.COM> wrote:
>
> I am trying to implement rs-232 communication on a UARTless pic (16F84 --
> surprise, surprise :). I have the code created to send and recieve data via
> any pin, and that works fine, the problem now is flow control... It's for an
> LCD serializer, and I need the PC to stop talking when I'm busy working with
> the LCD module... I can twiddle with CTS, but apparently, the 16550 UART
> (and derivitaves thereof) sends 8 bytes even after the CTS line has been
> cleared... (the 8250 is apparently not guilty of this crime)

the 16550 can send up to 16 or 17 bytes after CTS is dropped.

{Quote hidden}

If you can choose the protocol used to talk to the PIC then one solution is to
design the protocol so that receipt of each command sequence has to be
acknowledged by the PIC before you send the next.

You can acknowledge by sending a certain control character (an ACK maybe) back
to the PC.

What baud rate are you using and is the clock spped of the PIC?

Brian Gregory.
TakeThisOuTbriangEraseMEspamRemoveMEcix.co.uk

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\03@151114 by briang

flavicon
face
In-Reply-To: <spam_OUT3.0.1.32.20000701205945.009115f0RemoveMEspam.....mail.byonics.com>

Dan Welch - W6DFW <spamdanKILLspamspamKILLspamBYONICS.COM> wrote:
>
> At 09:13 PM 7/1/00 -0600, you wrote:
> Configure your PC for Xon/Xoff flow control you then  send an Xoff, (Ctl
> S), to stop the data flow and a Xon, (Ctl Q), to restart the data flow.
>
> -Dan spamw6dfwspam_OUTspamqsl.net

This would make no difference.

A PC with a 16550 is no better at XON/XOFF flow control that it is at RTS/CTS
flow control.

Brian Gregory.
STOPspambriangspam_OUTspamspamBeGonecix.co.uk

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\03@155232 by Keelan Lightfoot

flavicon
face
So, it looks like flow control via CTS/Xon/Xoff is out...

I can't really choose the protocol, I wanted this to be just a simple serial
device (no special software requirements)... I had made a successful module
before by communicating with it at 1200 baud, no parity, 8 data bits, and
*2* stop bits - the 2 stop bits gave the PIC enough time to deal with the
data. I was using a 4 MHz clock, running my 10 MHz LCD code (LCD delays not
reduced for the slower clock), so, by moving to a 10 MHz clock, I would
spend half as much time talking to the LCD.. I might be able to jump to 2400
baud, N82 or 1200 baud, N81 - I would have half of the last bit, and a full
stop bit of 'spare' time to work with the data from the PC.. 1200 is a bit
slow for the LCD module (refresh is noticible), but I don't think 2400 would
be...

My original intentions were 9600 baud and a 10 MHz clock speed, though
necessity might require less...

- Keelan

--- Original Message ---
>Brian Gregory Wrote:

-- snip --

>the 16550 can send up to 16 or 17 bytes after CTS is dropped.

-- snip --

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\03@172319 by Bob Ammerman

picon face
This really ought to work for you:

1: Set up a buffer that has room for 1 + the maximum number of 'dribble'
characters that can be received from the 16550.

2: When receiving, as soon as you get the first character, then immediately
drop CTS.

3: The PC will continue to send for a while. Receive those characters and
put them in the buffer. Note that the 16550 will send the characters one
right after the other, so if more than a few bit times go by without seeing
a start bit then you know no more bytes will be coming.

4: Process _all_ the characters in the buffer.

5: Raise RTS.

6: Go back to step 2.

Bob Ammerman
RAm Systems
(high performance, high function, low-level software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\04@143534 by Peter L. Peres

picon face
Sorry if I post 2 x but the tag system begins to bug me. I simply respond
to a message in a thread that already exists and I do not feel appointed
to add a tag to it. Then I get a warning and I don't see my message, so I
repost, after someone adds a tag. And I will keep doing this until the
mixup about responders to untagged threads being innocently flogged is
resolved ;-)

---------- Forwarded message ----------
Date: Sun, 2 Jul 2000 21:53:47 +0300 (IDT)
From: "Peter L. Peres" <EraseMEplpspamKILLspamplp.plp.home.org>
To: pic microcontroller discussion list <EraseMEpiclistRemoveMEspammitvma.mit.edu>
Subject: UARTless & Interruptless RS232 flow control


imho, fix your protocol on the transmit side so it throttles data after
certain characters. Terminal driver code has been doing this since
teletypes ruled the earth. Sending CTS to the computer becomes a problem
because the 16550 has FIFOs that are 16+1 (for the THR) long. You probably
can't store 17 bytes in the PIC. If you can, then do. Else tell users to
go into control panel->serial->settings (advanced I think) and set the Tx
FIFO threshold low for that port. That and CTS will probably fix it, you
still need a 2 deep FIFO on the PIC.

LCDs are controlled SO much better from the parallel port...

Peter

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu>

2000\07\04@171113 by briang

flavicon
face
In-Reply-To: <@spam@1249468710-6738570EraseMEspamspammail.bzzzzzz.com>

In reply to Keelan Lightfoot <keelanTakeThisOuTspamKILLspamMAIL.BZZZZZZ.COM>:

Why can't you use a PIC with a UART?

If you really can't use one with a UART you might be able to simulate
one with a PIC running really fast by having tick interrupts going at a
multiple of the baud rate - minimum 3 times the baud rate, preferably
five times.

Brian Gregory.
RemoveMEbriangTakeThisOuTspamcix.co.uk

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestSTOPspamspammitvma.mit.edu>

2000\07\06@031219 by Tim Forcer

flavicon
face
Sorry to come in late on this one.  Couple of suggestions, following a
recent project using an '84 talking to a PC (plus doing other stuff).

I used the Maxim MAX3110 IC which provides in one 28-pin IC both a
SERIAL-access UART and a dual TTL/RS232 transceiver set.  Of the 28 pins
you only need to get at 13, the rest being connections to the charge pumps
for linking the UART to the transceivers, so the whole thing could have
fitted in a 14 pin package.  None the less this is a VERY useful device.
With the '84 running a 4MHz resonator, the UART handler code has no waits.
The UART doesn't have auto-handling of CTS/RTS - they need to be read/set
explicitly, but it DOES have a 9-byte FIFO buffer on incoming.  It also has
an interrupt output, which I didn't use as it wasn't necessary or even
appropriate for my application.  Sending and collecting bytes by the PIC at
maximum PIC speed means that even at 19200 baud there's a fair bit of
"spare" time to do other things between reads/writes.

So much for the PIC end.  Yes, I know it's an extra IC, but most of the
time there's a MAX232 or equivalent somewhere anyway if RS232 is involved,
so the MAX3110 is not increasing component count, only board space.
Depending on what else the PIC is doing, you may even save PIC pins, as the
SPI-alike 3110 interface uses data in, data out, clock and chip select, so
the data and clock lines can be re-used (as in my design) - I was even able
to re-use code to an extent by setting up similar protocols to interface
with other units in the system.

Now for the PC end.  Dear old Terminal finally failed me, because the
transmit buffer just takes far too long to respond to hardware handshaking
(even with the 3110's receive buffer).  But HyperTerm is fine in that
respect, just go into Properties, then Configure (to bring up Port
Settings), then Advanced and pull the Transmit Buffer pointer to the left
hand end.

Having got all this sorted out, I was still having occasional problems, and
couldn't figure out what I was doing wrong (wierd things like intermittent
echoing of PC-transmitted characters, bytes with bit 8 set, that sort of
nonsense).  Finally tracked it down to the trusty breakout box!  Duly
overhauled and two of the DIP switches replaced!!  (But it is almost 20
years old.)

Hope this helps, even if it isn't "UARTless".

Tim Forcer, Department of Electronics & Computer Science
The University of Southampton, UK.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\06@105917 by Tim Forcer

flavicon
face
Sorry to come in late on this one, and for having got the protocol wrong
for replying to topics (shows how long since I contributed!).  Couple of
suggestions, following a recent project using an '84 talking to a PC (plus
doing other stuff).

I used the Maxim MAX3110 IC which provides in one 28-pin IC both a
SERIAL-access UART and a dual TTL/RS232 transceiver set (available in both
SM and through-hole versions).  Of the 28 pins you only need to get at 13,
the rest being connections to the charge pumps for linking the UART to the
transceivers, so the whole thing could have fitted in a 14 pin package.
None the less this is a VERY useful device.  With the '84 running a 4MHz
resonator, the UART handler code has no waits.  The UART doesn't have
auto-handling of CTS/RTS - they need to be read/set explicitly, but it DOES
have a 9-byte FIFO buffer on incoming.  It also has an interrupt output,
which I didn't use as it wasn't necessary or even appropriate for my
application.  Sending and collecting bytes by the PIC at maximum PIC speed
means that even at 19200 baud there's a fair bit of "spare" time to do
other things between reads/writes.

So much for the PIC end of things.  Yes, I know it's an extra IC, but most
of the time there's a MAX232 or equivalent somewhere anyway if RS232 is
involved, so the MAX3110 is not increasing component count, only board
space.  Depending on what else the PIC is doing, you may even save PIC
pins, as the SPI-alike 3110 interface uses data in, data out, clock and
chip select, so the data and clock lines can be re-used (as in my design) -
I was even able to re-use code to an extent by setting up similar protocols
to interface with other units in the system.

Now for the PC end (in my case, a Pentium Pro with pseudo 16550 embedded
somewhere on the motherboard).  Dear old Terminal finally failed me,
because the transmit buffer just takes far too long to respond to hardware
handshaking (even with the 3110's receive buffer).  But HyperTerm is fine
in that respect, just go into Properties, then Configure (to bring up Port
Settings), then Advanced and pull the Transmit Buffer pointer to the left
hand end.

Having got all the above sorted out, I was still having occasional
problems, and couldn't figure out what I was doing wrong (wierd things like
intermittent echoing of PC-transmitted characters, bytes with bit 8 set,
that sort of nonsense).  Finally tracked it down to the trusty breakout
box!  Duly overhauled and two of the DIP switches replaced!!  (But it is
almost 20 years old.)

Hope this helps, even if it isn't "UARTless", just artless.

Tim Forcer, Department of Electronics & Computer Science
The University of Southampton, UK.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2000\07\06@112200 by Tim Forcer

flavicon
face
Sorry to come in late on this one, and for having got the protocol wrong
TWICE for replying to topics (shows how long since I contributed!).

Couple of suggestions, following a recent project using an '84 talking to a
PC (plus doing other stuff).

I used Maxim's MAX3110 IC which provides in one 28-pin IC (available in
both SM and through-hole versions) both a SERIAL-access UART and a dual
TTL/RS232 transceiver set.  Of the 28 pins you only need to get at 13, the
rest being connections to the charge pumps for linking the UART to the
transceivers, so the whole thing could have fitted in a 14 pin package.
None the less this is a VERY useful device.  With the '84 running a 4MHz
resonator, the UART handler code has no waits.  The UART doesn't have
auto-handling of CTS/RTS - they need to be read/set explicitly, but it DOES
have a 9-byte FIFO buffer on incoming.  It also has an interrupt output,
which I didn't use as it wasn't necessary or even appropriate for my
application.  Sending and collecting bytes by the PIC at maximum PIC speed
means that even at 19200 baud there's a fair bit of "spare" time to do
other things between reads/writes.

So much for the PIC end of things.  Yes, I know it's an extra IC, but most
of the time in a PIC <-RS232-> PC system there's a MAX232 or equivalent
somewhere anyway, so the MAX3110 is not increasing component count, only
board space.  Depending on what else the PIC is doing, you may even save
PIC pins, as the SPI-alike 3110 interface uses data in, data out, clock and
chip select, so the data and clock lines can be re-used (as in my design) -
I was even able to re-use code to an extent by setting up similar protocols
to interface with other units in the system.

Now for the PC end (in my case, a Pentium Pro with pseudo 16550 embedded
somewhere on the motherboard).  Poor old Terminal finally failed me,
because the transmit buffer just takes far too long to respond to hardware
handshaking (even with the 3110's receive buffer).  But HyperTerm is fine
in that respect, just go into Properties, then Configure (to bring up Port
Settings), then Advanced and pull the Transmit Buffer pointer to the left
hand end.

Having got all the of those aspects sorted out, I was still having
occasional problems, and couldn't figure out what I was doing wrong (wierd
things like intermittent echoing of PC-transmitted characters, bytes with
bit 8 set, that sort of nonsense).  Finally tracked it down to the trusty
breakout box!  Duly overhauled and two of the DIP switches replaced!!  (But
it is almost 20 years old.)

Hope this helps, even if it isn't "UARTless", just artless.

Tim Forcer, Department of Electronics & Computer Science
The University of Southampton, UK.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

'[PICLIST] [PIC] F871 (et al) TMR0 overflow inerupt'
2000\07\07@094911 by Hardware Engineering

picon face
OK..embarking on my next project..redesign of a control that is years old and
still uses a C57, and bunches of other obsolete parts. Figure that if half the
parts are impossible to find, its time!

So..here goes the first question.  I had on my old design, a programmable
timer by Intersil, and the clock source was from another Intersil part that
used a xtal, and based on the divide ratio, you got out from the chip a one
second or one minute timebase.  This allowed the user to program the timers
for intervals of seconds.

Now, if I used a tuning fork xtal, feeding into the RA0 bit for TMR0, used a
prescaler of 256, that would give me 128 counts left. Now, TMR0 has an
overflow interupt flag bit.  I can see a few ways to get my final desired...1
second....interupt/signal to enable a counter.  First, I could build a
software loop count, that decrements everytime the overflow occurs. Second, is
there a way to feed this direct to TMR1 ? This way, it could be totally
transparent to the rest of the program.

I'm not sure if this made sense, but I hope it did.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\07@100046 by Andrew Kunz

flavicon
face
Timer1 can run off an external xtal.  That sounds even easier to me.

Andy








Hardware Engineering <TakeThisOuTpic-ineerTakeThisOuTspamRemoveMEUSA.NET> on 07/07/2000 09:48:44 AM

Please respond to pic microcontroller discussion list <spam_OUTPICLISTspamspam.....MITVMA.MIT.EDU>








To:      PICLIST.....spam@spam@MITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: [PIC] F871 (et al) TMR0 overflow inerupt








OK..embarking on my next project..redesign of a control that is years old and
still uses a C57, and bunches of other obsolete parts. Figure that if half the
parts are impossible to find, its time!

So..here goes the first question.  I had on my old design, a programmable
timer by Intersil, and the clock source was from another Intersil part that
used a xtal, and based on the divide ratio, you got out from the chip a one
second or one minute timebase.  This allowed the user to program the timers
for intervals of seconds.

Now, if I used a tuning fork xtal, feeding into the RA0 bit for TMR0, used a
prescaler of 256, that would give me 128 counts left. Now, TMR0 has an
overflow interupt flag bit.  I can see a few ways to get my final desired...1
second....interupt/signal to enable a counter.  First, I could build a
software loop count, that decrements everytime the overflow occurs. Second, is
there a way to feed this direct to TMR1 ? This way, it could be totally
transparent to the rest of the program.

I'm not sure if this made sense, but I hope it did.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

'[PICLIST] [Re: [PIC]: F871 (et al) TMR0 overflow i'
2000\07\07@100916 by Hardware Engineering

picon face
but...it would require a 256Hz xtal...ie...custom...but yes its a solution



Andrew Kunz <spamBeGoneakunzspamspam_OUTTDIPOWER.COM> wrote:
Timer1 can run off an external xtal.  That sounds even easier to me.

Andy








Hardware Engineering <EraseMEpic-ineer.....spamUSA.NET> on 07/07/2000 09:48:44 AM

Please respond to pic microcontroller discussion list
<spamPICLISTKILLspamspam@spam@MITVMA.MIT.EDU>








To:      PICLISTspamspamTakeThisOuTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: [PIC] F871 (et al) TMR0 overflow inerupt








OK..embarking on my next project..redesign of a control that is years old and
still uses a C57, and bunches of other obsolete parts. Figure that if half
the
parts are impossible to find, its time!

So..here goes the first question.  I had on my old design, a programmable
timer by Intersil, and the clock source was from another Intersil part that
used a xtal, and based on the divide ratio, you got out from the chip a one
second or one minute timebase.  This allowed the user to program the timers
for intervals of seconds.

Now, if I used a tuning fork xtal, feeding into the RA0 bit for TMR0, used a
prescaler of 256, that would give me 128 counts left. Now, TMR0 has an
overflow interupt flag bit.  I can see a few ways to get my final desired...1
second....interupt/signal to enable a counter.  First, I could build a
software loop count, that decrements everytime the overflow occurs. Second,
is
there a way to feed this direct to TMR1 ? This way, it could be totally
transparent to the rest of the program.

I'm not sure if this made sense, but I hope it did.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2000\07\07@102411 by Andrew Kunz

flavicon
face
No, a 32.768KHz one.   TMR1 is 16 bits, so when the sign changes on TMR1, that's
equivalent to 1 second.

Andy

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


'[PIC]: Timer overflow interrupt problem using PIC1'
2000\09\04@230836 by Thomas Robert de Massy
flavicon
face
Hi,
   I'm trying to program a PIC16C71 to generate a given frequency at the
output. I'm using the 71's timer overflow interrupt to generate the pulse.
I've been doing some tests using the C2C plus 4.004e compiler's wizard. But
everytime I put the PIC on I get a different frequency, about 1 time on 3 I
get the correct one, but most of the time the frequency is too high. The
4Mhz crystal of the put is constant so it does not cause the problem.

Here's how the PIC should work :
I'm using the internal clock of the PIC with a prescaler 2.
On timer overflow interrupt a function is called (tmrHandler) switch portB 1
to high or to low if it's already high.

I did some calculation and figured I should get a 976.56 Hertz signal at the
output :

(1/(1/(4 000 000 / 4) * prescaler * 256))/2
(256 is the overflow count)
(the result is divided by 2 because the output is toggled On and Off each
time
the function is called)
(1/(1/1000000 * 2 * 256))/2 = 976.56 Hertz
or
1000000/2/256/2 = 976.56 Hertz

When I turn the PIC on sometimes I get 978 Hertz but sometimes I get 7.5KHz,
4xx Hz, 8.xKHz etc...

I really do not understand why I get this result, I'm using a new 9volt
battery to drive the circuit (with a 78x05 regulator)
I tried to add an 1000uF capacitor at the regulator without any results.

Could my PIC be damaged ? Something is wrong with my code ?

Thanks in advance !


Here's the C2C testing code  :
----------------------------------------------------------------------------
----------------------------------------------------------------------------
-------
//This file was generated by the C2G Code Generator 1.1


//If necessary insert your global variables declaration here
char toggle = 1;



//TMR0 Overflow handler
void tmrHandler( void )
{
if (toggle)
 {
  output_low_port_b (1);
  toggle = 0;
 }
 else
 {
  output_high_port_b (1);
  toggle = 1;
 }
}


//This is the interrupt handler
void interrupt( void )
{
   //Insert your code which should run
   //before any interrupt processing here


   //Interrupt processing
   //TMR0 Overflow processing
   if( INTCON & 4 )
   {
       clear_bit( INTCON, 2 );
       tmrHandler();
   }
   //Insert your code which should run
   //after any interrupt processing here


}

//This is the main function which is called
//after processor power-up or reset
void main( void )
{
   //Hardware Initialization
   set_bit( STATUS, RP0 ); //Select the Register bank 1
   set_tris_a( 1 ); //Configure the Port A
   set_tris_b( 0 ); //Configure the Port B
   OPTION_REG = 128; //Configure the OPTION register
   clear_bit( STATUS, RP0 ); //Select the Register bank 0
   INTCON = 160; //Configure the INTCON register

   //Don't forget to insert your code here!!!
   //(As there is no "return" from the main code
   //an endless loop may be a good idea)


}
----------------------------------------------------------------------------
---------------------------------

Here's the compiled code :
----------------------------------------------------------------------------
---------------------------------
; This file was generated by C2C-plus compiler version 4.00.4e

   include "p16C71.inc"
   ;Variables *****************************************
__int_save_cont_W               equ 0x0c
__int_save_cont_STATUS          equ 0x0d
__int_save_cont_FSR             equ 0x0e
__int_save_cont_PCLATH          equ 0x0f
_toggle                         equ 0x10
   ORG 0
   goto start__code

   ORG 4
_interrupt
_interrupt__code
   movwf __int_save_cont_W
   swapf __int_save_cont_W, F
   swapf STATUS, W
   movwf __int_save_cont_STATUS
   swapf FSR, W
   movwf __int_save_cont_FSR
   swapf PCLATH, W
   movwf __int_save_cont_PCLATH
   btfss INTCON, 2
   goto label_0002
   bcf INTCON, D'2'
   call _tmrHandler
label_0002
   swapf __int_save_cont_PCLATH, W
   movwf PCLATH
   swapf __int_save_cont_FSR, W
   movwf FSR
   swapf __int_save_cont_STATUS, W
   movwf STATUS
   swapf __int_save_cont_W, W
   retfie
_interrupt__end

start__code
   movlw D'1'
   movwf _toggle
_main__code
   bsf STATUS, RP0
   movlw D'1'
   movwf TRISA
   movlw D'0'
   movwf TRISB
   movlw D'128'
   movwf OPTION_REG
   bcf STATUS, RP0
   movlw D'160'
   movwf INTCON
_main__end
_tmrHandler__code
_tmrHandler
   movf _toggle, W
   btfsc STATUS, Z
   goto label_0000
   bcf PORTB, 1
   clrf _toggle
   goto label_0001
label_0000
   bsf PORTB, 1
   movlw D'1'
   movwf _toggle
label_0001
   return
_tmrHandler__end
   END
----------------------------------------------------------------------------
---------------------------------

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\04@233208 by Tony Nixon

flavicon
picon face
Thomas Robert de Massy wrote:

> //This is the main function which is called
> //after processor power-up or reset
> void main( void )
> {
>     //Hardware Initialization
>     set_bit( STATUS, RP0 ); //Select the Register bank 1
>     set_tris_a( 1 ); //Configure the Port A
>     set_tris_b( 0 ); //Configure the Port B
>     OPTION_REG = 128; //Configure the OPTION register
>     clear_bit( STATUS, RP0 ); //Select the Register bank 0
>     INTCON = 160; //Configure the INTCON register
>
>     //Don't forget to insert your code here!!!
>     //(As there is no "return" from the main code
>     //an endless loop may be a good idea)

Ahhh!!! you did forget ;-)

{Quote hidden}

See :-)

Put an endless loop in your code that causes it to appear here.

Otherwise the tmrHandler code will execute and the "return" will get a
false value from the stack and who knows what happens after that.

Iforgot  goto Iforgot

{Quote hidden}

--
Best regards

Tony

ICmicro's
http://www.picnpoke.com
RemoveMEsalesRemoveMEspampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

2000\09\05@001733 by Thomas Robert de Massy

flavicon
face
I feel so stupid ! :-) all my other testing were done with the endless loop,
and I forgot it for my actual frequency measuring test. Forget my question
:-) Thanks you saved me a lot of time figuring it out, because I thought it
was still there.

{Original Message removed}


'[PICLIST] Checking for stack overflow with an ICD?'
2000\10\24@062736 by ranma
flavicon
face
Hi guys,

Does any one know a way of checking for a stack overflow using just an ICD?.
I want to be absolutely sure that my program is not overflowing the stack. I
have checked all the code and mapped out what I think are the worst-case
scenarios (nested calls) and included the extra one level required by the
ICD itself.

It would also be nice if I could view the stack contents to see where the
code has been when something goes wrong...

Has someone already been down this road?

Thanks,

David

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\10\24@064233 by ranma

flavicon
face
Oops, forgot the [PIC]: on the subject last time :-o...

Hi guys,

Does any one know a way of checking for a stack overflow using just an ICD?.
I want to be absolutely sure that my program is not overflowing the stack. I
have checked all the code and mapped out what I think are the worst-case
scenarios (nested calls) and included the extra one level required by the
ICD itself.

It would also be nice if I could view the stack contents to see where the
code has been when something goes wrong...

Has someone already been down this road?

Thanks,

David

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads





'[OT]: Flowcharting software'
2000\11\14@082747 by Michael Rigby-Jones
flavicon
face
Does anyone have a recomendation for the above?  I've been using Visio,
which isn't a bad package, but IMHO it's "jack of all trades, master of
none" and I find it quite fiddly to use.

Regards

Mike

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\14@085152 by Pfaff, John

flavicon
face
There is a package called ABC Flowcharter.  It's made by Micrografx
(http://www.micrografx.com).  I've never used it, but it came with my
Micrografx Picture Publisher.

{Original Message removed}

2000\11\14@090312 by Simon Nield

flavicon
face
I think this was discussed on the list a month or so back. try checking the archives for "viso" as I
am sure that's what started it all then too.

Regards,
Simon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\14@092925 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Simon Nield [SMTP:TakeThisOuTsimon.nield@spam@spam@spam@QUANTEL.COM]
> Sent: Tuesday, November 14, 2000 2:01 PM
> To:   TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU
> Subject:      Re: [OT]: Flowcharting software
>
> I think this was discussed on the list a month or so back. try checking
> the archives for "viso" as I
> am sure that's what started it all then too.
>
> Regards,
> Simon
>
It was discussed...sortof.  The OP wanted a tool to help with producing PDL
(program description language) but flowcharting programs became involved.
Visio was mentioned but, although it can produce nice looking charts, I find
it has several little quirks such as lines sometimes not snapping to grids
properly, especially after resizing which makes the final result look less
than satisfactory.  ABC Flowcharter sounds like it may be worth looking at
though.  I'm surprised there aren't more packages dedicated to this kind of
thing.

Cheers

Mike

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\14@105218 by John Walshe

flavicon
face
I have a copy of the ABC flowcharter and it seemed ok for the little use I
gave it (it came as part of a bundle I got some years ago).
If you don't mind my expanding this topic a little - does anyone know of a
program which can develop a flowchart from an assembly listing ie it can
reconcile all the branches etc.
I came across one for the 68HC11 a long time ago and can't find it now.
Obviously I would prefer one for the PIC if I could get it.
John
***************************************************************
KILLspamJohn.WalsheKILLspamspamspamBeGoneinpactmicro.com

INPACT MICROELECTRONICS (Irl) Ltd
21A Pouladuff Road,
Cork,
Ireland,

Tel: +353 21 4318296
Fax: +353 21 4318980

WWW.INPACTMICRO.COM
***************************************************************

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\11\14@114728 by Douglas Wood

flavicon
face
I use a product called "All Clear" that produces flow charts from a textual
description similar to psuedo code.

Douglas Wood
Software Engineer

{Original Message removed}

2000\11\14@123419 by Don Hyde

flavicon
face
As a crusty OOOld programmer (grey hair to prove it), I often flowchart
stuff, especially when I know I'm going to have to grub around with assembly
to code it.

I've been using ABC Flowcharter for years, and while younger programmers
tend to make gurgling noises when they see 'em (I'm not entirely sure they
can read them), they sure help me a lot a few months later when I can no
longer figure out what the code was trying to accomplish.  You know, find
the forest in that thicket of opcodes...

I've been keeping an eye out for a long time, and haven't seen anything that
comes close to ABC Flowcharter.  If you can find a 5-year-old copy, buy it,
because they'v added a lot of dubious features and raised the price a lot,
but it basically hasn't gotten any better since about the third release or
so.

As for automatic flowcharting, that's been like artificial intelligence.
Real soon now for most of the last 25 years, with nothing visible but an
occasionally howler.  But autorouters for PC layout were like that, too, and
people find them useful now, so if I see it, I'll believe it.

> {Original Message removed}

2000\11\15@050011 by Peter Tiang

flavicon
face
Hi,

   I suggest SmartDraw, http://www.smartdraw.com

   It's not overly complicated like Visio,
   and very intuitive to use.

   Besides flow charting, it's a big help when
   doing most day-to-day business presentation.

   Disclaimer: I'm in no way related to
   SmartDraw, just a satisfied user.

Regards,
Peter Tiang

----- Original Message -----
From: "Michael Rigby-Jones" <spamBeGonemrjonesKILLspamspamNORTELNETWORKS.COM>
Sent: Tuesday, November 14, 2000 10:16 PM
Subject: Re: [OT]: Flowcharting software


> > {Original Message removed}

2000\11\15@061227 by Bill Kaufman

flavicon
face
From:  Bill Kaufman@MITEL on 11/15/2000 06:12 AM
I use Visio 5 Technical with the Professional Add-on. Someone
mentioned the problems of rerouting connectors when you move
objects but this was resolved in the 5C service release. The
Professional Add-on comes with a stencil set that includes all the
standard flow chart symbols.

Bill

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\11\15@062520 by Michael Rigby-Jones

flavicon
face
I have just found out that Visio 2000 Pro is the corporately approved
package for flowcharting, so I'm going to have a hard job convincing the
boss to get anything else.  I'll give it a go though, if the annoying bits
have been fixed it shouldn't be too bad.  I'll let you know what I think.

Cheers

Mike

> {Original Message removed}


'[EE]: Buffer flow control, was Re: [PIC]:16F873 pr'
2000\12\18@110820 by Alan B. Pearce
face picon face
>Software flow control (xon/xoff) isn't the best solution if you have to
>stop a serial stream unless your host program disables or defines the size
>of the fifo.  You simply can't count on just a 16 byte buffer anymore
>(well, you can probably count on about 80-90% of the systems having just a
>16 byte, and chances are system builders will skip the faster uarts and go
>straight to USB, so it may never really be a problem for more than 20% of
>your customers...).  Either define the largest packet your controller can
>receive before the host system has to wait for a response, use hardware
>flow control (which stops the flow after the fifo), or accept and process
>data at the speed of the input stream...

Ahh roll on ETX/ACK flow control - best software flow control that existed....

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\18@201717 by Bob Ammerman

picon face
----- Original Message -----
From: Alan B. Pearce <A.B.Pearce@spam@spamKILLspamRL.AC.UK>
To: <EraseMEPICLISTRemoveMEspam@spam@MITVMA.MIT.EDU>
Sent: Monday, December 18, 2000 11:08 AM
Subject: [EE]: Buffer flow control, was Re: [PIC]:16F873 programming


> >Software flow control (xon/xoff) isn't the best solution if you have to
> >stop a serial stream unless your host program disables or defines the
size
> >of the fifo.  You simply can't count on just a 16 byte buffer anymore
> >(well, you can probably count on about 80-90% of the systems having just
a
> >16 byte, and chances are system builders will skip the faster uarts and
go
> >straight to USB, so it may never really be a problem for more than 20% of
> >your customers...).  Either define the largest packet your controller can
> >receive before the host system has to wait for a response, use hardware
> >flow control (which stops the flow after the fifo), or accept and process
> >data at the speed of the input stream...
>
> Ahh roll on ETX/ACK flow control - best software flow control that
existed....

Certainly ETX/ACK is an excellent idea, but it is far from the most
efficient way to handle a link.

To get maximum throughput on a PC->PIC link you'd have to use some sort off
windowing protocol:

The PC is allowed to send 'N' unacknowledged bytes/packets/buffers.

The PIC has room to store the N bytes/packets/buffers, probably in interrupt
level buffers.

The PIC acknowledges each buffer as it is processed.

This will allow the PC to keep blasting data out as long as the PIC is
keeping up.



Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2000\12\18@210147 by Bill Westfield

face picon face
   > Ahh roll on ETX/ACK flow control - best software flow control that
   existed....

   Certainly ETX/ACK is an excellent idea, but it is far from the most
   efficient way to handle a link.

   To get maximum throughput on a PC->PIC link you'd have to use some sort off
   windowing protocol...

Like TCP.  Run IP/TCP/PPP on the computers, and you're all set!

Oops.  People are doing that.

Oops - it doesn't solve the problem.  Both ETX/ACK flow control and a window
based scheme assume that the bottlenecks are at the endpoints, and aren't
much good if there are intermediate devices (modems, MUXes, networks, etc)
that might also have flowcontrol requirements...  XON/XOFF is about the only
thing that came close to allowing any device in the path to control data
flow (and it does a pretty poor job of it, unfortuately.)

The current trend in big-FIFO uarts is ... amusing.  FIFOs address a
latency issue, but they don't really improve overall throughput much
(beyond a certain point, anyway.)  So I think the big FIFOs are
pretty... intimate... with wintel PC's poor interrupt/driver latency.

Using a DMA based controller for typical Async traffic presents it's own
set of challenges having to do with preserving that 'asynchronous' nature
of the communications.  In a lot of ways, PPP/IP/TCP with HW flow control
on the individual hops IS the best solution...

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


'[PIC]: Hardware Flow Control (was 16F873 programmi'
2000\12\19@093026 by Bob Ammerman

picon face
> I have a feeling that early Intel 8251 USART chips (the non-A version) had
a
> problem like this, or maybe it was the National 8250 chip. I definitely
remember
> that there was a UART chip in common circulation that had a problem like
this.

It would not have been the 8250. The 8250 was the ancestor of our PC UARTS
of today, and it didn't have any hardware support for flow control.

I know the ZILOG SCC chips _do_ have hardware flow control support,  but I'm
pretty sure it has always worked correctly (ie: output stops immediately
after the current character is sent).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


'[OT]: Hardware Flow Control (was 16F873 programmin'
2000\12\19@101245 by David Kott

flavicon
face
> > I have a feeling that early Intel 8251 USART chips (the non-A version)
had
> a
> > problem like this, or maybe it was the National 8250 chip. I definitely
> remember
> > that there was a UART chip in common circulation that had a problem like
> this.
>
> It would not have been the 8250. The 8250 was the ancestor of our PC UARTS
> of today, and it didn't have any hardware support for flow control.
>
> I know the ZILOG SCC chips _do_ have hardware flow control support,  but
I'm
> pretty sure it has always worked correctly (ie: output stops immediately
> after the current character is sent).
>

The Philips SC26C9X series (often seen in Digi products) *do* have hardware
flow control support, however they *don't* stop transmitting until all of
their output buffer has been exhausted.  So, you could have up to eight
characters emitted, worse case, after deasserting CTS.
I don't know anything about the SCC chips, but this SC26C92's documentation
says that it "Powers up to emulate SCC2692".
This was... problematic.  Ultimately, I changed the code to feed only one
character at a time, essentially bypassing the transmitter FIFO.  The device
we were talking to, an 'HC711K4 IIRC, was programmatically generating their
CTS signal with general I/O when the device absolutely *could not* buffer
anymore characters.  As you might imagine, the two devices didn't get along
all that well.

-d

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\12\19@180712 by Bill Westfield

face picon face
   The Philips SC26C9X series (often seen in Digi products) *do* have hardware
   flow control support, however they *don't* stop transmitting until all of
   their output buffer has been exhausted.  So, you could have up to eight
   characters emitted, worse case, after deasserting CTS.

Ouch.  I suppose it depends on exactly where in the transmission path you
check for HW flow control.  The Cirrus/Basis/Intel cd24xx uarts we use are
interesting - they have a FIFO that is separate from the transmitter holding
register (I thought most uarts replaced the THR with the FIFO), and they
check CTS before moving characters from FIFO to THR, so they'll transmit up
to 2 bytes before stopping...

:-)
BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics



'[PIC]: Stack Overflows'
2001\01\25@130710 by Andy N1YEW
picon face
Is there a problem if my code overflows the stack?
like if in the delay i poll some lines and call a function if the lines are in a certain state.
The delay wont matter.  it is trivial.
but if the stack overflows (ie the delay poll call a function which does the same delay routine and call another, and on till the stack overflows.) what happens?
does it reset the stack? (empty it like)
would it matter?
Thanks,
Andy N1YEW
btw this is using an f84 for a PL board controller....

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@140450 by Olin Lathrop

face picon face
> Is there a problem if my code overflows the stack?

No, a stack is just one of those silly frills Microchip puts in there to
justify a higer price.  Sorta like that ALU whatsit thingy.  Go ahead ignore
all this stuff and go merrily on your way.  Just stay away from pacemakers
and nuclear power plant control systems.  (By the way, does Mommy know
you're playing with the 'puter again?)

> like if in the delay i poll some lines and call a function if the
> lines are in a certain state.
>
> The delay wont matter.  it is trivial.
>
> but if the stack overflows (ie the delay poll call a function which
> does the same delay routine and call another, and on till the stack
> overflows.) what happens?

It starts forgetting how to return from the outer subroutines.

> does it reset the stack? (empty it like)

No, it starts loosing things off the end, like.

> would it matter?

Does it matter if your subroutines return from where they were called, or is
it OK if they return to after a more recent call?



*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, STOPspamolin.....spamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservRemoveMEspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@142320 by David VanHorn

flavicon
face
>
> > would it matter?
>
>Does it matter if your subroutines return from where they were called, or is
>it OK if they return to after a more recent call?

It's a feature :)
--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@142535 by M. Adam Davis

flavicon
face
Andy N1YEW wrote:
> Is there a problem if my code overflows the stack?

It won't hurt the chip, but your program will essentially forget where to
go back to.  The stack is an area that hold information about jumps and
function calls.

Let's say you have a 2 level stack, which is empty now:

Call funcA     ; goto funcA, and come back here when it's done
Call funcB     ; goto funcB, return when done
Call funcC     ; goto funcC, return when done
...

funcA           ; At this point, the stack stores where it's supposed to return to
return         ; the stack 'pops' the value off, and the program continues
running right after
               ; the call func A instruction.  The stack only had to store one of these
values

funcB           ; Again the stack stores the location of the call funcB instruction
Call funcA     ; Now it's going to call A, and store this location
return         ; While A is running, the stack (2 level) is completely full.

funcC           ; Again, the stack stores the location of the Call funcC
instruction
Call funcB     ; Now it calls B, which stores another location
return         ; But B calls A!  This is called a stack overflow, the first
location that
               ; was stored (the original Call funcC) is now lost.  When it hits
               ; the return in funcC, it won't go where we thought it would,
               ; in fact, we have no idea wher it might go next, it could go to the
               ; end of our program, it could go back to the beginning, it could end up
               ; anywhere in between.

This is what is called a stack overflow.  You have too many calls with too
few returns, and the processor cannot keep track of where you meant to go
back to.

> like if in the delay i poll some lines and call a function if the lines are in a certain state.
> The delay wont matter.  it is trivial.
> but if the stack overflows (ie the delay poll call a function which does the same delay routine and call another, and on till the stack overflows.) what happens?

If you call the delay, the delay calls another function, then your stack
is full.  If that function now calls the delay (or any other function) you
will push the first value off the stack (overflow it) and your program
will not go back to the original call to delay.

> does it reset the stack? (empty it like)

The value of the stack if you use return more than twice without any calls
is undefined.  It may be clear (empty), or it may be random garbage.

> would it matter?

It only matters if you want to use calls and returns, or interrupts.  If
you never use call or return, and never use interrupts you'll never have
to worry about the stack.  But it makes things so much easier, so I would
use it when you can.

-Adam

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@152311 by Bob Ammerman

picon face
How the stack behaves on underflow/overflow depends on the particular flavor
of PIC.

See your datasheet.

Here are a couple examples:

for the 16F87x (which has an 8 slot stack) the datasheet says:

"The stack operates as a circular buffer. This means that
after the stack has been PUSHed eight times, the ninth
push overwrites the value that was stored from the first
push. The tenth push overwrites the second push (and
so on)."

On these chips a CALL or INTERRUPT will always push an address on the stack,
a RETURN/RETLW/RETFIE will always pop an address off the stack. In reality
no data moves on the stack, instead an invisible (to your program)  3-bit
pointer is incremented/decremented to point to a different stack slot.

for the 18Cxxx (which has a 31 slot stack) things are a little fancier. The
datasheet tells us:

The action that takes place when the stack becomes
full depends on the state of the STVREN (stack over-flow
reset enable) configuration bit. Refer to Section 18
for a description of the device configuration bits. If
STVREN is set (default) the 31st push will push the (PC
+ 2) value onto the stack, set the STKFUL bit, and reset
the device. The STKFUL bit will remain set and the
stack pointer will be set to 0.
If STVREN is cleared, the STKFUL bit will be set on the
31st push and the stack pointer will increment to 31.
The 32nd push will overwrite the 31st push (and so on),
while STKPTR remains at 31.
When the stack has been popped enough times to
unload the stack, the next pop will return a value of zero
to the PC and sets the STKUNF bit, while the stack
pointer remains at 0. The STKUNF bit will remain set
until cleared in software or a POR occurs.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamlistservspamspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@155827 by Andy N1YEW

picon face
Ok Thanks guys!

Exactly what I wanted to hear :)

Andy

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservKILLspamspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@160511 by Drew Vassallo

picon face
> > Is there a problem if my code overflows the stack?
>
>No, a stack is just one of those silly frills Microchip puts in there to
>justify a higer price.  Sorta like that ALU whatsit thingy.  Go ahead
>ignore
>all this stuff and go merrily on your way.  Just stay away from pacemakers
>and nuclear power plant control systems.  (By the way, does Mommy know
>you're playing with the 'puter again?)
.
.
.
> > would it matter?
>
>Does it matter if your subroutines return from where they were called, or
>is
>it OK if they return to after a more recent call?

Ouch.  Olin, I sense that you may be hinting at sarcasm here.  You having a
bad day?  Take it easy, there are lots of beginners out there... you were
one once, weren't you? :)

To answer the original question briefly:  the F84 has an 8-level hardware
stack which holds the program counters during program branching.  Once you
jump to a subroutine, or an interrupt, the current program counter (where
you are in the program before the jump) gets pushed onto the stack.  It
pushes all the other values down also.  If you jump to more than 8
consecutive locations, the stack will overflow and you will lose your first
location value.  Then, when you try to RETURN to that particular calling
location, it will return to the wrong place because the stack now contains
an incorrect program location.

There are no flag bits to tell you when you've overflowed the stack.  So
just don't.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\26@051243 by Vasile Surducan

flavicon
face
Olin
 He, he, is this an american joking style or just you've weak up
again with your left face on the pillow ?
Vasile


On Thu, 25 Jan 2001, Olin Lathrop wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu


2001\01\26@063248 by Roman Black

flavicon
face
Bob Ammerman wrote:
>
> How the stack behaves on underflow/overflow depends on the particular flavor
> of PIC.
>
> See your datasheet.
>
> Here are a couple examples:
>
> for the 16F87x (which has an 8 slot stack) the datasheet says:
>
> "The stack operates as a circular buffer. This means that
> after the stack has been PUSHed eight times, the ninth
> push overwrites the value that was stored from the first
> push. The tenth push overwrites the second push (and
> so on)."


Yep, I knew it was a circular stack, but when I read
your post a funny thought occured to me. Since the stack
is circular, you could call a function ANY amount of times,
and return the same amount of times, provided:
* It was originally called from the top level
* no ints or other functions were called.

This would give an option to do a recursive activity
a very large number of times??

Any opinions?? :o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
spampiclist-unsubscribe-requestspammitvma.mit.edu


2001\01\26@090625 by Olin Lathrop

face picon face
> Since the stack
> is circular, you could call a function ANY amount of times,
> and return the same amount of times, provided:
> * It was originally called from the top level
> * no ints or other functions were called.
>
> This would give an option to do a recursive activity
> a very large number of times??

An infinite number of times, actually.  That is because the recursive
routine would only be able to return to itself and no longer be able to
return to the original caller.

If you think about it hard enough, you can probably contrive a case where
you can use the limited stack as a "feature", but I personally don't want to
go there.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinKILLspamspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamBeGonespamspammitvma.mit.edu


2001\01\26@092042 by Bob Ammerman

picon face
> Yep, I knew it was a circular stack, but when I read
> your post a funny thought occured to me. Since the stack
> is circular, you could call a function ANY amount of times,
> and return the same amount of times, provided:
> * It was originally called from the top level
> * no ints or other functions were called.
>
> This would give an option to do a recursive activity
> a very large number of times??
>
> Any opinions?? :o)
> -Roman
>

Sorry Roman, this won't work.

Remember the stack stores return addresses, not function addresses.

Given:

main:
   call     func
point_a:
   ...


func:
   ...
   call       func
point_b:
   ...
   return

After 8 calls every "return" will go back to "point_b", and we'll never get
back to "point_a".

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspammitvma.mit.edu


2001\01\26@093158 by Bob Ammerman

picon face
> Yep, I knew it was a circular stack, but when I read
> your post a funny thought occured to me. Since the stack
> is circular, you could call a function ANY amount of times,
> and return the same amount of times, provided:
> * It was originally called from the top level
> * no ints or other functions were called.
>
> This would give an option to do a recursive activity
> a very large number of times??
>
> Any opinions?? :o)
> -Roman

Sorry, Roman. Remember the stack stores _return_ addresses, not the address
of the called function.

So: given:

main:
   call    func
pointa:
   ...

func:
   ...
   call    func
pointb:
   ...
   return

After we recursively called func more than 8 times every subsequent 'return'
would return to 'pointb', not to 'pointa'.

i

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspamspammitvma.mit.edu


2001\01\26@095224 by Roman Black

flavicon
face
Olin Lathrop wrote:
>
> > Since the stack
> > is circular, you could call a function ANY amount of times,
> > and return the same amount of times, provided:
> > * It was originally called from the top level
> > * no ints or other functions were called.
> >
> > This would give an option to do a recursive activity
> > a very large number of times??
>
> An infinite number of times, actually.  That is because the recursive
> routine would only be able to return to itself and no longer be able to
> return to the original caller.

Ha ha! Of course! After 8 calls the original address
will be rubbed... Whooops! I'll work on my projects HARDWARE
today I think. It's a good day for hardware! ;o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam@spam@mitvma.mit.edu


2001\01\26@095643 by Lawrence Lile

flavicon
face
Bob,

I just read about a RAM company in IL who developed some small parts choking
models for the CDC, some CAD software models as well as a physical model of
a child complete with  breathing functions and a scale model throat.  It's
more useful than the abbreviated plastic tube used in the industry today.
They also developed a cruncher with the same forces as a baby's teeth (to
see if a toy would fly abart when bitten) and a pull tester with the same
grip force and strength as a small child to see if a toy would pull apart
under forces a child could generate.  That wasn't you, was it?

-- Lawrence Lile

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request.....spammitvma.mit.edu


2001\01\26@104334 by Drew Vassallo

picon face
>main:
>     call    func
>pointa:
>     ...
>
>func:
>     ...
>     call    func
>pointb:
>     ...
>     return

Wouldn't this just keep cycling between "func:" and "call func", never
getting to the "return" instruction?
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spammitvma.mit.edu


2001\01\26@115958 by Dan Michaels

flavicon
face
Roman wrote:
........
>
>Yep, I knew it was a circular stack, but when I read
>your post a funny thought occured to me. Since the stack
>is circular, you could call a function ANY amount of times,
>and return the same amount of times, provided:
>* It was originally called from the top level
>* no ints or other functions were called.
>
>This would give an option to do a recursive activity
>a very large number of times??
>
>Any opinions?? :o)


Forget it. Recursive routines generally use the stack
to store "local" variables, and if too many levels are in
use, you can easily overflow it with your data, besides
return addresses -[on older 80x86, at least]. And If you
only use global variables, then you would be continually
overwriting them - also called non-re-enterable routines,
the bane of M$-DOS and other non-multitasking OSes.

Existence of the circular stack on some PICs, however
means you can use a s.w. bailout to go to the beginning of
your program from "anywhere" in your code - no matter what
is already on the stack. I use this method to bailout of
some routines that are so tightly coded that there isn't
space to add a < btfs_ + goto >. [this is probably the
place Olin just said he didn't want to go to].

- danM

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspammitvma.mit.edu


2001\01\26@120823 by jamesnewton

face picon face
The problem would be stopping when you make it back to the top.

---
James Newton (PICList Admin #3)
jamesnewtonRemoveMEspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\01\26@174554 by Bob Ammerman

picon face
> >main:
> >     call    func
> >pointa:
> >     ...
> >
> >func:
> >     ...
> >     call    func
> >pointb:
> >     ...
> >     return
>
> Wouldn't this just keep cycling between "func:" and "call func", never
> getting to the "return" instruction?

Yes, except that the "..."s represent additional code that would determine
when to exit the recursion.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
spampiclist-unsubscribe-requestspammitvma.mit.edu



'[EE]: 0-5V Air Flow Sensor'
2001\04\04@102401 by Montaigne, Mike - NRC
flavicon
face
       Hi:

       I am using a PIC for a simple gas flow check on an air sampler.  My
crude first run at this was to use a Radio Shack 271-110A 10K@25 degrees C
Thermistor, 5 min epoxied to a 82 ohm resistor which was connected to 5
volts.  The thermistor was connected in series with a 5K resistor to 5V and
the middle junction point connected to a meter (eventually a a/d ip on a
PIC).  I got 1.72V (a/d 88) at 25C room temp, 3.28V (a/d 168) with no
airflow (63C), and 2.78V (a/d 142) with some airflow (50C).  The a/d numbers
are what I figure I'll get in my PIC with 256 bit resolution.

       So my questions............

       I can't find a cheap airflow sensor.  A pressure switch won't work
as it could still read OK if there was a blockage.  This sensor would cost
me about $3. and I need 20 or so.

       My airflow is 20L/min and I have not tested at that exact airflow
yet.  I'm hoping there will be enough cooling to give me a significant
change in my a/d reading.  How many counts change between no airflow and
20l/min should I attempt to design for to give me reliable operation.  Is
there another approach I should be looking at?

       I know there are lots of gurus out there who are a lot smarter at
this than I am.  I'm just trying a seat of the pants approach and this is
where I am at, after my first run at this.

       tks

       Mike Montaigne
       Montaigne Audio
       Pembroke Ontario
       montaigmspam_OUTspamTakeThisOuTnrtco.net

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\04@104043 by Spehro Pefhany

picon face
At 10:11 AM 4/4/01 -0400, you wrote:

>
>        My airflow is 20L/min and I have not tested at that exact airflow
>yet.  I'm hoping there will be enough cooling to give me a significant
>change in my a/d reading.  How many counts change between no airflow and
>20l/min should I attempt to design for to give me reliable operation.  Is
>there another approach I should be looking at?

Yes, you should try to temperature compensate it. Try making a bridge
with two thermistors and heaters but with one shielded from the air flow.

You'll then get a differential reading that is independent of ambient
temperature. You may be able to do this without additional parts, just
going directly into the PIC A/D input.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeff@spam@spamRemoveMEinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\04@113239 by James Paul

flavicon
face
What about a Mass Air Flow Sensor for a car?  I'm not sure of the
cost, but that may be the killer.  Anyway, just a thought.

                                           Regards,

                                             Jim


On Wed, 04 April 2001, "Montaigne, Mike - NRC" wrote:

{Quote hidden}

@spam@jimspam_OUTspamjpes.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\04@135423 by Lawrence Lile

flavicon
face
A real standard airflow sensor is a hot wire anemometer.  Omega will have
them, of course, for two price+ACQ-. http://www.omega.com

I think they work thusly:  A small strip of nichrome wire is exposed to the
airflow, and heated red hot.  It's about  3/8+ACI- or 1/2+ACI- long, so it's
hopefully not enough heat to affect the temperature of the airflow much.
The hot wire will be hottest in still air, and progressively cool as airflow
increases.

The voltage across the nichrome wire will change in proportion to it's
temperature.  Placing this in a bridge arrangement would give you an easy
way to measure this .

There's an exceedingly complex formula describing the relationship between
the airflow and the voltage output, which we won't delve into here.  In PIC
land, this means we need a lookup table.  Get a real airflow meter for
calibration, stick your shop-made sensor in the airflow and generate a table
yourself.


{Original Message removed}

2001\04\04@173013 by goflo

flavicon
face
Oops. Sorry, Lawrence - Meant to send it to the list.

                 ***********

Hot-wire is a good way to go - Using a constant-current
source the voltage across the wire will vary with temp.

A thermistor scheme:
If you can afford two pins - Use the thermistor in series
with a capacitor - Drive the thermistor pin low & the cap
pin high for 5 TC, switch the cap pin to input, increment
a counter till the cap pin goes low. The count will vary
with temperature. You can do it with just one pin, with a
bit more footwork...

A pressure approach - Instead of absolute pressure, pass
the airflow thru a venturi and read differential pressure
across it. Within limits there is a relatively straight-
forward relationship between delta-P and airflow.

regards, Jack

Lawrence Lile wrote:
{Quote hidden}

> {Original Message removed}

2001\04\04@182252 by Spehro Pefhany

picon face
At 12:52 PM 4/4/01 -0500, you wrote:

>
>There's an exceedingly complex formula describing the relationship between
>the airflow and the voltage output, which we won't delve into here.

A very good approximation can be made by King's law.

It's like one line of C.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\05@092908 by Lawrence Lile

flavicon
face
<Drum roll = on....>   And the one line of C code is.....????  </DrumRoll>

<Grin = Big> Lawrence Lile </Grin>



{Original Message removed}

2001\04\06@080113 by Peter L. Peres

picon face
> <Drum roll = on....> And the one line of C code is.....???? </DrumRoll>
>
> <Grin = Big> Lawrence Lile </Grin>

(taken from:)
From: "Mark Folsom" <spamfolsommanKILLspamspamredshift.com>
Newsgroups: alt.sci.physics,sci.physics
Subject: Re: Question about Specific heat and conductivity experiment.
Date: Tue, 20 Mar 2001 16:51:38 -0800

Here's what I posted before on the topic:

"In the range of Reynolds numbers from 3 to 100, the empirical correlation
between the Nusselt modulus and the Reynolds and Prandtl numbers for cross
flow over a tube is (Principles of Heat Transfer 3rd ed., Frank Kreith)

Nu = 0.82*Pr^.3*Re^.4

where

Nu = hc*D/k, k is thermal conductivity, hc is the film heat transfer
coefficient, D is the diameter of the tube,

Pr = Cp*mu/k, Cp is specific heat, mu is kinematic viscosity,

Re = V*D*rho/mu, V is fluid velocity, rho is fluid density.

This can be reorganized to give you the film heat transfer coefficient in
terms of properties we are familiar with:

hc = 0.82 * Cp^.3 * k^.7 * rho^.4 * V^.4/(D^.6 * mu^.1).

The properties of the oil are Cp, k, rho and mu.  Heat capacity per unit
volume doesn't vary much unless there are phase changes or reactions
involved.  Reduced viscosity could help a little."

The above indicates that thermal conductivity is more important than heat
capacity, but that could change at higher flow rates.

Mark Folsom

--end of quote--

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestRemoveMEspammitvma.mit.edu


'[PICLIST] [PIC] Flow measurement: Was: [PIC]: Indu'
2001\04\08@040120 by spam

flavicon
face
Hi,

The best way to use a thermistor to measure flow is to keep it at a
constant temperature = constant resistance.
You can do this with a simple opamp.

After that, it is pretty linear within Re=100-10000

Siemens had som very small PTC's (0.2 mm) once.

Kent


On 6 Apr 2001, at 21:50, John wrote:

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


'[PIC]: reset problem (stack underflow)'
2001\04\24@112344 by shif

flavicon
face
I'm forwarding this to the list for Kashif and I will direct him to
http://www.piclist.com for instructions on joining the list but you may want
to reply to him directly.

---
James Newton (PICList Admin #3)
KILLspamjamesnewtonspam@spam@piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\04\24@144636 by Graham Harrison

flavicon
picon face
> Dear Mr. Jamesnewton,
>
> I'm working first time on pic microcontroller (pic16f84) and facing a
> problem of "reset" after two second of execution.
> (Note: I am not using wdt)
>
> Is it "Program Memory Paging" problem ?
>
> If it is Please let me know how can I solve my problem.
>
> In past I have an experience of 8051 Microcontroller and there was no
> problem of paging or reset. Is it possible I can use pic_microcontrollers
> like 8051 microcontroller. If there is any way please tell me
>
> I am including my source code with this email and tell me how can I send
my
> mail to all piclist members please give me the address where I can send
the
> message.
>
>
> Kashif ali
> (my member ID is : kpp-MTL-AC9a)

When Kashif says he is not using the watchdog timer, does he mean he is not
restarting the watchdog timer or not setting the config bit with a _config
statement or during programming (default is ON). If it is the former but not
the latter, it will explain why it resets in approx 2 seconds.

Graham

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.



'[EE]: detect waterflow'
2001\05\08@123143 by Patrik Husfloen
picon face
Are there any clever ways to detect waterflow in a hose/tube?


/Patrik

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@124417 by Mark Newland

flavicon
face
Microphone

Patrik Husfloen wrote:

> Are there any clever ways to detect waterflow in a hose/tube?
>
> /Patrik
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@125457 by Patrik Husfloen

picon face
Didn't think of that, what kinf of a microphone goes well with water?

/patrik


----- Original Message ----- From: "Mark Newland" <@spam@apeRemoveMEspamESKIMO.COM>
To: <PICLIST@spam@spamEraseMEMITVMA.MIT.EDU>
Sent: Tuesday, May 08, 2001 6:42 PM
Subject: Re: [EE]: detect waterflow


{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\05\08@125649 by Shawn Yates

flavicon
face
Fire alarm compananies detect when water flows through the sprinkler system
and set off an alarm.

If the tube starts empty, just an air gap switch that will be shorted when
covered with water would work, unless you are trying to detect FLOW not just
the presence of water.

How about a small impeller and and monitor the shaft for rotation.  Then you
could get realy fancy and measure the speed of the flow.



Just some thoughts.

Shawn

{Original Message removed}

2001\05\08@130948 by Patrik Husfloen

picon face
Yes, the tube would be filled at all times and I would only want to monitor the actual flow.
Impeller is one way to go although I'm looking for something more simple :)

Thanks.

Patrik


----- Original Message ----- From: "Shawn Yates" <spam_OUTsyatesspam_OUTspamRemoveMECARETECHNOLOGIES.COM>
To: <RemoveMEPICLISTspam.....MITVMA.MIT.EDU>
Sent: Tuesday, May 08, 2001 6:49 PM
Subject: Re: [EE]: detect waterflow


{Quote hidden}

> {Original Message removed}

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