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 14:37 On Sun, 7 Mar 2010 20:26:33 +0100, Frank Buss <fb(a)frank-buss.de> wrote: >Jon Kirwan wrote: > >> Partly, I think, because I'm not yet even sure what I want. > >That's the first thing you have to solve :-) hehe. That's why I called it out. Some of the licenses worry about patent retaliation. I've no idea what that is like or if I care about it, or not. It's things like that which require some kind of legal education and experience that I'm largely lacking. So I have no idea which way to choose. >Maybe a short explanation can help: LGPL allows other developers to build a >library from your source code and this library can be used in closed source >programs, but the library source and all changes to the library has to be >made public. If it is GPL, anything which uses it has to be public and GPL, >too. 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 think I understand your writing if the code were provided as a contribution to a larger system of library files that would be included by a compiler tool. In that case, the whole library must be disclosed but not the private project, if I gather your meaning. But provided as isolated files and not part of some library of files, what does this mean? >For most public projects, I prefer the BSD license: Do whatever you want >with it, but add some credits of the original author to your documentation. That makes sense. I will go back and re-read that one, again. Jon
From: Jon Kirwan on 7 Mar 2010 14:42 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
From: Frank Buss on 7 Mar 2010 14:45 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, so in theory the user can replace it easily. Linking staticly to a program is not allowed with LGPL (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. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Tim Wescott on 7 Mar 2010 14:46 David Brown wrote: > On 07/03/2010 01:56, Jon Kirwan wrote: -- snip -- >> I've isolated these into three short modules -- one for each >> of the three data types required. There's an encode and >> decode routine in each. If anyone is interested in the >> results, here's a link to the code. >> >> http://www.infinitefactors.org/misc/hamm.zip >> >> A very short demo program that tests the routines and >> illustrates their use is also included. There is a small -- snip some more -- >> Jon > > Hi Jon, > -- snip even more -- > 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. -- and yet more -- Uh, no. The "GPL" part means that if someone incorporates it into a bit of production hardware they need to publish the parts of Jon's code they used. The "L" part means that they _don't_ have to publish any code that they wrote to link against Jon's code (unlike the "full" GPL, which includes the source of anything you link against). There are products out there that ship under GPL and LGPL -- witness the older Linksys routers, which ran Linux and for which there is a web page with full source --> for the 'regular' Linux parts <-- available. Granted, many companies aren't willing to include _anything_ that has a GPL or LGPL license, because they don't want to go to the trouble of sorting out what's what and publishing the "gotta publish" bits without publishing the "we want this a secret" bits. Change "legally" to "for most commercial purposes given today's corporate culture" and you'll be 100% correct. Were Jon willing to go to the trouble and pain _himself_, this would be a prime candidate for a dual licensing scheme. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Vladimir Vassilevsky on 7 Mar 2010 14:56
Jon Kirwan wrote: > On Sun, 07 Mar 2010 08:58:17 +0100, whygee <yg(a)yg.yg> wrote: > > >>Jon Kirwan wrote: >> >>>Vladimir Vassilevsky wrote: >>> >>>>If your goal is the absolutely the smallest code, Meggit decoder is a >>>>way to go. It is going to be rather slow though. It only takes ~10 lines >>>>of code to decode either of the codes; the decoder is going to be >>>>identical except for a couple of constants. > > >>I've never heard of Meggit, however SECDED is often good enough >>when speed is needed, for example in real-time communications >>(radio or long wires anyone ?) > > > I've not heard of Meggit, either. Perhaps Vladimir can > discuss it, since he has put it on the table for us. 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" // Meggitt decoder demo // (c) VLV // 32.26 ext. Hamming code d = 4 // Polynomial: X5 + X2 + 1 // Corrects one error and detects two const u8 UNCORRECTABLE = 0xFF; u8 Polynom(u32 data) { for(u8 ci = 0; ci < 26; ci++) { if(data&0x80000000) data = (data<<1)^0x28000000; else data <<= 1; } return (u8)(data>>27); } u8 Parity(u32 data) { data ^= data>>16; data ^= data>>8; data ^= data>>4; data ^= data>>2; data ^= data>>1; return (u8)(data&1); } u32 Encode(u32 data) { data <<= 6; data |= Polynom(data)<<1; data |= Parity(data); return data; } u8 Decode(u32 &data) { u8 s, p; s = Polynom(data); p = Parity(data); if(s) { if(!p) return UNCORRECTABLE; u32 mask = 0x80000000; for(;;) { if(s == 0x12) { data ^= mask; return 1; } mask >>= 1; s <<= 1; if(s & 0x20) s ^= 0x05; s &= 0x1F; } } if(!p) return 0; data ^= 1; return 1; } //----------------------------- Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |