digital low pass filter output errors

Clifford Heath expounded in news:4e389b23$0$3035$ snipped-for-privacy@news.optusnet.com.au:

..

Ada is more than just a "good language". It is the software _engineer's_ language. It is very well thought out with an emphasis on engineering for correctness. Every language has a few design warts but Ada is really the only practical choice when code absolutely must work.

And the SPARK folks really do prove that their software is going to do what it is supposed to do. This is essential for air traffic control centers and fly by wire systems etc. They live with some pretty severe restrictions to do this- for example no dynamic memory allocation is permitted, since a memory request is potentially a failure point (it's also too difficult to prove that it will never fail).

In my own limited experience, every program I have ported from C or C++ to Ada has been shown by the _compiler_ to still have a subtle bug or two. This is at the _compiling_ stage, long before testing even begins. This is the best phase to discover problems.

One subtle case that sticks out in my memory was dealing with

The compiler dutifully pointed out that if the sample variable S when inverted as -S was problematic. It pointed out that if S was -32768 (16-bit signed) then -S is not representable as

In the original C code -32768 gets inverted as -32768. So an incorrect value slips through the system in thousands of lines of code.

Of course a sharp programmer would catch this as it is being coded but no programmer is sharp all the time and never as sharp as the compiler for all details involved.

This example is not a serious error in sound sample code but it sure would be irritating- with the programmer wondering where on earth is that glitch coming from? Worse, the problem might be so rare that it goes unnoticed for a long time.

But in a life and death scenario, this kind of error is completely unacceptable.

Warren

Remember C is designed for "flexibility" and "performance" NOT correctness. If correct results are a concern that is up to the "application". I remember one processor where they wanted to support C and had to do strange things to the run time to counteract the hardware, which would give an exception on overflow. They had to ignore overflow errors so that you would get the "right" result in C.

(The main use of this machine was business data processing where correct answers are important and they want to know about errors.)

Dennis expounded in news:w0A_p.24779$ snipped-for-privacy@newsfe13.iad:

..

I don't reminding -- but at the time, C was a big step in the right direction for correctness over B. As a B programmer at the time, C took a lot of adjusting to!

B was derived from BCPL, both C's predecessors. In B, everything was a word (36-bit word on the Honeywell L66), which could be used as an integer. You performed function calls to move (Honeywell 9-bit) byte strings from one word array to another.

In B, there was almost no type checking (there was virtually no types!). The only other type was a float, which had it's own special operators for the purpose. IIRC, there were a few cases where the use of the wrong operator would provoke an error. Otherwise there was no type checking at all.

But the application is built upon it's development tools. The debatable thing then is how much should the development tools protect the developer from mistakes?

Leaving Ada out of it, some tools saved the programmers from themselves (like Pascal): array bounds checks, defined string operations etc.

Other tools like C, were focused on empowerment, giving you the gun to shoot yourself in the foot, if that is what you asked for.

You could apply the empowerment argument to assembly language as well. Yet, people have learned to move on from assembly- though in fairness, the portability of C was a big factor in this. Lack of portability is why NT came out while OS/2 was left in the dust (OS/2 being written in assembly).

It has been argued that Ada would excel in that arena. There are a few (European?) financial institutions using it. You might only need one hand to count them, however.

I think the language would have gained more traction had there been free/affordable compilers for the non-military world when C was born. Now there is gnat (gcc-ada), which is available for free. You can get support from adacore.com if you need it.

But the world has formed a big foundation in C today and increasingly C++ (the mess that it is). It is probably too late to make big changes there now.

However, at the application level, you do have the option of choosing your poison for each new project. But other factors like existing libraries often decide the choice.

Warren

programming.

the

media player),

other I guess.

Hi,

Could you recommend a good way to make a "real time" task manager using threads for the tasks? I would like to be able to specify the desired frequency that each thread is called, ie, from 1Hz to 10kHz. I am thinking of using a central task manager thread for this which runs full out polling the current time to determine when to start each thread. That is not as efficient as an interrupt based task manager, but I'm not sure if such a thing exists on Windows 7 at least.

cheers, Jamie

Heath

would

it

programming.

testing in the

all but the

design, and

multi-threaded media player),

the other I guess.

=20

=20

Monotonic rate schedulers are anathema to modern mainstream desktop OS's. If you really want to do something like that you really should go to a proper real time OS. That said, i think that there are some sorta real time adaptations of many regular desktop OS's. In the MS world there is the possibility intercepting the RTC interrupt at about 18.2 Hz. In the RT Linux world you can access a similar interval timer with some more flexibility.

?-)

On a sunny day (Fri, 05 Aug 2011 15:41:43 -0700) it happened Jamie wrote in :

I probably cannot answer that question, and I am not sure I see the advantage in that. I am a bit limited to my experience as I only use Linux and libpthreads these days. How often 'a thread is called' or better how often the code in the tread is executed, is set by the kernel task switch, unless perhaps if it runs on a separate core. If you wanted the thread to do something only every now and then, then you could put it to sleep for a while, or, as I do when waiting for data use the select() function. Using threads in Linux is really transparent. Task switching at 10 kHz (100 us) seems a bit fast to me. Some things are pre-emptive, it may take much longer before a task switch happens.

Long time ago (when we still had 5 1/4 inch floppies) I wrote a small multitasker that also displayed windows and did everything like mouse, display, keyboard, etc. But these days with all the 'required' interfaces (LAN, USB, disk, cards, etc) it is simpler to run a small Linux system.

There was a 25 dollar ARM board with Linux and HDMI + USB announced a while back. There is also a huge amount of software source code available that you can look at for how to do things with threads, plus some good tutorials on the net. Why one would even think of something line Winbloat 7 is beyond me.

The other thing that could be useful is start a new process, not a thread, and communicate with that via for example pipes. You will need to be more specific about environment, requirements, for an answer to your question. I am sure you could program something from the ground up for an embedded system, but why?

I do not know about Windows 7, but at least for previous NT based kernels _with_ multimedia timers enabled, 1 ms resolution (1 kHz) is obtainable. In each thread, after the actual work has been done, get the time stamp, calculate how long it takes, until the thread should be restarted for the next time and use this for the timeout parameter for the WaitForSingleObject() call.

To have some predictability, the thread should execute at some priority in the real time priority class and the keyboard and mouse ports should be plugged by glue to avoid any user interference :-).

Without enabling multimedia timers, the resolution is 10 ms (or 15.625 ms for multiprocessor boards).

For other multitasking OSs, run the hardware timer interrupt at 10 kHz and activate the sleeping threads by activating an event flag (or what ever it is called) or send a message to the thread sleeping and waiting to be activated each time the reactivation time has occurred.

With lots of threads with different reactivation times, it makes sense to have a clock queue with the next reactivation times in a sorted list, thus you generally have to check only two reactivation times in the ISR.