starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 244 seconds]
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic_ has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> How can I use external flash on stm32f730? I know the external flash address is `0x09000000`, but how do I tell rust to put my code on there as well?
<re_irc> <@w​illeml:m​atrix.org> I am exceeding the 64K of internal memory and external has 8M
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> external flash is hooked up via QSPI
fabic_ has quit [Ping timeout: 240 seconds]
<re_irc> <@s​ajattack:m​atrix.org> you probably have to mess with your memory.x file
fabic_ has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> I have been trying that, but then I need to know how to flash the two seperately
<re_irc> <@w​illeml:m​atrix.org> or better, how to flash external with probe-rs
<re_irc> <@w​illeml:m​atrix.org> Just asked that in the probe rs matrix
fabic_ has quit [Ping timeout: 272 seconds]
<re_irc> <@l​itchipi:m​atrix.org> Hello !
<re_irc> <@l​itchipi:m​atrix.org> I just built a tiny blinky project for the Lora32 board from Heltec, (in rust of course) by reusing rust-xtensa and xtensa-rust-quickstart.
<re_irc> <@l​itchipi:m​atrix.org> I never needed a memory.x so I'm kinda confused, but at least it's working like a charm !
<re_irc> <@l​itchipi:m​atrix.org> The link if you want to throw an eye: https://github.com/litchipi/esp32rs
<re_irc> <@l​itchipi:m​atrix.org> I don't really like the svd generated gpio structs, is there some macro to ease their usage ?
<re_irc> <@l​itchipi:m​atrix.org> Something like `get_gpio_nb!(4) => Gpio4` ?
<re_irc> <@l​itchipi:m​atrix.org> The fact of having separate struct for each gpio / pin /peripherals is really annoying when trying to make more Rusty things
<re_irc> <@r​yan-summers:m​atrix.org> I'm personally not quite following what you mean about easing the usage of the svd-generated gpio structs. What should `get_gpio_nb!(4)` do? Get you the GPIO4 register block? If so, you could wrap all your register blocks in an `enum Gpio { GPIO4(esp32::GPIO4) }` and then manage like that
<re_irc> <@r​yan-summers:m​atrix.org> And then match off the `enum Gpio`
<re_irc> <@l​itchipi:m​atrix.org> For now, to use a gpio, it requires to do `pins.gpio4.into_push_pull_output()`, and the return type is `Gpio4<Output<PushPull>>`
<re_irc> <@l​itchipi:m​atrix.org> It would be more convenient to have a `enum` using a system like `enum_dispatch` and a function `get_gpio(nb: u8)` to have something like: `let mut led = esp32_hal::gpio::Gpio::get_gpio(4)`
<re_irc> <@l​itchipi:m​atrix.org> The return type would be an enum (with no necessity to match the gpio between the 30 existing), and it would allow to put a `const LED_PIN: u8 = 4` in the beginning of the file
<re_irc> <@l​itchipi:m​atrix.org> I don't know if I'm clear sorry ^^' I'm not yet very "deep" in the embedded rust yet
<re_irc> <@r​yan-summers:m​atrix.org> Ah, so you don't like the way the HAL defines GPIO pins
<re_irc> <@r​yan-summers:m​atrix.org> You can always just do it yourself without the HAL and make your own abstractions
<re_irc> <@l​itchipi:m​atrix.org> Okay, I just wanted to make sure I didn't have to reinvent the wheel doing so.
<re_irc> <@l​itchipi:m​atrix.org> It would be interesting to make a crate that allows that kind of thing in a generic way, whatever the hal is
<re_irc> <@r​yan-summers:m​atrix.org> What do you not like about the accessor methods as is?
<re_irc> <@r​yan-summers:m​atrix.org> I personally find them really nice and explicit in what you're doing. Is there some function you're trying to do?
<re_irc> <@l​itchipi:m​atrix.org> I want to store the led pin in a struct, but I also want to declare the led pin as a constant I can change
<re_irc> <@l​itchipi:m​atrix.org> So the fact that there's a struct for each number of GPIO is annoying
<re_irc> <@r​yan-summers:m​atrix.org> Ah, yeah I see your pain. The justification for the current design is that in embedded projects, hardware is generally immutable, so having constant, type-based IO assignments is actually somewhat of a bonus
<re_irc> <@r​yan-summers:m​atrix.org> Because it's a means of double checking the translation from schematic to code
<re_irc> <@l​itchipi:m​atrix.org> Oh I see then
<re_irc> <@r​yan-summers:m​atrix.org> But for hacking projects, I can see why that would be somewhat annoying
<re_irc> <@r​yan-summers:m​atrix.org> I think it's something you generally get used to over time personally
<re_irc> <@l​itchipi:m​atrix.org> I was having a more Arduino-style type of programming (considering my scope)
<re_irc> <@r​yan-summers:m​atrix.org> But like I said, if it really bugs you, you can roll your own implementation as well :)
<re_irc> <@r​yan-summers:m​atrix.org> I'd encourage you to try out the existing designs though and see what works/what doesn't
<re_irc> <@r​yan-summers:m​atrix.org> Always helps to get feedback into the ecosystem
<re_irc> <@l​itchipi:m​atrix.org> Well I'll try to do something ^-^
<re_irc> <@l​itchipi:m​atrix.org> Was really nice talking to you about it !
<re_irc> <@l​itchipi:m​atrix.org> Sure, I need to explore the ESP32-related projects in Rust
<re_irc> <@r​yan-summers:m​atrix.org> I know there's definitely more knowledgeable people re: ESP32 in this chat around if you ever run into problems - I typically do STM32 work, but I'm sure there's someone here that can help if you get stuck
fabic_ has joined #rust-embedded
<re_irc> <@l​itchipi:m​atrix.org> Thank you :D I'll do some STM32 too, I heard they were better supported than ESP boards
fabic_ has quit [Ping timeout: 240 seconds]
neceve has joined #rust-embedded
<re_irc> <@b​radleyharden:m​atrix.org> Litchi Pi, I think I understand what your asking. In C world, you would declare a constant integer of 4 to define which pin is the LED. But that's not how it works in Rust. However, the same idea does still exist. In Rust, we often use type-level programming to enforce things at compile-time. That usually...
<re_irc> ... helps prevent bugs. But doing so means that you don't select a GPIO pin with a constant, you select it with a type. But you can still define a type alias, similarly to a constant, to represent your LED.
<re_irc> <@b​radleyharden:m​atrix.org> Exactly how you do that depends on your specific HAL
<re_irc> <@b​radleyharden:m​atrix.org> Feel free to hack on your own API, but as ryan-summers said, I would encourage you to give the current API a shot first. There are good reasons it was designed that way.
<re_irc> <@b​radleyharden:m​atrix.org> You may need something like
<re_irc> <@b​radleyharden:m​atrix.org> ```rust
<re_irc> <@b​radleyharden:m​atrix.org> type Led = Pa8<Output<PushPull>>;
<re_irc> <@b​radleyharden:m​atrix.org> struct Storage {
<re_irc> <@b​radleyharden:m​atrix.org> Does syntax highlighting not work anymore?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Of note, that syntax you describe comes from a HAL, not the SVD-generated PAC
<re_irc> <@f​irefrommoonlight:m​atrix.org> In a STM32HAL I use, I've used a syntax more along the lines of what you propose, with the caveat that everything is split by GPIO port (to match hardware; STM32 uses several GPIO ports, ie GpioA, GpioB etc, each with its own reg block), an enum instead of integer to specify pin, and a mode that also...
fabic_ has joined #rust-embedded
<re_irc> ... goes into the constructor (Not sure if mode is relevant to ESP?)
<re_irc> <@f​irefrommoonlight:m​atrix.org> bradleyharden: Syntax highlighting is showing for me on your example
<re_irc> <@l​itchipi:m​atrix.org> Subtle syntax highlight, but it works
<re_irc> <@l​itchipi:m​atrix.org> @bradleyharden:matrix.org: Ok I understand the paradygm difference here
<re_irc> <@l​itchipi:m​atrix.org> To enforce things at compile-time, I guess the use of macros in conjugaison with enums could simplify the things without needing any runtime process
<re_irc> <@l​itchipi:m​atrix.org> I'm going to investigate this way, I think there's a way to get both, Rust is powerful enough for that
<re_irc> <@l​itchipi:m​atrix.org> But as @rya
<re_irc> <@t​urbinenreiter:m​atrix.org> I have a problem with embedded hal on a nrf91 - is this the right place to ask?
<re_irc> <@t​urbinenreiter:m​atrix.org> Hi awesome people!
<re_irc> <@t​urbinenreiter:m​atrix.org> If so:
<re_irc> <@t​urbinenreiter:m​atrix.org> The controller hangs after the call to `I2S::new_controller()` and I am a bit lost trying to find the cause.
<re_irc> <@h​egza:m​atrix.org> Continuing on our quest to generate SVD from an implementation, then using svd2rust to convert the SVD to a Rust API. We just started using clusters, and most of the peripherals vanished from the API. Only GPIO and interrupt status registers remain. The original peripherals still exist in the SVD, so surely we...
<re_irc> ... misgenerated the clusters somehow. Any idea what that could be?
<re_irc> <@h​egza:m​atrix.org> Found a really suspicious looking empty registers-abstraction level just now :) `<registers><clusters> ..actual registers here... </clusters></registers>`
<re_irc> <@h​egza:m​atrix.org> Well nevermind. I didn't think I could figure it out this fast by reading the XML. We overwrite our registers by declaring multiple <registers>.
fabic_ has quit [Ping timeout: 268 seconds]
fabic_ has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> @turbinenreiter:matrix.org: Yes, this is the a good place to ask but there's also a #nrf-rs:matrix.org which might yield better results or even have an answer in the history already.
fabic_ has quit [Ping timeout: 252 seconds]
fabic_ has joined #rust-embedded
Rondom has joined #rust-embedded
rjframe has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> On reflection, I like your integer-as-pinnum constructor syntax
<re_irc> <@f​irefrommoonlight:m​atrix.org> With an assertion the number is in range
<re_irc> <@r​ubberduck203:m​atrix.org> :wave:
<re_irc> <@f​irefrommoonlight:m​atrix.org> `let pin = gpioa.new_pin(10, PinMode::Output)`. For esp, without the 'a'
<re_irc> <@t​urbinenreiter:m​atrix.org> @therealprof:matrix.org: Thanks, that was what I was looking for :D
<re_irc> <@9​names:m​atrix.org> There are channels for other chip families as well - stm32-rs, esp-rs, etc. Please ask if you can't find what you're looking for, not all of them have obvious names
<re_irc> <@p​atrik_nordquist:m​atrix.org> Hey guys, I'm new here :) I see that we normally use `#![no_std]` at the top of our programs since we cannot use the full std crate. But I want a piece of it anyway! Can I import just a piece of it somehow? Specifically I want all the math stuff you can do on f32 and f64 intrinsics, so I can do...
<re_irc> ... trigonometry.
<re_irc> <@j​duchniewicz:m​atrix.org> Maybe there is a nostd crate for that?
<re_irc> <@9​names:m​atrix.org> You can pull in parts of of the standard library from core, but you might prefer to pull in a library like micromath instead
<re_irc> <@r​ubberduck203:m​atrix.org> Does anyone know what the if this is the right file for the next blog post? I just released a new version of switch-hal and would like to include it. https://github.com/rust-embedded/blog/blob/master/content/2021-05-07-newsletter-29.md
<re_irc> <@e​ldruin:m​atrix.org> @rubberduck203:matrix.org: that is correct
<re_irc> <@r​ubberduck203:m​atrix.org> :+1: thanks
<re_irc> <@e​ldruin:m​atrix.org> @patrik_nordquist:matrix.org: you can use either libm or micromath
<re_irc> <@s​ympatron:m​atrix.org> I can see your point. It takes some getting used to switching from C, because you use integers as identifiers a lot in embedded C. The main benefit of Rust is that hardware restrictions are encoded in the type system to catch configuration/programming errors at compile time. That is why every pin has it's own...
<re_irc> ... type. In practice it's not too bad, because you can define type aliases (which would be the equivalent to `#define LED 4`) and you can write functions that work with any pin using generics and embedded-hal traits. Something like `fn toggle_pin<P: ToggleableOutputPin>(&mut pin: P) { pin.toggle().unwrap() }`
<re_irc> <@l​itchipi:m​atrix.org> sympatron: Yes, switching to Rust changed a lot of paradygms already, I didn't expect embedded Rust to be that "special" too. It makes sense and I now see why Rust could be a real evolution in the world of embedded softwares (as I think it is a bit messy atm in this field nowadays)
<re_irc> <@l​itchipi:m​atrix.org> I do not use enough generic types and I guess this is a typical use case where they could unleash their full power
<re_irc> <@l​itchipi:m​atrix.org> Thanks for that
<re_irc> <@l​itchipi:m​atrix.org> BTW if anybody tried to do some ESP32 dev with Rust, I want to use the `ssd1306` driver for an Oled display but I cannot find any I2C interface made in the hal, am I missing something ? Can I get an interface from elsewhere and just plug it in ?
<re_irc> <@l​itchipi:m​atrix.org> (As long as it has a Write trait on)
<re_irc> <@p​atrik_nordquist:m​atrix.org> @eldruin:matrix.org: Thanks - libm looks like the thing for me. Now I just need a random number generator too....
<re_irc> <@s​ympatron:m​atrix.org> Litchi Pi: there is a esp32-rs matrix channel: https://matrix.to/#/#esp-rs:matrix.org
<re_irc> <@9​names:m​atrix.org> @litchipi:matrix.org: Have you looked at https://github.com/esp-rs/esp32-hal/blob/master/examples/i2c.rs
<re_irc> <@l​itchipi:m​atrix.org> @sympatron:matrix.org: neat, thanks :3
<re_irc> <@l​itchipi:m​atrix.org> @9names:matrix.org: My bad, should have looked the examples. He rewrites an I2CWrapper here tho
<re_irc> <@e​ldruin:m​atrix.org> @patrik_nordquist:matrix.org: you can have a look at the RNG in [wyhash](https://crates.io/crates/wyhash) (disclaier: I' the author)
<re_irc> <@e​ldruin:m​atrix.org> Litchi Pi: `linux-embedded-hal` works with numbers like `let pin = Pin::new(25)`
<re_irc> <@e​ldruin:m​atrix.org> It's just a HAL implementation optimization, so that you do not attempt to use a pin configured to be used in SPI as a GPIO, which will not work. This way something like that will not compile at all
<re_irc> <@e​ldruin:m​atrix.org> ah, I see sympatron already answered that. nvm
<re_irc> <@l​itchipi:m​atrix.org> eldruin: Interesting ! Everything is done at compile time just like `embedded_hal` ? Or is it meant more for hacking ?
<re_irc> <@e​ldruin:m​atrix.org> what do you mean with "like e-h"?
<re_irc> <@b​radleyharden:m​atrix.org> @firefrommoonlight:matrix.org: firefrommoonlight, if the constant `10` is known at compile-time, what is the advantage of this vs. a type-based approach? In fact, this would have to return an `Option`, to prevent you from creating more than one instance of the pin simultaneously. But doing so means it could...
<re_irc> ... panic. All that goes away if you use a type-based approach and restrict how you can create the types. The compiler does all the checking for you, up-front.
<re_irc> <@b​radleyharden:m​atrix.org> The only case where that doesn't work is when you need to decide which pin to use dynamically, but I think that's a pretty rare use case.
<re_irc> <@l​itchipi:m​atrix.org> eldruin: I mean that the pin 2 is type Gpio2, so there is one type for each pin. I learnt earlier today that it was an avantage when developping embedded softwares
<re_irc> <@l​itchipi:m​atrix.org> Does it wraps this process into a more ergonomic function or is it more like a runtime assignment and check of the pins ?7
neceve has quit [Ping timeout: 272 seconds]
<re_irc> <@e​ldruin:m​atrix.org> AFAIK `linux-embedded-hal` does not do any runtime or compile time checks on the numbers. it just forwards them to the linux kernel via gpio-cdev or sysfs-gpio
<re_irc> <@e​ldruin:m​atrix.org> if there is any problem, it is the kernel the one who will tell tell
fabic_ has quit [Ping timeout: 268 seconds]
<re_irc> <@e​ldruin:m​atrix.org> `linux-embedded-hal` is an `embedded-hal` implementation for the linux kernel, but that can run in many processors, so you cannot do things like on an stm32f103 pin PB4 cannot be used for X/Y
<re_irc> <@l​itchipi:m​atrix.org> Yeah it's more for MPU Embedded Linux development rather than MCU. I wonder if using a Linux built using buildroot or yocto you could use std as any Rust program in a standard x86 laptop
<re_irc> <@e​ldruin:m​atrix.org> it can, yes
<re_irc> <@e​ldruin:m​atrix.org> a raspberry pi is an example
<re_irc> <@l​itchipi:m​atrix.org> So `linux-embedded-hal` allows a Rust program to access to low-level things (driver dev for ex ?) on a running Linux system, using the kernel as a basis for abstraction ?
<re_irc> <@e​ldruin:m​atrix.org> yep
<re_irc> <@e​ldruin:m​atrix.org> with l-e-h you can access the i2c/spi/serial peripherals, pins, and whatever
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 264 seconds]
<re_irc> <@l​itchipi:m​atrix.org> Any simple way to convert a `usize` into `&str` without all the `alloc` burden in no_std ?
<re_irc> <@l​itchipi:m​atrix.org> I dug through it and got a nasty rustc compiler error ^^'
<re_irc> <@d​irbaio:m​atrix.org> usize as in a C string? like `char*`?
<re_irc> <@d​irbaio:m​atrix.org> ah no
<re_irc> <@d​irbaio:m​atrix.org> you mean formatting a number into text
<re_irc> <@l​itchipi:m​atrix.org> Yep, as simple as that ^^'
<re_irc> <@d​irbaio:m​atrix.org> use heapless::String
<re_irc> <@d​irbaio:m​atrix.org> it implements core::fmt::Write
<re_irc> <@d​irbaio:m​atrix.org> so you can `write!(&mut myString, "{}", 42);`
<re_irc> <@d​irbaio:m​atrix.org> core::fmt is a bit bloated, you may want to use ufmt instead
<re_irc> <@l​itchipi:m​atrix.org> Exactly what I was searching for, many thanks :D
<re_irc> <@l​itchipi:m​atrix.org> Yeah I already saw some ufmt, gonna use this. TY !
fabic_ has joined #rust-embedded
<re_irc> <@s​ightline:m​atrix.org> Anybody in Texas?, I'm thinking about creating an "emergency" LoRa network.
<re_irc> <@l​itchipi:m​atrix.org> dirbaio: FYI, I didn't succeed to use `uwrite` with `heapless::String`, apparently it requires special traits from `ufmt` crate that `heapless` doesn't have. Basic `core::fmt::Write` works tho.
<re_irc> <@d​irbaio:m​atrix.org> Litchi Pi: https://docs.rs/heapless/0.7.1/heapless/#optional-features
<re_irc> <@l​itchipi:m​atrix.org> I succeeded to do what I wanted to, but I ran into a lot of new-version-breaking-old-one type of problems, a lot of examples do not use up-to-date dependencies.
<re_irc> <@l​itchipi:m​atrix.org> In case you got some weird troubles, try to investigate that way !
<re_irc> <@l​itchipi:m​atrix.org> dirbaio: Ok I feel stupid now. Thanks for pointing that out
fabic_ has quit [Ping timeout: 268 seconds]
_whitelogger has joined #rust-embedded
<re_irc> <@r​obyoung:m​atrix.org> Pimoroni just sent me a free micro:bit V1.3 to help with testing the rust board support crate 😁
rjframe has quit [Quit: Leaving]
<re_irc> <@e​ldruin:m​atrix.org> robyoung: nice! BTW. I wrote a driver for the accelerometer included in V1.3 as well: https://crates.io/crates/mma8x5x
fabic_ has joined #rust-embedded
<re_irc> <@r​obyoung:m​atrix.org> @eldruin:matrix.org: That's actually what prompted me to start asking around for one. No one seems to sell the V1.3 anymore.
<re_irc> <@e​ldruin:m​atrix.org> ah, I see
<re_irc> <@f​irefrommoonlight:m​atrix.org> @bradleyharden:matrix.org: It depends what you're comparing to. Compared to the current PinNun enum: cleaner constructor syntax. Compared to TSP: reduced complexity . The reg block is owned in stm32 at the port level, not pin
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm on the phone now where quotes don't work too good, but re "The main advantage of Rust is types that keep you from making mistakes" - Strongly disagree
<re_irc> <@f​irefrommoonlight:m​atrix.org> Rust is as very nice language and tool set
<re_irc> <@f​irefrommoonlight:m​atrix.org> And the types as we see them are a roadblock
<re_irc> <@f​irefrommoonlight:m​atrix.org> Note that owning the port reg block is consistent with other peripherals, all over rust embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> Does anyone know of an existing QSPI flash implementation in rust?
fabic_ has quit [Remote host closed the connection]
<re_irc> <@d​irbaio:m​atrix.org> embassy has one for nrf52 but I don't think it'll share much core..
<re_irc> <@d​irbaio:m​atrix.org> nrf52 qspi peripheral is very magic, it automagically handles all the qspi instruction set
<re_irc> <@w​illeml:m​atrix.org> hmm, ~~I guess I could still look at that to get some idea on how to do this~~, because I am somewhat lost, oh, it handles all that?
<re_irc> <@w​illeml:m​atrix.org> Yeah, I need to do it all myself
<re_irc> <@d​irbaio:m​atrix.org> yea you tell it "read" or "write
<re_irc> <@w​illeml:m​atrix.org> lol
<re_irc> <@w​illeml:m​atrix.org> It looks like the one I am using has a mode where I can use it like internal flash addresses, but first I need to configure it and send it an instruction
<re_irc> <@d​irbaio:m​atrix.org> stm32 will be more complicated
<re_irc> <@d​irbaio:m​atrix.org> as everything stm32 is :D
<re_irc> <@w​illeml:m​atrix.org> I do have a reference C++ code base, but its still complicated
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://github.com/stm32-rs/stm32h7xx-hal/blob/master/src/qspi.rs. Stm32H7xx Hal QSPI
<re_irc> <@w​illeml:m​atrix.org> /! ```
<re_irc> <@w​illeml:m​atrix.org> //! // Get the device peripherals and instantiate IO pins.
<re_irc> <@w​illeml:m​atrix.org> //!
<re_irc> <@w​illeml:m​atrix.org> //! use stm32h7xx_hal::qspi;
<re_irc> <@w​illeml:m​atrix.org> oh
<re_irc> <@w​illeml:m​atrix.org> argh, formatting did not work out as I hopped
<re_irc> <@d​irbaio:m​atrix.org> F7 is QSPIv1, H7 is QSPIv2
<re_irc> <@d​irbaio:m​atrix.org> you probably can't copypaste it, but if you're lucky the peripherals will be similar
<re_irc> <@r​yan-summers:m​atrix.org> I wrote that originally for indirect operation only. That QSPI driver is essentially just a 4-channel SPI
<re_irc> <@r​yan-summers:m​atrix.org> You can operate the H7 QSPI to directly memory map as well I believe
<re_irc> <@r​yan-summers:m​atrix.org> We don't use it for flash in our application, but rather as a high bandwidth SPI bus
<re_irc> <@w​illeml:m​atrix.org> yeah, different api
<re_irc> <@w​illeml:m​atrix.org> but hopefully I will figure it out
<re_irc> <@w​illeml:m​atrix.org> ah, well it says in here how to do it kind of 😅 https://github.com/stm32-rs/stm32f7xx-hal/blob/master/src/qspi.rs
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
neceve has joined #rust-embedded
neceve has quit [Ping timeout: 244 seconds]
<re_irc> <@t​herealprof:m​atrix.org> @robyoung:matrix.org: I have one, too. 😉