Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » DSDP - Real-Time Software Components (RTSC) » XGCONFIG disabling form input(Very specific knowledge needed for help.)
XGCONFIG disabling form input [message #952697] Sun, 21 October 2012 18:00 Go to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
I have created a somewhat complicated form for setting pinmux settings. I have attached a screen shot to illustrate what I am doing.

In a listbox, I have a list of ports that can be selected. Each port bit has specific settings that can be selected from various droplist controls that give the allowable options. Since each port and bit have specific options, I have declared this in my .xdc file.

metaonly config Any Ports[string];

in my .cfg file, I do this:
PinProfile_INIT.Ports["PORT_A"] = new PinProfile_INIT.PortA();
PinProfile_INIT.Ports["PORT_B"] = new PinProfile_INIT.PortB();
PinProfile_INIT.Ports["PORT_D"] = new PinProfile_INIT.PortD();
PinProfile_INIT.Ports["PORT_E"] = new PinProfile_INIT.PortE();
PinProfile_INIT.Ports["PORT_F"] = new PinProfile_INIT.PortF();
PinProfile_INIT.Ports["PORT_G"] = new PinProfile_INIT.PortG();
PinProfile_INIT.Ports["PORT_H"] = new PinProfile_INIT.PortH();
PinProfile_INIT.Ports["PORT_J"] = new PinProfile_INIT.PortJ();
PinProfile_INIT.Ports["PORT_C"] = new PinProfile_INIT.PortC();

PinProfile_INIT.mapPortBitsToGpio();


mapPortBitsToGpio() function has statements like this:

  this.Ports["PORT_A"].baseIndex = IPortBaseRegs.PORT_A_INDEX;
  this.Ports["PORT_A"].baseAddress = IPortBaseRegs.PORT_A_BASE;
  this.Ports["PORT_A"].bit0 = this.gpio0;
  this.Ports["PORT_A"].bit1 = this.gpio1;
  this.Ports["PORT_A"].bit2 = this.gpio2;
  this.Ports["PORT_A"].bit3 = this.gpio3;
  this.Ports["PORT_A"].bit4 = this.gpio4;
  this.Ports["PORT_A"].bit5 = this.gpio5;
  this.Ports["PORT_A"].bit6 = this.gpio6;
  this.Ports["PORT_A"].bit7 = this.gpio7;


This all works, but I would like to put the first lines of code into the mapPortBitsToGpio function, or ideally the whole thing into the module$meta$init function so it is not necessary for the user to add these lines into the .cfg file at all.

However, when I do that, the controls on the screen are disabled and faded.

Can anyone provide insight into what I would have to do to re-enable the controls?

Re: XGCONFIG disabling form input [message #955572 is a reply to message #952697] Tue, 23 October 2012 22:33 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
James,
one of the reasons a module's Xgconf view is grayed out is that the module is not being used. If you move your code to PinProfile_INIT.module$meta$init, you have to invoke xdc.useModule() on PinProfile_INIT in the CFG script to be able to configure that module in Xgconf. You can also right-click on that module in the Available Products view and then click on Use PinProfile_INIT.

Hint:
When you develop Xgconf representation of your module in CCS, sometimes it's useful to run CCS with '-console' flag. This will open a console window, which displays some warnings and errors that I couldn't find displayed anywhere else. Not everything that shows up there is related to your development though.
Re: XGCONFIG disabling form input [message #958319 is a reply to message #952697] Thu, 25 October 2012 23:17 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
Thanks for the tip on the console screen. But, I still have problems. To illustrate, I have some screenshots and .cfg code.

Here is the first part of my .cfg file.
var IPinOptions = xdc.module("trust.drivers.gpio.concerto.m3.IPinOptions");
var IMuxOptions = xdc.module("trust.drivers.gpio.concerto.fm28h52c1.m3.IMuxOptions");
var PinProfile = xdc.useModule("trust.drivers.gpio.concerto.fm28h52c1.m3.PinProfile");

if (1==0) { 
  	PinProfile.Ports["PORT_J"] = null;
	print("we set PORT_J");
}
else {
  print("we did not set PORT_J");
}

var defaultPortsSettings = PinProfile.mapPortBitsToGpio();

for (var prop in defaultPortsSettings) {
   PinProfile.Ports[prop] = defaultPortsSettings[prop];
}
PinProfile.Ports["PORT_A"].bit0.isUsedInProfile = true;
PinProfile.Ports["PORT_A"].bit0.pin.owner = IPinOptions.PIN_OWNER_C28;
PinProfile.Ports["PORT_A"].bit0.mux = IMuxOptions.GPIO0_MUXVALUE_GPIO;
PinProfile.Ports["PORT_A"].bit0.pin.direction = IPinOptions.PIN_DIRECTION_MODE_HW;
PinProfile.Ports["PORT_A"].bit0.pin.pinType = IPinOptions.PIN_TYPE_STD;
.........much more......


Notice that the statement of "PinProfile.Ports["PORT_J"] = null;" does NOT get executed because of (1==0). But it's presence DOES influence how my form behaves.

In the screenshot PORT_J, you can see that the form items are enabled. In the PORT_H screenshot (as well as all other ports), they are disabled.

You can also see in the screenshots the console screen that prints that PORT_J was not set.

What is different? My best guess is that the .cfg file is compiled, and so PinProfile.Ports["PORT_J"] is represented differently than all the other ports without literal strings, which causes the disabling of the form object.

There really should be some sort of way to automatically set this stuff up programatically for the users of this module, and I have struck out trying to stick it inside my RTSC .xs file. Help???
  • Attachment: PORT_J.jpg
    (Size: 388.37KB, Downloaded 510 times)
  • Attachment: PORT_H.jpg
    (Size: 355.11KB, Downloaded 531 times)
Re: XGCONFIG disabling form input [message #964969 is a reply to message #958319] Tue, 30 October 2012 23:23 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
James,
I replicated the problem as reported in your first post, where the controls are grayed out if the init code is moved to module$meta$init. I don't know the cause yet, but I have some ideas that I am going to try.
I'll let you know when I make any new progress.

[Updated on: Wed, 31 October 2012 07:53]

Report message to a moderator

Re: XGCONFIG disabling form input [message #965952 is a reply to message #952697] Wed, 31 October 2012 16:39 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
Thanks, for looking at this. I was thinking I was on my own here. I have tried many things, and it only gets more confusing.

Yes, my CFG script is not located in the same package as the module PinProfile. For my case, it should not be. Any configuration will be project and board-specific, and I want to place all board-specific configurations in their own directory.

I think the effect of javascript "variable hoisting" may be playing a role here, where a side-effect sometimes will allow the Value$Map typed variable "PinProfile.Ports" to work as intended.

Please take a look at the following .cfg snippet.

var IPinOptions = xdc.module("trust.drivers.gpio.concerto.m3.IPinOptions");
var IMuxOptions = xdc.module("trust.drivers.gpio.concerto.fm28h52c1.m3.IMuxOptions");
var IPortBaseRegs = xdc.module('trust.drivers.gpio.concerto.fm28h52c1.m3.IPortBaseRegs');
var Port_A = "PORT_A";
var Port_B = "PORT_B"; 

// The following block of code for "if (1 == 0) {" will never get executed, yet affects the behavior of
// this .cfg script in different ways depending on:
//
// 	A) Whether the block is above the line "var PinProfile = xdc.useModule(......" or below
//                      AND
//      B) Whether the line 'PinProfile.Ports["PORT_B"] = "some...."' is commented or not.
//
// Here are the 4 scenarious and their effects of XGCONF for input:
//                                 PORT_A     PORT_B     PORT_C     PORT_D
// A - above, B - commented:       disabled   disabled   enabled    enabled
// A - above, B - uncommented:     disabled   disabled   disabled   disabled
// A - below, B - commented:       disabled   disabled   enabled    enabled
// A - below, B - uncommented:     disabled   enabled    enabled    enabled
if (1 == 0) {
	PinProfile.Ports["PORT_B"] = "some junk that never runs."
} 

var PinProfile = xdc.useModule("trust.drivers.gpio.concerto.fm28h52c1.m3.PinProfile");

PinProfile.Ports[Port_A] = new PinProfile.PortA;    // This will never be enabled on the form.
PinProfile.Ports[Port_B] = new PinProfile.PortB;
PinProfile.Ports["PORT_C"] = new PinProfile.PortC;
PinProfile.Ports["PORT_D"] = new PinProfile.PortD;

[Updated on: Wed, 31 October 2012 16:58]

Report message to a moderator

Re: XGCONFIG disabling form input [message #965973 is a reply to message #965952] Wed, 31 October 2012 16:56 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
I just tried it, and the placement of the above .cfg script into the same directory as my PinProfile module makes no difference.
Re: XGCONFIG disabling form input [message #974071 is a reply to message #965973] Tue, 06 November 2012 20:59 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
James,
from your observations, and from what I am seeing in my example, it's clear that the script is being processed to determine which values on the GUI can be changed. However, the processing I am talking about is not the actual processing in the context of the RTSC configuration, but only simple parsing to determine referenced objects. Statements that do not reference any variables are ignored, even if they define the logical flow. The referenced objects are then enabled in the GUI.
Your fourth case, "A - below, B - uncommented" is an example of the script where PinProfile is defined first, and then PinProfile.Ports["PORT_B"] is referenced, which makes PORT_B enabled. PORT_C and PORT_D are always enabled, except in the case "A - above, B - uncommented", which is an invalid script, and everything is disabled. In other two cases, PORT_B is never referenced, so it's disabled.

This is obviously not how we want the GUI to work. I think I have now enough info to go to the GUI team and check if there is a simple fix for what we are seeing, or we are trying to use functionality that is not implemented yet. I'll check your latest post now to check if your findings there are consistent with this explanation.
Re: XGCONFIG disabling form input [message #976557 is a reply to message #952697] Thu, 08 November 2012 17:18 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
Hi Sasha,

I just wanted to respond to convey that I am still affected by this, need this to behave properly, and am near the end of my ability to debug effectively.

I will patiently wait for a solution. Please update with progress as appropriate to keep me informed.

Thank you,
James Lockwood
Re: XGCONFIG disabling form input [message #997105 is a reply to message #952697] Thu, 03 January 2013 17:53 Go to previous messageGo to next message
James Lockwood is currently offline James LockwoodFriend
Messages: 43
Registered: July 2009
Member
Has there been any progress on this?

I have another similar issue I ran across that is related. The form/instance will not show up in the outline window without the hack of the if (1 == 0) and specifying the actual string of the module.

var FileMappings = xdc.useModule('trust.utils.FileMappings');
FileMappings.deviceName = "F28M35H52C1";
FileMappings.cpuName = "M3";

if (1 == 0) {  // this is a hack to allow the form to be visible.  
    var GpioConfig = xdc.useModule('trust.drivers.gpio.concerto.f28m35h52c1.m3.GpioConfig');
}
else {  // FileMappings will select the appropriate module based upon the settings of deviceName and cpuName.
		// It will also mark the module as being used, so an automatically created header file can be included in the application.
	var GpioConfig = FileMappings.useModule('GpioConfig');
}
Re: XGCONFIG disabling form input [message #997148 is a reply to message #997105] Fri, 04 January 2013 00:46 Go to previous message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 115
Registered: July 2009
Senior Member
James,
I haven't had much time recently to make any progress. I got some responses from the developers who work on that code, but I haven't tried them yet. I hope to get to it soon.
Previous Topic:Property params of the build target was not copied to the config object model
Next Topic:Using xdc with VS2008 - problems
Goto Forum:
  


Current Time: Fri Oct 04 15:18:48 GMT 2024

Powered by FUDForum. Page generated in 0.03244 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top