Serial Monitor Deluxe 0.1 announcement

Robin2:
I've now tried to load your project into Lazarus and there seem to be 2 pieces missing
etpackage
SdpoSerialLaz

I'm using Lazarus v1.0.10

...R

Ah yes. Those are "packages" - extra components you can download and install into your Lazarus. Or, more accurately, you unpack and tell Lazarus to re-compile itself with the new addition :slight_smile:

I do wonder why etpackage is mentioned though, it belongs to a timer component that I'm quite sure I didn't use...

Here's how to install packages:
http://wiki.freepascal.org/Install_Packages

The Serial component is here:

That mysterious timer component:

Quite a mess, huh?

Thanks. I will try that later.

...R

Learn Python !

i got those packages installed and I was able to compile your program, and it seemed to work - but obviously could not access my serial ports.

Alas, I think I may have given up.

Contrast these instructions for accessing Linux serial ports

Using ioperm to access ports on Linux

The best way to access the hardware on Linux is through device drivers, but, due to the complexity of the task of creating a driver, sometimes a quick method is very useful.

In order to use the "ports" unit under Linux your program must be run as root, and IOPerm must be called to set appropriate permissions on the port access. You can find documentation about the "ports" unit here.

The first thing to do is link to (g)libc and call IOPerm. A unit that links to the entire (g)libc exists on free pascal, but this unit gives problems when used directly by application and linking statically to the entire (g)libc library is not a very good idea because it changes often between version in an incompatible manner. Functions like ioperm, however, are unlikely to change.

{$IFDEF Linux}
function ioperm(from: Cardinal; num: Cardinal; turn_on: Integer): Integer; cdecl; external 'libc';
{$ENDIF}

"from" represents the first port to be accessed.
"num" is the number of ports after the first to be accessed, so ioperm($220, 8, 1) will give access for the program for all ports between and including $220 and $227.

After linking to IOPerm you can port[] to access the ports.

{$IFDEF Linux}
i := ioperm($220, 8, 1);
port[$220] := $00;
myLabel.Caption := 'ioperm: ' + IntToStr(i);
i := Integer(port[$220]);
myOtherLabel.Caption := 'response: ' + IntToStr(i);
{$ENDIF}

With the following, which is the total Python coded needed to get a list of serial ports on all 3 platforms

def listSerialPorts():
	# http://stackoverflow.com/questions/12090503/listing-available-com-ports-with-python
	
    """Lists serial ports

    :raises EnvironmentError:
        On unsupported or unknown platforms
    :returns:
        A list of available serial ports
    """
    if sys.platform.startswith('win'):
        ports = ['COM' + str(i + 1) for i in range(256)]

    elif sys.platform.startswith('linux') or sys.platform.startswith('cygwin'):
        # this is to exclude your current terminal "/dev/tty"
        ports = glob.glob('/dev/tty[A-Za-z]*')

    elif sys.platform.startswith('darwin'):
        ports = glob.glob('/dev/tty.*')

    else:
        raise EnvironmentError('Unsupported platform')

    result = []
    for port in ports:
        try:
            s = serial.Serial(port)
            s.close()
            result.append(port)
        except (OSError, serial.SerialException):
            pass
    return result

...R

Robin2:
Contrast these instructions for accessing Linux serial ports

With the following, which is the total Python coded needed to get a list of serial ports on all 3 platforms

Now now, let's not jump to conclusions... :smiley:

I agree that some tasks take a lot less code in Python (i.e. code that YOU write, anyway), but that may have a cost in performance and resources. That's for the general case.

Specifically about the ports - can I assume that Linux exposes only the devices (/dev/tty.*) that are currently available? If so, I can quite easily check for their existence and essentially do the same thing I did with the Windows registry, in no more than a few extra lines of code.

igendel:
Specifically about the ports - can I assume that Linux exposes only the devices (/dev/tty.*) that are currently available? If so, I can quite easily check for their existence and essentially do the same thing I did with the Windows registry, in no more than a few extra lines of code.

