Helios C- and timing-question...

Helios C- and timing-question...

Post by Erik Baiga » Thu, 18 Aug 2005 01:24:31


Hi transputer *** s,

for a electronics project I need to generate a
timing on 20-30 bits and read digital inputs
simultaneously. Therefor the plan is to attach
busdrivers (74F374 latches for output and
74F244 drivers for input) with glue (GALs for
address decoding and strobe generation) to a
transputer board carrying a T800 and running
helios 1.31.

The code I want to run (e.g. generating a strobe
and than reading data in this simple example) looks
like this:

for (i=0 ; i<7 ; i++ ) {
printf ("%d(0x%p): ",i,OutPort);
*OutPort= 4096+i;
*OutPort=16384+4096+i;
*OutPort= 4096+i;
data=*OutPort;
*OutPort= 0;
printf ("%d\n",data);
}

Here I have got TWO Questions:

(1) Is there a possibility in helios to prevent
the OS from switching to another task for a
certain amount of time? E.g. inline assembler
inhibiting all interrupts on the T800
would be fine - does anyone out there
know the syntax thereof?
(2) There is a sleep function for sleeping several
seconds implemented in helios' c compiler. I
was not able to find a usleep function or
someting similar for sleeping shorter periods.
Is someting like this available? Otherwise
I could of course use (1) for this purpose
reducing responsivity of the system since
I'd like to sleep several 10ms... Accuracy
is not really important in this case...

Best regards,

Erik.



P.S. I want to use transputers and helios because
the OS is nice and can be booted fast after
changes in hardware or wiring have been made.
Transputers are powerful enough to do a lot
of data processing "in hardware" but you all
know this... ;-)
P.P.S. I have the transputer stuff up and running
using a SUN4C as host system with a sbus
BBK-S4 interface board. Realizing the hardware
is not a difficult task once the boards feature
connecor pinout is known.
P.P.P.S. The nature of the electronics project is
that I want to learn details about an old
computer based on core memory. Therefor I
want to be able to program the core memory
with certain patterns to decode the machine
code od the CPU. I already know a reasonable amount
about the box giving me the hope that
it should absolutely be possible - the nature
of the project essentially is solving a
5000 piece puzzle ;-)
 
 
 

Helios C- and timing-question...

Post by Mike » Thu, 18 Aug 2005 03:25:44

Hi Erik!

Questions 1:
============

It's not really an answer, it's a slight modification of your origin
design to make question 1 obsolete.

Use for the input also a 374 and clock it the same as your output
latches. This has two big advantages:
* Your data are stable during read!
* The read-data are sampled synchronous to the last write (e.g. 0->1 of
Bit14)

Question 2:
===========

In SYSLIB.H is a prototype Delay(word micros). Never used.

Mike

 
 
 

Helios C- and timing-question...

Post by Mike » Thu, 18 Aug 2005 03:30:31

Correction: 374er are FF (not latches) and it's a 1->0 transition of
Bit 14.

Sorry, Mike
 
 
 

Helios C- and timing-question...

Post by Erik Baiga » Thu, 18 Aug 2005 15:41:57


Hi Mike,

thanks for your reply!!!


My question was not clear maybe. The problem is
not to apply signals simultaenously. Where I will
encounter problems is that the program must not be
interrupted if e.g. the strobe is low: The
strobe pulse must have a defined duration of
e.g. 2us. Application: The strobe puls applies
current to the readout wires of the core memory
and if the transputer is doing OS related stuff
it will probably miss the data read since reading
core memory is destructive...

Hey, thats cool - I will try this on the next weekend!

Thanks Mike,

Erik.
 
 
 

Helios C- and timing-question...

Post by Mike » Thu, 18 Aug 2005 17:28:56

Hi Eric,

now it's a little bit clearer ;-)

If you want to solve the problem in SW (T+Helios) you MUST switch to
HI-prority and DON'T use Delay() for the inner timing! The first time
you block, you're off, because Helios also uses HI-prio tasks. Since
HI-prio task runs as long as they "want", you can use Delay() only
between your core memory read(+rewrite). The other (inner) timings are
with polling the timer or fix instruction delay (2us are only
15cycles@30MHz and you have only a 1us timer resolution). Hopefully
Helios will accept such tasks.

I will check it this evening. Should be possible ...

