<diondokter[m]>
I've not removed the feature, but optimized the code a bit
<diondokter[m]>
If that's not good enough, then I'll make it so you can turn off the feature entirely
AshconMohseninia has joined #rust-embedded
<AshconMohseninia>
random question, for embassy's tick rate, what should be a recommended value based on CPU Speed (If any)?
vancz has joined #rust-embedded
mameluc[m] has joined #rust-embedded
<mameluc[m]>
<AshconMohseninia> random question, for embassy's tick rate, what should be a recommended value based on CPU Speed (If any)?
<mameluc[m]>
I don't 100% understand the question. Are you talking about maximum tick rate for Ticker from embassy-time?
<JamesMunns[m]>
<AshconMohseninia> random question, for embassy's tick rate, what should be a recommended value based on CPU Speed (If any)?
<JamesMunns[m]>
In case this is a terminology mixup: embassy doesn't have a "scheduler tick" like an rtos. The embassy time tick rate only affects the precision of the Instant timer values. e.g. at 1mhz, you have 1us precision.
<JamesMunns[m]>
JamesMunns[m]: The two most common values are 32.768khz (usually fed by a lower power lfclk) or 1mhz (usually pretty easy to handle in most hardware timers)
<AshconMohseninia>
<JamesMunns[m]> In case this is a terminology mixup: embassy doesn't have a "scheduler tick" like an rtos. The embassy time tick rate only affects the precision of the Instant timer values. e.g. at 1mhz, you have 1us precision.
<AshconMohseninia>
Oh, so then in theory, it would be possible to set something as fast as your CPU speed? (EG 120Mhz)
<JamesMunns[m]>
AshconMohseninia: Yes, though embassy-time needs an interrupt every 1/2 the range of your timer. On a 32-bit timer at 120mhz, that's every 17.9s, on a 16-bit timer that's every 273us.
<JamesMunns[m]>
JamesMunns[m]: So, yes, in theory, it would be a bad idea if you aren't using a 32-bit timer in 32-bit mode to back embassy-time though. Even a 24-bit timer would require a timer interrupt every 70ms or so.
<AshconMohseninia>
which on another note im suprised isn't a part of embassy
<JamesMunns[m]>
Systick is... not a great timer
<AshconMohseninia>
really? Why not
<JamesMunns[m]>
IMO it's worth using a hardware-specific timer in most cases.
<AshconMohseninia>
but having a systick timer would be best for hardware support across all Cortex-M devices, HALs can implement an additional timer if they see fit
<JamesMunns[m]>
IIRC it's fairly bound to your CPU's frequency, it only has 24 bit resolution, it's not actually required everywhere, and I think there are some other quirks when it comes to timer interrupts, e.g. you have to stop and restart it, which will lose ticks? I never use it, so I don't remember all the quirks off the top of my head
<AshconMohseninia>
JamesMunns[m]: that is true i guess, but unless you are doing dynamic clocking, that isn't an issue. And yeah, i guess dueing the systick exception, you will loose some ticks
<AshconMohseninia>
s/dueing/during/
<JamesMunns[m]>
Like, you totally can use systick everywhere, but it's going to be Equally Not Great everywhere.
<JamesMunns[m]>
where nearly every MCU is going to have a timer with a driver you can use for embassy time-driver
<AshconMohseninia>
true
<dirbaio[m]>
<diondokter[m]> Guinea Wheek: Could you try out this branch and see if the compile times are now acceptable?...
<dirbaio[m]>
coherence doesn't look at function bodies, you won't fix it by optimizing function bodies
<dirbaio[m]>
dirbaio[m]: i'm surprised it's slow though, I don't see complex impls in the generated code :o
<JamesMunns[m]>
<diondokter[m]> Guinea Wheek: Could you try out this branch and see if the compile times are now acceptable?...
<JamesMunns[m]>
It's worth reporting these upstream as "unexpectedly slow", it's possible there just wasn't a perf test already that would have caught this kind of "accidentally quadratic" behavior
<JamesMunns[m]>
I wonder if it gets faster if you add in -Znext-solver
<JamesMunns[m]>
Ah, that's only put on some "hangs" issues, not "is just slow" issues
<dirbaio[m]>
I think coherence is inherently quadratic by design...
<diondokter[m]>
<JamesMunns[m]> It's worth reporting these upstream as "unexpectedly slow", it's possible there just wasn't a perf test already that would have caught this kind of "accidentally quadratic" behavior
<diondokter[m]>
Good point!
<dirbaio[m]>
like, in the general case it has to check every pair of impls and try to prove they don't overlap
<diondokter[m]>
What's also fun is that I format the output code using rustfmt.
<diondokter[m]>
It doesn't succeed because it stackoverflows
<diondokter[m]>
* it stackoverflows (on the current master branch)
<diondokter[m]>
* it stackoverflows (on the current master branch) on the repro
<diondokter[m]>
Idk why because the generated file is 'only' 12k lines with a boatload of whitespace
<vollbrecht[m]>
<jesse-de-loore[m> Hi guys. I'm embarking on my first embedded adventure. It's been a lot of fun....
<vollbrecht[m]>
for esp specific question its best to ask directly on #esp-rs:matrix.org . In this particular case not sure how the author is providing the environement. But by default you need to set ESP_IDF_VERSION and MCU version somewhere to influence it in here. In general we put it in the [env] section inside the .cargo/config.toml file
<vollbrecht[m]>
vollbrecht[m]: And yes if the library is using that field you would need ESP_IDF_VERSION > 5.2
<vollbrecht[m]>
vollbrecht[m]: by not providing it some older ESP_IDF version will be picked by default iirc
<Assatadajamante[>
I had so much fun with ariel-os that I forgot the time 😆
<jesse-de-loore[m>
vollbrecht[m]: Thanks. When I do that I get:
<jesse-de-loore[m>
Tool doesn't match supported version from list ['esp-13.2.0_20240530']
<jesse-de-loore[m>
Which leads me to think there are other things I should change as well
fstracke has joined #rust-embedded
<jesse-de-loore[m>
jesse-de-loore[m: MCU is esp32 (esp32-A1S audio kit V2.2 436
<Assatadajamante[>
Can't wait to test on more platforms and tell friends
<vollbrecht[m]>
jesse-de-loore[m: did you set any other specific env variables or did you have a C esp-idf install lingering in your shell?
<vollbrecht[m]>
Otherwise you can just nuke the .embuild dir in your project and make a clean build. It should repopulate it for you correctly then
<jesse-de-loore[m>
vollbrecht[m]: sure. I didnt set this initially It was generated as part of a template. Let me try nuking .embuild
<fstracke>
Hey Everyone! I wanted to inquire about the current maintainer status of the aarch64-cpu crate. There seems to have been only little activity over the last few months (which is no problem, please don't get me wrong!) and I am interested to amend the crate with more registers (especially SP_EL{2,3}).
<thejpster[m]>
aarch64-cpu is maintained by the working group's Arm Team.
<thejpster[m]>
I think the easiest way to show a reviewer that the changes work, is to have a test that runs in QEMU and shows that they work. At least, that's the approach we take for the AArch32 cortex-ar crate.
<fstracke>
Okay, thank you! Knowing who to contact is already half the deal. Again, thank you so much!
<AshconMohseninia>
<JamesMunns[m]> Like, you totally can use systick everywhere, but it's going to be Equally Not Great everywhere.
<AshconMohseninia>
true, but i noticed that RTIC has a built-in systick driver, so it works out of the box on more setups rather than waiting for HALs to implement their own time drivers. Also, AFIK, systick does not pause during servicing, but i might be wrong
<dirbaio[m]>
the problem with systick is it requires an interrupt at every tick
<dirbaio[m]>
like, if you set it at 1mhz you will actually have 100000 interrupts per second which will steal a lot / all of the cpu cycles away from your app
<dirbaio[m]>
if you set it at a more reasonable 1khz then you only have a precision of 1ms
<dirbaio[m]>
with embassy-time you can set the timer to go at 1mhz but it won't actually spam interrupts at that rate, it'll set a compare to fire an interrupt at the next expiration. so you get high precision without the interrupt spam.
<thejpster[m]>
systick is designed to run a ~100 Hz timer for pre-emptive scheduling of threads
<thejpster[m]>
modern embedded stacks run tickless (set an interrupt for the future instant at which the next event needs to happen) which systick is not good at
<AshconMohseninia>
yh
<thejpster[m]>
the RTIC monotonic emulates a tickless timer by making systick fire interrupts really really often.
<AshconMohseninia>
one last question then. If you are setting up embassy-time at runtime using a timer running at any potential frequency, is there a way to set the tick-rate up dynamically rather than using a feature?
<JamesMunns[m]>
<dirbaio[m]> the problem with systick is it requires an interrupt at every tick
<JamesMunns[m]>
The benefit that embassy-time has is that it has sub-interrupt precision by reading the current count values between interrupts
<firefrommoonligh>
And I guess a third approach is just using the RTC if equipped
<JamesMunns[m]>
<dirbaio[m]> the problem with systick is it requires an interrupt at every tick
<JamesMunns[m]>
so you can still get 1us precision for a timer interrupt that only fires every hour or whatever.
<firefrommoonligh>
Nice
<firefrommoonligh>
JamesMunns[m]: Yea exactly; that's what I do as well. Overflow count + counter val
<JamesMunns[m]>
Basically, it fires an interrupt every 1/2 of the range of the timer so you can reliably avoid wrapping cases.
<firefrommoonligh>
* counter val * overflow count, paraphrased
<firefrommoonligh>
* Yea exactly; that's what I do as well. Overflow count + counter val
<firefrommoonligh>
That sounds like a nice improvement
<JamesMunns[m]>
Yeah! AFAIK it's to enable cases where you want to get the current time in an interrupt, and the "tick" interrupt hasn't had a chance to run but the timer HAS rolled over
<JamesMunns[m]>
so if you've seen the "halfway tick", but the timer is < 1/2 the range, you know you implicitly need to add another tick
<JamesMunns[m]>
that way, you can say "we handle delayed tick interupts, as long as it is not delayed MORE than 1/2 the range of the timer"
<firefrommoonligh>
I should probably do that. How do you get the interrupt to fire at 1/2 range? Is that available on certain MCUs?
<JamesMunns[m]>
which is usually a pretty substantial amount of times.
<JamesMunns[m]>
firefrommoonligh: most timers have multiple compare and capture registers
<firefrommoonligh>
Ah yea that sounds familiar. Knowledge gap here
<JamesMunns[m]>
firefrommoonligh: so you can make it fire interrupts at say `0x8000` on a 16-bit timer, as well as on the "wrap" point
<JamesMunns[m]>
you could check out the nrf52 or stm32 embassy-time-driver impls
<JamesMunns[m]>
s/times/time/
<JamesMunns[m]>
or: use embassy-time :D
<firefrommoonligh>
Nice, that sounds more robust than just the overflow
jfsimon has joined #rust-embedded
<KevinPFleming[m]>
Many of the Embassy crates are really well thought-out designs, it's been a pleasure learning about them (and supports my decision to use them) :-)
fstracke has quit [Ping timeout: 272 seconds]
<JamesMunns[m]>
I think it helps a lot that there are a lot of people actively using them, giving feedback, and contributing back to them. A lot of them have improved a lot, the more people and platforms that are using them.
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
Silly question: suppose you have a mutable static structure that is 16kb large called `BufferStateMachine` that has 10 fields.
<jason-kairos[m]>
If one field contains initialized data, is a copy of the entire structure supposed to reside in .rodata/.data?
jfsimon has joined #rust-embedded
<JamesMunns[m]>
idk about "supposed to", but the general answer is yes
<JamesMunns[m]>
right now, an item is either in data or bss, it can't be part in both
<JamesMunns[m]>
so if ANY subpart needs to be non-zero initialized, it's in .data, not bss, which means the WHOLE thing gets initialized from flash
<jason-kairos[m]>
That explains why I was confused. I thought it was per field.
<jason-kairos[m]>
Would per field initialization even make sense in rust?
<JamesMunns[m]>
it would require a much more complicated startup/crt0 behavior
<JamesMunns[m]>
I don't think it would make sense without a lot of design.
<jason-kairos[m]>
* in rust? (ie. initialize the one field to the non-zero value, leave the rest zero)
<JamesMunns[m]>
in general, most of the time you want to use stuff like MaybeUninit::uninit and have an explicit init step
<jason-kairos[m]>
I guess the root cause is that structures are contiguous memory. So to avoid that, use references or pointers.
<jason-kairos[m]>
* or pointers to separate ., * .data and .bss fields.
<jason-kairos[m]>
(side remark: I've never used MaybeUninit in any of my drivers, most of the more complicated ones do unsafe pointer stuff on plain old u8 arrays)
<jason-kairos[m]>
* plain old zero initialized u8 arrays)
<JamesMunns[m]>
it's a useful tool, it's not mandatory though
<jason-kairos[m]>
* or pointers to separate ., * .data and .bss fields into two different structures.
sroemer has quit [Ping timeout: 240 seconds]
<JamesMunns[m]>
It's useful for cases where you have runtime init of a static, you can put the contents in a `MaybeUninit`, which makes const construction easy because `MaybeUninit::uninit` is const, and then you can use an atomic to track `UNINIT`/`INITIALIZING`/`INITIALIZED`, etc.
<vollbrecht[m]>
yes the correct xtensa c compiler and all other things necessary gets pulled in into the .embuild dir, with the correct version depending on what ESP_IDF_VERSION is choosen. The only thing where this can go wrong is if your current env does defines overrides.
<jason-kairos[m]>
additional question: sometimes it seems like the compiler will put structures containing 100% zero initialized stuff into .rodata/.data?
<jason-kairos[m]>
Is there some set of rules dictating that?
fstracke has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
fstracke has quit [Ping timeout: 252 seconds]
Tidur has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<GuineaWheek[m]>
<dirbaio[m]> i'm surprised it's slow though, I don't see complex impls in the generated code :o
<GuineaWheek[m]>
that branch seems to fix it
<GuineaWheek[m]>
GuineaWheek[m]: diondokter: ^^^
<diondokter[m]>
GuineaWheek[m]: Thanks for checking!
<diondokter[m]>
Don't know if you read the rest of the thread, but it seems to be a compiler bug.
<diondokter[m]>
For now I'll just merge that branch and create a release (probably tomorrow)
<adamgreig[m]>
ok, let's start! no announcements from me this week I don't think, anyone else?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Just finishing a spellcheck pass on the next round of MB2 Disco Book changes. Thanks huge to the folks who provided feedback and corrections. I'll post a rollup shortly, and folks can have one more chance to look before we merge.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
bartmassey[m]: The interrupt chapter?
<bartmassey[m]>
Yes, and the polling chapter.
<therealprof[m]>
Great. Looking forward to it.
<bartmassey[m]>
The last major missing piece is the DMA chapter. I'm starting to think about that now. If anyone wants to help with code or text, please let me know.
<bartmassey[m]>
This may involve changes to the nrf-hal and microbit crates.
<JamesMunns[m]>
Happy to chat about it
<bartmassey[m]>
Cool.
<JamesMunns[m]>
I don't fully remember where the DMA chapter is at, but I certainly have lots of opinions, happy to turn those into docs :)
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
bartmassey[m]: I can help with review if you ping me.
<bartmassey[m]>
There really isn't any DMA chapter at all, since ever as far as I know. So opinions would be welcome 😀
<adamgreig[m]>
cool, thanks for the update!
<adamgreig[m]>
let's start with the triage tickets then...
<adamgreig[m]>
next, provisioning repo, as James Munns mentioned it's used for the hosting infra so we need to keep it for now
<adamgreig[m]>
fixedvec... I think has been in rust-embedded org possibly longer than the wg has?
jannic[m] has joined #rust-embedded
<jannic[m]>
Yes there are ticket comments talking about assigning it to some team.
<jannic[m]>
But AFAIK its functions are completely covered by heapless anyway, aren't they?
<bartmassey[m]>
Definitely deprecate and archive fixedvec in favor of heapless in my opinion.
<adamgreig[m]>
yea, I think heapless covers it, so maybe we just update the readme to say "not actively maintained", though afaik Nick Stevens is still happy to maintain it if required
<jannic[m]>
Likely there's nothing wrong with fixedvec, but keeping it next to heapless is a bit confusing.
<bartmassey[m]>
Oh shoot. We need to talk more about demotion of Rust embedded targets today; want to try to find names or leads on names we can attach to some of these. Sorry for forgetting to get it on the agenda.
<jannic[m]>
Maybe instead of "not actively maintained" we could point to heapless as a more feature rich alternative?
<adamgreig[m]>
sounds good
zeenix[m] has joined #rust-embedded
<zeenix[m]>
but heapless is itself barely maintained
<bartmassey[m]>
Who is the lead maintainer for heapless? I kind of thought it was doing ok?
<jannic[m]>
I think the repo is doing fine, but it badly needs a release.
<zeenix[m]>
I'm hopefully going to change that after I'm back from vacation (assuming my request to be added to the team, is accepted)
<zeenix[m]>
jannic[m]: Not really. Release hasn't happend for months because nobody is reviewing/merging PRs needed
<jannic[m]>
Of course we could do better, but it's far from being unmaintained.
<zeenix[m]>
Anyway. Just wanted to point out the fact that at last currently it's not a well-maintained crate so perhaps it'd be a good idea to hold off any recommendations to treat it as such, until it's well-maintained
<zeenix[m]>
jannic: sure but not the one PR that's blocking the release even though it looks ready
<therealprof[m]>
therealprof[m]: I think we should probably just ship it as is.
<jannic[m]>
I don't know anything about loom, but I think the author deserves some reply. Even if it was something like "sorry we don't know enough about loom, could you explain why it's useful"?
<JamesMunns[m]>
loom is a very cool tool for testing atomic ordering and similar concurrency bugs, +1 from me to merging it
<adamgreig[m]>
the PR implementation itself is straightforward enough so I'd also be happy to have it merged
<bartmassey[m]>
I don't see any obvious harm from merging it, so I'd support it.
jfsimon has joined #rust-embedded
<adamgreig[m]>
that's one for the HAL team to vote on, but we can ping them on the PR
<therealprof[m]>
Checking now. I love loom, never thought it would have applications for embedded though.
jfsimon has quit [Remote host closed the connection]
<bartmassey[m]>
Can we talk about Rust embedded targets a bit today? I am a little concerned about the current situation.
jfsimon has joined #rust-embedded
<adamgreig[m]>
yep, let's, one sec
<adamgreig[m]>
right, sorry
<adamgreig[m]>
let's briefly do quickstart before we get to it, since they're already in that order on the agenda
<adamgreig[m]>
I think it's probably still useful having quickstart as a template, so maybe it just needs a little update?
<thejpster[m]>
knurling-rs/app-template also exists
<adamgreig[m]>
I guess the hard thing is like, do you talk about things like embassy or rtic, do you pull in some kind of hal, or do you have a quickstart that's totally generic to cortex-m but thus can't do any actual gpio
<adamgreig[m]>
yep indeed, we could just signpost that
<bartmassey[m]>
That sounds kind of ideal to me (having not looked closely at the knurling-rs template yet 😀)
<thejpster[m]>
is "starter project for Arm Cortex-M" in scope for the embedded-wg? I feel like it's covered well enough elsewhere, and "one starter project to rule them all" isn't a requirement
<adamgreig[m]>
yea, ok, so just update the quickstart repo to point at app-template and then archive it? are there any other's we'd like to point to?
<thejpster[m]>
Sets up flip-link, defmt, probe-rs, vscode, walks you through adding a HAL and/or a memory.x
<bartmassey[m]>
Are we still using flip-link? I kind of quit using it in favor of rust-lld a while back. Am I missing something?
<JamesMunns[m]>
Does rust-lld allow you to re-order your memory sections to put stack at the bottom?
<thejpster[m]>
flip-link links your program upside so a stack overflow is a hard fault instead of silent data corruption
<jannic[m]>
One reason to have a quick-start within the WG is that we can keep it up to date whenever there's a change in cortex-m. But as we are both very reluctant in merging breaking changes in cortex-m, and not very good in keeping our repos in sync, I don't think that's a strong argument.
<thejpster[m]>
it's a very thin linker wrapper, that links, makes a new custom .ld file, and then relinks
<therealprof[m]>
bartmassey[m]: People are very actively using it.
<thejpster[m]>
JamesMunns[m]: only if you tell it to through the memory.x file
<bartmassey[m]>
Good to know all this, thanks! I had fundamentally misunderstood what flip-link was.
<thejpster[m]>
the trick to putting the globals at the top of RAM is that you need to know how many globals you have.
<adamgreig[m]>
crucially rust-lld can't automatically move things so stack is right at the bottom based on the actual size of the static memory allocations, which is what flip-link does, right?
<JamesMunns[m]>
JamesMunns[m]: I thought general linkers couldn't do the relevant/relative offset math that was required for this, maybe lld can these days
<bartmassey[m]>
I think there's some way to get the compiler to do stack-guard stuff in no_std now, but don't quote me on this.
<thejpster[m]>
anyway, flip-link is a knurling project so knurling-rs/app-template isn't going to not use it ;)
<JamesMunns[m]>
yeah, to do what flip link does, your linker script would have to be able to do something like SIZE_OF(.bss) + SIZE_OF(.data) etc
<bartmassey[m]>
:grinning: Just wondering whether we should be using it in the Disco Book? Easy change to make if so.
<bartmassey[m]>
I had completely misunderstood its purpose — thought it was just a host platform linker compatibility kludge. I will look at documentation again and try to see where I got that idea and fix it.
<adamgreig[m]>
well, I'm halfway into a PR for quickstart then, will finish after meeting
<adamgreig[m]>
final point for today is the arm targets
<adamgreig[m]>
names wise, I think the answer is already "our existing arm team, unless anyone shows up to volunteer, in which case they could already just take those targets on themselves"
<JamesMunns[m]>
Someone recently was asking about the aarch64 crate
<JamesMunns[m]>
maybe worth doing a "hey who wants to join the arm team" call, esp for cortex-r and cortex-a targets?
<bartmassey[m]>
It sounds like the Project wants a lead individual for each target? Did I misunderstand this?
<adamgreig[m]>
the project is happy for our team to be the maintainer aiui
<adamgreig[m]>
I didn't think it had to be a single person
<adamgreig[m]>
I like the idea of us being able to support those targets, but personally I've got minimal ability to do anything about cortex-a or cortex-r, so I wouldn't be leading any efforts
<adamgreig[m]>
I think there's a lot more benefit getting armv8r-none-eabihf up since it's currently tier 3 and could see more use, whereas the older targets seem unlikely to see a resurgence...
<bartmassey[m]>
I'm working on a cortex-a bare-metal (ish) project these days, so maybe I should step up a bit? I don't know if I'm smart enough or free enough to do much, but I'm at least interested. I don't know how much work target maintenance for a "mature" target is?
<thejpster[m]>
the wg-embedded arm team are already maintainers for thumbv6m-none-eabi, thumbv7m-none-eabi, thumbv7em-none-eabi* and thumbv8m. -none-eabi
<thejpster[m]>
I expect very few calls on the target maintainers. The LLVM backend is very stable, and the AArch32 code paths get exercised a lot by all the Arm Linux stuff.
<thejpster[m]>
the link in the quickstart readme is broken
<thejpster[m]>
it's taken as a relative link
khionu[m] has joined #rust-embedded
<khionu[m]>
Hi, I'm looking to use as cheap of a MCU as I can for a project, any recommendations? Hoping for something known to work well with Rust already, doesn't need any particular features, it's basically just going to shuffle a very small amount of data (16 bytes per physically connected source, hundreds of sources) and provide a USB interface.
<thejpster[m]>
khionu[m]: where are you buying from? JLCPCB, LCSC or digikey?
<bartmassey[m]>
Most any cheap Arm or RISC-V part should work ok with Rust these days. Are you looking for US10¢ or US$1? The latter is probably the cheapest STM parts. The former is a bit harder.
<khionu[m]>
LCSC, probably going to use JLCPCB for producing in bulk once I'm through the prototyping phase. Pins, not exactly sure yet, but just enough for 1 I2C relay and the USB interface.
<KevinPFleming[m]>
STM32G0 is a nice family to use and the smallest parts are quite cheap
<bartmassey[m]>
Yeah, the G0 is my default, but it's close to $1 until the quantities get quite large IIRC.
<khionu[m]>
So far, I'm expecting the plastic to be more expensive than the electronics, lol, so that's fine.
<khionu[m]>
Project is essentially a board for building a TTRPG terrain on that will track the pieces for the purpose of line-of-sight and cover calculations.
<bartmassey[m]>
Suggest printing plastic until you get to at least 1K units :grinning:
<khionu[m]>
bartmassey[m]: Hmm? Not sure what you mean there
<bartmassey[m]>
Using JLCPCB or PCBWay or somebody to print cases will typically be much cheaper than paying for injection molds for small-volume stuff. But you knew that.
<bartmassey[m]>
The other thing you might consider for your application is the STM low-power line. It is truly power-frugal, and not so expensive.
<firefrommoonligh>
bartmassey[m]: PolyCase's machining and silkscreen service is fantastic and reasonably priced for low volumes.
<thejpster[m]>
(also feel free to steal my CI actions that generate gerbers and JLCPCB pick and place files as artefacts. tragically few electronics projects have that)
<firefrommoonligh>
And, if g0 is still too expensive... that's what C0 is for
<firefrommoonligh>
I think that's its shtick
<firefrommoonligh>
I think paying for an OTS enclosure machining service is a nice middle ground between 3D printing and injection molding. Note that you will probably be designing your PCB dimensions and connector/LED/button placement around the enclosure you choose, vice the other way around
<thejpster[m]>
OK, hot take for the next WG meeting: we should deprecate cortex-m-semihosting.
<khionu[m]>
bartmassey[m]: I mean, the lower the better, the one thing I don't want to sacrifice is ease of development. It's literally just reading from a dynamic array of EEPROMs, aggregating their data, and providing an interface to write to them.
<KevinPFleming[m]>
firefrommoonligh: The F0 series is extremely old at this point :-)
<bartmassey[m]>
Wow. That's a lot of crates.
<khionu[m]>
bartmassey[m]: (continuing the topic in thread)
<bartmassey[m]>
Yeah, I forgot that F0 may go out of stock sometime in the foreseeable future. That's good to remember.
<thejpster[m]>
khionu[m]: is your application battery powered?
<bartmassey[m]>
Yeah, taiki-e looks legit. Maintains a bunch of highly-used crates, apparently. I think I'm on board with this plan.
<khionu[m]>
thejpster[m]: For now, let's assume not, but I'll want it to not be too much of a drain on the laptop it would be drawing power from
<khionu[m]>
khionu[m]: Later I might consider a controller with touch screen and battery, since it could use the same USB-C port
<thejpster[m]>
khionu[m]: oh, well any cortex-m is fine then
<thejpster[m]>
thejpster[m]: the ultra low power chips just get you down to microamps, which is where you need to be for 10 years on a coin cell or something
<thejpster[m]>
thejpster[m]: The STM32G0 is *newer* and technically *better* but it's really marginal. The STM32F0 series is 12 years old at this point and very well understoof.
<khionu[m]>
thejpster[m]: Price point is about the same. I guess going with the F0 line would be better ecologically, using up stock.
<thejpster[m]>
khionu[m]: And the STM32G030 is 20 cents more than the STM32F030 equivalent
<therealprof[m]>
They're still actively bumping 10 year longevity counter on the F0 series.
<khionu[m]>
<khionu[m]> But yeah, I'll just go with the F0 one. I don't have any reason to want a G0 it seems, so might as well
<khionu[m]>
I don't have a programmer for an SoC like this, any recommendations?
Pete[m]1 has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]>
I've got a silly question, suppose you wanted to convert a `println!()` into an IPC call automatically (assuming a 256 byte max buffer allocated on the stack and passed by reference elsewhere)
<jason-kairos[m]>
Has anyone done work in this area? serialization of write/fmt arguments?
<jason-kairos[m]>
(execution would stop while what is effectively some function would parse the buffer containing serialized string formatting args / values / references / etc.)
<jason-kairos[m]>
* is effectively just "some function, * some function out there" would parse
<khionu[m]>
Could you not write your own macro for this? If you have alloc, you could just use write! and then serialize the string, and avoid doing all the formatting work yourself.
<jason-kairos[m]>
In reality, I need to figure out how to pass a the write args to some other thread so it can do the formatting there. (Moving buffers or references to buffers around is easy, what I don't know is about passing around the arguments)
<jason-kairos[m]>
In my local threads, I don't have enough space in memory to do the local formatting. But I do have enough space to send the stuff to be formatted to another thread that does.
<JamesMunns[m]>
You can't really because Arguments is opaque
<jason-kairos[m]>
So I can't make a clone of the arguments and pass it around?
<jason-kairos[m]>
Well, I can pass a reference to it
<JamesMunns[m]>
I think you can, but I don't think you can do much other than fmt it
<Lumpio->
So this is just for memory reasons and it would be OK to block the source thread while the other thread does formatting..?
<Lumpio->
E.g. you're not hoping to speed up things by doing this
<Lumpio->
I.e.!!
<Lumpio->
Sending references easily gets you into a situation where the source thread will have to block indefinitely waiting for the target thread to do its thing
<Lumpio->
Can't release whatever is potentially still being referenced by the target thread
jfsimon has quit [Remote host closed the connection]
<jason-kairos[m]>
<Lumpio-> So this is just for memory reasons and it would be OK to block the source thread while the other thread does formatting..?
<jason-kairos[m]>
Yes, it will be blocked.
<jason-kairos[m]>
And priority inversion in impossible in this system.
jfsimon has joined #rust-embedded
<Lumpio->
In practice it sounds like it should be ok to just send a reference (or pointer) to the other thread, however in theory if you think about the soundness of everything the arguments will contain references to who knows what that can do who knows what so it's probably not possible to make this completely safe
jfsimon has quit [Remote host closed the connection]
<jason-kairos[m]>
looks like it's currently impossible to store and pass around `format_args!` due to a compiler limitation regarding the computation of lifetimes.
<jason-kairos[m]>
Does this mean I have to use a third party crate for formatting?
jfsimon has joined #rust-embedded
<jason-kairos[m]>
* looks like it's currently impossible to store and pass around `format_args!` due to a compiler limitation regarding the computation of lifetimes.
<jason-kairos[m]>
Does this mean I have to use a third party crate for string formatting?
<jason-kairos[m]>
* looks like it's currently impossible to store and pass around `format_args!` due to a compiler limitation regarding the computation of lifetimes.
<jason-kairos[m]>
That's quite the limitation if one is going to try to do IPC.
jfsimon has joined #rust-embedded
<jason-kairos[m]>
* looks like it's currently impossible to store and pass around `format_args!` in local variables assigned via `let` due to a compiler limitation regarding the computation of lifetimes.
<jason-kairos[m]>
Does this mean I have to use a third party crate for string formatting? (if I want to pass around the format args in a variable)
Pete[m]1 has joined #rust-embedded
<Pete[m]1>
Anyone know of a fixed say future select_all, before I implement it? The one in the futures crate uses iter/vec
<Pete[m]1>
s/say/size/, s//`/, s/,/`,/
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<thejpster[m]>
<therealprof[m]> Friends don't let friends use semihosting... Just get rid of it altogether.
<thejpster[m]>
it's perfect for QEMU though.
<thejpster[m]>
also for getting probe-rs to disconnect when the program is finished.
<thejpster[m]>
and to indicate test failures.
<thejpster[m]>
<khionu[m]> I don't have a programmer for an SoC like this, any recommendations?...
<thejpster[m]>
a Raspberry Pi Debug Probe will work, or just load some CMSIS-DAP firmware onto a Raspberry Pi Pico and wire it up yourself.
<thejpster[m]>
you're welcome to re-write the cortex-ar test suite if you like ;)
<Pete[m]1>
s/say/size/, s//`/, s/,/`,/
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
Noah[m] has joined #rust-embedded
<Noah[m]>
Hmm is there any way to have a different cargo.tomls for each crate in the workspace?
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cirho has quit [Ping timeout: 265 seconds]
cirho has joined #rust-embedded
<khionu[m]>
Are there any guides to writing a HAL? I'm looking at another MCU (for a different purpose in the same project) and it's starting to look more attractive than my shenanigans.