Lazarus 1.9 trunk Qt4 and Qt5 interface (screenshots)

A new version of plugins will be coming soon:
1

6 Likes

Since the previous time I tested with the software on Haiku, I have added some port flushing/purging commands in the code for a specific RS232C connection. While creating screenshots yesterday I ran into trouble since these are not yet implemented in the updated termios download (the missing functions). I am going to attempt to add them en get them working in my software. I’ll let you know and add a new download by then. Still, this should be pushed into the official codebase for FPC/Lazarus by someone…

screenshot1 screenshot2

The first screenshots… :slight_smile:

So all the data shown on the chromatogram are calculated ‘real time’ when loading the file: it’s not saved data that’s just shown. Oh, and some integration debugging helper graphs are shown, normally they are hidden (grey graphs, vertical dotted lines).

6 Likes

Fixed. QtHaikuPlugins updated.
Update packages and try again.

5 Likes

Updated to href54052, also updated the Qt package. I confirm the problem is solved designtime, and runtime. Thank you very much! That was quick… :slight_smile:

1 Like

So, I did some tests with an updated termiosproc.inc but it seems I have a problem: while configuring the ports baudrate etc works by more or less directly calling the respective routines in that file, things like sending breaks, purging and flushing works trough another mechanism I don’t fully grasp yet.
All in all it would be needed I expect that I just dump this file in place of the original one, and recompile FPC/Lazarus.
On Windows, this is no problem: but on Haiku it -is-. Since we have the read-only filesystem in place…

If someone knows how to circumvent this in a rather straightforward and both simple way, I’d love to learn this.
The other route would be to use fpcupdeluxe on Haiku to download all sources and build FPC/Lazarus since it does it in the home folder. That way, I can do it like on windows: just overwrite the file afterwards, and let fpcupdeluxe recompile.

Unfortunately I can’t get fpcupdeluxe going. While the executable runs (so no Qt problems), and I can manage to install subversion (which it complains about), I cannot simply solve problems like failing ‘make’ since no targets (recipes) are defined for x64 (or something like that, I’d have to look up the exact messages).

I tried different source versions etc, but alas, nogo.

It would be super if someone (s40in?) updates fpcupdeluxe where needed, or even create a hpkg for it, so it ‘automatically’ can solve dependancies: while in the end leaving me with the option to overwrite source files and rebuild FPC/Lazarus with it.

That way I have a working chance solving these kinds of issues, otherwise, well, I’m stuck.
I have a partial workaround though: leaving the .inc files inside my project, accepting that I cannot use the FP_IOCntl() functions in there and so comment out all flow-control related serial port commands in my project (thereby making that project less stable since I have things like flooding-prevention built in normally).

Hoping that someone can help out here… If so, I would be very gratefull :wink:

1 Like

