Using Lazarus on Embedded Linux?

[Bo Berglund]

I am new to this list and I would like to get advice on the capabilities of Lazarus.
My background is 15 years of Delphi programming (almost all versions Delphi1 to BDS2006).
For the upcoming project I want to keep using Pascal if possible rather than learn
and get productive in Java....

So:

1) Can I work in Windows or Ubuntu on the same project? I.e. are there differences
in the IDE/compiler between the two work environments?
We use CVS to handle the sourcecode so checking in/out will handle the line ending
differences between Windows and Unix. But are there other caveats?

2) Can I compile in either environment for a third runtime platform?
I am especially looking for a GUI programming environment where the target system
is Embedded Linux on ARM or Atom platform boards.

3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?
The target is an embedded board that is intended to communicate with a data acquisition
system via RS232 (38400 baud, binary proprietary protocol).

4) The programs planned will also need to produce graphic rendering of the data
retrieved from the acquisition system, so what is the graphic capabilities of
Lazarus/FPC on the Linux platform?

5) Can data be stored on memory cards/hard disk on an embedded system?

TIA

BosseB


--

[Michael Van Canneyt]

Post by Bo Berglund
I am new to this list and I would like to get advice on the capabilities of Lazarus.
My background is 15 years of Delphi programming (almost all versions Delphi1 to BDS2006).
For the upcoming project I want to keep using Pascal if possible rather than learn
and get productive in Java....
1) Can I work in Windows or Ubuntu on the same project? I.e. are there differences
in the IDE/compiler between the two work environments?

No. Linking is slightly slower on windows.

Post by Bo Berglund
We use CVS to handle the sourcecode so checking in/out will handle the line ending
differences between Windows and Unix. But are there other caveats?

None to my knowledge.

Post by Bo Berglund
2) Can I compile in either environment for a third runtime platform?

Yes, but not easily.

Post by Bo Berglund
I am especially looking for a GUI programming environment where the target system
is Embedded Linux on ARM or Atom platform boards.

I recommend Lazarus on Ubuntu, cross-compile to arm. There is a FAQ available.

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

There is the serial unit.

Post by Bo Berglund
The target is an embedded board that is intended to communicate with a data acquisition
system via RS232 (38400 baud, binary proprietary protocol).
4) The programs planned will also need to produce graphic rendering of the data
retrieved from the acquisition system, so what is the graphic capabilities of
Lazarus/FPC on the Linux platform?

Virtually the same as at least Delphi 7.

Post by Bo Berglund
5) Can data be stored on memory cards/hard disk on an embedded system?

If the card/disk is mounted, it is just like writing any other file.

Michael.

--

[Bo Berglund]

Post by Michael Van Canneyt

Post by Bo Berglund
1) Can I work in Windows or Ubuntu on the same project? I.e. are there differences
in the IDE/compiler between the two work environments?

No. Linking is slightly slower on windows.

What I really wanted to know is if it is possible to work in Windows and still
make the program run in both Windows and Linux. If that is not possible then
the next way would be to develop in one side, check in the code, open the
other side and update the code and finally load and compile on that other side.
So for this to work there must be no differences between the code on Windows and on Linux...

Post by Michael Van Canneyt

Post by Bo Berglund
2) Can I compile in either environment for a third runtime platform?

Yes, but not easily.

Where is it easier to compile for an embedded board? On Ubuntu maybe because there
one is already in Linux???

Post by Michael Van Canneyt

Post by Bo Berglund
I am especially looking for a GUI programming environment where the target system
is Embedded Linux on ARM or Atom platform boards.

I recommend Lazarus on Ubuntu, cross-compile to arm. There is a FAQ available.

Almost answers the previous question!

Post by Michael Van Canneyt

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

There is the serial unit.

Is it the same on Linux and Windows?

Post by Michael Van Canneyt

Post by Bo Berglund
4) The programs planned will also need to produce graphic rendering of the data
retrieved from the acquisition system, so what is the graphic capabilities of
Lazarus/FPC on the Linux platform?

Virtually the same as at least Delphi 7.

That is good, my main work platform the last decade or so...

BosseB


--

[Michael Van Canneyt]

Post by Bo Berglund

Post by Michael Van Canneyt

Post by Bo Berglund
1) Can I work in Windows or Ubuntu on the same project? I.e. are there differences
in the IDE/compiler between the two work environments?

No. Linking is slightly slower on windows.

What I really wanted to know is if it is possible to work in Windows and still
make the program run in both Windows and Linux. If that is not possible then
the next way would be to develop in one side, check in the code, open the
other side and update the code and finally load and compile on that other side.
So for this to work there must be no differences between the code on Windows and on Linux...

If you don't use windows-isms, the code should compile as-is on all platforms.

Just stick to the provided cross-platform units and all should work out of the box.

If you do have code that is low level and os-dependent, put it in a single
unit, for easy porting.

Post by Bo Berglund

Post by Michael Van Canneyt

Post by Bo Berglund
2) Can I compile in either environment for a third runtime platform?

Yes, but not easily.

Where is it easier to compile for an embedded board? On Ubuntu maybe because there
one is already in Linux???

Ubuntu because in my opinion it will be easier to set up a cross-compiling environment.
(all needed libraries for the embedded system must be present)

Post by Bo Berglund

Post by Michael Van Canneyt

Post by Bo Berglund
I am especially looking for a GUI programming environment where the target system
is Embedded Linux on ARM or Atom platform boards.

I recommend Lazarus on Ubuntu, cross-compile to arm. There is a FAQ available.

Almost answers the previous question!

Post by Michael Van Canneyt

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

There is the serial unit.

Is it the same on Linux and Windows?

The interface is the same.

Michael.

--

[Sven Barth]

Post by Michael Van Canneyt

Post by Bo Berglund

Post by Michael Van Canneyt

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

There is the serial unit.

Is it the same on Linux and Windows?

The interface is the same.

It isn't, cause there isn't a serial.pp for Windows (at least not in
2.5.1 from some weeks ago). :)

Regards,
Sven

--

[Luis R. Hilario B.]

Hello,

You can find a version for Windows here:
http://www.luisdigital.com/programacion/fpc/serial.pp

Post by Bo Berglund

Post by Michael Van Canneyt

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

There is the serial unit.

Is it the same on Linux and Windows?

