I have a need to port a Delphi console program written for Windows to be used on Raspberry Pi2.
Apparently it is possible to use Freepascal to get programs running on the Pi2 platform, but can it be done in Windows so I don't have to install the complete IDE on a Pi and set it up with a monitor, keyboard and mouse just for running the compile?

The program is a communication module that talks over TCP/IP sockets to a data collection device connected via WiFi.
I use the Indy10 TCP/IP components (created in code) to communicate and the data is decoded and stored on disk.

What are the steps needed to port to Pi2?

Any experience with a similar project would be good to read about!

What are the steps needed to port to Pi2?

Standard cross compiling rules apply. Nothing is fancy, pi is just another arm-linux system. Probably only SoftFP vs hard float that's problematic, but simply installing the latest raspbian and compile using hardfloat enabled FPC for arm should suffice.

You might be able to compile on the RPi as I did. See the section "Compiling..." at:

http://www.satsignal.eu/raspberry-pi/DigitalClock.html

I, too, would be interested in cross-compiling....

On Linux X86 you could use MSEide and the FPC cross compiling environment from here:
http://mseide-msegui.sourceforge.net/pics/crossarm.png http://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/

I assume it is possible to make something similar for Lazarus and Windows, I don't know if it already exists.

For integrated development with FPC 3.0.1 MSEide+MSEgui git master version is necessary:

https://gitlab.com/mseide-msegui/mseide-msegui
From MSEide+MSEgui README.TXT:
"
Crosscompiling and remote debugging i386-linux -> arm-linux *********************************************************** For Raspberry Pi:
- Establish a ssh login without password (public key authentication).

- On the i386-linux host install the scp program
- download and extract
?
http://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/crossfpc-i386_linux-eabihf_3_0_1.tar.gz ? to <your crossfpc directory>.

- Start MSEide, in 'Settings'-'Configure MSEide'-'Global Macros' add:

Name ? ? ? ? ?Value

CROSSMSEDIR ? <MSEide+MSEgui directory>
CROSSFPCDIR ? <your crossfpc directory>
HOSTIP ? ? ? ?<the IP of the host>
REMOTEIP ? ? ?<the IP of the remote target>
REMOTEPORT ? ?<the remote port, ex: 2345>
REMOTEUSER ? ?pi

- 'Project'-'New'-'From Template', select "crossarmdefault.prj" or ? "crossarmconsole.prj".
- Create the new project.
- 'Project'-'Options'-'Macros', set the TARGETPROJECTDIR value to the project ? path in remote target, ex: "/home/pi/proj/testcase".
- Check the TARGETENV macro.
- If your application needs additional libraries copy them from Raspberry Pi ? /lib/arm-linux-gnueabihf or /usr/lib/arm-linux-gnueabihf to ? <your crossfpc directory>/eabihf/lib

Press F9 and hope the best. ;-)
"
MSEide+MSEgui also runs amazingly fast natively on the Raspberry Pi, the limiting factor is FPC compiling speed and memory consumption especially for smart linking.

Martin

I found a guide t o install FPC-Lazarus directly on the Pi2 itself here:
http://www.tweaking4all.com/hardware/raspberry-pi/install-lazarus-pascal-on-raspberry-pi-2/

It seems like an easier way to build directly on the end hardware than crosscompiling. But the CPU power might be a limiting factor of course. I will make an attempt at doing this first and see how it goes.
I can always try cross-compilation later.

I would use a Linux desktop to do the port to Linux in the most comfortable way, before considering the port to ARM.

Especially with "console programs" Delphi/Windows is rather different from Lazarus/Linux, as in Lazarus console programs don't feature an Event queue.

-Michael

Maybe MSE is more suitable in this case, as (AFAIK) here console programs with an event queue is supported in Linux.

-Michael

To the best of my knowledge, Delphi itself does not offer an event queue either in console programs.

If you are talking about thread queues: the mechanisms in Delphi and Lazarus are exactly the same. If you are talking about the windows 'event system': this is a windows concept, not a linux concept. Linux has different mechanisms entirely. This is unrelated to Delphi/Lazarus/FPC whatever.

I really do not appreciate this kind of derogatory comments.

Michael.

Michael Van Canneyt wrote

To the best of my knowledge, Delphi itself does not offer an event queue either in console programs.

In fact I doubt that the OP really intends to do a pure "console program" that is called by e.g. bash and runs through without waiting for anything and then exits.

AFAIK, with Delphi a "console program" is just a normal application that only does not show a Windows, but that can use e.g. TTimer in the normal Delphi-way.

If you are talking about thread queues: the mechanisms in Delphi and Lazarus are exactly the same.

AS the OP did not mention threads, I was mainly thinking of TTimer (I should have better written "TTimer" instead of "Event-Queue", even though under the hood this means the same in that issue) .

If you are talking about the windows 'event system': this is a windows concept, not a linux concept. Linux has different mechanisms entirely. This is unrelated to Delphi/Lazarus/FPC whatever.

With Lazarus the User does not need to be aware that under the hood the Event Queue in the Windows and Linux brand of the LCL is implemented in a different way. Lazarus rather perfectly hides this. (But not with "Console Applications").

I really do not appreciate this kind of derogatory comments.

I did not mean to sound am very happy that the
maintainers of the FPC and Lazarus Project do this great work.

I was just trying to be helpful to the OP, and I think - not only because of the potential issue I described - it is a good idea to split the porting task in porting from Delphi/ Windows to Lazarus/Linux and then form PC to ARM. (Been there, learned my lesson.) With a complex Project, it even could be viable to do a port from Delphi to Lazarus on Windows first).

-Michael

Bo, I did that on the original RPi at the end of last month. You'll need a couple of the Debian -dev packages (yell if you want me to check my notes) but the important things are (a) you'll need at least 512Mb of RAM+swap available and (b) remember that you can run the IDE etc. over SSH- you don't need a local screen and keyboard.

So, we are talking about the windows event queue.

The way your post was constructed, you made it sound as if lazarus fails to offer what Delphi offers. It has nothing to do with Lazarus. Linux does not have an event queue as windows has it. One is emulated in e.g. X11 applications, and Lazarus uses that for it's GUI, and for TTimer.

Glad we straightened that out.

I'm still waiting for your patch to create a basic TEventApplication class descending from TCustomApplication. When you do, I'll be glad to include it in FPC, and as a bonus I'll even throw in an item for it under "new project" in File|New in the lazarus IDE...

It will then hopefully put an end to this years long bickering about event queues :)

Michael.

Michael Van Canneyt wrote

The way your post was constructed, you made it sound as if lazarus fails to offer what Delphi offers.

Sorry for being unclear !! (This obviously is just an issue of the word "Console Application".)

The contrary is true. Lazarus (at least in Linux) is able to compile real "pure run through" command line tools, while Delphi (AFAIK) just does normal "Applications" that don't show the main Windows and calls this a "Console Program".

