Searching \ for 'An Idea....' 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=idea
Search entire site for: 'An Idea....'.

Truncated match.
PICList Thread
'An Idea....'
2000\02\14@064536 by Jonathan Philpott

picon face
Hi,


I was thinking, would it be possible to have a PIC
that could you could "talk" to via a serial port, to
give it commands... i was thinking something like
this,

When you connect to it, it just waits for input, and
gives a prompt:

>_

Then you can give it a command to turn on one of the
output lines, a simple one character command would be
enough, e.g "o" for on and "f" for off, so:

>o1

would turn on output line one, and f1 would turn it
off.

Is this is possible?

Jon
--

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

2000\02\14@070648 by Michael Rigby-Jones

flavicon
face
part 0 2778 bytes
<P><FONT SIZE=2 FACE="Arial">I was thinking, would it be possible to have a PIC</FONT>
<BR><FONT SIZE=2 FACE="Arial">that could you could &quot;talk&quot; to via a serial port, to</FONT>
<BR><FONT SIZE=2 FACE="Arial">give it commands... i was thinking something like</FONT>
<BR><FONT SIZE=2 FACE="Arial">this,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">When you connect to it, it just waits for input, and</FONT>
<BR><FONT SIZE=2 FACE="Arial">gives a prompt:</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&gt;_</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Then you can give it a command to turn on one of the</FONT>
<BR><FONT SIZE=2 FACE="Arial">output lines, a simple one character command would be</FONT>
<BR><FONT SIZE=2 FACE="Arial">enough, e.g &quot;o&quot; for on and &quot;f&quot; for off, so:</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">&gt;o1</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">would turn on output line one, and f1 would turn it</FONT>
<BR><FONT SIZE=2 FACE="Arial">off.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Is this is possible?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Jon</FONT>
<BR><FONT SIZE=2 FACE="Arial">--</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Yes.&nbsp; Very easy actually, you could do this on a tiny 12C508 with room to spare, although you'd be limited to only 4 pins to control (2 power, 2 serial).&nbsp; A bigger PIC or a shift register could be used to increase the number of lines available.&nbsp; But why stop there?&nbsp; You could also have a command to read in the state of an input, to change an input to an output and vice versa, toggle an output.&nbsp; It's all pretty straightforward.&nbsp; Did you have an application in mind?</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Mike</FONT>
</P>
<BR>

<P><FONT SIZE=2 FACE="Arial">__________________________________________________</FONT>
<BR><FONT SIZE=2 FACE="Arial">Do You Yahoo!?</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">No.</FONT>
</P>
</UL>
</BODY>
</HTML>
</x-html>

2000\02\14@072345 by paulb

flavicon
face
Jonathan Philpott wrote:

> I was thinking, would it be possible to have a PIC that could you
> could "talk" to via a serial port, to give it commands...

 You mean the http://www.dontronics.com/picex.html or the AnswerMan
http://www.micromint.com/modules.htm ?
--
 Cheers,
       Paul B.

2000\02\14@073558 by Dave VanHorn

flavicon
face
> > I was thinking, would it be possible to have a PIC that could you
> > could "talk" to via a serial port, to give it commands...

I did an interpreted language in an F84 a while back.
16 commands, with varying parameters, including ASCII text.
Program flow control like Skip + N commands or Skip - N commands, or
if input, (a TTL line) skip N commands

There was a PC program that took the english version, and tokenized it, then
fed it to the 84 on a bit-banged serial port, and the 84 stored it in EEPROM
for execution later.
(after it detected that the host program was no longer talking to it.)


--------
Are you an ISP?
Are you tired of dealing with SPAM?
We can help.
http://www.spamwhack.com

2000\02\14@085101 by WF

flavicon
face
The famous SET and QUERY commands, i think, used in ANSWER MAN...

For PIC will be a good idea, because the ANSWER MAN is too expensive...

Miguel

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

then
> fed it to the 84 on a bit-banged serial port, and the 84 stored it in
EEPROM
> for execution later.
> (after it detected that the host program was no longer talking to it.)
>
>
> --------
> Are you an ISP?
> Are you tired of dealing with SPAM?
> We can help.
> http://www.spamwhack.com

2000\02\14@095351 by Jonathan Philpott

picon face
I was thinking of having a standard controlling
program, that could use the idea to make a sort of
"engineers mode" for debugging etc.


--- Michael Rigby-Jones <mrjonesspamKILLspamNORTELNETWORKS.COM>
wrote:
{Quote hidden}

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

2000\02\14@105432 by M. Adam Davis

flavicon
face
Short Answer: Yes, and not too difficult to accomplish.

Long Answer:
First you should define your needs, and then your instruction set.  For
instance, were I to create such a beast, I would probably shoot for 1 PIC, and
16 i/o lines.  To make my job easier, I would choose one of the flash chips
which has an on-board USART, and the ability to program it's own memory
(16F8xx).

