!ZAnLsPitgFNnrNRLOQ:matrix.org

Drone OS

66 Members
An Embedded Operating System for writing real-time applications in Rust.5 Servers

Load older messages


Timestamp Message
13 May 2020
13:57:16@valff:matrix.orgvalffThat's correct. Drone approach to memory safety is to leverage Rust type system. Using C code in unsafe, just like in a regular Rust program.
21:28:31@craigoverend:matrix.orgcraigoverend joined the room.
21:40:57@dhylands:matrix.orgdhylands I've been doing some refactoring on my weact-blinky example, and I so far I've created a Led trait and GpioLed implementation, which can be found here: https://github.com/dhylands/drone-stm32f4-utils/blob/master/src/gpioled.rs (I still need to add some documentation). Anyways, I've been trying to factor out the code for setting the clock frequency, and this is what I have so far: https://github.com/dhylands/drone-weact-blinky/blob/master/src/clock.rs Currently I pass all of the RCC and a couple other registers into the init constructor and then raise_system_frequency can use self to get access to them all. I still need to pass rcc_cir as a parameter to raise_system_frequency though. If I try to make it a member of the struct I get the error: "error[E0507]: cannot move out of self.rcc_cir.hserdyc which is behind a shared reference" I checked in the modified code into the rcc-cir branch: https://github.com/dhylands/drone-weact-blinky/commit/59f0fe32664816c5c3379b78933456f72de4286f If anybody has any ideas on how I might be able to improve this, it would be greatly appreciated.
14 May 2020
09:50:25@valff:matrix.orgvalff dhylands: Nice! A few suggestions: you don't need to store active state inside GpioLed, it's already stored in the register: self.pin.gpio_odr_odr.read_bit().
09:57:54@valff:matrix.orgvalff dhylands: About rcc-cir: there are 2 options: 1) store it as rcc_cir: Option<reg::rcc::Cir<Srt>> and move it using Option::take() 2) make it copyable: rcc_cir.into_copy() inside SystemClock::init
09:58:25@valff:matrix.orgvalffGenerally I prefer the second way.
12:09:14@dhylands:matrix.orgdhylands valff: The active field determines if the GPIO is active low or active high. (i.e. does calling led.on() drive the gpio low or high) The ODR is the current value of the output. I could save the RAM (at the possible expense of increased flash if you needed both implementations) by creating 2 different implementations, say GpioLedActiveHigh and GpioLedActiveLow and have the GpioLed::init return one or the other.
12:10:17@dhylands:matrix.orgdhylands * valff: The active field determines if the GPIO is active low or active high. (i.e. does calling led.on() drive the gpio low or high) The ODR is the current value of the output. I could save the RAM (at the possible expense of increased flash if you needed both implementations) by creating 2 different implementations, say GpioLedActiveHigh and GpioLedActiveLow and have the GpioLed::init return one or the other.
12:10:38@valff:matrix.orgvalff dhylands: Ah, I overlooked this, makes sense then.
12:11:14@dhylands:matrix.orgdhylands Thanks for the tip on rcc_cir. I'l take a look at into_copy
15 May 2020
18:30:54@valff:matrix.orgvalff@room Just added Quick Tour section to the front page of https://www.drone-os.com/ I would encourage everyone to give it a glance, because you may have missed some features.
16 May 2020
11:27:54@moerk:matrix.orgmoerk valff how much effort to get existing hal trait ecosystem to work on drone, or would it work with minimal effort
11:39:22@valff:matrix.orgvalff moerk: We didn't try it. We prefer writing our own drivers or reuse C libraries. Embedded hal uses its own register API and rely on busy waiting, which is a deal-breaker for us. However I think it can be used with Drone, just like a C library can.
11:41:10@valff:matrix.orgvalffInstead of building on top of a set of traits for HAL, we use dependency inversion principle. I plan to write a blog post on this soon.
11:41:40@valff:matrix.orgvalffHere is an example driver: https://github.com/smartoris/smartoris-apds9960
13:08:32@moerk:matrix.orgmoerkI will look forward to that blog post
11:58:07@_discord_266051021204094976:t2bot.iocatplant is there a suggested BLE stack with drone yet?
16:43:07@alfred-ch:matrix.orgalfred-ch@catplant We have no specific recommendations. What we have done so far: we wrote firmware in Drone for NordicSemi nRF52832 modules. The BLE protocol stack, however, is implemented in the NordicSemi nRF5 SDK's 'Softdevices.'
16:43:40@alfred-ch:matrix.orgalfred-ch * @catplant We have no specific recommendations. What we have done so far: we wrote firmware in Drone for NordicSemi nRF52832 modules. The BLE protocol stack, however, is implemented in the NordicSemi nRF5 SDK's 'Softdevices.'
17:15:21@_discord_266051021204094976:t2bot.iocatplant I was considering working with https://github.com/jonas-schievink/rubble/ or possibly mynewt's nimble
may just stick to the nRF5x softdevices
17 May 2020
00:17:20@dhylands:matrix.orgdhylandsI haven't used this myself, but you may also want to look at https://github.com/jamesmunns/nrf52dk-sys There are also some workshops coming up as part of Oxidize Global https://oxidizeconf.com/ that will be using nRF52840 https://ferrous-systems.com/blog/oxidize-global-workshop-and-cfp-announcement/
02:11:49@dhylands:matrix.orgdhylands valff: I have a crate here https://github.com/dhylands/drone-stm32f4-utils that I'd like to publish to crates.io (so that the documentation will be available online). I thought I'd check with you about the name. It currently starts with "drone". I'm also happy to name it something like dh-drone-stm32f4-utils so that it doesn't interfere with the drone namespace, but I thought I check with you first to see what your thoughts are.
08:41:11@valff:matrix.orgvalff dhylands: Thank you for checking with me first. Our current stance on this is that all drone-* crates should correspond to repos inside https://github.com/drone-os/. They share the same major version and maintained as a whole. For other crates we tend to use other prefixes. See for example https://github.com/smartoris/. It's my new experimental project - smart home framework based on Drone. For example there is a smartoris-i2c crate, which is limited to my use-case: only for stm32f4, works only through DMA, only master role, i2c/dma errors are panics. If we were to create drone-i2c, I think it should be implemented for all supported targets, DMA should be optional, errors should be propagated to the caller who decides whether to panic or reset only the i2c peripheral, support for 10-bit addressing mode, slave role, and so on.
19:29:14@dhylands:matrix.orgdhylandsFinally got everything figured out and I've now published: https://crates.io/crates/dh-drone-stm32f4-utils and have the rustdoc automatically generated and served as github pages on each checkin (using Travis).
18 May 2020
18:07:58@oleid:matrix.orgoleid

