Post by thread:An Idea....

part 0 2778 bytes 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 -- Yes.  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).  A bigger PIC or a shift register could be used to increase the number of lines available.  But why stop there?  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.  It's all pretty straightforward.  Did you have an application in mind? Mike __________________________________________________ Do You Yahoo!? No. </UL> </BODY> </HTML> </x-html>

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}> De: Dave VanHorn <spam_OUTdvanhornTakeThisOuTCEDAR.NET> > Para: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU > Assunto: Re: An Idea.... > Data: Segunda-feira, 14 de Fevereiro de 2000 09:31 > > > > 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

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 <mrjonesKILLspamNORTELNETWORKS.COM> wrote: {Quote hidden}> > > 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 > > -- > > > Yes. 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). A bigger PIC or a shift register could > be used to increase the > number of lines available. But why stop there? 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. It's all pretty > straightforward. Did you > have an application in mind? > > Mike > > > > __________________________________________________ > > Do You Yahoo!? > > > No. > > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

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}> > 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

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}>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 Erik Reikes Software Engineer Xsilogy, Inc. .....ereikesKILLspam.....xsilogy.com ph : (858) 535-5113 fax : (858) 535-5163 cell : (858) 663-1206

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}> > 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

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 jamesnewtonspam_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}

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 <KILLspampicxpertKILLspamyahoo.com> To: <RemoveMEjamesnewtonTakeThisOuTpiclist.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: spamBeGonePICxpertspamBeGoneyahoo.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}

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}> 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 > >

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}> 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: > > > > 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 > >

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 ;-)

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}>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)? > >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 > >James Newton RemoveMEjamesnewtonTakeThisOuTgeocities.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----- >From: pic microcontroller discussion list >[PICLISTEraseME.....MITVMA.MIT.EDU]On Behalf Of Jonathan Philpott >Sent: Monday, February 14, 2000 06:52 >To: EraseMEPICLISTMITVMA.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. >

[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.

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}>[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. > >

Jonathan Philpott wrote: {Quote hidden}>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? > 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/

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}> >Do you think a single step program monitor could be implemented in an ISR? >Could the '877 be a minimal ICD without the ICD? > >Would you or your company be interested in pulling the pieces together and >making the board and / or PC software? > >James Newton, PICList Admin #3 >RemoveMEjamesnewtonTakeThisOuTspampiclist.com >1-619-652-0593 phone >http://www.piclist.com >

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 EraseMEjamesnewtonspamspamBeGonegeocities.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}

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}> >IRQ bcf intcon,t0if > ; process anything here > clrf tmr0 > decf tmr0 > nop > retfie > >start bsf status,rp0 > movlw b'11000000' > movwf opton ... 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

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 jamesnewtonSTOPspamspam_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}

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}>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 spamBeGonejamesnewtonSTOPspamEraseMEgeocities.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) >

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

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

> >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

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@spam_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}

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 spamBeGonejamesnewtonKILLspamgeocities.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