From: Vladimir Vassilevsky on


D Yuniskis wrote:

> Hi Vladimir,
>
> Vladimir Vassilevsky wrote:
>
>> Actially, it is Meggitt decoder. The idea is to calculate the
>> syndromes on the fly rather then store them in a LUT. This kind of
>> decoder could be easily applied for *any* cyclic code; it's advantage
>> is simplicity.
>>
>> For those who are interested in the classic error correction math, the
>> good book is R. Blahut "Theory and practice of the error control codes"
>
> I like _Error-Correcting Codes_ by W Wesley Peterson.

Well known book, also.

> No doubt out of date.

That's the basis; it couldn't be outdated although they couldn't cover
the latest discoveries.

> But, requires a considerable math background to
> truly appreciate much of what is covered (field theory, etc.).
> And, you won't find any code snippets within. :< But, if
> you understand the math behind the theory, you can usually
> roll your own implementation fairly easily.

Code snippets are of no use if you don't understand how they work. And
if you do understand, then you don't need code snippets.

> I will try to chase down a copy of Blahut just to see how it feels.

R. Blahut is a good writer; his books are pleasure to read.
Besides the book on codes, I can recommend his "Fast Algorithms for
Signal Processing".


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com


From: Jon Kirwan on
On Mon, 08 Mar 2010 04:13:02 +0100, whygee <yg(a)yg.yg> wrote:

>Jon Kirwan wrote:
>> To achieve software freedom in RMS' sense, they have to use
>> force on _developers_ (not users) to fight the proprietary
>> developers' forces. Which is why the licenses exist, I gather.
>
>wrong, the FSF provides tools to the coders, it's more like
>providing weapons to the poorer side of a war... which is
>not popular.
>
>The GPL is not appreciated by a lot of people because...
>well, it gives the developers the means to unite in a way,
>and defend themselves. Nobody is "forced" but there is
>a choice, a bit more freedom.
>
>Then, between the plan and its implementation, there
>are probably a lot of... glitches. So don't get impressed
>by David : read RMS's "writings" and make your *own* opinion
>(and yes, RMS is stubborn, but it does make him malevolent).
>
>> Jon
>yg

I liked this comment from RMS in a 2006 barcelona transcript:
"In other cases, it's because the licence is so permissive
that to relicense it under the GNU GPL is permitted." That
would seem to make sense for me. Such a permissive license
that others could modify it and then relicense that combined
product under the GPL. I've no problem there, either.

See? I'm beginning to know more of what I want. But I still
don't know all of what I'd like, as I am obviously just
discovering more and more as I read. Nor do I know how to
write it up. Oh, well.

Jon
From: D Yuniskis on
Hi Vladimir,

Vladimir Vassilevsky wrote:
>>
>>> For those who are interested in the classic error correction math,
>>> the good book is R. Blahut "Theory and practice of the error control
>>> codes"
>>
>> I like _Error-Correcting Codes_ by W Wesley Peterson.
>
> Well known book, also.

Ah, that;s good to know. I inherited it MANY years ago and
have found it answers most questions I ask of it. (though the
typesetting is REALLY hard on the eyes! :< )

>> No doubt out of date.
>
> That's the basis; it couldn't be outdated although they couldn't cover
> the latest discoveries.
>
>> But, requires a considerable math background to
>> truly appreciate much of what is covered (field theory, etc.).
>> And, you won't find any code snippets within. :< But, if
>> you understand the math behind the theory, you can usually
>> roll your own implementation fairly easily.
>
> Code snippets are of no use if you don't understand how they work. And
> if you do understand, then you don't need code snippets.

Yup. I find most of the folks who buy books with code are
looking for "a routine that does....". If they can't find
exactly what they need, the book is often worthless.

>> I will try to chase down a copy of Blahut just to see how it feels.
>
> R. Blahut is a good writer; his books are pleasure to read.
> Besides the book on codes, I can recommend his "Fast Algorithms for
> Signal Processing".

Ah, thanks! I will add that to my list as well.

I'm assuming your endorsement means the books are
*relatively* free of errors? (often highly technical
books are proofread poorly)
From: Frank Buss on
David Brown wrote:

> Static linking is allowed, but it's not straightforward to be compliant
> while linking statically - dynamic linking makes it much easier. With
> static linking, you have to supply linkable object files along with any
> other files or instructions needed for the end user to be able to
> re-compile the LGPL'ed files and re-link with the rest of your object files.

This article:

http://answers.google.com/answers/threadview/id/439136.html

says the same, but it says, that e.g. Richard Stallman does not
interpret the LGPL in this way, so you are safe, if you ask the copyright
holder of the library, before you do such things.

--
Frank Buss, fb(a)frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: D Yuniskis on
Hi Jon,

