Multiple Simultaneous Applets

[gregdavill]

For a hardware project I'm working on now I'm using both the Glasgow as a UART pty and a separate basic FTDI breakout for JTAG.

I see potential for having both a JTAG and UART interface when debugging a target.
Or having two UARTs one for a CLI and another for Embedded Logic analyses in SoC designs.
From a hardware perspective there isn't any reason why Glasgow couldn't theoretically handle this.

But I'm not sure what that would look like from the software side, and the command line side.

I understand this feature may be impractical to support in a general sense, but do you think it may be possible for some subset of cases? Like Applet.* + UART?

[whitequark]

I understand this feature may be impractical to support in a general sense, but do you think it may be possible for some subset of cases?

I think it is, in principle, practical to support in general, and in fact, I have aimed to do so from the very beginning. It's been one of the design goals!

But I'm not sure what that would look like from the software side,

This one is easy: you simply build/run multiple applets. I've never actually tried it, but none of the applet APIs assume that there is only one applet; there can be any amount of submodules in the target, and asyncio takes care of concurrency inherent to multiple applets.

and the command line side.

Here... I'm not sure either, which is precisely why it isn't yet implemented.

Let's brainstorm CLI ideas in this issue?

[gregdavill]

Brainstorming sounds like a good idea.

One idea, which I think could work in practice, but may be not very elegant.
The initial command which creates the multiple applets, also creates a server, each applet gets a socket or pipe interface.

In separate terminals each applet can run in a "client" mode which connects to the server to interact with the hardware. Kind of like how litex_server operates.

[whitequark]

One problem is that currently applet code assumes that build/run state is one and same, and that's pretty well baked in. So these "clients" would have to be thin clients, perhaps reduced to passing the terminal fds and cwd through that socket.

But I think I could do that.

[whitequark]

That still leaves open a question of how to specify multiple applets on the CLI invocation of the server.

[gregdavill]

You could just specify run multiple times?

glasgow run uart --pin-rx 1 --pin-tx 0 -V 3.3 -b 115200 pty run uart --pin-rx 2 --pin-tx 3 -b 115200 pty

[whitequark]

I think you can't do that with argparse. Imagine what would happen if pty took a filename.

[gregdavill]

Turn each command into a string?

glasgow run "uart --pin-rx 1 --pin-tx 0 -V 3.3 -b 115200 pty" "uart --pin-rx 2 --pin-tx 3 -b 115200 pty"

So argparse just sees two strings? This gets ugly when filenames are required and strings need to be escaped.

Or adding a new command:

glasgow run-multiple

That drops you into a REPL or other interactive console that enabled you to add interfaces then run. If this is the path this feature heads down, it would be possible to show recently used interface combinations.

[whitequark]

I think a guard argument can be done:

glasgow run-multiple uart --pin-rx 1 --pin-tx 0 -V 3.3 -b 115200 pty -- uart --pin-rx 2 --pin-tx 3 -b 115200 pty

Still kind of ugly though.

[alexhude]

+1
run-multiple with -- guard argument is pretty straight forward, I vote for that :)

[andresmanelli]

Hello, what about a config file? I see it like a "glasgow compose" file

glasgow run -f config.?

[whitequark]

what about a config file?

I don't know what a good syntax would be, and worse, currently the frontend is very closely tied to argparse.

[RX14]

Would it be possible to have the interface be to run glasgow multiple times in multiple terminals and have that be handled gracefully? Then the server/daemon would be configured over some form of IPC?

[whitequark]

Would it be possible to have the interface be to run glasgow multiple times in multiple terminals and have that be handled gracefully?

Not really, since there's no partial reconfiguration possible on iCE40.

[alexhude]

I think config file should be an alternative to command arguments, not a replacement. Therefore run-multiple with guard or something similar should also exist.