[Sven Barth]

Post by Luis R. Hilario B.
Hello,
http://www.luisdigital.com/programacion/fpc/serial.pp

Could this unit be integrated into FPC, so that one doesn't need to find
that one? (I didn't know that such a unit already existed till now ^^ )

Regards,
Sven

--

[Michael Schnell]

Post by Bo Berglund
What I really wanted to know is if it is possible to work in Windows and still
make the program run in both Windows and Linux.

As Lazarus (especially the debugger) runs better in Linux than in
Windows this does not make much sense. Of course doing a program that
can be compiled for all platforms does make sense :).

-Michael

--

[Bo Berglund]

Post by Luis R. Hilario B.

Post by Bo Berglund

Post by Michael Van Canneyt

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

There is the serial unit.

Is it the same on Linux and Windows?

http://www.luisdigital.com/programacion/fpc/serial.pp

Thanks,
I saved the unit file to my PC now.

Just an hour or so ago I downloaded and installed Lazarus 0.9.28.2 on my Win XP-Pro
development machine for the first time.
I opened the IDE and added serial to the uses clause of the default project and tried
to compile.
Of course the compiler could not find the serial.pp file....

This raises the following questions:

1) Where should the external source like serial.pp be put so Lazarus can find it?
I assume I don't have to copy it into each and every project I make, so there should
be a special place for these type of files...

2) I am used in Delphi 7 to manage my project files in various project directories
by going to ProjectOptions/DirectoriesConditionals/SearchPath and entering my
project folders with relative paths from the project file.
Can this be done also in Lazarus, if so where?

About serial.pp:
----------------
How can I set the communications buffer size? I would like it to be something like
16Kbytes to accommodate the protocol being used.

I have used the Turbo Power Async Pro components in the past (without actually
putting them on a form, instead I intantiate the objects in code). They expose
various settings like the buffer size and also others that I have used to optimize
the communications.

In the serial.pp unit it seems like there is no object created that could hold
the serial connection data, it just looks like a collection of procedures...

Is there not an object oriented type of serial communications container for Lazarus?

--
Bo Berglund


--

[Paul Breneman]

I've also replied to you FPC mailing list messages.

This won't answer all of your questions but I hope it will help:
http://www.turbocontrol.com/embeddedfreepascal.htm

I'd be glad to discuss this in more detail.

For some serial code, look for "Simple Serial" on this page:
http://www.turbocontrol.com/monitor.htm
--
Regards,
Paul Breneman
www.dbReplication.com - VCL database replication components
www.TurboControl.com - Hardware and software development services
- Educational programming project for environment monitoring
- Information on using FreePascal for embedded systems
- Support information for the TurboPower open source libraries

--

[Bo Berglund]

Looks like the freepascal site is down at the moment.
No replies have been relayed over to the GMane news server,
which I use to monitor the activity...
And I cannot connect to the list server to change my maile
delivery options (have to enable mail to get the responses).

I am replying to this with Outlook 2003, hence the strange
formatting.

Thanks for your links, look quite interesting!
I will for sure be back with more questions.
Now my next task after setting up Lazarus on Windows I will
try to do the same on Ubuntu.
Any suggested version of Ubuntu recommended?
And is sudo apt install lazarus all one need to do to get
it on Ubuntu or is there a more complex method required?

Bo Berglund

-----Original Message-----
From: Paul Breneman [mailto:***@BrenemanLabs.com]
Sent: Saturday, September 25, 2010 6:17 PM
To: Lazarus mailing list
Subject: Re: [Lazarus] Using Lazarus on Embedded Linux?

I've also replied to you FPC mailing list messages.

This won't answer all of your questions but I hope it will help:
http://www.turbocontrol.com/embeddedfreepascal.htm

I'd be glad to discuss this in more detail.

For some serial code, look for "Simple Serial" on this page:
http://www.turbocontrol.com/monitor.htm

[Paul Breneman]

Hi Bo,

You might look here first:
http://www.turbocontrol.com/simpleserial.htm

There are 3 small zips there that you can use to compile the same
program under Windows, Linux Desktop, and embedded Linux on
OABI-compatible ARM systems.

I've been able to avoid the complexity of cross-compiling by compiling
directly on my ARM device (using NFS so all the files aren't stored on
the device).

I'm doing development of GUI programs (using fpGUI) on 3 systems in the
same manner as the "Simple Serial" distros. Actually, I'm also using a
4th system to cross-compile for WinCE, see the WinCE distro here:
http://www.turbocontrol.com/helloworld.htm

Regards,
Paul

--

[Bo Berglund]

Post by Paul Breneman
I've also replied to you FPC mailing list messages.
http://www.turbocontrol.com/embeddedfreepascal.htm