My instructions might be as follows:
(Pins are number in hex, 0-f, so I only need to specify one digit to refer to
any pin)
COx     - Configure Pin x as output
CIx     - Configure Pin x as input
CBxyy   - Configure Byte (8 pins, x being 0 or 8) as in/out according to yy
CCyyyy  - Configure Chip input/output according to yyyy
CNyyyy  - Configure Notify, notify me (send a read/set response) when one of
         these pins change states (so I don't have to keep polling you)

SHx     - Set Pin x High
SLx     - Set Pin x Low
SWxy    - Set Word (4 pins, x being first pin in the group of four [0,4,8,C])
         to value y (again, in hex)
SBxyy   - Set Byte to hex value yy
SCyyyy  - Set Chip (16 bits) according to yyyy

RBx     - Read bit x
RWx     - Read word x
RBx     - Read Byte x
RC      - Read all bits

Pyyyy   - Reprogram Chip, yyyy being size of program in words
         This can be used to upgrade the firmware, add new features, etc.
         This command actually gives control to the bootloader, and is the
         only command available if the loaded program has a bad checksum.

Chip responses might be:
Configure Responses:
C:yyyy:zzzz     - yyyy is the current configuration if I/O
                 zzzz is the current notify setting
Read/Set Responses:
x:b     - b is the current status of pin x (H or L) (so it isn't confused
         with the next response which is in hex)
x:y     - y is the current status of word starting at x (y = 0-f)
x:yy    - yy is the current status of byte starting at x
C:yyyy  - yyyy is the current status of all i/o (also in response to
         change in pin state if one of the changed pins is on the Notify
         list)
Program response:
P:yyyy  - Ready to receive yyyy words of program, Checksum first.

One could certianly add new features (A/D, PWM, Timers, etc) as their needs
warranted.

At any rate, I might actually persue something along these lines.  It would make
proof-of-concept and prototyping much easier for some projects... One could
almost think of it as a serial 8255, just more configurable.

There would be more pins available than just 16, which could be used as more
I/O, A/D, or as an address scheme (every command and response is prefaced by a 1
digit hex address, four extra pins are used to set that address)

At any rate, that's enough thinking for now.  I will finish my current project
(rs-232 LCD & keypad interface for home automation) first, then will work on
this.  Anyone who is interested in the progress of this project should check my
PIC web site occasionally (http://ubasics.com/adam/pic/)

-Adam

Jonathan Philpott wrote:
{Quote hidden}

2000\02\14@130436 by Erik Reikes

flavicon
face
Absolutely.  This is how I do a lot of my debugging and set calibration
values on my PIC's.  All that you need is a level shifter such as a MAX203
or 232 or whatever you can dig up.  With the lack of an ICE for the F87x
series and the (IMHO) utterly useless nature of the ICD, I end up debugging
most everything using the tried and true "printf" debugging system out the
serial port.

I use the USART when possible and I have a software uart that I can TX on
any available IO line.



At 03:43 AM 2/14/00 -0800, you wrote:
{Quote hidden}

Erik Reikes
Software Engineer
Xsilogy, Inc.

.....ereikesKILLspamspam.....xsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\02\14@135856 by Don McKenzie

flavicon
face
"Paul B. Webster VK2BZC" wrote:
>
> Jonathan Philpott wrote:
>
> > I was thinking, would it be possible to have a PIC that could you
> > could "talk" to via a serial port, to give it commands...
>
>   You mean the http://www.dontronics.com/picex.html or the AnswerMan
> http://www.micromint.com/modules.htm ?
> --
>   Cheers,
>         Paul B.

Had to look to see what it was Paul, wrote that back in 1994, late last
century!
You mean Don actually used to do some PIC code? :-)

Don McKenzie    EraseMEdonspam_OUTspamTakeThisOuTdontronics.com      http://www.dontronics.com

World's Largest Range of Atmel/AVR and  PICmicro Hardware and  Software.
Free Basic Compiler and Programmer http://www.dontronics.com/runavr.html

2000\02\14@172335 by Stuart O'Reilly

flavicon
face
I actually did this using PBP, My aim was to have a little board like
this inside a cd player so i could make it remote controlled, eg. have
the output line connected to the buttons on the front panel and then
pulse the outputs when I wanted something to happen. I can post the code
later if any one wants it. (if i still have it). Setup was all done by
serial to eg. if the pulse on an output was to be positive going or
negative going etc.
Regards
Stuart O'Reilly

Jonathan Philpott wrote:
{Quote hidden}

2000\02\14@183349 by jamesnewton

face picon face
Exactly! YES YES YES. See
http://techref.massmind.org\idea\ebb.htm
especially the last bullet point under "In the CUMP project"

The upshot is that I think a $10 board consisting of a '877, MAX 232, Analog
front end, PWM output filters and power regulators could provide the
following:

Boot loader
http://www.picnpoke.com/demo/ROMzap.zip
http://www.htsoft.com/files/samples/bootldr.zip

RS232 debugger / monitor?

A port monitor
Ralph Stickley had already implemented a program to monitor register values
over an available hardware serial port. His PC software polls the PIC with
register numbers and receives a response via an ISR that consists of the
current value of that register. You can get it at:
http://www.piclist.com/stickleyregmon
[note that] one of the registers is the program counter and others are the
ports....

Triggered high speed copy of pins to RAM with RS232 control / reporting for
a super simple logic analyzer (20MHz max ~300x8 samples or ~5Mhz and ~2400x1
samples per trigger)?

A/D support for pic o'scope (20uS per sample gives 0-25kHz, ~300x8 to ~600x4
samples ) with display on PC via RS232?
http://www.people.cornell.edu/pages/shb7/posc.html Sean Hugh Breheny started
a higher end version of such a thing
http://www.bitscope.com/  is a top end version. Not worth the extra cost for
this but interesting anyway.

DVM (0 to 5v, 10bits = ~3 digits single channel via A/D or multiple channel
at lower res. via PWM capture with simple external hardware) display on PC
via RS232?
http://www.chipcenter.com/circuitcellar/november99/c119dp1.htm PIC Base DVOM
http://www.infosite.com/%7Ejkeyzer/piclist/2000/Feb/0623.html Wagners list
of options on front ends.

Function generator based on copy of RAM to port pins (20Mhz max ~300x8 or
~5Mhz and ~2400x1 steps) under PC control via RS232?

