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

Re: Is JSON suitable for embedded applications?

Expand Messages
  • pozzugno
    ... It sounds interesting, I ll look at it in short time. Thank you for your suggestion.
    Message 1 of 6 , Sep 6, 2011
    • 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 2 of 6 , Sep 21, 2011
      • 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 3 of 6 , Sep 21, 2011
        • 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 4 of 6 , Sep 21, 2011
          • 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.