no_std support
jiayihu opened this issue · 18 comments
Is there any plan to support no_std with this crate since CoAP is heavily used in embedded? There is coap-lite but it's unmaintaned and it handles only packet parsing and creation
Can you tell me what would you do in the embedded device?
I'm currently using a MCU called STM32F407 with 512KB flash and 128KB RAM and this lib currently weights too much
. I don't have all the std library or the tokio runtime, some embedded apps don't even have a heap. I'm currently using smoltcp as network stack.
Regarding the usage of CoAP, I'm using it as base protocol for REST api calls to the board to get a description of the resources and other operations like reading data or sending a WASM module.
I've already managed to integrate CoAP using coap-lite and you can see the result here, although it's at its very early stage. I made my own fork and copied to relevant implementation of CoAPRequest and CoapResponse from this crate. At first I thought about making the changes in this repo and submit a PR, but I feel there's too much work for me. This crate is very much relying on crates like bincode, serde and tokio without actually being necessary IMO. For instance I feel it should be out of the crate the responsibility of connecting to a UDP socket.
I think you just need a CoAP message packaging library. The coap-lite fit you well. This library was made for people easy to setup a CoAP server/client.
It would be nice to separate this lib into two crates maybe, one with only message packing with no_std support and another one easy to setup. This would avoid fragmentation of libraries, for instance RFC 8516 has been recently added here and it's missing in coap-lite. In the current situation people like me have to make a fork of coap-lite and try to catch up with any changes that have been made to the packaging modules, creating "yet another fork" that will be forgotten. What do you think? This would also require not much work in this crate and without breaking changes
That sounds like a good idea. I will do it later. Or can you implement the no_std crate and then I use it to packing message ?
Do you mean creating a separate branch where I transform this repo into a workspace and add the no_std crate? Then you add another crate on top of it with tokio (I think serde and bincode won't be needed if you are only encoding/decoding to binary, which is already done in no_std without dependencies)
I think you create a new repo would be better. And I update this repo based on your repo.
My fork is already available at https://github.com/jiayihu/coap-lite where I pushed the latest changes including CoAPResponse and CoAPRequest based on the impl in this crate. I skipped IsMessage though because it seemed a non-necessary indirection.
The fork is no_std compliant without using bincode and serde for binary conversion to [u8]
Can you upload it to https://crates.io/ ? After that I can import it into my repo.
Wouldn't be more correct if you did it? In the end it's practically code that you wrote and you should take credit for it. You would also have more freedom in changes. I can make PRs if I feel something more is needed. Let's also hear if @martindisch is active, I could just make a PR to his already published crate
That's neat, I originally repurposed this implementation into coap-lite because I was working with STM32F3 and STM32F4 too. You could absolutely just make a PR to my repository. But consider that I made a couple of changes to the original code, so this implementation and mine might have digressed quite a bit, making it harder to integrate coap-lite here.
I don't think much work is needed because coap-lite deals only with the packet layer and the main difference is the absense of serde and bincode. The other structs and methods are the same, when I added CoapResponse and CoapRequest in my fork I just had to copy some methods from this crate which had been added meanwhile. That being said, I'm going then to open a PR for you @martindisch . Then let's see if this crate can be based on coap-lite to unify the work 😄
Waiting the pr: martindisch/coap-lite#1
Merged and published Version 0.3.1 on crates.io. Thank you!
@martindisch Can you public the enum https://github.com/martindisch/coap-lite/blob/2788f41cf15365ee84a885f6dd5f87d1a3a1b32f/src/packet.rs#L174 ? I need it in this repo.
Will do, I'll release a new version once I've merged martindisch/coap-lite#2.
Version 0.3.2 is now published, with the Observe option port by @jiayihu. It also publicly exports the ObserveOption enum.
Thanks. I created #54 for this issue. Any reviews are welcome.