Wow! This looks exactly like the product I have been looking around for!
Except their datasheet links are broken so I cannot get detailed info
on the unit. :-(

One particularly important piece of information is the size of the
screen (outside dimensions) so we can see if it will fit into the given
space.
Maybe you have info on this, since you have used it?

Post by Paul Breneman
I'd be glad to discuss this in more detail.

Thanks for your offer! I will surely take you on your words and come back
once I have set up a working Lazarus system on both Win XP and Ubunttu so
I can verify that it is indeed possible to talk to our equipment via RS232.
I will use the examples posted here as a starting point for a very simple
comm program to see if I can get the data out of the serial link.
Then I need to dig down deep into the cross-compilation problems for the
target board and then your advice will be vey vluable indeed!

Post by Paul Breneman
http://www.turbocontrol.com/monitor.htm

I have downloaded it and tried to open it in Lazarus, but there seems not
to be a project file that Lazarus recognizes. :-(

If I try to open the pas file Lazarus offers to create a project for me
but then I don't know what to enter in the following dialogs so I gave
up....
Is it really a Lazarus project at all???

I did a command line compile as directed on the webpage and it produced
an exe file that looks like a console application, so I guess that it
compiles
like that in any case. It listed my two com ports and then ended.

Have to study the "Getting Started" docs for Lazarus to get the basics
in place. Once that is done I hope not much will differ from developing
in Delphi 7 so I can get productive fairly soon...

Post by Paul Breneman
Regards,
Paul Breneman

--

[Paul Breneman]

Post by Bo Berglund

Post by Paul Breneman
I've also replied to you FPC mailing list messages.
http://www.turbocontrol.com/embeddedfreepascal.htm

Wow! This looks exactly like the product I have been looking around for!
Except their datasheet links are broken so I cannot get detailed info
on the unit. :-(
One particularly important piece of information is the size of the
screen (outside dimensions) so we can see if it will fit into the given
space.
Maybe you have info on this, since you have used it?

I don't have access to the hardware at the moment so I can't help you on
the dimensions. But Technologic Systems is a great company that has
been around for a very long time so I'm sure you can get that info from
them on Monday.

Post by Bo Berglund

Post by Paul Breneman
I'd be glad to discuss this in more detail.

Thanks for your offer! I will surely take you on your words and come back
once I have set up a working Lazarus system on both Win XP and Ubunttu so
I can verify that it is indeed possible to talk to our equipment via RS232.
I will use the examples posted here as a starting point for a very simple
comm program to see if I can get the data out of the serial link.
Then I need to dig down deep into the cross-compilation problems for the
target board and then your advice will be vey vluable indeed!

Glad to help as I'm able. The info and code I've posted is my way of
contributing to the FreePascal and Lazarus effort. I would be glad to
see more embedded use. In the near future I'd even like to start using
FreePascal with no OS:
http://wiki.freepascal.org/TARGET_Embedded

I'm also keeping tabs on ToroOS (written with FreePascal) and ReactOS as
those might come in handy for embedded use in the future.

Post by Bo Berglund

Post by Paul Breneman
http://www.turbocontrol.com/monitor.htm

I have downloaded it and tried to open it in Lazarus, but there seems not
to be a project file that Lazarus recognizes. :-(
If I try to open the pas file Lazarus offers to create a project for me
but then I don't know what to enter in the following dialogs so I gave
up....
Is it really a Lazarus project at all???
I did a command line compile as directed on the webpage and it produced
an exe file that looks like a console application, so I guess that it
compiles
like that in any case. It listed my two com ports and then ended.
Have to study the "Getting Started" docs for Lazarus to get the basics
in place. Once that is done I hope not much will differ from developing
in Delphi 7 so I can get productive fairly soon...

Those zip files are actually minimal distributions of FreePascal so they
contain the compiler and everything needed to compile the console
application. If the protocol of your device isn't too complicated it
might be easy to modify the program to talk with your device. That
might be worth doing just so you have the serial equivalent of a "hello
world" app that you can try on Windows, Linux desktop, and an embedded
Linux ARM device.

On my "hello world" page I do have a minimal disto with fpGUI and the
FreePascal WinCE cross-compiler. I'd like to release 3 more minimal
distros for fpGUI as those would make it easy to try fgGUI.

I'm not using Lazarus at this time because I think GTK would run too
slow on the slow ARM devices I'm using. Plus, using Lazarus (even with
fpGUI) would probably force me to use a cross-compile environment which
so far I've been able to avoid (except for WinCE).

If I can get an inexpensive ARM device powerful enough to run Lazarus it
might be nice to try using that to compile ARM programs directly without
cross-compiling. Here is something I'm considering but it still looks
under-powered:
http://www.windowsfordevices.com/c/a/News/CVS-Sylvania-netbook/?kc=rss

So many options, so little time... :)

--

[Bo Berglund]

Sent: Sunday, September 26, 2010 3:13 PM

Post by Bo Berglund

Post by Paul Breneman
I've also replied to you FPC mailing list messages.
http://www.turbocontrol.com/embeddedfreepascal.htm

Wow! This looks exactly like the product I have been
looking around for!

Technologic Systems is a great company that has
been around for a very long time so I'm sure you can get that
info from them on Monday.

I just ordered a TS-TPC-7390 from them (including dev kit).
Can't wait to get my hands on it.
Will I be able to install Lazarus on it or do I cross-compile
from my Ubuntu machine?

Post by Bo Berglund

Post by Paul Breneman
I'd be glad to discuss this in more detail.

Good :-)

--

Bo B


--

[Paul Breneman]

Post by Bo Berglund

Sent: Sunday, September 26, 2010 3:13 PM

Post by Bo Berglund

Post by Paul Breneman
I've also replied to you FPC mailing list messages.
http://www.turbocontrol.com/embeddedfreepascal.htm

Wow! This looks exactly like the product I have been
looking around for!

Technologic Systems is a great company that has
been around for a very long time so I'm sure you can get that
info from them on Monday.

I just ordered a TS-TPC-7390 from them (including dev kit).
Can't wait to get my hands on it.
Will I be able to install Lazarus on it or do I cross-compile
from my Ubuntu machine?

I think it is too slow to use Lazarus on the embedded system itself.
You could try cross-compiling programs and see how that works.

I've only used console and fpGUI programs on my TS-TPC-7390, and I
compile those directly on the device itself (but using a NFS server on
an old PC).

Please let me know how it goes.

--

[Michael Schnell]

Post by Paul Breneman
I think it is too slow to use Lazarus on the embedded system itself.
You could try cross-compiling programs and see how that works.
I've only used console and fpGUI programs on my TS-TPC-7390, and I
compile those directly on the device itself (but using a NFS server on
an old PC).

Did you get remote debugging (via TCP/IP) in Lazarus running running ?

Thanks,
-Michael

--

[Michael Schnell]

Post by Bo Berglund
I have used the Turbo Power Async Pro components in the past (without actually
putting them on a form, instead I intantiate the objects in code).

Same here. I intend to port Async Pro to Lazarus/Linux/ARM, once we
start working on the project (which we are raving about since years, so
don't hold your breath ;) )

-Michael

--

[Paul Breneman]

Hi Michael,

... I intend to port Async Pro to Lazarus/Linux/ARM, once we
start working on the project (which we are raving about since years, so
don't hold your breath ;) )

I've spent many years with AsyncPro (even 5 years as an APro TPX person)
and I would not recommend porting APro. It has too much legacy code in
too many layers and is full of Win32 oddities. But maybe you've dug
into this a bit and see a way to port just the higher layers?

I do have threaded code using SynaSer on Linux that is almost identical
to threaded code on Win32 that is compatible with APro and SynaSer so I
can switch between the two libraries on Windows. Of course that is just
for basic serial port stuff. If you need protocols or other APro
features that makes things more difficult.
--
Regards,
Paul Breneman
www.dbReplication.com - VCL database replication components
www.TurboControl.com - Hardware and software development services
- Educational programming project for environment monitoring
- Information on using FreePascal for embedded systems
- Support information for the TurboPower open source libraries

--

[Bo Berglund]

Sent: Tuesday, September 28, 2010 1:24 AM
Hi Michael,

... I intend to port Async Pro to Lazarus/Linux/ARM, once we
start working on the project (which we are raving about since years, so
don't hold your breath ;) )

I've spent many years with AsyncPro (even 5 years as an APro TPX person)
and I would not recommend porting APro. It has too much legacy code in
too many layers and is full of Win32 oddities. But maybe you've dug
into this a bit and see a way to port just the higher layers?
I do have threaded code using SynaSer on Linux that is almost identical
to threaded code on Win32 that is compatible with APro and SynaSer so I
can switch between the two libraries on Windows. Of course that is just
for basic serial port stuff. If you need protocols or other APro
features that makes things more difficult.

Well, I am not really fond of AsyncPro because of the heaviness of the
code but I have not found a good Delphi package alternative, which is
either stable or maintained so we are using it still with D7.

We only use the minimum functionality of AP though:
- The TApdComPort object
- Properties for setting port, baud, bits, parity, handshake etc
- Properties for handling the buffer size
- Methods/Events for sending and receiving byte data
- We also use the possibility to switch from serial to TCP/IP

But that is about it. We never ever used any of the other functionality
of AP like the different protocols and stuff. Just the simple port.

And that is what I would like to have also with FPC/Lazarus. I could even
live without the TCP/IP mode.

So if you have code to implement the simple serial comm system outlined
above I'd be very interested to try that out.

My immediate application calls for communicating with a data acquisition
device with a binary data transfer protocol, so I need all 256 byte codes
to pass transparently through to my application. There must be no
interception
based on data values. Example of packet structure:
<type><blocklength><data><crc>
All binary of course.

What do you think?


--

[Mark Morgan Lloyd]

Post by Bo Berglund
But that is about it. We never ever used any of the other functionality
of AP like the different protocols and stuff. Just the simple port.
And that is what I would like to have also with FPC/Lazarus. I could even
live without the TCP/IP mode.
So if you have code to implement the simple serial comm system outlined
above I'd be very interested to try that out.
My immediate application calls for communicating with a data acquisition
device with a binary data transfer protocol, so I need all 256 byte codes
to pass transparently through to my application. There must be no
interception
<type><blocklength><data><crc>
All binary of course.

On Windows, we use (an older version of) Dejan Crnila's TComPort. On
Linux I'm currently using FPC's standard serial unit, wrapped in a
class. In both cases I've hacked things a bit to expose a few extra
facilities, e.g. to make sure I can get at both Ring and CD and to do
reads with timeouts.

In my opinion most comms libraries got top-heavy with facilities to
handle things like call control and faxing which should have been
completely separate layers. However my interest is interfacing with
scientific instruments etc. rather than the minutae of VT-100 emulation,
other people might disagree. I've also got some very definite ideas on
modem handling and have the equipment to monitor traffic, and I don't
want anything getting in the way.

I presume you're aware of Wolfgang Erhardt's Pascal CRC code, so I won't
mention it here :-)

[Michael Schnell]

Post by Bo Berglund
What do you think?

Creating a new portable package from scratch that provides those parts
of AsyncPro's user program API you need would be great. Same could be
enhanced with additional features whenever necessary.

The primarily essential part of AsyncPro's basic functionality is the
thread based buffer handling. By this the AsyncPro "Events" can be
handled by the main Thread of the application and thus in an "even
driven Object-Pascal" way, freeing the user from dealing with threads
himself.

This now needs a portable "backend" of inter-thread notification. This
can be done with messages (such as AsyncPro works).

Using the LCL "Windows", "KDE" or "Gnome" Widget set ,this can be done
by PostMessage (SendMessage) and "Procedure ... Message". Unfortunately
the non GUI-based Widget sets ("NoGUI", "FPGUI", etc") don't seem to
support this (yet) (no idea about Mac). I feel this is a big
short-coming for "Using Lazarus on Embedded Linux". Maybe SyncOBJs can
be used in a more portable way to achieve the same goal.

-Michael

--

[Graeme Geldenhuys]

Using the LCL "Windows", "KDE" or "Gnome" Widget set ,this can be done by
PostMessage (SendMessage) and "Procedure ... Message". Unfortunately the non
GUI-based Widget sets  ("NoGUI", "FPGUI", etc") don't seem to support this
(yet) (no idea about Mac).

Just to correct you there. fpGUI does have PostMessage() and
SendMessage() support. If it's implemented in the LCL-fpGUI widgetset
layer is another story, but using fpGUI directly, it is available.
--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/

--

[Michael Schnell]

Post by Graeme Geldenhuys
Just to correct you there. fpGUI does have PostMessage() and
SendMessage() support. If it's implemented in the LCL-fpGUI widgetset
layer is another story, but using fpGUI directly, it is available.

This is GREAT ! Since when is this available (and tested) ? How is it
implemented ?

Thanks,
-Michael


--

[Graeme Geldenhuys]

Post by Michael Schnell
This is GREAT ! Since when is this available (and tested) ? How is it
implemented ?

Sending or Posting internal message (inside the application) and
Procedure...Message has been implemented since years ago. fpGUI
maintains its own internal event queue. This is how fpGUI notifies any
widget/window of OS or internal events. Sending external events are
handled in each backend platform API's code.
--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/

--

[Michael Schnell]

Post by Graeme Geldenhuys
Sending or Posting internal message (inside the application) and
Procedure...Message has been implemented since years ago. fpGUI
maintains its own internal event queue. This is how fpGUI notifies any
widget/window of OS or internal events. Sending external events are
handled in each backend platform API's code.

Due to a request in the German Forum, I re-tested PostMessage the KDE
Widget Set and it did not work any more. I am quite sure that it did
work some months ago :(.

-Michael

--

[Michael Schnell]

Post by Paul Breneman
I've spent many years with AsyncPro (even 5 years as an APro TPX
person) and I would not recommend porting APro.

I agree, but we have a huge system of programs that use AsycPro and
would need to be ported to Linux. So providing Async Pro's user-program
API to the user programmers is the only viable option.

-Michael


--

[Michael Schnell]

On 09/25/2010 09:07 AM, Bo Berglund wrote:

5) Can data be stored on memory cards/hard disk on an embedded system?


P.S.:
Not a Lazarus problem but...

Using Flash Cards on an embedded system is a huge security risk.

After writing to the card, same performs the storage procedure internally which takes a undefined amount of time and can't be watched from outside. So you don't know how long you need to apply power to the card after switching off the system. If you remove the power to the card too early, _all_ (even unrelated) data on the card might be lost. This is why using a special file system (a Flash File system and/or a journaling file system) does not help.

So only battery powered embedded systems (like cameras) are viable for writing to flash cards: they never switch off the power unexpectedly.

-Michael


--

[Henry Vermaak]

Post by Bo Berglund
5) Can data be stored on memory cards/hard disk on an embedded system?
Not a Lazarus problem but...
Using Flash Cards on an embedded system is a huge security risk.
After writing to the card, same performs the storage procedure
internally which takes a undefined amount of time and can't be watched
from outside. So you don't know how long you need to apply power to the
card after switching off the system. If you remove the power to the card
too early, _all_ (even unrelated) data on the card might be lost. This
is why using a special file system (a Flash File system and/or a
journaling file system) does not help.

See sync, fsync, fdatasync, etc. You can also mount some filesystems
with sync, but that's usually not a good idea for performance and flash
cycle issues. Best is to remove the power only after your kernel has
powered down, obviously, so you know that all the buffers have been flushed.

Why do you think all data will be lost with a journalling file system?

Post by Bo Berglund
So only battery powered embedded systems (like cameras) are viable for
writing to flash cards: they never switch off the power unexpectedly.

The battery can run out or the user can pull it out.

Henry

--

[Mark Morgan Lloyd]

Post by Henry Vermaak

Post by Michael Schnell
After writing to the card, same performs the storage procedure
internally which takes a undefined amount of time and can't be watched
from outside. So you don't know how long you need to apply power to the
card after switching off the system. If you remove the power to the card
too early, _all_ (even unrelated) data on the card might be lost. This
is why using a special file system (a Flash File system and/or a
journaling file system) does not help.

See sync, fsync, fdatasync, etc. You can also mount some filesystems
with sync, but that's usually not a good idea for performance and flash
cycle issues. Best is to remove the power only after your kernel has
powered down, obviously, so you know that all the buffers have been flushed.

I think I'd like to see a clarification from Michael here: did he mean
that the kernel/filesystem/drivers take an indefinite time committing
the data or that the card takes an indefinite time after receiving data
from the operating system?

The first of those can at least be initiated using a sync() call, and
it's reasonable to assume that a filesystem designed for the purpose
won't get screwed if the driver finds it can no longer talk to the
storage device. However if the storage device itself is susceptible to
errors caused by power removal that is far more sinister.

We have equipment scattered around Europe, and the reliability of the
power sources on industrial sites is far worse than most people
appreciate. A common scenario is where our kit is wired to a supply that
intermittently runs a pump or similar, i.e. sometimes it sees 230V but
most of the time it doesn't.

[Henry Vermaak]

Post by Mark Morgan Lloyd

Post by Michael Schnell
After writing to the card, same performs the storage procedure
internally which takes a undefined amount of time and can't be watched
from outside. So you don't know how long you need to apply power to the
card after switching off the system. If you remove the power to the card
too early, _all_ (even unrelated) data on the card might be lost. This
is why using a special file system (a Flash File system and/or a
journaling file system) does not help.

See sync, fsync, fdatasync, etc. You can also mount some filesystems
with sync, but that's usually not a good idea for performance and
flash cycle issues. Best is to remove the power only after your kernel
has powered down, obviously, so you know that all the buffers have
been flushed.

I think I'd like to see a clarification from Michael here: did he mean
that the kernel/filesystem/drivers take an indefinite time committing
the data or that the card takes an indefinite time after receiving data
from the operating system?
The first of those can at least be initiated using a sync() call, and
it's reasonable to assume that a filesystem designed for the purpose
won't get screwed if the driver finds it can no longer talk to the
storage device. However if the storage device itself is susceptible to
errors caused by power removal that is far more sinister.

The only delay I can see (after fsync) would be due to the hardware
cache of the disk in use (or a defective drive). On linux you can call
hdparm to flush on-disk caches.

Henry

--

[Mark Morgan Lloyd]

Post by Henry Vermaak

Post by Mark Morgan Lloyd
The first of those can at least be initiated using a sync() call, and
it's reasonable to assume that a filesystem designed for the purpose
won't get screwed if the driver finds it can no longer talk to the
storage device. However if the storage device itself is susceptible to
errors caused by power removal that is far more sinister.

The only delay I can see (after fsync) would be due to the hardware
cache of the disk in use (or a defective drive). On linux you can call
hdparm to flush on-disk caches.

But is hdparm fully supported by external Flash cards, and does it
return before or after data is guaranteed to be filly committed?

I suspect that the answer to this is going to depend on what the card
"looks like" and how it's connected.

[Henry Vermaak]

Post by Mark Morgan Lloyd

Post by Henry Vermaak

Post by Mark Morgan Lloyd
The first of those can at least be initiated using a sync() call, and
it's reasonable to assume that a filesystem designed for the purpose
won't get screwed if the driver finds it can no longer talk to the
storage device. However if the storage device itself is susceptible to
errors caused by power removal that is far more sinister.

The only delay I can see (after fsync) would be due to the hardware
cache of the disk in use (or a defective drive). On linux you can call
hdparm to flush on-disk caches.

But is hdparm fully supported by external Flash cards, and does it
return before or after data is guaranteed to be filly committed?

This is a red herring (sorry, my mistake). Compact flash cards (and
other removable media) are block devices, they have firmware that do
this flash to block emulation. I realise now that Michael meant that
some cf cards have crappy firmware that can't handle power cuts. There
isn't much you can do about that, but choose a good cf card or usb stick.

Henry

--

[Mark Morgan Lloyd]

Post by Henry Vermaak

Post by Mark Morgan Lloyd

Post by Henry Vermaak
The only delay I can see (after fsync) would be due to the hardware
cache of the disk in use (or a defective drive). On linux you can call
hdparm to flush on-disk caches.

But is hdparm fully supported by external Flash cards, and does it
return before or after data is guaranteed to be filly committed?

This is a red herring (sorry, my mistake). Compact flash cards (and
other removable media) are block devices, they have firmware that do
this flash to block emulation. I realise now that Michael meant that
some cf cards have crappy firmware that can't handle power cuts. There
isn't much you can do about that, but choose a good cf card or usb stick.

But there are several different interfaces to Flash storage technology,
CompactFlash (i.e. PCMCIA -> IDE/ATA) is only one of them. Different
considerations probably apply to other MTD devices (in particular SD and
its derivatives), which might make them either more or less vulnerable
to abuse.

[Michael Schnell]

Post by Mark Morgan Lloyd
But there are several different interfaces to Flash storage
technology, CompactFlash (i.e. PCMCIA -> IDE/ATA) is only one of them.
Different considerations probably apply to other MTD devices (in
particular SD and its derivatives), which might make them either more
or less vulnerable to abuse.

The problem is not related with the interface. it's completely
internally within the card.

-Michael

--

[Mark Morgan Lloyd]

Post by Michael Schnell

Post by Mark Morgan Lloyd
But there are several different interfaces to Flash storage
technology, CompactFlash (i.e. PCMCIA -> IDE/ATA) is only one of them.
Different considerations probably apply to other MTD devices (in
particular SD and its derivatives), which might make them either more
or less vulnerable to abuse.

The problem is not related with the interface. it's completely
internally within the card.

I wonder if I could have a reality check here. The thing that's
bothering me is that, for example, a CompactFlash card looks like an
IDE/ATA disc hence must have internal firmware handling wear levelling.
Similarly, an MMC card with a matched host controller looks like a
storage device so presumably the same applies.

But what is the situation with an MMC card in isolation, being driven by
bit-banging or by code in e.g. a BASIC Stamp using SPI? Do these still
look like discs?

Going back to the OP's question, there certainly used to be things like
battery-backed SRAM cards that fitted in a PCMCIA slot, if I recall
correctly Sun used them to move configuration information between
computers. Does anybody put bare Flash into a similar outline, i.e.
relying on the kernel and drivers to handle all housekeeping?

[Michael Schnell]

Post by Mark Morgan Lloyd
I wonder if I could have a reality check here.

To be sure, you would need a decent specification by the card's
manufacturer. Otherwise there is a problem that _can_ hit, and according
to Murphy it _will_ hit.

-Michael

--

[Mark Morgan Lloyd]

Post by Michael Schnell

Post by Mark Morgan Lloyd
I wonder if I could have a reality check here.

To be sure, you would need a decent specification by the card's
manufacturer. Otherwise there is a problem that _can_ hit, and according
to Murphy it _will_ hit.

Agreed. I admit I was trolling slightly there: I'd already read a spec
for an MMC device and found that the actual card (not just a host
controller) looks like a disc, so I think it's fair to assume that this
applies to just about anything these days. I was wondering though
whether anybody had any conflicting opinions.

The bottom line is that when a system gets a powerfail signal it will
unmount all filesystems and shut down. But the action of unmounting
rewrites (something equivalent to) the superblock to reset the dirty
flag, and that requires that power remains stable.

[Michael Schnell]

On 09/28/2010 11:27 AM, Mark Morgan Lloyd wr

Post by Mark Morgan Lloyd
The bottom line is that when a system gets a powerfail signal it will
unmount all filesystems and shut down. But the action of unmounting
rewrites (something equivalent to) the superblock to reset the dirty
flag, and that requires that power remains stable.

Yes. This is why unmounting might make the system even less safe. If
some data is not written back at all only those are bad. But it you
unmount and thus rewrite the superblock immediately before power down
the card might trash more and more important data.

-Michael

--

[Henry Vermaak]

Post by Mark Morgan Lloyd

Post by Michael Schnell

Post by Mark Morgan Lloyd
But there are several different interfaces to Flash storage
technology, CompactFlash (i.e. PCMCIA -> IDE/ATA) is only one of
them. Different considerations probably apply to other MTD devices
(in particular SD and its derivatives), which might make them either
more or less vulnerable to abuse.

The problem is not related with the interface. it's completely
internally within the card.

I wonder if I could have a reality check here. The thing that's
bothering me is that, for example, a CompactFlash card looks like an
IDE/ATA disc hence must have internal firmware handling wear levelling.
Similarly, an MMC card with a matched host controller looks like a
storage device so presumably the same applies.
But what is the situation with an MMC card in isolation, being driven by
bit-banging or by code in e.g. a BASIC Stamp using SPI? Do these still
look like discs?

For a device to be called MMC, it has to follow the MMC protocol, which
hides the flash from the user and looks like a block device by
definition. Basically, if it's not a raw flash chip, it's going to have
some translation layer. How well this translation layer treats the
flash will probably depend on the vendor of the card.

Henry

--

[Michael Schnell]

Independent from the kind of the hardware interface to the card, the
problem is that
- in Linux you think you are safe if you unmount the file system
before powering off
- when using a journaling file system you are sure that you always can
power off the system and when restarting the file system will restart
after the latest completed written transaction, with all previous data
being safe and a clean file system structure.
- with a journaling file system on an MTD medium this is even true if
the file system preforms wear leveling.

A card that does complex stuff independently of the file system that
uses it's data trashes all this, if it does not succeed in doing it's
stuff after the last write from the file system. Only providing power to
the card for an appropriate time can make it work safe. But to construct
a system that does this, you need an appropriate specification from the
manufacturer. Unfortunately they do not seem to be inclined to provide this.

-Michael

--

[Henry Vermaak]

Post by Michael Schnell
Independent from the kind of the hardware interface to the card, the
problem is that
- in Linux you think you are safe if you unmount the file system before
powering off
- when using a journaling file system you are sure that you always can
power off the system and when restarting the file system will restart
after the latest completed written transaction, with all previous data
being safe and a clean file system structure.

No. If you have a disk that does out of order write caching, you will
have to enable barriers (which are not enabled on ext3 by default, for
example). Then you may still have the problem of some disks not
implementing the flushing correctly, at which point you will have to
disable the write caching, which will have a big performance impact.

My point is that you are always at the mercy of your device (not just
with sd/mmc). A good sd/mmc will implement a log structured file system
in the translation layer that won't be prone to data loss.

These are corner cases, though, and I fear that we're very far off topic
again.

Henry

--

[Bo Berglund]

Post by Bo Berglund
-----Original Message-----
Sent: Tuesday, September 28, 2010 11:57 AM

Post by Michael Schnell
Independent from the kind of the hardware interface to the card, the
problem is that

... snip ...

Post by Bo Berglund
These are corner cases, though, and I fear that we're very
far off topic
again.

Hi guys, my intent for this thread was not to discuss the borderline case
where data are saved to a memory card by the user and he pulls the card out
in the middle of a write operation or right after it is done and so causes
corruption on the card...
I realize now that this may happen, but in my case the memory card is
inserted behind a watertight door (system is for outdoor use) so it will
sit there for a whole session and probably not come out until the system
is back in the office....

The memory card problems warrant a separate thread so one may find the
conclusions later on.

--
Bo B


--

[Michael Schnell]

Post by Bo Berglund
in my case the memory card is
inserted behind a watertight door (system is for outdoor use) so it will
sit there for a whole session and probably not come out until the system
is back in the office....

The main problem is power fail of the complete system, though. You only
con prevent that when using a battery.

-Michael

--

[Michael Schnell]

Post by Henry Vermaak
No. If you have a disk that does out of order write caching, you will
have to enable barriers (which are not enabled on ext3 by default, for
example). Then you may still have the problem of some disks not
implementing the flushing correctly, at which point you will have to
disable the write caching, which will have a big performance impact.

Of course you are correct as such a disk also does "complex stuff"
inside. But a disk with a cache will never trash data that has been
written long ago. The wear leveling in a flash card needs to move such
data ()user data and it's own management blocks) around. This results in
the said effects.

Post by Henry Vermaak
My point is that you are always at the mercy of your device (not just
with sd/mmc).

Yep. But I do suppose that you can get information from the disk
manufacturers how long it might take at most to write the cache back to
the disk and I don't think this is more than some mSeks. While with
Flash cards this time can be long (supposedly max several seconds) and
the manufactures don't provide a spec of that.

Post by Henry Vermaak
A good sd/mmc will implement a log structured file system in the
translation layer that won't be prone to data loss.

An sd/mmc does not implement a file system at all.

Post by Henry Vermaak
I fear that we're very far off topic again.

yep.

-Michael

--

[Henry Vermaak]

On 27 September 2010 14:45, Mark Morgan Lloyd

Post by Mark Morgan Lloyd

Post by Mark Morgan Lloyd

Post by Henry Vermaak
The only delay I can see (after fsync) would be due to the hardware
cache of the disk in use (or a defective drive). On linux you can call
hdparm to flush on-disk caches.

But is hdparm fully supported by external Flash cards, and does it
return before or after data is guaranteed to be filly committed?

This is a red herring (sorry, my mistake).  Compact flash cards (and other
removable media) are block devices, they have firmware that do this flash to
block emulation.  I realise now that Michael meant that some cf cards have
crappy firmware that can't handle power cuts.  There isn't much you can do
about that, but choose a good cf card or usb stick.

But there are several different interfaces to Flash storage technology,
CompactFlash (i.e. PCMCIA -> IDE/ATA) is only one of them. Different
considerations probably apply to other MTD devices (in particular SD and its
derivatives), which might make them either more or less vulnerable to abuse.

CF, SD, MMC, USB stick, etc. are not MTDs. They will all have a
translation layer inside to talk to the flash chip and make them look
like block devices. Due to this translation layer they will all have
this problem (according to Michael, at least), irrespective of the
interface (USB or PCMCIA). With an MTD you are in control, since you
are talking to the flash directly.

We have a simple device that allows the user to transfer data onto a
USB stick. I just call sync when the copying is done and I haven't
noticed anything weird when randomly pulling the stick out. Since a
USB stick also has this translation layer, surely I would've had
problems? Maybe I'm just lucky, or maybe CF cards are worse than USB
sticks.

Henry

--

[Michael Schnell]

Post by Henry Vermaak
Due to this translation layer they will all have
this problem

With this translation they need to do the wear leveling internally while
with MTD the file system (such as JFSS2) will do the wear leveling and
can combine it with journaling to avoid data loss on power fail.

-Michael

--

[Michael Schnell]

I realise now that Michael meant that some cf cards have crappy
firmware that can't handle power cuts.

Not some but seemingly nearly all.

I did not yet see a flash card that comes with a specification how long
power needs to be supplied after a write access to prevent data loss.

-Michael

--

[Michael Schnell]

Post by Henry Vermaak
The only delay I can see (after fsync) would be due to the hardware
cache of the disk in use (or a defective drive). On linux you can
call hdparm to flush on-disk caches.

Nope it's inside the card itself and some delay between the last write
access and the arrival of the data in the flash storage is always there.
but sometime this can get huge.

-Michael

--

[Michael Schnell]

Post by Mark Morgan Lloyd
We have equipment scattered around Europe, and the reliability of the
power sources on industrial sites is far worse than most people
appreciate. A common scenario is where our kit is wired to a supply
that intermittently runs a pump or similar, i.e. sometimes it sees
230V but most of the time it doesn't.

Non Card based directly managed flash chips with file systems like JFFS2
and UBIFS that handle the wear leveling in the file system code itself
can be made secure, as it is clean after unmounting and the system can
know if the unmount has been completed. Moreover the journaling can take
wear leveling into account and (maybe) it even can be rolled back clean
to the last transaction completely stored on the flash ship.

But this does not help with flash cards as they might destroy seemingly
stored data when storing of other data is aborted.

I was even told about cards that could not even be formatted after an
aborted write (obviously the writing to a a page management page has
been aborted.) It was completely dead but _could_ be reconfigured by the
manufacturer.

-Michael


--

[Michael Schnell]

Post by Henry Vermaak
Why do you think all data will be lost with a journalling file system?

This has already been discussed at any length in several embedded Linux
forums.

A flash card does an internal wear management by moving data around when
pages become due to end of life. For thus purpose it has a bunch of
spare pages. Of course the pages that contain dynamic file management
structures (FAT, directories, ...) are especially due to wear out and
need to be replaced often. Of course there also are pages that just
internally manage the use of the data pages. same are due to wear out, too.

Now if the card detects a dying page (by seeing that the time needed to
erase it gets long) it copies and replaces it. this results in updates
to management pages that might be close to dying, as well.

The manufactures don't guarantee how long this process might take and
how much electrical energy it might take.

All this is completely independent of the file system used, as it
concerns a lower level than handled by the file system.

-Michael

--

[Henry Vermaak]

Post by Michael Schnell
All this is completely independent of the file system used, as it
concerns a lower level than handled by the file system.

I'd consider disks which firmware can't handle power failure to be
broken. Luckily this hasn't happened to me (yet, heh).

Any disk with on-disk cache is susceptible to data loss if write
barriers aren't enabled (luckily they are enabled by default for ext4).
Unfortunately all file systems don't have this feature, so the only
way to be really safe is to have a battery backup.

Henry

--

[Michael Schnell]

Post by Henry Vermaak
Any disk with on-disk cache is susceptible to data loss

A flash card need to have a cache. The pages of the flash medium are
several MB. you can erase a page only completely, not partially. So
whenever you overwrite some data by writing just a sector (usually 512
Byte) quite complex things need to be done internally, as overwriting in
place is not possible. So a cache is used to collect some changes and
handle the on block for better speed and less wear out.

Of course the cards will write unused parts of the storage when possible
(not creating a problem with power down in that case), but if all free
space is used, some complex housekeeping needs to be done copying pages
and erasing some.

-Michael

--

[Michael Schnell]

Post by Henry Vermaak
I'd consider disks which firmware can't handle power failure to be
broken. Luckily this hasn't happened to me (yet, heh).

I found a comment on this in another forum:
You can use industrial compact flash cards that don't have this low
level integrity loss problem. As an example, we use the cards from STEC
that are guaranteed not to become in an unusable state after a power
loss. Of course they are a lot more expensive than the ones you can find
in supermarkets
<<<<<<<<<<<<<<<<<<<<<<<<<

-Michael

[Flávio Etrusco]

I'd consider disks which firmware can't handle power failure to be broken.
Luckily this hasn't happened to me (yet, heh).
You can use industrial compact flash cards that don't have this low level
integrity loss problem. As an example, we use the cards from STEC that are
guaranteed not to become in an unusable state after a power loss. Of course
they are a lot more expensive than the ones you can find in supermarkets
<<<<<<<<<<<<<<<<<<<<<<<<<
-Michael

What's the date of this post? I've read several times that this problem only
occurred in early flash "cards" and it's virtually non-existent nowadays...

Best regards,
Flávio

[Michael Schnell]

Post by Flávio Etrusco
What's the date of this post?

Yesterday.

In a second post he sent a link to the data sheet:
http://www.stec-inc.com/downloads/ssd_datasheets/SLCFxxx_G_M2PU_I_61000-05610.pdf

I'm not absolutely sure the wording there definitively rules out that
data that has been written is lost or destroyed with any random power fail.

Post by Flávio Etrusco
I've read several times that this problem only occurred in early flash
"cards" and it's virtually non-existent nowadays...

What is needed is a clear written spec from the manufacturer.

-Michael

--

[Michael Schnell]

Post by Bo Berglund
1) Can I work in Windows or Ubuntu on the same project?

Yes. You can do the same source code for both targets, but you need to
be aware of certain differences regarding some system calls and things
like thread synchronizing. You can even cross compile (and supposedly
cross-remote debug).

Post by Bo Berglund
2) Can I compile in either environment for a third runtime platform?
I am especially looking for a GUI programming environment where the target system
is Embedded Linux on ARM or Atom platform boards.

You can cross compile for ARM and, AFAIK, you can compile FPC and
Lazarus to run on ARM/Linux.

But what ARM system is the target ? I suppose it's hard to make a
Lazarus program that needs the LCL run on a non-MMU ARM. If you don't
install X and KDE or GNOME on your embedded system you need to use a LCL
"Widget type" that has no GUI binding and same are as well restricted as
not in the same level of perfection as the GUI based Widget Types.

Post by Bo Berglund
3) I need to access the serial communications channel from my programs, so what is
the support available for RS232 communications in Lazarus/FPC?

