<re_irc>
<James Munns> adamgreig: "there and back again: a story of "dereferenceable"" - ewg studios, 2022
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
crabbedhaloablut has quit [Write error: Broken pipe]
crabbedhaloablut has joined #rust-embedded
causal has quit [Quit: WeeChat 3.5]
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<Mehmet Ali> ryan-summers: The package requires me to implement NorFlashError for the Error type (in my case MockError) but requires a dyn keyword on them like this:
<re_irc>
error[E0782]: trait objects must include the `dyn` keyword
<re_irc>
<Mehmet Ali> Any pointers to me? I get that dyn keyword is used for types that don't have a known size at compile time. but here, they are all enums?
<re_irc>
<henrik_alser> Mehmet Ali: i guess it means you’re supposed to use the concrete type (the enum) that you implemented the trait for?
<re_irc>
<henrik_alser> Instead of the trait itself
dc740 has quit [Remote host closed the connection]
<re_irc>
<Mehmet Ali> Pondering 🤔
<re_irc>
<Mehmet Ali> So, "NorFlash" trait seems to require a "type Error" to be defined.
<re_irc>
<Mehmet Ali> So I created a dummy "MockError" enum.
<re_irc>
<Mehmet Ali> Then realized that "MockError" must implement "NorFlashError"
<re_irc>
<Mehmet Ali> "NorFlashError" has a aaargh I pasted the wrong code henrik_alser sorry.
<re_irc>
<Mehmet Ali> Ad I guess I understood what the problem is.
<re_irc>
<Mehmet Ali> impl NorFlashError for MockError {
<re_irc>
<Mehmet Ali> i mean we tended to have enumLast all the time to check
<re_irc>
<Mehmet Ali> James Munns: Also very relevant
<re_irc>
<Mehmet Ali> Maybe it is time to crack postcard open
<re_irc>
<dirbaio> is this for a network protocol thing?
<re_irc>
<Mehmet Ali> no, it is actually safeish
<re_irc>
<Mehmet Ali> a struct for FLASH
<re_irc>
<dirbaio> hmmm
<re_irc>
<dirbaio> dunno then. trying to do zerocopy seems a bit like premature optimization to me
<re_irc>
<dirbaio> vs using serde/postcard which are fully safe and handle errors nicely
<re_irc>
<Mehmet Ali> Oh, I was just using the tool that I have had used
<re_irc>
<Mehmet Ali> I am not interested in the zero copniess of it
<re_irc>
<dirbaio> but if it's for storing data in internal flash, if you're OK with considering the data "trusted"
<re_irc>
<Mehmet Ali> I used it, it worked.
<re_irc>
<Mehmet Ali> dirbaio: Yep
<re_irc>
<Mehmet Ali> I think the best course of action is to plug and play alternatives
<re_irc>
<dirbaio> then maybe you can get away even with the "real" enu
<re_irc>
<dirbaio> * enum
<re_irc>
<Mehmet Ali> All Traits are names similarly, maybe it is just a matter of a switcheroo.
<re_irc>
<dirbaio> because you can assume the data on flash is "always valid" because you've written it yourself
<re_irc>
<dirbaio> but it's very very dangerous
<re_irc>
<Mehmet Ali> dirbaio: dang what do you mean by a real enum
<re_irc>
<James Munns> (postcard will also encode the enum value in a single byte, as long as it has <= 127 variants :D)
<re_irc>
<Mehmet Ali> James Munns: Will give that a try, I was silently watching from the sides
<re_irc>
<Mehmet Ali> What about valued enums?
<re_irc>
<James Munns> yup, supports those too
<re_irc>
<Mehmet Ali> Any chenc?
<re_irc>
<Marco Silva> Mehmet Ali: yeah I've seen some, but was wondering it there was an effort to standerdzize some parts of it. stuff like this crate to declare registers https://docs.rs/i2c-reg/latest/i2c_reg/index.html
<re_irc>
<diondokter> It should get some love again though... Thing is, I was writing a couple of drivers and was sick of it. So then I created this crate and haven't had to write a driver after it... So yeah... 😅
<re_irc>
<diondokter> But it still works even though it's a bit rough behind the scenes
<re_irc>
<Marco Silva> like most rust stuff right? xD
<re_irc>
<Marco Silva> keeps working
<re_irc>
<dirbaio> I've written a few drivers with it, works very nicely
<re_irc>
<diondokter> Yeah, but the thing is that this crate has like 3-4 macros inside eachother, so changing anything or fixing anything is a massive pain!
<re_irc>
<diondokter> dirbaio: Good to hear!
<re_irc>
<dirbaio> one thing that annoys me though is the syntax to define the regs is "very custom"
<re_irc>
<dirbaio> for chips with lots of regs/fields, I've had to parse C headers with python+regex
<re_irc>
<diondokter> There is a branch that started migrating it to a proc macro with different syntax.
<re_irc>
But if you have feelings for how it should look, then please open an issue with a suggested syntax
<re_irc>
<dirbaio> which then needed more custom python code to print the data in the device-driver syntax
<re_irc>
<dirbaio> and once printed in the device-driver syntax you can't easily "parse it back" to something structured to manipulate it further either
<re_irc>
<dirbaio> it'd be nicer if it somehow took json/yaml... that'd require a proc macro though..
<re_irc>
<James Munns> okay
<re_irc>
<James Munns> okay
<re_irc>
<James Munns> we store the register information in XML
<re_irc>
<James Munns> then we generate a pac using ~svd2rust~ xml2driver
<re_irc>
<dirbaio> :D
<re_irc>
<Mehmet Ali> James Munns: It just compiled?
<re_irc>
<James Munns> I think that's a good thing?
<re_irc>
<Mehmet Ali> dirbaio was able to manage all stm32's, this would be a piece of cake.
<re_irc>
<dirbaio> I've written a driver like that, feeding yaml to a hacked-up chiptool
<re_irc>
<Mehmet Ali> Yep, this looks like a good it just compiled.
<re_irc>
<Mehmet Ali> Let me use it on my mock Flash and see whet it writes
<re_irc>
<Mehmet Ali> * what
<re_irc>
<James Munns> Postcard's whole thing is basically "if you can make a rust struct, and slap on derive(Serialize, Deserialize), it will Just Work."
<re_irc>
<dirbaio> hacked up to call fns to do i2c read/writes instead of MMIO
<re_irc>
worked fine, and not having macros was nice
<re_irc>
but ideally we should have a real tool for this, more maintainable than a one-off patched up chiptool
<re_irc>
<Mehmet Ali> it will Just Work™
<re_irc>
<James Munns> There are certainly cases where if you need a really specific thing (streaming support, very small code size), postcard won't be perfect for you, but it's generally a great first choice, and sometimes only choice.
<re_irc>
<Mehmet Ali> Not like one of those cases where things were so bad but it just works and that makes you even more anxious and you start to perspire harder.
<re_irc>
<James Munns> Aims for the trifecta of "pretty small, pretty fast, pretty widely usable" :D
<re_irc>
<diondokter> So what I would like to have a library with a separated frontend and backend for device drivers.
<re_irc>
The backend would generate the rust code and there could be multiple frontends. E.g. a macro based one and json, xml and whatever ones that build in the build.rs
<re_irc>
<James Munns> My $0.02: Don't do codegen for stuff that doesn't change without a commit
<re_irc>
<James Munns> just have the tool, and check in the output
<re_irc>
<James Munns> the hardware you are targeting doesn't change that often (really: never)
<re_irc>
<James Munns> so adding proc macro/build-rs built time to EVERY USER OF THAT LIBRARY seems like a bad trade off, to me.
<re_irc>
<James Munns> decl macro is a little different, since the cost is so much lower. but if you are switching to proc-macro or build-rs, the cost/benefit changes
<re_irc>
<dirbaio> ...unless the pregenerated output doesn't fit into the 10MB crates.io limit 😂
<re_irc>
<James Munns> dirbaio: Oh no
<re_irc>
<James Munns> (you can also ask crates io to up this limit for you)
<re_irc>
<James Munns> but like... 10MB is a lot of text lol
<re_irc>
<adamgreig> 10MB zipped at that
<re_irc>
<dirbaio> can you? :P
<re_irc>
<adamgreig> You definitely can, they have in the past for PACs
<re_irc>
<dirbaio> I had to do lots of golfing to get stm32-metapac to fit under 10mb.. 😂
<re_irc>
<diondokter> So you'd rather a cli tool that generates a crate from some source file?
<re_irc>
<adamgreig> could you post your code anywhere? how are you flashing the microcontroller?
<re_irc>
<762spr> I am just hitting run in vscode. I do get defmt::println!'s to work so I am assuming flashing is somewhat working. the LED on the nucleo board flashes appropriately as well
<re_irc>
<adamgreig> ah cool, yea if defmt::println is working that's a good sign your code is running on the device
<re_irc>
<762spr> there are a lot of commented out things I did to try and get it working so sorry about that 😅
<re_irc>
<adamgreig> that's fine! why are you setting the pin to open-drain?
<re_irc>
<762spr> that is what the guy did on the guide, but I tried it both ways
<re_irc>
<adamgreig> you'll definitely need push-pull for this
<re_irc>
<762spr> I was honestly wondering about that myself but push pull didn't work either
<re_irc>
<adamgreig> the LED is connected directly to the IO pin: open-drain means the pin can only be actively driven to 0V, and never outputs a positive voltage
<re_irc>
<adamgreig> sometimes that _is_ right for an LED, if the LED is wired like 3v3 -> LED -> resistor -> stm32, then the stm32 provides the ground and open-drain would work
<re_irc>
<adamgreig> but on the nucleo board it's stm32 -> resistor -> LED -> ground, so the stm32 pin needs to be 3v3, which needs push-pull
<re_irc>
<762spr> makes sense. I did just try it with
<re_irc>
<adamgreig> just to check, have you ever seen the LED light up on the nucleo board? if SB15 is removed on the board, the LED can't light up
<re_irc>
<adamgreig> that's probably not your issue but worth being sure about
<re_irc>
<762spr> by the way I really like the way of setting up peripherals the way you guys do it in runs vs manually setting them in C. It makes more sense to me even though I am still having trouble 😅
<re_irc>
<762spr> you know what, I think this is a new one I just got... I have never tested it working let me see if I can find some known good code to flash onto it
<re_irc>
<adamgreig> could of other quick things: you should probably write "rcc.ahb2enr.modify(|_, w| w.gpioben().set_bit());" instead of using "write()", because write sets all the other fields to their reset value
<re_irc>
<adamgreig> but in this particular case it won't matter because you don't change anything else...
<re_irc>
<adamgreig> but for example if you wrote "rcc.ahb2enr.write(|w| w.gpioben().set_bit());" and then "rcc.ahb2enr.write(|w| w.gpiocen().set_bit());" (note port C in the second one), it would turn off port B
<re_irc>
<adamgreig> aaah, ok, I think I've noticed your actual problem
<re_irc>
<adamgreig> you set OTYPER which is push-pull vs open-drain, but you don't set MODER, which is input vs output vs alternate
<re_irc>
<adamgreig> you don't actually need to set OTYPER at all, but you do need to set MODER, it's input by default (iirc)
<re_irc>
<adamgreig> (the default OTYPER is push-pull)
<re_irc>
<762spr> 🤦♂️ ok that makes sense
<re_irc>
<762spr> it's been a while since I have done any configuration on an STM32 and even then I wasn't very experienced with it... now I am jumping back in AND trying a new language. What could possibly go wrong???
<re_irc>
<adamgreig> hehe
<re_irc>
<adamgreig> if you don't have the chip's reference manual open already, i think it's essential when doing direct register writes, it documents all the registers and i'll usually just quickly go through all of them to check i've not missed anything
<re_irc>
<762spr> BINGO! it lit up now. I feel dumb but hey, that's how I learn. I really appreciate the help!
<re_irc>
<James Munns> 762spr: You love to see bugs that are easy to fix, and don't require fixing libraries or the compiler :D
<re_irc>
<762spr> I have it up on the other monitor, but the other guide didn't mention it at all... or maybe he did and I didn't notice. it was close to 4 am!😅
<re_irc>
<762spr> but of course now that you mention it it makes total sense! and yes, I will need to skim the register definitions again!
<re_irc>
The nice thing is without even having to refer to the docs, or counting bits or converting to a 0x or 0b literal or any of that. No |'ing or &'ing I can basically just press . to chain through exactly what I want to do and I really love that about the way it is done with rust embed
<re_irc>
<762spr> the only down side is it makes it easier to not understand exactly what's going on under the hood so I am wondering why my led isn't lighting when it is still set to input 🤡
<re_irc>
<762spr> Anyway I will stop spamming the channel. Thanks for all the help and thanks to all of you who have developed all this stuff for me to play with and mess up 😂
<re_irc>
<adamgreig> yea, having actual names for fields and values is so nice, and not having to manually OR things together etc... and (in release mode) it compiles to exactly the same "load this single value into this memory address"
<re_irc>
<adamgreig> no problem, this is what the channel is here for!