Can you post a (fixed font) timing diagram?

Mike
 
 
 

Helios C- and timing-question...

Post by Mike » Thu, 18 Aug 2005 18:17:48

Helios API about running at a selected priority ...

From
http://www.yqcomputer.com/

10.2.3 The System libraries/UTILITY LIBRARY/Thread creation
This library provides a low-level thread creation interface,
essentially a veneer on top
of the Kernel routines.
The NewProcess function allocates a stack, using Malloc, and calls
InitProcess.
The result is a pointer to the position of the first argument for the
new thread. The
functions RunProcess and ExecProcess start a thread created by
NewProcess running.
The main difference between these routines is that RunProcess starts
the thread
running at the same priority as the caller, while ExecProcess starts it
at a selected priority.
If the caller decides not to start a process, it can call ZapProcess to
deallocate
the stack.
The Fork function is the most frequently used interface to these
routines. It simply
calls NewProcess to allocate and initialise a stack, copies the
supplied parameters into
the new thread's stack frame, and calls RunProcess to start it.
As described in chapter 9, The Kernel, threads are only able to
terminate themselves,
they cannot be terminated externally except on task exit. A thread
created by
NewProcess (and hence Fork) can terminate by returning from its entry
procedure.
This returns to code which will deallocate the stack and halt the
process (by calling
FreeStop).

Mike
 
 
 

Helios C- and timing-question...

Post by Erik Baiga » Fri, 19 Aug 2005 02:46:53


Tried out this function - it works well and rather accurate.
But it can be interrupted by OS stuff and thus is not OK
for generating my timing. But for lots of tasks it is good
to know about!!!
 
 
 

Helios C- and timing-question...

Post by Erik Baiga » Fri, 19 Aug 2005 02:52:17


OK, sounds reasonable for me after my experience with
the Delay procedure in stnadard priority.

I will have to try this I think...



I want to apply (simplified) the following signals:

Adress/Data (12Bit Out): ____ADR-VALID________________________________REWRITE-DATA-VALID__________
ALE (Adress-Latch-Out): ______---________________________________________________________________
C1EN (Current-Enable-Out): ________________-------------------------_________-----------____________
C2EN (Read-Current-En-Out): _________________________----------------________________________________
C3EN (Write-Current-En-Out): _____________________________________________________------_______________

As a resonse I expect the data from core-memory:

Data (12Bit In) _____________________________DATA-VALID____________________________________
|
What is critical is the timing from switching on ^ | |
the read current C2EN until the valid data appears ^ ^
after this there is only a small time window in which <------>
data can be read. Thus after switching the read current
on the process must not be interrupted until valid data
appeared an has been read in. During rewrite timing is
not critical any more. Thus only approx 20% of the whole
cycle are critical regarding timing and would require
high priority.

Mike, thanks a lot for your tips and time,

Erik.
 
 
 

Helios C- and timing-question...

Post by Erik Baiga » Fri, 19 Aug 2005 02:53:49


Thanks for the reference - I will have to study
this. Is there an example included? Sounds quite
tricky... Hopefully I will find time on the weekend
to investigate this...

Thanks for now,

Erik.
 
 
 

Helios C- and timing-question...

Post by Erik Baiga » Fri, 19 Aug 2005 04:25:41


OK, these functions reside in nonansi.h and the
essential one will be

void ExecProcess( void * process, word logpri );

Looks good that they will do what I need. Maybe
it creates a lot of overhead to call ExecProcess
every time I want to run a piece of timing critical
code but efficiency is not a real concern in my
application ;-)

Thanks,

Erik.
 
 
 

Helios C- and timing-question...

Post by Mike » Fri, 19 Aug 2005 04:55:08

This reference isn't a solution, because ExecProcess() don't allow
TransputerPrio 0 (=HeliosPrio -32768 (=HighestPri from process.h)) but
you can bypass the priocheck with StartProcess( p, 0 )!!!

I'm (currently) unable to change the priority of a running process
(myself).

This is my high-prio-starter-sample:

#include <stdlib.h>
#include <process.h>
#include <sem.h>

Semaphore _finished;

static void reader_process( void );
static void writer_process( void );

extern void StartProcess( void *args, word pri );

