<JamesMunns[m]>
fwiw: poststation can basically do this for you already, either with string formatted logs, or any serde serialize type
<JamesMunns[m]>
poststation/postcard-rpc have schema discovery, which is sort of like defmt's elf metadata, but you query it from the device on first connect.
<JamesMunns[m]>
Poststation will then also translate into JSON, which you can use for forwarding to a log collection application
<JamesMunns[m]>
I don't handle the "to flash" part, that would require an additional service, but could use the same typesystem of messages, or you could have an endpoint for retrieval of messages.
<JamesMunns[m]>
Poststation isn't cloud based, it's meant to be use locally, but it can act as the "edge gateway" depending on what services you want to use.
<JamesMunns[m]>
s/use/used/
<t-moe[m]>
ah nice. Yeah, tbh, I havent looked into poststation so far (I think back in august you only started working on it / talking about it..)
<JamesMunns[m]>
I think there are a lot of defmt users that might not be poststation/postcard-rpc users though, so having more services is definitely interesting!
<JamesMunns[m]>
It Should™️ be shipping this week as a 0.x preview, just waiting on the logo designer at this point (and ideally finishing the tutorial docs) :D
<JamesMunns[m]>
Happy to send preview builds today to anyone interested tho.
<JamesMunns[m]>
Very cool to see you built out a log queue based on bbqueue + sequential storage!
<t-moe[m]>
its an honor to work with your excellent tools :) James Munns diondokter
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Storing defmt data in flash is one of the reasons why the queue exists in sequential-storage haha
m5zs7k has quit [Ping timeout: 246 seconds]
m5zs7k has joined #rust-embedded
cinemaSundays has joined #rust-embedded
ruabmbua[m] has quit [Quit: Idle timeout reached: 172800s]
<MathiasKoch[m]>
<t-moe[m]> "Hello Again,..." <- I would be very interested in seeing the lambda, and the cli tool as a reference, as we have exactly this setup on our roadmap.
<MathiasKoch[m]>
That is, if you want to share ☺️
cr1901 has quit [Ping timeout: 248 seconds]
cr1901 has joined #rust-embedded
cinemaSundays has quit [Quit: Connection closed for inactivity]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
> ISO 26262 ASIL D, are now supported with the same safety level by HighTec’s Rust compiler
<diondokter[m]>
For their 'stellar' cortex-r cores
<diondokter[m]>
* > ST’s Stellar MCUs certified to the highest level of risk management, ISO 26262
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
it seams there plan was to running it on pxros-hr - eg here is a github [link](https://github.com/hightec-rt/pxros-hr), but doesn't seam like a active place.
<vollbrecht[m]>
It seams like they go the same obscure route as infinion. At least they make nice power point slides. Bummer that there aren't more open about the day to day stuff
<diondokter[m]>
<vollbrecht[m]> "it seams there plan was to..." <- Yeah, I saw a talk from HighTec last year at embedded world about their Rust work for Infineon. He didn't really make it sound like something nice to work with. Very custom, very captured in their ecosystem
<dirbaio[m]>
vendors gotta vend
<thejpster[m]>
as someone who just spent weeks working on Rust on Cortex-R and making it all open source ... I have feelings
<RoyBuitenhuis[m]>
They do make pac + hal for accessing hardware, so I guess that's nice.
<diondokter[m]>
Ah yes, but that's an infineon effort
<diondokter[m]>
Nothing to do with HighTec
<vollbrecht[m]>
i mean rust interop on existing platforms can be a nice viable solution. But yeah it still needs some work, and actual care so users can productively use that stuff :D You cannot just magical throw some crate/repo out there without integration into the wider ecosystem, if you are not plan on creating a complete ecosystem by yourself
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
almindor[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has joined #rust-embedded
<TomB[m]>
I had read a long time ago infineon was going to add rust support for their tricore parts, but then the repos never showed up
<TomB[m]>
I guess this is it?
<thejpster[m]>
Hightec have been advertising Rust for Infineon Aurix (Infineon TriCore based) and Traveo (Arm based) for some time. I haven't seen any of it online - I don't know that it is open source.
<thejpster[m]>
This is an announcement about Hightec working with ST Micro, which in and of itself, is amazing news.
<TomB[m]>
seems like rust is really making inroads in automotive
<thejpster[m]>
can confirm
<thejpster[m]>
There was a reason that Ferrocene got ISO 26262 automotive qualification first - it was what the customer asked for (you've heard of them)
<Ralph[m]>
i'd love to see a "here's a list of (well known) companies which now use rust for their embedded things" list (e.g. currated by the WG) - i'm still confronted by (stupid) sayings like "many languages have come to challenge C but none has ever managed it", "we don't know anyone using Rust for embedded", "this is just a fad and will pass". sure, there are blog posts here and there of people stating that they're using it (IIRC there's
<Ralph[m]>
one from volvo for something super small in their cars?). i think having such a list to point to would really help out with such discussions
<Ralph[m]>
* i'd love to see a "here's a list of (well known) companies which now use rust for their embedded things" list (e.g. currated by the WG) - i'm still confronted by (stupid) sayings like "many languages have come to challenge C but none has ever managed it", "we don't know anyone using Rust for embedded", "this is just a fad and will pass". sure, there are blog posts here and there of people stating that they're using it (IIRC there's
<Ralph[m]>
one from volvo for something super small in their cars?). i think having such a list to point to would really help out with such discussions.
<Ralph[m]>
in 10 years we (hopefully) won't need such a list anymore since by then hopefully rust is used so far and wide that it's just public knowledge and you don't need to proof it anymore to anyone
<dirbaio[m]>
maybe it's because it's such an OP competitive advantage that we don't want to let our competitors know about it 🕵️♂️
<vollbrecht[m]>
well most company's especially conservative automotive are tightly liped around many aspects. not the best example but even if you would ask tesla( comparable "open), who where there drive by wire system comes from ( cybertruck - and i think it comes from ZF) or if you ask them who builds there giga casting press they would not be direct answers to all the suppliers. Software and supply chain is the same here
<vollbrecht[m]>
* well most company's especially conservative automotive are tightly liped around many aspects. not the best example but even if you would ask tesla( comparable "open"), where there drive by wire system comes from ( cybertruck - and i think it comes from ZF) or if you ask them who builds there giga casting press they would not be direct answers to all the suppliers. Software and supply chain is the same here
kit[m] has joined #rust-embedded
<kit[m]>
I know there are also teams within Amazon that use Rust for embedded, though I don't think I can say which ones (have NDAs)
<kit[m]>
though obviously Amazon is heavily invested in Rust
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
Embedded linux or embedded on mcus, if you can at least share that?
<kit[m]>
Embedded on MCUs and embedded linux both
<thejpster[m]>
I mean, yeah, just point at the Foundation corporate membership list if you don't believe anyone is using Rust in production more widely.
<thejpster[m]>
it's already running your Windows PC and your Android tablet, and the Pluton processor inside your Surface device.
<thejpster[m]>
and serving your DNS queries, and running the CDN you use to host the blog where you complain no-one is using Rust in production
<cr1901>
thejpster[m]: Just to reiterate- I _did_ get defmt 1.0.0-rc.1 to work on MSP430 in at least a minimum capacity. So no issues testing on my end :P.
<thejpster[m]>
nice
<cr1901>
Oh... and it's delayed. Maybe I'll test more
<cr1901>
(The point is I won't be raising breaking issues I think. Maybe I'll make a PR for the weird linker script ordering required, but required more research)
<cr1901>
requires*
<adamgreig[m]>
ok, let's begin!
<adamgreig[m]>
quick announcement, the PR to update the rust-lang teams merged, so all wg members should now be on the main page at https://www.rust-lang.org/governance/wgs/embedded as well as further down in their specific team
<adamgreig[m]>
that's all the announcements from me, thejpster want to talk about defmt and then cortex-r?
<thejpster[m]>
ok
<thejpster[m]>
the defmt 1.0 pre-release is working, in that people are saying "hey, maybe this thing needs to be done before 1.0?"
<thejpster[m]>
there's a PR to add cbor support but as part of it we probably want to make one of our enums in ther decoder non_exhaustive, and it makes sense to do that pre-1.0.
<TomB[m]>
right I had noted consistent message identifiers would be nice to see for a 1.0
<thejpster[m]>
there was another issue around making defmt::Format trait object-safe (dyn-compatible I think we call that now), which we've had to bring in an expert to look at because all the chat here was "ugh, that needs specialisation"
<TomB[m]>
I get if its not on the must have list
<adamgreig[m]>
sounds good
<thejpster[m]>
in general I can't do anything firmware side that's a breaking change, but I can on the host side.
<thejpster[m]>
if it's not a breaking change firmware side but requires a Wire Format bump, that can wait to 1.1
<thejpster[m]>
so anyway, it's not being release tomorrow. Please keep you feedback coming, but I can't promise to fix everything you ask for even if you ask nicely. If you have a commercial need, you can always pay you way to the top of the list.
<thejpster[m]>
s/release/released/, s/you/your/
<thejpster[m]>
on to Cortex-R
<thejpster[m]>
so, back in the olden days, there were microcontrollers and there were big processors you'd put in a computer
<bartmassey[m]>
Those were good times.
<thejpster[m]>
ever since Version 7 of the Arm Architecture was released, it has been more complicated
<thejpster[m]>
The M-Profile doesn't look an awful lot like the A-Profile, but then there's this R-Profile in the middle.
<thejpster[m]>
It's (usually) bare-metal and has an MPU like M-Profile.
<thejpster[m]>
But it uses A32 (or T32) instructions like A-Profile (or at least, 32-bit A-Profile)
<thejpster[m]>
So ... I propose you fold the Cortex-M team into the Cortex-A team and call it the Arm team. This solves the problem of the Cortex-R team being empty.
<thejpster[m]>
Arm Unified Assembly language looks the same on all three anyway.
<JamesMunns[m]>
cortex-arm team? :p
<bartmassey[m]>
Cortex-R team into Cortex-A?
<thejpster[m]>
An alternative is having an AArch32 team and an AArch64 team, but Armv8-R AArch64 is coming.
<cr1901>
ARM team reads the ARM to do embedded ARM
<adamgreig[m]>
it technically means there's no empty cortex-r team, but it doesn't change that there's no-one in the new arm team with knowledge or interest in maintaining the cortex-r crate, so practically I don't know if it makes a real difference
<thejpster[m]>
bartmassey[m]: there is no Cortex-R team - it's empty. Which is a problem.
<thejpster[m]>
there's enough overlap between R and A that some of the A team might know most of the details
<thejpster[m]>
and if push comes to shove, Jorge and I can help out - temporarily.
<adamgreig[m]>
it might be a good idea anyway, just in terms of reducing the number of teams and the complexity that comes with that, but I also don't imagine there will be much overlap with existing cortex-a members doing cortex-m things and vice versa
<bartmassey[m]>
So is the proposal to unify everything into a single ARM team? Because I am down with this proposal, even though I haven't been participating much.
<adamgreig[m]>
but I do feel like we have more teams than we need and this would help with that
<thejpster[m]>
the R and the M overlap, and the R and the A overlap (in different areas), but M and A don't really overlap except they all (can) use T32 machine code
<bartmassey[m]>
I feel like the A people can easily learn M things and vice-versa. Both should be able to figure out R. Maybe a unified team would help that process along?
<bartmassey[m]>
In other words, only a couple of people want to specialize in R, but there may be more that would be willing to take an interest.
<thejpster[m]>
as an aside, you could probably also use a SPARC team, but let's not get into that...
<adamgreig[m]>
first we'd need volunteers for it :P
<TomB[m]>
thejpster[m]: spppppaaace wire
mabez[m] has joined #rust-embedded
<mabez[m]>
Xtensa team when 🙈
<adamgreig[m]>
when someone volunteers to start it
<bartmassey[m]>
Lol. Gotta leave for class now. Fully support an ARM team merge, but my opinion is worthless since I'm not on any of the teams.
<thejpster[m]>
I always highly value your input, Bart!
<adamgreig[m]>
it's still a useful opinion, thanks!
<cr1901>
I like the idea, FWIW
<adamgreig[m]>
I'll open a vote for it and we can see what people think
<thejpster[m]>
hey, maybe someone from ST can join
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Is there a good summary of pending work on the various sub teams?
<adamgreig[m]>
at a high level it's just "maintain the crates owned by that team", but in terms of plans for each of those crates, I don't think there's any one summary
<adamgreig[m]>
there are a few ideas for cortex-m at least
<thejpster[m]>
oh, also, the new arm team might think about dropping the cortex-m-semihosting crate, because semihosting works basically the same on A., R and M (modulo using either BKPT, HLT or SVC instructions - but the syscalls are the same), and there's already the 'semihosting' crate that works across all three (and RISC-V)
<d3zd3z[m]>
I imagine a lot has helped by a lot of the what were cortex-m-... crates just becoming embedded-...
<adamgreig[m]>
any other points anyone would like to discuss this week?
<thejpster[m]>
who votes on the team merge? the existing M and A team members>
<thejpster[m]>
s/>/?/
<adamgreig[m]>
yea
<thejpster[m]>
cool. I will continue to work to get a representative who has first-hand knowledge of these architectures. No promises.
<adamgreig[m]>
thanks!
<adamgreig[m]>
if that's all then let's finish here for today, thanks all
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
dsvsdveg[m] has joined #rust-embedded
<dsvsdveg[m]>
Hey everyone, i'm looking to create support for pic16F microcontroller, but i'm not sure the ideal way to support it and be able to flash it. What are my option ?
<dsvsdveg[m]>
but for now, i'am not sure how i would continue the work
swork[m] has joined #rust-embedded
<swork[m]>
Hi all. What's the intended way to switch embassy_rp::pio::onewire into a bit-at-a-time mode, for implementing the Dallas rom-search algorithm? There's a hard-coded 8-bit shift config in pio_programs/onewire.rs, but I don't see how to modify it once set. Is this doable with the existing implementation?