Allow connections to individual ports in port arrays.

[brlarson]

In section 9.2:

The most prominent use case is GPIO pins that look like a port array on the microcontroller side, but may be attached individually to drive LED or read switches, or collectively such as a bi-directional byte with handshakes.

Grammatically, this would require adding (optional) [ [ array_index_literal ] ] after *_port_identifier in port_connection_reference. Only literals would be allowed--not properties or property constants--though I could see how some might want to specify which GPIO port is used for what indirectly.

Lutz said that there was some difficulty in augmenting the grammar, and that the Graphical Editor could not be updated at this time, and suggested using the Connection_Set property instead of changing the grammar.

[lwrage]

To support this we can use the Connection_Set property. As it's a record we could interpret a missing src (or dst) field as the source (or destination) being a feature that is not an array.

[brlarson]

I've never used Connection_Set. Please provide a small example which connects ports in a port array to single port.

On Oct 15, 2021, at 7:59 AM, Lutz Wrage @.**@.>> wrote:

This email originated from outside of K-State.

To support this we can use the Connection_Set property. As it's a record we could interpret a missing src (or dst) field as the source (or destination) being a feature that is not an array.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/saeaadl/aadlv2.2/issues/71#issuecomment-944276898, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJC32Q5MRTUMTR32Z5TNPLUHAQR7ANCNFSM5EPOOBSQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[lwrage]

Here's an example of what this can look like

package P1
public
    system S
    end S;

    system implementation S.i
        subcomponents
            d: device D;
            s: system Sub;
        connections
            c11: port D.gpio -> s.d1 {
                    Connection_Set => ([src => (1);]);
                };
            c12: port s.d1 -> D.gpio {
                    Connection_Set => ([dst => (1);]);
                };
            c21: port D.gpio -> s.d2 {
                    Connection_Set => ([src => (2);]);
                };
            c22: port s.d2 -> D.gpio {
                    Connection_Set => ([dst => (2);]);
                };
    end S.i;

    device D
        features
            gpio: in out data port [2];
    end D;

    system Sub
        features
            d1: in out data port;
            d2: in out data port;
    end Sub;

end P1;

This actually works in OSATE, already. The instance model has the expected connection instances. However, there are two incorrect error markers created on the connection instances that have gpio as the destination.

Note that I am not sure that the standard is clear on whether this is legal or not.

[brlarson]

Lutz,

Yes, that will do what's needed.

The syntax is clumsy, but generating analyzable models is most important.

I will save this note for when I need to use it, but there should be some way to alert others. Is there a place in OSATE help which could include this information?

--Brian

On Oct 19, 2021, at 9:30 AM, Lutz Wrage @.**@.>> wrote:

This email originated from outside of K-State.

Here's an example of what this can look like

package P1 public system S end S;

    system implementation S.i
            subcomponents
                    d: device D;
                    s: system Sub;
            connections
                    c11: port D.gpio -> s.d1 {
                                    Connection_Set => ([src => (1);]);
                            };
                    c12: port s.d1 -> D.gpio {
                                    Connection_Set => ([dst => (1);]);
                            };
                    c21: port D.gpio -> s.d2 {
                                    Connection_Set => ([src => (2);]);
                            };
                    c22: port s.d2 -> D.gpio {
                                    Connection_Set => ([dst => (2);]);
                            };
    end S.i;

    device D
            features
                    gpio: in out data port [2];
    end D;

    system Sub
            features
                    d1: in out data port;
                    d2: in out data port;
    end Sub;

end P1;

This actually works in OSATE, already. The instance model has the expected connection instances. However, there are two incorrect error markers created on the connection instances that have gpio as the destination.

Note that I am not sure that the standard is clear on whether this is legal or not.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/saeaadl/aadlv2.2/issues/71#issuecomment-946783666, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAJC32SO524WV6NEJWRIIADUHV6GXANCNFSM5EPOOBSQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.