Jump to content
BeeryMiller

TIPI - Geneve 9640 to Raspberry PI interface development

Recommended Posts

16 minutes ago, arcadeshopper said:

So wouldn't resetting the Geneve also call the routine? And if not you're missing something in your power up to support TIPI

By the time Beery gets to TIPICFG, the TIPI onboard EPROM powerup has been called twice - once by the Geneve boot EPROM and once by the emulated /4A ROM (due to rompage).  

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, InsaneMultitasker said:

Is the service restart inhibited if the bit is set and cleared, then immediately followed with a TIPI operation such as an IO read or write?  Beery and I tested powerup code early on (using your ROM as the guide) and the powerup only worked some of the time, seemingly random.  I'm wondering if we need(ed) a delay between the powerup and post-powerup operation.

 

My power up routine in the TIPI ROM assumes the execution speed of a 4A. 

 

It sets the second cru bit, busy loop ( 4A speed assumed ), and clears the bit.  This triggers a kill of the tipi.service. 'systemd' then observes the absence of the process, and restarts it. The cru bit must be set long enough to propagate the signal to the python GPIO interrupt handler. 

 

If TIPI messages are sent while the service is down, they will block until the service is done starting. 

 

I haven't had a need to solve the storm problem... on the 4A this only happens if I hit reset a bunch of times like a child. When I have seen that, 'systemd' logs a warning that there are too many restarts of the tipi.service, and that it is backing off. Do something else for a little while ( like get a cup of coffee, from a different room ) and it will have resumed normal operation... usually.

 

This cru controlled service reset, is completely different than TIPICFG's reboot option. The latter issues the linux command 'reboot now' - the cru base reset routine is designed to prevent the need to reboot the PI. 

 

----

 

Program lifecycle is important. On a 4A... there really isn't task switching without going back through console powerup routines. So... if TI-Artist locked up on a 4A due to a tipi.service crash, you just reset the 4A, and the tipi.service crash is cleared by the console powerup routine.  On a 4A any file left open is abandoned by going through the powerup again. All state in the tipi.service such as left-open sockets and whatever is cleaned up implicitly by the PI OS when the tipi.service process exits. 

 

It seems GPL works that way.. 

 