Signal generator via PWM (?Hz low useful frequency ~300 waveform steps with
simple external hardware RC) under PC control via RS232?
"Digital Frequency Synthesis" by Tom Napier in issue 99 (October 1998) of
Circuit Cellar INK. Uses a PIC as a Digital Frequency Synthesizer. Richard
Ottosen has developed an improved version for the Scenix SX
../scenix/sxncoex.zip

Regulated variable power supply with intelligent current limiting.
see also:

http://www.picnpoke.com
http://www.htsoft.com
http://www.piclist.com/projects.htm
www.geocities.com/CapeCanaveral/Lab/9595/
http://204.210.50.240/techref/default.asp?url=tools.htm

Anyway, you could develop right on [this board] and then port it to a
(smaller, cheaper) target processor which [this board] programs, and
stimulate and test via [this board] after the code is basically running.

---
James Newton jamesnewtonspamspam_OUTgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\02\14@232038 by Randy Glenn

picon face
Anything like PICIO for Virtual Breadboard (which looks like a really neat simulator)?

http://www.virtualbreadboard.com/PICIO.htm

-Randy Glenn
E-Mail: @spam@PICxpertKILLspamspamyahoo.com
Web: http://i.am/PICxpert

Currently wondering why I can't get in to Safe Mode - where's a Mac when you need it?

{Original Message removed}

2000\02\15@002341 by piclist.com

face picon face
Yes we can add all these external chips on to do everything better BUT... do
we really need it? How much can we accomplish with the basic "virtual"
versions supplied by the chip, a cable, a PC with a GUI front panel and a
few passives alone? Audio frequency O'Scope and signal generator, a few MHz
for logic and functions, 1 or 2 variable regulated power supplies. Its
enough for most work AND... it would cost what? $10.00?

Right now, people are paying $30, $40, $50, $200 for PIC programmers alone
and "making do" with Radio Shaft DVMs and wall warts to get started with
PICs. I think we can give them much, much more for much, much less.

As a professional, I can always use another 'scope channel and it doesn't
have to be fast most of the time. The digital triggering and sample hold
ability would be a nice complement to my analog 'scope.

If the CUMP thing would take off, we could have groups of people supporting
the programming of a growing list of other processors, PIC and AVR and
others.

Beginners like Jon can see the logic of it. I keep hearing echoes of this
idea from so many different places its just impossible for me to keep my
mouth shut about it.

Its something the PICList community needs to come together on. Its an open
source, give back to the community thing that everyone will benefit from.
Somebody will make a PCB and kit and sell them and others will add routines
and add ons like PLLs and external RAM scopes and better more sensitive
analog front ends, etc... Someone will write and sell or give away a nice
IDE style PC GUI front end program.

But to start with, someone has to take a '877, take Stickleys register
monitor and extend it into a full monitor, setup timing and port pin capture
/ function generation routines and PC display / stimulus program, add the
A2D setup code, analog front end and PC front end program to display
captured traces, add the PWM output and signal generator code and PC program
for frequency, waveform and amplitude selection, add the regulator biasing
passives and incorporate the PWM output for that with the PC program to set
the voltage out and then people (come on CUMP) need to start adding the code
to program other devices.

----- Original Message -----
From: Randy Glenn <KILLspampicxpertKILLspamspamyahoo.com>
To: <RemoveMEjamesnewtonTakeThisOuTspampiclist.com>
Sent: Monday, February 14, 2000 20:00
Subject: RE: [PICLIST] An Idea....


> Wouldn't PLL be less processor-intensive for the function generator? I
know, it requires
> extra hardware, but maybe an expansion port on the development board...
>
> Also, won't you be needing some external RAM for the logic analyzer and
oscilloscope?
>
> -Randy Glenn
> E-Mail: spamBeGonePICxpertspamBeGonespamyahoo.com
> Web: http://i.am/PICxpert
>
> Currently wondering why I can't get in to Safe Mode - where's a Mac when
you need it?
>
> {Original Message removed}

2000\02\15@043031 by Dr. Imre Bartfai

flavicon
face
hi,

it is possible, it is even very simple task. It can be done also with
PicBasic or with the stamp, or hopefully with the stamp/4.
Regards,
Imre


On Mon, 14 Feb 2000, Jonathan Philpott wrote:

{Quote hidden}

2000\02\15@043240 by Dr. Imre Bartfai

flavicon
face
Hi,

there is a ready-made application. It is called at us as Pic-Basic Port
Extender, and it is a pre-programmed PIC16C57, communicating with one pin
serial 2400 Baud. Costs $4 or so.

Regards,
Imre




On Mon, 14 Feb 2000, M. Adam Davis wrote:

{Quote hidden}

2000\02\15@080211 by Tom Handley

picon face
At 03:31 PM 2/14/00 -0800, James Newton wrote:
>Exactly! YES YES YES. See
>http://techref.massmind.org\idea\ebb.htm
>especially the last bullet point under "In the CUMP project"
>
>The upshot is that I think a $10 board consisting of a '877, MAX 232, Analog
>front end, PWM output filters and power regulators could provide the
>following:

[snip]

  Jim, if you are going to do such a board, I designed a simple 24-Bit
