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

Truncated match.
PICList Thread
'More on the PIC-Eval board'
1996\06\24@145925 by Doug Manzer

picon face
I've gotten some interest in USENET about my proposed PIC
evaluation board; here are some responses from different readers
with my replies:

> Couldn't one just feed the PIC 4 clock pulses (or 8 for a
> conditional) to do a single-step?...  The only little flaw is that
> the regs can't be examined, but there way be a workaround.

Exactly the problem that ruled out this approach for me, since
the whole point is to be able evaluate the performance of the PIC
in several ways including examine registers. However, you did give
me the idea that clock cycles could be run through a binary counter
to get an instruction count between events.

> I agree with you there's something missing, but I think what it is
> [and I've been tempted to fix this myself] would be a
> PC-compatible board which would emulate a PIC's I/O (port pins,
> RTCC, and clock input) and allow the 8x88 to access it
> conveniently.

Something like this has been suggested to Microchip already and I
don't think they're overly thrilled with the idea. The thing is,
it seems like a big programming effort to get an IBM-PC to emulate
a PIC, compared to the real thing running in a test environment.
For instance, could you duplicate *exactly* the interrupt latency
of a real PIC? (And therein could lurk a tricky bug).

>       Why not make up a 16c84 based board.  Have the '84 hooked up to
>the parallel port in 'In System Programming mode', provide a cheap $0.84
>4Mhz ceramic resinator.  Sure you could only reprogram the chip 1000 or
>so times (100 minimum, 1000 typical), but for about $10, whoe cares?  The
>entire device (minus power-supply) could be built for about $20 or less.

I have all the hardware to do this, but it's not quite enough.
Sure I can program an '84 and run it in a PICDEM or proto
board, but the problem is, how do I verify its performance -- even
if all the LED's and bells and whistles seem to work correctly?
With that setup I can't, say, run just one subroutine (in real
time, in a real target environment) and make sure it's working
correctly.

I'm always amazed at the sheer variety of disguises that bugs come
in; some deceptively simple while others are fiendishly subtle.
And the same goes for their discovery. Sometimes it takes days of
testing with sophisticated instruments while other times you just
stumble over a nasty one while reviewing the code for some other
reason. On one recent project I noticed a small (but unusual) time
lag between pulses on a scope, but was busy with something else at
the time and didn't pay much attention (uh-oh!). I only found out
what was going on some time later when a senior associate asked,
"Why are you missing a break in this switch statement?" (The
source code had gotten scrambled while being sent as e-mail.)

So what I'd like to see are facilities for several levels of
testing. For instance the PIC-Eval could have a few extra features
such as scope trigger points that don't take up any of the user's
i/o pins. This could be done at almost no cost (with some
diagnostic code in the user's pgm) or with a bit more hardware to
monitor the instruction bus.

My last posting left out a method of resetting the output
handshake bit (to host). Here's an idea - run the latched versions
of A15 and A14 into both sides of an LS139 dual 2-4 decoder. OE-
enables one side and WR- the other. Y0 and Y1 aren't used on
either side (corresponds to A15 low). Y2 with WR- sets the output
data latch as well as the 1-bit handshake latch. Y3 with WR-
clears the handshake bit. (A hex inverter will be needed to get
the right polarity on some of these signals).

Y2 with OE- reads the input latch and handshake. Y3 with OE- is
spare, and could be used as a scope trigger point for the user.

If more trigger points or other functions are wanted then A15
through A13 could be used with a pair of 3-to-8 deocders.

A few developers have suggested a serial interface, rather than
parallel which I suppose is too much like a hardware hack.
However, if I build a proto it's probably going to be parallel as
it's faster and requires less debugging of the loader PIC since
the host communicates with the target more directly. The
difference in speed starts to get significant with functions such
as multi single step with instruction trace.

Regards, D.M.

1996\06\25@113504 by John B C Walker

flavicon
picon face
On Mon, 24 Jun 1996, Doug Manzer wrote:

> > Couldn't one just feed the PIC 4 clock pulses (or 8 for a
> > conditional) to do a single-step?...  The only little flaw is that
> > the regs can't be examined, but there way be a workaround.
>
> Exactly the problem that ruled out this approach for me, since
> the whole point is to be able evaluate the performance of the PIC
> in several ways including examine registers. However, you did give
> me the idea that clock cycles could be run through a binary counter
> to get an instruction count between events.
>

Okay, you've said that this idea won't work. Have you any other ideas for
single-stepping? I had thought of supplying 4 clock pulses myself. And to
read the registers, could they not be displayed sequentially on a port in
a predefined format, including the initial state of WREG, which could
then be written back in, so that the state is the same. Not exactly
real-time, but do you think it would suffice?

J.W.

-----------------------------------------------------------------
       Johnnie Walker
       MSc Digital Systems Engineering
       Heriot-Watt University
       email: spam_OUTceejbcwTakeThisOuTspamcee.hw.ac.uk
              .....ceejbwKILLspamspam@spam@pp.hw.ac.uk
              ceejbwspamKILLspamtorduff.hw.ac.uk
       www: http://www.cee.hw.ac.uk/~ceejbcw
       tel: (0131) 343 2864
