<re_irc>
<@9names:matrix.org> you usually don't get crashes from binary size - the flashing tools are smart enough to know it won't fit (or error when it can't write)
<re_irc>
<@dngrs:matrix.org> hm! ok.
<re_irc>
<@dngrs:matrix.org> then I must be doing something fishy with this `static mut`. I do only access it inside `interrupt::free` though 🤔
<re_irc>
<@9names:matrix.org> how much ram do you have? could be copying something and blowing your stack.
<re_irc>
<@dngrs:matrix.org> ah...! that's a good point. I'm putting some big-ish object in the static mut. It did work previously when I was only accessing it on the main fn's stack, so maybe some optimizations can't be done anymore now that it's global
<re_irc>
<@dngrs:matrix.org> (it's a framebuffer)
<re_irc>
<@9names:matrix.org> or maybe you now have two copies? (one on stack, one that's static)
<re_irc>
<@dngrs:matrix.org> hm - I'm only creating it once and it does not implement `Copy`. But I'll check some more
<re_irc>
<@dngrs:matrix.org> yeah, that should be fine. Anyway, I might be doing something super foolish?
<re_irc>
<@grantm11235:matrix.org> I believe line 5 creates `display` on the stack
<re_irc>
<@dngrs:matrix.org> ah DUUUUHH it needs to be moved and for that I need 2x the memory..!
<re_irc>
<@dngrs:matrix.org> (sound of a thousand facepalms)
<re_irc>
<@dngrs:matrix.org> so, mmmh, what can I do?
<re_irc>
<@grantm11235:matrix.org> Try changing line 8 to `DISPLAY = Some(Ssd1331::new(spi, dc, Rotate0));`
<re_irc>
<@dngrs:matrix.org> ... (more facepalms)
<re_irc>
<@grantm11235:matrix.org> I'm not sure if that is guaranteed to work, but you have a much better chance
<re_irc>
<@dngrs:matrix.org> looking a lot better at least!
<re_irc>
<@dngrs:matrix.org> still odd crashes (of a different kind) when I exceed 32kb flash size (omitting those fancy build flags), and it doesn't quite *work* when I'm at 25kb, but hey, at least it starts and logs something
<re_irc>
<@dngrs:matrix.org> thanks folks :)
<re_irc>
<@dngrs:matrix.org> (still not working, but hey, a big step forward. Was banging my head against this for some hours)
troth has joined #rust-embedded
troth has quit [Ping timeout: 260 seconds]
<re_irc>
<@dngrs:matrix.org> whoop whoop, it works!
<re_irc>
<@sympatron:matrix.org> dngrs (spookyvisiongithub): You might want to look at the disassembly to see were formatting code is invoked from. This will probably remove a few kB.
troth has quit [Ping timeout: 256 seconds]
troth has joined #rust-embedded
<re_irc>
<@richarddodd:matrix.org> dngrs (spookyvisiongithub): I'm late to the party, but if you want to format stuff but can't afford the space, then look at `defmt`.
<re_irc>
<@luojia65:matrix.org> Is there anyone working on Freedom U740 chip? I recently received one of its unleashed board, but I don't know how to use its peripherals (the Fu740-hal serial port seems not working)
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> grantm11235:matrix.org: Does this solve it due to creating the variable directly as `static` instead of as a `let` binding in a fn?
<re_irc>
<@firefrommoonlight:matrix.org> So, the variable has to exist in memory twice?
<re_irc>
<@newam:matrix.org> I am looking for the least awful way to do compile time configuration for a library, requiring users to fill in some details about their hardware. C-style "fill in this header".
<re_irc>
<@kinghat:matrix.org> hi, noob here, are the arduino boards(SAMD21) well supported? like the arduino nano33iot and its wifi/bt chips?
<re_irc>
<@newam:matrix.org> kinghat:matrix.org: This is a big question 😅
<re_irc>
<@newam:matrix.org> "Arduino" can refer to many different CPU types. The AVR based CPUs are not as well supported (Arduino Uno) as a compile target. The SAMD21 you mentioned has an ARM Cortex-M0+, which is very well supported as a compile target.
<re_irc>
<@firefrommoonlight:matrix.org> On the surface it seems that Rust support is only good for a few embedded platforms, but so many MCUs use Cortex-M, it doesn't feel like a limitation!
<re_irc>
<@firefrommoonlight:matrix.org> I'm excited about trying the Risc stuff in the future
<re_irc>
<@firefrommoonlight:matrix.org> The cortex m libs and Knurling tooling make the experience nice
<re_irc>
<@firefrommoonlight:matrix.org> Along with SVD2Rust
<re_irc>
<@firefrommoonlight:matrix.org> And patching system
<re_irc>
<@kinghat:matrix.org> ive never worked with rust or hardware and was looking for a place to start and i liked the idea of arduino boards
troth has quit [Ping timeout: 256 seconds]
<re_irc>
<@newam:matrix.org> That's a lot of new things at once :)
<re_irc>
<@newam:matrix.org> embedded is difficult in general (even with C), I would recommend doing some general rust introductions ([rustlings](https://github.com/rust-lang/rustlings) is excellent) to get familiar with the language.
troth has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
<re_irc>
<@dkhayes117:matrix.org> kinghat:matrix.org: I would go with the micro:bit v2 board instead of arduino.
<re_irc>
<@kinghat:matrix.org> also, what about esp32?
troth has quit [Ping timeout: 268 seconds]
<re_irc>
<@newam:matrix.org> There has been some newly added support for those - I'm not sure where it is at these days, but I know it is possible.
<re_irc>
<@newam:matrix.org> If you're interested in wireless the Nordic products (NRF) are well loved around here.
<re_irc>
<@kinghat:matrix.org> ok thanks for the advice all 🙏
<re_irc>
<@robyoung:matrix.org> And the micro:bit V2, which dkhayes117 just mentioned, is based on an NRF52833
<re_irc>
<@firefrommoonlight:matrix.org> Nordic has very nice docs and Reg API, although the docs are almost terse to a fault
<re_irc>
<@firefrommoonlight:matrix.org> They're a bit specialized for low power RF applications
<re_irc>
<@firefrommoonlight:matrix.org> Great in that domain
<re_irc>
<@jessebraham:matrix.org> kinghat:matrix.org: Still very much a work in progress, but we're progressing reasonably fast. You can check out our organization for more details:
<re_irc>
<@jessebraham:matrix.org> Support using `no_std` is fairly limited but if you are willing to use `std` then most things are working, Wi-Fi included, as long as you use our compiler fork
<re_irc>
<@firefrommoonlight:matrix.org> They have all the standard peripherals, so this won't limit you for learning
<re_irc>
<@firefrommoonlight:matrix.org> I'm about to launch a product using Nrf-52
<re_irc>
<@dkhayes117:matrix.org> I mentioned yesterday about looking for an embedded system topic for my thesis. I came across ultra wide-band wireless tech (uwb) yesterday and found it really interesting. Has anyone here messed with it any?
<re_irc>
<@firefrommoonlight:matrix.org> Sounds fun
<re_irc>
<@dkhayes117:matrix.org> It is low-power enough to not require any FCC licensing and is in a frequency range that wouldnt have any inteference from other devices.
troth has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> ooh mesh networking with uwb would be a cool idea
<re_irc>
<@firefrommoonlight:matrix.org> Newam and someone else has been messing with Stm's lOrA chip,
<re_irc>
<@firefrommoonlight:matrix.org> Which I think is considered "wide band"
<re_irc>
<@dkhayes117:matrix.org> Instead of using modulation, it uses 2ns pulses for data transfer. It is super accurate for time of flight stuff, but has range limitations
<re_irc>
<@dkhayes117:matrix.org> I think realistic range is 80m
<re_irc>
<@dkhayes117:matrix.org> The power usage for this is only like 1mW
<re_irc>
<@dkhayes117:matrix.org> I have a galaxy note 20 ultra which has built in uwb support. It can be used for things like indoor localization
<re_irc>
<@diondokter:matrix.org> Uwb is super cool!
<re_irc>
<@diondokter:matrix.org> The dw1000 crate is also pretty complete now if you want to do tdoa
<re_irc>
<@dkhayes117:matrix.org> The freq range is 3.1 to 10.6 Ghz with bandwidths over 500Mhz.
<re_irc>
<@diondokter:matrix.org> I know, because I made such a system
<re_irc>
<@dkhayes117:matrix.org> Basically jusy noise for other protocols
<re_irc>
<@dkhayes117:matrix.org> Oh wow there is a rust crate for it! Awesome
<re_irc>
<@diondokter:matrix.org> Well, for that chip, yes!
<re_irc>
<@diondokter:matrix.org> And there's also a BSP crate for the Dwm1001c module
<re_irc>
<@dkhayes117:matrix.org> I saw nxp has a sr150 dev kit but it is €1600!
<re_irc>
<@diondokter:matrix.org> Yeah, I've searched and you can't even buy the chips anywhere yet
<re_irc>
<@dkhayes117:matrix.org> The dwm sounds tempting
<re_irc>
<@diondokter:matrix.org> They look really nice
<re_irc>
<@kinghat:matrix.org> jessebraham:matrix.org: std vs no-std
<re_irc>
<@dkhayes117:matrix.org> diondokter: what was the use case for your uwb project ( if you can say)
<re_irc>
<@jessebraham:matrix.org> Using the standard library (`std`) we have basically used `esp-idf` as an "operating system" so that you are able to use most features as expected.
<re_irc>
<@jessebraham:matrix.org> `no_std` is the "bare metal" approach with no such underlying "operating system", and as such not all language features are available but it's technically more efficient
<re_irc>
<@jessebraham:matrix.org> You could probably write a book on the differences (and maybe somebody has) but that's kind of the gist of it
<re_irc>
<@jessebraham:matrix.org> This will probably help:
<re_irc>
<@diondokter:matrix.org> So I don't work there anymore because they cancelled the project. There was a big factory and a lot of packages of which we wanted to know the exact location.
<re_irc>
<@diondokter:matrix.org> So in the end I created a system where there were anchors on the walls and ceilings. They would synchronize the time to each other with about half a nanosecond precision just using UWB.
<re_irc>
<@diondokter:matrix.org> The tags in the packages then can send their messages and with the tdoa calculations on the server we'd know the locations.
<re_irc>
<@diondokter:matrix.org> This worked great in the end in my bedroom if the tag had line of sight with all 4 anchors. A lot of iterations were done to get to that point.
<re_irc>
<@diondokter:matrix.org> Oh, bedroom precision was around 40-ish cm in good conditions (and in 3D)
<re_irc>
<@diondokter:matrix.org> And I know I could've made that even better, but oh well
<re_irc>
<@dkhayes117:matrix.org> Nice. Sounds like something definately worth considering. Just ordered 2 dwm1001c modules. Any other hardware I should consider with it?
<re_irc>
<@diondokter:matrix.org> Just first try to set up some ranging with the two. You can't do TDOA with them because you probably need some custom clocking with that. But a good ~10cm accurate ranging should be possible
<re_irc>
<@diondokter:matrix.org> Oh and you need to be able to flash them, so make sure you have a probe that can flash nordic chips
<re_irc>
<@dkhayes117:matrix.org> I have the probe-rs one
<re_irc>
<@diondokter:matrix.org> Ah, have not tried it, but should work
<re_irc>
<@dkhayes117:matrix.org> I'm meeting my committee chair Monday for the first time, starting my thesis next semester. 😁 I'll see what he says about the UWB stuff.
<re_irc>
<@dkhayes117:matrix.org> Thanks for the insight
<re_irc>
<@diondokter:matrix.org> Good luck!
troth has quit [Ping timeout: 240 seconds]
troth has joined #rust-embedded
<re_irc>
<@wucke13:matrix.org> Is there any way of creating an array of analog pins on stm32? `erase()` seems to loose the adc channel information, thus the resulting array is not usable in the adc anymore.
<re_irc>
<@ryan-summers:matrix.org> I don't know of a way given the typestate implementation of most HALs. The best approach is to wrap all your pins in an enum containing the actual type
<re_irc>
<@ryan-summers:matrix.org> Or you could modify the HAL such that when you pass it an ADC pin, it gives you some generic ADC Channel struct enum
<re_irc>
<@ryan-summers:matrix.org> That allows you to measure using said enum
<re_irc>
<@wucke13:matrix.org> That's certainly a possiblity. Is there anything on the horizon for rust which goes in the direction of compile time loop unrolling like [in zig](https://kristoff.it/blog/what-is-zig-comptime/)
<re_irc>
<@grantm11235:matrix.org> 3. Store display in static
<re_irc>
<@grantm11235:matrix.org> 1. Enter critical section
<re_irc>
<@grantm11235:matrix.org> In the second case, the compiler is allowed to combine steps 2 and 3 to create the display directly in the static. The compiler is not allowed to do that optimization in the first case because that would require moving something into or out of the critical section.
<re_irc>
<@ryan-summers:matrix.org> AFAIK compiler optimizations like that are only allowed in const-fns, or are otherwise resolved for optimization by the compiler
<re_irc>
<@ryan-summers:matrix.org> Since rust uses LLVM as a backend, I imagine LLVM handles loop unrolling etc. I think you can hint functions to unroll though?
<re_irc>
<@ryan-summers:matrix.org> But in general, the compiler can often know better than you on whether or not to unroll loops etc. and likely does so for smaller loops already
<re_irc>
<@grantm11235:matrix.org> There have been a few proposals/RFCs that would allow you to loop over a tuple of `impl AdcPin`s for example
<re_irc>
<@firefrommoonlight:matrix.org> Would accessing the static later, eg in an ISR, cause the same duplication?
<re_irc>
<@firefrommoonlight:matrix.org> Btw, I've hit this issue before, or something similar. Big display buffer can't be stored as a static, and *only* worked locally
<re_irc>
<@firefrommoonlight:matrix.org> Seems opposite, but is perhaps the same issue
<re_irc>
<@wucke13:matrix.org> Hmm, I'm imaging something else here, rather than plain loop unrolling (coming back to the analog pins :D )
<re_irc>
<@wucke13:matrix.org> Considering that I have a set of types with a known size, and a common interface (e.g. all implement a specific function), I would like to be able to write code for which iterates over them like over elements of an array. However, the code is unrolled at compile time to the rather repetitive
<re_irc>
<@grantm11235:matrix.org> Once it is in the static it will stay there unless it is moved or copied out
<re_irc>
<@firefrommoonlight:matrix.org> So I worked around it by doing all display ops in a superloop, then sending it flags in ISRs.
<re_irc>
<@firefrommoonlight:matrix.org> Nice. So, accessing the static via RTIC or a CS wouldn't cause teh dup?
<re_irc>
<@firefrommoonlight:matrix.org> Or an unsafe block if using neither
<re_irc>
<@richarddodd:matrix.org> I'm very much a newb, but it seems more organized to do to do as little as possible in ISRs: just flag stuff for the main loop to handle. Of course you can't do this when something **must** happen by a certain time (e.g. make someone's heart beat using a pacemaker) if your main loop doesn't have enough determinism, but if you don't have this requirement you get more control over how things happen and in...
<re_irc>
... what order. And it's easier to keep track of all the different states your data can be in
<re_irc>
<@firefrommoonlight:matrix.org> Completely to taste
<re_irc>
<@firefrommoonlight:matrix.org> I generally prefer the opposite!
<re_irc>
<@firefrommoonlight:matrix.org> I think it depends on the problem
<re_irc>
<@dngrs:matrix.org> richarddodd:matrix.org: thx! I already am :D not quite sure what's causing the actual bloat. Either way, turned out my problem was a memory one (still observing odd crashes when using `flip-link`; it seems to work fine without? somewhat creepy)
<re_irc>
<@richarddodd:matrix.org> dngrs (spookyvisiongithub): yeah embedded is hard :)
<re_irc>
<@adamgreig:matrix.org> if it crashes with flip-link and works fine without it, you're probably overflowing your stack into some statics and overwriting them and just not noticing
<re_irc>
<@adamgreig:matrix.org> the behaviour of flip-link is to turn silent memory corruption into noticable crashes
<re_irc>
<@richarddodd:matrix.org> I was just reading about flip-link and it looks really useful!
<re_irc>
<@adamgreig:matrix.org> it's the sort of thing you'd think linkers should just already be able to do, huh?
<re_irc>
<@adamgreig:matrix.org> in some cortex-m you can set up the memory protection unit to generate faults if you overflow the stack too but it's faffier and in some sense not as reliable
<re_irc>
<@dngrs:matrix.org> sympatron:matrix.org: that's a good idea. I have very little experience with inspecting disassembly. Any tools I should be checking out on top of a raw hexdump? 😬
<re_irc>
<@richarddodd:matrix.org> Are there any tools that will calculate an upper bound on stack usage? Obviously it won't be very accurate, but if you only have e.g. one function you can get an exact answer. If you have a recursive function you're on your own.
<re_irc>
<@richarddodd:matrix.org> dngrs (spookyvisiongithub): `cargo-asm` I think is really great
<re_irc>
<@richarddodd:matrix.org> not sure if it comes with `cargo` or is separate
<re_irc>
<@dngrs:matrix.org> adamgreig: I thought the same; however: the only static I have is a framebuffer which I'm constantly blitting onto a display and it all looks just dandy & never crashes. Odd.
<re_irc>
<@adamgreig:matrix.org> maybe there are some other statics you're not creating directly, like the RTT buffer?
<re_irc>
<@dngrs:matrix.org> but I do agree, my gut feeling is also I'm merely overwriting a part of my memory that never gets hit hard enough
<re_irc>
<@dngrs:matrix.org> richarddodd:matrix.org: checking it out, thx!
<re_irc>
<@adamgreig:matrix.org> if you're using rtt the default macro makes a few kB of static buffer
<re_irc>
<@dngrs:matrix.org> while we're at it, how would I go about analyzing general ram usage?
<re_irc>
<@dngrs:matrix.org> apart from statics
<re_irc>
<@newam:matrix.org> Some cores have fancy hardware debug capabilities for that (HSSTP on the Cortex-A's), I forget if any Cortex-M's offer something here. Otherwise sampling the usage in the code at a few key points works.
<re_irc>
<@adamgreig:matrix.org> the links I pasted above about static analysis go some of the way to showing what stack usage might be
<re_irc>
<@adamgreig:matrix.org> beyond statics you're basically just talking about stack though, you could poll the stack counter with probe-rs and hope to catch the extremes, single-step through risky parts and watch it, there are some other tricks
<re_irc>
<@dngrs:matrix.org> `cargo-binutils` not quite getting it right:
<re_irc>
<@dngrs:matrix.org> No such file or directory (os error 2)```
<re_irc>
<@dngrs:matrix.org> ```Failed to execute tool: nm
<re_irc>
<@dngrs:matrix.org> I do have `arm-none-eabi-nm` though. Oh well
<re_irc>
<@adamgreig:matrix.org> you can fill the whole ram with a pattern like 0x55555555 and then dump the ram after a few hours running and see how far you overwrote the pattenr
<re_irc>
<@newam:matrix.org> dngrs:matrix.org: I get that too. There's a multiarch clang nm that works for almost everything. How to install it will depend on your distro.
<re_irc>
<@dngrs:matrix.org> how would I sample the stack?
<re_irc>
<@dngrs:matrix.org> I guess I'll just stick to `arm-none-eabi-nm`
<re_irc>
<@adamgreig:matrix.org> not sure there's any simple answer to give you beyond "write a short rust program that uses the probe-rs library to connect to your target via a debug probe, and occasionally reads the SP register"
<re_irc>
<@adamgreig:matrix.org> i.e. afaik it's not written yet
<re_irc>
<@dngrs:matrix.org> adamgreig: how do I configure it to use less?
<re_irc>
<@adamgreig:matrix.org> otherwise depends how you're initialising rtt
<re_irc>
<@adamgreig:matrix.org> the macros all take buffer sizes I think
<re_irc>
<@newam:matrix.org> dngrs:matrix.org: I don't know a ton about mac, but if you're using nixpkgs it should be `nix-env -iA nixpkgs.llvmPackages_12.bintools-unwrapped`.
<re_irc>
<@dngrs:matrix.org> adamgreig: inspect SP register, alrighty! Sounds like a fun project
<re_irc>
<@dngrs:matrix.org> newam:matrix.org: thx! I'm not though. All good
<re_irc>
<@adamgreig:matrix.org> `cargo-binutils` _should_ work on macos, so if it doesn't on a fresh install it might be worth opening a bug report on https://github.com/rust-embedded/cargo-binutils (it's one of ours)
<re_irc>
<@wucke13:matrix.org> grantm11235:matrix.org: I know, however I refuse to opt into dynamic polymorphism for ergonomics, when all relevant types are easily known at compile time. Thank you for hint anyways!
<re_irc>
<@dngrs:matrix.org> adamgreig: yeah, I tried `cargo nm` on a native arch `std` project and it also doesn't work, same issue
<re_irc>
<@dngrs:matrix.org> Fresh terminal and everything
<re_irc>
<@yatekii:matrix.org> Wouldn't GDB/Vscode be able to track SP?
<re_irc>
<@adamgreig:matrix.org> yea, I'm sure it can
<re_irc>
<@adamgreig:matrix.org> but if you want to sample it like 10/s and plot the usage/maximum it's a bit boring to try adn do that manually from within gdb I guess?
<re_irc>
<@newam:matrix.org> adamgreig: It doesn't grab the GCC editions of binutils is all, in my experience it only grabs the LLVM binutils, but I am also on a special snowflake linux.
<re_irc>
<@adamgreig:matrix.org> newam: yea, it should use the llvm nm, which should work?
<re_irc>
<@yatekii:matrix.org> ah sorry, yeah I was not reading the whole problem explanation
<re_irc>
<@yatekii:matrix.org> Actually, I did something like that 2 years ago even, so I am sure it works
<re_irc>
<@adamgreig:matrix.org> ah 😅 I don't use defmt, looks like you can't indeed
<re_irc>
<@adamgreig:matrix.org> that's a shame
<re_irc>
<@dngrs:matrix.org> adamgreig: fair 😬 yes, that fixed it!
<re_irc>
<@newam:matrix.org> dngrs:matrix.org: Maybe we should add that as a message upon filenotfound?
<re_irc>
<@yatekii:matrix.org> all you gotta do is `connect(); loop { core.halt(); core.read_core_reg(); core_run(); }`
<re_irc>
<@adamgreig:matrix.org> yea, the #1 reason to not find nm is surely becuase they haven't done it, lol
<re_irc>
<@adamgreig:matrix.org> do you gotta halt the core to read sp?
<re_irc>
<@adamgreig:matrix.org> wonder if you can set up itm to dump sp over swo on a regular basis
<re_irc>
<@yatekii:matrix.org> adamgreig: not on all targets but the spec allows impls that require it
<re_irc>
<@yatekii:matrix.org> adamgreig: I think you can, yes
<re_irc>
<@adamgreig:matrix.org> lots of these sorts of profilers seem like they'd be neat to have
<re_irc>
<@adamgreig:matrix.org> i'd also like something that samples pc at a regular basis and gives a flamegraph or something
<re_irc>
<@yatekii:matrix.org> adamgreig: actually it kind of makes sense for most registers because you always need them in some context and if you just continue running the context is lost after 1 instruction or so. SP is kind of an exception here, but it's a register just like all the others :)
<re_irc>
<@adamgreig:matrix.org> true! but if I just want a non-invasive poll of sp and pc maybe it'd be ok
<re_irc>
<@grantm11235:matrix.org> wucke13:matrix.org: If you think about it, an erased pin is a bit like dynamic polymorphism but with a simple index number instead of a vtable pointer
<re_irc>
<@yatekii:matrix.org> adamgreig: yep would be nice :) actually tmplt is working on tracing for RTIC. I made a GUI that can display all the tasks in a timing diagram. but not much more yet. and it requires ITM.
<re_irc>
<@adamgreig:matrix.org> yea, tmpit's stuff is very cool!
<re_irc>
<@adamgreig:matrix.org> excited for things that make using swo easier too
<re_irc>
<@dngrs:matrix.org> still need to manage to *successfully* solder ITM on one of my cheapo st-link clones
<re_irc>
<@grantm11235:matrix.org> grantm11235:matrix.org: (at least I think it is, I am not an expert at dynamic polymorphism 😁)
<re_irc>
<@adamgreig:matrix.org> but it feels like a simple profiler that can record stack and pc during execution is like an evening's hacking... hmmm
<re_irc>
<@adamgreig:matrix.org> just all the boring plumbing of hooking up command line arguments and probe selection and so on :P
<re_irc>
<@yatekii:matrix.org> the only problem for me atm is that I do not much embedded atm so progress kinda stagnated ...
<re_irc>
<@adamgreig:matrix.org> hehe yea it's hard maintaining stuff when you're not using it atm but a lot of other people sure are
<re_irc>
<@yatekii:matrix.org> I hope that the probe-rs-hive brings more confidence so we can add stuff more agressively and also test it well
<re_irc>
<@yatekii:matrix.org> adamgreig: I mean idk, I feel like I want to but I just end up coding other stuff ... idk how it works ...
<re_irc>
<@adamgreig:matrix.org> i just have to go with whatever my brain is happy working on that day
<re_irc>
<@yatekii:matrix.org> Also, it's kind of just chores when you fix bugs for other folks that direly want to use some broken unsupported core you distain and it works for you :D
<re_irc>
<@adamgreig:matrix.org> would probe-rs-cli-util make it easy to string together a quick cli profiler do you think?
<re_irc>
<@yatekii:matrix.org> adamgreig: same here ^^ I recently ventured into writing my own emailclient ... it was a mistake
<re_irc>
<@adamgreig:matrix.org> or is it quite specific for cargo-flash/embed?
<re_irc>
<@yatekii:matrix.org> can be used for sure :)
<re_irc>
<@yatekii:matrix.org> tmplt and tiwalun refactored it to be more generic and tmplt and the probe-rs-cli use it too nowadays :)
<re_irc>
<@adamgreig:matrix.org> 👀
<re_irc>
<@yatekii:matrix.org> it basically contains all the code to properly build a cargo manifest and get the artifacts and flash a binary with nice progressbars etc. just stuff that doesn't belong in the core lib but is used in UI tools
<re_irc>
<@adamgreig:matrix.org> unfortunately the simple fix for that particular issue is included in a somewhat bigger pr
<re_irc>
<@esden:matrix.org> Hey everyone. I have a question. I am exploring the use of Rust on RISC-V FPGA soft cores with custom peripherals. To make this easier I try to leverage as much of the existing tools and autogenerate as much possible (aka. use svd2rust). Writing svd files is a pain, so I figured out that I can use svdtools to generate them by using `_add` and using a minimal skeleton .svd file. I now have a peripheral that has...
<re_irc>
... a register with a field that has a few predefined values. Perfect candidate for `enumeratedValues`. But as far as I can tell `_add` does not support adding `enumeratedValues`? But I might be missing something. Here is the yaml file I currently have to generate the svd file: https://github.com/icebreaker-fpga/icetwang/blob/main/soc/ice-twang/svd/icetwang-soc.yaml and here is the new file with a non working enum:...
<re_irc>
<@adamgreig:matrix.org> correct, _add only adds "structural" stuff like peripherals, registers, and fields
<re_irc>
<@adamgreig:matrix.org> you then need a second section to add the enumeratedValues
<re_irc>
<@dngrs:matrix.org> adamgreig(please tell me if I'm bothering you with this topic) anything I could check out in terms of SPI blocking vs DMA abstraction?
<re_irc>
<@adamgreig:matrix.org> dngrs (spookyvisiongithub): sorry! not bothering me but i don't really know much about what the various hals are doing here really... a bunch of hals (f4 and h7 for example) have quite solid dma support i believe, so maybe worth checking what they're doing?
<re_irc>
<@adamgreig:matrix.org> esden: so add a new top-level yaml map `UART: CSR: TFFFULL: { Full: [1, "TFF is full"], NotFull: [0, "TFF not full"] }` sort of thing
<re_irc>
<@dngrs:matrix.org> adamgreig: ok, haven't checked back in on them in a while, last time I did it was all manual register manipulation etc - I'm specifically wondering if it's even possible to abstract things so that a driver can take *either* a blocking or a DMA SPI. But I feel my type-fu is inadequate to come up with anything solid there myself
<re_irc>
<@dngrs:matrix.org> maybe I should just take it as a challenge though
<re_irc>
<@esden:matrix.org> adamgreig: Hah... right, I thought I tried it... but I was getting an error. I have found my mistake though. All I needed to add at the bottom of the file was:
<re_irc>
<@dngrs:matrix.org> but also on the other hand don't want to reinvent the wheel
<re_irc>
<@adamgreig:matrix.org> dngrs (spookyvisiongithub): ah yea, not sure... I think mostly the work so far has been making traits for either async (presumably backed by dma) or blocking, but not abstracting over either, e.g. the new embedded-hal has blocking and a PR for async, embassy is all async... the driver might need to care which it's got right?
<re_irc>
<@adamgreig:matrix.org> esden: btw disasm has also done some work on risc-v fpga peripherals, rust, and svd2rust for pacs, if you haven't chatted yet
dsmith has left #rust-embedded [ERC (IRC client for Emacs 27.1)]
<re_irc>
<@esden:matrix.org> adamgreig: good to know. Would definitely be good to exchange notes. :)
<re_irc>
<@adamgreig:matrix.org> i really want to try it one day 😬
<re_irc>
<@dngrs:matrix.org> adamgreig: ah yes, async sounds like the better abstraction layer then! I've been thinking in dma-specific terms like prepare buffer, circular buffers, half transfers etc, but that can probably just become a set of ... callbacks? state enum variants? Something something. Time to do an embassy project I guess, never done async on embedded so far!
<re_irc>
<@adamgreig:matrix.org> async and dma seem like a very natural fit, in theory i guess you could do it with just interrupts too
<re_irc>
<@dngrs:matrix.org> esden: in general I'm very interested in the intersection rust/risc-v/FPGA! I have bought a ULX3S a while ago but it currently just sits there ...
<re_irc>
<@esden:matrix.org> adamgreig: the biggest hope of mine would be to have a mode in svdtools where one could just write a simple yaml file to generate svd files from scratch. Leveraging svdtools the way I do is good enough for now, but it would be nicer if it is slightly more streamlined. :) (I don't use a separate soc generator like litex, so I have to write something by hand.. ;) )
<re_irc>
<@adamgreig:matrix.org> the #embassy-rs:matrix.org room might be a good place to ask about traits abstractions
<re_irc>
<@adamgreig:matrix.org> esden: yea, I've wanted something like that for writing cortex-m core peripheral svds from scratch too
<re_irc>
<@adamgreig:matrix.org> just a convenient dsl for writing svds from scratch
<re_irc>
<@adamgreig:matrix.org> but... just haven't quite needed it enough to tweak the current svdtools syntax for it
<re_irc>
<@esden:matrix.org> fair enough I figured ... there are a lot of TODOs :)
<re_irc>
<@adamgreig:matrix.org> the majority of what i use svdtools for is patching existing bad svds where it's quite nice to separate the structural changes from the enumerated values
<re_irc>
<@adamgreig:matrix.org> hehe yep always
<re_irc>
<@adamgreig:matrix.org> the whole thing has gotten a bit out of control compared to the very quick and dirty script it started as to solely add enumerated values to like two svd files
<re_irc>
<@esden:matrix.org> in any case ... svdtools did save me a ton of time having to develop something new
<re_irc>
<@esden:matrix.org> so thanks
<re_irc>
<@dngrs:matrix.org> adamgreig: jamesmunnsmaybe relevant to your interests
<re_irc>
<@esden:matrix.org> I might come around to contribute a "create?" mode or something... :))
<re_irc>
<@adamgreig:matrix.org> Maybe just _add could support enums too, would be a fairly simple addition
<re_irc>
<@esden:matrix.org> yeah that is probably simpler thing to add firstt
<re_irc>
<@grantm11235:matrix.org> dngrs (spookyvisiongithub): Keep in mind that you can also use dma to implement the blocking spi traits. Just start the dma and then busy-loop until it is finished. You won't get the possible concurrency benefits of async, but you might get a higher throughput
<re_irc>
<@ryan-summers:matrix.org> In SPI, your bottleneck is not the CPU, but rather the SPI bus being busy I would imagine
<re_irc>
<@ryan-summers:matrix.org> You'd only use DMA if you want to kick off the transaction and then have the CPU do _other_ things other than busy loop
<re_irc>
<@dngrs:matrix.org> ryan-summers:matrix.org: yeah, I'm definitely bottlenecking on the SPI. On the other hand I don't have enough memory for double buffering anyway, so hm. Would probably need to do some clever "don't outrun the buffer filling while it's getting DMA's out" thing. Although frame tearing *might* be OK
<re_irc>
<@grantm11235:matrix.org> You could split your buffer in half and update one half while the other half is being dma'd out
<re_irc>
<@dngrs:matrix.org> might help, might not - the data I'm putting into the buffer comes in via UART and the way I've set this up I can't easily apply backpressure
<re_irc>
<@dngrs:matrix.org> might need to set up some kind of framing, currently it's literally just pixels back to back (aka, no start-of-frame marker or anything)
<re_irc>
<@dngrs:matrix.org> works surprisingly well
<re_irc>
<@grantm11235:matrix.org> If you only start dma'ing the next half once you are done updating it, that will give you your backpressure
<re_irc>
<@grantm11235:matrix.org> But if it takes you too long to update the second half, you would effectively have a tear in the middle of the screen
<re_irc>
<@dngrs:matrix.org> yeah, I guess in that case it's just a question of "do I tear exactly in the middle or at some random point", which probably doesn't gain me *much*. Anyway, all just theories that remain to be tested!
<re_irc>
<@firefrommoonlight:matrix.org> grantm11235:matrix.org: To do this, make the buf twice the size, enable half and full transfer interrupts, and offset the index with 0, or data size depending on which occured
<re_irc>
<@grantm11235:matrix.org> I think that a regular tear is a bit worse because you need to update the whole screen before the old image at the bottom goes away
starblue has quit [Ping timeout: 268 seconds]
<re_irc>
<@gauteh:matrix.org> has anyone tried to write a flash algorithm in rust?
<re_irc>
<@adamgreig:matrix.org> like for probe-rs?
<re_irc>
<@adamgreig:matrix.org> i've seen others but don't remember where right now
<re_irc>
<@gauteh:matrix.org> Thanks, this is very useful
<re_irc>
<@gauteh:matrix.org> somehow nothing is written to flash, and maybe the flash algorithm checks something special
<re_irc>
<@gauteh:matrix.org> i don't know if it is realistic, but i hope to debug the flash algo over uart..
<re_irc>
<@gauteh:matrix.org> probe-rs / probe-run now works to the degree that if I flash the program using another bootloader, and then use probe-run with flashing it thinks all is well and reset of probe-run works... so I guess that works for now..
<re_irc>
<@gauteh:matrix.org> but nothing probe-rs tries to write to flash actually gets there, flash is unchanged (tried with loader.add_data and reading back). sometimes flash is garbled though.
<re_irc>
<@adamgreig:matrix.org> weird :/ could be some flash protection is active? or some specific sequence that needs to run (which the flash loader should take care of..)?
<re_irc>
<@gauteh:matrix.org> Yes, I found some JLink scripts buried in a repo, and modified probe-rs reset_and_halt accordingly: that took care of probe-rs crashing when trying to reset_catch_set + reset_system, which needs to be done in a particular way. this does result in a secure bootloader going into a loop. maybe there is something additional that needs to be done by the debugger / flash loader.
<re_irc>
<@gauteh:matrix.org> It's also essential to delay after writing AIRCR_ADDR before reading DHCSR
starblue has joined #rust-embedded
starblue has quit [Client Quit]
starblue has joined #rust-embedded
<re_irc>
<@dngrs:matrix.org> firefrommoonlight:matrix.org: unfortunately I'm already out of memory with a single buffer
<re_irc>
<@dngrs:matrix.org> but yeah, in theory, yep
troth has quit [Ping timeout: 260 seconds]
<re_irc>
<@grantm11235:matrix.org> Are you using one of those monochrome oleds? You could shrink the size of the framebuffer to only 8 lines, but then you could only draw to those 8 lines at a time.
<re_irc>
<@grantm11235:matrix.org> Those displays are annoying because you can't just update a single pixel, you need to update a vertical group of 8 pixels
troth has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> It's a full color
<re_irc>
<@firefrommoonlight:matrix.org> 96x64x6 / 8 bit buffer
<re_irc>
<@firefrommoonlight:matrix.org> There are cheats though
<re_irc>
<@firefrommoonlight:matrix.org> Like use its drawing primitive commands