Manipulate information in file C++

Question

2.50/5 (2 votes)

See more:

Hi,

I am working on an application in C++ for a embedded device. This application have to make a kind of historical of the differents problems or alarms that appear in the device.
An alarm is illustrated by a line like that :
2500 1 alarm1 (the 1st number is an ID, the second indicates that the alarm is up )

At each time an alarm is up, a line is written in a text file and when the alarm is down the previous line is deleted in the file.

For example :
In the file :
2500 1 alarm1
2450 1 alarm3

Now the alarm 2500 goes down on the device so the line "2500 1 alarm1" is deleted.

I plan to make this in C++ with opening a file, research inside and so on.

I would like to know if someone have an idea, a method to do that (other than mine) which increase performance and don't use lot of memory in the device.

Thanks in advance.

Posted 16-Jun-11 10:07am

Zaraki21

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

TRK3 · Answer 1 · 2011-06-16T12:00:00

Solution 2

Do you have a fixed number of possible alarms?

If so, I'd suggest storing alarm data in a fixed length record file.

Say 4 bytes per alarm. Use the high order bit for the alarm state (on/off) and the lower 31 bits for a timestamp / sequence number.

Then when an alarm changes state, you don't have to search your file, you just go to the appropriate offset in the file and write a new 4 byte value at that offset to indicate the current state of that alarm and the current timestamp / sequence number.

This will give you the same information as you have in the file structure you propose, it has the advantage of being a fixed size file and a predictable execution time (both important for an embedded system).

Depending on the number of possible alarms and how much non-volatile storage you have available, it might be worthwhile to just store separate timestamps for on/off for each alarm -- then you'll have a more complete history.

Even better idea (if the number of unique alarms is small and non-volatile storage is adequate):

In your fixed length record file, store: last time on, last time off, number of times the alarm has triggered, and the cummulative time the alarm has been on.

From that you can determine what alarms are going off most and for how long on average. Gives you way more historical data then your file.

If, on the other hand, the number of unique alarms is large compared to tha available non-volatile storage:

Just maintain a circular buffer in non-volatile storage and write every on/off event into the buffer as it occurs, when you fill up the available buffer/file just start at the beginning again and overwrite the oldest entries.

This may give you a more useful picture of what is happenign in your system. For example if alarm 2450 is toggling on and off constantly, while nothing else is happening, this will be a much better solution than the one you originally envisioned. In any case, the last N events are probably most important in your history.

You might also store a single historical bit per alarm to show if that alarm has ever gone off.

In any case, spend a bit of time thinking about how exactly this historical data is going to be used and it will help you decide what data you really should store.

Posted 16-Jun-11 12:00pm

TRK3

Updated 16-Jun-11 12:24pm

v2

Comments

Zaraki21 17-Jun-11 3:37am

Acctually, the number of alarms are defined and fixed by the device ; I mean there is a list of possible alarms that can be up or down. The fact is we don't know the number of alarms that can be up during a day for example : it could be a lot or only one.

TRK3 17-Jun-11 8:48am

Does either of the solutions form Albert or myself solve your problem, or do you need more help/advice?

Is the application you are writing running on the embedded device itself, or is running on a pc that is connected to the device?

Albert Holguin 17-Jun-11 9:21am

think he needs to share more details on what he's trying to accomplish, he's being very vague (maybe on purpose?)

Zaraki21 17-Jun-11 11:29am

I will try to explain what I would like to do :

A software runs on the embedded device. On the device, there are alarms and warning which are toggle sometimes. My software module that I have to create have to
store and make a list of alarms through a file.

For example, after booting, I have those following alarms and those are "recorded" like that :
file.txt
|--------------------------------
|2501 1 alarm1
|2560 1 alarm2
|2561 1 alarm3
|2578 1 alarm4
|2568 1 alarm5

