Extended Hamming encode/decode
in [Embedded]
|
Prev: Announcement: New version of UML state machine code generator available
Next: CFP with Extended Deadline of Mar. 21, 2010: The 2010 International Conference on Computer Design (CDES'10), USA, July 2010
From: Jon Kirwan on 7 Mar 2010 20:18 On Sun, 07 Mar 2010 19:02:44 -0600, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: > > >Jon Kirwan wrote: > >> On Sun, 07 Mar 2010 18:22:46 -0600, Vladimir Vassilevsky >> <nospam(a)nowhere.com> wrote: >> >> >>>Jon Kirwan wrote: >>> >>>>Thanks, Vladimir. That helps a lot. This isn't Hamming, >>> >>>But that *is* Hamming. >> >> Okay. Of course. I guess I meant as separate from reed >> solomon and gegenbauer. > >Huh? Reed-Solomons are nonbinary; as for Gegenbauer, he is from >different bookshelf :))) > >> Which is why I mentioned the dates >> you removed from my post in replying. > >VLV http://en.wikipedia.org/wiki/Polynomial_code Jon
From: David Brown on 7 Mar 2010 20:19 Jon Kirwan wrote: > On Sun, 7 Mar 2010 20:45:21 +0100, Frank Buss > <fb(a)frank-buss.de> wrote: > >> Jon Kirwan wrote: >> >>> So what does this mean? If I put out some routines that get >>> directly linked into the code as a separate project file >>> within a project, it's not really part of a "library" per se >>> but really part of the project as a whole, just like any >>> other module file may be. Does this mean the entire project >>> must be disclosed? If not, why not? >> I'm not a lawyer, but I think the idea is that the library has to be >> provided as some dynamic link library, > It doesn't /have/ to be a dynamic library, but that's the typical case. > By "dynamic link library" do you mean this in the way that > Windows used it -- something loaded by the operating system > as a separate file of routines without its own stack, but > accessible to a calling program? If so, that pretty much > excludes all embedded systems I work on. > Yes, that's what he means by "dynamic library" - DLL for windows, .so shared library in Linux, etc. >> so in theory the user can replace it >> easily. > > Well, that would certainly be true for DLLs under Windows if > the user had all the necessary source code required to > regenerate the DLL (or VxD, I suppose.) > There is no requirement in the LGPL that replacement should be /easy/, just that it is possible. >> Linking staticly to a program is not allowed with LGPL > 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. > Somehow, although I've seen that discussed here, I simply > have missed this in reading the license. But it is probably > because I'm confused. > >> (I think >> then the resulting program is GPL'ed). E.g. that's one reason why Qt is >> provided as LGPL and as a commercial license: With the LPGL license you >> have to deploy DLLs, the commercial license allows you to link all in one >> executable-file. For details read the LGPL text, but maybe you'll need a >> lawyer to understand it. > > Yeah. I tried to read it more carefully today and I'm still > not "getting it." > > Jon
From: Jon Kirwan on 7 Mar 2010 20:28 On Mon, 08 Mar 2010 01:45:14 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >Jon Kirwan wrote: >> On Sun, 07 Mar 2010 20:23:26 +0100, David Brown >> <david.brown(a)hesbynett.removethisbit.no> wrote: >> >>> steve_schefter(a)hotmail.com wrote: >>>> Hi David. >>>> >>>>> Why did you pick the LGPL? It basically means that people here can use >>>>> your code in test code, but can't (legally) use it in any "production" code. >>>> This isn't my impression of LGPL. Can I ask what leads you to that >>>> conclusion? >>>> >>>> Steve >>> 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. >> >> In this case, though, the files stand alone. So all the code >> is there and anyone is able to change and recompile it. >> >> I'm still confused, I suppose. >> >>> For non-embedded systems (or "big" embedded systems), >>> that typically means the LGPL'ed code is part of a dynamic library. >> >> But in this case, it's a stand alone set of files that can be >> included into the project as another module. It is just what >> it is, and no more than that. >> >> I'm still confused about what this means to small or large >> systems or why it would make any difference. >> >>> 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. >> >> But since I'm providing all of the source, they have all >> that. Right? >> >>> 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. >> >> I wish I followed from your premises to your conclusion here. >> This is where I'm stuck. I think I can almost understand >> your earlier points -- maybe -- but if I do, your conclusion >> doesn't follow from them. So I must not understand them. >> Which means I still can't reach the conclusion. I feel dumb >> about this, but there it is. >> >>> Of course, in some cases that is exactly what the code supplier is >>> intending - the end user is able to use the code for evaluation and >>> testing, and in non-commercial systems (and also for internal use), but >>> for a commercial system they would get a separate license from the code >>> supplier. That's a valid way of licensing code to developers. But I >>> don't think that was Jon's intention here. >> >> No, it's not. You are right on that point. >> >>> This has been covered endlessly in previous threads in this newsgroup - >>> please let's not have another one unless someone has new points that >>> were not covered recently. >> >> yeah. And I still can't say I am better informed than >> beforehand. Probably just me. But I can use some hand >> holding from those who imagine they follow all this well. >> >> Jon > >At some point, you're going to get an "ah-ha" moment and wonder why you >couldn't see it earlier... I am sure that is so. :) >The problem is not with your code - it is with other people's. > >Suppose I make a little wireless sensor that uses your hamming code as >part of the software. I've got other modules for reading the sensor, >making the obligatory LED blink, and so on. Since the hamming code is >under the LGPL, I give the end user a copy of your hamming code (or a >written offer, valid for three years, etc., etc., according to the >LGPL). The end user finds a bug in the hamming code, and corrects it. > He wants to use this new version in the sensor instead of the old one. > The LGPL gives him the right to do this - I therefore have to pass him >the source code, or at least linkable object files, for the rest of my >code. Note only does he have the right to such code, along with >whatever information is needed to be able to compile, link, download and >run the new binary, but he is free to pass everything along to anyone else. Hmm. I had read this: http://www.gnu.org/licenses/why-not-lgpl.html It seems to actually recommend that I release it under the GPL, not LGPL and says near the top, "using the Lesser GPL permits use of the library in proprietary programs" which is about what I want. But I have to say reading the LGPL text didn't improve things for me. >/Now/ do you see why embedded developers can't (in general) use LGPL'ed >code, unless there is an explicit exception such as is used in eCOS and >FreeRTOS licenses? Well, given your explanation of it, yes. Of course. Jon
From: Jon Kirwan on 7 Mar 2010 20:34 On Sun, 07 Mar 2010 15:12:28 -0800, I wrote: >On Sun, 07 Mar 2010 22:08:03 +0100, David Brown ><david.brown(a)hesbynett.removethisbit.no> wrote: >> <snip> >>I'd go for a FreeRTOS-style modified GPL saying that the original >>"library", and any changes made to it, must be released under the same >>license, while other code linked to the "library" that only uses the >>library's public interface is not bound by the license. eCOS has a >>similar license: >> >><http://ecos.sourceware.org/license-overview.html> > >Thanks, I'll look it over (and hope I understand it better >than I did the LGPL.) Okay. I took a look. It really seems targeted squarely at eCos. I'm not sure I can use it. Its circumstances are quite different. They want modifications made to eCos to benefit all, but they don't want to force people to release their own application code that runs under it. This license would seem to solve a problem for a situation that doesn't apply to my case. It's more like the Apache license, perhaps? Still struggling. Jon
From: D Yuniskis on 7 Mar 2010 20:49
Hi Jon, Jon Kirwan wrote: > On Sun, 07 Mar 2010 22:08:03 +0100, David Brown > <david.brown(a)hesbynett.removethisbit.no> wrote: > >> Jon Kirwan wrote: >>> On Sun, 07 Mar 2010 13:16:44 +0100, David Brown >>> <david(a)westcontrol.removethisbit.com> wrote: >>> >>>> You should drop the "auto" keyword. It has been unnecessary in C for >>>> decades, conflicts with newer C++ standards, and if there are in fact >>>> any compilers that pay attention to it, it will generate worse code >>>> (since "auto" is then a hint to the compiler to put the variable on the >>>> stack, hindering the optimiser). >>> I also use LET when writing BASIC code. It's an idiom of >>> mine, I suppose. But it helps _me_ by placing a written word >>> that explicitly calls my attention to its unique nature in >>> functions and it harms nothing at all. >> Generally, I'm all for "explicit" rather than "implicit". I consider >> the "implicit int" in C to be one of the language's many failings. But >> the keyword "auto" is so archaic that it's only purpose is to confuse >> programmers with less than twenty years of experience. And it conflicts >> directly with modern C++ - that's an indication of how rarely it is used >> in any C code you'd find these days. Unnecessary and gratuitous >> conflicts with C++ is, I would say, harmful. (I would say the opposite >> too - for example, in the little C++ I write, a function taking no >> parameters is void foo(void), which is valid in both languages.) > > I'll hope to hear from others on this topic, rather than just > jumping forward and either accepting or rejecting this > argument. I have my habits and, for now, I can afford to > keep them. But you've put me on notice. Write the way that is most comfortable for you. Just be *consistent*. I've honed my writing style over the past 30 years to something that works well for me, is easy for others to understand, and works with *every* toolchain I've ever had to use. Change? Why?? :> >> Sometimes in this industry, you have to deal with ancient systems or >> ancient tools - I know that well. But you have to draw a line and say >> that the code you write today is for the systems available today, and >> for use with today's software and today's tools. > > Well, you have my answer to that. Someone else's job, if > they want it. C90 remains the "portable" standard for me for > embedded use. Not C99. Not c++. Agreed. I think this is also the case in much of the "open software" community -- folks doing things in whatever way is "best for them" and not necessarily "best" or "best for others". After all, *they* are solving *their* problem and being kind enough to share their solution with "others" -- what right do those others have to define *how* they go about this task? :> >> You take advantage of >> the modern tools and their benefits. If it turns out that you need to >> retrofit your new code to work with an old system, /that/ is the time to >> go out of your way to make it work there. For example, I use // >> comments because they are neater and clearer than /* */ comments (for >> short comments), even though I have a few compilers that don't support >> them. But I won't limit myself just for the sake of a couple of >> projects I haven't touched for years. > > Well, we will simply have to leave this unresolved between > us, then. I can follow your argument, but I don't embrace > it. Agreed. Too often, there *is* a need to back-port things. If you make it harder to do so, then you condemn old designs to languish when they could, otherwise, benefit from "new work". I have a little C interpreter that I wrote back in the 80's. It runs in *old* single-chip devices. It's really nice to be able to take a code fragment and move it into that environment without having to make silly, time wasting syntactic changes *just* to get it to run in that "old context". And, I haven't seen any newly released compilers for Z180's, 6809's, 8x300's, etc. "Sure, I can make those changes to that old codebase for you -- but, you'll have to find someone who makes a more modern compiler for that processor because I *really* like using // comments..." >>> It is a C99 standard, not C90. I honestly wish that I could >>> rely upon C99 (despite some sour comments I've read from at >>> least one compiler author, who I trust to know what he speaks >>> of, that C99 is a terrible standard... an opinion I'm not >>> well enough informed about to argue either way), but that >> C is a terrible language, and C99 is a terrible standard - but they are >> the best we've got in this industry. > > No, C90 is the best. C99 isn't always there. Agreed. >>>> Having first defined these size-specific types, you then ignore them in >>>> the code and use that most hideous of illogical expression, the >>>> "unsigned char". >>> No, the specified size is on purpose, Dave (setting aside for >>> a moment what you will address in a moment regarding my use >>> of unsigned.) >>> >>> In this case, the check values will NEVER exceed that size. >>> Because of that fact, I can insist on it. There is no need >>> for the user of this code to worry about that detail, because >>> I have. Check values, plus parity, of 8 bits will cover 128 >>> bit words. For those interested in exceeding that with my >>> code, I suppose they can modify the code to deal with it. (I >>> might have created a separate typedef, I suppose.) >> I'm not arguing against your use of __HAMM_VALUE_T for size-specific >> types - far from it (though I argue against your use of "__", and I >> forgot to complain about the use of all-caps being ugly to read). > > hehe. What would you consider to be pretty? > >> I'm arguing against using "unsigned char" when what you really mean is >> "unsigned 8-bit integer", generally written "uint8_t". > > Hmm. okay. I changed that. More ugliness, but what the > heck. __HAMM_CHECK_T is used throughout, now. ;) > >>> Do you have a good way I might be able to use sizeof() in a >>> #if? I seem to recall that doesn't work. >> No, you can't use sizeof in an #if. But I can't see why you might want >> to do that here - perhaps we are misunderstanding each other? > > Oh, something like this: > > #if sizeof( __HAMM_VALUE_T ) == 2 Be careful -- sizeof isn't "valid" in preprocessor context! (though many compilers will "do the expected thing" here) > might be useful. There is code that is either needed, or not > needed, depending on the word size. It would be nice to > modify code depending upon the number of check bits required > and the size of the data word. > > That's all. >>>> Until someone can draw me two letter "a"s and explain >>>> to me why one of these is "signed" and the other "unsigned", I will only >>>> use "char" for holding a character. Because char is a misnomer. It should have been called "small" or something else (byte). There is a difference between how char, signed char and unsigned char behave. And, sometimes a cost to using one variant over another (in terms of code generation) >>> Well, then we have a serious problem, Dave. There is quite a >>> difference between c's handling of signed and unsigned in >>> terms of conversions and in this particular case, it becomes >>> important. A shift operation is only one such reason. >>> >>> If you are interested in exploring what happens, go ahead and >>> change the unsigned chars to just char and modify the 1U to a >>> 1, instead, in hamm_xx.c and recompile and check the results. >>> >> I know all about C's handling of "signed char" and "unsigned char" - >> that's not the issue. >> >> But a "char" is a "character", i.e., a letter or character in a string. >> Regardless of what K&R thought, it makes no logical sense to talk >> about a "signed" letter - just as it makes no sense to talk about an Because you are assuming "char" is an abbreviation of "character". typedef it to "small" and then, suddenly, there *is* some sense to having signed and unsigned "smalls". >> upper-case number. "signed char" is a meaningless concept in itself - >> and using any sort of "char" for numbers is dangerous because people >> think they can use plain "char", and then get trouble with >> signed/unsigned issues. >> >> It is true that the original C had no better standard for 8-bit data, >> but C99 does have better types - they are called "uint8_t" and "int8_t". >> And if you have to use a compiler without <stdint.h>, then you define >> these types yourself. >> <snip> > > :) I'm still back on C90. > > I've enjoyed this and you've made me think a little and > change a few things in the process. Plus, I'm still hoping > to learn something about various licenses, too. I opt for a BSD license on most things that *I* own and release. If I didn't want others to use it, then why would I release it? And, why would I want to impose other conditions on the rest of the code? If you use it, fine. Don't be alarmed if one of your competitors ALSO uses it, etc. |