lulf

6 ms·

1.
by lulf 2y ago
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 use the MP
2.
by lulf 2y ago
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.
3.
by lulf 3y ago
Check out https://vespa.ai
4.
by lulf 3y ago
Async Rust is great for embedded! Check out https://embassy.dev as well which is very similar but with support for more hardware.
5.
by lulf 5y ago
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 peripheral can be used
6.
by lulf 5y ago
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
7.
by lulf 6y ago
This was an inaccuracy on my part, sorry for that. It should probably have been "... used in multiple places _at the same time_".
8.
by lulf 6y ago
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 given pin can
9.
by lulf 6y ago
I’ll throw in another alternative to look at for those using Kubernetes: https://enmasse.io
10.
by lulf 6y ago
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 routers lik
11.
by lulf 7y ago
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 https://github.com/EnMasseProje
12.
by lulf 7y ago
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 ba
13.
by lulf 7y ago
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 nice async capabilities
14.
by lulf 7y ago
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 HTTP , or via an interm
15.
by lulf 8y ago
Check out Vespa: https://vespa.ai
16.
by lulf 8y ago
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 Azure Service B