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

No. Linking is slightly slower on windows.

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.

2) Can I compile in either environment for a third runtime platform?

Yes, but not easily.

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.

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.

Virtually the same as at least Delphi 7.

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.

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...

> > 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???

Almost answers the previous question!

Is it the same on Linux and Windows?

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

BosseB

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.

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)

The interface is the same.

Michael.

Hello,

You can find a version for Windows here:
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?

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

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

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

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

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

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

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'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!

For some serial code, look for "Simple Serial" on this page: 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...

Regards, Paul Breneman

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.

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.

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 wrote

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).

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.

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.

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.

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 ?

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

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

On 09/25/2010 03:34 PM, Bo Berglund wrote

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 wrote

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

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?

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

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 wrote

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

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

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 wrote

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

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.

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

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

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.

Henry Vermaak wrote

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

From: Michael Schnell []
Sent: 27/9/2010 3:53:31 PM

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> -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100927/a6b132e5/attachment.html>

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

-Michael

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

Henry Vermaak wrote

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

Henry Vermaak wrote

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

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?

Paul Breneman wrote

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

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 :-)

Bo Berglund wrote

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

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?

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.

Mark Morgan Lloyd wrote

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

Graeme Geldenhuys wrote

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

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 wrote

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.

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

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.

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

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

... snip ...

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.

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

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

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.

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.

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.

I fear that we're very far off topic again.

yep.

-Michael

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

-Michael

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'd be glad to discuss this in more detail.

Good :-)

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.

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

Thanks,
-Michael

Henry Vermaak wrote

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101006/b798698c/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: wink.gif
Type: image/gif
Size: 1062 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101006/b798698c/attachment.gif>

2010/10/6 Michael Schnell

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101006/ce0b34e8/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1062 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101006/ce0b34e8/attachment-0001.gif>

Fl?vio Etrusco wrote

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.

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