SD Card FAT support issues (dosfs, fatfs,fatlib)

Its probably better in this case to use macros to define accessors. The macros being there just to make the code more readable and self commenting. There isn't any nice solution to this sort of problem for portable code.

Peter

Using the __attribute__((packed)) breaks the code generated using the header files defined for the Philips LPC series which uses bitfields to define the LPC hardware registers. Many of the small development boards come with examples using these header files. In the GCC documentation it also warns that code compiled with this attribute set might not be binary compatible with code compiled without it.

Regards Anton Erasmus

This kind of stuff is a bit concerning you know. Patenting an algorithm of some sort?

-Isaac

Where have you been for the last decade or so?

this

then I

I don't think that you can patent an algorithm, only its use. Clearly in this case there its hard to separate the two though. The text of the first patent talks about a computer system. Does that mean its OK if I'm not using one? It may be difficult to convince a judge that my analytical instrument is not a computer system. What if I never format the media? Here, the patent relates to directory records and could apply to any 8.3 file system so the formatting is probably a red herring. What if I never write the media, perhaps I only want to read existing files? What if I want to open existing files for write? I don't have to update the directory info at all unless I change the length of the file or its starting cluster, and even if I do I only need to update the original 8.3 FAT entry where the length is kept.

In fact, in my case, reading LFN but only writing 8.3 would get me most of the way.

Murky stuff these patents.

Peter

that

I'm

using

patent

existing

Sorry to follow up on my own post but it appears that the legal problems of LFN and FAT can be avoided by paying MS 25 cents a pop. For my situation, where the numbers are small and the unit cost quite high its probably worth it. Many, including me, may resent having to do that but I also resent starving or being sued.

I have also had my attention directed towards commercial FAT support code that has support for LFN. I'm still investigating that. I'm fairly sure it can do what I want but I'm not clear whether there is more work integrating with my other requirements than adding LFN to open/free/public code.

Peter

In the United States you can patent an algorithm.

The way it's done is by describing the algorithm in terms of the operation of a physical device with a descriptive title. For example, you might refer to a computer as a "processing unit" or somesuch, with a "computer" being a proffered example of what a "processing unit" might be. The patent office accepts the patent because it's described in terms of a physical implementation, and the patent lawyers can then argue that an offending implementation fits the descriptive titles. I'm not really sure how other countries go about denying such claims...

Mmm, I just finished writing an article about similar issues. Basically my summary was:

a) IP issues are the biggest barrier to entry into the embedded engineering market, and

b) The EU doesn't "do" software patents - bully for them - but the definitions are so vague that the lawyers are kicking up their heels in joy.

I see a significant difference between 'software' and 'algorithm'. Ultimately I'm more interested in solving my problem than figuring out the niceties of the patent system.

Peter

In article , Peter Dickerson writes

The problem is that you may have a conflict as you could not release the source code with the commercial stuff in it. The Open source may require you to release the modified code...

This is always the problem when using open source. One licence wants all the adapted code to be released and the other says you can't....

In article , larwe writes

How so? There are VERY many patents in the electronic and embedded world... CD and DVD's for a start... hasn't stifled them.

The EU couldn't do SW patents because there is a reciprocal agreement with the US on patents. As soon as the EU had them all the US ones would apply in the EU...... Not a good idea.

For example an EU company could show that it invented the system years before a US company took the patent.... The EU company probably would not have known about the later US patent . What then?

it

integrating

Actually, in the case of FatFS the terms are "You can use, modify and republish it for non-profit or profit use without any limitation under your responsibility". Not that I necessarily want to do that. I think that if I do make use of such code I should at least give something back in return. That might only be providing help and assistance to others who go that route, or it might mean releasing some code. In any case the company I'm working for have their own views, such as wanting there to be someone to blame when things don't work. Buying in a solution means there is someone other than me available for that role, and there is someone who can provide support when I'm hit by a truck. A file full of source code is only a small part of the story.

It seems DosFS has a similar, though more wordy, license.

Peter

I tried to make it as succinct as possible, but I needed to have the major bases covered.

1. I can't allow anyone else to claim ownership of the code fork I offer; otherwise, someone could change one comment, say "DOSFS is mine" and try to suppress my original.
2. I explicitly disclaim liability for any damage caused by the code and require that, as a condition of licensing, the user indemnifies me and keeps me out of any lawsuit.
3. In some jurisdictions, it is not possible to limit liability in this way, even for a giveaway product. Therefore I have to make it clear that if you're covered by such laws, you can't legally use DOSFS.
4. I don't require you to release any sourcecode, or tell me that you're using DOSFS, or do anything else whatsoever. However if you DO tell me you're using it, and you tell me some feature you added or bug you found, this isn't secret information and I may publish it as part of the free DOSFS tree.

your

Yes. I wasn't trying to imply anything odd. I was just justifying not quoting the license verbatim.

Yes. Its your code, it will stay your code. That you let others use it and update it for their one ends is great.

Yes. FatFS has english and japanese docs, so I suspect the author does not have english as their first language. Hence the terseness there. It always pays to make it clear where the resposibility lies for use of the code.

This is the hardest one because now the user must make sure how the law applies to them but noone can blame you for put that in.

Indeed I reported what I perceived to be a problem and you kindly offered to look at it.

Peter

Some edited quotes:

... certainly it is becoming progressively harder to get into the engineering field. This is true both from the perspective of an entrepreneur wanting to make a new product, or a prospective engineering student simply trying to decide what to learn in order to be marketable, and cramming all this knowledge into his or her skull.

The single biggest barrier to entry in product development, particularly for the US market, is intellectual property (IP) issues. Due in part (it is said) to the privations suffered by tech firms after the dot-com implosion, we live in a society of unparalleled IP-related litigiousness. It should be no surprise to you that patents and other IP disputes are a major business - for some technology companies, the only profitmaking business. All over America, there are erstwhile investors who presently hold the worthless remnants of failed companies. Tucked away inside many of these paper corporations is a dusty shoebox full of assorted patents. Armies of lawyers are poring over these documents as you read this, trying to determine if any extant product can be argued to infringe upon those patents.

This is partly the inherent nature of science and engineering; no sane engineer builds everything from scratch. He or she will obviously use time-proven techniques and add whatever new innovation the application requires. In theoretical science, all that's necessary is to cite the proper references when you publish your research, and there are no problems. When you're developing a commercial product, however, big-money patent issues pop up. No product you will ever make can possibly evade this tar pit.

The reason I bring up these IP issues is that as a small entrepreneurial engineering company, you might not be able to afford detailed IP searches for every product you intend to develop. Unfortunately, this means that when you release a product, you're playing Russian roulette with the gun held to your head for a very long time - as much as twenty years, or even longer. Large companies, which can afford to pay for full searches, also have the option of either buying the patent in question, or negotiating cross-licensing agreements with their own patent portfolio; these luxuries are inaccessible to the small firm.

One of the other reasons you're so likely to be bitten by a patent problem when you build a product these days is that interoperability with very recent commercial standards is much more important now than it used to be.

Today, the software and protocol landscape is much more homogeneous than it was twenty years ago. It might not always appear that way to a developer, of course - there are seemingly millions of new extant standards, simply because computers and networks now have many capabilities that didn't exist back in the 1980s. However, in a given field (say, operating systems) there are usually only two or three usefully popular standards, at most. If you want to attach to a modern LAN, you'd be crazy not to support TCP/IP over Ethernet, not to mention a commonly-used higher-level protocol like SMB or HTTP. The fact that so many players are implementing products on the same foundations increases the chance that they are going to infringe on each others' IP rights.

Closely related to the latter point, another big barrier to entry is that these immensely complicated modern systems contain a huge amount of functionality (executed either in software or by the hardware of the system) compared to their more elderly counterparts. It is a stated goal of several large corporations to raise the barriers to entry in their industry by training consumers to require more and more "free" functionality as a baseline.

By the way, some people will argue with this last point. They will point out that a huge amount of infrastructure IP (often free) is now available to get your project off the ground, so the overall effort of developing a new application might even be less than it was in the "good old days". While it is certainly true that there exists a vast amount of software and reference hardware design material available for free, or at least a reasonable cost, I'll point out that this merely trades engineering hours spent writing from scratch for engineering hours integrating and testing. The testing effort required to certify correct operation of a modern product is quite unbelievable (it increases exponentially with a linear increase in the size of the system), and in many cases skipping tests on "proven" components, particularly software components, is foolhardy.

I liked this quote. It fits well the way I see the planet today: overcrowded of useless people fiercely elbowing each other in the necessity to grab some of the goods coming out of the automated factories... So antiutopic.

Dimiter (wishing he were Hari Seldon or at least had some plan...:-)

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

larwe wrote:

It's amusing that you say this, because the intro, which I didn't quote, was this:

Our colleges will cease to offer engineering degrees (since there is no demand), and the knowledge of how to design and build machinery will pass forever into the hands of our outsourcing partners. To borrow a peculiarly apposite image from H.G. Wells, we will become the consumer Eloi, with the rest of the world predatory Morlocks who both feed us and prey upon us.

I imagine our colleagues around European water-coolers hear the same sort of talk. This sort of thing irritates me no end, because there are much more important things than outsourcing to worry an engineer in the twenty-first century.

In a recent book, I described this alarmist line of thinking as the Malthusian school of thought, in a nod to Thomas Malthus (1766-1834). Malthus famously predicted that human population would expand exponentially, outstripping the food supply, with catastrophic results. He was wrong; thus far, technological advances have kept the total potential world food supply well in excess of the needs of our total world population. In my opinion, the Malthusian-style outsourcing doomsayers are wrong as well, but certainly it is becoming progressively harder to get into the engineering field.

Well I only made an observation. I agree there are lots of more important things to do - but this does not change the reality. To quote some more old philosophers, "let's not throw the baby out with the water" regarding Malthus. His formula is naive, however his vision is not - expecting the planet cannot be saturated as a system is simply stupid. Where the point is I don't know - and frankly, like most people, I am busy surviving rather than thinking on things like that, except when triggered and in the suitable mood :-). Overall I am not pessimistic, don't get me wrong. We have evolved so far, with a little (or some more...) luck we can evolve where now we just cannot imagine we could ever be. But this does not change the painful reality of today, which it is for most of the billions walking around. I guess the pain is just part of the push designed into the evolutionary process - so its level is likely to stay with us well regulated as long as there is life... Oh and don't be surprised if life opts to migrate onto silicon - there's so much more of it on Earth than carbon :-). I would say we have made the first few steps that part of the evolution will take - I am sure this will be well understood in this group :-).

Dimiter (wishing more he were Hari Seldon with a less painful plan :-)

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

larwe wrote: