Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #27590

Re: Simple filesystem for embedded platform

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>

Show all headers | View raw


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


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