SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

About the mesh errors discovered by Donamy: Can't we just do a pre-release and wait at least a week before releasing should nothing need to be fixed?

I think the errors we discover right now are not necessary, we could have found them before release.

I know people have lives and stuff but, where has everybody been since April or May when I first started to "ask" for a release? Yes, doing RCs is good, and I'm expecting we'll need more than a few to tweek 5.0 before it comes out, but it's not like there are a lot of people waiting for a release for Orbiter 2010 when 2016 has been out for some months now.
Right now I think the priority has to be getting SSU running in Orbiter 2016, and for that we needed to get SSU 4.0 out the door, so the trunk can (finally) be switched to the 2016 sdk. Yes we could have delayed 4.0 a few more weeks/months and get everything squared way before it came out, but then it would probably be 2018 before we get SSU for Orbiter 2016.
I'm not happy with this "solution", but I think it's the least painful... it's like Cooper says in Interstellar "To go somewhere you gotta leave something behind".

 

[Urwumpe]

it's like Cooper says in Interstellar "To go somewhere you gotta leave something behind".

"Features that have not been tested, are not existing."

Urwumpe, in the wrong movie. (Spring 2016)

 

[GLS]

Well, I would use a struct for the COMPOOL I think and leave it to the software to interpret what it is. Maybe just have an array of COMPOOL pointers for a major function/major mode to simplify the addressing (In the real system, this would be done during compilation, it had a very simple memory management)

That is actually the pretty simple part of it all. For the IO, what about using a DAO-like class as abstraction layer?

The final state that I plan for is having IO programs, that are essentially used with a simple I/O interface in the sense of the following SVC function:

svc_start_io(CCW& command_word)

with the CCW containing where to find the IO program instructions.

I am writing this from a hotel room, so don't expect too much detail from me. I know from comparisons at home, that the CCW is very similar to the standard System/360 CCW, but has some small important differences.

Having read this a few more times, I'm wondering if this is aimed at GPC I/O from the MDMs? If so, that's not what I had in mind. I just want to move most/all STS()->GetABCfromOrbiter() and STS()->GetXYZfromOrbiter() from the software classes into a single place where all that data is anyway (eventually these calls would go into the subsystems: IMU, ADP, etc to source the data instead of it just appearing there). This way we could change the altitude reference between MM304 and 305 more cleanly.

On the first part about the COMPOOL, is this what you mean?

// declaration
DWORD COMPOOL[wtvr_size];

// addrs
const int VAR_A = 0;
const int VAR_B = 1;
const int VAR_C = 2;

// sw saves a float var in the COMPOOL
memcpy( floatvar, COMPOOL[VAR_B], 4 );

 

[Urwumpe]

Having read this a few more times, I'm wondering if this is aimed at GPC I/O from the MDMs? If so, that's not what I had in mind. I just want to move most/all STS()->GetABCfromOrbiter() and STS()->GetXYZfromOrbiter() from the software classes into a single place where all that data is anyway (eventually these calls would go into the subsystems: IMU, ADP, etc to source the data instead of it just appearing there). This way we could change the altitude reference between MM304 and 305 more cleanly.

On the first part about the COMPOOL, is this what you mean?

// declaration
DWORD COMPOOL[wtvr_size];

// addrs
const int VAR_A = 0;
const int VAR_B = 1;
const int VAR_C = 2;

// sw saves a float var in the COMPOOL
memcpy( floatvar, COMPOOL[VAR_B], 4 );

No, I would say something like:

struct COMPOOL_MF_GNC {
    int A;
    int B;
    int C;
};



//...................