After few minutes for example, the alarm4 is down so basically the file should be like that :
|--------------------------------
|2501 1 alarm1
|2560 1 alarm2
|2561 1 alarm3
|2578 1 alarm4
|2568 1 alarm5
|2578 0 alarm4

But I would like to update the file according to the fact that "because the alarm4 was up before and it is down, so I delete the record in the file".
|--------------------------------
|2501 1 alarm1
|2560 1 alarm2
|2561 1 alarm3
|2568 1 alarm5
This process should allow me to have a "picture" of the system.

Also, the file is updated in real time.

TRK3 18-Jun-11 11:31am

The example you show deletes all information about alarm4, so it doesn't provide any historical data that alarm4 was up and now is down. All it does is tell you what alarms are currently on, there is not really any historical data at all. Is that what you really need/want? (If so, there is probably a simpler way to do that.)

Before you get into how best to solve creating the specific solution you are talking about, you should step back and take a look at what are the actual user requirements. What is the user going to do with this information? Is it important to know any historical data or only the current state? Is it important to know the actual time of each event, or just the sequence, or is the sequence itself irrelevant?

Then you (we) need to know:

What are you using to store the "file" -- is this RAM, flash or disk drive? (The nature of the storage affects the best way to store/retrieve data when you are interested in real time performance.)

How much of this is available for your file? (There are space / speed / information density trade offs to be considered in order to get the most useful historical log which satisfies you real time performance requirements.)

What are you real time performance requirements: How many alarms do have to deal with? How fast will they change state (do they have any hystereses or will they potential toggle between on and off every cycle when they are right at the alarm threshold)? Do you need to catch and log every change of state or is the current state good enough? Does anything else in the system have to happen when an alarm occurs or just the logging? Do the alarms generate an interupt, or are polling them in a loop?

If the log file is stored on the embedded device, how is ultimately accessed by a user? (On board LCD? Upload over serial?) Is the device off line when the file is accessed, or does the user access it while the device is still performing it's job? How often do you expect the user to actually look at it and what is the user actually going to look at?

The real lesson here is:

The fastest way to get a working product that is acceptable to the user is to spend 90% of your time clarifying what is meant by "working" and "product" and "acceptable", 8% of your time figuring out the best way to implement that and 2% of your time implementing it.

It doesn't matter how good or clever an implementation is if it doesn't solve the problem it was originally supposed to solve or if it's solution is so cumbersome that the user finds paper and pencil an easier way of doing it....

Albert Holguin · Answer 2 · 2011-06-16T10:41:00

Solution 1

This shouldn't take a lot of memory unless the file gets big... in which case, don't load the entire file into memory, open the file and pull in one line at a time as needed. In this case, there's a tradeoff, loading a file into memory consumes RAM (which embedded devices don't typically have a lot of) but reading from non-volatile memory is slower, so make a decision as to what your priority is.

To increase performance, do the searching through the file in a different thread than your main (don't wait for it, just let it tell you when its done or if the main thread doesn't need to know, it'll be better).

Posted 16-Jun-11 10:41am

Albert Holguin

Comments

TRK3 16-Jun-11 18:05pm

Doing the operation in a different thread doesn't necessarily change the performance at all in an embedded system. Typically you've only got one processor / microcontroller, with only one core.

This sounds like a system with realtime requirements, which means you'll need to process each alarm in a predictable and finite amount of time. Or queue them up and process them when you aren't doing anything else, provided you can guarantee the alarms don't change state so fast they overwhelm your queue.

Albert Holguin 16-Jun-11 20:10pm

you're making assumptions, as am I

TRK3 16-Jun-11 20:13pm

Yeah, without knowing the details of the system it's hard to say what the best solution is. My idea of embedded may be drastically different than what he's trying to do...

Zaraki21 17-Jun-11 3:30am

Actually, we don't know when an alarm change state. An alarm can be up for long time or short one. The process of making down an alarm is in charge of the device, I don't control that.

Albert Holguin 17-Jun-11 9:20am

that doesn't affect any of my suggestions... ::headscratch::