crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<dkhayes117> I'm doing a project with an nrf9160 dev board, Icarus from actinius, and I'm wondering if if I should create a board support crate for it.
<re_irc>
There is an nrf9160-hal already, so I wonder how long/hard would it be to make one? I've never done it before.
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Bob McWhirter> James Munns: Thanks!
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
explore has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has joined #rust-embedded
explore has joined #rust-embedded
fabic_ has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<GrantM11235> dkhayes117: I don't think that board support crates are very useful, it is easier to just put that code in your main app crate
GenTooMan has quit [Ping timeout: 264 seconds]
GenTooMan has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<Lumpio->
Personally I've never used a board support crate either. Might be nice for beginner tutorials so you don't have to remember which pins peripherals are on, but that's not too hard to do yourself.
<re_irc>
<9names (@9names:matrix.org)> I find them great for slideware and weekend projects, which is practically 100% of my use of embedded rust so I use BSPs almost exclusively.
<re_irc>
Finding pins, working out crystal frequencies, finding all the common traits you want to import is not hard for us, but it's also not fun or interesting work, and it's just a pile of meaningless distracting noise when you're trying to teach something.
fabic_ has quit [Ping timeout: 256 seconds]
<Lumpio->
Yeah, great for teaching too.
<Lumpio->
But if you're at the level you can make one yourself, and one doesn't exist, means you really don't need to write one for a single project
<Lumpio->
If you want to share the BSP with the community then that's something to think about.
<re_irc>
<9names (@9names:matrix.org)> also depends on the community you're targetting
<re_irc>
<9names (@9names:matrix.org)> like, if they're already the folks that won't use a HAL there's no point trying to sell them on a BSP
fabic_ has joined #rust-embedded
<re_irc>
<henrikssn> Is there any overhead of using load/store on a AtomicU32 on cortex M4 vs a u32?
<re_irc>
<henrikssn> I assume not, since LDR and STR instructions are atomic, but I wanted to understand if there is anything else going on
<re_irc>
<thalesfragoso> henrikssn: There are some DMB instructions if using anything other than relaxed ordering
<re_irc>
<thalesfragoso> But if you need anything order than relaxed, then the DMB might be needed anyway
<re_irc>
<thalesfragoso> * other
<re_irc>
<thalesfragoso> In M4 you might not need the DMB instruction per se, but sometimes you need the ordering for the compiler itself
<re_irc>
<thalesfragoso> You can also use relaxed plus compiler_fences, but not sure if worth the hassle
<re_irc>
<thalesfragoso> Especially if you want to someday run the code on a M7
<re_irc>
<thalesfragoso> You need DMB there
<re_irc>
<henrikssn> Thanks, I only need relaxed ordering in this case
<re_irc>
<henrikssn> I just want to not end up with reading a half-written value
<re_irc>
<henrikssn> It's essentially single writer multiple reader of a single u32
<re_irc>
<thalesfragoso> Atomics are great, go for it
<re_irc>
<henrikssn> Thanks! So AtomicU32::load with relaxed ordering is pretty likely to compile to a single LDR instruction, right?
<re_irc>
<thalesfragoso> Yep
causal has quit [Quit: WeeChat 3.5]
fabic_ has quit [Ping timeout: 264 seconds]
fabic_ has joined #rust-embedded
<re_irc>
<omar_u8> What is the best approach using embedded Rust to poll a gpio input for a level change?, sort of like the "while(pinRead(somePin) != True);" equivalent in C.
<re_irc>
<omar_u8> Meaning that I want to keep polling (stay at the same statement line) until the event happens.
seer has joined #rust-embedded
<re_irc>
<K900> Something like "while some_pin.is_high() {}"?
<re_irc>
<K900> (assuming you're using embedded-hal)
<re_irc>
<K900> Something like "while some_pin.is_low() {}"?
<re_irc>
<omar_u8> Yes!
<re_irc>
<omar_u8> right, I am using the hal
<re_irc>
<omar_u8> K900: This syntax, generally acceptable? :)
<re_irc>
<K900> Why wouldn't it be?
<re_irc>
<omar_u8> Out of consistency, I figure because probably when polling in general other types of peripherals a "bool" is not necessarily what is returned.
<re_irc>
<omar_u8> Or am I overthinking it? :D
<re_irc>
<K900> Do you mean "some_pin.is_low()" instead of "some_pin.is_low() == true"?
<re_irc>
<K900> Yes, that is definitely acceptable
<re_irc>
<K900> Rust does not allow non-bool values in conditionals
<re_irc>
<K900> So if it's something else, it will be a type error
<Lumpio->
This is why != true and == true and such are generally not needed
<re_irc>
<James Munns> "while let true = some_pin.is_low() {}"
<re_irc>
🤡
<re_irc>
<omar_u8> K900: Ok, thats also the same in C I figure.
<re_irc>
<James Munns> (this actually makes more sense in old e-h, where it's a result, then "while let Ok(true) = ..." was actually something I did)
<re_irc>
<K900> omar_u8: No, C allows integers and such in conditions
<Lumpio->
You know you can do while some_pin.is_low() == Ok(true)
<re_irc>
<K900> So it can cause subtle errors
<Lumpio->
no need for let
<re_irc>
<James Munns> omar_u8: In C, any non-zero number (or anything that can be coerced into a number) is false)
<re_irc>
<K900> *true
<re_irc>
<James Munns> * true)
<re_irc>
<James Munns> yes, correct, sorry
<re_irc>
<James Munns> (fixed)
<re_irc>
<omar_u8> James Munns: Right, yes, I see the difference.
<re_irc>
<omar_u8> James Munns: So braces are a must, cant terminate the statement with a ;
<re_irc>
<K900> Yes
<re_irc>
<omar_u8> Perfect, thanks folks!
<re_irc>
<K900> Rust does not have blocks without braces
<re_irc>
<K900> Ever
<re_irc>
<omar_u8> Got it. I should keep that in mind.
seer has quit [Quit: quit]
seer has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
<re_irc>
<dkhayes117> 9names, Lumpio- , GrantM11235 : thanks for the advice.
GenTooMan has joined #rust-embedded
fabic_ has quit [Ping timeout: 264 seconds]
bjc has joined #rust-embedded
<re_irc>
<taunusflieger> I’m trying to understand the current state of embedded rust when it comes to WI-FI and TCP/IP network stack. My current understanding is that on the bare metal side things are developing, but not there at this point. For ESP there is a esp-idf runtime solution, which is not bare metal, but has WI-FI support. Is my understanding correct? Any further points / through? - thanks!