gnupic: Thread: Re: PIC Emulator...

Matt wrote:
>  I have been inspired (thanks Ray) to employ my C/C++ skills in
writing
>  an emulator to tie the new pinout stimulator to the parallel port...
> this would be excellent for creating a really really easy ICE... you
> couldn't get simpler than putting wires on connectors, on your working

> hardware (excluding PIC)..

I'd just the same idea when I saw the stimulus capabilties in gpsim.
But we'll need external hardware for the port to get more than 8 outputs

and 4 inputs, at least if a port is bidirectional we'll need a tristate
buffer.

Does anybody know a PLD which can be programmed in system, (EEPROM- |
FLASH-able)
to have the possibility to reconfigure the PORT-Layout. Using a PIC16x84
directly would be
to slow, because there is the communication with the host.

(What to do with the AD-conversion of 16C71, using the Soundblaster ?)

Regards Axel

Xilinx XC9532 (available from Digikey for $5.00 in 44 PLCC) it just the
ticket. Abel programming s/w is free. At worst 2 ea 74hc125s
and some resistors makes the pport flash programmer (documented
on Xilinx site) and then the dongle is 'in place dynamically'
reprogrammeble,
has enough I/Os to talk to pport AND behave like a PIC on a date with
a Scenix.
I had planned to do something like this but graduated from PIC to
AVR (with $200 ICE :<} ) But have fun!!!

R.Martin

Axel Wachtler wrote:

> Matt wrote:
> >  I have been inspired (thanks Ray) to employ my C/C++ skills in
> writing
> >  an emulator to tie the new pinout stimulator to the parallel port...
> > this would be excellent for creating a really really easy ICE... you
> > couldn't get simpler than putting wires on connectors, on your working
>
> > hardware (excluding PIC)..
>
> I'd just the same idea when I saw the stimulus capabilties in gpsim.
> But we'll need external hardware for the port to get more than 8 outputs
>
> and 4 inputs, at least if a port is bidirectional we'll need a tristate
> buffer.
>
> Does anybody know a PLD which can be programmed in system, (EEPROM- |
> FLASH-able)
> to have the possibility to reconfigure the PORT-Layout. Using a PIC16x84
> directly would be
> to slow, because there is the communication with the host.
>
> (What to do with the AD-conversion of 16C71, using the Soundblaster ?)
>
> Regards Axel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Wed, 1 Mar 2000, Axel Wachtler wrote:

> Matt wrote:
> >  I have been inspired (thanks Ray) to employ my C/C++ skills in
> writing
> >  an emulator to tie the new pinout stimulator to the parallel port...
> > this would be excellent for creating a really really easy ICE... you
> > couldn't get simpler than putting wires on connectors, on your working
> 
> > hardware (excluding PIC)..
> 
> I'd just the same idea when I saw the stimulus capabilties in gpsim.
> But we'll need external hardware for the port to get more than 8 outputs
> 
> and 4 inputs, at least if a port is bidirectional we'll need a tristate
> buffer.
> 
> Does anybody know a PLD which can be programmed in system, (EEPROM- |
> FLASH-able)
> to have the possibility to reconfigure the PORT-Layout. Using a PIC16x84
> directly would be
> to slow, because there is the communication with the host.
> 
> (What to do with the AD-conversion of 16C71, using the Soundblaster ?)


