Comments (18)
Can you tell me what would you do in the embedded device?
from coap-rs.
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.
from coap-rs.
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.
from coap-rs.
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
from coap-rs.
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 ?
from coap-rs.
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)
from coap-rs.
I think you create a new repo would be better. And I update this repo based on your repo.
from coap-rs.
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]
from coap-rs.
Can you upload it to https://crates.io/ ? After that I can import it into my repo.
from coap-rs.
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
from coap-rs.
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.
from coap-rs.
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 😄
from coap-rs.
Waiting the pr: martindisch/coap-lite#1
from coap-rs.
Merged and published Version 0.3.1 on crates.io. Thank you!
from coap-rs.
@martindisch Can you public the enum https://github.com/martindisch/coap-lite/blob/2788f41cf15365ee84a885f6dd5f87d1a3a1b32f/src/packet.rs#L174 ? I need it in this repo.
from coap-rs.
Will do, I'll release a new version once I've merged martindisch/coap-lite#2.
from coap-rs.
Version 0.3.2 is now published, with the Observe option port by @jiayihu. It also publicly exports the ObserveOption
enum.
from coap-rs.
Thanks. I created #54 for this issue. Any reviews are welcome.
from coap-rs.
Related Issues (20)
- Generic subject observer (RFC 7641) support HOT 5
- Server::run abruptly returns when a response payload is too large HOT 4
- Observe requests crash server if the client uses an empty vec![] to represent Observe: 0
- Migrate to Rust 2021 edition HOT 1
- Updating observes from server? HOT 10
- Crash when using python aiocoap HOT 2
- Unexpected panic due to network connectivity state HOT 1
- Outdated documentation refrenced HOT 1
- Message IDs and tokens not set HOT 2
- Client: Separate responses not processed HOT 2
- GET, POST etc. with Uri-Host HOT 2
- Blockwise transfer for with a request payload HOT 4
- Server response retransmission due to duplicate client request (duplicate MID) HOT 3
- Update coap-lite dependency HOT 2
- 0.12.2's update of coap-lite is incompatible HOT 1
- No easy way to set options in client requests HOT 8
- The observer implementation and my use case HOT 7
- Mio 1.8.8 incompatible with newer Tokio versions HOT 3
- observe uses hard-coded default receive timeout HOT 1
- Inject/queue a notification for the Server to dispatch HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coap-rs.