Newsgroups: comp.sys.transputer
From: peteric@creda.isltd.insignia.com (Peter Ivimey-Cook)
Subject: Re: CHAN vs. PORT
Organization: Insignia Solutions Ltd
Date: Sun, 6 Nov 1994 19:33:56 GMT
Message-ID: <Cyv2CL.A4n@isltd.insignia.com>

Oyvind Teig (teig@autro1.UUCP) wrote:
: OCCAM CHAN vs. PORT

: Questions below concern memory mapped I/O only:
: Q1.  CHAN and PORT - What is the difference?
: Q2.  Which do I use if I want to access memory mapped I/O?
: Q3.  Which do I use if I later on want to make a simulator for the I/O?
: Q4.  How do I access memory mapped registers on a UART?

: I think the answers are like this, please correct:
: A1?  PORT/CHAN     OF BYTE
:      PORT/CHAN     OF [16]BYTE
:      [16]PORT/CHAN OF BYTE
:      No PORT OF protocol
:      Both may be PLACEd at a memory address
:      PORT is bidirectional
: A2?  CHAN OR PORT, either one
: A3?  Not PORT because occonf gives a warning that a PORT should be PLACEd
: A4?  CHAN/PORT     OF [16]BYTE   ??
:      [16]CHAN/PORT OF BYTE       ??
:      A PORT is bidirectional, ok, but not 'simulator-friendly'
:      If I use CHAN, do I have to make one declaration for I and one for O?


Q1.  CHAN and PORT - What is the difference?

	CHAN specifies a communications channel.  Something which
	connects two software processes together to enable them to talk.

	PORT specifies a memory location where (typically) a piece of
	hardware has been mapped.  Thus you are linking a software
	process with a hardware one.

	Note that CHAN's may be multiplexed (e.g.  by software routers,
	C101 hardware routers etc) in ways not visible in the OCCAM
	source.  Assumptions about what you can do with CHAN not
	otherwise specifed in the OCCAM manuals are very dangerous.

	PORT access is dependent upon the hardware of the card being
	used.


Q2.  Which do I use if I want to access memory mapped I/O?

	You *must* use PORT. See above.


Q3.  Which do I use if I later on want to make a simulator for the I/O?

	It depends upon the simulator.  I would suggest that you encapsulate
	accesses to real hardware with a process, so:

                ---------               ---------               ---------
                process 1  ----CHAN-->  HW server  ----PORT-->  'real' HW
                ---------               ---------               ---------
	
	This is a _good thing_ even if you don't intend to change the
	way the system works - but if you wish to simulate the hardware,
	you replace the 'HW Server' with a 'HW Sim' process which
	simulates the effect of 'HW Server --> real HW' on the external
	system - i.e you don't need to simulate the hardware, just the
	interface the hardware presents to 'process 1'.  So:

                ---------               ------------
                process 1  ----CHAN-->  HW simulator
                ---------               ------------


Q4.  How do I access memory mapped registers on a UART?

	Given the documentation which defines typically the offsets of
	the UART registers from base, and (for your hardware) the base
	address, you PLACE appropriately defined PORTS at the hardware
	addresses, then write (assign) or read (use) the placed
	variables.  e.g.  given an 8 bit write-only control reg at
	offset 0, a read-only status reg also at offset 0 and a r/w 8
	bit data reg at offset 4:

	VAL base.address IS #100:	-- use your H/W address here
	PORT OF BYTE control:
	PORT OF BYTE data:
	PORT OF BYTE status:
	PLACE control.reg AT base.address + 0:
	PLACE status.reg AT base.address + 0:
	PLACE data.reg AT base.address + 4:
	BYTE control.shadow:
	SEQ
	  -- set up control, e.g. to set baud rate
	  control.shadow := #34(BYTE)	-- use shadow so you can find out
					-- what 'control' contains later.
	  control.reg := control.shadow

	  -- write 'A' to 'Z' to UART data reg.
	  SEQ i = 32 FOR 26
	    SEQ
	      -- write byte to UART data register
	      data.reg ! (BYTE)i

	      {{{ wait for ack signal from UART status reg bit 7
	      BYTE status:
	      SEQ
		status := 0
		WHILE ((status /\ #80) == 0)
		  SEQ
		    status.reg ? status
		    -- probably be good to wait a bit here rather than
		    -- busy wait.
	      }}}
	
Hope this helps.


Regards,

Peter

--

---------------------------------------------------------------------------
Peter Ivimey-Cook                       Mail Id: peteric@isltd.insignia.com
---------------------------------------------------------------------------
Std.Disclaimer:                          My own opinions, not my employers.