Jon Kirwan wrote:
> On Sun, 07 Mar 2010 20:58:59 -0700, D Yuniskis
> <not.going.to.be(a)seen.com> wrote:
>
>> steve_schefter(a)hotmail.com wrote:
>>> David Brown <david.br...(a)hesbynett.removethisbit.no> wrote:
>>>
>>>> To use LGPL'ed code with your own code, anyone receiving your code must
>>>> have access to the LGPL'ed code, be able to change and recompile that
>>>> code, then link it along with the rest of the binary and run that
>>>> software instead. For non-embedded systems (or "big" embedded systems),
>>>> that typically means the LGPL'ed code is part of a dynamic library. To
>>>> use LGPL code in a (typically statically linked) embedded system means
>>>> that the end user will need access to your source code, or at least
>>>> compiled and linkable object files. Since that is impractical or
>>>> impossible for most embedded systems, the rough conclusion is that pure
>>>> LGPL code is very seldom suitable for embedded systems.
>>> Okay, thanks. I guess where we differ is in the opinion that
>>> dynamically linked apps are not suitable for embedded systems. The
>>> ones I work on (Linux-based) tend to use dynamically linked apps more
>>> than statically linked ones. In the early days, I've even had to
>>> force the apps to be dynamically linked to fit everything in flash
>>> (several apps linked with the same library).
>> I think the reasons many (most?) embedded systems shy away from
>> "shared objects" are twofold: resources and tools.
>>
>> Small (< 1MB TEXT+DATA) systems
>
> "Modest," for me, is 512 flash and 16 RAM. "Small" would be
> half that. "Decent" and kind of roomy is anything like 4k
> flash and 512 RAM. "Unbelievably big" is 40k flash and 4k
> RAM.

<grin> Yeah, been there. Done that. Have the cramped up
hands to prove it! :>

We designed a LORAN-C (precursor to GPS) plotter with 256 (or
maybe it was 512?) bytes of RAM. When you consider it had to
navigate anywhere around the world, take into account things
like the oblateness of the globe, operate in real-time, etc.
it was amazing how everything fit! I think our floats were
each 6 bytes (kinda hard to do all that trig and hyperbolic
math with ints!) so you can imagine how *few* of those we
had!

> Anywhere _near_ 1Mb of anything is called "monstrously huge,"
> or is just a "workstation" and has way way too many pins or
> is way too expensive or is way too power hungry or has way
> too many extras to worry about. Probably all of those.

Nowadays, 1M is almost as low power as some of the 4 and 8b
machines I grew up with. My network audio client falls
in this category -- mainly because of the data requirements
(though the network stack is also a pig). OS is nice and
lean :>

> My operating system, which supports pre-emption or
> cooperative tasking (either), and messages and sleep and
> semaphore queues and so on can live with singly-linked lists
> (everything is compile-time selectable, so you can remove
> what you don't want or add what you do) for the queues. It
> adds a little extra code and certainly some small execution
> time, but sometimes you want that because RAM is scarse. I
> can shovel it into very small devices. But the nice thing is
> that when I have the RAM for doubly-linked lists, it's just a
> change to a #define and then a recompile. Or if I want to
> support a lot of processes, etc. It's all compile-time
> stuff.

I have a really tiny, fast MTOS (doesn't do real-time
guarantees -- though you can apply it to RT designs
if you exercise discipline) that is a few hundred bytes
(timers, etc.). It can do a context switch in ~1us on
a small processor. I actually use it *inside* interrupt
routines on some machines because it is *that* fast.

>> tend to feel like they don't
>> have the resources to spare on the dynamic binding (I think
>> this is usually silly-talk but the folks building those
>> systems are the ones who have the final say :> ). Personally,
>> I find the overhead to be small and the discipline associated
>> with developing with s.o.'s makes it a *big* win "almost always".
>
> Well, if you consider <1Mb to be 'small,' then most
> certainly.
>
> Despite your earlier agreement with me on some points, we do
> not appear to live in similar programming worlds.

I span almost the entire gamut of application environments.
I don't often write for the desktop, though. I think it
is also a bad practice. Sort of like driving with two feet...

>> The other reason is often poor tools. E.g., you aren't going to
>> find (?) an 8051 compiler/linkage editor that will support
>> this sort of thing. So, to do it, you (the developer) have to
>> build your own tools (this isn't very hard but *is* another
>> step and something *you* have to support -- not the tool vendor).
>
> I've had to develop my own linkers before. Twice, at least.
> It happens. You just don't want to make it happen if you can
> avoid it.
>
>> I think if more folks were accustomed to this sort of
>> run-time environment, they might be more willing to
>> add it to their toolkit (e.g., just like adding PMMU
>> support)
>
> Not sure what to say to that. I understand some of the
> context, but not all of it, I suspect.

Nowadays, with FLASH based systems, it becomes increasingly
more common to swap in bits of your application "as needed".
(i.e. serial FLASH). With dynamic linking (late binding)
this is a piece of cake! Load the code into RAM, make
all the bindings (unresolved externals) to the "resident
code", then "run". When done, throw it away and load whatever
the next part of the application needs to be.