Trigger Comparator as part of a Logic Analyzer block that may be of use. The
following is a `snippet' from the docs:

  - Tom
---------------------------------------------------------------------------

  This is a 24-Bit Programmable Comparator with Bit-Enable qualifiers. It
uses an SPI-style serial interface to load the Bit-Enable qualifiers and the
Comparator data. This data is compared with the 24 Inputs to generate an
Equality Output. Inputs with their corresponding Bit-Enables cleared are
ignored. It also provides a Serial Data Output and an Enable Input to
support expansion. One application is a 24-Bit Trigger Comparator in a Logic
Analyzer.

  The design is implemented in a Lattice Semiconductor ispLSI1016E-100LJ
CPLD using a 44-pin PLCC package. The device features +5V
In-System-Programming. To program the device you need to download the free
ISP Daisy Chain Download software from Lattice Semiconductor at:

     http://www.latticesemi.com

  If you don't have the Lattice buffered ISP Download Cable, plans for
building one are at:

     http://www.teleport.com/~thandley/Wilbure.htm

Hardware Interface
==================

  Inputs:

     TC0 - TC23 = Comparator Inputs.
           SCLK = Serial Clock Input. Clocks on Rising Edge.
            SDI = Serial Data Input.
             EN = Enable Input for Expansion. High = Enabled.

  Outputs:

             EQ = Comparator Output. High = True.
            SDO = Serial Data Output for Expansion.

  From a software standpoint, you send 48 Bits (MSB-first). The first
24 Bits are the Bit-Enable Qualifiers. High = Enable. The next 24 Bits are
the Comparator Data.


------------------------------------------------------------------------
Tom Handley
New Age Communications
Since '75 before "New Age" and no one around here is waiting for UFOs ;-)

2000\02\15@105232 by jamesnewton

face picon face
Thanks Tom, I've added a link to this post. I think that this would be a
nice addition (like Randy Glenn's mention of external ram and PLLs) to a
more upscale version of the CUMP/EBB idea. I'd like to concentrate on the
base version for now, but I certainly see that one day our new PIC user will
have a project that needs a faster logic analyzer than the 1 or 2 MHz that
he can get with just the '877 and our programs, so he will look for an find
a way to add some external ram and your Trigger comparator.

---
James Newton TakeThisOuTjamesnewtonEraseMEspamspam_OUTgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\02\15@120917 by Dan Michaels

flavicon
face
Jim,

In response to your "An Idea" response, concerning "minimalist
engineering tools", I've done a number of the things you
mention using 20Mhz PIC16C73/74/76 chips. They make rather
nice simple 1-chip scope/logic_analyzer/generator instruments
- albeit a little slow.

The best "logic analyzer" rate I can get is 2.5Mhz using a 20Mhz
part. 1 instr to capture, 1 to store, using linear code and direct
addressing. You can't fill more than about 96+80=176 locations
without bank-fiddling, which adds some skew. The best rate I could
coax out of 1-bit sampling, which of course requires time to pack
8-bits to a byte, was 1 Mhz.

Also, regarding "signal generator via PWM", this works extremely well
on the 2nd gen PICs with the built-in PWM generator. Turns out all
period values and duty-cycles are available on these chips, so you are
not limited to just a few PWM rates (as on most microcontrollers??),
and you can actually get continuous pulse widths and rep-rates from
50ns @ 5Mhz, down to about 800us @ 1.2Khz. Since, it's done in h.w.,
there is no s.w. overhead or timing loop problems.

A while back, I wrote an Appnote about this, which spells it out in
detail:

"AN-ECD06 - Precision 50-nsec Pulse Generation Using a PIC16C63"

available at: http://www.sni.net/~oricom/appnotes.htm

- Dan Michaels
Oricom Technologies

==================

{Quote hidden}

..
>
>-----Original Message-----
>From: pic microcontroller discussion list
>[PICLISTEraseMEspam.....MITVMA.MIT.EDU]On Behalf Of Jonathan Philpott
>Sent: Monday, February 14, 2000 06:52
>To: EraseMEPICLISTspamMITVMA.MIT.EDU
>Subject: Re: An Idea....
>
..
>I was thinking of having a standard controlling
>program, that could use the idea to make a sort of
>"engineers mode" for debugging etc.
>

2000\02\15@121957 by jamesnewton

face picon face
May I have and post your scope/logic_analyzer/generator code on the PICList
projects page at
http://www.piclist.com/projects
you pick a name?

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


{Original Message removed}

2000\02\15@124420 by Wagner Lipnharski

picon face
[snip]
> The best "logic analyzer" rate I can get is 2.5Mhz using a 20Mhz
> part. 1 instr to capture, 1 to store, using linear code and direct
> addressing. You can't fill more than about 96+80=176 locations
> without bank-fiddling, which adds some skew. The best rate I could
> coax out of 1-bit sampling, which of course requires time to pack
> 8-bits to a byte, was 1 Mhz.
[snip]

hmmm... suppose you would use the PIC running at 20MHz, just to give
control and timing to the data capture... You don't need actually to use
the PIC to deserialize and store data...

You could use an external serial-parallel chip to do the serialization,
lets say at 20 mega-samples/second, a couple of 74HCT4040 would do the
secondary external RAM memory step up addressing during the data
capture, up to 24 bits addressing. The PIC would be used to setup this
stuff and then to read back and interface data out to a PC or something.

Using a software driven device to do a very fast operation is not the
best solution, when you can do it easily, faster and cheaper with few
external gates...  Using less than $10 you could boot up your logic
analyzer to 20 mega/samples/second, including 64k SRAM chips.  An extra
'4040 chip could be used divide the osc clock and to select the capture
sample rate (20, 10, 5, 2.5, 1.25... and son M/S/s)

The serialization chip is not necessary if you would use 8 input
channels.

2000\02\15@150603 by Dan Michaels

flavicon
face
Wagner,

I was responding to Jim Newton's query about what you can
do with a basic PIC chip - only 28-pins and 15 mA. I guess
this should be called "minimalist engineering tools".

You certainly can add more chips to do it all in hardware
- if you have the space. To your scheme, you also have to
add a few more chips for various triggering options, I/O bus
buffering, comm to the host, and for extending the timing up
to 50msec/sample. Also, to get std 1-2-5 time scaling takes
more than a 4040. Binary scaling starts out nice, but turns
to dung later on. 20mhz/4096 -> 204.8 usec, etc.

Actually, I do have the board you describe right here in
front of me - it's got 12 chips, 32K deep buffer, is 3" x 5",
and draws .5 Amp (albeit it does do 50Ms/s and the 74HCT4040
is replaced by four 74AC161s).
-------------

Back to the minimalist approach, for higher speeds, I am also
using a 60Mhz Scenix part to do 20Mhz 8-bit capture and 5Mhz
serialized capture - although the buffer *IS* limited to 128
bytes and 1024 bits. But only 28-pins and 60 mA. And different
trigger options are easily programmed in.

To give **some** credit to the minimalist approach, I have found
that once I have the basic h.w., it is extremely easy to get
stuck in s.w. featuritis mode - without having to re-design
the h.w. for every new feature. Gee (he said thinking out loud),
now I can use the LA pins for various logic OUT-putting, like
counting, static outputs, multi-phase/multi-pulse outputs,
simultaneous outputting with inputting, etc. The sky is the
limit. (If only the chips had more internal RAM).

- Dan Michaels
http://www.sni.net/~oricom
================

At 12:38 PM 02/15/2000 -0500, you wrote:
{Quote hidden}

2000\02\15@163521 by Dan Michaels

flavicon
face
Sorry the dates are coming up wrong on my messages, but
I called my ISP (ie, Qwest, the guys who are trying to
take over the telecom world), and they actually found the
problem in one of their mail servers - now if they can
just fix it.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom

2000\02\15@194125 by Thomas C. Sefranek

face picon face
Dan Michaels wrote:

> Sorry the dates are coming up wrong on my messages, but
> I called my ISP (ie, Qwest, the guys who are trying to
> take over the telecom world), and they actually found the
> problem in one of their mail servers - now if they can
> just fix it.
>
> - Dan Michaels
> Oricom Technologies
> http://www.sni.net/~oricom

Looks good now!
Great!

--
 *
 |  __O    Thomas C. Sefranek   RemoveMEtcsspam_OUTspamKILLspamcmcorp.com
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

2000\02\15@195618 by J Nagy

flavicon
face
Jonathan Philpott wrote:

{Quote hidden}

Jonathan:
       Check out our ELM621. It's based on a '508, and provides 3 I/O
lines in an 8 pin package. Communications is at 9600 8N1.
       For your example, it'll accept ATSp to set port bit 'p' on, or ATCp
to clear the pin, ATSA to set them all high, ATTA to toggle them all, etc.
etc. Quite a handy little thing.

       Jim Nagy
       Elm Electronics
 ICs for Experimenters
http://www.elmelectronics.com/

2000\02\16@114138 by Dan Michaels

flavicon
face
Jim,

In regards your query about:

>Do you think a single step program monitor could be implemented
>in an ISR?
>Could the '877 be a minimal ICD without the ICD?

I haven't looked at the ICD, as yet. Do you want to monitor internal
program operation (ie, by emulating the program in the '877), or just
monitor external pin signals, while single-stepping? Sounds like the
former. I haven't been going that route, but mostly building
"minimalist" h.w. debug tools using the PIC and Scenix - in my latest
device, the SX steps the clock of the target DUT, and monitors
external pins, until a trigger-point occurs.

The idea of using the '877 as a single-step, debug, 1-chip, cheapo ICE
sounds good, but I am not sure you can do it very easily. In the 8088,
for instance, they have a trap flag in the status reg that enables the
built-in (INT 1) single-step capability of the chip. This is what allows
you to run Debug.com and Codeview at the same time as executing a
target program. As far as I know, the PIC chips don't have this ability.
And since the PICs don't have s.w. interrupts, I am not sure an ISR
would help.

Myke Predko, who devised his minimalist EMU, might know more about
this stuff.
---------

In my own designs, I never use ICEs or simulators. Otherwise, I would
have a closet full of them. My preferred method is to first write a
basic monitor routine, accessible via RS-232, and which can display the
cpu registers, and read the external pins at high rates, and then I
write the app on top of that as small callable modules, rather than
a long chain of goto's. I then do "post-mortems" after running newly-
coded routines. This usually works quite well for rapid debugging.
(I realize this sounds very primitive to the ICE set).

Although I've never done it before, it just occurred to me that some-
thing even better would be to stick a < call reg_capture > statement at
strategic places in the code. It would save the reg values to a circular
buffer. Then you could do post-mortems on execution "inside" the
routines, rather than only at the end.

These methods work quite well in PICs that have multi-level stacks,
and more than minimal internal RAM.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom

=================
=================
[snip]
{Quote hidden}

2000\02\16@124432 by jamesnewton

face picon face
I was wondering if the ISR could be setup to allow only one instruction of
the main code to execute when the ISR returns. When the ISR regains the
processor after that instruction, it could read the registers (one of them
is the saved program counter, right? or wrong? I haven't worked with this,
maybe it can't be read) report that to the PC which could then match the PC
value against the code listing and display the listing with that line
highlighted along with the other register values, port pin states, etc.. and
buttons for single step, reset, etc..

The ISR would loop checking the RS232 port and could also be capturing port
pin signals, a2d results, etc.. and sending them to the PC which could
display them on the screen in virtual logical analyzers, o'scopes etc...

When the user presses the single step button, the single step command is
sent by the PC to PIC and the ISR returns for one more main code
instruction. If the user selected the Run button the ISR could still
interrupt the main code every so many cycles and report to the PC the
registers, ports, a2d etc... This would introduce a heck of a jitter in the
main program but it would be better than not having it at all.

If the user selected a register in the PC display the GUI would allow
editing and then send a request to the PIC ISR which would update the
register and continue looping.

That would facilitate the use of the device for writing / debugging code in
the PIC. This is the MONITOR mode.

The next step would be to translate and program that code into a target PIC
which would be connected to the main PIC for that purpose. Maybe a ZIF or
low cost socket on the main PIC's PCB. Maybe an optional daughter board that
routes the main PIC pins and high voltage signals to the correct pins for
the target using the main PCB socket or with a socket on the daughter board
for other types of packages. Each low cost daughter card could (not must)
have the target device ID and/or programming instructions for the main PIC
in a serial EEPROM. Daughter cards could have stacking connectors to allow
other cards to be connected at the same time.

In this programming mode, the main PIC would regulate the high voltage power
and stimulate the target PIC according to a programming procedure developed
for the target device. This is the CUMP mode.

Finally, the main PIC could be used to debug and test the target device by
stimulation and monitoring while the target is still attached.

If the user requested that the function or signal generator do something,
the PC would send the request to the PIC and the main code would do that,
while looping for the RS232 port and recording and/or reporting signals for
the virtual logic probe or analyzer and o'scope on the PC screen. This would
be used to stimulate a connected device, not to generate signals for the PIC
itself and yes, that would have to be some very tight code to get good
results. Probably the PWM out would help with the signal generator and some
jitter in the function generator may have to be accepted at the higher
speeds of operation if the input virtual devices needed to be used at the
same time. This is the EBB (Electronic Bench in a Box) mode.

Optional extensions are without limit. Starting from a low cost, easy base,
the unit could be cheaply extended to add external high speed RAM signal
capture and generation, high impedance analog front ends and back ends, user
interfaces to replace the PC GUI. If the daughter card interface is done
correctly, these additions would be as easy as plugging in a new card with
the code for the main processor to use it right on the daughter cards own
EEPROM.

And before anyone starts talking about replacing the main processor with a
higher power, faster, more ram having, kickinger buttinger, other chip let
me point out that the bitscope is run via a what? 16F84? and that no other
uController support base has a better hope of actually doing it than the
PICList. You people RULE! The combined force of the PICList membership can
accomplish just about anything. Ummm... just one thing... somebody has to
start, and I don't have the time. I do the site and part of the admin and
that's too much as it is.

---
James Newton EraseMEjamesnewtonspamspamspamBeGonegeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\02\16@171333 by Tony Nixon

flavicon
picon face
James Newton wrote:
>
> I was wondering if the ISR could be setup to allow only one instruction of
> the main code to execute when the ISR returns.

This works, but sacrifices TMR0, and I'm not sure how it would perform
in all code situations.

         org 0h

         goto start

         org 4h

IRQ       bcf intcon,t0if

         ; process anything here

         clrf tmr0
         decf tmr0
         nop
         retfie

start     bsf status,rp0
         movlw b'11000000'
         movwf opton
         bcf status,rp0

         movlw b'00100000'
         movwf intcon
         clrf tmr0
         decf tmr0
         goto $ + 1
         bsf intcon,gie

SingleStep movlw 0x00
          movlw 0x01
          goto $ + 1
          movlw 0x02
          goto $ + 1
          movlw 0x03
          movlw 0x04
          movlw 0x05
          goto SingleStep


--
Best regards

Tony

http://www.picnpoke.com
RemoveMEsalesKILLspamspampicnpoke.com

2000\02\17@105906 by Dan Michaels

flavicon
face
Tony Nixon wrote:
>>
>>James Newton wrote:
>>
>> I was wondering if the ISR could be setup to allow only one
>>instruction of the main code to execute when the ISR returns.
[snip]
{Quote hidden}

...

Tony,

Your code idea looks interesting, but don't you need something like
b'11000001' (prescale TMR0 by 4) in the option register to make the
INT occur at the right time on return? Unfortunately this method
commandeers the most critical resource in the PIC - namely TMR0, but
might be worth playing with. It does clearly show how much overhead
is required to implement debug - 1 for execution, 10-to-20-to-50 for
overhead.
===============

James,

Your questions are answered. No need for fancy work-arounds. I looked
at the specs for the '87x chips, and Microchip saw the light and finally
implemented what I described yesterday was present in the 8088s since
birth - built-in debug mode.

The info is sketchy, but you set a bit in the config reg during program-
ming (like the trap flag on the 8088), load a Microchip-supplied module
in the last 100h bytes of code space (like the INT 1 ISR on the 8088),
and use RB6,7 for control (got to talk to it somehow).

When I built my own PIC Monitor chips, I specifically did not add any
Go/Step/Disassemble/etc commands like 8051 & other monitors use, simply
because the others can use external program ROM/RAM while the PIC cannot.
So instead, I built into the command set many of the other features
you've been describing the past couple of days - o'scope, logic analyzer,
reg/port read/write, PWM, generator, and pulse counter modes - and billed
it as a "1-Chip TestBench", useful for testing target hardware (external
to the cpu) before/while the firmware is being written.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom

2000\02\17@125502 by jamesnewton

face picon face
Dan, What's the Microchip supplied module? you mean code? is source
available? can you decompile it if not?

Debug overhead really doesn't matter as most time is spent waiting for the
wetware to cycle.

Nice unit (1-chip testbench) you have there! Lots of function for little
price. Now, if you can just add device programming, bootloader (have to go
open source for that don't you?), monitor, debug, and improve your user
interface software.... What do you sell the bare board for?

Tony, That is really interesting code. Correct me if I'm wrong but the ISR
can't see what the PC was before the interrupt can it? Can you read the
stack? Scenix has a shadow register that stores the w, PC and something on a
int IIRC. Reduces interrupt latency? Does the '877 have such a thing?
Undocumented?

---
James Newton jamesnewtonSTOPspamspamspam_OUTgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\02\17@150120 by Dan Michaels

flavicon
face
Jim,

In answer to your question, Microchip just calls it "In-Circuit
Debug module available from Microchip" in their spec. Roughly 100h
worth of '87x code that loads at the top of code space and is
accessed by the ICD. Details at Microchip.

Re your question to Tony, on other PICs, the stack/TOS is not
available, as far as I know. It may be on the '87x, at least
when the debug bit is set. On the Scenix, shadow regs don't appear
to be available either, but the whole context (W, status, PC) is
stored in shadow automatically.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom
============
============

At 09:50 AM 2/17/00 -0800, you wrote:
{Quote hidden}

2000\02\17@164455 by Tony Nixon

flavicon
picon face
> Tony, That is really interesting code. Correct me if I'm wrong but the ISR
> can't see what the PC was before the interrupt can it? Can you read the
> stack? Scenix has a shadow register that stores the w, PC and something on a
> int IIRC. Reduces interrupt latency? Does the '877 have such a thing?
> Undocumented?

I doubt that the code can do anything useful except load and read RAM
registers inside the ISR.

As far as I know the F series do not have auto context save and stack
manipulation, although 'I think' the 18C series do???

--
Best regards

Tony

http://www.picnpoke.com
KILLspamsalesspamBeGonespampicnpoke.com

2000\02\17@170124 by Scott Dattalo

face
flavicon
face
On Fri, 18 Feb 2000, Tony Nixon wrote:

> As far as I know the F series do not have auto context save and stack
> manipulation, although 'I think' the 18C series do???

You think correctly. In fact, there are two stacks. There's the one we're
all familiar with that saves the return address following a call and
there's the 'fast stack' that can save the status, W, and bsr (bank
select) registers in a single cycle. The 'normal stack' is 32 words deep
and you have access to it via some special function registers.
Additionally, there are push and pop instructions for placing moving data
onto and off of the stack. The 'fast stack' is only one level deep and is
useful for saving the cpu context through interrupts.

You could also argue that there are three more stacks available with the
indirect addressing modules. These would be useful for implementing a data
stack for passing parameter to subroutines. (The call stack could be used
for this, but it's much more difficult to read and write data to it).


This little monitor thingy you guys have been discussing could be
implemented quite easily in the 18cxxx. I'm not sure if there's a config
parameter for trapping single cycle executions, but you could modify the
program memory to achieve the same behavior (e.g. by writing:
  bra  monitor
immediately after the next instruction (s) that supposed to be executed).


Scott

2000\02\17@172828 by Tony Nixon

flavicon
picon face
Scott Dattalo wrote:

> You think correctly. In fact, there are two stacks. There's the one we're
> all familiar with that saves the return address following a call and

I wonder why Microchip made these devices in C series and not Flash
based. It seems they would be a much more versatile chip, especially if
they implement ROM changes under code protection.

Much cheaper than worrying about unerasable JW types too.

--
Best regards

Tony

http://www.picnpoke.com
EraseMEsalesspamEraseMEpicnpoke.com

2000\02\17@174256 by Scott Dattalo

face
flavicon
face
On Fri, 18 Feb 2000, Tony Nixon wrote:

> Scott Dattalo wrote:
>
> > You think correctly. In fact, there are two stacks. There's the one we're
> > all familiar with that saves the return address following a call and
>
> I wonder why Microchip made these devices in C series and not Flash
> based. It seems they would be a much more versatile chip, especially if
> they implement ROM changes under code protection.
>
> Much cheaper than worrying about unerasable JW types too.

AFAIK, they ARE flashable (well, at least they are in gpsim :). The C is
there just to through you for a loop.

Take a look at the Table read and write section in the data sheet. It
discusses all the details (no more 55/AA business).

Scott

2000\02\18@135050 by Dan Michaels

flavicon
face
>
>This little monitor thingy you guys have been discussing could be
>implemented quite easily in the 18cxxx. I'm not sure if there's a config
>parameter for trapping single cycle executions, but you could modify the
>program memory to achieve the same behavior (e.g. by writing:
>   bra  monitor
>immediately after the next instruction (s) that supposed to be executed).
>
>Scott
>

Scott,

Great, another new PIC chip (that doesn't seem to be widely available)
to look at. However, eventually, Jim's problem of having one chip to
do it all can be solved. I looked at the memory map on the 8Cxxx and,
compared to current PICs, it's like going from an 8088 to an 80486,
and would probably have all the same nightmares involved with trying
to backward emulate a segmented (ie, banked/paged) architecture on a
linear one.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom

2000\02\18@142850 by Scott Dattalo

face
flavicon
face
On Fri, 18 Feb 2000, Dan Michaels wrote:

> >
> >This little monitor thingy you guys have been discussing could be
> >implemented quite easily in the 18cxxx. I'm not sure if there's a config
> >parameter for trapping single cycle executions, but you could modify the
> >program memory to achieve the same behavior (e.g. by writing:
> >   bra  monitor
> >immediately after the next instruction (s) that supposed to be executed).
> >
> >Scott
> >
>
> Scott,
>
> Great, another new PIC chip (that doesn't seem to be widely available)

True. They were supposed to be shipping before the end of the last
century.


> to look at. However, eventually, Jim's problem of having one chip to
> do it all can be solved. I looked at the memory map on the 8Cxxx and,
> compared to current PICs, it's like going from an 8088 to an 80486,
> and would probably have all the same nightmares involved with trying
> to backward emulate a segmented (ie, banked/paged) architecture on a
> linear one.

Not completely true. I'd say the analogy is more like this: 17c4x family
is to the 16cxx family what the 80286 was to the 8086; the 18cxxx is
analogous to an 80386 running in real mode. The 18cxxx is advertised to be
source code compatible with a 16cxx device - even the pin-outs are the
same (on the same sized devices, of course). Source code compatible means
that you only need to tell your assembler to targe an 18cxxx instead of a
16cxx part. In other words, they're not object code compatible. (The 80386
in real mode IS object code compatible with the 8086; so the analogy is
not perfect). The source code compatibility is not 100%. The examples that
come to mind are the rotate instructions (rrf/rlf) and the
increment/decrement instructions. On the 16cxx parts, the rotate
instructions don't affect Z, while on the 18cxxx parts they do. Similary,
INCF and DECF on the 16cxx parts don't affect C and DC, while on the
18cxxx parts they do (the incfsz and decfsz instructions behave the same).

There other 'minor', but important variations too. For example, some of
the mnemonics have changed names. The CALL in an 18cxxx device is two
words. The 18cxxx RCALL is one word, however it's a relative call. On the
16cxxx parts, CALL is one word and is absolute. Some code may depend on
this absolute behavior by playing tricks with the banking. A similar
difference exists for the GOTO instruction. On the 18cxxx this two words;
the one-word version is called BRA and is a relative branch.

The 32-word stack could be the source of an obscure bug as well. On the
16cxx devices you only have an 8-word stack. You might have code that
depends on this behavior. For example, the recent task switching thread
discussed 'stack stuffing' for a means of saving two cycles by avoiding
unneccessary CALLs. So stack rollovers were taken advantage of (you could
do the same on the 18cxxx parts, but you'd have to modify the code - i.e.
you're not source level compatible).

It's true that the banking paradigm is largely different. However, if you
use the Microchip supplied macros for bank switching, then you oughta be
covered.


Scott

2000\02\18@155825 by Dan Michaels

flavicon
face
>
>Not completely true. I'd say the analogy is more like this: 17c4x family
...
>There other 'minor', but important variations too. For example, some of
...
>The 32-word stack could be the source of an obscure bug as well. On the
...
>unneccessary CALLs. So stack rollovers were taken advantage of (you could
>do the same on the 18cxxx parts, but you'd have to modify the code - i.e.
>you're not source level compatible).
>
>It's true that the banking paradigm is largely different. However, if you
...
>Scott
>

Well, Jim, after hearing Scott's description of the 18Cxxx, do you still
want to go ahead with your "minimalist" PIC emulator/monitor/testbench?
(minimalist only in the sense of requiring a single chip - NOT in how
many man-years it would take to write it :>).

Also, sounds like your emulator would probably DIE trying to emulate some
of my code, where I actually use the stack rollover feature of the PIC to
break out of occasionally-infinite loops I've planted in my code in places
where every cycle has to be counted.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom

2000\02\18@162803 by jamesnewton

face picon face
No, unless someone else has a good reason to stick to the 16F87x, I would
focus on the latest and greatest.

Especially if the 16C's:
1. are still flash low voltage programmable
2. have all the same or better io hardware (a2d, TMR, PWM, lots a pins,
etc...)
3. allow access to the PC off the top of the stack (there is the monitor,
single step etc...)
4. support some type of breakpoint register like the 16F87x obviously must
for the ICD to work.
5. isn't horribly expensive or impossible to get in low quantities.

Um... I still don't think you've read what I'm suggesting with much care...
Please see:
http://techref.massmind.org/idea/ebb
I have no desire to emulated anything. Emulators are only slightly less evil
than simulators.
http://techref.massmind.org/spicegotcha
I want
1. ICD without the ICD module (you build the RS232 cable) for testing code
and ideas on the main chip,
2. a device programmer for the real (low cost for production) target,
3. and a minimal test bench to stimulate and test the final project, and I
want it for $10 if you scavenge parts (pull some passives from old TV's,
order some free samples. etc) and sweat or $50 as a kit or $100
pre-assembled in a case.

---
James Newton @spam@jamesnewton@spam@spamspam_OUTgeocities.com 1-619-652-0593
http://techref.massmind.org NEW! FINALLY A REAL NAME!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)


{Original Message removed}

2000\02\18@213550 by Dan Michaels

flavicon
face
At 01:25 PM 2/18/00 -0800, you wrote:
>
>Um... I still don't think you've read what I'm suggesting with much care...
>Please see:
>http://techref.massmind.org/idea/ebb
>I have no desire to emulated anything. Emulators are only slightly less evil
>than simulators.
>http://techref.massmind.org/spicegotcha
[snip]
..
>James Newton spamBeGonejamesnewtonspamKILLspamgeocities.com 1-619-652-0593
>http://techref.massmind.org NEW! FINALLY A REAL NAME!
>Members can add private/public comments/pages ($0 TANSTAAFL web hosting)
>

Sorry Jim, I've guess I've been using "emulate" in the wrong places.
I looked at the ...... page, and he calls his device an "ICD emulator",
and now realize I've been doing the same thing.

What you want is a debug monitor - like those available on the 8051 and
other chips that use external program space, but which will work with
the internal program space of the PIC - and upon which you can assemble
and overlay a program, which you can then run, single-step, and debug
interactively, using an RS-232 port to access the underlying monitor.
(please god, let me have formed this complex run-on sentence correctly!}.

Thus, the monitor has to be open source, since it has to be assembled
along with the target program. At least until the day Microchip comes
up with an object code linker.

At least we agree on the use of emulators and simulators. I think the
time it takes to use them is better spent on other matters.

Also, thanks for the citations on the ebb page. Your desire to make
the entire ebb project open source and buildable cheaply is admirable.
Could be the GNU/Linux of the PIC world.

- Dan Michaels
Oricom Technologies
http://www.sni.net/~oricom

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