Re: Linux serial port dropping bytes

Didi wrote:
David Brown wrote:
"Low latency" is a relative term.

It is, relative to the current state of technology. Readers of this
newsgroup are assumed to be aware of it.


I think you are looking at a very narrow view of the technology used in embedded systems. Just because fast devices are available cheaply and easily, does *not* mean that fast devices are appropriate for every embedded system. When designing a new system, I choose a microcontroller running at 150 MHz if that's what suits the system - but I might choose one running at 1 MHz if that's a better fit.

Were all your millions of lines of code written for just the one
project?

No. You can see some of my projects at
http://tgi-sci.com/dsv/dsvpex.htm . Then take into account the fact
that "the 1 project" contains 7 processor designs so far - two of
them running DPS.

And there you will not see some which are too old - from the 1 MHz
6809 and 6800 times, some of which did latency related miracles
of their own (1985 or so). These sources are not included in the
line/byte counts I quote either.

Because you seem to be having difficulty appreciating the
breadth of possible embedded systems, and how their requirements may
vary enormously.

I do not have this difficulty. You seem to have a difficulty to
comprehend
the fact that being able to afford overkill resources resulting in a
working
product does not mean your practice is worth being repeated by others.


< Hits head repeatedly on the table...>

The whole point of picking your program structure to match the application is that you get smaller, faster, simpler, clearer, and more reliable code by picking the most appropriate setup for the application in hand.

Go back and re-read that paragraph.

You have been claiming it is *always* better to use the one single technique (minimal work in the ISR) - despite repeated examples from various other posters of when other methods can be better, and have been used successfully in real world projects. Spending time thinking about the design and using an appropriate interrupt structure results in a better program using less resources (developers' resources as well as run-time resources) - forcing your code to use a single structure regardless of the application can easily result in wasted resources.

If you design a 100 tonn car which will take you places at a speed and
cost you accept you may have solved your immediate problem, but
not many people would be well advised to repeat your design.


Again - it is *your* dogma that will lead to wasted resources. I (and everyone else still following this branch) recommend using the best interrupt routine structure for the given application. It *cannot* be worse (assuming a competent developer!) than sticking to a general rule such as yours - if minimal interrupt routines are the best for the job in hand, then that's what we'll use!

To correct your analogy - *you* say that all vehicles must have four wheels. I say that four wheels is a good number in many cases, but that sometimes two or six wheels is a better choice, and you should pick the right number of wheels for a given type of vehicle.
.

Relevant Pages

  • RE: Compiling C++ modules
    ... at least ten times the performance and resources of the computers from the ... The majority of embedded systems that run very low-end hardware perform ... in all the years I developed embedded systems (from industrial ...
    (Linux-Kernel)
  • Re: [OT] How often are functions pointers used
    ... Function pointers can make for efficient state machine code, ... especially for embedded systems which may have very minimal hardware ... resources. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: is glib suitable for embedded systems ?
    ... I am having doubts whether to use glib on embedded systems. ... I need some sort of IPC mechanism, so I tend to use DBUS. ... but I don't think it requires that many resources. ...
    (GNOME)
  • Re: C vs C++ in Embedded Systems?
    ... Chris Hills wrote: ... > You mean like the embedded systems have had for the last decade? ... and "higher-end" after it. ...
    (comp.arch.embedded)