<re_irc>
< (@jamesmunns:beeper.com)> oh yeah, there's definitely 868/915 sub-ghz phys. TI made some part I've used in the past before
dc740 has quit [Remote host closed the connection]
<re_irc>
<justinestrada> I'll help anyone interested in how to earn $30k within 3 days and hours but you will reimburse me 10% of your dividend when you collect it. Note: only interested people should involve. Contact my user
<re_irc>
< (@9names:matrix.org)> > fwiw, lora/lorawan is typical for these kinds of ranges.
<re_irc>
lora is practically line of sight only though, same as those 868/915 radios
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
< (@9names:matrix.org)> you can get great range to a weather balloon, but for surface comms you rely on gateways being high (and preferably several of them to deal with occlusion)
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I don't know of anything else better that is available commercially and operates on ISM bands so you don't need some kind of domain-specific license tho.
<re_irc>
< (@jamesmunns:beeper.com)> (open to hearing tho!)
<re_irc>
< (@jamesmunns:beeper.com)> There are some lower frequency ism bands which should be theoretically more friendly to longer range, but they are way less common in off the shelf modules. There's some older 433mhz stuff, but I haven't looked seriously at those.
<re_irc>
< (@ithinuel:matrix.org)> I know some transceivers in the RC world can do very long range but I believe they also require some sort of phased array antenna of some sorts.
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, if you have line of sight, you can do a lot of things to improve range
<re_irc>
< (@jamesmunns:beeper.com)> depends on how "not line of sight" you have in mind :p
<re_irc>
< (@grantm11235:matrix.org)> For some reason, rustc doesn't know that "NonZeroXx::get" never returns zero https://godbolt.org/z/GvfG348fr
<re_irc>
< (@jamesmunns:beeper.com)> you can divide directly
<re_irc>
< (@adamgreig:matrix.org)> it's a pain that you can't put a non zero integer literal into a function that wants a NonZero though
<re_irc>
< (@adamgreig:matrix.org)> really makes using the function more annoying everywhere else
<re_irc>
< (@jamesmunns:beeper.com)> "new_unchecked" is const at least, and unwraps in consts happen at compile time
<re_irc>
< (@jamesmunns:beeper.com)> but it's uh... verbose, for sure lol
<re_irc>
< (@adamgreig:matrix.org)> yea, but ergonomically that's even grosser lol
<re_irc>
< (@ithinuel:matrix.org)> I was hoping to be able to find something that wouldn't require a subscription.
<re_irc>
The amount of data would be a couple of tens of bytes every hour and/or on demand. I worked with cellular in the past and that's too heavy for my needs.
<re_irc>
I don't know about the battery yet (might try to run out of solar).
<re_irc>
Thanks for your input btw 🙂 I'll put that project on the side for when I have more time to dig deeper 🙂
<re_irc>
< (@jamesmunns:beeper.com)> maybe a handy "nz!()" macro?
<re_irc>
< (@jamesmunns:beeper.com)> something that expands to
<re_irc>
< (@adamgreig:matrix.org)> my vague feeling is that NonZero is really useful for storage and niche optimisations and other compiler opts when used as a struct member, but maybe it's not as useful for arguments to functions to express bounds on integer ranges
<re_irc>
< (@jamesmunns:beeper.com)> relatively sucks to no that.
<re_irc>
< (@adamgreig:matrix.org)> especially since the only expressable bound like this is "anything except zero", or you can DIY some more types for it
<re_irc>
< (@adamgreig:matrix.org)> pretty often you have some other bound/limit too and you can error check or return a result or panic or make a newtype or whatever, but only non-zero is std special?
<re_irc>
< (@adamgreig:matrix.org)> still it's hard to justify "oh yea let's just say it's UB to pass in zero for this argument, good luck"
<re_irc>
< (@jamesmunns:beeper.com)> it's used for niche opt stuff, I guess?
<re_irc>
< (@adamgreig:matrix.org)> yea, exactly, it's great for niche opts
<re_irc>
< (@adamgreig:matrix.org)> and for not-a-pointer-i-promise...unless...
<re_irc>
< (@adamgreig:matrix.org)> just maybe not a perfect fit for functions taking integer arguments that happen to need to be >0
<re_irc>
< (@jamesmunns:beeper.com)> but a "do_something(NonZeroU32)" and "try_do_something(u32)" might be reasonabe?
<re_irc>
< (@adamgreig:matrix.org)> ada's range types when :p
<re_irc>
< (@jamesmunns:beeper.com)> but yeah, "do the range checks on a newtype" is viable, for sure
<re_irc>
< (@grantm11235:matrix.org)> I don't think it is necessary to use "new_unchecked" for a literal. "new" + "unwrap" should be fine with any any opt level >= 1
<re_irc>
< (@jamesmunns:beeper.com)> ah yeah, both are const
<re_irc>
< (@jamesmunns:beeper.com)> plus you don't need to unwrap unchecked anyway, which was the whole thing I wanted to demo :P
<re_irc>
< (@jamesmunns:beeper.com)> that means, time for me to go to bed instead of trying to be helpful anymore lol
<re_irc>
< (@adamgreig:matrix.org)> but given the denom is very likely to be always a literal, sure sucks to be writing "core::num::NonZeroU16::new(12).unwrap()" instead of "12"
<re_irc>
< (@adamgreig:matrix.org)> ho hum
<re_irc>
< (@jamesmunns:beeper.com)> macros :p
<re_irc>
< (@grantm11235:matrix.org)> I am also considering adding this to the beginning of the function
<re_irc>
< (@jamesmunns:beeper.com)> I don't love that. I tend to run all my embedded stuff in release mode, esp when using defmt.
<re_irc>
< (@jamesmunns:beeper.com)> I don't always just change the debug profile to be opts + debug_assertions=true
<re_irc>
< (@grantm11235:matrix.org)> The asm is still a few lines longer than the nonzero version
<re_irc>
< (@adamgreig:matrix.org)> I'd love a "compile-time assert on literals" but it's a false sense of security here I guess
<re_irc>
< (@adamgreig:matrix.org)> well. I guess actually, "compile time check literals are >0 or error, otherwise do a runtime check", but that doesn't really work unless it's been inlined
<re_irc>
< (@jamesmunns:beeper.com)> I mean that macro I posted above will work or be a compiler error.
<re_irc>
< (@jamesmunns:beeper.com)> like, binding it to a scoped const will guarantee its evaluated at compile time.
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@jamesmunns:beeper.com)> but also: macro. I guess.
<re_irc>
< (@adamgreig:matrix.org)> but imagine if rustc could do that for you for integer literals going into a NonZero sized hole
<re_irc>
< (@jamesmunns:beeper.com)> would be neat.
<re_irc>
< (@adamgreig:matrix.org)> associated macros when :P
<re_irc>
< (@jamesmunns:beeper.com)> though seriously, might be worth a "denominator!()" macro in that module.
<re_irc>
< (@adamgreig:matrix.org)> I would love associated macros for stm32ral actually, "write_reg!(gpio, gpioa, MODER, MODER2: Output)" could be "gpioa.write_reg!(MODER, MODER2: Output)"
<re_irc>
< (@adamgreig:matrix.org)> wow, rustc really likes it when it can be sure you won't be dividing by 0
Amanieu has quit [Quit: No Ping reply in 180 seconds.]
Amanieu has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
cr1901 has joined #rust-embedded
WSalmon has quit [Ping timeout: 255 seconds]
WSalmon has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
dc740 has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 255 seconds]
agg has quit [Quit: WeeChat 1.8]
crabbedhaloablut has joined #rust-embedded
agg has joined #rust-embedded
<cr1901>
why is core::fmt::Write implemented for dyn ehal::serial::Write, rather than "any type that impls ehal::serial::Write"?
<cr1901>
I mean trait objects are cool, but what advantage do you get since you're not likely to have multiple impls of ehal::serial::Write for a single chip
<re_irc>
< (@jamesmunns:beeper.com)> the core/stdlib's "fmt" machinery is all done through dynamic dispatch
<cr1901>
ahhh
<cr1901>
Anyways, they got rid of that impl in ehal 1.0 :(
<cr1901>
Btw jamesmunns: Can confirm postcard works on AVR
<re_irc>
< (@jamesmunns:beeper.com)> That's super neat :D
<cr1901>
I could use ufmt, but there's actually a reason I want core::fmt in this case. It's a surprise :)
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, if you have a scratch buffer, you should be able to impl Write for it pretty easily. Or even on a serial port basically. Shame there's no out of the box option tho anymore
crabbedhaloablut has quit [Ping timeout: 255 seconds]
<cr1901>
Adding ARM and MSP430 should be easy enough, but I need a break lmao
<re_irc>
< (@jamesmunns:beeper.com)> That's some feat of portability.
<re_irc>
< (@jamesmunns:beeper.com)> Congrats :D
<cr1901>
Tyvm... all it does is dump the infomem to the console/terminal, and confirm that deserialization succeeded. I may add a Display impl, but not sure what that should look like
<cr1901>
(oh and I tried to limit the cfg boilerplate. Still not happy with it
<cr1901>
I should add Linux/Mac support as well, but Idk if the latter supports appending custom data to output sections
<cr1901>
(Linux should, but haven't bothered to look)
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
cr1901 has quit [Read error: Connection reset by peer]
mightypork has quit [Ping timeout: 260 seconds]
mightypork has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
cr1901 has joined #rust-embedded
<re_irc>
< (@charles:computer.surgery)> Freecad user checking in. It works well enough although figuring out the workflow kinda sucks because afaik there's no real documentation about what the overall strategy for doing things is
<re_irc>
< (@charles:computer.surgery)> has anyone tried writing FDM 3d printer firmware in rust
dc740 has quit [Remote host closed the connection]