Searching \ for 'SoNoboby knows' 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=sonoboby+knows
Search entire site for: 'SoNoboby knows'.

Truncated match.
PICList Thread
'SoNoboby knows'
1997\05\29@124617 by Kenny Baby

flavicon
picon face
I take it that noboby knows how to save watch and stopwatch windows
with a project, and noboby knows if the osc cal value in
12c508/9 is erased under a uv source, and nobody knows how to cancel
a stack underflow warning in mplab, and noboby knows why you have to
move the mouse during simulation of one's machine code, to get it to
'run to' quicker, but everybody knows how to find the guy that the
other guy is looking for. And everybody knows how to discuss projects
or problems that have never died away, and have very little
connection to pic programming.

oh well, I'll have to find out another way.
,
,
,
,
The Samaratans........They bring a smile to an empty heart.

1997\05\29@134611 by Mike

flavicon
face
At 05:41 PM 5/29/97 BST, you wrote:
>I take it that noboby knows how to save watch and stopwatch windows
>with a project, and noboby knows if the osc cal value in
>12c508/9 is erased under a uv source, and nobody knows how to cancel
>a stack underflow warning in mplab, and noboby knows why you have to
>move the mouse during simulation of one's machine code, to get it to
>'run to' quicker, but everybody knows how to find the guy that the
>other guy is looking for. And everybody knows how to discuss projects
>or problems that have never died away, and have very little
>connection to pic programming.

Maybe its just not sexy enough ?

Rgds

mike
Perth, Western Australia


Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
                                                                      Massen

1997\05\29@163748 by Andy Kunz

flavicon
face
At 05:41 PM 5/29/97 BST, you wrote:
>I take it that noboby knows how to save watch and stopwatch windows
>with a project,

Maybe nobody knows what emulator you're running...

>and noboby knows if the osc cal value in
>12c508/9 is erased under a uv source,

It is erased then, but it comes pre-programmed.

>and nobody knows how to cancel
>a stack underflow warning in mplab, and noboby knows why you have to
>move the mouse during simulation of one's machine code, to get it to
>'run to' quicker,

Because... <G>

Maybe nobody is running mplab...

>but everybody knows how to find the guy that the
>other guy is looking for. And everybody knows how to discuss projects
>or problems that have never died away, and have very little
>connection to pic programming.

AMEN!

>oh well, I'll have to find out another way.

Do that, and somebody will ask you to post the results!

Andy

======================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865 USA
             Electronics for Industry & R/C Hobbyists
        "Go fast, turn right, and keep the wet side down!"
======================================================================

1997\05\29@164200 by Stephen R. Synakowski

flavicon
face
Kenny Baby wrote:
>
> I take it that noboby knows how to save watch and stopwatch windows
> with a project, and noboby knows if the osc cal value in
> 12c508/9 is erased under a uv source, and nobody knows how to cancel
> a stack underflow warning in mplab, and noboby knows why you have to
> move the mouse during simulation of one's machine code, to get it to
> 'run to' quicker, but everybody knows how to find the guy that the
> other guy is looking for. And everybody knows how to discuss projects
> or problems that have never died away, and have very little
> connection to pic programming.
>
> oh well, I'll have to find out another way.
> ,
> ,
> ,
> ,
> The Samaratans........They bring a smile to an empty heart.


maybe this is not their life and haven't gotten around to reading your
message yet. As far as saving watch windows, don't know. I've used MPlab
and like it, but have never tried to save them. Probably can't..

1997\05\30@005458 by tjaart

flavicon
face
Kenny Baby wrote:
>
> I take it that noboby knows how to save watch and stopwatch windows
> with a project, and noboby knows if the osc cal value in
> 12c508/9 is erased under a uv source, and nobody knows how to cancel
> a stack underflow warning in mplab, and noboby knows why you have to
> move the mouse during simulation of one's machine code, to get it to
> 'run to' quicker, but everybody knows how to find the guy that the
> other guy is looking for. And everybody knows how to discuss projects
> or problems that have never died away, and have very little
> connection to pic programming.

I'm afraid you are right on most counts. I'd also like to know why
nobody
knows why it is impossible to save the File Register windows setup
to'symbolic'.

