Implement serial interface

[Peque]

The serial interface should implement the three methods in SerialInterface class.

• __init__: I would suggest you to hard-code your serial initialization code there. I would suggest you to hard-code your settings and we will think about how to connect to other targets when we need it (i.e.: maybe we could list available targets and let the user choose, or load preferred targets from a local config file, or add a command line option...)
• send: your code to send a message (assumed previously formatted) through serial.
• receive: reads up to N bytes from the serial port (I set it to 1024 in my Bluetooth interface). It has a timeout (I set it to 10 ms). So basically, read raw bytes and avoid blocking here. I am assuming you can do that with the serial module you use.

[Peque]

@micromouseonline Tell me if you find any issues!

Code is dirty and not documented (don't have much time, so I basically trimmed my original code).

We can slowly improve it and clean it as needed. 😇

[micromouseonline]

Miniterm seems to use a reasonable model for handling connection settings. Command line or give the user a menu if not provided.

At present, I Have a class, SerialThread, that inherits from QThread. It places complete lines of text into a queue.

The main code uses QTimer to periodically read the queue and process all the lines in it.

Use of the Qt5 framework is a fundamental design choice. Am I correct in assuming this is appropriate? After all, I think PyQtGraph is likely to be the better option for visualisation tasks.

[Peque]

I started this as a CLI, but it probably makes sense to create a GUI.

Using Qt5 is a good choice (with PySide2, now known as "Qt for Python"). Using Qt allows us to integrate PyQtGraph in the GUI when we need to.

[micromouseonline]

[replied by email to see the difference from working on github directly] Perhaps the basic tool should implement a CLI in a Qt Application window. Would you prefer all in one window like a terminal or a window for responses and a separate text entry box - like the Arduino serial monitor? — Peter Harrison peter.harrison@helicron.net

…

On 9 Dec 2019, at 22:58, Miguel Sánchez de León Peque ***@***.***> wrote: I started this as a CLI, but it probably makes sense to create a GUI. Using Qt5 is a good choice (with PySide2, now known as "Qt for Python"). Using Qt allows us to integrate PyQtGraph in the GUI when we need to. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Peque]

I think I would prefer a terminal. But I do not mind. So go with whatever you prefer or is easier to implement. 😊

[micromouseonline]

OK I need to finish the timing gate stuff first. That will give me some practice with the Python side as well. — Peter Harrison peter.harrison@helicron.net

…

On 9 Dec 2019, at 23:11, Miguel Sánchez de León Peque ***@***.***> wrote: I think I would prefer a terminal. But I do not mind. So go with whatever you prefer or is easier to implement. 😊 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Peque]

By the way, a terminal is already implemented in the current mmconsole.py script. Maybe we can wait to implement a GUI until we need GUI features (like plotting sensors data or allowing for easy one-click selection of a Bluetooth/serial device).

Just to simplify things until we have some basic stuff working.

[micromouseonline]

To simplify things, we should strip as many dependencies as possible from mmconsole. I mean osbrain of course :) Plain text is all we need right now. The comms class(es) should just get and deliver complete lines without the rest of the code knowing how it is done. — Peter Harrison peter.harrison@helicron.net

…

On 10 Dec 2019, at 23:39, Miguel Sánchez de León Peque ***@***.***> wrote: By the way, a terminal is already implemented in the current mmconsole.py script. Maybe we can wait to implement a GUI until we need GUI features (like plotting sensors data or allowing for easy one-click selection of a Bluetooth/serial device). Just to simplify things until we have some basic stuff working. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Peque]

Getting rid of dependencies does not mean simpler code in my opinion. Libraries were meant to be used! Not defending osBrain dependency in particular, but your "less dependencies is simpler" statement may not apply for Python and non-embedded systems. I would rather spend a couple of seconds adding an import rather than (re)implementing some code somebody else has implemented before, even at the cost of a couple MiB of storage in dependencies. 😜

I think shorter is simpler. If osBrain dependency makes you feel uncomfortable, I am of course willing to get rid of it if you want to come up with an alternative implementation (i.e.: using threads or asyncio).

Why should comm classes deliver complete lines? We currently have two comm cases: serial and bluetooth. They work the same way: they read bytes from a stream. So we can share the code that transforms a stream of bytes into complete lines, don't you think so? I do not mind if you want to refactor the classes any way you want though. As long as there is no duplicated code I am fine.

