crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
conplan has left #rust-embedded [Leaving.]
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 272 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
Shell has joined #rust-embedded
agg has quit [Ping timeout: 252 seconds]
wose has quit [Ping timeout: 252 seconds]
richardeoin has quit [Ping timeout: 252 seconds]
Shellhound has quit [Ping timeout: 252 seconds]
vancz has quit [Ping timeout: 252 seconds]
vancz has joined #rust-embedded
richardeoin has joined #rust-embedded
agg has joined #rust-embedded
wose has joined #rust-embedded
<re_irc>
< (@almindor:matrix.org)> : if the model is missing mipidsi is designed so that adding is fairly simple. Ping me if you need help for your model (I'm the author)
<re_irc>
< (@sparky:matrix.possumlodge.me)> : well, the issue is i looked by the model number of the screen, NOT the spec it used for display (as i didnt even know it had one). so google and the like couldnt point me to your crate as it doesnt have enough of the proper keywords present
<re_irc>
< (@almindor:matrix.org)> : Ah, SEO failure
<re_irc>
< (@sparky:matrix.possumlodge.me)> the crate has the model i was looking for inside of it already, its just google and lib.rs was no help at finding it
<re_irc>
< (@sparky:matrix.possumlodge.me)> and yeah... SEO failure. it exists and works fine, just could not find it due to lack of knowledge and lacking SEO stuff
<re_irc>
< (@almindor:matrix.org)> yeah I should probably add the model list to readme and lib.rs
<re_irc>
< (@sparky:matrix.possumlodge.me)> no idea how much that help for google and the like, but ideally that should help for lib.rs and crates.io searches
<re_irc>
< (@sparky:matrix.possumlodge.me)> +🙂
<re_irc>
< (@almindor:matrix.org)> : which model do you use? I'm curious coz I don't have all of them to test
<re_irc>
< (@sparky:matrix.possumlodge.me)> ILI9342C. though, technically its not me and im asking on behalf of someone else that owns it but doesnt have a matrix account
<re_irc>
< (@almindor:matrix.org)> ah cool, that one is completely done by a 3rd party
<re_irc>
< (@sparky:matrix.possumlodge.me)> : in this particular case, the screen is soldered and cased up as part of a complete product: https://docs.m5stack.com/en/core/core2
<re_irc>
< (@almindor:matrix.org)> ah haha I use M5 USB module, don't have any of their displays though
<re_irc>
< (@sparky:matrix.possumlodge.me)> so itll probably work based on their wiring diagram in their docs, but it hasnt been fully confirmed yet... ill probably hear at some point in a week or so though
emerent has quit [Ping timeout: 276 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 258 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> :wave: Hello everyone, it's your favourite meeting time. We'll get started in a few minutes. I'll be your driver today since might not be available.
<re_irc>
< (@therealprof:matrix.org)> * (wave)
<re_irc>
< (@therealprof:matrix.org)> * Hello everyone, it's your favourite meeting time. We'll get started in a few minutes. I'll be your driver today since might not be available. 👋
<re_irc>
< (@therealprof:matrix.org)> The minutes are here: https://hackmd.io/moBjjIIPSWit7GYFL8AiqA . Please feel free to add yourself to the attendance and also add any topics you would like to discuss today.
GenTooMan has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> Sorry for the delay, let's get started.
<re_irc>
< (@therealprof:matrix.org)> First up: People have been busy, especially so we had been able to release "svd2rust" 0.27.0 (and a bugfix 0.27.1) with exciting new features.
<re_irc>
< (@therealprof:matrix.org)> Anyone else have anything to announce?
<re_irc>
< (@therealprof:matrix.org)> I think the IRC bridge was successfully restored if I'm tracking the chat correctly? Can someone confirm (or deny)?
<cr1901>
Test
<cr1901>
I can see your msgs
<re_irc>
< (@jamesmunns:beeper.com)> TESTACK
<cr1901>
can you see mine?
<cr1901>
awesome
<re_irc>
< (@therealprof:matrix.org)> 😄
<re_irc>
< (@therealprof:matrix.org)> I'll put that down as a success. 😉
<re_irc>
< (@therealprof:matrix.org)> Alright, hearing nothing to announce so let's move on.
<re_irc>
< (@therealprof:matrix.org)> Last week we had some discussion about critical-section in Cortex-M and RISC-V. Are there any new discoveries to mention?
<cr1901>
I may have a solution to critical-section bloat in msp430, but it's a bad hack. I'll see if I can impl it this week
conplan has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> We all love a good hack. 😅
<re_irc>
< (@therealprof:matrix.org)> So do people feel we're still good on the "critical-section" ordering (which was my soft takeaway from last week)?
<re_irc>
< (@therealprof:matrix.org)> Seems we can punt on that topic as well, then. Moving on.
<re_irc>
< (@therealprof:matrix.org)> : Are you there? Any news on your interrupt handles experiment?
<re_irc>
< (@korken89:matrix.org)> Currently only testing and gathering feedback :)
<re_irc>
< (@korken89:matrix.org)> Not much, mostly a discussion of the interface is enough or if one should be able to register more than one method, but no conclusions yet
GenTooMan has quit [Remote host closed the connection]
<re_irc>
< (@korken89:matrix.org)> The interface seems to cater quite well so wherever we can we use it to see if we find an issue
<re_irc>
< (@korken89:matrix.org)> I think atsamd Hal was going to try it as well
<re_irc>
< (@therealprof:matrix.org)> Nice. IIRC you wanted to update the documentation?
GenTooMan has joined #rust-embedded
<re_irc>
< (@korken89:matrix.org)> Indeed, some beginning docs were added
<re_irc>
< (@korken89:matrix.org)> Not done yet though
<re_irc>
< (@korken89:matrix.org)> I most content is there, just needs some massage
<re_irc>
< (@korken89:matrix.org)> Readme and API docs
<re_irc>
< (@korken89:matrix.org)> Most important know is examples
<re_irc>
< (@korken89:matrix.org)> * now
<re_irc>
< (@therealprof:matrix.org)> As in "needs doing" or "has changed"? 😅
<re_irc>
< (@korken89:matrix.org)> So I'm doing some partial conversion of nRF52 HAL as an example
<re_irc>
< (@korken89:matrix.org)> Should have changed
<re_irc>
< (@korken89:matrix.org)> Oh maybe not API docs yet
<re_irc>
< (@therealprof:matrix.org)> I'm really excited about this work but (as usual) didn't have the time to check it out myself.
<re_irc>
< (@korken89:matrix.org)> I hope we'll find a good API that we can base the next generation of HALs on :) at least we'll learn a lot :D
<re_irc>
< (@korken89:matrix.org)> +async
<re_irc>
< (@therealprof:matrix.org)> I do feel that having a good story on how to generically combine interrupts and async is going to be important.
<re_irc>
< (@korken89:matrix.org)> Indeed, I fully agree
<conplan>
any cool tools to start writing a hal with?
<re_irc>
< (@therealprof:matrix.org)> conplan: What kind of tools where you thinking of?
<conplan>
well, to easily generate a pac we have SVD to rust.
<conplan>
and alot of the hal gpio structs are the same
<conplan>
is there anything that can easily generate the functions for gpio structs
<conplan>
or a similar system
<re_irc>
< (@therealprof:matrix.org)> Well, that's basically all there is to a HAL: Creating the glue between the register and their use and the traits on the other end.
<re_irc>
< (@therealprof:matrix.org)> There're ways to remove the repetition but at least once per implementation you'll always have to do yourself.
<conplan>
that's understandable
<re_irc>
< (@therealprof:matrix.org)> But that's kind of a good segway... Any news about "embedded-hal" and the road to 1.0?
<re_irc>
< (@eldruin:matrix.org)> nothing new this week
<conplan>
ooh... whats the relationship between embedded hal, and writing a new hal? is it a dependnecy?
<re_irc>
< (@burrbull:matrix.org)> It is bridge
<re_irc>
< (@therealprof:matrix.org)> : I notice there's a PR open to bump the MSRV from 1.45 to 1.56; I was quite surprised to see that we're lagging so far behind for the async stuff...
<re_irc>
< (@burrbull:matrix.org)> between hals and drivers
<conplan>
burrbull: can you elaborate
<re_irc>
< (@dirbaio:matrix.org)> I belive that's for the main e-h crate, which doesn't have the async stuff
<re_irc>
< (@dirbaio:matrix.org)> async traits is still nightly-only
<re_irc>
< (@therealprof:matrix.org)> : Then I don't quite get it.
<re_irc>
< (@eldruin:matrix.org)> > Raise MSRV for embedded-hal-async to Rust 1.65.0
<re_irc>
< (@eldruin:matrix.org)> but it is not even released yet
<re_irc>
< (@eldruin:matrix.org)> plus, e-h-a still depends on nightly
<re_irc>
< (@dirbaio:matrix.org)> "embedded-hal-async/README.md" stating 1.46 before was copypaste error
<re_irc>
< (@eldruin:matrix.org)> so it does not make much sense to me
<re_irc>
< (@eldruin:matrix.org)> it comes out some time in november
<re_irc>
< (@dirbaio:matrix.org)> technically it requires 1.65 because GAT, but it requires nightly because TAIT
<re_irc>
< (@dirbaio:matrix.org)> so having a MSRV doesn't make sense
<re_irc>
< (@dirbaio:matrix.org)> IMO we should just state "requires nightly newer than X, but keep in mind nightly can break at any time", and no MSRV
<re_irc>
< (@therealprof:matrix.org)> I though so, too.
<re_irc>
< (@dirbaio:matrix.org)> * <date>,
<re_irc>
< (@chrysn:matrix.org)> : Does it really need TAIT to build, or only to practically use?
<re_irc>
< (@therealprof:matrix.org)> Any new insights on the "bus" front?
<re_irc>
< (@dirbaio:matrix.org)> anyway, we'll soon be able to switch to "#![feature(async_fn_in_trait)]"
<re_irc>
< (@chrysn:matrix.org)> It may not be worth explicitly rewriting them (it's probably even more clutter than for the iterators for which I've been doing that), and the feature sounds like the more practical route to go.
<re_irc>
< (@dirbaio:matrix.org)> : No updates from me
<re_irc>
< (@therealprof:matrix.org)> It would be really great if we could put a check behind that and get e-h 1.0 out this year.
<re_irc>
< (@eldruin:matrix.org)> : nothing from me, currently SPI hangs on l-e-h implementability
<re_irc>
< (@eldruin:matrix.org)> I2C is also unclear
<re_irc>
< (@therealprof:matrix.org)> Indeed, should have said busses, probably.
<re_irc>
< (@dirbaio:matrix.org)> iirc we already discussed it's not blocking?
<re_irc>
< (@therealprof:matrix.org)> I think the most favoured solutions were: Remove the features (and potentially add back later when we have clarity) or document the problems away, right?
<re_irc>
< (@dirbaio:matrix.org)> becuase most usage is "N writes + maybe 1 read", which is implementable (for both spi, i2c)?
<re_irc>
< (@therealprof:matrix.org)> : I think the usage pattern for SPI and I2C is quite different.
<re_irc>
< (@eldruin:matrix.org)> : IIRC that was the case for SPI, for I2C there was more unclear I think
<re_irc>
< (@dirbaio:matrix.org)> i'd say it's roughly the same for i2c
<re_irc>
< (@dirbaio:matrix.org)> you can buffer all writes and flush on read
<re_irc>
< (@dirbaio:matrix.org)> and thne if you get another read then error
<re_irc>
< (@dirbaio:matrix.org)> you can buffer all writes and flush on first read
<re_irc>
< (@dirbaio:matrix.org)> and then if you get another read then error
<re_irc>
< (@therealprof:matrix.org)> With I2C it is quite typical to have multiple devices connected to a shared bus and there's a wild mix of read/write operations. With SPI a shared bus is much less common, but you typically have dedicated CS signals if you do have multiple devices on the same bus. Also most often the data is transferred unidirectionally.
<re_irc>
< (@dirbaio:matrix.org)> the old API only supported "1 write + 1 read"
<re_irc>
< (@dirbaio:matrix.org)> +in a single transaction
<re_irc>
< (@dirbaio:matrix.org)> and it was _fine_ for pretty much any device driver
<re_irc>
< (@dirbaio:matrix.org)> new API supports "N writes + 1 read" on all hardware, "N writes + N reads" on most
<re_irc>
< (@therealprof:matrix.org)> I'm not fully sure how that is supposed to work. To read on SPI you have to clock out enough clocks to read back.
<re_irc>
< (@therealprof:matrix.org)> So when we're talking about N writes, 1 read: what does that actually mean?
<re_irc>
< (@dirbaio:matrix.org)> calls to "write", "read"
<re_irc>
< (@dirbaio:matrix.org)> which transfer a "[u8]"
<re_irc>
< (@therealprof:matrix.org)> Okay, so from the API perspective but not on the SPI bus?
hwj has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> Anyway we're out of time for today.
<re_irc>
< (@therealprof:matrix.org)> I wanted to quickly mention that we haven't had a blog post for a long time but I noticed that there were a number of embedded related posted on the regular TWIR.
<re_irc>
< (@therealprof:matrix.org)> Those newsletter are not mutually exclusive, people are very much welcome to add links to both newsletters. 😉
<re_irc>
< (@therealprof:matrix.org)> If you have anything to add, please create a (or multiple) PR. Maybe I'll find the time to scrub the webs for some noteworthy things to add so maybe we can have a new blog next week.
<re_irc>
< (@therealprof:matrix.org)> Thanks for joining the discussion and have a great remainder of the day. 👋
<re_irc>
< (@9names:matrix.org)> Just a friendly reminder that the rust foundation community grants applications close on the 31st of October. We had several successful applications from the embedded community in April, which was great to see. If you were planning on applying for one you should get your
<re_irc>
<Rik> Hi!, I got a. hopefully simple, question. I am working on a hobby project in Rust on an STM32F042. It's a bare metal (no rtic or such) application, a nixie clock. It works quite well but I have one annoying issue. When I debug it via GDB it all works, but when I power on the board it does not. The moment I then connect a debugger and debug the application it works.
<re_irc>
I can power cycle the board, attach GDB to the STM32 and see where it ended up, which is in the panic handler. I already checked the boot pins (and if it boots the internal bootloader I expect it to end up somewhere else) and the reset pin, so hardware wise that all looks OK.
<re_irc>
<Rik> Would someone have an idea what could cause this behavious?
<re_irc>
<Rik> * behaviour?
<re_irc>
< (@jamesmunns:beeper.com)> Are you using rtic? and what panic handler are you using?
<re_irc>
< (@jamesmunns:beeper.com)> A typical problem is that the dwt-based monotonic provider only works (on STM32) if the debug core is enabled
<re_irc>
<Rik> I am not using RTIC, and I am using panic-halt
<re_irc>
< (@jamesmunns:beeper.com)> Any chance you have the code up in a repo somewhere?
<re_irc>
<Rik> Only on a private one, but that can be fixed, one moment :)
Lumpio- has quit [Read error: Connection reset by peer]
<re_irc>
< (@jamesmunns:beeper.com)> Gotta run here in a minute, but I can take a quick peek :)
<re_irc>
<Rik> https://github.com/riktw/nixiewatch There we go, I started this 2 years ago but now finally the parts arrived.... And the code is more then a bit of a mess, sorry for that 😅
conplan has quit [Remote host closed the connection]
<re_irc>
< (@therealprof:matrix.org)> : Good shout! 👍️
<re_irc>
< (@therealprof:matrix.org)> Rik: The F042 can indeed be a bit finicky to boot, there're multiple ways to push it into the bootloader (including unclear reset). Are you sure you have strapped the pins properly so it doesn't accidently is pushed into the BL via residual currents or magnetic fields?
<re_irc>
< (@jamesmunns:beeper.com)> Rik I don't see anything super obvious, a couple of routes to go down:
<re_irc>
- What therealprof said (you can test with a simple hello world app that turns an LED on or blinks it or something)
<re_irc>
- Some external I2C devices take some time to boot up, and I see you "unwrap"ing the init steps. Maybe try a delay of like 50ms before talking to anything external?
<re_irc>
- Do you really only have 4K of RAM? it's possible you are overflowing your stack (you could try "flip-link"), and GDB sometimes masks hardfaults/memory faults
<re_irc>
< (@jamesmunns:beeper.com)> Overall, if it's not any of those things, it would be good to see _why_ you are panicking. You could use something like "panic-persist", to save the panic message, or just vomit out the panic message on a UART or something if you have one available.
<re_irc>
< (@jamesmunns:beeper.com)> (or, start removing code that can panic, and see where the problems come back)
<re_irc>
< (@jamesmunns:beeper.com)> Sorry no silver bullet, but good luck! I'll check back later
<re_irc>
<Rik> No, you had the silver bullet :D
<re_irc>
< (@jamesmunns:beeper.com)> oh?
<re_irc>
< (@therealprof:matrix.org)> BTW: The 0x4x has 6kB of RAM. 😉
<re_irc>
<Rik> The MPU-6050 needs some startup time it seems.
<re_irc>
<Rik> I added a small delay and presto
<re_irc>
< (@jamesmunns:beeper.com)> huzzah!
<re_irc>
< (@therealprof:matrix.org)> * F04x
<re_irc>
<Rik> Time to look at the crate a bit better if they have a nicer option then a delay before initing it.
<re_irc>
< (@jamesmunns:beeper.com)> (50ms is probably too much, but read the datasheet :D)
<re_irc>
<Rik> : I think with the STM HAL 2KB is reserved for USB or so, but yeah that is likely not the case, good one.
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, looks like the PLLs take 1ms typ, 10ms max to lock, I imagine it wont talk to you until that happens
<re_irc>
< (@therealprof:matrix.org)> Rik: I thought that was separate but I might be wrong.
Lumpio- has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> The reason why the "stm32f0xx-hal" defaults to 4kB is because the F03x only has 4kB. I happen to be the author of that BTW.
<re_irc>
< (@jamesmunns:beeper.com)> Anyway, glad it works :D
<re_irc>
< (@jamesmunns:beeper.com)> And congrats on your extra bonus RAM :D
<re_irc>
< (@jamesmunns:beeper.com)> (the rust USB crates don't have a separate linker section for USB buffers, so it just comes out of your main "RAM" section)
<re_irc>
<Rik> Ah awesome, bonus RAM. And thanks a ton!
<re_irc>
< (@therealprof:matrix.org)> "• Up to 1024 bytes of dedicated packet buffer memory SRAM (last 256 Bytes are exclusively shared with CAN peripheral)"
<re_irc>
<Rik> : Hah awesome, and thanks for the awesome work :D
<re_irc>
< (@therealprof:matrix.org)> Rik: Glad you like it. Had very little time the last few years though so if you have some love to spare. 😉
<re_irc>
<Rik> Sadly my time (and Rust knowledge) is limited as well 😅
hwj has quit [Remote host closed the connection]
hwj has joined #rust-embedded
<re_irc>
< (@xgroleau:matrix.org)> Is there any gain to use defmt::unwrap!(option) vs option.unwrap() if the panic handler is panic_probe?
<re_irc>
< (@grantm11235:matrix.org)> "option.unwrap()" will pull in a lot of core::fmt bloat
Lumpio- has quit [Ping timeout: 255 seconds]
Lumpio- has joined #rust-embedded
conplan has joined #rust-embedded
hwj has quit [Ping timeout: 240 seconds]
dne has quit [Ping timeout: 264 seconds]
dne_ has joined #rust-embedded
dne_ is now known as dne
conplan has quit [Remote host closed the connection]