I think the 'Stack underflow' problem is a bug that Mchip tried to
squash in the 3.22.02 version. I still get it from time to time though.

I disagree on your statement about finding 'the other guy'. I'd like to
get hold of the guy that's responsible for fixing the bugs in MPLAB and
MPLABC. :) I think Microchip should make him work more that ten minutes
a day. :))

> oh well, I'll have to find out another way.

--
Friendly Regards

Tjaart van der Walt
spam_OUTtjaartTakeThisOuTspamwasp.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\30@035948 by Keith Dowsett

flavicon
face
At 17:41 29/05/97 BST, you wrote:

> and noboby knows if the osc cal value in 12c508/9 is erased under a uv
source,

It is, so read 'em when they arrive and write it on the bottom with a
diamond tipped scriber.

>and nobody knows how to cancel a stack underflow warning in mplab,

RTFM (under ERRORLEVEL)


>and noboby knows why you have to
>move the mouse during simulation of one's machine code, to get it to
>'run to' quicker,

FIIK  (F...ed If I Know)

>but everybody knows how to find the guy that the
>other guy is looking for. And everybody knows how to discuss projects
>or problems that have never died away, and have very little
>connection to pic programming.

What do you expect when you get a whole lot of creative engineers on a list.
We'll talk about other things as well as engineering. If you're too
blinkered to enjoy these issues don't blame us.

>oh well, I'll have to find out another way.

Have fun...

Keith.
==========================================================
Keith Dowsett         "Variables won't; constants aren't."

E-mail: .....kdowsettKILLspamspam@spam@rpms.ac.uk
  WWW: http://kd.rpms.ac.uk/index.htm

1997\05\30@040822 by David Gould

flavicon
face
> >and noboby knows why you have to
> >move the mouse during simulation of one's machine code, to get it to
> >'run to' quicker,
>
> FIIK  (F...ed If I Know)

Just guessing here, but most modern (last 3 years) PCs go into reduced clock
power save modes (Energy Star Green PC (tm)) if there is no "user" activity
within a certain time. "user" activity is taken to mean mouse, keyboard,
serial or printer port interrupts.

I have never run, indeed seen, this simulator, but if it takes a long time
and you wander off to lead a life for a few minutes, your PC may go into
powersave mode and run really s l o w l y . To avoid this, bump the mouse,
or reboot into your bios setup mode and reset the powersave parameters in
your bios.

Since I am just guessing here, please feel free to flame me to cinders if
I got it way wrong. If I am close, please keep it to lukewarm.


-dg


David Gould           dgspamKILLspamillustra.com            510.869.6383 or 510.305.9468
Informix Software (formerly Illustra)  1111 Broadway #2000  Oakland, CA 94607
- I realize now that irony has no place in business communications.

1997\05\30@045634 by Kalle Pihlajasaari

flavicon
face
Hi,

> I take it that noboby knows how to save watch and stopwatch windows

I think this is a persistent feature of MPLAB, makes you think about
what you want in those windows and where you place them each time.
I believe one of the versions sort of got it right but cannot confirm.

> with a project, and noboby knows if the osc cal value in
> 12c508/9 is erased under a uv source, and nobody knows how to cancel

The OSCCAL value is indeed erased under UV like any other program word.

You can have a look at a bit of testing I did at the following URL.

  http://www.ip.co.za/people/kalle/pic/default.htm#caltest

Cheers
--
Kalle Pihlajasaari   .....kalleKILLspamspam.....ip.co.za   http://www.ip.co.za/ip
Interface Products   P O Box 15775, DOORNFONTEIN, 2028, South Africa
+ 27 (11) 402-7750   Fax: 402-7751    http://www.ip.co.za/people/kalle

DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

1997\05\30@051328 by Clyde Smith-Stubbs

flavicon
face
Thus spake David Gould (EraseMEdgspam_OUTspamTakeThisOuTILLUSTRA.COM):

> > >and noboby knows why you have to
> > >move the mouse during simulation of one's machine code, to get it to
> > >'run to' quicker,
>
> Just guessing here, but most modern (last 3 years) PCs go into reduced clock
> power save modes (Energy Star Green PC (tm)) if there is no "user" activity

