Introducing a simple process control block meant to be enhanced...

ErNa

Had to overcome some obstacles, so I could not proceed with my projects in a timely manner and now I have to start the race..
My goal has not changed, I'm looking to create a modular, flexible and reliable solution using a single scheme for inter-process communication. The resources available with the P2 allow to spend some memory and instruction for safety measures.
I'll see how far I come, so I start at the very beginning.

Mickster

@ErNa

I am sure that I have psychic powers because I was just thinking about you. This stuff happens to me all the time

ErNa

In the past (P1) I created a communication mechanism between cogs to have a uniform solution both for SPIN and ASM objects. I'm now moving my motor control project to the P2, hopefully I'll expand it to a smart home control system (smarter than anything, that exists, or even smarter than we can imagine, or, alternatively, not). While in the past I just started a process, waiting for acknowledge, I now will exchange a version number to be sure, that the right object was linked.
This should work also for inter-chip communication, what means, mixed systems P1, P2 could run also.

Mickster

@ErNa

[Subtle hint]

Need to get the P2 on the map but it's above my pay-grade

Craig

ErNa

I'm digging out an old project I intended to demonstrate how I organize communication between processes. It's a type of early Ping/Pong, using Andy Schenk's terminal software. For just now I create a documentation do be in line again, next I have to move it to the P2. And do some improvements. 17 year passed by.

ErNa

OK, here we go. When looking through the code I found it to be very rudimentary. I now made some changes and it now runs that way, that three different moving object wander along the screen, but do not interact yet.
Documentation mixes German and Denglish, as I move it to SPIN2, I'll also revise documentation. The first goal is to start processes and exchange the pointers to establish communication.

In HUB a ProcessControlBlock is located:
CON AnzWrfrPar = 11 ' Wertezeiger für den Fänger <br /> Dat ProzWrfr long @WrfrCmd, @WrfrDisp, @XWrfrAlt, @YWrfrAlt, @XWrfrNeu, @YWrfrNeu, @XBttrNeu, @YBttrNeu<br /> long @YWrfrMini, @YWrfrMaxi, @WrfrColo , 0, 0, 0, 0
THe process is started by telling the number of parameters as the first parameter, later this is the command/Ack mechanism
WrfrCmd := AnzWrfrPar ' Damit kann WerferStart die richtige Anzahl Pointer initialisieren i := Wrfr.start(@ProzWrfr, @@0) ' Butter starten
The process then is controlled by invoking a command:

AktStat := CmdInvok (@FngrCmd, Run, 0)
PRI CmdInvok (CmdPtr, Cmd, Stat) ' Wait until process idle, output cmd, wait for acknowledge, return "Stat" for documentation/debuging purposes repeat while long[CmdPtr] long[CmdPtr] := Cmd repeat while long[CmdPtr] Result := Stat
The start-procedure of the process started looks like this:
`PUB Start( GlobPtr, AddrOffs) | i

Stop ' Start can restart, therefore stop a possibly running cog first
' Create a local copy of the global pointer array and do the address correction "quick and dirty"
repeat i from 0 to LONG[LONG[GlobPtr + 0]+AddrOffs]-1 ' The first parameter is the number of parameters
LONG[@LoclPtr + (i<<2)] := LONG[GlobPtr + (i<<2)] + AddrOffs ' all pointers are 32 bit, the pointer address is byte oriented

ifnot ID_cog
ID_cog := cognew(CogProc, @Sk) + 1
Result := ID_Cog
`
This copies all the pointers to a local variable and corrects the offset
The process then can have access to the hub variables
This start works both for spin and ASM

I'll now try to move it to the P2, where I/O can be down via debug to run the program on any PC

ErNa

A quick update: Moved all the code to SPIN2, eliminated all the compiler messages, moved procedure for Ariba's PCASCIIinterface to jm_fullduplexserial and: surprise! got a first version running. Have to to hunt down, why the mouse interface doesn't run yet, but, I'm quite happy now.

ErNa

One more step: Ariba's serial driver handles mouse events ( initiated by $05 ). Have to implement this in jm_fullduplexserial to get my app running. Next: make this function selectable. It may also be a goal to introduce flow control like XON/XOFF.

ErNa

Just a short note: With the P1 hub access was slow and access time jittered, whenever possible it was a good idea to keep variables in the COG (ASM) . Now we can address hub ram indexed ptra[X], so it is appropriate to keep variables in hub. But: in the past, I supplied processes using a pointer array to the actual data, what allowed me to read/write hub data from all processes. To keep this flexibility and keeping track with the idea, that all the processes can be fully controlled from outside, I opt for flexibility, not for performance or compactness. Whenever I come to an end, flexibility still will an issue, speed and space not. This said, I'll continue with full duplex serial. Have to see, how the smartpins do their job ;-)