But in MDOS, there is an actual operating system. tasks are created, switched, etc... A program like Myart ( don't remember how myart is run ) can crash things with the PI.PIO bug, and then jumping back into MDOS leaves the tipi.service still hung. I assume. 

Edited by jedimatt42
  • Like 1

Share this post


Link to post
Share on other sites
53 minutes ago, jedimatt42 said:

It sets the second cru bit, busy loop ( 4A speed assumed ), and clears the bit.  This triggers a kill of the tipi.service. 'systemd' then observes the absence of the process, and restarts it. The cru bit must be set long enough to propagate the signal to the python GPIO interrupt handler. 

 

If TIPI messages are sent while the service is down, they will block until the service is done starting

I honestly do not recall any observable message blocking when I was testing the powerup routine, in fact, the only thing I do recall observing was the lack of a logged reset message when I executed any level3 IO request immediately following the reset.  On the other hand, I do not recall ever seeing a time where the Geneve boot EPROM powerup or GPL rompage /4a powerup failed to trigger a tipi reset, so I assume(d) the TIPI ROM-based timing loop is sufficient, and that my immediate, subsequent IO request was what disrupted the powerup.  I documented the need to revisit this code at a later date and moved on to other aspects of the DSR;  it's later now, so I'll test it this weekend.

 

1 hour ago, jedimatt42 said:

A program like Myart ( don't remember how myart is run ) can crash things with the PI.PIO bug, and then jumping back into MDOS leaves the tipi.service still hung.

Myart runs from MDOS mode.   I think that the point Beery was trying to make is that the TIPI rom-based EPROM powerup was executed but he still had no "access" to the PI as a result of the PI.PIO 'crash'.  Maybe there are multiple reset scenarios being conflated?  I'll defer to Beery to clarify his own actions and intent.

 

1 hour ago, jedimatt42 said:

On a 4A any file left open is abandoned by going through the powerup again. All state in the tipi.service such as left-open sockets and whatever is cleaned up implicitly by the PI OS when the tipi.service process exits.

That's an important point to keep in mind.  Hmm, a TIPI reset after each task completes could be problematic for open batch files executed from the TIPI.    (Has FC tackled batch files and program execution in any particular manner?)   I/we have been more concerned with the front end so it will require a bit of research into how a task cedes control to the OS and what cleanup, if any, occurs at that time.  Maybe I'll write a short, misbehaving MDOS program to see if I can purposely lock all available file handles.

 

Share this post


Link to post
Share on other sites

ForceCommand closes the script if it passes control to user code. If return is successful, it reopens and seeks to the next line. If user code crashes the TIPI, that user code is stuck in one of the DSR recv message routines. So the only way back to ForceCommand in such a case is through the console power up path.

 

I guess I will have to try and reproduce this crash on the 4A. 

 

I would think that the cru reset process triggered by an MDOS reboot would also kick the PI from your description, such that manually restarting the PI isn't necessary. IDK about the issue with making a request 'too soon' after the reset. On a 4A it is a computational millennium between power up and any program asking the TIPI for anything.

 

My main point with all this reset talk is that a user should not encounter a situation that requires rebooting the PI. After a client device, 4A or Geneve, misbehaves resetting that client device should get the PI rolling again.

 

-----

 

I will see if I can correct the top level exception handler to pro-actively reset the tipi.service. 

 

And then fix the PI.PIO to properly error on write if not open. 

  • Like 1

Share this post


Link to post
Share on other sites
55 minutes ago, jedimatt42 said:

...

I will see if I can correct the top level exception handler to pro-actively reset the tipi.service. 

...

 

The top level exception handler already resets the tipi.service implicitly on catastrophic fail such as writing to PI.PIO without having opened: 

 

2021-02-14 08:25:24,470 PioFile     : INFO     write special? PI.PIO
2021-02-14 08:25:24,485 TipiService : ERROR    Unhandled exception in main    <-------- Oh, I already had code deal with this.
Traceback (most recent call last):
  File "./TipiService.py", line 79, in <module>
    if specialFiles.handle(pab, filename):
  File "/home/tipi/tipi/services/SpecialFiles.py", line 52, in handle
    handler.handle(pab, devname)
  File "/home/tipi/tipi/services/PioFile.py", line 31, in handle
    self.write(pab, devname)
  File "/home/tipi/tipi/services/PioFile.py", line 105, in write
    with open(self.data_filename, "ab") as data_file:
TypeError: expected str, bytes or os.PathLike object, not NoneType
2021-02-14 08:25:24,935 TipiService : INFO     physical mode enabled
2021-02-14 08:25:24,936 TipiService : INFO     TIPI Ready    <------------ it restarted 

This happened while the 4A was still locked up waiting for an answer from the DSR write routine. 

 

So I don't understand why the tipi.service is 'hung' still after you exit Myart.

 

Anyway, on to correcting the crash in the first place. Fixing it so it properly errors back to the 4A.

  • Like 1

Share this post


Link to post
Share on other sites

TIPi update 2.19 will fail fast if writing to PI.PIO without having opened the file. 

 

But wait, that doesn't fix Myart... sure.. I know... but PI.PIO is tolerant of re-opening, to support issues where programs don't close. So you an go into TI BASIC and 're-open' PI.PIO, then close it to trigger flushing the print job.

 

Likewise, since myart doesn't behave, an open and close tool could be written for MDOS to run first, then run myart... print... then exit, and run the tool again to close. ( maybe... IDK the rules on XOP file close routines ) 

 

 

--- as an aside -- barely on topic ---

 

Here is the ForceCommand user code I used to test:

 

#include "fc_api.h"

int main(char* args) {
  struct DeviceServiceRoutine* pi_dsr = 0;
  pi_dsr = fc_find_dsr("PI", 0);        <---- this is a new API I had to expose - so PROGRESS.

  if (pi_dsr == 0) {
    fc_tputs("PI. not found\n");
    return 0;
  }

  struct PAB pab;
  pab.Status = 0;
  pab.OpCode = 0;
  pab.ScreenOffset = 0;
  pab.VDPBuffer = 0;
  pab.CharCount = 0;
  pab.RecordNumber = 0;
  pab.RecordLength = 80;

  pab.pName = "PI.PIO";
  pab.NameLength = 6;

  int err = fc_dsr_write(pi_dsr, &pab, "Hello World", 11);

  if (err) {
    fc_tputs("failed to write to PI.PIO\n");
  }

  return 0;
}

 

  • Like 2

Share this post


Link to post
Share on other sites

Matt,

 

Your 2.19 update takes care of the Myart issue.  

 

And after I tried to print, and Myart recognized it could not print, I then copied my AUTOEXEC file to PI.PIO and everything resumed as it should.

 

Many thanks for the update.

 

Beery

 

 

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...