ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
IlPalazzo-ojiisa has quit [Quit: Leaving.]
AtleoS has joined #rust-embedded
kenny has joined #rust-embedded
kenny has quit [Client Quit]
kenny has joined #rust-embedded
diagprov has quit [Ping timeout: 240 seconds]
dreamcat4 has quit [Ping timeout: 240 seconds]
Allie has quit [Ping timeout: 240 seconds]
diagprov has joined #rust-embedded
dreamcat4 has joined #rust-embedded
Allie has joined #rust-embedded
K900 has quit [Quit: Idle timeout reached: 172800s]
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
thomas25 has left #rust-embedded [Textual IRC Client:]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
beanflame[m] has joined #rust-embedded
<beanflame[m]> hi
dj2v65fnvh[m] has joined #rust-embedded
<dj2v65fnvh[m]> Hi guys, I have a stm32f429lDiscovery, I would like to run a working serial USB example. I have tried with the embassy but unfortunately, it doesn’t go smoothly => It would be great if you would point me on a working example.
<dj2v65fnvh[m]> I really need that for a proof that we could use Rust in prod for our embedded projects.
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> dirbaio: Is the embassy USB code forked off the `usb-device` crate? Because I've made a number of fixes for windows enumeration there that may not be in embassy that could be causing the above issue
<JamesMunns[m]> fwiw: I've been running embassy and USB on windows in prod for ~5mo now.
<ryan-summers[m]> Hmm okay then seems less likely to be that
<JamesMunns[m]> Not saying that the other comment or isn't facing some issue, but it's not just "embassy USB doesn't work with windows". I'm on F405 OTG instead of f429 hs, but yeah.
<adamgreig[m]> yea, I suspect this is just "clock config not right for this disco board" or similar error
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> I've had an f407-disco doing embassy usb on windows np
<adamgreig[m]> lol
<adamgreig[m]> or maybe it is and just james and i are both using a f407 otg
<ryan-summers[m]> The windows enum issues we were seeing with usb-device were super sporadic. Some PCs worked fine, but randomly other users had issues
<ryan-summers[m]> And could very much be related to the specific PHYs
<adamgreig[m]> the f407 and f429 have identical usb though I think
<JamesMunns[m]> Dirbaio also has a 429 disco in the ci pool
<adamgreig[m]> just whether you use the OTG_FS or OTG_HS peripheral
<adamgreig[m]> it's OTG_FS on the f407 disco board but I don't have an f429 disco board to test on
<dj2v65fnvh[m]> I just used the same clock configuration as in embassy example
<JamesMunns[m]> dj2v65fnvh[m]: Yeah, your clock config might be for another board, not sure
<adamgreig[m]> yea, the clock config is extremely board-specific
<adamgreig[m]> and USB is not very forgiving
<dj2v65fnvh[m]> hmmm ok, where I could get the correct clock?
<adamgreig[m]> the f429i-disc1 user manual, _hopefully, but
<adamgreig[m]> it also depends on what solder jumper settings you have
<adamgreig[m]> it sure looks like X3 should be fitted by default but I think the default state of the solder jumpers might be to use the st-link mco?
<adamgreig[m]> I would expect the st-link mco should be a stable enough 8MHz to work USB too though
<dj2v65fnvh[m]> hmm, let me check
xiretza[cis] has joined #rust-embedded
<xiretza[cis]> judging by 6.13 Solder bridges, default seems to be no HSE?
<xiretza[cis]> assuming "ON" = closed, "OFF" = open
<adamgreig[m]> it does seem that way
<adamgreig[m]> but why....
<adamgreig[m]> given the pcb has a crystal soldered down and everything..
<adamgreig[m]> it seems nuts if the default SB config doesn't work for USB, on a disco board, that presumably does work out-the-box with an ST USB example
<dj2v65fnvh[m]> do you talking regarding these jumpers?
<xiretza[cis]> no, it's about solder bridges SB18, SB19, SB20
<xiretza[cis]> the jumpers are just SWD selection
<xiretza[cis]> check the board manual (UM1670) for the locations of the solder bridges
<JamesMunns[m]> Oh I think I looked it up once yeah, it's just an 8mhz clock driven by the stlink
<adamgreig[m]> that's true on most nucleos
<adamgreig[m]> the f429i disco in question has either 8mhz mco from stlink, or 8mhz onboard xtal, or external xtal from the P2 pin headers, and chosen by solder jumpers
<JamesMunns[m]> The crystal is populated on the stlink but not the target iirc?
<xiretza[cis]> JamesMunns[m]: the manual says the default state is "MCO signal of STM32F429ZIT6 is not used." though
<adamgreig[m]> and the user manual suggests the default sb config is the third one
<JamesMunns[m]> xiretza[cis]: Ah maybe I'm remembering another board
<adamgreig[m]> which seems nuts and very unhelpful so idk
<xiretza[cis]> hold on, I'll check zephyr
<adamgreig[m]> though looking at it, the f407g-disc1 that I have - which "just worked" setting an 8mhz xtal - does say the SBs default to xtal mode
<adamgreig[m]> different to the 429 disco
<adamgreig[m]> so maybe they really did just have a very unhelpful default sb config for it
<xiretza[cis]> zephyr DTS has an 8MHz HSE
<xiretza[cis]> * zephyr DTS for the `stm32f429i_disc1` has an
<adamgreig[m]> but does it work on an unmodified f429i-disc1 or does the user have to change the solder bridge...
<xiretza[cis]> should work unmodified
<adamgreig[m]> for sure the board has an 8mhz hse xtal fitted
<adamgreig[m]> dj2v65fnvh: take a photo of the metal pads on the bottom of the PCB labelled SB18, SB19, SB20
<adamgreig[m]> some of them will have a small black resistor soldered on, some won't
<dj2v65fnvh[m]> one sec
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> back then the usb example would work unmodified on nucleo-f429zi
<dirbaio[m]> that's a different board though, not the disco-f429zi
<dirbaio[m]> <ryan-summers[m]> "dirbaio: Is the embassy USB code..." <- the state machine is written from scratch with async, though i did heavily reference usb-device. the handling for the "get device descriptor cut short" required for windows is different tho.
<dirbaio[m]> haven't seen any windows problems since implementing that
<adamgreig[m]> the nucleos mostly have mco in by default iirc
<adamgreig[m]> the windows usb stack is pretty weird huh
<adamgreig[m]> i got my ffp stack working so fast for linux and then plugged it into windows and discovered i was only half done lol
<adamgreig[m]> doesn't help that it's very sticky at remembering your half-screwed-up devices
<adamgreig[m]> i assume it's all so it's compatible with usb 1.0 keyboards from 1998
gauteh[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> <dirbaio[m]> "that's a different board though,..." <- so the only difference I can find is it's using the OTG_HS peripheral, not OTG_FS (but without a PHY so it can only do FS anyway)
<dirbaio[m]> so its DP=PB15, DM=PB14
<dirbaio[m]> instead of PA11/PA12
<dj2v65fnvh[m]> for my demo purposes FS is enough, I just need that is correctly displayed in Windows PC
<dirbaio[m]> and I dunno if you need to set something to choose to use internal FS PHY
<dirbaio[m]> can you share your full code, and output with DEFMT_LOG=trace ?
<dj2v65fnvh[m]> at the end there are logs.
<dirbaio[m]> that's not the full code
<dj2v65fnvh[m]> unfortunatelly, for now I am from another machine, I will get back to work tomorrow and I will share the full code that I have.
Socke has joined #rust-embedded
<dirbaio[m]> so OTG_HS on f429zi is core id 0x00001100
<dirbaio[m]> we're setting pwrdwn just fine tho :|
<dirbaio[m]> welp
<dirbaio[m]> my guess is there's something wrong about OTG_HS
<dirbaio[m]> but I don't know wht
<dirbaio[m]> s/wht/what/
<beanflame[m]> good!
<xiretza[cis]> <dj2v65fnvh[m]> "image.png" <- SB18, SB19, SB20 look open, so that's the 8MHz X3 crystal as HSE
<xiretza[cis]> dj2v65fnvh: try using `HseMode::Oscillator` in the RCC config
<dj2v65fnvh[m]> xiretza[cis]: it ended with this =>
<xiretza[cis]> dj2v65fnvh[m]: is that with bypass or oscillator mode?
<dj2v65fnvh[m]> it displayed as a some usb device but not detected correctly
<dj2v65fnvh[m]> xiretza[cis]: oscillator
<xiretza[cis]> ah sorry, I missed that that was already discussed in the issue
<JamesMunns[m]> You did swap the pins in the example right?
<JamesMunns[m]> > so its DP=PB15, DM=PB14
<JamesMunns[m]> > instead of PA11/PA12
<dj2v65fnvh[m]> yep
<dj2v65fnvh[m]> JamesMunns[m]: > <> > so its DP=PB15, DM=PB14
<dj2v65fnvh[m]> > > instead of PA11/PA12
<dj2v65fnvh[m]> with PA11 and PA12 it even don't diplayed as a usb device.
IlPalazzo-ojiis1 has joined #rust-embedded
AtleoS has quit [Ping timeout: 246 seconds]
AtleoS has joined #rust-embedded
<dirbaio[m]> anyone knows a reliable machine-readalbe data source for memory maps for stm32 chips?
<dirbaio[m]> like "stm32h755zi has FLASH_BANK1 at 0x0800_0000 512kb, FLASH_BANK2 at 0x0810_0000 512kb, SRAM1 at 0x2000_0000 64kb, SRAM2, TCM, etcetc
<dirbaio[m]> * like "stm32h755zi has FLASH\_BANK1 at 0x0800\_0000 512kb, FLASH\_BANK2 at 0x0810\_0000 512kb, SRAM1 at 0x2000\_0000 64kb, SRAM2, TCM, etcetc"
<dirbaio[m]> just flash and ram
<dirbaio[m]> s/readalbe/readable/
<Lumpio-> Wouldn't probe-rs have that information somehhere
<dirbaio[m]> ah yes, the cmsis packs!
<dirbaio[m]> of course
<Lumpio-> That's where it originally comes from
<Lumpio-> I wonder if this target info is available as a separate crate
<JamesMunns[m]> dirbaio[m]: Okay but are they correct
<dirbaio[m]> there's definitely been bugs in there
<dirbaio[m]> * in there in the past
<dirbaio[m]> but I think it's way better than what we have now
<dirbaio[m]> I think I'll extract some "chip name regex => memory map" mapping and check it in as yaml in the repo and hand-maintain it from there..
<dirbaio[m]> that should hopefully reveal inconsistencies in the probe-rs data too
<dirbaio[m]> yay already found mistakes
<dirbaio[m]> missing SRAM1, SRAM2, SRAM3 starting at 0x3000_0000
<dirbaio[m]> plus the RAM names are all weird too
<dirbaio[m]> it's always this shit with data from ST
<dirbaio[m]> incosnistent, crap naming, mistakes everywhere
<dirbaio[m]> 😭
<dirbaio[m]> stm32cube xmls -> only contain total ram/flash, not the memory map.... (full message at <>)
<M9names[m]> So the solution is to buy every stm32 chip, read it straight from the only reliable source of truth? 😜
<adamgreig[m]> Even the chips will sometimes lie about how much ram they have...
<dirbaio[m]> yeah that's why flash/ram size is OTP and not ROM
<dirbaio[m]> * not ROM 🤪
<dirbaio[m]> only reliable source is going through every RM PDF 🤪
jannic[m] has joined #rust-embedded
<jannic[m]> Perfect use case for an AI, isn't it?
barnabyw[m] has joined #rust-embedded
<barnabyw[m]> I have 99 PDFs, I add in an AI, now I have 100 problems
<Lumpio-> Yeah but if the AI is 90% accurate you still have to check them yourself...
<dirbaio[m]> I once tried to use gpt3 to add names to enums in SVDs. didn't end well (but probably because I was holding it wrong)
diondokter[m] has joined #rust-embedded
<diondokter[m]> AI has helped me on several occasions!
<diondokter[m]> Sadly not because it provided an answer, but because it forced me to rubber duck the problem to it :P
<dirbaio[m]> i've seen chatgpt hallucinate how to do shit with libraries quite a few times
<dirbaio[m]> "how do I do X with $LIB?" "Easy just use $METHOD of $CLASS, pass it X, Y and Z"
<dirbaio[m]> and $CLASS has no method at all
<dirbaio[m]> s/method/$METHOD/
<Lumpio-> It can apparently also hallucinate the existence of libraries
<Lumpio-> Which does make the job of generating code to do something quite easy, just assume there's a library for it
<dirbaio[m]> but it was like, really convincing. a method name that made a lot of sense, what chatgpt said the imaginary method did and its params made also a lot of sense, like that's how i'd have added that feature to the lib
<dirbaio[m]> but ... no method
<dirbaio[m]> lib simply can't do X
<barnabyw[m]> just ask chatgpt to write the method for you and send a PR :P
<diondokter[m]> I've asked it how one could implement sequential-storage like functionality for flash memory. Maybe it would have an amazing idea I wasn't seeing! But it was only able to say that I should use a file system and named two or so of them
<dirbaio[m]> barnabyw[m]: apple closed-source shit :P
<barnabyw[m]> ah
<diondokter[m]> dirbaio[m]: Yeah, hallucinations are a huge problem for reliability
<dirbaio[m]> and i've seen it violently derail junior people by saying wrong things to them
<dirbaio[m]> like repeating common misconcpetions or reasoning things wrong :D
<diondokter[m]> We've had people use copilot in our Rust trainings... Kinda missing the point for learning :P
<Lumpio-> If you tell people not to are they like "ok boomer"
<dirbaio[m]> yea wtf :D
<dirbaio[m]> i've tried copilot, I found it quite bad
<dirbaio[m]> sure it might be amazing for React CRUD boilerplate apps
<Lumpio-> I guess it depends on largely what you're doing
<Lumpio-> Yeah I was just about to say if it's a generic web app it probably works ok
<dirbaio[m]> but as soon as you have to use your brain very slightly, it just can't
<Lumpio-> I did get ChatGPT to almost generate code to "SPI bitbang" one of those RGB LEDs though, in Rust!
<dirbaio[m]> but even for boring CRUD stuff, it's just plain bad, it encourages writing very verbose and repetitive code
<Lumpio-> I was seeing if it could generate something better than I came up with but not quite, but its code would have worked with minor tweaks
<diondokter[m]> Lumpio-: Almost?
<dirbaio[m]> instead of abstracting stuff so you write less boilerplate
<dirbaio[m]> which sure you can write it faster the 1st time, but next time you want to change how something works in the 500 boilerplated components you made, good luck
<Lumpio-> Well it would not have compiled but the errors were fairly simple to fix
<barnabyw[m]> I’ve never managed to get a good LLM workflow working for programming, but some people have a lot of success with it. Simon Willison has a couple of blog posts where he shows his entire workflow e.g.
<jannic[m]> My comment was mostly joking, I don't expect current AIs to accurately understand a RM. But in theory, I guess it's something an AI could do, if the RM contains accurate information in the first place. After all, it's a task that doesn't really require much thought or creativity.
<dirbaio[m]> yeah for these boring tasks it should work
<barnabyw[m]> and now I think of it, that tool he made could even be useful as part of a theoretical AI RM-scraping workflow 👀
<dirbaio[m]> feels like i'd spend more time rigging it up than going through all RMs manually
<dirbaio[m]> * RMs manually tho
<dirbaio[m]> google "stm32 memory map data source" ... google suggests stm32-data to me 😭
<dirbaio[m]> * me 😭 👊
<dirbaio[m]> * me 😭 🤦‍♂️
<jannic[m]> Where it did help me in the past was when I had questions about quite popular but not well documented libraries. Like where you'd need to google through lots of blog posts and stackoverflow questions to get an answer manually.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> using LLM for coding is like "cheating" in speedrunning games. Its nice for people who absolutely have no idea about a topic to get some otherwise impossible results with there then current understanding of thinks. But they completely miss the training step for themself. So yeah if the goal is to actually learn something maybe only use LLM only to ask critical questions about coding and then try to evaluate the answer with more
<vollbrecht[m]> critical questions, but blindly accepting code output itself is the worst outcome.
<vollbrecht[m]> For an already experienced programmer as for an "experienced" speedrunner it might be sometimes a tool to get an edge, because one have the ability to evaluate the answer given. But as a beginner its just the wrong tool.
<barnabyw[m]> yeah, similarly it can be very useful for generating argument strings for complex, badly-documented command line tools
<dirbaio[m]> until it lies to you
<barnabyw[m]> eh, for how little effort it takes to make a query it doesn’t have to have a high success rate to save you time overall. provided you know it could be lying and can quickly discard garbage answers it’s not a big deal
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> LLMs are great for things like translating languages, using a new lib, finding a concise way to write repetitive code, writing macros etc. Anything where you would ask a person or Stack Overflow a question about, or reference docs that either don't exist, are tricky to navigate, or don't provide examples
<firefrommoonligh> This wasn't true until recently
<firefrommoonligh> Or, actually, probably the best one: If your code doesn't compile or misbehaves, and you can't figure out why (quickly enough). Copy+paste the code and error message, and out pops both the correction, and the explanation for what you screwed up