neceve has quit [Ping timeout: 256 seconds]
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #rust-embedded
Amadiro has quit [Remote host closed the connection]
Amadiro has joined #rust-embedded
ni has quit [Quit: WeeChat 3.0]
ni has joined #rust-embedded
<re_irc> <> anyone know of some nostd crate to encode/parse NFC NDEF data?
PyroPeter has left #rust-embedded [WeeChat 3.1]
neceve has joined #rust-embedded
jackneillll has joined #rust-embedded
jackneilll has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 256 seconds]
<re_irc> <> adamgreig: TYIER looks good to me. Just added a quick explainer to each of the platform support groups.
<re_irc> <> Cool, thanks! I guess we'd better mention rtic 1.0 too! Wanna make a pr from the hackmd?
<re_irc> <> I'm afk today but will be back tomorrow
<re_irc> <> PR attempted
<re_irc> <> Bumped RTIC to 1.0 :)
Amadiro has quit [Remote host closed the connection]
<re_irc> <> Ah, too slow! I was going to suggest changing the title to tyier 2021 since it's not a newsletter release exactly
<re_irc> <> Maybe still worth doing?
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
starblue has joined #rust-embedded
hwj has joined #rust-embedded
cr1901_ is now known as cr1901
<re_irc> <> question - just wondering, is there a way to turn a `slice of arrays` into a `slice of bytes` i.e. something like this - `&mut [[u8; 10]]` to `&mut [u8]`. I suppose this cant be done without allocation but what;s a good way to do this in a `no_std` environment.
<re_irc> <> I believe this would be legal to transmute
hwj has quit [Quit: Leaving]
<re_irc> <> hmm, do we have a document for safe or legal transmutation (or is it in rustnomicon)
<re_irc> <> nihal.pasham: if you use something like heapless::Vec in between you could do something like .iter().flatten().collect::<u8, CAP>().as_slice()
<re_irc> <> yeah, was thinking of `heapless` but I cant seem to predict `capacity allocations`. I writing an EMMC driver where reads/writes can take up arbitrarily sized allocations.
<re_irc> <> Ahh i see
<re_irc> <> I guess you could use `from_raw_parts`
<re_irc> <> Something like
<re_irc> <> `let slice: &[u8] = unsafe { core::slice::from_raw_parts(&x as *const _ as *const _, x.iter().flatten().count()) };`
<re_irc> <> Ah, I'll try that but I guess there's no way around this without reaching out for `unsafe`. (just thought I'd double check to see if I was missing something)
<re_irc> <> `hold_my_beer { … }`
<re_irc> <> Unless you can work with the iterator all the way instead?
<re_irc> <> 😄, guess not
<re_irc> <> Are there any good patterns I can follow to use a serial connection globally? For example I want to use a serial connection in my panic handler, and also register it for use with the log or tracing crates
<re_irc> <> have you looked at `bytemuck`?
<re_irc> <> not sure if it works in this case but it's my go-to safe transmute crate
<re_irc> <> hi, does anybody know repository with with some bare-metal Rust code? I mean where it's showed how to share access to peripherals betweend files/modules.
<re_irc> <> maybe ?
<re_irc> <> no RTIC and no hal
<re_irc> <> please
<re_irc> <> you can take the code and build your own no-hal version
<re_irc> <> I wish I would know as much Rust
<re_irc> <> but ye, I'll try
<re_irc> <> it doesn't use RTIC and the only point where `embedded_hal` is referenced is
<re_irc> <> in other words, if you have a bus that's not `e_h::i2c` or `e_h::spi` you need to write your own proxy anyway and still can use `shared-bus`
<re_irc> <> the basic idea is sketched out at
<re_irc> <> okey, thanks, at first I'll try to reach from another file handle to uart registers from main
<re_irc> <> so you want to share a UART between different parts of your code?
<re_irc> <> yeah, I want to have access to uart register in another file
<re_irc> <> well you can always reach directly into the register block (it's just unsafe). What is your high level usage pattern?
<re_irc> <> if you're on STM32 you might want to check out
<re_irc> <> > well you can always reach directly into the register block (it's just unsafe). What is your high level usage pattern?
<re_irc> <> I don't want to use unsafe blocks
<re_irc> <> as far as I did i wrapped access to peripherals with Mutex and Refcell and critical sections
<re_irc> <> writing to mcu memory is always unsafe, the question is merely who's hiding that 🙃
<re_irc> <> but now I want to get access to peripherals in another file
<re_irc> <> on an even higher level, what do you want to achieve? Do you have multiple parts of your program that are sending/receiving data?
<re_irc> <> For now I have one file named where I use one button one LED and interrupt
<re_irc> <> so.. nothing special, but now I want to make circular buffer in another file
<re_irc> <> where can I put and receive bytes from PC and to PC
<re_irc> <> oh, I didn't see earlier that there are RAW pointers here :D
<re_irc> <> from your problem description I don't see where you need *shared* access to the UART
<re_irc> <> so hm, is this just about factoring out parts of your code to another file? For that you don't need any mutexes etc
<re_irc> <> ```let p = stm32g071::Peripherals::take().unwrap();``` then shall I invoke it in another file on another funciont?
<re_irc> <> and take 'new' handle to uart register?
<re_irc> <> - what your object structure looks like (who's owning what values)
<re_irc> <> those two problems are completely separate:
<re_irc> <> - where your code lives (in which file(s)/module(s))
<re_irc> <> but yeah, having a `struct` that owns the UART is definitely an option
<re_irc> <> the HALs typically have a `release` method that gives you the peripheral/pins back when you need them, e.g.
<re_irc> <> I don't use HAL libs
<re_irc> <> do you mean in another file?
<re_irc> <> can I create another handle in another file/
<re_irc> <> I think the "another file" thing is a bit of a red herring - that's what I tried to communicate with "2 separate problems"
<re_irc> <> Rust does not care where your structs, enums, functions etc. are defined (except when it comes to visibility, aka `pub`)
<re_irc> <> another option could be message passing yeah?
<re_irc> <> I found that in RAL repository, I didn't know that I can `release` it after `take`
<re_irc> <> And as I pasted before I'm `taking` whole peripherlas structure. Maybe it's wrong, I saw that in Embedded Guide on rust lang web
<re_irc> <> `take` is probably on `Option` - slightly different issue
<re_irc> <> I haven't seen a `take`/`release` pair, it's more a `new`(or other constructor)/`release` thing. If you `take` from an `Option` you now own the value and can either store it somewhere (for a later `release`) or return it to your caller
<re_irc> <> it might help to show us a concrete example of the problem you're trying to solve, along with what you've tried maybe
<re_irc> <>
<re_irc> <> let p = stm32g071::Peripherals::take().unwrap();
<re_irc> <> ```Rust
<re_irc> <> fn main() -> ! {
<re_irc> <> what is `InitUart`s purpose?
<re_irc> <> to set Uart Registers related to Uart
<re_irc> <> I mean to set for example baud-rate
<re_irc> <> so, initialization? I'd make that a function that takes a `&mut` to the register block
<re_irc> <> do you mean that, You would pass this register from main, right?
<re_irc> <> well, I'd not pass ownership
<re_irc> <> also I just now see you did write `fn InitUart` indeed, but used `struct` syntax
<re_irc> <> (style side note - functions in Rust use `snake_case` not `CamelCase`)
<re_irc> <> yeah, I change it, clippy warned me thankls
<re_irc> <> can you describe on a high level what you want to achieve in the end? What behavior (from a user perspective) is your project aiming for?
<re_irc> <> high level? what do you mean, I want to get access to uart registers from another file
<re_irc> <> to have it separated
<re_irc> <> instead of all code in
<re_irc> <> user, not developer, perspective
<re_irc> <> you have some kind of project, what do you want this thing to do in the end?
<re_irc> <> anyway, Rust does not care where your function lives - you merely need to import it
<re_irc> <> really that is needed? :P
<re_irc> <> check out this chapter
<re_irc> <> I'm still trying to understand your high level problem (I think our current conversation is an )
<re_irc> <> I want to teach myself how to write Rust code in Embedded domain, so I want to do some stuff with it. I'm trying to move forward with dividing code into modules. At the end I want to create device that logging via UART to PC orientantion and position of lis3dh sensor.
<re_irc> <> I know how to divide into files, but from now I stay with that I'll try to pass reference to register as you mentioned before
<re_irc> <> ok! that's a good start :) so in that case I'd probably structure things so that whoever gets sensor data also has access to the UART. I don't think there's a need for Mutexes etc
<re_irc> <> do you have some time?
<re_irc> <> this is my repository, I pasted that code 1 month ago.
<re_irc> <> not right now but I can come back tomorrow
<re_irc> <> however, the rest of the room might!
<re_irc> <> How shall i access those registers?
<re_irc> <> you mean like in line 50?
<re_irc> <> as long as you're inside a critical section you don't need a `Mutex`
<re_irc> <> do you this static variables in 16..19 line?
<re_irc> <> yeah that's why I said `Mutex`
<re_irc> <> anyway, it kinda depends - if you don't want to use RTIC, you need to write your own resource management, I personally go for `static mut` most of the time then
<re_irc> <> if you don't want to use RTIC <- yeah don't want to
<re_irc> <> at first I want to learn how it works do not learn 'framework'
<re_irc> <> I personally go for static mut most of the time then <- do you mean all registers that I use changed to static mut?
<re_irc> <> as I did with local variables in ISR of Tim3, right>?
<re_irc> <> I'm curious that Rust compiler let me do this.
<re_irc> <> this is how I've done this
<re_irc> <> you don't need register access except once during setup so I don't see the need to share the register
<re_irc> <> I'd share a higher level struct, e.g. a UART
<re_irc> <> ... maybe I have written too much C code... and that's why I don't see something... 😞
<re_irc> <> so I'll try to make it just yours
<re_irc> <> make static mut with None value and then change them when needed
<re_irc> <> looks more like C now :D
<re_irc> <> This is a decent write up from nothing to pac to hal.
<re_irc> <> and it even talks about UARTs in particular, so probably quite useful!
<re_irc> <> thanks then I've to go sleep
<re_irc> <> got so much to read for tommorow :D
<re_irc> <> yw :)
<re_irc> <> fyi
<re_irc> <>
<re_irc> <> ```Rust
<re_irc> <> then I did something like this
<re_irc> <> static mut G_TIM2: Option<stm32g071::TIM2> = None;
<re_irc> <> I'll try tommorow make my code simple, even with those unsafe directives.
<re_irc> <> STM32 timers are ... fun. Good luck!
<re_irc> <> I want to compare some code for converting from raw sensor data using floating point arithmetic agains fixed point. This code comes from a library i'm fiddling around with. But i had no luck with running `cargo disassemble` or feeding the rlib file to `arm-none-eabi-objdump`. How could i look at the code for a certain function of a library?
<re_irc> <> For the final binary `arm-none-eabi-objdump` spits out the expected disassembly. But i can't find the function in question there so i'm assuming for now that it got inlined.
<re_irc> <> Cargo asm ?
<re_irc> <> This is the command, i was looking for. Thank you very much! :)