Foxyloxy has quit [Ping timeout: 256 seconds]
Foxyloxy has joined #rust-embedded
<re_irc> <James Munns> https://docs.rs/voladdress/latest/voladdress/ is also a thing
starblue1 has quit [Ping timeout: 250 seconds]
starblue1 has joined #rust-embedded
slugbyte has quit [Read error: Connection reset by peer]
slugbyte has joined #rust-embedded
slugbyte has quit [Read error: Connection reset by peer]
slugbyte has joined #rust-embedded
slugbyte has quit [Ping timeout: 250 seconds]
slugbyte has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
tokomak has joined #rust-embedded
onio has quit [Remote host closed the connection]
slugbyte has quit [Ping timeout: 256 seconds]
slugbyte has joined #rust-embedded
Guest284 has joined #rust-embedded
tokomak has quit [Ping timeout: 245 seconds]
slugbyte has quit [Ping timeout: 250 seconds]
slugbyte has joined #rust-embedded
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
unmanbearpig has quit [Quit: WeeChat 3.3]
starblue1 has quit [Ping timeout: 250 seconds]
Guest284 has quit [Ping timeout: 256 seconds]
<re_irc> <Robert Gałat> I have an issue with https://docs.rs/nrf52840-hal/0.14.0/nrf52840_hal/. I try to use embedded HAL, and use uart on the board. I struggle with creating UART object that will implement embedded_hal::serial::write trait. in examples, to this crate, I found a hello world example, that sends a short message to uart. but it uses UARTE, and when I try to pass this to struct that require embedded hal trait, I get an error...
<re_irc> ... "the trait "_embedded_hal_serial_Write<u8>"is not implemented for"Uarte<UARTE0>`` I dug a little, and I found a file uart.rs in the sources for this crate, and there I can see that there is a struct called Uart, and it implements embedded hal traits, that I need, but I can not access it :( Am I doing something wrong, or this crate does not expose everything that it has?
starblue1 has joined #rust-embedded
<re_irc> <Robert Gałat> when I looked into lib.rs I found out this:
<re_irc> use embedded_hal as hal;
<re_irc> #![no_std]
<re_irc> #![doc(html_root_url = "https://docs.rs/nrf52840-hal/0.14.0")]
<re_irc> <Robert Gałat> Oh, ok, there are separate structs UarteRx, and UarteTx, that implement embedded_hal trait... but this means, I can not have one object that will be able to do read and write ? do I have to manually create a wrapper if I want an object that will be able to do read + write ?
<re_irc> <danielzfranklin> What you're probably doing wrong is having incompatible versions of embedded_hal
<re_irc> <Robert Gałat> OK, so I think I understand, I can create an Uarte struct, and in this struct is a function to split it into UarteRx, and UarteTx that implement embedded_hal::serial read and write. What If I want to have a struct that implements both Read and write? Is there any issue why this can not be combined into one struct ? I wonder if I just want to do something dumb, and Rust is just trying to convince me that it will be...
<re_irc> ... a bad design ? I understand why in embedded hal this would be separated into read and write, but if in my application I want both, why I have to pass two structs, one to read, and another to write. I just do not get it. Another thig is that this crate has only one job - to provide implementations for embedded Hal, so why I have to create some temporary structs, that later I need to convert to structs compatible with embedded...
<re_irc> ... hal. I mean that in this example it would be much easier if struct Uarte just implemented read and write, and if I want, I can later split it to separate structs
<re_irc> <Robert Gałat> danielzfranklin: ok, that is one possibility, how to check if they are incompatible ?
<re_irc> this is my cargo.toml
<re_irc> cortex-m = "0.7.3"
<re_irc> [dependencies]
<re_irc> <danielzfranklin> Embedded-hal is a "common language" so that libraries can specify "I need to be able to send UART", and hals can specify "here's how you send UART on this device", and you can link them together without them needing to know about each other
<re_irc> <danielzfranklin> You don't seem to be using a driver library (like a driver that handles talking to a specific kind of gps over uart), so you don't need embedded hal
<re_irc> <danielzfranklin> Just use the read and write methods on this https://docs.rs/nrf52840-hal/latest/nrf52840_hal/uarte/struct.Uarte.html
<re_irc> <danielzfranklin> Robert Gałat: Nevermind, I misunderstood you. It's not a version issue
<re_irc> <Robert Gałat> well, but I want to use embedded_hal, because I want to deploy the application to multiple targets, nrf52, stm, etc ... that's why my application will use embedded hal. Oryginally when I created a struct to define interface for my application, I written that UART object should implement Read<u8> + Write<u8>, and I just realized that I can not do it with nrf52
<re_irc> <ryan-summers> You can use the split function and write your own wrapper struct that just contains the Rx and Tx portions
<re_irc> <ryan-summers> Then manually implement embedded-hal::Write and Read for your struct to just defer to the member impls
<re_irc> <ryan-summers> If you really want to
<re_irc> <Lachlan Sneff> I'm getting an error when setting up clocks on an stm32f105vhb6:
<re_irc> 1 ERROR panicked at 'assertion failed: sysclk <= 72_000_000 && hclk <= 72_000_000 && pclk1 <= 36_000_000 &&\n pclk2 <= 72_000_000 && adcclk <= 14_000_000', /Users/lachlansneff/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32f1xx-hal-0.8.0/src/rcc.rs:699:9
<re_irc> and here's the code:
<re_irc> <Lachlan Sneff> I'm getting an error when setting up clocks on an stm32f105vhb6:
<re_irc> 1 ERROR panicked at 'assertion failed: sysclk <= 72_000_000 && hclk <= 72_000_000 && pclk1 <= 36_000_000 &&\n pclk2 <= 72_000_000 && adcclk <= 14_000_000', /Users/lachlansneff/.cargo/registry/src/github.com-1ecc6299db9ec823/stm32f1xx-hal-0.8.0/src/rcc.rs:699:9
<re_irc> and here's the code:
<re_irc> let clocks = rcc
<re_irc> <Lachlan Sneff> As far as I can tell, they're all in the right ranges
<re_irc> <danielzfranklin> For example embedded-hal doesn't cover interrupts
<re_irc> <ryan-summers> embedded-hal is not intended to be a platform to make an entire application platform-agnostic...
<re_irc> <ryan-summers> It's a mechanism to allow device drivers to be written in a chip-agnostic fashion
<re_irc> <adamgreig> Lachlan Sneff: perhaps you can't generate 16MHz from 72MHz sysclk, it's /4.5
<re_irc> <adamgreig> try 18MHz pclk1?
<re_irc> <Lachlan Sneff> Oh, you're right
<re_irc> <Lachlan Sneff> I'll try 18 Mhz, thank you
<re_irc> <adamgreig> I haven't used f1xx-hal, just guessing
<re_irc> <Lachlan Sneff> Didn't work unfortunately :/ Same error
<re_irc> <ryan-summers> Maybe float rounding error on the 72mhz?
<re_irc> <Lachlan Sneff> I don't there's any floating point
<re_irc> <Lachlan Sneff> +think
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
<re_irc> <Lachlan Sneff> Looking at the stmcube clock configurator, it seems like to get from my 25 MHz oscillator to a sysclk higher than that is to use the pll, but I'm not sure if that's done behind the scenes in the hal
<re_irc> <ryan-summers> It very well might be bumping up to a 3x multiplier at 75MHz. Try setting sysck to 50MHz or some integer multiple of the HSE
<re_irc> <ryan-summers> tl;dr from the f1 reference manual - there's a predivider and then a multiplier before going to SYSCLK, so you very well might be hitting some frequency that's slightly above the max 72MHz allowed, depending on the algorithm used.
<re_irc> <ryan-summers> Not sure what the algorithm the HAL uses, but there's definitely some math being done on the requested SYSCK to determine predivider and PLL multipliers, and that's likely exceeding the 72MHz limit
<re_irc> <ryan-summers> Judging by the fact that 72MHz is 2.88x the 25MHz HSE, I find it pretty unlikely that the HAL is able to find a combo that gives exactly 72MHz Lachlan Sneff
<re_irc> <Lachlan Sneff> I'm okay with less. I guess I can live with 36 MHz
starblue1 has quit [Ping timeout: 245 seconds]
<re_irc> <Lachlan Sneff> * MHz. I'll try for 50 MHz though
<re_irc> <Lachlan Sneff> I'm still trying to get used to how clocks work on embedded devices haha
<re_irc> <Lachlan Sneff> That being said, STMCube seems to think that 72 MHz is possible. It might be that the HAL isn't able to figure out how though.
<re_irc> <ryan-summers> The algorithms the HALs use have been notoriously difficult from what I've heard of peoples experiences so far
<re_irc> <ryan-summers> Outside of dividing the input 25MHz to 1MHz and then multiplying by 72 on the PLL, I don't see a way to get a perfect answer. And those requirements are outside the range of the divider/multiplier
<re_irc> <ryan-summers> So anything it comes up with will be an approximation with associated tolerance, so you'll be +/- some frequency off 72MHz
<re_irc> <ryan-summers> Generally, the fix here would be to use a 16MHz HSE, since that just requires multiplier of 4 to get to 72MHz
<re_irc> <ryan-summers> If you really need the full 72MHz. If not, you can probably get the PLLs to something close, like 70MHz, without too much effort, but you need to ask less of the HAL
<re_irc> <ryan-summers> In any case, it's likely a bug in the HAL calculations. They should always do an upper bound on max CPU SYSCK
<re_irc> <Lachlan Sneff> Gotcha, thank you!
<re_irc> <Lachlan Sneff> I'll aim for something lower then. Unfortunately, I only have a 25 MHz external oscillator in this case.
<re_irc> <ryan-summers> Try 70 or some multiple of 5 to make the math a bit easier on the HAL
starblue1 has joined #rust-embedded