When I plug in my Arduino it shows up in the Arduino serial monitor as /dev/ttyS80 and /dev/ttyACM0

I don't know enough about Linux to know why it shows up twice or whether it is "exposing the devices that are currently available"

Serial ports are only listed occasionally - it would not worry me if the code to do that was a bit slow. :slight_smile:

...R

Okay. I'll have a look at how Debian on my Beaglebone Black behaves, hopefully I can find something useful that will be applicable to less exotic platforms as well.

I have some got news and some bad news...

As I suspected earlier, Linux does expose the available ports as devices ("/dev/ttyUSBn") and removes then when they are disconnected, so in theory I can perform a simple "file search" in code for these, once every couple of seconds, and detect the available ports.

However, the Beaglebone Black doesn't have enough resources to re-compile the entire Lazarus with the required components... so I can't test my own code :fearful:

There may be some crazy way to do cross-compilations or other tricks, but I couldn't find it and frankly, these issues become irritating at an exponential rate. In short, a Linux version of Serial Monitor Deluxe seems further now than it did before.

Can it run in Wine? An easy fix for Linux until it can be compiled.

pYro_65:
Can it run in Wine? An easy fix for Linux until it can be compiled.

I have no way of trying...
The program talks to an external hardware device, and from the little I know these can be tricky on Wine.

It might run with Wine but I tried Wine a while back and got fed up with it - never again.

When I get my present project finished I might plagiarize your design and build a Python version.

...R

Robin2:
When I get my present project finished I might plagiarize your design and build a Python version.

Heh, that sounds almost like a challenge :wink:
It will take me some time to master Python and Python GUI enough for this, so... feel free :slight_smile:

Thinking more about this, why do you need to use your BealeBone to compile the Linux version. Can't you make a Linux version on a Windows PC and vice versa?

This business of multi-platform development is one of my hobby-horses. It should not be necessary to develop a program on the target device - though I accept that you need the target for testing.

As far as I know the Python code in this demo (which was written on Linux) will work on Windows.
And I know (because I did some testing) that a program that works on the JVM will run on another PC as long as it has the JVM installed.

I was wondering about a Python development system called Kivy which claims to be cross-platform. But it can only package Windows apps on a Windows machine which is not much use.

...R

Robin2:
Thinking more about this, why do you need to use your BealeBone to compile the Linux version. Can't you make a Linux version on a Windows PC and vice versa?

This business of multi-platform development is one of my hobby-horses. It should not be necessary to develop a program on the target device - though I accept that you need the target for testing.

That's exactly the issue. I may be able to cross-compile from Windows, but because the Linux version will have some code that's not in the Windows version, testing and debugging a program this way will be slow and painful.

igendel:
but because the Linux version will have some code that's not in the Windows version,

The nice thing about Java (and Python as far as I can see) is that those variations are hidden within the JVM and the Python implementation. I had assumed that the Pascal P-code served the same function.

...R

Robin2:
The nice thing about Java (and Python as far as I can see) is that those variations are hidden within the JVM and the Python implementation. I had assumed that the Pascal P-code served the same function.

...R

No, Free Pascal compiles to 100% native exectables. Many components, libraries etc. are OS-aware so you don't have to change too much in your source code, but when you have to do something OS-specific, like reading from the Windows Registry or /dev, and there's no existing library to encapsulate it, you have to code all the alternatives yourself.

igendel:
Free Pascal compiles to 100% native exectables.

Silly idea IMHO

...R

Robin2:
Silly idea IMHO

There are many factors that come into play when determining the silliness of an approach... native, bytecode, interpreted all have their proper contexts and uses. For Pascal, I think the easiest answer would be that it was simply born too early to be anything else :grinning:

Sorry for derailing the introduction of your very useful product. I did set out with the best of intentions to help make it available to Linux users.

...R

Robin2:
Sorry for derailing the introduction of your very useful product. I did set out with the best of intentions to help make it available to Linux users.

...R

On the contrary, it keeps this thread alive ;D
I haven't said the last word about my program and Linux - it'll just take longer than I thought...