Hello luojia65, Drone doesn't work on RISC-V as of now, but it designed to be portable. In the near future we will work on documenting the process of porting Drone to other platforms.

I'd be interested in that as well. Especially for esp32. But I'm not remotely sure where to get started.

19 May 2020
16:59:09@alfred-ch:matrix.orgalfred-ch oleid: Isn't it still true that the Xtensa CPU of ESP32 is not supported by the Rust compiler? We use the official Rust in our Drone-OS toolchain and there is no plan to change that. But I might have missed something.
17:06:06@oleid:matrix.orgoleid

oleid: Isn't it still true that the Xtensa CPU of ESP32 is not supported by the Rust compiler? We use the official Rust in our Drone-OS toolchain and there is no plan to change that. But I might have missed something.

Esp32 is in the process of being mainline to llvm by Xtensa. If you like, you can already build your own rustc with xtensa support, today. Or use a pre-built docker container.
E.g.
https://dev.to/mtnmts/containerized-builds-for-rust-on-the-esp32-e8m

So while it is true that there is no official rustc support today, it will get there, eventually.

20 May 2020
19:03:40@alfred-ch:matrix.orgalfred-chESP32 (or ESP32-S2?) integration into Drone-OS might become one of our next activities. Which dev board do you recommend?
20:58:25@oleid:matrix.orgoleid I'm not really an expert on esp32, just did a little programming with freertos. But to me it would seem even the cheapest from Aliexpress are fine (~4 EUR / piece, shipping included).
25 May 2020
21:16:13@dieter:matrix.allmende.iodieter joined the room.

There are no newer messages yet.


Back to Room List