wifi and other interfaces, what is the plan to add support?

[ghost]

I've got a pretty basic and still IMO fundamental question, and see no answer to that question.

For any language to be useful for embedded programming one needs to have the ability to really use all the features of the respective development board one is targeting.

I mean compiling some code to work on some cpu is very much the easy part afaik.

The main question is, how do you get wifi, bluetooth, multi core, power saving and this kind of stuff working on a wide range of products. Mostly the code that drives these things is locked up/ proprietary as it seems.

So my question is, does someone have something in mind to solve this issue? Is the plan to straight up ignore it and just have a mini cpu with some rudimentary pins?

There are other languages out there that have the same issue so it might be worth finding a more general solution along the lines of how llvm is a general solution for many languages for the easy problem mentioned above.

Having wifi etc. support in llvm on the other hand seems completely off even if such a thing would probably be the most helpful...

This should not sound mean, the effort your making is great and I'm exited about it after all, otherwise I would not be posting this issue.

Thanks

[RandomInsano]

What you’re talking about here seems more like a real-time operating system, which itself would probably have its own hardware abstraction layer.

It’s an interest case, I personally work one layer lower just talking directly to various external doodads (others here can share their experience). I don’t need any of the features you mention because if I do, I’ll usually choose a board that runs Linux because that’s all been done for me.

One thing though, what you’re talking about has been done once here. There is an abstraction for graphical LCDs. I guess folks can lay the groundwork when enough people need Bluetooth, PM, etc. over multiple boards.

[ghost]

I'm actually not talking about an operating system at all, just libraries like they exist in c/cpp for given micro controllers that enable usage of wifi like this pseudo use case

while true {
  connect(myWifi)
  doSomeADC()
  send(someData) 
  sleep()
}

Between running some micro controller and a real linux mini computer there is quite a gap (price/ size/ power consumption) and as more and more micro controllers have these advanced options, does the rust community plan to straight rule them out?

An Abstraktion for an LCD is just way easier than wifi/ bluetooth/ core clocking/ core targeting support. (at least I've done the former but never yet seen the latter being done)

aside: Say I want to run task x on one core and task y on another (low power) core. That is more of a mini OS usage example but still the question remains, how do you expect to get support for such features in?

Writing a mini OS is not hard once basic primitives for accessing the micro controllers options are available.

[RandomInsano]

I don’t represent this community, but I don’t think there’s a reason to rule it out.

Just build it when there’s demand, and make sure the current system is flexible enough when that demand comes. In my professional life I build things when people need them because there should be requirements gathering and demand.

This discussion should happen so that when people need to build it, the thought’s been had.

[therealprof]

I think we have added support for all interfaces which can be easily supported via embedded-hal. In addition there's projects like https://github.com/rust-embedded-community/embedded-nal and https://github.com/smoltcp-rs/smoltcp to take care of the more abstract networking needs in embedded projects.

Since it's unlikely we'll hear from the original author again, I'm going to close this issue.