In Linux, a Lazarus Console application can be used on hardware with no GUI system installed.

So Bo supposedly is save if he selects "Application" and not "Console Application" when setting up his project. In fact on a PI a GUI system is active by default.

Other than MSE, a Lazarus "Console Application" can't use TTimer, this might not be relevant for Bo on Pi.

-Michael

Michael Schnell wrote

AFAIK, with Delphi a "console program" is just a normal application that only does not show a Windows, but that can use e.g. TTimer in the normal Delphi-way.

Could you please post your Delphi test for that? Thanks.

"Michael Schnell" wrote

The contrary is true. Lazarus (at least in Linux) is able to compile real

"pure run through" command line tools, while Delphi (AFAIK) just does normal "Applications" that don't show the main Windows and calls this a "Console Program".

Creating a new Console Application in Delphi creates a nearly empty project file that contains an empty "begin...end." block with a "{$apptype console}", so exactly what is needed for a console application that does not show any GUI by default (the Lazarus analog is "Simple Program" or so).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150918/9216034c/attachment.html>

Bo Berglund wrote

It seems like an easier way to build directly on the end hardware than crosscompiling.

Yeah, that's what I've been doing for years, and it works very well. I have an original RPi, so even less memory and CPU power, so I opted not to use Lazarus IDE or LCL. Maximus or MSEide only use 15-25MB of RAM (compared to Lazarus's 100+MB for the same project).

You can obviously compile from the command line too and use any lightweight text editor if you want.

Regards,
- Graeme -

...

Thanks for your suggestions!
I think I need to explain more what I am after....

What I want to do is the following:

I want to create an automation function running on the RPi2 for managing a data monitoring system to collect data for detecting imminent risk of failure of dams.
The system would work as follows:
- An instrument collects data from a number of sensors on the dam
- The instrument is essentially designed to be manually operated so the Pi is there to automate it
- It has a communications channel via a WiFi adapter hooked to its serial port and there are commands to do whatever needed
- Via this channel it is possible to command a measure cycle and to download the resulting data
- So a schedule needs to be set up to tell the instrument to do two different measure cycles at certain times
- The data will be downloaded to the RPi2 when the cycle finishes in order to free memory on the instrument
- Access to the data will be provided on the RPi2 via a mobile network router also connected to the RPi2
- The whole system will be deployed unattended for long periods (months-years)

I have previously built systems like this using a Windows PC to automate the instrument and using serial communications. The software was written using Delphi 7 as a Windows service controlled via settings in the Registry.

Now we need to shrink and ruggedize the system and I wanted to use an RPi2 to implement the controller. It would be dual homed with a wired connection to the router and a WiFi connection to the instrument which emulates the serial link.

Yesterday I realized that it would be a large task to re-invent the software on the Pi using for example python since I am not at all familiar with that language.
Then it dawned on me that freepascal is multi-platform and I colud possibly port existing Delphi code over to the Pi, thus reducing the amount of work needed. I have used a serial comm component in the existing code but I figured I could replace that by an Indy TCP client component instead. Apart from that there are only standard functions used and no user interface.

So that is why I am here now. I have used RPi units for a lot of things at home (I run media centers, printer servers, VPN servers and such things using 4 different Pi:s). So it is a natural to try this road...

I am still looking for the proper way to go. Possibly first starting from my existing Delphi software and creating the cut down unattended software on Windows and then porting over to the Pi. Windows services is not possible of course so I figured I could make a console program started by cron instead.

What would be the best way in your view?

Bo Berglund wrote

On Fri, 18 Sep 2015 11:02:23 +0200, Michael Schnell What would be the best way in your view?

1. Port the Delphi 7 application to FPC Windows X86 on a Windows X86 PC.
2. Port the FPC Windows to FPC Linux X86 on a Linux X86 PC.
3. Cross compile and cross debug the Linux application to RaspberryPi on the Linux X86 PC.

Martin

Martin Schreiber wrote

2. Port the FPC Windows to FPC Linux X86 on a Linux X86 PC.

2. Port the FPC Windows application to FPC Linux X86 on a Linux X86 PC.

Thanks!
I have Lazarus installed on my laptop so I guess I can start right away to cut and paste code from my existing project and create the console app on Windows but in Lazarus then.
I have not really used Lazarus except for some hello world tests and for checking how to port a Sentinel dongle function to FPC.

I'll probably ask some more, but how does one go about getting Indy10 onto Lazarus/FPC?

Bo Berglund wrote

I have not really used Lazarus except for some hello world tests and for checking how to port a Sentinel dongle function to FPC.

Now that is a chance to use MSEide instead. ;-)
MSEide runs amazingly fast on Raspberry Pi and has very good suport for development of embedded and microprocessor projects written in Pascal or C, cross development with MSEide is very comfortable. I use it daily for different ARM and AVR32 projects.
With MSEgui you also have a state of the art cross platform GUI toolkit with excellent database options at your fingertips. MSEgui probably is the most versatile GUI toolkit on the market.

Martin

Quite cheeky, posting this on a Lazarus list :)

Michael.

Does that mean I can install FPC only on the Pi and then develop on a Linux box (x86) using Lazarus and then move the project to the Pi and recompile using the FPC from a terminal on the Pi? Anything I need to take into account for that to work?

On the Windows service application I am checking every minute if a start time for a measure task has occurred and then I run the process to get the measurement going.
I probably have to do something about the way to handle the scheduling in Linux, either by programmatically setting up cron jobs or by having my program run in an eternal loop and checking the time in every loop iteration.
Or is there a better way on Linux?
As described my Windows application is a service and I am not porting that, I only want to use all of the ObjectPascal classes I created for the handling of the instrumentation but using whatever scheduling functionality that may be available in Linux.
And I have to include an Indy TCP Client too....

OK, I will have a look when I get a chance. Right now I am specing down the project and am investigating my different options. I know Delphi (obviously) and a little about Lazarus. But MSE is news to me....

Hello Bo,

Bo Berglund wrote

Does that mean I can install FPC only on the Pi and then develop on a Linux box (x86) using Lazarus and then move the project to the Pi and recompile using the FPC from a terminal on the Pi?

Yes, that is an option too, and should work just fine - especially since you said the project is a console program.

If you developed a GUI application, then the RPi would need the *.ppu files for the GUI toolkit too. But this is irrelevant in your case.

Regards,
- Graeme -

FYI, I have done FPC daemon to run on RPi to communicate with Serial port and the feed the data back to a PC program from time to time via LAN. It is not very difficult.
However, I had difficulties using Indy on FPC and eventually gave up. I later moved to lNet because it runs on linux and supports SSL. If I had to redo it, I would do it in synapse, especially if I don't need SSL.

For the loop, I would loop infinitely in the console program. A better way if you don't mind is to create a few threads. One for collection data and another for communicating on the LAN.

