完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
电子发烧友论坛|
我正在寻找支持或库,允许我将JSON对象序列化为char数组,并将char数组/字符串解析为JSON对象。我查看了JSMN库,但它看起来只是解析,而不是序列化。我目前在ARDUINO板上使用ARDuijJon来执行这些任务,我想将代码迁移到PIC32。我正在寻找尽可能接近的功能,以便于迁移。我是:1。使用ARDIONJSON 2创建内存中的JSON对象。将所有需要传输的数据复制到新创建的JSON对象。3。调用ARDUIONJSON函数将新创建的JSON对象序列化为char数组。4。通过UART 5发送字符阵列。销毁JSON对象(超出范围),并在接收序列化字符串时:1。在内存中创建一个JSON对象并使用ARDuijJSON解析函数填充它。2。将所有相关数据从新创建的JSON对象复制到我自己的数据结构。3。销毁JSON对象(走出范围)。就像我说的,我正在寻找一个类似于这个功能的库,再加上UART/串行通信。我会感激任何建议,就是这样的东西存在。提前感谢。
以上来自于百度翻译 以下为原文 I am looking for support or libraries to allow me to serialize a JSON object into a char array and to parse a char array/string into a JSON object. I looked into the jsmn library but it looks like it only does parsing, not serializing. I am currently using ArduinoJson on an Arduino board to perform those tasks and I would like to migrate the code to a PIC32. I am looking for as close a functionality as possible for ease of migration. I am: 1. Creating a JSON object in memory, using ArduinoJson. 2. Copying all the data I need to transmit into the newly created JSON object. 3. Calling an ArduinoJson function to serialize the newly created JSON object into a char array. 4. Transmitting the char array through UART. 5. Destroying the JSON object (going out of scope). And when receiving a serialized string: 1. Create a JSON object in memory and populate it using ArduinoJson parse function. 2. Copy all relevant data from the newly created JSON object to my own data structures. 3. Destroy the JSON object (going out of scope). Like I said, I am looking for a library that will closely resemble this functionality, coupled with UART/Serial communication. I will appreciate any suggestions, is such a thing exists. Thanks in advance. |
|
相关推荐
19个回答
|
|
|
你看过DaveGamble在吉瑟布上的CJSON吗?我认为这是一种比较流行的实现方式。
以上来自于百度翻译 以下为原文 Have you looked at cJSON by DaveGamble on GitHub? I think this is one of the more popular implementations. |
|
|
|
|
|
谢谢。我仔细看了看,看起来很有希望。我会深入研究的。
以上来自于百度翻译 以下为原文 jg_ee Thanks. I looked into it a bit and it looks promising. I will look further into it. |
|
|
|
|
|
我已经使用了这两个库。CJSON有一个更好的接口,并生成和解析JSON。不幸的是,该库使用了大量的分配/免费语句,因此RAM内存使用率相当高且不可预测。JSMN仅解析并具有较差的接口,但它使RAM使用最小化,只使用静态存储器。使用SaveTF生成JSON相对容易。如果您有很多内存,CJSON是一个不错的选择。
以上来自于百度翻译 以下为原文 I have used both libraries. cJSON has a much better interface, and generates as well as parses the JSON. Unfortunately the library uses a lot of allocate/free statements, so RAM memory usage is fairly high and unpredictable. jsmn only parses and has a poorer interface, but it minimizes the RAM usage and only uses static memory. Generating JSON is relatively easy using sprintf. If you have a lot of memory cJSON is a good choice. |
|
|
|
|
|
您是否尝试直接传输数据,而不浪费您的时间和MCU资源将数据转换为JSON?
以上来自于百度翻译 以下为原文 Have you tried transmitting data directly, without wasting your time and MCU resources on converting the data to and from JSON? |
|
|
|
|
|
NordGuyYes,这将节省大量的MCU资源,我同意。不幸的是,在我的项目中,MCU串行地与一个具有一个TCP/IP栈的WiFi服务器的ESP8266通信,并且该服务器负责使用服务器发送的事件将数据来回传送到Web页面。该数据被限制在7位ASCII中,这限制了值的范围。我可以转移,有效地使JSON是唯一可行的选择,如果我想转移全范围的值。我不想负担的ESP的转换,因为它处理时间敏感的TCP/IP服务器软件,因为它是。只剩下MCU。我相信还有其他设置可以绕过这个限制,但这是项目设计,因为它是。BTW,有一个库或工具来帮助管理RAM内存在运行时间在MCU的?垃圾收集器?也许这将有助于处理动态记忆分配的副作用?提前感谢。
以上来自于百度翻译 以下为原文 NorthGuy Yes, that would save a lot of MCU resources, I agree. Unfortunately, in my project the MCU communicates serially with an ESP8266 that functions as a WiFi server with a TCP/IP stack, and that server is tasked with relaying data back and forth to the web page using Server Sent Events. That data is limited to 7 bit ASCII, which limits the range of values I can transfer, effectively making JSON the only viable option if I want to transfer the full range of values. I don't want to burden the ESP with the conversion as it deals with time sensitive TCP/IP server software as it is. That leaves only the MCU. I'm sure there are other setups that could go around this limitation, but this is the project design as it is. btw, is there a library or a tool to help manage RAM memory during run time in MCU's? sort of a garbage collector? maybe that would help deal with the side effects of dynamic memory allocations as malaugh has pointed out? Thanks in advance. |
|
|
|
|
|
虽然JSON是一个选项,但它不是唯一的一个。CSV也应该这样做。如果您正在服务,同一个JSON提交的SNPrnter()也会创建它们。如果只接收到相同的文件,那么解析可能也不难。一般情况下需要图书馆。
以上来自于百度翻译 以下为原文 While JSON is an option, it is not the only one. CSV should do the same. If you are serving the same JSON filed over and over snprint() will create them too. If you are only receiving a the same files then parsing may not be that hard either. The library is needed for a general case. |
|
|
|
|
|
我个人认为JSON是个不错的选择。我们在设计中越来越多地使用它。当对象数据和CSV的直接传输将工作时,随着设计随着时间的推移而开始出现问题。如果有一个传输方案,串行数据流中的位置决定了该值所代表的值,那么很难添加需要更多或不同值的特征,并且仍然保持向后兼容性。很容易将单半径值直接发送,或者基于CSV格式,但是,后来的设计增加了一个具有侧维度的正方形,JSON很容易将JSON从{RADIUS:20 }改为{RADIUS:20,边:40 },而不支持正方形的旧单元将忽略侧。将CSV从“20”改为“20,40”,保持兼容性是比较困难的,唯一的成本是库的额外程序内存需求和关键字。
以上来自于百度翻译 以下为原文 Personally I think JSON is a good choice. We are using it more and more in our designs. While direct transmission of the object data and CSV will work, issues start arising as the design changes over time. If you have a transmission scheme where position in the serial data stream dictates what the value represents, then it becomes very difficult to add features that require more or different values, and still maintain backwards compatibility. For example if an object is a circle with a radius, then is is very easy to transmit the single radius value directly, or on CSV format, however, of a later design adds a square with a side dimension, it is very easy in JSON to change the JSON from { radius:20 } to { radius:20, side:40 }, and the older units, that do not support squares will ignore the side. It is much more difficult to change the CSV from "20" to "20,40" and maintain the compatibility. The only cost is the extra program memory need for the library, and the keywords. |
|
|
|
|
|
我怀疑数据仅限于7位值。这在40年前是很常见的。无论如何,Base64(甚至十六进制)应该工作。至于版本控制,我认为JSON在这里没有任何帮助。你把版本(和可能的长度)合并到被转移的数据结构中:这是非常有效和稳健的做事方式。在所有方面,JSON BULAT比Malo的方法少3倍,没有编码或解析代码,很少维护/扩展性。
以上来自于百度翻译 以下为原文 I doubt the data are limited to 7-bit values. This was common 40 years ago ... Anyway, Base64 (or even Hexadecimal) should work. As to the versioning, I don't think JSON is of any help here. You incorporate version (and possibly length) into the data stracture being transferred: #define DATA_TRANSFER_VERSION 2 typedef struct { uint8_t version; uint8_t length; uint16_t radius; uint16_t side; // added in version 2 } data_transfer; This is very efficient and robust way of doing things. Beats the JSON bloat in every respect - 3 times less transfer size than in malaugh's method, no code to encode or parse, very little maintenance/extensibility effort. |
|
|
|
|
|
诺斯古伊大体上同意你的观点。JSON更大,更难解析。但他确实保存了Web服务器。JSON是一种通用的数据传输方式,它被构建成浏览器和其他Web的东西。
以上来自于百度翻译 以下为原文 NorthGuy I agree with you in general. JSON is bigger and harder to parse. But he did save web server. and JSON is a common way to transfer data the is builtin to browsers and other web stuff. |
|
|
|
|
|
Hi NothGuii同意直接对象传输适用于简单的例子(也许我让我的例子太简单,让我的观点),但如果你的对象是复杂的嵌入式数组结构,类似的东西变得更棘手。
以上来自于百度翻译 以下为原文 Hi NothGuy I agree direct object transmission works for simple examples (and maybe I made my example too simple to get my point across), but if your object is complicated with embedded arrays of structures, something like typedef struct { UINT8 Red; UINT8 Green; UINT8 Blue; } DB_COLOR; typedef struct { UINT8 len; UINT8 height; DB_COLOR Color; } DB_AREA_ENTRY; typedef struct { UINT8 numberOfEntries; DB_AREA_ENTRY Entries[20]; } DB_MAIN; It gets a lot trickier |
|
|
|
|
|
JSON也不会匆忙离开。还记得XML吗?大声笑
以上来自于百度翻译 以下为原文 JSON is not going away in a big hurry either. Remember XML? lol |
|
|
|
|
|
这是另一个考虑用JSON使事情复杂化的考虑。如果过去是任何迹象,我们应该在未来期待更多的膨胀。
以上来自于百度翻译 以下为原文 Which is another consideration against complicating things with JSON. So true. If the past is any indication, we should expect much more bloat in the future. |
|
|
|
|
|
你想做什么方法来转移数据?我正在考虑是否应该通过JSON通过HTTPS获得PIC32获取数据。有很多理由要做到这一点,最令人信服的是,交付它的服务器基础设施是微不足道的。
以上来自于百度翻译 以下为原文 What method are you wanting to do the transfer of data over. I'm considering right now if i should have pic32 get data via JSON over HTTPS. Theres a bunch of reasons to do this, the most comelling is that the server infrastructure to deliver it is trivial. |
|
|
|
|
|
HTTPS非常重。身份验证是基于证书的。这可能有问题。例如,不久前,社区决定他们不信任Sa1证书,而你需要Sa256。开关将需要在PIC侧进行大修代码。您可以成为您自己的证书颁发机构,但这将需要一个额外的IP地址只是为PICS -浏览器将不信任您的自制证书。证书处理代码需要DER解析等许多特殊的东西,您在PIC上不需要这样做。我将避免SSL标准,直接使用认证/加密,而不使用证书,但只使用一对KESSA LASSH。当然,我将使用纯HTTPU。服务器的“基础结构”将与JSON一样使用二进制数据,除非使用二进制数据,PIC结束时不需要解析任何内容。
以上来自于百度翻译 以下为原文 HTTPS is very heavy. Authentication is based on certificates. There may be a problem with this. For example, not long ago, the community decided that they're not going to trust SHA1 certificates and you need SHA256. The switch would require code overhaul on the PIC side. You can become your own certificate authority, but this would require an extra IP address just for PICs - browsers won't trust your home made certificates. The certificate handling code requires DER parsing etc. and lot of peculiar stuff which you do not otherwise need on your PIC. I would avoid the SSL standard and do the authentication/encryption directly, without using certificates, but with only a pair of keys a la SSH. Of course I would use plain HTTP unless the encryption is absolutely necessary. The server "infrastructure" will work with binary data just as well as with JSON, except if you use binary data you do not need to parse anything on the PIC end. |
|
|
|
|
|
如果您需要发布的服务仅是AVAIALBLIVATHTPS,那么您别无选择,只能使用它。Sa256是可用的HARDWare加速的,同时也是一个软件选项的和谐,既工作又不太重(只有HKLAST加速的几个KB)。不要把它看成是一个问题。当你不操作你正在获取数据的服务器时,成为CA的TnAN选项。既然你想确定它,你需要看看证书,如果你只能得到JSON数据,那就是你能得到的。-解析证书并不繁琐,它们格式化好。我觉得我看到了一个例子,但是我很难记住在DeV板上的哪一个。
以上来自于百度翻译 以下为原文 If the service you need to post to is only avaialble via HTTPS, then you have no choice but to use it really. Sha256 is availaible harware accelerated, and also as a software option in harmony and both work and are not too heavy ( only a few kb for the harware accelerated ). NDo'nt see that as an issue. Becoming a CA is'tn an option when you dont' operate the server you are getting data from. And since you want some certainity for it, you need to look at the certs. And again, if you can only get the JSON data, thats what you can get. :-) Parsing certs is not that cumbersome, they are well formatted. I seem to think I saw an example of this somwhere, but i'm struggling to remember where, on one of the dev boards. |
|
|
|
|
|
有一个例子;和谐。ITSWOLSFLSLTCP客户端
以上来自于百度翻译 以下为原文 There is an example; in harmony. Its wolfssl_tcp_client |
|
|
|
|
|
对于HTTPS,您需要像保鲁夫这样的SSL库,但并不便宜。
以上来自于百度翻译 以下为原文 For HTTPS you will need a SSL library like Wolf, but it is not cheap. |
|
|
|
|
|
这是一个奇怪的许可证,它的GPL,或支付…但是,当我在被覆下看时,所有的密码功能都不在他们的图书馆里。他们只是提供胶水。对于一种产品,我想买它。对于一些产品来说,它的昂贵…是时候让我们建立一个替代品了。
以上来自于百度翻译 以下为原文 its a weird licence, its GPL, or pay... WHen i look under the covers though, all the crypto functions are not in their librarys. they are just providing the glue. For one product i'd problaby pya for it. For several products its expensive... Time for us to build a replacmeent i say. |
|
|
|
|
|
还有其他SSL库可用,但它们需要移植到和声中。它们连接到Neress层。
以上来自于百度翻译 以下为原文 There are other SSL libraries available, but they would need to be ported to harmony. They connect to the netpress layer. |
|
|
|
|
只有小组成员才能发言,加入小组>>
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475 浏览 0 评论
5795 浏览 9 评论
2334 浏览 8 评论
2224 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3530 浏览 3 评论
1125浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
1098浏览 1评论
我是Microchip 的代理商,有PIC16F1829T-I/SS 技术问题可以咨询我,微信:A-chip-Ti
873浏览 1评论
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475浏览 0评论
/9
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-12-2 18:27 , Processed in 1.412789 second(s), Total 108, Slave 91 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191

淘帖
2359