Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27590
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Simple filesystem for embedded platform |
| Date | 2018-02-02 13:22 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <p51l63$apk$1@dont-email.me> (permalink) |
| References | <p4ujob$6gf$1@dont-email.me> <p4ukvj$dp6$1@dont-email.me> <p4us76$r44$1@dont-email.me> <p4ut7c$22j$1@dont-email.me> |
Il 01/02/2018 12:21, David Brown ha scritto:
> On 01/02/18 12:04, pozz wrote:
>> Il 01/02/2018 10:00, David Brown ha scritto:
>>> On 01/02/18 09:39, pozz wrote:
>>>> I'm using lwip that runs httpd over LPC1769 MCU. Now the filesystem for
>>>> httpd can't fit the internal Flash memory anymore. So I'm going to use
>>>> an external SPI Flash memory.
>>>>
>>>> I need some suggestions about a filesystem to use. I need:
>>>>
>>>> - a tool that creates a binary (or Intel HEX) image from a folder on my
>>>> Windows development machine (the image will be downloaded to Flash);
>>>> - file management functions (open, close, read);
>>>> - simple integration with lwip httpd;
>>>>
>>>> I don't need to change the filesystem, so a read-only filesystem is
>>>> enough.
>>>
>>> Do you really need open, close and read functions? All you actually
>>> need is to copy a block of SPI memory into ram. That might simplify
>>> things a bit.
>>
>> Yes, you're right. open/close here can be avoided. read is a must (your
>> copy from SPI to memory RAM is a *read*).
>>
>>
>>> Does your filesystem need to be independent of the main program? Your
>>> filesystem tool could read through the files in a directory, concatenate
>>> them together into a single binary file, and generate a C header with
>>> something like:
>>>
>>> enum {
>>> start_index_html = 0, length_index_html = 4040,
>>> start_favicon_ico = 4040, length_favicon_ico = 840,
>>> start_node_js = 4880, length_node_js = 10391,
>>> ...
>>> };
>>>
>>> If that is enough, then your "tool" could be done as a bash script if
>>> you wanted (I'd use Python myself).
>>
>> I can't understand. Suppose you need to open the URI "/index.html". How
>> to search for this filename in your enum list?
>
> First ask yourself, /do/ you need to search for this URI in a list? An
> embedded web server will often have just one web page - it might not
> even have any other files or URI's at all. Then you don't need to parse
> the incoming URI in any way - you return the same "file" each time. For
> the web server in an application I have, I have 4 files - index.html,
> favicon.ico, 404.html, and a jquery.js file. The searching can be done
> be a set of "if (strcmp....)" checks that are fixed in the code. (My
> server is a little bit beyond that, but not much.)
>
> You are not trying to re-create Apache here - there is no need to make
> things more complex than they have to be for the task in hand. I don't
> know what features you need here, and whether such a method for
> "searching" is enough - but it is possible.
My static web files will be around 20. However I got your point:
auto-generate a hardcoded file-list made by a sequence of !strcmp(). I
think it would be ok.
>>> It will be a little more work if you want to track filenames as well,
>>> rather than having them fixed in the code, but you could generate a
>>> table of indexes, lengths, and names. It is easier if that part can be
>>> linked directly in the C code, but it would be possible to have it at
>>> the start of the binary blob for the SPI.
>>
>> I know I can write something from zero, but I'm sure something already
>> written that can be reused.
>
> My script for reading a bunch of files and putting them in a static data
> structures linked directly with my C code (I guess my microcontroller
> has more flash than yours!) is about 130 lines of Python. Half of that
> is static text copied directly to the generated header and C file. I
> wrote that myself, along with the httpd daemon in C, because I found it
> easier to get the features I wanted than to use the demo server and code
> from the LWIP httpd server. The "filesystem" bit was easy. Perhaps
> writing it from zero is not as hard as you think it might be - while
> finding and adapting existing solutions may be more effort. (Of course
> I cannot give you an answer here, I am just giving ideas for consideration.)
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Simple filesystem for embedded platform pozz <pozzugno@gmail.com> - 2018-02-01 09:39 +0100
Re: Simple filesystem for embedded platform David Brown <david.brown@hesbynett.no> - 2018-02-01 10:00 +0100
Re: Simple filesystem for embedded platform pozz <pozzugno@gmail.com> - 2018-02-01 12:04 +0100
Re: Simple filesystem for embedded platform David Brown <david.brown@hesbynett.no> - 2018-02-01 12:21 +0100
Re: Simple filesystem for embedded platform pozz <pozzugno@gmail.com> - 2018-02-02 13:22 +0100
Re: Simple filesystem for embedded platform David Brown <david.brown@hesbynett.no> - 2018-02-02 14:43 +0100
Re: Simple filesystem for embedded platform Stefan Reuther <stefan.news@arcor.de> - 2018-02-02 19:08 +0100
Re: Simple filesystem for embedded platform pippo2@disney.com (Jack) - 2018-02-01 21:58 +0100
Re: Simple filesystem for embedded platform Dave Nadler <drn@nadler.com> - 2018-02-01 18:18 -0800
Re: Simple filesystem for embedded platform Joe Chisolm <jchisolm6@earthlink.net> - 2018-02-01 17:25 -0600
csiph-web