Nowadays, a raspberry pi has much more RAM and faster CPU. It would make it even easier.

For writing daemon, just refer to FPC wiki.

Dennis

Bo Berglund wrote

Or is there a better way on Linux?

A typical Linux way in fact is doing a cron job. A common Unix paradigm is to do any functionality in a small dedicated "run through" executable and chain those via pipes and/or call them via system functionality such as cron.

Of course it also is possible to to a complex program that internally handles events (e.g. timers that schedule certain activities) in a way Delphi suggests. But here the typical Delphi way is using TTimer (and threads with appropriate synchronization if appropriate) to handle the multiple events that occur. This is why I suggested to do an "Application" in Lazarus instead of a "Console program", as only same has support for TTimer etc, This does not harm on a Pi, as here GUI support is enabled by default, and showing status information on the GUI of our program can be a great help with debugging.

And I have to include an Indy TCP Client too....

I did not ever try myself but I multiple times heard about problems with Indy on Lazarus/Linux. No Idea if this in fact is workable on ARM.

Please let us know what you find.

-Michael

Marco van de Voort wrote

Could you please post your Delphi test for that? Thanks.

You are correct that this does not work in the way I assumed.

-Michael

Bo later said:

"As described my Windows application is a service"

I am rather positive that a Delphi "Service Application" can do TTimer etc.

-Michael

Bo Berglund wrote

Now we need to shrink and ruggedize the system ...

IMHO a Pi is nit suitable to "ruggedize" a system. The Pi is made for education purpose not for embedded use. It's stability, EDS immunity, and temperature range is not suitable for this. If there is any security issue with this project you should choose another ARM Linux system. There are lots of them that offer better specifications for embedded use. Moreover Wifi is not usable for decent embedded application. it is very prone to be temporarily unavailable by environmental influence (such as microwave ovens and other Wifi routers nearby).

esterday I realized that it would be a large task to re-invent the software on the Pi using for example python since I am not at all familiar with that language....

To me it is a very viable idea to use the well tested Delphi code and port the Project to fpc/Lazarus.

-Michael

Martin Schreiber wrote

3. Cross compile and cross debug the Linux application to RaspberryPi on the Linux X86 PC.

I did try rather hard but getting cross compiling running with Lazarus was not really amusing and I did not at all succeed in getting cross (aka remote) debugging with Lazarus going.

So I suggest to install fpc on the target and compile natively on the ARM.

Debugging there might be a problem, but I know that running Lazarus naively on a decent ARM system is possible and debugging should work in the normal way. Maybe a Pi oi to small a system for doing this with acceptable performance.

-Michael

Michael Van Canneyt wrote

Quite cheeky, posting this on a Lazarus list :)

I never installed MSE IDE, as for porting to Linux an large Delphi project with several Desktop applications and multiple Delphi-trained Developers (I intended to trigger that for a long time) Lazarus seemed a lot more appropriate.

But for Doing Cross projects (in my case for an ARM device with no GUI support), I needed to work around a lot of issues with Lazarus. Supposedly MSE would have been easier to use. (But as an old GUI I did not dare to start the learning curve.)

-Michael

That is because (at least up till Delphi XE) a Delphi service application runs the *GUI* processmessages loop (it uses unit forms for this).

Which, incidentally, also calls 'CheckSynchronize'.

A vanilla console application does not run a message loop, hence also in Delphi does not have TTimer, thread synchroniszation and whatnot.

But now you found out yourself :)

Michael.

Michael Schnell wrote

I am rather positive that a Delphi "Service Application" can do TTimer etc.

No it doesn't... At least not by simply creating an instance of TTimer and hooking up the OnTimer event.

This applies to both Console and Service applications under Delphi. The Delphi TTimer, in uses the WM_TIMER Windows message and a Console and Service application don't have a message loop. So to get it to work, you need to implement your own message loop.

http://stackoverflow.com/questions/12026951/using-vcl-ttimer-in-delphi-console-application

http://objectmix.com/delphi/403332-ttimer-service.html

Regards,
- Graeme -

Correct for console, not for service. Check svcmgr unit, it runs the message loop.

Michael.

Michael Van Canneyt wrote

That is because (at least up till Delphi XE) a Delphi service application runs the *GUI* processmessages loop (it uses unit forms for this).

Maybe from the POV of the application but...

With Win XP a Service could optionally show a GUI Window which is depreciated as a security glitch as that window runs with system rights.

In fact in Windows >=7 (or so) the OS prevents that a Service shows a Window.

As pointed out above to the user it is not important how the implementation of the event queue (aka "message queue", aka " processmessages loop") is implemented,. If he does not want his project top show a GUI (e.g. with a Windows Service or with a GUI-less Linux project. He just needs to know how to set up a project that allows him to use the features he needs (be that TTimer, TThread.Queue, TThread.Synchronize and/or Application.QueueAsncCall) .

If that needs for doing an application with full GUI support in Linux, this is not really desirable, but IMHO not a problem that should prevent using Lazarus, but in very rare cases.

-Michael

Graeme Geldenhuys wrote

No it doesn't...

Sorry if I am wrong here. I do know that colleagues of mine do Services in Delphi by doing normal GUI applications that definitively do use TTimer, and in the end just do a small modification to have them run as Services.

I am not aware of the exact method how they do so.

-Michael

Michael Van Canneyt wrote

Correct for console, not for service. Check svcmgr unit, it runs the message loop.

Ah yes, I see what you mean. I just double checked in Delphi 7. Wow, a Service Application in Delphi (unlike under FPC - at least for *nix) seems to be a full-on GUI application, just without a UI. It pulls in Controls, Graphics, Dialogs (WTF??), Forms etc units.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Wow, a Service Application in Delphi (unlike under FPC - at least for *nix) seems to be a full-on GUI application, just without a UI.

... because this is easy to do in Windows, but not that easy in Linux ;-)

The Lazarus team did a great job but needs to draw a line at certain locations.

(As you might know I do have a working draft of an "Active NoGui" Widget Type implementation, and I suppose with fpc 3.0 - that seemingly finally provides TThread.Queue in a released version - it might be viable to push it. I'll re-check as soon as I find some time to do this.)

-Michael

Michael Schnell wrote

... because this is easy to do in Windows, but not that easy in Linux ;-)

That only applies to Delphi. :) The brilliant FPC developers managed it just fine.

Last year I implemented a Windows Service / Linux Daemon application using FCL's daemonapp.pp unit. It was a 100% non-GUI application, and I used threads and all without issue. Just to be clear, using threads in this case didn't require Synchronize() either - because Synchronize() is purely there for GUI apps, which this wasn't.

The Lazarus team did a great job but needs to draw a line at certain locations.

