|
|
Re: XGCONFIG disabling form input [message #958319 is a reply to message #952697] |
Thu, 25 October 2012 23:17 |
James Lockwood 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 #965952 is a reply to message #952697] |
Wed, 31 October 2012 16:39 |
James Lockwood 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 #974071 is a reply to message #965973] |
Tue, 06 November 2012 20:59 |
Sasha Slijepcevic 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.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03244 seconds