You just open the COM device :). In fact it makes a lot of sense to do
this in a thread (such as Async Pro does). But Async Pro is not yet
ported to Lazarus and handling threads is not really portable,
especially with non-GUI widget sets that (at the moment) don't have
built-in portable Message handling for thread synchronizing.

Post by Bo Berglund
The target is an embedded board that is intended to communicate with a data acquisition
system via RS232 (38400 baud, binary proprietary protocol).

I'm doing a similar research since long :) In fact the market for
"embedded ARM/Linux boards" is moving to MMU-based ARMs and lots of
memory, so that installing X is not a problem any more ant thus you can
use the KDE or Gnome widget set and with that doing software with
Lazarus is _very_ viable.

Post by Bo Berglund
4) The programs planned will also need to produce graphic rendering of the data
retrieved from the acquisition system, so what is the graphic capabilities of
Lazarus/FPC on the Linux platform?

If the ARM has X, same as in Windows. The user program sees the LCL API,
which is very similar to the Delphi VCL API <just beware of Unicode!> ).
Regarding Graphics this of course is not a very high level. But (like
with Delphi you can use things like SDL and other graphics libraries
that have portable backands). What specifics do you need ?

Post by Bo Berglund
5) Can data be stored on memory cards/hard disk on an embedded system?

With Linux you should store data in files ! There are several flash file
systems you can install.

-Michael

--

[Bo Berglund]

From: Michael Schnell [***@lists.lazarus.freepascal.org]
Sent: 27/9/2010 3:53:31 PM

Post by Michael Schnell

I realise now that Michael meant that some cf cards have crappy
firmware that can't handle power cuts.

Not some but seemingly nearly all.
I did not yet see a flash card that comes with a specification how long
power needs to be supplied after a write access to prevent data loss.
-Michael

I intended to use SD-card for external data storage and an SSD
for the operating system internally.
Both essentially flash devices.

Bo Berglund
(I tried a different subscriptiont and I can still not post to the
GMANE newsserver dammit!)


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Hitta kärleken med hjälp av vårt matchningstest - <a href="http://spray.matchaffinity.se/?mtcmk=614114">Klicka här!</a></font>