Note that, in general, I just want to make things work with the first implementation that comes to my mind (complying with the requirements of course). I am assuming changes will be required at some point (AKA refactoring), but that is always the case, even if you spend a lot of time thinking about the implementation. So basically, if you want to refactor code (remove dependencies, split classes or modules...), just go ahead and open a PR. 💪 I think it is easier to discuss over code than over abstract ideas.

If PR changes mean less lines of code or reduced cyclomatic complexity, I would almost always agree with the changes. If they mean more lines of code, but result in better compliance with the requirements (i.e.: missing feature or bug), then unless I can immediately suggest a better implementation, I would also agree with the changes. 😊

[micromouseonline]

Yes, I was not clear and did not think it all through very well. Clearly, dependencies and library imports do not intrinsically make a project or application more complex. It would, for instance, be very foolish to try and rewrite the functionality of pyQtGraph. To my mind, the osBrain stuff does not make sense to me. It does not appear to add to the functionality and instead obscures the code. The question I ask when I see classes and code sections is "what is this contributing?" and I get no answer for that part of the code. Also, I was not clear about the comms stuff. The physical connection will, of course, deal in streams of characters. They could come from any device or service. For the point of view of the higher levels though, the unit of communication is the line, the message in fact. Thus I think there should be a single point of access for sending and receiving lines. Your Proxy class seems to do that but does not appear to need to subclass Agent. And, what is it doing asking for battery voltages? I am pretty well tied up with the timing gate stuff at present but I will begin to contribute where I can once that is mostly behind me. I have a terrible habit of fragmenting attention between too many projects and I don't want to lose momentum on the timing system. — Peter Harrison peter.harrison@helicron.net

…

On 11 Dec 2019, at 01:36, Miguel Sánchez de León Peque ***@***.***> wrote: Getting rid of dependencies does not mean simpler code in my opinion. Libraries were meant to be used! Not defending osBrain dependency in particular, but your "less dependencies is simpler" statement may not apply for Python and not-embedded systems. I would rather spend a couple of seconds adding an import rather than (re)implementing some code somebody else has done before, even at the cost of a couple MiB of storage in dependencies. 😜 I think shorter is simpler. If osBrain dependency makes you feel uncomfortable, I am of course willing to get rid of it if you want to come up with an alternative implementation (i.e.: using threads or asyncio). Why should comm classes deliver complete lines? We currently have two comm cases: serial and bluetooth. They work the same way: they read bytes from a stream. So we can share the code that transforms a stream of bytes into complete lines, don't you think so? I do not mind if you want to refactor the classes any way you want though. As long as there is no duplicated code I am fine. Note that, in general, I just want to make things work with the first implementation that comes to my mind (complying with the requirements of course). I am assuming changes will be required at some point (AKA refactoring), but that is always the case, even if you spend a lot of time thinking about the implementation. So basically, if you want to refactor code (remove dependencies, split classes or modules...), just go ahead and open a PR. 💪 I think it is easier to discuss over code than over abstract ideas. If PR changes mean less lines of code or reduced cyclomatic complexity, I would almost always agree with the changes. 😊 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Peque]

Sure! You should concentrate on the timing gate. 😊 Plus, I am also busy with other things and will probably find little time to work on this in the short term. 😅

Yeah, we could probably replace Agent with any asyncio/multithreading stuff, no problem. With any class/function refactoring needed.

The battery stuff is a vestige of the previous implementation. When you write >>> battery in the console, it sends "batery\0" to the mouse. My mouse processes that request and sends back a reply. The reply should be like 1234,process,REPLY,3.7 (in the format we talked about). There should be a handler to associate with the battery-reply logs (i.e.: to print the voltage value), but there are none. The current "handlers" just push received logs into 2 separate lists: raw_log (where messages are appended as received; as strings) and log (where messages are appended as tuples). You can access those from the console with >>> log and >>> log raw.

We still need to agree upon the format of the requests sent to the mouse. "battery\0" is just what I had before.

In order to connect to the target, from the console, you also need to start by >>> connect serial (not implemented). In my case, it is >>> connect bluetooth, which is implemented. You can run >>> help in the console to see available commands.