I don't know what Lazarus does with regards to Service/Daemon apps - my above mentioned application wasn't written with Lazarus (just a text editor and fpc compiler). Do they (Lazarus) introduce a GUI dependency for such applications? That would be stupid if they do.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Just to be clear, using threads in this case didn't require Synchronize() either - because Synchronize() is purely there for GUI apps, which this wasn't.

Of course it is *possible* (it even is _possible_ to code a complete application with a hex editor :-) ) But this is a point of view I don't me it is a very bad idea to have the Lazarus users use completely different paradigms for common stuff like timers,
Worker-Thread-responses, and - in the end - the makeup of a project (as a number of events scheduled by the infrastructure vs as a thing that needs a loop just for waiting on anything).

Nowadays, even very small embedded boards do have GUI support. So it's not very important to have a NoGUI application like I did (just for fun, when I still had some spare time). You simply can always tolerate a link to a GUI framework an let same do it's thing, even if nobody will ever see it.

-Michael

Michael Schnell wrote

To me it is a very bad idea to have the Lazarus users use completely different paradigms for common stuff like timers,

I don't know what Lazarus's TTimer uses in the back-end (hooks into the GUI I presume), but FPC does includes a fptimer (which I wrote the initial implementation of) which is thread based and doesn't require a GUI. In my service application I used TThread to implement my own file-system monitoring class (which is based on interval checking). I don't consider using TThread a "different paradigm" - it's simply a class like any other.

You simply can always tolerate a link to a GUI framework an let same do it's thing, even if nobody will ever see it.

I wholeheartedly disagree with that! There is absolutely NO reason to pull in the extra dependency when it is NOT needed.

I'm currently busy developing another cross-platform Daemon/Service application. It uses multiple threads, IPC, multiple DB connections etc... It must have absolutely *no GUI dependency*, because it must be able to run on a truly headless server. Think Mail server, Database server etc especially under Unix-type environments - Windows and Mac servers are an abomination.

Regards,
- Graeme -

Am 21.09.2015 13:51 schrieb "Graeme Geldenhuys" <

Just for clarification: Synchronize() is not only for GUI. It's purpose is to execute a piece of code in the main thread triggered by another thread. If that piece of code uses GUI or not is secondary. (Of course it's often used in that context, but it's not restricted to that!)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150921/4e84ffb1/attachment.html>

Graeme Geldenhuys wrote

I don't know what Lazarus's TTimer uses in the back-end

I do. But this is completely irrelevant regarding what is desirable to offer to the users.

My ActiveNoGui draft does not use any GUI hook and it does work - according to first simple tests.

The "different paradigm" I meant is "event driven programming" that obviously requires an Event queue (but obviously does not require a GUI).

Or on a less sophisticated layer: Why have (force) the user use TTimer in one project and fptimer in another ?

I wholeheartedly disagree with that! There is absolutely NO reason to pull in the extra dependency when it is NOT needed.

So you are (the only) one here who understand the implications and nonetheless supports the idea of an "ActiveNoGui" Widget Type ?

Maybe it some day could be accepted in Lazarus, but I doubt it, because I think I am able to take the library to a decent level, but I am not able to do the integration in the IDE.

-Michael

Sven Barth wrote

Just for clarification: Synchronize() is not only for GUI....