COMPOOL_MF_GNC *mf_gnc_compool = linker.allocateMajorFunctionOverlay(sizeof(COMPOOL_MF_GNC);

//...................

mf_gnc_compool->A = 4;

//...................

IOLayer.readABCSensor(&(mf_gnc_compool->A));        //blocks thread

//Do something with A, B or C....

//.........

CCW my_ccw = IOLayer.requestABCSensor(&(mf_gnc_compool->A));        //does not block thread

//.........

if(IOLayer.isFinished(my_ccw)) {
     //Do something with A, B or C....
}

 

[GLS]

No, I would say something like:

struct COMPOOL_MF_GNC {
    int A;
    int B;
    int C;
};



//...................

COMPOOL_MF_GNC *mf_gnc_compool = linker.allocateMajorFunctionOverlay(sizeof(COMPOOL_MF_GNC);

//...................

mf_gnc_compool->A = 4;

//...................

IOLayer.readABCSensor(&(mf_gnc_compool->A));        //blocks thread

//Do something with A, B or C....

//.........

CCW my_ccw = IOLayer.requestABCSensor(&(mf_gnc_compool->A));        //does not block thread

//.........

if(IOLayer.isFinished(my_ccw)) {
     //Do something with A, B or C....
}

Again, is this so the software can share data in the COMPOOL, or to get data into the GPCs? Right now I'm only interested in sharing, so data is centralized and, e.g., everyone uses the same altitude. For now the data would still come from Orbiter in the same way it does now, except those calls to Orbiter would be made from the UPP, instead of it getting the data from the sensors and subsystems.

BTW: DaveS, I don't know what source you used for the MECO altitudes, but AFAIK (from NASA/TM-2011-216142) STS-101, 114, 120 and 126, and I think the other ISS flights, had a 52NM MECO.

 

[Urwumpe]

Again, is this so the software can share data in the COMPOOL, or to get data into the GPCs? Right now I'm only interested in sharing, so data is centralized and, e.g., everyone uses the same altitude. For now the data would still come from Orbiter in the same way it does now, except those calls to Orbiter would be made from the UPP, instead of it getting the data from the sensors and subsystems.

For sharing - as long as all processes use the same pointer to the COMPOOL, this should be no problem. Maybe instead of using a linker that needs all COMPOOL allocations in the same order, you could also use a string identifier to a COMPOOL dictionary.

 

[DaveS]

BTW: DaveS, I don't know what source you used for the MECO altitudes, but AFAIK (from NASA/TM-2011-216142) STS-101, 114, 120 and 126, and I think the other ISS flights, had a 52NM MECO.

I got my data from Bill Harwood's Ascent Data sheets that he published prior to each flight. Generally, they were all above 105 km.

 

[GLS]

I got my data from Bill Harwood's Ascent Data sheets that he published prior to each flight. Generally, they were all above 105 km.

But that altitude (57NM) was +/- the standard prior to the PE stuff they added in the late 90s to get extra performance for the ISS flights.

---------- Post added at 02:48 PM ---------- Previous post was at 02:47 PM ----------

For sharing - as long as all processes use the same pointer to the COMPOOL, this should be no problem. Maybe instead of using a linker that needs all COMPOOL allocations in the same order, you could also use a string identifier to a COMPOOL dictionary.

Let me digest the previous post a bit further then...

 

[DaveS]

But that altitude (57NM) was +/- the standard prior to the PE stuff they added in the late 90s to get extra performance for the ISS flights.

This is the STS-126 Ascent Data: http://spaceflightnow.com/shuttle/sts126/fdf/126ascent.html

 

[Urwumpe]

Let me digest the previous post a bit further then...

Sorry.

 

[GLS]

Sorry.

Why?
So if I'm understanding this correctly, you want us to treat the memory (or just the COMPOOL) as a "device", and to access it we use a certain IO protocol. Right, wrong?

---------- Post added at 12:16 PM ---------- Previous post was at 12:09 PM ----------

This is the STS-126 Ascent Data: http://spaceflightnow.com/shuttle/sts126/fdf/126ascent.html

Nothing against Bill Harwood but, if available, I prefer to use NASA info.
Looking at the Ascent Checklists it points to they targeting a 57NM MECO.... which then makes me wonder "why all the talk in several documents about the 52NM????" If anyone has any info on this, I'd really like to clear this discrepancy.
Anyway, changing just the MECO altitudes in the misson files will mess up the apogee altitude... the FPA also needs to be changed.

 

[Urwumpe]

Why?
So if I'm understanding this correctly, you want us to treat the memory (or just the COMPOOL) as a "device", and to access it we use a certain IO protocol. Right, wrong?

Wrong. Just as a shared memory that it is.

But: IO happens mostly in the background in the Shuttle, the data in the shared memory is updated while the process that needs the data is still not executed.

That is needed to a real-time system and it sure isn't stupid should we maybe want to minimize the length of a time step.

 

[GLS]

I'm merging the beta branch into the trunk, so I want to ask for no commits to be made until this is finished. It's unlikely I'll commit today as there are tons of files to check for the proper content.

 

[Urwumpe]

I'm merging the beta branch into the trunk, so I want to ask for no commits to be made until this is finished. It's unlikely I'll commit today as there are tons of files to check for the proper content.

Don't worry. I doubt I will start to do much before next weekend. I still need to renew my TLS certificate for Sourceforge.

 

[GLS]

So far so good in the checking of things (hopefully in a few hours I'll commit the merge), but I found something odd: the Centaur doesn't have reflections anymore in D3D9. I checked our recently released 4.2 and everything is shiny in there, but in Orbiter 2016 only the PLB doors have reflections and they seem fuzzy, and the Centaur looks as it does in MOGE. Can anyone check what the state of this is in the beta branch, to determine if this is a merge problem or something else*? (I can as I'm "stuck" until I commit the merge)

*) if it is something else, please wait until the merge is done to fix it

 

[DaveS]

So far so good in the checking of things (hopefully in a few hours I'll commit the merge), but I found something odd: the Centaur doesn't have reflections anymore in D3D9. I checked our recently released 4.2 and everything is shiny in there, but in Orbiter 2016 only the PLB doors have reflections and they seem fuzzy, and the Centaur looks as it does in MOGE. Can anyone check what the state of this is in the beta branch, to determine if this is a merge problem or something else*? (I can as I'm "stuck" until I commit the merge)

*) if it is something else, please wait until the merge is done to fix it

Things changed with the introduction of Physics Based Rendering (PBR) in D3D9Client for 2016 so the textures will have to be updated.

 

[GLS]

Everything seems in order so I'm committing the merge now. Just a reminder that after this, the trunk version is Orbiter 2016.

---------- Post added at 02:45 PM ---------- Previous post was at 02:23 PM ----------

Done! I have no more restrictions on commits.

 

[DaveS]

The Centaur reflection map texture have been updated to work with the PBR-based D3D9Client and checked in.

 

[GLS]

Wrong. Just as a shared memory that it is.

But: IO happens mostly in the background in the Shuttle, the data in the shared memory is updated while the process that needs the data is still not executed.

That is needed to a real-time system and it sure isn't stupid should we maybe want to minimize the length of a time step.

Coming back to this: could that "running in background" be simulated (for now at least) by putting the UPP process running before all the others at each time step? Or should I start buying mutexes and go multithread?

Having a COMPOOL structure located in the SimpleGPCSystem class and available to all SimpleGPCSoftware processes, and having the UPP process updating it each time step with the STS()->GetXYZ() calls (for now), is pretty much what I need. Now, you know more about the GPCs than me, so I'm trying to understand how to make this such that it's +/- usable in the future... but I'm still not following your line of thought... :facepalm:

 

[Urwumpe]

Coming back to this: could that "running in background" be simulated (for now at least) by putting the UPP process running before all the others at each time step? Or should I start buying mutexes and go multithread?

Leave this to me, I already have a volume license for semaphores. :lol:

Essentially, the non-multithreaded solution would be like you say. Get the data before the process is executed and don't switch processes when a SVC is called. Maybe split bigger processes into smaller "execution blocks" that begin with a finished SVC operation.

Similar happens for the application software that drives the displays. The I/O with the IDP happens by HAL/S macros at the definition of the application process.

I have a prototype that works already with multithreaded DPS processing, but it is still just a prototype with many design bugs in it. It even crashes sometimes, so hardly useful now. I can offer it to SSU when I have it stable and you can understand it as well.

About the line of thought: How much do you know about Direct Memory Access I/O?