That is what I've observed too. My impression is that people go to RTOS for libraries and dependency management, which you kinda just get out of the box with Rust, cargo and crates.io. A lot of applications simply don't…
One of the things not immediately apparent for people coming to Embassy is that you can mix and match RTIC with the Embassy HALs. So the more appropriate comparison is RTIC vs the Embassy async executors.
Check out https://vespa.ai
Async Rust is great for embedded! Check out https://embassy.dev as well which is very similar but with support for more hardware.
You might want to take a look at the embassy project for a unified stm32 HAL. The idea is that it defines the APIs per peripheral version as defined by STM (spi v1, spi v2, usart v1 etc). The advantage is that a given…
You can use a subset of MQTT for ingress data and store it in Kafka for instance. Check out https://www.drogue.io and https://sandbox.drogue.cloud for an open source project that does that
This was an inaccuracy on my part, sorry for that. It should probably have been "... used in multiple places _at the same time_".
Having distinct types for P0 and P1 is deliberate and is what is called "type state programming" in the embedded rust book [0]. The advantage is that you can prevent misconfiguration at compile time (ensuring that a…
I’ll throw in another alternative to look at for those using Kubernetes: https://enmasse.io
I'll add that the AMQP 1.0 spec (supported in Rabbit using a plugin) is a peer-to-peer protocol that supports both the traditional broker use case, 'direct' p2p messaging and opens some interesting uses of message…
For Java, have a look at vertx-proton which builds on top of proton-j and is a bit more intuitive (still not great) than proton-j for creating servers and clients. :) Example “blocking” client…
Couple of protocols that would be nice to benchmark for comparison: * AMQP 1.0 - can also be used for RPC without a broker in between client and server. See https://qpid.apache.org/proton/ * Aeron - low latency, UDP…
If you don’t use any other pattern than request-response, I agree there is no point. If you have a mix of pub-sub, work queues and request-response, it could simplify your dependencies perhaps. Also AMQP 1.0 has some…
I recommend looking at a standard messaging protocol like AMQP 1.0, which will allow you to implement the request-response pattern in an efficient manner without message brokers. Either “direct” client server as with…
Check out Vespa: https://vespa.ai
You can also use AMQP 1.0, an ISO and OASIS standard protocol, over websockets. It supports RPC and pub/sub semantics and has client libraries in many languages. It’s implemented by many messaging components as well as…
That is what I've observed too. My impression is that people go to RTOS for libraries and dependency management, which you kinda just get out of the box with Rust, cargo and crates.io. A lot of applications simply don't…
One of the things not immediately apparent for people coming to Embassy is that you can mix and match RTIC with the Embassy HALs. So the more appropriate comparison is RTIC vs the Embassy async executors.
Check out https://vespa.ai
Async Rust is great for embedded! Check out https://embassy.dev as well which is very similar but with support for more hardware.
You might want to take a look at the embassy project for a unified stm32 HAL. The idea is that it defines the APIs per peripheral version as defined by STM (spi v1, spi v2, usart v1 etc). The advantage is that a given…
You can use a subset of MQTT for ingress data and store it in Kafka for instance. Check out https://www.drogue.io and https://sandbox.drogue.cloud for an open source project that does that
This was an inaccuracy on my part, sorry for that. It should probably have been "... used in multiple places _at the same time_".
Having distinct types for P0 and P1 is deliberate and is what is called "type state programming" in the embedded rust book [0]. The advantage is that you can prevent misconfiguration at compile time (ensuring that a…
I’ll throw in another alternative to look at for those using Kubernetes: https://enmasse.io
I'll add that the AMQP 1.0 spec (supported in Rabbit using a plugin) is a peer-to-peer protocol that supports both the traditional broker use case, 'direct' p2p messaging and opens some interesting uses of message…
For Java, have a look at vertx-proton which builds on top of proton-j and is a bit more intuitive (still not great) than proton-j for creating servers and clients. :) Example “blocking” client…
Couple of protocols that would be nice to benchmark for comparison: * AMQP 1.0 - can also be used for RPC without a broker in between client and server. See https://qpid.apache.org/proton/ * Aeron - low latency, UDP…
If you don’t use any other pattern than request-response, I agree there is no point. If you have a mix of pub-sub, work queues and request-response, it could simplify your dependencies perhaps. Also AMQP 1.0 has some…
I recommend looking at a standard messaging protocol like AMQP 1.0, which will allow you to implement the request-response pattern in an efficient manner without message brokers. Either “direct” client server as with…
Check out Vespa: https://vespa.ai
You can also use AMQP 1.0, an ISO and OASIS standard protocol, over websockets. It supports RPC and pub/sub semantics and has client libraries in many languages. It’s implemented by many messaging components as well as…