Same is true for TThread.Queue and Application.QueueAsyncCall, as well. All three (from the user's point of view) do similar stuff: schedule an event that is executed in the main thread at an appropriate point in time.

But TThread.Queue and TThread.Synchronize is implemented in the fpc RTL, while Application.QueueAsyncCall, is implemented in the LCL. And the LCL Queue management is only available when attaching to a GUI (even though it is possible to do a *new* Widget Set with that functionality without a GUI binding).

-Michael

No. Because it will simply fail to run on a headless system.

We have countless virtual machines for webservers. None of them has X or X libraries installed. And that is as it should be.

The software should run on those, and that will not be the case if you allow such dirty hacks.

So you are totally wrong in your argument.

Michael.

Michael Van Canneyt wrote

So you are totally wrong in your argument.

This argument had been pointing against myself, as it invalidates my effort to do an ActiveNoGui WidgetType I had been requesting at the time I investigated about porting a large embedded Delphi project to a headless Linux system.

But as we stopped this effort (at that time due to lack of manpower, now we think it could stay being a Delphi project as with Windows IOT Core there finally is a (free) "embedded" Windows that can fun Delphi programs), "ActiveNoGui" is just a legacy hobby project of mine. If you think it is useful, I hope I can provide some code some day soon.

-Michael

I believe you are partially correct, but in this case I thought of activating the watchdog on the Pi thus ensuring that if it hangs it will come back on-line within short.
The work is now on making a prototype and if the hardware is not up to the task we will be able later to change it if the need arises and the system is accepted as such.
I take your comment as meaning there are other platforms where FPC also runs, right?

Moreover Wifi is not usable for decent embedded application. it is very prone to be temporarily unavailable by environmental influence (such as microwave ovens and other Wifi routers nearby).

Don't have much choice here...
The intrument has already been modified by replacing the serial port by an internal WiFi AP module which connects to the instrument via RS232 and the outside world will get access via a TCP port on the AP host. This was done to make it possible to use Android tablets for managing the instrument.
OTOH, the whole monitoring system will be enclosed in an aluminum box so outside WiFi disturbances are probably not going to enter into the system.

That was my second realization after first thinking it might be "easy" to code in some Linux friendly language. After all we had a working Delphi system, albeit running as a windows service.

But then I looked up the existing sources to check what was involved and it turned out to be at least 4 different rather big unit files implementing various aspects of the data handling. So porting the object-pascal code became the probably most efficient way of doing thus.
Only one unit deals with the physical layer and it has already a conditional to specify what kind of com port is used. That is where I have to tie in the conditional for TCP/IP comm using whatever socket implementation I find most suitable.

Unfortunately since the existing code is built on non-blocking serial communications and events to handle the data reception I am at a loss right now concerning what TCP socket component to use. Indy is blocking, synapse is blocking and ICS being non-blocking is not open for commercial use and even so not really maintained for FPC either...

Still looking...

Michael Van Canneyt wrote

No. Because it will simply fail to run on a headless system.

Hi all,
being the topic creator I want to just intervene about the target system:
It is intended to run on a *headless* RaspberryPi2 (or equivalent more robust ARM platform as was pointed out in another response).

I could maybe use cron to start it every 1 minute (but then I would need to find a way to NOT start it if it is already running but has not finished yet).
Most executions would find that there is nothing to do since the time for the next measurement has not arrived.

Or else I would have to have it running 24/7 (as a windows service does) but be idle most of the time until a time trigger is detected at which time it will run a measurement. Such a measurement may run for several minutes before it finishes.
Meanwhile nothing else can be done towards the instrument.

Michael Schnell wrote

Moreover Wifi is not usable for decent embedded application. it is very prone to be temporarily unavailable by environmental influence (such as microwave ovens and other Wifi routers nearby).

Not just for embedded applications... anything wifi in general is prone to network issues.

I had constant issue at my home-office where there are computers, printers, game consoles, TV decoder, phones, tablets, ebook readers just to name a few - all on the wifi network. Then add in the neighbours all round also on wifi, and suddenly you see the issues clearly. So this past weekend I wired my house with a gigabit network to all vital locations and moved as many devices off the wifi network. Oh, what a pleasure, and now suddenly everything is super fast - and my media centre runs without a hitch (no more random disconnects). :-D

Regards,
- Graeme -

Bo Berglund wrote

I take your comment as meaning there are other platforms where FPC also runs, right?

Yep. You can always switch to another ARM/Linux board with not much porting effort.

The intrument has already been modified by replacing the serial port by an internal WiFi AP module which connects to the instrument via RS232 and the outside world will get access via a TCP port on the AP host.

We (company) did tests with serial via WLAN (and Zigbee) and gave up due to lack of reliability. We very happily use DECT instead

Only one unit deals with the physical layer and it has already a conditional to specify what kind of com port is used. That is where I have to tie in the conditional for TCP/IP comm using whatever socket implementation I find most suitable.

The data path of the Serial via TCP/IP link supposedly is just Telnet, i.e. just a TCP/IP Socket. So you really don't need Indy.

-Michael

Bo Berglund wrote

I could maybe use cron to start it every 1 minute (but then I would need to find a way to NOT start it if it is already running but has not finished yet).

If you must go the cron route, SimpleIPC is your friend for checking if an instance of the application is already running. The same application will be an IPC client and a server. The new instance will check for an existing instance and if found, terminate immediately. Very simple to implement, and I've been doing that for years.

Regards,
- Graeme -

Well, we found a WiFi module that could implement an AP functionality and then we created an Android app to communicate with TCP/IP on the port that runs to the instrument RS232. It has worked very well for a couple of years now.

I don't really know how Telnet could tie in here. I belive the port we use just channels whatever is received from either end to the other end. There is no protocol involved inside the TCP link, just rawe (binary) data streaming through. One level up in our software there is a protocol though to handle the streamed data.
Isn't Telnet some kind of terminal emulation system with escape codes and all?

You could take a look at the TInetSocket of the ssockets unit which is part of FPC (at least in 3.0.0, don't remember about 2.6.4).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150921/f6eb52bf/attachment-0001.html>

I tried to find information on this but it seems a bit difficult... Since I have Lazarus installed in my Win7 PC it would be good to know where in the installation I might find the units for this component. A search from the top of Lazarus finds a number of files with socket in their names but no ssocket sockets.pas file I found indicates that it is for OS/2 only

I also found a wiki page http://wiki.freepascal.org/Sockets where some info could be gleaned.
But I am worried that this component actually is TEXT oriented such that it strips off/adds line endings to whatever is sent/received...

Could you confirm that the TSocketClient can actually handle raw binary data such taht one can send/receive a binary file over the TCP connection?
If tha is the case then it might just be what I need to implement my simple serial port interface via TCP/IP.

Bo Berglund wrote

That is where I have to tie in the conditional for TCP/IP comm using whatever socket implementation I find most suitable.

MSEgui also has nonblocking socket components with ssl support. Please compile MSEide with -dmse_with_ifirem in order to activate them. It also has "tnoguiapplication" in order to build daemon applications with an event loop where all nonvisual components including ttimer can be used.

Martin

part

As I said it might be that you need at least 3.0.0. But you could try to install the release candidate for that.
The code should be in lazarusdir/fpc/VER/packages/fcl-net/src (Note: path might be not entirely correct as I don't have a Windows installation of Lazarus in front of me right now).

No, that's a different unit/component/class...

I can't say anything about TSocketClient, but the TInetClient in the ssockets unit I mentioned is a class that's rather directly on top of the native socket API, so that should definitely be able to handle it.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150921/9a07357e/attachment.html>

Thanks,
in my installation it sits here:
C:\Programs\lazarus\fpc\2.6.4\source\packages\fcl-net\src\ssockets.pp

I can't say anything about TSocketClient, but the TInetClient in the ssockets unit I mentioned is a class that's rather directly on top of the native socket API, so that should definitely be able to handle it.

Fine, then I just need to make it visible inside Lazarus... Right now after firing up the Lazarus IDE I cannot see any trace of it unfortunately.
I decided to give it a shot by creating a test application but the palette does not sow even one internet component...

Not everything is a component. TInetSocket is merely a class that you need to instantiate in code.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150921/8d21e763/attachment.html>

Bo Berglund wrote

I don't really know how Telnet could tie in here.

"Telnet" is just a synonym for "transfer Bytes via TCP/IP without any additional higher protocol".

-Michael

Bo Berglund wrote

Fine, then I just need to make it visible inside Lazarus...

I suppose you mean "accessible".

Is it not enough to include the appropriate unit in the "uses" clause ?

If not, I suppose you just need to add the file to the search path.

-Michael

Bo Berglund wrote

Unfortunately since the existing code is built on non-blocking serial communications and events to handle the data reception ...

You can convert a blocking socket (or serial port receive) to be a non-blocking Event-triggering (i.e. Delphi-Paradigm based) code by encapsulating the blocking API in a thread and fire an event to the main threads by TThread.Synchronize, TThread.Queue or
Application.QueueAsyncCall. Now you can do the complex work in the main Thread event.

-Michael

Martin Schreiber wrote

pport. Please compile MSEide with -dmse_with_ifirem in order to activate them. It also has "tnoguiapplication" in order to build daemon applications with an event loop where all nonvisual components including ttimer can be used.

That is really nice !

Alternatively Bo could do a normal application and just ignore the GUI. I also would be happy to provide my NoGuiApplication code to him, if he would like to stay with Lazarus and try it.

-Michael

https://tools.ietf.org/html/rfc854, it is not a synonym for 'just bytes', it is predominantly text - human readable oriented.

for 'just bytes' you'd rather use 'just sockets', IMO(YMMV)

el es

Graeme Geldenhuys wrote

On 2015-09-21 12:37, Michael Schnell wrote: >

[...]

The Lazarus services I run here at work have zero GUI dependency.

Marc

Marc Weustink wrote

The Lazarus services I run here at work have zero GUI dependency.

Of course you can do programs that don't have a GUI dependency (e.g. a Service/Daemon) using Lazarus.

The question discussed is whether it is possible to use the "Event programming" paradigm to do the software (e.g. using TTimer) that is typical for Delphi/Lazarus enabled software and "makes the difference" that makes using such programming systems desirable over "legacy" programming methods.

-Michael

The answer is: Yes, it is.

Michael.

Michael Van Canneyt wrote

The answer is: Yes, it is.

I never saw a Linux project without GUI binding that use TTimer. (Other than my own TTimer implementation, done in a compatible way.)

-Michael

Michael Schnell wrote

Delphi/Lazarus enabled software and "makes the difference" that makes using such programming systems desirable over "legacy" programming methods.

Now you are approaching ?dangerous? territory. :-) Just because Delphi and Lazarus promotes the idea of RAD development - definitely doesn?t mean you should.

If you want to develop any easy to maintain application over a long term - definitely DO NOT USE RAD style development. This was proven over and over. RAD is only good for prototyping or small utility apps. There is no substitute for well designed code - like when using the well documented (tried and tested) Design Patterns, or well separated code (UI layer, Storage layer, Business rules).

Designing a Service or Daemon application without TTimer usage definitely doesn't mean it is ?bad? or ?legacy? coding style. It might just mean you are not using RAD style development. Nothing wrong with that!

Regards,
- Graeme -

Michael Schnell wrote

I never saw a Linux project without GUI binding that use TTimer.

Michael said it is possible, and I agree. Martin Schreiber told you many times in the past MSEgui's TTimer can be used in non-GUI projects. The Lazarus team simply haven't had the need to go that route - that doesn't mean it is impossible.

Regards,
- Graeme -

Please !

sed/TTimer/TFPTimer/ and you're all done.

If you cannot do that as a programmer, you should have your license revoked.

Michael.

Graeme Geldenhuys wrote

Michael said it is possible, and I agree.

Of course I do know. I did it myself (doing my version of TTimer and some more EventQueue enabled functions)

Martin Schreiber told you many times in the past MSEgui's TTimer can be used in non-GUI projects.

Of course I do know.I am discussing this with Marin since years.

The Lazarus team simply haven't had the need to go that route - that doesn't mean it is impossible.

Of course I do know. But I always get bashed when stating this. (And trying to discuss ways to improve that.)

-Michael

Graeme Geldenhuys wrote

Now you are approaching ?dangerous? territory. :-)

Right, but RAD does not require Event Programming, nor makes Event Programming a project "RAD" !

OTHO you can of course state that preferring Event Programming over fully user managed code is a matter of taste I can't decently argue against that (I do fully user managed code with 90 % of my projects).

But If the programming system suggests to to Event Programming for 90 % of the projects done by the users (i.e. for Desktop application) and every user is trained by doing this, to me it is not very "nice" to force the users to use a different paradigm when doing certain non-Desktop projects. And as you state yourself in the other mail, MSE proves that it is possible using fpc in a seamless way.

(Not at all wanting to bash the Lazarus developers, as they do a great job and you can't expect that everything you want is just there out of the box. But OTOH ignoring the facts does not change them ;-) )

-Michael

RAD might not just mean 'drag a component from the palette to a form' ;) In some sense, even the (responsibly applied) OOP paradigm leads to (more) rapid (program) development...

If you want to develop any easy to maintain application over a long term - definitely DO NOT USE RAD style development. This was proven over and over. RAD is only good for prototyping or small utility apps.

Mmmm, from your own garden ;)
Aren't you making the tiOPF designer and framework for that purpose actually?

