getopenmono / monoprog Goto Github PK

When monoprog searches for a connected Mono device, it has a default timeout before giving up. Say, you run monoprog -d without a Mono connected, the request will fail after approx. 6 secs.

I would like a way to configure this timeout using a command line switch. We can use -t, --timeout [MSECS]. Here we provide how many milliseconds monoprog should search for a connected mono, before giving up.

$ monoprog -d -t 500
..
Mono device not detected on USB ports.

By providing -t 500 we we instruct monoprog to abort the detection of a device after 500 ms. I know that monoprog searches for both for Mono's bootloader (a HID) and for Mono Serial Port (a CDC). I suggest we use the timeout -t for both processes (HID and CDC detect) - giving them each the same timeout. This effectively sets the total timeout to be 2xt.

This feature is useful for our coming GUI app, that continuously queries monoprog for the state of connected devices.

To use monoprog from our coming GUI app, it would be nice with a command line switch for headless mode. I suggest we use the switch --headless. Headless mode is primarily needed in 2 scenarios:

1. Progress feedback when programming

A call like:

$ monoprog --headless -p myApp.elf
1%
3%
5%

Instead of returning dots (....) monoprog returns the percentage, that can be parsed by a GUI client. The percentage should only be returned when the programming actually has started. If no Mono is connected, the execution should just terminate with a non zero error code.

2. Keyword feedback on detection

When detecting a connected Mono and its current state, headless mode should just return one of 2 keywords: bootloader or app. If no Mono could be found monoprog should just terminate with a non zero error code.

A case where we have a Mono connected and running an app, monoprog should:

$ monoprog --headless -d
app

This change will make it easy for a GUI to display a progress bar when programming an app to Mono, and to easily parse detection responses.

Issue

monoprog does not support space in the path to the ELF file to be programmed. If you run a command like this:

$ monoprog -p "/path/with spaces/program.elf"
File does not exist: /path/with

Escaping spaces like this: /path/with\ spaces/program.elf has no effect.

I know spaces in paths are hated (by some), but I expect that our users might have them.

Suggestion

The command line parser should be able to understand the convention that " " surround paths with spaces. Before expecting next argument, it must match the "