Loading ...
Sorry, an error occurred while loading the content.

Is JSON suitable for embedded applications?

Expand Messages
  • pozzugno
    Dear group, I m a firmware developer on small embedded platform. Until now, I used to read/write the in-memory configuration C structures (with padding bytes)
    Message 1 of 6 , Sep 6 9:30 AM
    • 0 Attachment
      Dear group,

      I'm a firmware developer on small embedded platform.

      Until now, I used to read/write the in-memory configuration C structures (with padding bytes) from/to a non-volatile memory.
      This approach was sufficient for my old needs.

      Actually I want to improve the configuration file format, most of all to face the upgrade situations. When I create a new version of my application, usually I have a new configuration C structure, so a new file format for the configuration. After the upgrade, the software should be capable to read the configuration in the old format, make the relevant changes and save the configuration in the new format.

      Could JSON data format be useful for me? Consider that my C compiler doesn't support malloc()/free() functionalities, but only static and automatic variable allocations. Is there a JSON C implementation suitable for small embedded applications, without malloc()/free() and capable reading/writing without storing the entire configuration in RAM?

      Any suggestion for other data format?
    • jonathan wallace
      I don t see why not.  JSON is lightweight, I use it for configuration all the time.  I maintain a project called libjson that might work well for you.
      Message 2 of 6 , Sep 6 10:12 AM
      • 0 Attachment
        I don't see why not.  JSON is lightweight, I use it for configuration all the time.  I maintain a project called libjson that might work well for you.  There are ways to configure it so that it never calls malloc/free, and it has compiling options for embedded systems.

        If you want to know how to do this with libjson, you can email me directly, or ask on the sourceforge page.
         

        ________________________________
        From: pozzugno <pozzugno@...>
        To: json@yahoogroups.com
        Sent: Tuesday, September 6, 2011 12:30 PM
        Subject: [json] Is JSON suitable for embedded applications?


         
        Dear group,

        I'm a firmware developer on small embedded platform.

        Until now, I used to read/write the in-memory configuration C structures (with padding bytes) from/to a non-volatile memory.
        This approach was sufficient for my old needs.

        Actually I want to improve the configuration file format, most of all to face the upgrade situations. When I create a new version of my application, usually I have a new configuration C structure, so a new file format for the configuration. After the upgrade, the software should be capable to read the configuration in the old format, make the relevant changes and save the configuration in the new format.

        Could JSON data format be useful for me? Consider that my C compiler doesn't support malloc()/free() functionalities, but only static and automatic variable allocations. Is there a JSON C implementation suitable for small embedded applications, without malloc()/free() and capable reading/writing without storing the entire configuration in RAM?

        Any suggestion for other data format?




        [Non-text portions of this message have been removed]
      • pozzugno
        ... It sounds interesting, I ll look at it in short time. Thank you for your suggestion.
        Message 3 of 6 , Sep 6 11:43 AM
        • 0 Attachment
          --- In json@yahoogroups.com, jonathan wallace <ninja9578@...> wrote:
          >
          > I don't see why not.  JSON is lightweight, I use it for configuration all the time.  I maintain a project called libjson that might work well for you.  There are ways to configure it so that it never calls malloc/free, and it has compiling options for embedded systems.
          >
          > If you want to know how to do this with libjson, you can email me directly, or ask on the sourceforge page.

          It sounds interesting, I'll look at it in short time. Thank you for your suggestion.
        • rkalla123
          In another thread I submitted a proposal for a binary format specification for JSON that you might find handy in an embedded system:
          Message 4 of 6 , Sep 21 12:42 PM
          • 0 Attachment
            In another thread I submitted a proposal for a binary format specification for JSON that you might find handy in an embedded system:
            http://tech.groups.yahoo.com/group/json/message/1685

            It might be worth a look. The format is very simple (1 construct) used to define all the different types in JSON so it is easy to read and write.
          • Stephan Beal
            ... It sounds like binary is your best bet, but if you re willing to hack/experiment a little... i have a portable C89/C99 json library (
            Message 5 of 6 , Sep 21 1:27 PM
            • 0 Attachment
              On Tue, Sep 6, 2011 at 6:30 PM, pozzugno <pozzugno@...> wrote:

              > **
              >
              > Could JSON data format be useful for me? Consider that my C compiler
              > doesn't support malloc()/free() functionalities, but only static and
              > automatic variable allocations. Is there a JSON C implementation suitable
              > for small embedded applications, without malloc()/free() and capable
              > reading/writing without storing the entire configuration in RAM?
              >
              > Any suggestion for other data format?
              >
              It sounds like binary is your best bet, but if you're willing to
              hack/experiment a little...

              i have a portable C89/C99 json library (
              http://whiki.wanderinghorse.net/wikis/cson/) which, with only minor changes,
              could use a custom allocator. i also just happen to have a custom allocator
              (http://fossil.wanderinghorse.net/repos/whalloc/index.cgi/wiki/whalloc_bt)
              which
              allows clients to give it a chunk of static (or otherwise-allocated) memory
              for it to malloc/realloc/free from (it was designed for _small_ apps which
              cannot/do not want to call malloc()). With that combination (again, with a
              small amount of hacking), if you know the approximate memory requirements in
              advance and you can spare it, i think it would work. You could also test it
              without your embedded device, and tweak/optimize the memory parameters, by
              using the same static memory block size on a dev environment. If you're
              interested in trying that out, send me your rough memory limits (off list:
              sgbeal googlemail com) and i'll see if i can throw it together. i can't
              guaranty it would work without a single malloc(), but (A) i think it could
              and (B) it might be fun to try. cson is fairly heavily optimized for a
              minimal number of calls to malloc(), that being an explicit design goal.

              i would also recommend looking at the jansson C library, but if i'm not
              sorely mistaken, cson is better optimized for low memory consumption.
              jansson supports, e.g., handling of cyclic structures, and that inherently
              adds memory costs. jansson also allows mutation of values after creating
              them, which (if i'm not mistaken) implicitly precludes certain pedantic
              malloc() reduction optimizations which cson does (i had to remove the
              mutator functions from the public API in order to be able to make some of
              those optimizations).

              --
              ----- stephan beal
              http://wanderinghorse.net/home/stephan/


              [Non-text portions of this message have been removed]
            • Mark Joseph
              I don t see the point of using something new for binary data. Clearly this is not JSON. If you have an application that needs an encoding that handles
              Message 6 of 6 , Sep 21 3:10 PM
              • 0 Attachment
                I don't see the point of using something new for binary data. Clearly this is not JSON. If you have an application that needs an encoding that handles binary I suggest ASN.1 encoding (which is used by LDAP and SNMP)
                http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

                ASN.1 handles binary and text data, it is extensible and easy to parse. There are also existing software for it.



                Mark Joseph, Ph.D.
                President
                P6R, Inc
                408-205-0361
                mark@...
                Skype: markjoseph_sc
                _____

                From: Stephan Beal [mailto:sgbeal@...]
                To: json@yahoogroups.com
                Sent: Wed, 21 Sep 2011 13:27:54 -0700
                Subject: Re: [json] Is JSON suitable for embedded applications?






                On Tue, Sep 6, 2011 at 6:30 PM, pozzugno <pozzugno@...> wrote:

                > **
                >
                > Could JSON data format be useful for me? Consider that my C compiler
                > doesn't support malloc()/free() functionalities, but only static and
                > automatic variable allocations. Is there a JSON C implementation suitable
                > for small embedded applications, without malloc()/free() and capable
                > reading/writing without storing the entire configuration in RAM?
                >
                > Any suggestion for other data format?
                >
                It sounds like binary is your best bet, but if you're willing to
                hack/experiment a little...

                i have a portable C89/C99 json library (
                http://whiki.wanderinghorse.net/wikis/cson/) which, with only minor changes,
                could use a custom allocator. i also just happen to have a custom allocator
                (http://fossil.wanderinghorse.net/repos/whalloc/index.cgi/wiki/whalloc_bt)
                which
                allows clients to give it a chunk of static (or otherwise-allocated) memory
                for it to malloc/realloc/free from (it was designed for _small_ apps which
                cannot/do not want to call malloc()). With that combination (again, with a
                small amount of hacking), if you know the approximate memory requirements in
                advance and you can spare it, i think it would work. You could also test it
                without your embedded device, and tweak/optimize the memory parameters, by
                using the same static memory block size on a dev environment. If you're
                interested in trying that out, send me your rough memory limits (off list:
                sgbeal googlemail com) and i'll see if i can throw it together. i can't
                guaranty it would work without a single malloc(), but (A) i think it could
                and (B) it might be fun to try. cson is fairly heavily optimized for a
                minimal number of calls to malloc(), that being an explicit design goal.

                i would also recommend looking at the jansson C library, but if i'm not
                sorely mistaken, cson is better optimized for low memory consumption.
                jansson supports, e.g., handling of cyclic structures, and that inherently
                adds memory costs. jansson also allows mutation of values after creating
                them, which (if i'm not mistaken) implicitly precludes certain pedantic
                malloc() reduction optimizations which cson does (i had to remove the
                mutator functions from the public API in order to be able to make some of
                those optimizations).

                --
                ----- stephan beal
                http://wanderinghorse.net/home/stephan/

                [Non-text portions of this message have been removed]




                [Non-text portions of this message have been removed]
              Your message has been successfully submitted and would be delivered to recipients shortly.