There is no substitute for well designed code - like when using the well documented (tried and tested) Design Patterns, or well separated code (UI layer, Storage layer, Business rules).

True, that.

Sometimes I want it to 'just work' and be based on well known and understood code base, or just have no time to develop the intricacies of low-level e.g. timer handling stuff... and/or agree to the price of being limited by the 'underlying libraries'. Or find that when used the prototype it 'works well enough' for us (thanks to all the optimization & fixes from the Teams of Lazarus and FPC). (it actually means 'works amazingly') Or just don't want to reinvent the wheel for the gazilionth time...

Regards, - Graeme -

el es

Michael Schnell wrote

RAD does not require Event Programming, nor makes Event Programming a project "RAD

To me "RAD" more means stuff like doing the "business logic" code directly in the unit that is used for the GUI handling.

(Using Events that can easily be overcome by doing appropriate GUI Objects in one Unit and Business Logic Objects in another one and link those via properties and Events (=callbacks).

-Michael

Lukasz Sokol wrote

RAD might not just mean 'drag a component from the palette to a form' ;)

Show me one developer that doesn't think that. :) I haven't met any yet.

> over and over. RAD is only good for prototyping or small utility apps. Mmmm, from your own garden ;)

No, from commercial companies I worked for in the past - where Delphi based projects have been in development of many years (eg: started with D3 and upgraded as Delphi got released) and gone through stacks of developers as they come and go.

Here is the result of just one such case... You often end up with this after a 15 year development cycle.

http://geldenhuys.co.uk/~graemeg/datamodule.png

Aren't you making the tiOPF designer and framework for that purpose actually?

What is "tiOPF designer"?

Sometimes I want it to 'just work' and be based on well known and understood code base,

I understand my code just fine. :) I have also built up a "developers toolbox" over the years which includes tons of code snippets, code templates, template projects, template forms etc. Simply copy it in, do a rename here or there, and away I go. This saves me stacks of time and it 'just works' too. ;-)

But hey, we are seriously straying off-topic. Better stop here before I get band from the mailing lists again.

Regards,
- Graeme -

Graeme Geldenhuys wrote

On 2015-09-22 15:27, Lukasz Sokol wrote: >

[...]

sorry I meant fpGUI ;) and tiOPF.

el es

Graeme Geldenhuys wrote

On 2015-09-22 15:27, Lukasz Sokol wrote: >

[...]

It's more probably like, if I want to create a networked application, even something that communicates through locally opened sockets on 127.0.0.1, I have some usable options that separate me from the under-the-bonnet insides of TCP/IP stack, i can use them or ... or I can reinvent Synapse... which I'd rather not.

In deep abstract sense, making T(FP)Timer and Event-Driven programming to work universally, whether as dragged&dropped component or as instantiated class, is more similar to the above. To me, as a rookie, anyway ;)

But hey, we are seriously straying off-topic. Better stop here before I get band from the mailing lists again.

OK.

Regards, - Graeme -

el es

That was pretty impressively unreadable!
I know we have used data modules too in order to stuff non-visual components on and then get the RAD studio help in fixing the GUI dependencies, but we never walked this far....
Thanks for showing it, it is a reminder to keep things tidy!

As for the thread topic, I think I have already gotten the info I need:
1) Don't cross-compile
2) First port over to Lazarus in Windows <= I will start here soon
3) Next port to Lazarus on Linux (I have a Linux Mint virtual machine)
4) Finally port over to Raspberry Pi

This voids any need for cross-compilig, and the final step gets me the end result compiled on the final hardware.

Other threads created for other related topics....

That is what I figured I could do with the TInetSocket I found in some response here. I have verified it ships with FPC so I don't have to do any install or such to get it too.