Good guess, but it's not the reason. I don't know what the exact reason
is either, but it has something to do with certain programmers not knowing
how to handle Windows events properly. There are a number of things about
MPLAB that suggest its internal program structure is a little odd. For
example, if you have a source file window open and a program window open,
and you try to set a breakpoint in the source window, sometimes it will
instead set one at the corresponding line (i.e. window line, not program
location) in the program window. Sometimes you can even click on the scroll bar
arrows in the source window and see the program window scroll instead!

It seems to get confused sometimes about which window events belong in
which window.

Regarding the mouse and emulations speed, it seems that MPLAB has a timer
running that posts WM_TIMER events to its queue, at about a 5 Hz rate. I
suspect that it waits for these events, during which time it does nothing.

When the mouse is being moved, WM_MOUSExxx events and others get posted
to the queue, causing the wait for event call to return immediately. If you
monitor CPU usage of MPLAB (use the task manager window under NT) MPLAB
while simulating is using only 9% or so CPU time! But moving the mouse
rapidly can boost this to 60% or more. Since simulation is CPU intensive,
it must be spending the idle time waiting on the event queue.

One could be led to suspect that someone didn't have a queue :-) I surmise
that the programmer knew she had to be prepared to accept events (like
clicking the STOP button (why the stop and start buttons and keys are
different is another mystery) and decided to do this by starting a timer,
and periodically waiting on the event queue, relying on the timer to end
the wait after a short interval. This probably worked ok on a slow machine,
where the timer period was well matched to the time spend simulating between
GetMessage() calls, but on a faster machine most of the time is spent
waiting for the timer to expire.

The correct technique is, of course, to call PeekMessage() every so often
(like every several thousand instructions simulated) which is a non-blocking
test for queued events. If it returns an event, it can then be
dispatched and handled before (possibly) resuming simulation.


--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
clydespamspam_OUThtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\05\30@072312 by Mike Smith

flavicon
face
> From: Clyde Smith-Stubbs <@spam@clydeKILLspamspamHTSOFT.COM>
> To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
> Subject: Re: SoNoboby knows
> Date: Friday, 30 May 1997 18:43
>
> Thus spake David Gould (RemoveMEdgTakeThisOuTspamILLUSTRA.COM):
>
> > > >and noboby knows why you have to
> > > >move the mouse during simulation of one's machine code, to get it to
> > > >'run to' quicker,
> >
> > Just guessing here, but most modern (last 3 years) PCs go into reduced
clock
> > power save modes (Energy Star Green PC (tm)) if there is no "user"
activity
>
> Good guess, but it's not the reason. I don't know what the exact reason
> is either, but it has something to do with certain programmers not
knowing
> how to handle Windows events properly. There are a number of things about

How very true! :)

> MPLAB that suggest its internal program structure is a little odd. For
> example, if you have a source file window open and a program window open,
> and you try to set a breakpoint in the source window, sometimes it will
> instead set one at the corresponding line (i.e. window line, not program
> location) in the program window. Sometimes you can even click on the
scroll bar
> arrows in the source window and see the program window scroll instead!
>
> It seems to get confused sometimes about which window events belong in
> which window.
>
> Regarding the mouse and emulations speed, it seems that MPLAB has a timer
> running that posts WM_TIMER events to its queue, at about a 5 Hz rate. I
> suspect that it waits for these events, during which time it does
nothing.
>
> When the mouse is being moved, WM_MOUSExxx events and others get posted
> to the queue, causing the wait for event call to return immediately. If
you
> monitor CPU usage of MPLAB (use the task manager window under NT) MPLAB
> while simulating is using only 9% or so CPU time! But moving the mouse
> rapidly can boost this to 60% or more. Since simulation is CPU intensive,
> it must be spending the idle time waiting on the event queue.
>

