How to communicate serial port data in sub-window?

Python Help
1

How to create a sub-window that communicates with any serial port within a main-window

If any one have idea about the sub-window that communicates port?

2

It is completely unclear what you want to do.

  • What are those mysterious windows: a “sub-window”, a “main-window”?
  • What does a serial port have in common with those windows?
  • How does it relate at all to Python?

If you have a Python code we can help with, show it please.

3

Here i am trying to explain my system :
I am using an embedded controller board , having a serial port ; It is streaming messages on to the serial port , which has been connected to this host computer ; The user interface i am writing in Python GUI ; The streamed messages from the serial port i am displaying in the Python developed GUI sub- window .
If the above is not clear . i would like to explain more . Please let me know.

4

“Python GUI” is not a specific thing. I do no know what do you mean by that.

To develop a GUI application you usually use one of available GUI frameworks. This framework may impose certain ways of organizing data and control flow of your application.

Show the framework you use, the structure of the application, ideally the source code and maybe someone will be able to help you.

I have minimal experience with developing GUI applications so I will not probably help you.

5

By rasheed via Discussions on Python.org at 08Jul2022 09:49:

Here i am trying to explain my system :
I am using an embedded controller board , having a serial port ; It is
streaming messages on to the serial port , which has been connected to
this host computer ; The user interface i am writing in Python GUI ;
The streamed messages from the serial port i am displaying in the
Python developed GUI sub- window .

Ok. In my opinion you need to do the following:

  • have a worker Thread which is reading from the serial port; this is
    required because the controller is streaming data to your process and
    something needs to consume it which is not blocked by other tasks
    (like running the GUI or waiting for user input)
  • have a GUI window to display whatever is supposed to be displayed
  • have an event callback which updates the GUI window

The GUI window might be a text box of some kind if your controller is
sending text (or stuff you can simply describe as text), or it might be
something more complex. How you do that depends on the particular Python
GUI toolket you’re using (eg tkinter or PyQT etc).

The reason for the event callback is that GUI updates need to happen in
the main GUI event loop, as GUI toolkits are generally not thread safe.
When you fire an “event” from your monitoring thread, it is placed in a
queue data structure by the GUI, and processed linearly in the main loop
as it groinds through that queue. Thus avoiding concurrent access to the
GUI’s data structures.

So never make GUI calls from a different thread, unless it is the call
to submit an event.

I would implement this progressively myself:

  • write the controller monitor function, and have it just print stuff to
    the output using print(); run that and get it working
  • write a simple GUI which include making the subwindow, and display
    some stuff in that subwindow (not from the controller)
  • write the event callback, register it, and send some things to it (not
    from the monitor) - events containing example controller data
  • write the code to dispatch the monitor thread
  • modify the monitor thread by replacing the print() calls with calls
    to queue events with whatever data is needed to be displays

Dispatching a thread is pretty simple. Crude sketch:

from threading import Thread

def monitor(serial_port):
    ... read from the serial port, print() interesting stuff ...

... main programme ...
T = Thread(monitor, args=(your_serial_port,), daemon=True)
T.start()
... main programme continues here ...

The daemon=True specifies that when your main programme quits, the
Python interpreter should not hang around waiting for the thread. You
will probably want that in your GUI. If you end up doing stateful stuff
with the controller later you might want to do a more orderly shutdown,
in which case you don’t want the thread to be a “daemon” - instead
you’re indicate to it that it is shutdown time, which it should notice,
and you’d have the main programme end sequence: notify the monitor, then
wait for the thread. But that is a topic for later.

Cheers,
Cameron Simpson cs@cskk.id.au