But since I did not find any documentation "for Dummies" on
TInetSocket I am not at all sure what I should do to add a therad to
manage it via an event handler.
I looked at the ssocket unit and found the declaration of TInetSocket
as follows:
[code]
 TInetSocket = Class(TSocketStream)
  Private
    FHost : String;
    FPort : Word;
  Protected
    Procedure DoConnect(ASocket : longint); Virtual;
  Public
    Constructor Create(ASocket : longint); Override; Overload;
    Constructor Create(const AHost: String; APort: Word); Overload;
    Property Host : String Read FHost;
    Property Port : Word Read FPort;
  end;
[/code]
At this level it seems very sparse so I have to drill down to its
ancestor TSocketStream:
[code]
  TSocketStream = class(THandleStream)
  Private
    FReadFlags: Integer;
    FSocketInitialized : Boolean;
    FSocketOptions : TSocketOptions;
    FLastError : integer;
    FWriteFlags: Integer;
    Procedure GetSockOptions;
    Procedure SetSocketOptions(Value : TSocketOptions);
    function GetLocalAddress: TSockAddr;
    function GetRemoteAddress: TSockAddr;
  Public
    Constructor Create (AHandle : Longint);virtual;
    destructor Destroy; override;
    function Seek(Offset: Longint; Origin: Word): Longint; override;
    Function Read (Var Buffer; Count : Longint) : longint; Override;
    Function Write (Const Buffer; Count : Longint) :Longint; Override;
    Property SocketOptions : TSocketOptions Read FSocketOptions
                                            Write SetSocketOptions;
    property LocalAddress: TSockAddr read GetLocalAddress;
    property RemoteAddress: TSockAddr read GetRemoteAddress;
    Property LastError : Integer Read FLastError;
    Property ReadFlags : Integer Read FReadFlags Write FReadFlags;
    Property WriteFlags : Integer Read FWriteFlags Write FWriteFlags;
  end;
[/code]
And then I have to go further to THandleStream:
[code]
  THandleStream = class(TStream)
  private
    FHandle: THandle;
  protected
    procedure SetSize(NewSize: Longint); override;
    procedure SetSize(const NewSize: Int64); override;
  public
    constructor Create(AHandle: THandle);
    function Read(var Buffer; Count: Longint): Longint; override;
    function Write(const Buffer; Count: Longint): Longint; override;
    function Seek(const Offset: Int64; Origin: TSeekOrigin): Int64;
override;
    property Handle: THandle read FHandle;
  end;
[/code]

And I am lost.....

In all of this where could I for instance check if there are received data to read? The Read method being blocking would not really be useful, right? I don't want to call anything that can potentially be stuck and never return...
The minimum would be to be able to set a (short) timeout on the Read() method. But I don't see that.

Do you have any pointers?
And btw thanks for your help so far! :)

The MSEgui socket components (and the pipe reader and RS232 components too BTW) implement the model Michael describes. They have the event properties "oninputavailable" and "onsocketbroken". If you like to build something like this yourself based on "TInetSocket" the code is here:

https://gitlab.com/mseide-msegui/mseide-msegui/tree/master/lib/common/ifi (msesockets.pas)
https://gitlab.com/mseide-msegui/mseide-msegui/tree/master/lib/common/serialcomm (msesercomm.pas)
https://gitlab.com/mseide-msegui/mseide-msegui/tree/master/lib/common/kernel (msepipestream.pas).

Martin

Bo Berglund wrote

3) Next port to Lazarus on Linux (I have a Linux Mint virtual machine) 4) Finally port over to Raspberry Pi

And you'll most likely find that the last step doesn't require any extra development or "porting" - simply the setup of the FPC compiler. [Going with the assumption that most RPi's run a Linux distro]

Regards,
- Graeme -

From practical experience with Raspbian, it appears that once FPC and Lazarus are on an RPi the overall system behaves like any computer. Perhaps not quite as fast as a modern x86, but the difference is quantitative not qualitative.

That might not be the case with other distreax.

Martin Schreiber wrote

The MSEgui socket components (and the pipe reader and RS232 components too BTW) implement the model Michael describes.

For Delphi we (company) use AsyncPro (as well for RS232 as for TCP/IP) (Initially provided commercially by TurboPower, but free and open source now). Unfortunately this is Windows only and porting it it Lazarus (Linux) would require a decent amount of work.

-Michael

I have used the AsyncPro com port also and I noted that there is a TCP/IP version of the com port as well (ApdWinsockPort) such that using this in Delphi would make it possible to just switch from one to the other by setting a property.

I once tried to look at the dependencies in order to cut down on the number of needed units for my usage of the serial port, but it just chained wider and wider so the task became insurmountable.

I tried to find instructions on how to use Indy in Lazarus/FPC but what I found was very old and incomplete...
http://wiki.freepascal.org/Indy_with_Lazarus
http://www.indyproject.org/sockets/fpc/index.en.aspx

Bo Berglund wrote

I have used the AsyncPro com port also and I noted that there is a TCP/IP version of the com port as well (ApdWinsockPort) such that using this in Delphi would make it possible to just switch from one to the other by setting a property.

It would be grate to have a Lazarus Linux version of AsyncPro, but I don't have much hope...

-Michael

Bo Berglund wrote

I tried to find instructions on how to use Indy in Lazarus/FPC but what I found was very old and incomplete...

I've used Indy with FPC for years, in the tiOPF's 3-tier code. Tested under Windows, Linux and FreeBSD. Usage was identical compared to Delphi+Indy.

The only difference I remember was with server components (eg: HTTP Server) which required root access to open the port, because the port was below 1024. Using ports higher than 1024 could be run as a normal user.

Regards,
- Graeme -

I've done a lot with AsyncPro for about 27 years or so. About six months ago I helped a company add Ethernet to their serial support using the ApdWinsockPort which works well.

www.CtrlTerm.com uses Synapse for both serial and TCP/IP but it isn't as nice as AsyncPro but if someone wants to hire me... :)

See the bottom of this page for more info:
http://turbocontrol.com/APro.htm

So do I take it as:

1) I check out the Indy 10.5.7 sources (Core, Protocols, System) like I always do with new installs of Delphi into some subfolder of FPC. (WE keep the 10.5.7 version in our own version control in order to get some consistency in our development)

2) I add the path to these locations to somewhere in FPC or Lazarus. Where is this done???

3) Then I start using the Indy stuff in my application. Just add the proper units into the uses clause of teh applications as needed.

Is this the way to go?

Bo Berglund wrote

Is this the way to go?

I'm using Indy 10.2.0.3 (the FPC & Lazarus version downloaded from their website). I don't know if they merged those changes into their latest code repository version. I would imagine they did. I haven't looked at Indy's website in ages to see if there is anything newer, but from the version number you quoted I guess there is. ;-)