About a year ago we had similar discussions for gpsim (that is, extending
the parallel port out to real-world devices). In it's simplest form, I
think creating a gpsim module that interfaces between the simulator and
the parallel port would be a wonderful idea and not too hard to implement.
gpsim has all of the infrastructure in place to support stimuli (though as
some of you know, it's really rough around the edges). The 'module'
approach discussed a few weeks back would provide a convenient way to tap
into this infrastructure. gpsim has now become mature enough to begin
tackling these ambitious goals.

Axel's allusion to the Soundblaster interface is not too far fetched. Any
device that's available to your PC could be mapped to a gpsim module.
Keyboard LED's could serve as indicators or the serial port could be
mapped to a PIC uart.

The hard part will becoming up with a design that's fast, flexible. At
first, I had wanted to use the LCD display as a template for designing the
modular interface. However, emulating an LCD display requires a
significant amount of coding. So I'm backing off of that. I think a more
reasonable approach would be to implement an LED and a switch - these are
binary devices that are very simple to emulate, but would require the full
modular interface to abstractly connect to gpsim.

Nothing's cast in concrete right now. So I'm definitely open to ideas and
suggestions. 


Where things stand:
------------------

The things that I'm planning for gpsim right now are completion of the
16f87x devices. Version 0.18.2 (in cvs) supports program memory and data
memory flash reads and writes. I'm now working on the A/D converter and
after that I was planning on porting the 18cxxx's USART to the 14bit
family. Version 0.19.0 will be released after these are done, but I'll
make minor releases along the way for those interested in experimenting
with 16f877. 

The module interface development can begin now and co-developed along with
the 16f877. I'll certainly apply patches and provide any support. (But
I'll stay focused on the 'f877 until it's done).

Scott

Nathan wrote:

> I dunno if it'd be fast enough, but the Phillips PCF8574 has 8 bits of
> I/O with an i2c interface. which a number of folks have done over the
> parallel port.

I4ve ust viewed with my scope at David Taits PP (16c84 with AN587 and
PPDELAY=0, Celeron 400 Laptop),
there is a maximum clock period of 15 mus.
As for iic I remember that there was START,ADRESS,(MAYBECONTROL),DATA,STOP,
in fact approx.
20 cycles (without control), with this 15 mus approach we need 0.3 ms for a
byte to adjust.
This seems to reach for low speed apps. Also we would need some additional
glue logic to multiplex
the devices.

Maybe we can also use a PIC as parallel-2-iic converter to speed up the
transfer rate.

It should be possible to build up the gpemu (?) without having access to any
other programming hardware.


The idea from Richard with the xilinx xc9536 sounds also not bad.
Has anybody experience with the tools under Linux.

Regards Axel

Glad I could stimulate some discussion; funny though, how what seems
trivial to me (having not thought in depth about the problem) is now
generating idea's that go way over my head - for the moment.
	I only realised last night, even if we could gain control of the
parallel ports pins, and force them bi-directional, we still 10-15 pins
short on the 40pin devices.

Oops, i take back the statement... 'can't get easier than tying wires to
your port and hardware connectors' - there has to be something in the
middle..like the XC9532.

can we start with trying to get a, maybe an 18 pin 16c71 going.

and a theory, and just a theory, on pins. Could we solve it with
something less H/W orientated by using a PIC16F84/C84 to read control
words from a gpsim module, that knows how to drive the emulating pins.
or we could use a 16c74, for the extra I/o and even contemplate driving
the A/D ports. perhaps i'm dreaming without thinking again..
As for the control words, we make them generic, like put pin 5 high,
regardless of what pin 5 is. this way we don't need to allow for
different processors, the decision on what pins should be available is
left to the gpemu module. This also removes the nesseccity for a
re-programmable emulator control device. 

This is my thoughts, pick them to pieces.

matt

####@####.#### wrote:
> 
> Matt wrote:
> 
> ...
> >       I only realised last night, even if we could gain control of the
> >  parallel ports pins, and force them bi-directional, we still 10-15 pins
> >  short on the 40pin devices.
> >
> 
> also nobody will be happy if the port of the expensive new PC is burned by
> shortcut in hardware your trying to emulate.
> 
> Even we need some additional pins for interfacing to the PC.
> 
> >  ...... - there has to be something in the
> >  middle..like the XC9532.
> >  can we start with trying to get a, maybe an 18 pin 16c71 going.
> 
> yes.
> 
> >  and a theory, and just a theory, on pins.
> 
> see for instance PIC16F8X manual, page 21 ...23. If we want to emulate
> we should meet at least the raw specification.
> 
Naturally..


> >  Could we solve it with
> >  something less H/W orientated by using a PIC16F84/C84 to read control
> >  words from a gpsim module, that knows how to drive the emulating pins.
> >  or we could use a 16c74, for the extra I/o and even contemplate driving
> >  the A/D ports. perhaps i'm dreaming without thinking again..
> >  As for the control words, we make them generic, like put pin 5 high,
> >  regardless of what pin 5 is. this way we don't need to allow for
> >  different processors, the decision on what pins should be available is
> >  left to the gpemu module. This also removes the nesseccity for a
> >  re-programmable emulator control device.
> >
> 
> The instantiation of the hardware is another thing, your right we need
> an easy and fast control protocol.
> 
> Cause we have to simulate outputs AND inputs (as well as the MCLR-Pin)
> we should reuse the PIC approach with the TRIS and PORT register.
Explain.. I'm a bit lost on that little bit..

> The control language should also implement the PIC instructions for
> writing/reading a whole port-register complete as well as setting/testing
> single pins.
> 
> For this we should start with emulating one PORT using maybe a PIC as interface
> hardware.

That is a good idea... 
I am all for modularity, reusability (other engineer by-words, blah
blah) so perhaps we could make something that is easily multiplied to do
the whole PIC, but in steps. Such as we get a port going, so make 3 or 5
ports. Get a pin to do A/D, make all channels available. get serial
going, maybe the PSP on some of the 40 pin chips.

> 
> >  This is my thoughts, pick them to pieces.
> 
> ... Done
> 
> Bye Axel

Good