<re_irc>
<@adamgreig:matrix.org> : The only thing I'd add is that it's _any_ 5 bits anywhere in the message for HD=6, and in addition you get any bits flipped within a single 32-bit chunk (for crc32), and also the HD depends on both the CRC and the message length (longer messages will have lower HD)
<re_irc>
<@adamgreig:matrix.org> My guess is that putting it inside cobs degrades all those to just "one in 2^N chance of accepting corrupted message", which to be fair is what some people assume crcs give you anyway :p
<re_irc>
<@adamgreig:matrix.org> The other thing to be aware of though is that because the bit errors happen after cobs encoding, you might try and decode something where a bit or two have flipped causing totally wrong amounts of cobs encoded data to be decoded, at which point the "final crc" is actually just some random data from within the message and not a crc at all, which will then validate the smaller message with chance 1 in 2^N, which is the "be...
<re_irc>
... careful of interaction with encoding" point from that blog
jcroisant has quit [Quit: Connection closed for inactivity]
<re_irc>
<@shakencodes:matrix.org> Quick note of thanks to James and Chris... postcard::flavors::crc is up and running in my app and HIL test-stand. Once it compiled (which took a little while), the revised application ran and all HIL tests passed on the FIRST attempt.
<re_irc>
<@adamgreig:matrix.org> (perhaps in a full analysis you'd find a single bit is either detected by cobs if it's in the cobs encoded data or is passed through to, and detected by, the crc, so maybe you need two bit flips for a possible undetected error)
<re_irc>
<@jamesmunns:beeper.com> Yeah, the analysis gets kind of spicy, especially if you are using a something like CobsAccumulator with a fixed upper size. In order for something to fail the "swiss cheese stack", a corrupted message must:
<re_irc>
- Actually form a coherent "cobs linked list", which ends in a final "0x00" byte, BEFORE running into the real 0x00 byte
<re_irc>
- Form a chain that fits within the CobsAccumulator max size
<re_irc>
- Contain a message >= the number of bytes to decode as a postcard message
<re_irc>
- Contain data payload that passes payload sanity checks (enumerated values like Option or Result, varint lengths within type limits, boolean values, etc.)
<re_irc>
<@jamesmunns:beeper.com> practically for any non-trivial postcard message (like something that could decode from a wide range of very small to very large messages, with simple data, like say, directly serializing "&[u8]"), it'd be a pretty astronomical chances IMO to fall through all of those validation steps.
<re_irc>
It's just WAY harder to make mathematical guarantees about all those levels, and it's probably possible to thread the needle
<re_irc>
<@jamesmunns:beeper.com> Yeah, the analysis gets kind of spicy, especially if you are using a something like CobsAccumulator with a fixed upper size. In order for something to fail the "swiss cheese stack", a corrupted message must:
<re_irc>
- Actually form a coherent "cobs linked list", which ends in a final"0x00" byte, AT or BEFORE running into the real 0x00 byte
<re_irc>
- Form a chain that fits within the CobsAccumulator max size
<re_irc>
- Contain data payload that passes payload sanity checks (enumerated values like Option or Result, varint lengths within type limits, boolean values, etc.)
<re_irc>
- Contain a message >= the number of bytes to required to decode as a postcard message
<re_irc>
<@jamesmunns:beeper.com> though if you had something like "enum Message { Start, Stop, Data(HugeStructType), .. }" as your wire type, that could be as short as a single "0x00" or "0x01" byte (plus N bytes of CRC), which could fall into the trap
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> Missed this when it came out.
<re_irc>
<@thejpster:matrix.org> More throwing shade at Espressif
IlPalazzo-ojiisa has joined #rust-embedded
lehmrob has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> I think someone more or less "official" from NXP asked for work on a driver for some sensor chip. Maybe this is a sign that people there are taking it serious.
<re_irc>
<@sourcebox:matrix.org> My biggest concerns are though if we can ever come to a mature ecosystem for STM32 without help from ST. The pure number of chip families and variants makes it nearly impossible do it as side project.
<re_irc>
<@sourcebox:matrix.org> Has there ever been some attempt from someone here to contact ST about it?
lehmrob has quit [Ping timeout: 260 seconds]
lehmrob has joined #rust-embedded
<re_irc>
<@bugadani:matrix.org> "Infineon: A pioneer in enabling support of Rust for its MCUs" meaning "If someone else won't do this for us, we will"?
lehmrob has quit [Ping timeout: 246 seconds]
<re_irc>
<@sourcebox:matrix.org> But we should really rethink if it's a good idea to let the manufacturers just come up with it. If e.g. ST comes up with HALs of the same quality as their C HALs, then good luck.
<re_irc>
<@sourcebox:matrix.org> The risk is that they throw something in the room saying: "Hey, we have Rust, we're cool!" and if the design is bad, it results in bad reputation for Rust at all.
<re_irc>
<@9names:matrix.org> it honestly sounds a bit like you're arguing with yourself?
<re_irc>
"we can't let vendors support rust because they'll screw it up and no-one will take us seriously"
<re_irc>
is there something in particular you want to happen that isn't happening now?
<re_irc>
"we need vendors to support rust because otherwise no-one will take us seriously"
<re_irc>
<@bugadani:matrix.org> : world peace
<re_irc>
<@9names:matrix.org> yeah i don't trust STM to deliver that 🤣
<re_irc>
<@bugadani:matrix.org> I wonder if the rust trademark can be used to apply some pressure here
<re_irc>
<@9names:matrix.org> for what it's worth: i would prefer they spent money on the folks getting all the compiler + rust library bits to work how we want them.
<re_irc>
it's thankless work that most of us don't have the time or energy for.
<re_irc>
<@sourcebox:matrix.org> : that's what I tried to suggest. They should pay people from the community instead of coming up with a half-baked solution.
bpye has quit [Quit: Ping timeout (120 seconds)]
<re_irc>
<@sourcebox:matrix.org> But these people need to get in contact with the vendors and present some kind of roadmap.
bpye has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> you can be re-assured that people who provide commercial rust services do often try and engage with the major silicon vendors
starblue has quit [Ping timeout: 264 seconds]
<re_irc>
<@thejpster:matrix.org> it's worth observing that there's a heirarchy of parts from low-volume high profit, to high volume low profit. You can imagine silicon vendors would like to start at the highly profitable end of the scale and support those customers first.
starblue has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> : What I read between the lines from your video is that more vendors should act like Espressif and involve the community in development.
<re_irc>
<@omar_u8:matrix.org> I recall similar conversations occurred with RISC-V, some said that adoption would be a long-shot. See where we are now. Industries involving embedded are still hesitant from open-source (especially automotive). The drive will come from the top of the chain (Ex. OEMs).
<re_irc>
<@omar_u8:matrix.org> * Eventually, the drive will come from the top of the chain (Ex. OEMs) IMO.
<re_irc>
<@sourcebox:matrix.org> : Is RISC-V really competitive with MCUs right now? I've not encountered many RV32 chips with FPU until now. The ESP32-P4 will probably change the game when it's available.
<re_irc>
<@ryan-summers:matrix.org> Getting silicon vendor support for Rust is honestly pretty low on my "things I need to use Rust commercially" list. Many products don't even have the possibility to use software provided by third parties without some major heartache (i.e. SOUP [Software of Unknown Providence] in medical devices, I'm sure it's similar in automotive)
<re_irc>
<@ryan-summers:matrix.org> In fact, I'm fairly certain many embedded companies _are_ using Rust nowadays
<re_irc>
<@ryan-summers:matrix.org> Or trying to get the ball rolling. It's hard if you have an entire engineering team already and none of them know Rust though
<re_irc>
<@ryan-summers:matrix.org> And it takes time for institutions like that to change, so you more often see Rust in smaller startups right now
<re_irc>
<@ryan-summers:matrix.org> As more schools teach Rust, we may see this slowly change though. One big limiter is that there's not a significant rust embedded workforce, so it can be harder for companies to fill positions if they require extensive Rust background
<re_irc>
<@sourcebox:matrix.org> At the small to medium sized companies I'm doing freelance work for, nobody in in their team knows Rust. And they don't even consider to use it in the near future.
<re_irc>
<@sourcebox:matrix.org> * teams
<re_irc>
<@ryan-summers:matrix.org> But Rust outside of embedded is catching on big time at many large companies (i.e. Microsoft) and I remember the embedded guys at SpaceX were talking to me about embedded rust back in 2015
<re_irc>
<@ryan-summers:matrix.org> : In my professional opinion, this can likely lead to a market disadvantage - in my experience, Rust allows you to get a lot more done in a lot less time, and allows you to write more reliable software
<re_irc>
<@ryan-summers:matrix.org> And I think that will force companies to change over time
<re_irc>
<@ryan-summers:matrix.org> For context, I work with some SMEs and they _do_ do Rust
<re_irc>
<@ryan-summers:matrix.org> * use
<re_irc>
<@sourcebox:matrix.org> At the time around 2012, when I first started using ARM Cortex chips, I had to decide between STM32 and NXP LPC. One reason for choosing the STM32 was the better vendor library support at that time.
<re_irc>
<@ryan-summers:matrix.org> Just depends on your use case :) Like I said, some projects can't use vendor libs at all (or it's too onerous to do so)
<re_irc>
<@sourcebox:matrix.org> : I agree 100%, but these people don't realize it.
<re_irc>
<@sourcebox:matrix.org> The interesting question is though why the people are not considering Rust. The easy answer could be "because they're stupid", but it's not always that simple.
<re_irc>
<@ryan-summers:matrix.org> Talent is a huge one. Finding rust engineers is hard and they're expensive. Finding C/C++ engineers is easy and there's a lot of them.
<re_irc>
<@ryan-summers:matrix.org> Also comes down to toolchains and existing projects / systems at companies. Often times, they have projects going back like 10-20 years written in old languages, or they have tools already in place set up for C/C++ workflows, so the burden to transition to a new language is pretty high
<re_irc>
<@ryan-summers:matrix.org> But the second point mainly applies to larger, established companies. First point applies more to startups
<re_irc>
<@ryan-summers:matrix.org> * to both
<re_irc>
<@sourcebox:matrix.org> One argument that I also hear is, that they don't have the time for getting into it. That is indeed true, because they waste a lot of resources with getting the tooling right etc. And most of these companies are really small, even if they exist for a long time. You have a lot of generalist people there that work in many domains. And learning a new language is just a burden put on top.
<re_irc>
<@ryan-summers:matrix.org> Eh, but there's also a level as an engineer where you can pick up new tools and languages. I know I do it quite often personally. There's also companies that help deal with that, like ferrous
<re_irc>
<@ryan-summers:matrix.org> But those companies are generally taking the approach of "If it ain't broke, don't fix it" and see no need to innovate
<re_irc>
<@ryan-summers:matrix.org> +(in my opinion)
<re_irc>
<@jessebraham:matrix.org> : They hate us cuz they ain’t us 😉
<re_irc>
<@thejpster:matrix.org> I don't know how many chips Espressif sell per year, but I'm guessing it's not chicken feed. Those things are _everywhere_.
<re_irc>
<@sourcebox:matrix.org> As I already said, Espressif did a real good job in involving the community, even before Rust was a topic. I'm sure that's a reason why they are so popular.
<re_irc>
<@firefrommoonlight:matrix.org> They also did a good job of releasing cost-effective chips that have WiFi. Good niche that was unfilled
<re_irc>
<@firefrommoonlight:matrix.org> : A quick fix is for them to produce correct SVDs
<re_irc>
<@firefrommoonlight:matrix.org> +or similar
<re_irc>
<@sourcebox:matrix.org> : Having correct SVDs and therefore PACs is essential, but then the real work starts.
<re_irc>
<@sourcebox:matrix.org> : I appreciate all the work you did on the HAL and - in fact - I find them really usable. But I doubt you will be able to make them complete and maintain them in the long term as a single person.
<re_irc>
<@firefrommoonlight:matrix.org> The SVDs are the single biggest thing, but not the whole picture, ie subtle and not-so-subtle changes between variants, especially looking to the future
<re_irc>
<@firefrommoonlight:matrix.org> Reliable SVDs, I think would make this go from untenable to hard
<re_irc>
<@sourcebox:matrix.org> I my naive imagination, I would say that you have to talk with ST about these things and also about getting payed for the work and how to get more people involved.
<re_irc>
<@firefrommoonlight:matrix.org> Fun fact to tie these pts together: ESP is interested in paying Rust devs to maintain HALs (Not sure if doing it currently)
<re_irc>
<@jessebraham:matrix.org> We have had a Rust team at Espressif for nearly 2 years now
<re_irc>
<@jamesmunns:beeper.com> > ESP is interested in paying Rust devs to maintain HALs (Not sure if doing it currently)
<re_irc>
I mean they employ like 3+ person rust team full time :D
<re_irc>
<@jamesmunns:beeper.com> yeah :D
<re_irc>
<@jamesmunns:beeper.com> how many of y'all are there now?
<re_irc>
<@firefrommoonlight:matrix.org> I'm hoping St does something similar
<re_irc>
<@jessebraham:matrix.org> 6 full time, 2 interns
<re_irc>
<@sourcebox:matrix.org> Question is if it would make sense to actively contact ST about that.
<re_irc>
<@jamesmunns:beeper.com> I've ranted about this before, so I'll give the short version of my $0.02 on this:
<re_irc>
<@jamesmunns:beeper.com> - companies like ST have spent a lot of money on their existing tooling
<re_irc>
- to spend money on supporting something else, they need a really good reason, and "technically better" probably isn't as important to them as it is to us.
<re_irc>
- their existing tooling is what the majority of their customers use and "want"
<re_irc>
- the really good reason is money.
<re_irc>
* 1: lots of customers ask for it, who spend a lot of money
<re_irc>
- there are three cases to make on why rust would be worth it to them:
<re_irc>
* 2: they are convinced they are _losing_ money because people are choosing esp32 or infineon due to them having rust and st not
<re_irc>
* 3: they think that developing in rust would be net cheaper than developing in C
<re_irc>
<@jamesmunns:beeper.com> there's a case to be made, imo, for "reason 3", but that case is a LOT weaker without "reason 1" and "reason 2". Otherwise they are spending MORE money, because they have to support both
<re_irc>
<@ryan-summers:matrix.org> Yeah, I agree that thinking about this with money is 100% how to analyze these big companies :P
<re_irc>
<@ryan-summers:matrix.org> Same ideas apply to people _using_ rust
<re_irc>
<@jamesmunns:beeper.com> To "make rust happen", you need to find someone at ST (or similar) that has:
<re_irc>
- budget to hire or contract someone to do the work
<re_irc>
- authority to make the decision to spend that time and budget
<re_irc>
<@jamesmunns:beeper.com> the question is "who is that"? my answer is "I dunno". It needs to be someone reasonably senior, who can afford the time and salary of 1-6 engineers "indefinitely", until reasons 1, 2, and 3 start "paying out" more than they are "putting in"
<re_irc>
<@ryan-summers:matrix.org> Also, 1-6 engineers full time is _a lot of money_, so there needs to be the observed payout for them
<re_irc>
<@ryan-summers:matrix.org> Esp. if they're planning for long term (5+ years)
<re_irc>
<@sourcebox:matrix.org> But apparently ST has realized a few years ago that giving easy access to STM32 results in young engineers to use the platform and introduce it into their products. Something similar could happing with Rust.
<re_irc>
<@jamesmunns:beeper.com> Yeah, to justify a team of 3-4, they probably need to expect an increased PROFIT of 500k-1M, which depending on their margins, might mean increased sales of lets say 1M-5M of units. Which is a lot of chips.
<re_irc>
<@ryan-summers:matrix.org> The other driver would be if their users began demanding more rust support
<re_irc>
<@jamesmunns:beeper.com> (all numbers made up and imagined, I have no actual idea of ST's salaries or profit margins)
<re_irc>
<@ryan-summers:matrix.org> Which I think is more likely IMO
<re_irc>
<@jamesmunns:beeper.com> : yup! If you get one huge client, say "an Apple", or "a car vendor", that is spending 10s of millions of dollars/year on chips, who demands rust, or a LOT of little clients, who add up to a total of that much, then reasons 1 + 2 start carrying more weight
<re_irc>
<@jamesmunns:beeper.com> This is why I tell EVERYONE, if you have a sales rep/tech contact to ST/whoever, ask them as often as possible about their plan for rust!
<re_irc>
<@ryan-summers:matrix.org> That's why it's intriguing to see players like Microsoft start to embrace more rust
<re_irc>
<@juliand:fehler-in-der-matrix.de> : I recently discovered this project https://github.com/modm-io/modm-devices where apparently a lot of effort went into maintaining and correcting device information for a quite a number of chips. Maybe this could be of help for Rust here as well?
<re_irc>
<@jamesmunns:beeper.com> even if you "only" buy 10k a year in parts, you might be one of 100 people that ask.
<re_irc>
<@ryan-summers:matrix.org> Ah, but it looks like modm uses them to generate whole HALs instead of just PACs, so similar to embassy's approach I think
<re_irc>
<@juliand:fehler-in-der-matrix.de> Yes and apparently they are also parsing the datasheet PDFs and on top have some manual corrections
<re_irc>
<@juliand:fehler-in-der-matrix.de> As in: SVD file says X, datasheet says Y but the truth is Z or so.
<re_irc>
<@ryan-summers:matrix.org> It looks like the PDF parsing is done manually
<re_irc>
"We now have a toolbox that transcends its use as our C++ HAL generator and instead can be applied generically to any project in any language (*awkwardly winks at the Rust community*). That’s pretty powerful stuff."
<re_irc>
<@jamesmunns:beeper.com> Not saying "convincing vendors" isn't an effort worth making! But IMO if you want to be effective, it's important to "think like a business" and make a _business case_, rather than an appeal to "it's better". Because for businesses: making more money is the primary optimization factor.
<re_irc>
<@sourcebox:matrix.org> But you could also regard it as marketing budget.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Seems like the approach is similar. Might it be worth seeing if we could join forces somehow?
<re_irc>
<@jamesmunns:beeper.com> you never know! I have absolutely had clients (like, people making devices, not chips) that chose Rust even when the other proof points weren't there, or there wasn't a clear business case. But they were nearly universally either startups, where there was little to no momentum to overcome, OR places where that person had quite a bit of personal interest in rust, authority to make decisions (e.g. VP Eng, CTO), and/or there...
<re_irc>
... were some existing factors like "track record of reliability issues/bugs" that pushed them towards Rust
<re_irc>
<@jamesmunns:beeper.com> : Make a case! Nordic has sponsored Ferrous's events and efforts in the past as part of a marketing budget! Then you can make a business case for spending money/sponsoring. But they are more likely to sponsor events and ad videos/posts, rather than "recurring sponsorship of HAL maintenance efforts".
<re_irc>
<@jamesmunns:beeper.com> : Also while I'm on my soapbox: if they have something powerful, then do something with it! I think folks will be more receptive when they can see the benefit, e.g. get their tool spitting out a better Rust HAL than what stm32-rs does, or what embassy-stm32 does!
<re_irc>
<@jamesmunns:beeper.com> or: figure out how to feed the source of data from one project to another! You don't need anyone's approval, just make cool stuff :D
<re_irc>
<@sourcebox:matrix.org> Don't you think in the competion of ST, NXP and Infineon official Rust support is a selling point?
<re_irc>
<@sourcebox:matrix.org> * competition
<re_irc>
<@jamesmunns:beeper.com> : look at my post above. it isn't to ST until it is losing them sales in a measurable amount.
<re_irc>
<@ryan-summers:matrix.org> Also, looks like modm came out in 2018 or so, which was right as rust embedded was ramping up from what i recall?
<re_irc>
<@firefrommoonlight:matrix.org> : Yea - I'd love to see what that lib can do re spitting out a PAC lib for a single variant
<re_irc>
<@firefrommoonlight:matrix.org> May take a look when I have more bandwidth, but that's limited RN
<re_irc>
<@jamesmunns:beeper.com> again, this is all "in my opinion"! I have no secrets of their board or engineering planning meetings. Just a hunch from working in and working with big businesses before.
<re_irc>
<@sourcebox:matrix.org> : True, but you have to think about it in the long term.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Very good point. In fact, a good friend of mine knows the modm maintainers from university. I will ask around and see what we can do here. Would be a huge plus if it was usable for C++ and Rust efforts.
<re_irc>
<@jamesmunns:beeper.com> : _I_ am convinced! _They_ are not!
<re_irc>
<@jamesmunns:beeper.com> _They_ may or may not be convinced that Rust will be around in 5-10 years, or may or may not be used by the largest fraction of their customers in 5-10 years.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : I'll let you know once I talked to these guys
<re_irc>
<@jamesmunns:beeper.com> Their only feedback signals are "are my current customers using and asking for rust", "am I losing sales because people tell me Rust is a must-have", or "do my competitors seem to be attracting more customers because they support rust"
<re_irc>
<@jamesmunns:beeper.com> that's why it's AWESOME to have folks like ESP32 and Infineon officially supporting Rust.
<re_irc>
<@jamesmunns:beeper.com> because THAT registers on the radar of companies like ST and Nordic.
<re_irc>
<@jamesmunns:beeper.com> that is a market differentiator. But they still are probably going to "wait and see how it plays out for them", so that ESP32 and Infineon are taking the risk, and folks like ST can ideally be "late adopters" once it is a proven point, which they then hope they can catch up fast enough to not lose significant amounts of revenue.
<re_irc>
<@jamesmunns:beeper.com> (unless some other signal/datapoint falls onto their radar, like my reasons 1+2+3 above)
<re_irc>
<@jamesmunns:beeper.com> Big + conservative companies don't typically like to be risk takers or trailblazers. They like (reasonably) sure bets. That's why smaller companies (or smaller, more empowered teams at larger companies!) can make wins. But it's always a risk//reward calculation.
<re_irc>
<@jamesmunns:beeper.com> * risk/reward
<re_irc>
<@juliand:fehler-in-der-matrix.de> : That's a good point. And I think that rust is really good for young developers because it does not require huge amounts experience to not shoot you in the leg like with C all the time. And as more experienced developers retire, there might simply be no other option than using something more more, idk.
<re_irc>
<@sourcebox:matrix.org> More of a joke: we could try to get GigaDevice in the boat for their GD32 series ;-)
<re_irc>
<@jamesmunns:beeper.com> I do agree! I think that the "market forces" of "developers that use Rust will ship better things, faster" is where we want to end up, and there will be momentum building in that way, which then will end up with more companies demanding rust support so their teams can work faster.
<re_irc>
<@jamesmunns:beeper.com> : Honestly, yes, whoever! I would love to find a smaller silicon vendor, and help them make a badass HAL, and use it as a market differentiation to boost sales. If anyone has contacts, hit me up.
<re_irc>
<@ryan-summers:matrix.org> I like the "less shitty firmware" angle myself, but I come from the safety critical sector ;)
<re_irc>
<@jamesmunns:beeper.com> Yeah. I agree! Though we see that the _actual_ bar for most vendors is "just good enough it doesn't harm sales" :D
<re_irc>
<@jamesmunns:beeper.com> which is in itself an engineering calculation :D
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Absolutely. It's a lot quicker and you don't have to triple check for those stupid buffer overflows! ;p
<re_irc>
<@jamesmunns:beeper.com> (I'm not saying I _love_ this approach, or it _should_ be that way, just it's good to see things for what it likely is in reality)
<re_irc>
<@juliand:fehler-in-der-matrix.de> Presumably most developers would like to develop better quality products but simply don't have/get enough time to do so...
<re_irc>
<@dirbaio:matrix.org> : oh wtf it'd have been great to know about this before I started stm32-data lol
<re_irc>
<@ryan-summers:matrix.org> I know right, was thinking the same
<re_irc>
<@ryan-summers:matrix.org> Well, I didn't do the work, but still
<re_irc>
<@thejpster:matrix.org> That article is from 2018. Shame I hadn't come across it before.
<re_irc>
<@thejpster:matrix.org> It's almost as old at the Rust Embedded Working Group.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Is there any particular reason that would prevent doing something similar for Rust?
<re_irc>
Supporting different vendors from a single crate/project would be quite cool
<re_irc>
<@ryan-summers:matrix.org> That whole concept is very similar to embassy's approach, although embassy mainly does it for stm32 devices
<re_irc>
<@ryan-summers:matrix.org> In my opinion, I would claim that a lot of use cases for embedded make that impractical because you're always looking to optimize _something_ due to a constraint like size, battery capacity, or real-time speed
<re_irc>
<@ryan-summers:matrix.org> And generalizations generally work against those constraints, so you get priority inversions, which aren't great for design
<re_irc>
<@ryan-summers:matrix.org> But that's just my opinion
<re_irc>
<@juliand:fehler-in-der-matrix.de> That's a valid point. I agree.
<re_irc>
Still I feel like for prototyping and considering that there is such a huge variety of chips out there, it might be a got way to start. You can then still do optimizations based on what you get out of the general thing.
<re_irc>
Probably depends on what you want to do.
<re_irc>
<@firefrommoonlight:matrix.org> Yea. Not sure. Would have to explore a specific case and see how it works. I think you would be able to abstract some things like register names, addresses, field names and lengths etc
<re_irc>
<@firefrommoonlight:matrix.org> When looking at non-MCU ICs, things can get weird
<re_irc>
<@dirbaio:matrix.org> thing is different MCU families work very differently
<re_irc>
<@firefrommoonlight:matrix.org> Many have a register API like an Stm32 or whatever. Some use something more like a serial protocol. So e have bits that select different memories to read/write from etc, or change the meaning of an address to be a different reg
<re_irc>
<@dirbaio:matrix.org> for example in stm32 peripherals can only use some pins, but in nrf any peripheral can use any pin
<re_irc>
<@dngrs:matrix.org> micropython/circuitpython does a "cross vendor HAL" thing pretty well imo
<re_irc>
<@dirbaio:matrix.org> so making a single data model that can represent everything is hard
<re_irc>
<@dirbaio:matrix.org> and by making it so generic, you'll make it _worse_ at representing stm32 chips
<re_irc>
<@dngrs:matrix.org> but a tremendous amount of work has gone into it
<re_irc>
<@firefrommoonlight:matrix.org> Well, you don't have to worry about pins if the abstraction is reg level
<re_irc>
<@dirbaio:matrix.org> plus, you still need custom code in the HAL for nrf only, for stm32 only, etc
<re_irc>
<@dngrs:matrix.org> and it definitely comes with tradeoffs
<re_irc>
<@dirbaio:matrix.org> and
<re_irc>
<@dirbaio:matrix.org> for many chips, it's feasible to write the chip model in just Rust
<re_irc>
<@dirbaio:matrix.org> like, there's just 8 nrf chips
<re_irc>
<@dirbaio:matrix.org> the only reason stm32-data exists is because it's not feasible to do that for all 1400 stm32 chips
<re_irc>
<@dirbaio:matrix.org> for many chips, it's feasible to write the chip model in just Rust, by hand
<re_irc>
<@dirbaio:matrix.org> you don't gain development speed by trying to make the nrf chips go through the same model+codegen
<re_irc>
<@dirbaio:matrix.org> codegen is a pain to maintain
<re_irc>
<@ryan-summers:matrix.org> : Have you tried using micropython in a reliable system?
<re_irc>
<@ryan-summers:matrix.org> I absolutely loathe that I used it in one of our designs and I'm now actively ripping it off
<re_irc>
<@ryan-summers:matrix.org> It's too flaky
<re_irc>
<@dirbaio:matrix.org> but also, the C/C++ type system sucks, so codegening looks more appealing there
<re_irc>
<@dngrs:matrix.org> : I'd only use it for prototyping. But for that I think it's really cool
<re_irc>
<@dngrs:matrix.org> it's definitely not very reliable
<re_irc>
<@ryan-summers:matrix.org> Yeah, we have it on a test system for talking to I2C voltage/current/power sensors and GPIO, and it's been a pain in automated environments
<re_irc>
<@joelsa:fehler-in-der-matrix.de> : I think the layering of HAL/Driver/Application is solid and the Interfaces between them need to be sufficiently narrow that the code base residing in individual layers can be considered a somewhat disjoint set. Having defined APIs at the intersection points is definitively useful, and the „A“ should be put into HAL.
<re_irc>
Concerning the generalizations, there is always a tradeoff between ease of development and fitness of the result for a given purpose. But in many cases the generalization saves a lot of time and introduces only a slight performance penalty. Bricks are a reasonable generalization for buildings and the fixed distance between gas pedal and front axle in all VW cars is a reasonable generalization for cars.
<re_irc>
The advantage is that you can usually avoid generalizations, i.e. you don’t have to follow them, but inventing them on your own is time consuming.
<re_irc>
<@firefrommoonlight:matrix.org> Concur on this problem being uniqueish to St and similar due to mass amt of variants
<re_irc>
<@firefrommoonlight:matrix.org> This is also one of the reasons Stm32 is so nice: you can learn one MCU, then use the same knowledge and code for a different set of requirements
<re_irc>
<@bugadani:matrix.org> : not to mention the similar amount of clones that use ST's numbering scheme but aren't actually 1:1 copies so the amount of variations multiplies like rabbits
<re_irc>
<@firefrommoonlight:matrix.org> You can write mostly the same code for a super low-cost/simple device, a powerful one running DSP, one with hundreds of IOs, etc
<re_irc>
<@firefrommoonlight:matrix.org> While nRF, with its simplicity, is "battery-powered BT or cell data device"
<re_irc>
<@dirbaio:matrix.org> except each stm32 family has its own gotchas
<re_irc>
<@dirbaio:matrix.org> different RCC curses
<re_irc>
<@firefrommoonlight:matrix.org> Yea that's why it's a problem
<re_irc>
<@dirbaio:matrix.org> different magic pins that don't work or do different things unless you poke some magic register
<re_irc>
<@bugadani:matrix.org> : even ST tended to trip up on this a few years ago...
<re_irc>
<@dirbaio:matrix.org> +to make them "normal"
<re_irc>
<@dngrs:matrix.org> I like it when ST clones fix ST errata
<re_irc>
<@dirbaio:matrix.org> each family they launch, they toss a coin whether they'll include USBD or OTG
<re_irc>
<@firefrommoonlight:matrix.org> I hate that so much
<re_irc>
<@firefrommoonlight:matrix.org> At least one family mixes the 2
<re_irc>
<@dirbaio:matrix.org> it used to be "OTG if we want usb host support, otherwise USBD for device-only"
<re_irc>
<@firefrommoonlight:matrix.org> And the FS vs HS is a headache
<re_irc>
<@dirbaio:matrix.org> except some newer ones have USBD with host mode support 🤪
<re_irc>
<@firefrommoonlight:matrix.org> Even in the same family the terms are used to mean different things or not depending on context
<re_irc>
<@firefrommoonlight:matrix.org> So yea, St differences can be a pain, which was how this Convo started. But there's so much hardware and docs overlap between them it's a true asset, and why I use them
<re_irc>
<@bugadani:matrix.org> : They didn't even license the bugs 🙃
<re_irc>
<@joelsa:fehler-in-der-matrix.de> : Yeah, especially the GD Guys fix more Bugs than ST does
<re_irc>
<@firefrommoonlight:matrix.org> There are Stm32s at so many price/size/capability points
<re_irc>
<@bugadani:matrix.org> my first job included a firmware that used a timer that didn't exist according to the datasheets... thank G I forget quickly
<re_irc>
<@dirbaio:matrix.org> ST copying everything Nordic does
<re_irc>
<@dirbaio:matrix.org> first the stm32wb, then this :D
<re_irc>
<@firefrommoonlight:matrix.org> So, maybe this one will be in stock
<re_irc>
<@firefrommoonlight:matrix.org> I don't own a Nordic one BC it's unstocked
<re_irc>
<@firefrommoonlight:matrix.org> Oh wait it's ST makes this one FML
<re_irc>
<@bugadani:matrix.org> : do they have usable hardware events now? I kinda liked that in the nRFs
<re_irc>
<@dirbaio:matrix.org> they have the "interconnect matrix", but it's much less general than the nrf's ppi
<re_irc>
<@bugadani:matrix.org> is it still a restricted one where you have 2-3 options where you can map something? I'm the kind of guy who routinely mixes up 2 pins while drawing hardware, I've wasted a few pcbs on that 🤦♂️
<re_irc>
<@bugadani:matrix.org> give me a pair of MISO and MOSI and I'll get it wrong 3 times out of 4, which is _only_ an issue with STMs
<re_irc>
<@bugadani:matrix.org> oh, hm, well, what I wrote is true but I see the interconnect matrix is something else
<re_irc>
<@bugadani:matrix.org> is it (silly me talking about GPIOs here...) still a restricted one where you have 2-3 options where you can map something? I'm the kind of guy who routinely mixes up 2 pins while drawing hardware, I've wasted a few pcbs on that 🤦♂️
<re_irc>
<@bugadani:matrix.org> is it (silly me talking about GPIOs and alternate functions here...) still a restricted one where you have 2-3 options where you can map something? I'm the kind of guy who routinely mixes up 2 pins while drawing hardware, I've wasted a few pcbs on that 🤦♂️
<re_irc>
<@firefrommoonlight:matrix.org> Tx and Rx is like pre-C USB
<re_irc>
<@firefrommoonlight:matrix.org> Yes you will only have a few optiosn for a given periph on STM32
<re_irc>
<@firefrommoonlight:matrix.org> Your options go up with footprint size
<re_irc>
<@firefrommoonlight:matrix.org> RN I am having a strug on an otherwise ideal-for-the-job MCU where I want USB and CAN. I don't need them at once and understand that's a more fundamental issue. But they share teh same pins at this footprint
<re_irc>
<@firefrommoonlight:matrix.org> I thought I could just share the wires, but it is not working and I am highly suspicious it's due to this
<re_irc>
<@firefrommoonlight:matrix.org> Can't even get DFU
<re_irc>
<@firefrommoonlight:matrix.org> RN I am having a strug on an otherwise ideal-for-the-job MCU where I want USB and CAN. I don't need them at once and understand that's a more fundamental issue due to shared RAM. But they share teh same pins at this footprint
<re_irc>
<@firefrommoonlight:matrix.org> Of note on a similar STM32 that has more pins I have both CAN and USB working (separately), and it's fine BC they are not on the same pins
<re_irc>
<@joelsa:fehler-in-der-matrix.de> : In principle even the most basic STM32s can do CAN and USB simultaneous if there is no pin collision.
<re_irc>
<@joelsa:fehler-in-der-matrix.de> Avoid the F103 or the smaller F042 packages for that
<re_irc>
<@joelsa:fehler-in-der-matrix.de> : That should work in principle, is there a CAN Transceiver connected?
<re_irc>
<@dirbaio:matrix.org> share wires between CAN and USB? how??
<re_irc>
<@timokrgr:matrix.org> some STM32 share a special memory region between B them IIRC
<re_irc>
<@timokrgr:matrix.org> between USB and CAN*
<re_irc>
<@dirbaio:matrix.org> yea, the USB packet RAM
<re_irc>
<@dirbaio:matrix.org> but sharing the _wires_??
<re_irc>
<@timokrgr:matrix.org> oh lol helps if I read the the backlog
<re_irc>
<@joelsa:fehler-in-der-matrix.de> Sure, as long as you disable the interface that’s not in use. E.g. have the two on the PCB and use it either with USB or with CAN by disabling the Transceiver in the one case and not connecting USB in the other.
<re_irc>
<@joelsa:fehler-in-der-matrix.de> At least I understood that’s the proposal
<re_irc>
<@firefrommoonlight:matrix.org> : Like, I just did it. To see if it would work, you know?
<re_irc>
<@firefrommoonlight:matrix.org> Since I am not sure what other options I have
<re_irc>
<@firefrommoonlight:matrix.org> This is the _perfect_ MCU otherwise
<re_irc>
<@firefrommoonlight:matrix.org> G431 in QFN48
<re_irc>
<@dirbaio:matrix.org> usb and can running concurrently?
<re_irc>
<@dirbaio:matrix.org> or one or the other, but not at the same time? 😂
<re_irc>
<@firefrommoonlight:matrix.org> Reqs are cheap, easy to get, does FDCAN and the standard on-board busses etc. G431 is too perf
<re_irc>
<@firefrommoonlight:matrix.org> But the USB and FDCAN share teh same fucking pins
<re_irc>
<@firefrommoonlight:matrix.org> FML
<re_irc>
<@firefrommoonlight:matrix.org> Oh you can deconflict by using Boot0; yea no
<re_irc>
<@firefrommoonlight:matrix.org> Also CAN and USB share teh same RAM. I think you may be able to deconflict it somehow but not sure.
<re_irc>
<@firefrommoonlight:matrix.org> I only need one at a time
<re_irc>
<@firefrommoonlight:matrix.org> USB is just for firmware update and configuration via PC software (Can do both via CAN do actually but I want both)
<re_irc>
<@firefrommoonlight:matrix.org> * too
<re_irc>
<@firefrommoonlight:matrix.org> joelsa: Yes there is a tranciever
<re_irc>
<@firefrommoonlight:matrix.org> At first attempt, it does not, in fact work, in case that wasn't clear
<re_irc>
<@firefrommoonlight:matrix.org> *CAN works but USB is dead
<re_irc>
<@dirbaio:matrix.org> fun!
<re_irc>
<@firefrommoonlight:matrix.org> Btw I have a H7 board where I do have USB and CAN working, althoug not at teh same time. I think I can fix that by reassigning the CAN message RAM. I think on G4 it may be fixed though
<re_irc>
<@firefrommoonlight:matrix.org> Because the pins are not shared
<re_irc>
<@firefrommoonlight:matrix.org> Btw I have a H7 board where I do have USB and CAN working, althoug not at teh same time. I think I can fix that by reassigning the CAN message RAM. I think on G4 the msg ram is not customizable
<re_irc>
<@dirbaio:matrix.org> H7 is OTG which doesn't use that pktram, it has its own fifo thing (I think?)
<re_irc>
<@dirbaio:matrix.org> on chips with USBD+CAN, I think you can set BTABLE on the USBD side to make USBD use the top half and CAN the bottom half (?)
<re_irc>
<@joelsa:fehler-in-der-matrix.de> So you want to switch the configuration while the Micro is running?
<re_irc>
<@firefrommoonlight:matrix.org> Yea
<re_irc>
<@firefrommoonlight:matrix.org> Or before it runs ie if loading DFU mode
<re_irc>
<@firefrommoonlight:matrix.org> The USB is just for config and sys status on both teh G4 and H7 devs
<re_irc>
<@firefrommoonlight:matrix.org> (So only an issue on the pin-sharing G4 board)
<re_irc>
<@joelsa:fehler-in-der-matrix.de> Okay, that’s another story
<re_irc>
<@joelsa:fehler-in-der-matrix.de> Would the STM32F072xB be adequate?
<re_irc>
<@dirbaio:matrix.org> bitbang the usb 🤪
<re_irc>
<@dirbaio:matrix.org> or add a usb-to-uart!, or a cheap G0
<re_irc>
<@dirbaio:matrix.org> though at that point it's probably just cheaper to get a bigger main mcu
<re_irc>
<@firefrommoonlight:matrix.org> Yea those are options
<re_irc>
<@alexmoon:matrix.org> You could use a solid-state analog switch to disconnect the CAN bus when USB is connected
<re_irc>
<@firefrommoonlight:matrix.org> Actually that may be the play
<re_irc>
<@firefrommoonlight:matrix.org> Was possibly thinking a jumper as a low-tech soln
<re_irc>
<@firefrommoonlight:matrix.org> I actually half-expected my naive design to work, but I understand USB (Even 2.0) is subject to RF magic due to the reasonably high speeds involved
<re_irc>
<@firefrommoonlight:matrix.org> (I have USB DP and CAN TX on the same net; there are independent nets for CAN RX and USB DM)
<re_irc>
<@firefrommoonlight:matrix.org> I could try ripping out the CAN tranciever to see if that helps
<re_irc>
<@firefrommoonlight:matrix.org> If so, your idea would work
<re_irc>
<@firefrommoonlight:matrix.org> Other than RF magic or signals on the CAN line, could also be an impedance thing from the tranceiver.
IlPalazzo-ojiisa has quit [Remote host closed the connection]