Then simply add the <indy>/fpc/ path to your project's "Unit Path" and "Include Path" and away you go. I don't bother installing most components into Lazarus's component palette. I simply instantiate the classes I need in my code and go from there.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I'm using Indy 10.2.0.3 (the FPC & Lazarus version downloaded from their website).

Sorry, I forgot to post the link to Indy's exact page.

http://www.indyproject.org/Sockets/fpc/index.EN.aspx

Regards,
- Graeme -

Bo Berglund wrote

1) I check out the Indy 10.5.7 sources (Core, Protocols, System) like I always do with new installs of Delphi into some subfolder of FPC. (WE keep the 10.5.7 version in our own version control in order to get some consistency in our development)

I just had a look... From what I can see on their support newsgroup [news://news.atozed.com/atozedsoftware.indy.fpc], Indy 10.5.9 also works with FPC. Seems I need to upgrade at some point. :)

Regards,
- Graeme -

Thanks,
I will try this.
Regarding Indy10 I got the 10.5.7 from Fulgan in 2010 when I decided to freeze my versions for compatibility across IDE:s.

The current version on the Fulgan server, which is the one one gets to from your posted link is 10.6.2.0 (and a nightly build at that) i.e. the bleeding edge.
I'd rather stay with 10.5.7 as long as possible.

Bo Berglund wrote

I will try this.

I checked out the Indy10 version from our own version control into a new CMP folder for FPC.
Then added the Core, Protocols and System subfolders to the project search path after creating a new Console project.

I added code into the DoRun procedure of the new project so it looks
like this:
[code]
procedure TSSCommTest.DoRun;
var
  FComm: TIdTCPClient;
  T1, T2: Cardinal;
begin
  { add your program here }
  Writeln('Creating TCP client');
  FComm := TIdTCPClient.Create;
  try
    Writeln('Connecting to 10.0.0.7 on port 2401 (CVS)');
    T1 := GetTickCount;
    FComm.Connect('10.0.0.7', 2401);
    T2 := GetTickCount;
    T2 := T2 - T1;
    Writeln('Connection succeeded in ' + IntToStr(T2) + ' ms, now
closing down');
  finally
    if FComm.Connected then
       FComm.Disconnect;
    FComm.Free;
  end;
  // stop program loop
  Writeln('End of run');
  Terminate;
end;
[/code]
It compiled fine after I added Windows (for GetTickCount) and
IdTCPClient to the uses clause.

Then I ran it and could see this:

D:\Engineering\Projects\Lazarus\TCPIPTST>SSTCPTest.exe Creating TCP client
Connecting to 10.0.0.7 on port 2401 (CVS)
Connection succeeded in 62 ms, now closing down
End of run

So I say that this is milestone #1 on my way.
Now I have to create a server too and check comm between them. But that will probably be OK....

Thanks for the info!
I planned on going with RaspBian for this project. :)

The only caveat here would be if Indy10 will actually build and function correctly in RaspBian.
I will find that out in due time. I don't have the hardware available right now since I am travelling, will purchase a dedicated Pi2B as soon as I return to home base.

Since you plan to port to Linux a word of caution: the "Windows" unit doesn't exist there (and "GetTickCount" does neither), so you either need to use platform specific functionality from the "BaseUnix" unit or cross platform one from "SysUtils" and friends.
You should maybe also tale a look into using conditional compilation using "$ifdef" and the defines the compiler already provides for you (e.g. "windows", "linux", "unix", "cpui386", "cpuarm", etc.). Note: in 3.0.0 TThread provides the cross platform class functions TThread.GetTickCount and TThread.GetTickCount64.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150924/b6bef0fa/attachment-0001.html>

Bo Berglund wrote

The only caveat here would be if Indy10 will actually build and function correctly in RaspBian.

Does you project including Indy 10 already run decently on PC-Linux ?

-Michael

IMHO milestone #2 should be to run the same project on a Linux PC

-Michael

GetTickCount(64) exists in sysutils.

Which simply refer to sysutils.getTickCount(64).

Michael.

using

Ehm right... I forgot about them despite having added them myself. :P Like TThread.GetTickCount(64) however they are only available in 3.0.0 and newer (they were added at the same time as the TThread ones).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150924/bfb512d3/attachment.html>

Indeed. That is why I was slightly surprised to read your answer :)

Michael.

I blame that my mind is filled by generics and dynamic packages, there's no place anymore to remember such a small insignificant function :P

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150924/c68b21ac/attachment.html>

Exactly!
But I will first build a decent simulation server on Windows so I have something to talk to while developing the application. I cannot keep the data collection system on hand during that phase. My first test was aginst our CVS server on port 2401....

I know...
I only added the GetTickCount in order to get something to display with connection timing info. The test server is across a VPN channel into the company network about 1500 miles away. So 62 ms is acceptable.

You should maybe also take a look into using conditional compilation using "$ifdef" and the defines the compiler already provides for you (e.g. "windows", "linux", "unix", "cpui386", "cpuarm", etc.).

Right you are!
BTW is there a define for FPC itself too so I can differentiate between Delphi and FPC? THat way I could possibly use the exact same sources and not have to make a copy.
Maybe there is a complete list of the defines in FPC?

Note: in 3.0.0 TThread provides the cross platform class functions TThread.GetTickCount and TThread.GetTickCount64.

Is FPC 3.0 stable yet and does it exist on ARM?

Bo Berglund wrote

into the company network about 1500 miles away. So 62 ms is acceptable.

If only we could travel that fast! :)

BTW is there a define for FPC itself too so I can differentiate between Delphi and FPC?

Yes, "FPC". ;-)

{$ifdef FPC}...{$ELSE}...<delphi stuff>...{$endif}

There is also FPC versions which include major, minor etc.

Regards,
- Graeme -

Bo Berglund wrote

My first test was aginst our CVS server on port 2401....

Just for testing if a socket can receive data you can use any server in the Internet port 80 :-)

-Michael

Michael Schnell wrote

any server in the Internet port 80 :-)

or even better set up the Linux that you will need anyway. Linux always comes with telnet to a command line installed. You just need to activate it.

-Michael

"Bo Berglund" wrote

>You should maybe also take a look into using conditional compilation

using

The define is "FPC" ;)
The most important defines are available in the programmer's guide: http://www.freepascal.org/docs-html/prog/progap7.html#x333-348000G

We have already released the RC and thus only small fixes are still expected to take place. AFAIK I've also seen a RC for the RPi somewhere...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150924/4a400f7b/attachment.html>

I suppose the (RC-) release milestone is for all platforms.

Is there a date for an "official" 3.x release ?

-Michael

Before 2016? :)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150925/1049b2f0/attachment.html>

Sven Barth wrote

Before 2016? :)

Great ! (sauf the question mark) ;)

-Michael

Sorry,
I left this hanging....
The existing Windows/Delphi project does not use TCP/IP at all for communicating with the data collection system. It uses serial comm and it has not been ported to FPC/Lazarus yet.