A new version of plugins will be coming soon:
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ā¦
The first screenshotsā¦ 
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ā¦ 
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 
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ā¦ )
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 
)
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.
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
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
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
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 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
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 
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 )
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
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 ).
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 )
Update: the readme files:
FPC3.3.1 and Lazarus 2.1.0
1 Like