/*===========================================================================*/
int main( int argc, char *argv[] ) {
/*===========================================================================*/

int rc = -1;
void* p;

InitSemaphore( &_finished, 0 );

if ( argc != 1 ) {
printf( "Usage: %s\n", argv[ 0 ] );
rc = 999;
} else if (( p = NewProcess( 2000, &reader_process, 1 )) == NULL )
{
printf( "ERROR: Unable to create reader process.\n" );
rc = 1;
} else {
StartProcess( p, 0 );
Wait( &_finished );
writer_process();
rc = 0;
} /* endif */

return rc;
}

/*===========================================================================*/
static void writer_process( void ) {
/*===========================================================================*/
printf( "World (%d)\n", GetPriority());
}

/*===========================================================================*/
static void reader_process( void ) {
/*===========================================================================*/
printf( "Hello (%d) ", GetPriority());
Signal( &_finished );
}

During T-Prio 0 avoid all HeliosAPI calls (printf, GetPriority and
Signal works, but it's not timecritical, it's a sample ;-)
Use asm and ldtimer loops and maybe a simple channel between.

Maybe this helps.

Mike
 
 
 

Helios C- and timing-question...

Post by Mike » Fri, 19 Aug 2005 05:01:02

Why always remove him from work, send him a message ;-)
 
 
 

Helios C- and timing-question...

Post by Mike » Fri, 19 Aug 2005 05:37:18

Hi Erik,


No problem, but you have to decide the further solution strategy.

(1) Make the time critical problem to a non-time critical (transient to
persistent) with a little bit of hardware (easy, but you have to do
more soldering)
or
(2) solve it in software (yeah, do it the hard way ...)

Serios is 1 but cheaper is 2 ....

Mike

PS: Ausserdem ist es eine tolle Englischung, oder ...
 
 
 

Helios C- and timing-question...

Post by Mike » Fri, 19 Aug 2005 07:25:21

Hi Erik,

I've written a short (raw) prototype for the critical high-prio-part to
made estimations.
It looks, that a accuracy of -0.1us/+1.0us (@30MHz) is possible. (I'm
not really sure about the upper limit and there is a idea about a more
accurate code ... maybe tomorrow)

/*===========================================================================*/
static void critical( void ) {
/*===========================================================================*/

word delay, now, *port, data;

port = PORTADDR;

for (;;) {

chan_in_word( &_channel, delay );
if ( delay < 0 ) break;

data = _data; /* update */

now = ldtimer_();

while ( ldtimer_() == now );
*port = data;

now += delay + 1; /* wrap around? */

while ( ldtimer_() < now );
*port = data; /* latch data for read */

_data = *port;
} /* endfor */

Signal( &_finished );
}

looks in assembler:

.critical:
...
ldtimer
stl 0

..13: ldtimer
ldl 0
diff
eqc 0
eqc 0
cj ..13

ldl 2
ldl 1
stnl 0

ldl 0
ldl 3
adc 1
add
stl 0

..16: ldtimer
ldl 0
rev
gt
eqc 0
cj ..16

ldl 2
ldl 1
stnl 0

ldl 1
ldnl 0
ldl 4
ldnl @__data
stnl __data

...

ret

So good luck in reading core memory ...
Mike
 
 
 

Helios C- and timing-question...

Post by Mike » Fri, 19 Aug 2005 15:14:32

Hi Erik,

What a shame! The prototype for the critical high-prio-part is bad.


This is much better :-))))

...

ldl Delay

// first write
ldl 2
ldl 1
stnl 0

// variable delay
xxx

// second write
ldl 2
ldl 1
stnl 0

...

If vardelay is 0, the min pulse with (external memory access) is
approximately 12 cpu cycles.
Since vardelay is min 2 -> the minpulse is 14 cpu cycles or 467ns at
30MHz (has to be measured!)

What do you think about shl as vardelay.
It's not his function; it's his execution time of Areg+2.

This gives you a timer resolution from 1/CpuSpeed (30ns at 30MHz)!!
More accuracy isn't possible.

So: VarDelay = PulseWidth / CpuSpeed - 14;

Mike

PS: TIS says: Areg < wordlength, but we can ignore that, as long as it
works ;-)
PSPS: There are some solutions to reduce the minpulsewidth, but for the
first approach I think 0.5us are ok.
PSPSPS: Remember ... we do the second stnl to capture the input, the
output is the same.