All in all results are promising. The application is fully functional apart from a few things:

  • Serial or USB-serial port flush/purge due to outdated termio.inc and termioproc.inc in Lazarus/FPC. I use adapted Synaser to succesfully use both hardware serial and usb serial connections apart from purge/flush yet. Serial and serial USB would not work at all without my patches BTW;
  • TCP/IP not up yet (Indy 10 issues);
  • Missing hardware watchdog support. I have it running on Linux ARM/Intel via the existing subsystem there by directly loading the driver (posix), on Windows x86/x64 (XP…Windows 10) I have written my own drivers which work nicely also (via a specially written/maintained DLL for this purpose). Would be cool if Haiku would have the linux watchdog subsystem… (watchdog is used to reboot system in case the software malfunctions, in order to guarantee ‘up-time’ of the software/hardware.

As it is now things are good enough to use Haiku for a ‘service USB stick’ for clients. There might be a small chance we’ll use this in some occasions in the (nearer) future. It’s not good enough (mainly due to the missing ‘features’) to use on a day to day basis.

Still, Haiku has evolved -very- nicely over the years (remember, I’m here since ‘day one’: my first drivers were created when Be was still around… :slight_smile: )

Anyhow, posting three more screenshots in which you can see that I have a industry standard communication protocol running (MODBUS) with another computer, we are able to use for instance simplified Chinese as running language (though I still did not complete all translations: we support nine languages, via an app-internal system). Nice to know is that I can plug/unplug USB adapters on-the-fly, and the software will just re-detect them and restart all communications without user intervention. Also maintaining a list of free and ‘in use’ serial and serial-USB ports is working nicely…

On one of the shots you see TAChart working very nice (though the data is a mess, really :wink: )

Really, really looking good I think!

Oh, BTW: The executable is around 20-21Mbytes in size. On ARM linux its about 10Mb, on Windows around 5-6Mbytes.

screenshot4
screenshot5
screenshot6

1 Like

You can extract a package (using the “package extract” command), make changes to the extracted files, then repackage it (“package create”). Then install the modified package in place of the previous one. Would that help?

The more direct way would be to use non-packaged directories (/boot/system/non-packaged/libs for libraries, etc). This works for libraries, add-ons, etc, but for some files, if Lazarus or freepascal or something has not been patched to look there first, it won’t work, of course.

1 Like

Ah yes, that would most certainly help I’d expect. I didn’t know that this is possible. I guess then I can issue these commands in a terminal window? I’ll try this in the coming days :slight_smile:

Thank you for the tip!

PS: I did try the non-packaged folders a few times already in relation to Lazarus/FPC, but nogo AFAICT.
Hmm, say I want to change a few things in the app_server: can I simply repack that as well this way? Since also there using non-packaged did not work (I wanted to do some hardcursor tests with my nVidia driver some time ago, but I always seem to get stuck in this specific ‘packed’ feature with the lowlevel stuff I tend to fiddle with…)

Yes, that should work too. If you are working on parts of haiku itself, the shortest way is to run “jam -q haiku.hpkg” from haiku buildsystem, and then you can install the generated package with pkgman. If things break, you can just boot an older state from the boot menu to get your working OS back.

1 Like

I was able to extract-modify-create the fpc source package with my modifications. Installing works, files are in correct place. Searching in pascal sourcecode indeed shows me the modified files. Still, can’t compile with them, I guess (?) because fpc binary has to be recompiled from the modified sources, and repackaged, and installed also.

Now I run into trouble: I am unable to compile the new fpc. I can try from a terminal, but I get a message the fpc3.0.4 ‘starting compiler’ is needed to create 3.2.0. While a 3.0.4 x86 binary version exists, I cannot find or create a x64 version unfortunately.

Update:
Compiling fpc 3.3.1 is possible when you have fpc 3.2.0 installed, they have apparantly updated that ‘bootstrap’ compiler thing: and since version 3.2.0 is available this will work: that is, you need to probably patch for the IsManagedType() compile error, at least I had to. (just fallback to the old behaviour: return True always).
Looks like compiling succeeded but it won’t run…

So: still kind of stuck. Oh, I just grabbed the sources directly (trunk) with subversion so I’m more in control.

I also grabbed the Lazarus IDE sources that way (trunk), and with fpc 3.2.0 it is no problem to build it. I just saw Lazarus 2.1.0 running on Haiku x64 with my project: of course I am still stuck on the termios thing because I cannot create FPC still…

Another update: all in all it turns out compiling succeeded indeed. I could even create packages, install them, and use the 3.3.1 compiler to compile Lazarus 2.1.0. Now I’m stuck because I have no clue how to create correct /etc/settings stuff for FPC, and apparantly the structure of the FPC build is not correct or completely different from how the 3.2.0 looks like. So, I just quit on this, to try another, hopefully simpler approach:

  • extract existing 3.2.0 source package, patch it, tell it it should use the 3.2.0 as bootstrap compiler, and compile itself again. While I am typing I see this succeeds. So I’ll be trying a bit more on this road instead…

For completeness sake I created a bugreport at FPC with the termios fix as I was able to test succesfully in the meantime with updated compiler and compiler source:

https://bugs.freepascal.org/view.php?id=36958

Please note that serial port ‘purge’ ( at least on USB adapters) fails always: doesn’t matter if I call the old beos specific method, or the newer FPIOCtl method, same result: I expect that Haiku simply misses support for this feature inside the kernel drivers. For my projects I disable calling this function inside SynaSer now so I can work decently with serial connections outside of that one function.

If someone feels something should be different about that patch I created, feel free to comment and such :wink:

1 Like

I can have a look at the serial port drivers, but I’m not sure which function you refer to exactly. “flush” would be waiting for all bytes to be sent, which seems not possible in BSerialPort, while “purge” would be dropping all pending data and never sending it (ClearInput/ClearOutput).

And of course I don’t know much about FPIOCtl.

Please look at both if you can. So in SynaSer you have a ‘Purge’ function, which calls ‘Flush’ below. Nice name mixup… anyway, this is the same in Linux and I’d expect it to work there :slight_smile:

If I call the Synaser Purge function, it normally directly does:
SerialCheck(fpioctl(FHandle, TCFLSH, Pointer(PtrInt(TCIOFLUSH))));

I can route it though termios by changing that line in:
SerialCheck(TCFlush(FHandle, TCIOFLUSH));

If the implementation is the old one we had in termios, or if it’s the new one (which is same as first mentioned call in SynaSer), in all cases SerialCheck (asks for result status) will report failure on Haiku.
On Linux it succeeds though.

Thanks in advance for looking!

BTW: SerialCheck:

function TBlockSerial.SerialCheck(SerialResult: integer): integer;
begin
if SerialResult = integer(INVALID_HANDLE_VALUE) then
{$IFDEF MSWINDOWS}
result := GetLastError
{$ELSE}
{$IFNDEF FPC}
result := GetLastError
{$ELSE}
result := fpGetErrno
{$ENDIF}
{$ENDIF}
else
result := sOK;
FLastError := result;
FLastErrorDesc := GetErrorDesc(FLastError);
end;

AND: (BaseUnix)

function fpgeterrno:longint; external name ‘FPC_SYS_GETERRNO’;

I was able to create FPC3.1.1 source and executable packages for packagemanager, and also Lazarus 2.1.0 as executable package. I installed them and my program works OK with that. I have included the updated termios in the FPC packages.

I have to say without copying the file structures s40in has inside his packages I would not have been able to pull this off. He’s very knowlegdeable in my eyes :slight_smile: Thanks!

I only did the 64bit versions, and I’ll leave it at that for now.
I also updated FPC 3.2.0 source and executable packages that work with the already existing Lazarus 2.0.2 package, also with updated termios.

Update:

Just uploaded it all in two zip files:
http://www.rudolfs-place.nl/Haiku/Downloads/FPC_320_Lazarus_202-x86_64.zip
and
http://www.rudolfs-place.nl/Haiku/Downloads/FPC_331_Lazarus_210-x86_64.zip

Both these files contain the mentioned versions of:

  • FPC sources + termios,
  • FPC binaries + termios,
  • Lazarus binaries,
  • LibQt5Pas pascal bindings,
  • multiplatform version of SynaSer.

Update: please note that in Synaser the commented out ‘Purge’ command contains a mistake which of course is not active as it’s commented out. Anway, when the tty driver in Haiku is updated you can enable the purge command again, but the line should read:

SerialCheck(TCFlush(FHandle, TCIOFLUSH));

In my app it’s working OK that way :slight_smile:

For the tty driver update status see: https://review.haiku-os.org/c/haiku/+/2516

Hopefully I did it right (enough) so it indeed works on everyone’s recent 64-bit Haiku installations…

5 Likes

Thankyou very much Rudolf :smiley:

1 Like

Is there a way (or some guidance) to check if these build for 32bit also?

Patch for implementing TCFLSH: https://review.haiku-os.org/c/haiku/+/2516
I don’t know if this is working, or if it is complete (see the commit message for my questions).

Nice, Thanks!

So, Synaser has online documentation here:
http://synapse.ararat.cz/doc/help/synaser.TBlockSerial.html
For it’s Purge command we are talking about the doc says:
‘Unconditionally empty all buffers. It is good when you need to interrupt communication and for cleanups.’

So I’d say this goes for RX and TX buffers. TX should be interrupted and re-initialized therefore I would expect. The next time the serial port user sends data it should be transmitted normally: the port’s settings should be unchanged (baud and such).

Ah: you can specify which buffers are affected I see (https://linux.die.net/man/3/termios):
tcflush () discards data written to the object referred to by fd but not transmitted, or data received but not read, depending on the value of queue_selector :

TCIFLUSH

flushes data received but not read.

TCOFLUSH

flushes data written but not transmitted.

TCIOFLUSH (this is used by synaser, I see btw I introduced a (commented out) fault there :-/ )

flushes both data received but not read, and data written but not transmitted.

====

Please note that the Synaser.Flush command is non-intrusive: it says:
‘Waits until all data to is sent and buffers are emptied. Warning: On Windows systems is this method returns when all buffers are flushed to the serial port controller, before the last byte is sent!’

The difference between SynaSer’s Flush and Purge commands is clear I’d say.

To give you more pointers on the driver’s exact implementation expectations by Synaser:
On our Haiku Synaser will call termiosproc.inc routine ‘Function TCDrain(fd:cint):cint;’, which calls:
fpIoCtl(fd,TCSBRK, @arg);

Sounds a bit strange though that we’d call it break.
(see: https://linux.die.net/man/4/tty_ioctl for pointers on this i.e.)

I copied this from our termios.c file: but that’s wrong here I see now I would say… But then again: In linux it’s also done this way (within lazarus/fpc at least: just switch target OS and search :wink: )
The manpage says:
’ waits until all output written to the object referred to by fd has been transmitted. ’

Last update (5th? hmm, I should probably read more before I respond… sorry…)
Anyhow, it’s clear to me now that the ‘1’ argument for the break routine actually means that it’s a ‘custom’ implementation that’s called. if it were ‘0’ then indeed it would be used to start, or stop, a break command.

So our custom implementation is executing a flush (non-intrusive). On the manpages I saw:
Sending a break

TCSBRK

int arg

Equivalent to tcsendbreak(fd, arg) .
If the terminal is using asynchronous serial data transmission, and arg is zero, then send a break (a stream of zero bits) for between 0.25 and 0.5 seconds. If the terminal is not using asynchronous serial data transmission, then either a break is sent, or the function returns without doing anything. When arg is nonzero, nobody knows what will happen.

(SVr4, UnixWare, Solaris, Linux treat tcsendbreak(fd,arg) with nonzero arg like tcdrain(fd) . SunOS treats arg as a multiplier, and sends a stream of bits arg times as long as done for zero arg . DG/UX and AIX treat arg (when nonzero) as a time interval measured in milliseconds. HP-UX ignores arg .)’

So with Haiku the meaning of ‘nobody knows what will happen’ is translated to ‘wait untill the TX buffer is sent-out into the world and then return’).

Hopefully that is indeed what happens then :slight_smile:

I guess that if you have it in place (as a patch or otherwise) I should clone into Haiku, do the patch, compile the driver and place it in the ‘non-packaged’ folder for kerneldrivers?
I guess I could do some tests with it (maybe even connect a oscilloscope to track the hardware behaviour…)

I started out to write a readme, but in the end I didn’t really complete it since I determined that I find it too complex: the best way for me turned out to just analyze s40in’s packages and copy it’s structure.

The source package is not so complex, but the structure copying I did were for the Lazarus and FPC build versions.
Tricky things are:

  • the lazarus executables lazarus, buildlazarus and startlazarus (I think I remember): I manually set their signature’s to what s40 in has done. Also I manually added the icons to them.
  • you need to create several shortcuts i.e. for app-menu entries in Haiku’s menus, to link to where the binaries are installed by you in the read-only ‘target’ filespace. Only, at the moment you are building this all, you probably do it in a subfolder structure in your home folder. So make sure you always create relative shortcuts, not absolute ones. (holding the shift key when making a shortcut makes them go created in relative mode).

I’ll look once again at the readme’s and post links to them attached to this message (I’ll edit it again :wink: ).
Hopefully that will give you enough pointers. And yes, I would expect it to work without trouble. Though I am no expect in gcc mangling (but then again I read somewhere that for this specific item we don’t suffer from that stuff as we do Pascal :slight_smile: )

Update: the readme files:
FPC3.3.1 and Lazarus 2.1.0

FPC3.2.0 and Lazarus 2.0.2

1 Like