I suspect that its because its a 16bit(co-operative) app running in a
32bit(pre-emptive) os (lets not fight over whether '95 is 16 or 32 - for
the purposes of this argument it doesn't matter a stuff)  The foreground
app gets the WM_MOUSE messages, which are running at something like
real-time priority, rather than the normal priority a normal app gets.

> One could be led to suspect that someone didn't have a queue :-) I
surmise
> that the programmer knew she had to be prepared to accept events (like
> clicking the STOP button (why the stop and start buttons and keys are
> different is another mystery) and decided to do this by starting a timer,
> and periodically waiting on the event queue, relying on the timer to end
> the wait after a short interval. This probably worked ok on a slow
machine,
> where the timer period was well matched to the time spend simulating
between
> GetMessage() calls, but on a faster machine most of the time is spent
> waiting for the timer to expire.

This is a f***ing awful way to code for any windows program.  You can spot
the bad windows apps quite easily, BTW.  Set up the System Monitor and
watch for 100% processor usage.  Dead giveaway.

>
> The correct technique is, of course, to call PeekMessage() every so often
> (like every several thousand instructions simulated) which is a
non-blocking
> test for queued events. If it returns an event, it can then be
> dispatched and handled before (possibly) resuming simulation.
>

Or use multithreading.

MikeS
<spamBeGonemikesmith_ozspamBeGonespamrelaymail.net>

1997\05\30@090143 by Clyde Smith-Stubbs

flavicon
face
Thus spake Mike Smith (TakeThisOuTmikesmith_ozEraseMEspamspam_OUTRELAYMAIL.NET):

> I suspect that its because its a 16bit(co-operative) app running in a
> 32bit(pre-emptive) os (lets not fight over whether '95 is 16 or 32 - for

I think this is a red herring - the question is not really "why does MPLAB
get faster if you move the mouse", but "why the hell is it so slow to begin
with?".

> Or use multithreading.

Not an option for a 16 bit app.


--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
RemoveMEclydespamTakeThisOuThtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\05\30@143137 by Mike

flavicon
face
At 10:59 PM 5/30/97 +1000, you wrote:

>> Or use multithreading.
>
>Not an option for a 16 bit app.

Why not ?

Isn't that an operating system and program development issue not one
of word size ?

Rgds

mike


Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
                                                                      Massen

1997\05\30@151440 by Clyde Smith-Stubbs

flavicon
face
Thus spake Mike (erazmusEraseMEspam.....WANTREE.COM.AU):

> >> Or use multithreading.
> >
> >Not an option for a 16 bit app.
>
> Why not ?
>
> Isn't that an operating system and program development issue not one
> of word size ?

16 bit in this context refers to Win16, which is an API, as opposed to
Win32, which is also an API. The fact that Win16 and win32 programs use
16 and 32 bit word lengths is incidental to this discussion. Win16
programs will run under Windows 3.1, Win32 will not. Windows 3.1, and
therefore Win16, does not offer multi-threading. MPLAB is a Win16
program. Microchip have not announced when they will produce a Win32
version.

--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
EraseMEclydespamhtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\05\30@182142 by Andy Kunz

flavicon
face
At 02:31 PM 5/30/97 -0400, you wrote:
>>> Or use multithreading.
>>
>>Not an option for a 16 bit app.
>
>Why not ?
>
>Isn't that an operating system and program development issue not one
>of word size ?

Mike,

Some folks aren't of the caliber of others.  Some even think you need a
PC-size box to multi-thread.  Some think a weaver's beam <G>

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\05\30@214316 by Mike Smith

flavicon
face
> From: Andy Kunz <RemoveMEmontanaEraseMEspamEraseMEFAST.NET>
> To: RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU
> Subject: Re: SoNoboby knows
> Date: Saturday, 31 May 1997 06:48
>
> At 02:31 PM 5/30/97 -0400, you wrote:
> >>> Or use multithreading.
> >>
> >>Not an option for a 16 bit app.
> >
> >Why not ?
> >
> >Isn't that an operating system and program development issue not one
> >of word size ?
>
> Mike,
>
> Some folks aren't of the caliber of others.  Some even think you need a
> PC-size box to multi-thread.  Some think a weaver's beam <G>

Arrgh!  I knew this was going to degenerate into an os/machines war!    You
could MT on a high-end PIC if you didn't want GUI.  It's the GUI that needs
the PC size box, not the MT.

MikeS
<RemoveMEmikesmith_ozTakeThisOuTspamspamrelaymail.net>

1997\05\30@215520 by Mike Smith

flavicon
face
> From: Clyde Smith-Stubbs <EraseMEclydespamspamspamBeGoneHTSOFT.COM>
> To: RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU
> Subject: Re: SoNoboby knows
> Date: Friday, 30 May 1997 22:29
>
> Thus spake Mike Smith (mikesmith_ozSTOPspamspamspam_OUTRELAYMAIL.NET):
>
> > I suspect that its because its a 16bit(co-operative) app running in a
> > 32bit(pre-emptive) os (lets not fight over whether '95 is 16 or 32 -
for
>
> I think this is a red herring - the question is not really "why does
MPLAB
> get faster if you move the mouse", but "why the hell is it so slow to
begin
> with?".

I was trying to say that it is one of a class of 16 bit apps that run
slowly on Win32.

>
> > Or use multithreading.
>
> Not an option for a 16 bit app.
>

True.  So why is it still a 16 bit app?  3.11 was buried  2 years ago.
MPLAB's latest release is since then.  It doesn't take that long to port
from one to the other.

MikeS
<spamBeGonemikesmith_ozSTOPspamspamEraseMErelaymail.net>

1997\05\31@110842 by Andy Kunz

flavicon
face
>Arrgh!  I knew this was going to degenerate into an os/machines war!    You
>could MT on a high-end PIC if you didn't want GUI.  It's the GUI that needs
>the PC size box, not the MT.

You can cooperatively multi-task on a 12C508 if you know what you're doing.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\05\31@110845 by Andy Kunz

flavicon
face
>True.  So why is it still a 16 bit app?  3.11 was buried  2 years ago.
>MPLAB's latest release is since then.  It doesn't take that long to port
>from one to the other.

It can very well.  Many names were changed, and many parameters.  It ain't
a simple "recompile with a 32-bit bit compiler" deal.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\05\31@132935 by nigelg

flavicon
picon face
In message  <KILLspam01330523431454spamBeGonespamonaustralia.com.au> EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU writes:

> True.  So why is it still a 16 bit app?  3.11 was buried  2 years ago.
> MPLAB's latest release is since then.  It doesn't take that long to port
> from one to the other.

There's still many times more machines running 3.x than 95, so if compiled
as a 32 bit app it wouldn't run on most machines out there.

Besides, MicroChip would have to pay for the upgrade to Delphi 2 :-).

Nigel.

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

1997\05\31@152726 by Scott Newell

flavicon
face
>Besides, MicroChip would have to pay for the upgrade to Delphi 2 :-).
>
>Nigel.

Actually, I think it's written in OWL.

Speaking of Delphi, I got the simulator to run about 20 times faster by
writting a little Delphi app to simply 'pound' the MPLAB IDE with mouse
messages.  (A more elegant solution might be to raise the MPLAB thread's
priority.  Oh well.)


spamBeGonenewellspamKILLspamcei.net

1997\05\31@171852 by Clyde Smith-Stubbs

flavicon
face
Thus spake Scott Newell (.....newellspam_OUTspamCEI.NET):

> Speaking of Delphi, I got the simulator to run about 20 times faster by
> writting a little Delphi app to simply 'pound' the MPLAB IDE with mouse
> messages.  (A more elegant solution might be to raise the MPLAB thread's
> priority.  Oh well.)

Nope, raising the MPLAB task priority (it has no threads) will do nothing
since it is DELIBERATELY waiting for messages, and until one arrives, will
do nothing, irrespective of its priority. This behaviour is not unique to
running under Win32, BTW. It does exactly the same thing under Win3.1.

Any conspiracy theorists out there?

--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
TakeThisOuTclyde.....spamTakeThisOuThtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/


'SoNoboby knows'
1997\06\02@071257 by mike
flavicon
picon face
In message  <TakeThisOuT01330523431454KILLspamspamspamonaustralia.com.au> .....PICLISTspamRemoveMEMITVMA.MIT.EDU writes:
>
> True.  So why is it still a 16 bit app?  3.11 was buried  2 years ago.
> MPLAB's latest release is since then.  It doesn't take that long to port
> from one to the other.
>
> MikeS

No, but win3.1x apps work on win95, but not the other way round. There
are lots of people still developing on win3.1x platforms who would
be not be able to use the tools that Microchip produce.

So, you either have two versions of the same application (16 and 32 bit)
and all the headaches that that brings, or you produce one version of
software that runs on both.

The decision is easy to make, I think.


Regards,


Mike Watson

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