-----------------------------------------------------------------

1996\06\25@144856 by Scott Newell

flavicon
face
>On Mon, 24 Jun 1996, Doug Manzer wrote:
>
>> > Couldn't one just feed the PIC 4 clock pulses (or 8 for a
>> > conditional) to do a single-step?...  The only little flaw is that
>> > the regs can't be examined, but there way be a workaround.
>
>Okay, you've said that this idea won't work. Have you any other ideas for
>single-stepping? I had thought of supplying 4 clock pulses myself. And to
>read the registers, could they not be displayed sequentially on a port in
>a predefined format, including the initial state of WREG, which could
>then be written back in, so that the state is the same. Not exactly
>real-time, but do you think it would suffice?
>
>J.W.

I guess we really need a single-step interrupt.

Say we've got a gate on the clock line.
How about turning the clock on, counting 4 clocks (to allow one instruction
to execute) then force an interrupt (clock continues to run).  The interrupt
is caught by a routine that does a trace, register dump, whatever, before
returning and gating the clock back off (might have to delay a few cycles to
be sure to finish up the return instruction).  Wouldn't this put us back at
the next instruction in line?
Would interrupt latency cause problems?  You could sync the generated
interrupt to the main clock, so you could be sure the interrupt would happen
after just one instruction, right?  Am I missing something?

Now, single-stepping inside an interrupt without blowing the stack might get
tricky!

later,
newell

1996\06\25@181414 by Mark K Sullivan

flavicon
face
What's wrong with Microchip's bond-out package?  Will they sell them to third
parties?

- Mark Sullivan -

1996\06\26@015221 by fastfwd

face
flavicon
face
Mark K Sullivan <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU> wrote:

> What's wrong with Microchip's bond-out package?  Will they sell them
> to third parties?

Mark:

That first question has two possible interpretations... I'll assume
that you meant, "What's wrong with using Microchip's bondout chips
for the PIC-Eval board?" since to assume otherwise would mean that
I'd have to write a REALLY long reply.

Microchip doesn't seem real enthused about selling those bondout
chips to anyone who isn't already an established emulator
manufacturer.  There are at least a couple people on the list who've
been unsuccessful in their attempts to get small quantities of them.

-Andy

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

1996\06\26@045435 by Richard G. Thomas

picon face
>
> Mark K Sullivan <PICLISTspamspam_OUTMITVMA.MIT.EDU> wrote:
>
> > What's wrong with Microchip's bond-out package?  Will they sell them
> > to third parties?
>
> Mark:
>
> That first question has two possible interpretations... I'll assume
> that you meant, "What's wrong with using Microchip's bondout chips
> for the PIC-Eval board?" since to assume otherwise would mean that
> I'd have to write a REALLY long reply.
>
> Microchip doesn't seem real enthused about selling those bondout
> chips to anyone who isn't already an established emulator
> manufacturer.  There are at least a couple people on the list who've
> been unsuccessful in their attempts to get small quantities of them.

What are Microchip bondout chips? Are all emulators based on these?

We have a couple of Picmasters and several ICEPICs from RF Solutions, are
the chips on "daughter" boards for similar pics likely to be the same?
Some of the numbering would seem to suggest so.

?

----------------------------------------------------------------------------
| Richard Thomas                                 *%$!#*&D:\pic\pic archive 1? *&*(#~@* *&%#" |
| Department of Design,                                                    |
| Brunel University,  Runnymede,  Egham,  TW20 0JZ,  UK.                   |
| @spam@Richard.ThomasKILLspamspambrunel.ac.uk                  phone:  01784  431341  x267 |
----------------------------------------------------------------------------

1996\06\27@062421 by Eyal Oppenheimer

flavicon
face
Scott Newell wrote:

----------- cut------------
>
> I guess we really need a single-step interrupt.
>
> Say we've got a gate on the clock line.
> How about turning the clock on, counting 4 clocks (to allow one instruction
> to execute) then force an interrupt (clock continues to run).  The interrupt
> is caught by a routine that does a trace, register dump, whatever, before
> returning and gating the clock back off (might have to delay a few cycles to
> be sure to finish up the return instruction).  Wouldn't this put us back at
> the next instruction in line?
> Would interrupt latency cause problems?  You could sync the generated
> interrupt to the main clock, so you could be sure the interrupt would happen
> after just one instruction, right?  Am I missing something?
>
> Now, single-stepping inside an interrupt without blowing the stack might get
> tricky!
>


I assume that:
1. You have a second cpu to control the target cpu.
2. The target cpu runs its software from external RAM (mapped to code space).
3. You can count/control the clock.

How about the following setup:
You count 2 clocks and then insted of letting the target cpu to fetch the next
instruction from the RAM/ROM you send the opcodes from your control CPU,
send the taget 2 more clocks to compleate the instruction, and then continu to
send instruction for a program that read the registers. The start address can be
saved to an external leatch and the written to the PC at the end of the control
program.


--
Eyal Oppenheimer
E-mail: KILLspameyaloKILLspamspamaks.com
R&D
Aladdin Knowledge Systems Ltd.
Tel:    +972-3-636-2222
Fax:    +972-3-537-5796
WWW Home Page:  http://www.aks.com

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