Hi everyone,

This is my first post on opencores, and first attempt at posting a VHDL core,
so please bear with me if I'm out of line here :) I would like to post my first
version of the Sony IRCS protocol core (their remote-control infra-red
protocol), but I just had a question about the interface. The core takes an
infra-red bit-stream from any sony-remote and decodes it into device and command
codes. These two codes (7 bit and 8 bit) are currently parallel outputs. I was
thinking of the following simple interface:

- when valid data is received, raise an interrupt pin.
- Data bus (both cmd and dev. registers) are constantly updated
- When user wishes to strobe data, assert an ack signal that clears the interrupt.

Essentially, it is up to the user to respond as fast as they wish - the data
will constantly be updated even if the interrupt isn't serviced.

Anyway, i just wanted to see if this group of signals (ACK, INT, Device register
and Command register) is a decent starting point before implementing a more
complex interface.

Any feedback is appreciated!

Jai


----------------------------------------
This mail sent through www.mywaterloo.ca

Jai Dhar wrote:



15 bits of parallel output could be inconvenient to low-end micros (with
8-bit data bus). You'd have to decode 2 separate addresses or use two
GPIO ports (micro-controller).

You may wish to consider an 8-bit wide FIFO to store a couple of
device/command pairs (serially) whilst the host is too busy to process
and/or has a high interrupt latency. This could be useful if interfacing
to a small micro that disables interrupts for a while when it's doing
something else.



Are you contemplating an edge or level interrupt signal? I suspect level
is easier to implement (eg. tie to FIFO not empty). Don't know whether
you want to bother considering (host) interrupt sharing issues?!?

Without a FIFO simply reading the register (RD strobe) could clear the
interrupt. With a FIFO you could use the FIFO empty to control the
interrupt line. I'd also consider having an interrupt enable/disable as
well.

Depends on whether or not a missed command is important. Using a FIFO could cause a lot less headaches for low-end host processors... Regards, -- Mark McDougall, Software Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Thanks for your tips Mark, I have replied below. Quoting Mark McDougall markm at vl.com.au>:

So providing CLK+Data may be better I take it?



Are you contemplating an edge or level interrupt signal? I suspect level
is easier to implement (eg. tie to FIFO not empty). Don't know whether
you want to bother considering (host) interrupt sharing issues?!?

Without a FIFO simply reading the register (RD strobe) could clear the
interrupt. With a FIFO you could use the FIFO empty to control the
interrupt line. I'd also consider having an interrupt enable/disable as
well.