test mode support via serial interface

[jbqubit]

Runtime test mode via serial command line interface is missing since adoption of rust. Do we want it back?

Summary of discussion started in #643...
@jordens "Test mode was removed in the move to rust. I did like it and miss it as well but it was a bit tedious to maintain and hard to test itself."
@whitequark "We can bring back test mode if there's enough interest, there's no fundamental reason for its removal."
@jbqubit "I've found the Test Mode useful in a number of circumstances and would miss its absence. This is in part a result of familiarity with that path for configuring MAC/IP and doing simple LED/IO toggle tests. I can see that openocd is a clear alternate path for setting MAC/IP." See #643 for example code.

[sbourdeauducq]

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.

[whitequark]

Sure.

[sbourdeauducq]

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...

[whitequark]

@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.

[sbourdeauducq]

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

[jbqubit]

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

[sbourdeauducq]

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.

[jbqubit]

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

[sbourdeauducq]

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.

[jbqubit]

I'll give it a try. Thanks!