Instead of having a separate mode, what about keeping the runtime (and satellite manager) responsive at all times to commands typed on the UART? This would be useful for running JESD tests as well.

Sure.

It may not play nice with logs though (e.g. if a log message is emitted because a TCP connection is received while the user was in the middle of typing a command). I suppose that an interface like irssi (that requires terminal control codes) would be a mess, especially for Windows users...

@sbourdeauducq does it have to be on serial specifically? If yes, we can make it modal: press Enter to suppress logs and enter commands, press ^D (that's ^Z on Windows) to return.

Serial is nice because it's robust and easily available. This "modal" design sounds like an acceptable compromise.

Why is this now labeled type:for-contract? It's a feature that was funded by NIST for ARTIQ v1.0.

Maintaining features takes work, especially when there are major code modifications or rewrites, like those involved in the ARTIQ-3 runtime. The test mode was not explicitly funded by NIST, it's just something that I had done mostly to have a way to access DDSes at a low-level; back then the ARTIQ-Python compiler was not as powerful and some of the DDS logic had to be done in C and built into the runtime. With ARTIQ-3, DDSes are exposed at a low level from kernels, which makes test mode pretty redundant.

You can use moninj for simple LED/IO toggle tests.

OK. That makes sense. Thanks for the explanation. And yes, moninj is useful for those toggle tests. :)

The workflow we have for bringing up new systems is:

1. set IP and MAC using artiq_mkfs and artiq_flash
2. perform a full system test using a kernel such as https://github.com/m-labs/artiq/blob/master/artiq/examples/kasli_basic/repository/kasli_tester.py

The tester experiment is more powerful, easier to maintain, and much more user-friendly than the test mode; and setting IP/MAC over JTAG is an acceptable alternative IMO.

I'll give it a try. Thanks!