<firefrommoonligh>
We've discussed this, but from what I gather, they originated from initially people applying rust to embedded treated it as a safety-first mindset. Everything was built around leveraging rust's features for memory safety. I like rust because it's a nice overall lang, and IMO the nicest of the small set that can be used for embedded. So, just want to make firmware with code that's easy to write and maintain.
<firefrommoonligh>
s/initially//
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
dreamcat4 has quit [Ping timeout: 245 seconds]
dreamcat4 has joined #rust-embedded
_whitelogger has joined #rust-embedded
haobogu[m] has joined #rust-embedded
<haobogu[m]>
<adamgreig[m]> "4) we clarified that DMA is fine..." <- I'm wondering how to deal with problems like cache inconsistency with DMA? I don't know whether "normal fences and suitable mmio access" are enough.
<jannic[m]>
That needs to be covered by the firmware, rust (the compiler) can't know about it. Perhaps "normal fences" is too vague. https://github.com/rust-lang/unsafe-code-guidelines/issues/321#issuecomment-2894697770 describes it as "one has to put a suitable fence between the DMA accesses and the final MMIO access". Of course it still doesn't say what fence would be "suitable", but that's probably nothing the rust compiler spec can describe,
<jannic[m]>
as it's very hardware specific.
rafael[m] has quit [Quit: Idle timeout reached: 172800s]
<haobogu[m]>
Yeah, I agree that it's very hardware related. So generally, the hal authors are the person who need to play with it?
<Max[m]>
<Noah[m]> "Can you try and uncomment this..." <- will test today
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
<jannic[m]>
Yes - or whoever wants to implement a safe DMA API based on the low-level operations provided by Rust.
exark_ has joined #rust-embedded
exark has quit [Ping timeout: 252 seconds]
Artea has quit [Ping timeout: 252 seconds]
<haobogu[m]>
That makes lots of sense, thank you!
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
Artea has joined #rust-embedded
pcs38 has joined #rust-embedded
<Max[m]>
<Max[m]> "will test today" <- i commented this part "Check if the AP is accessible"
<Max[m]>
<Max[m]> "will test today" <- but not change
<RobinMueller[m]>
* instance trait of bxcan just expects, * the peripheral register block pointer, but
<RobinMueller[m]>
background: I am trying to make https://github.com/samcrow/canadensis work, adn there is bxcan support, but that was only implemented for the bxcan library, not for the embassy-stm32 CAN implementation
<dcz[m]>
thanks to whoever mentioned trouble, this channel is a good information trove. I always wanted blob-free Bluetooth
<jason-kairos[m]>
I've got a situation where I would like to store a list of variable length structures (something like `address: u8`, `length: u8`, `data: [u8; length]`)
<jason-kairos[m]>
And I'd like to not waste any memory.
<jason-kairos[m]>
Are there any good alternatives to using an heap allocator like `heapless` ? (I don't really want to write yet another custom buffer in the name of efficiency/performance/etc.)
<jason-kairos[m]>
* I've got a situation where I would like to store a list of messages / variable length structures (something like `address: u8`, `length: u8`, `data: [u8; length]`)
<jason-kairos[m]>
I'd like to fit as many messages as possible into a fixed sized piece of memory. And I'd like to not waste any memory.
<jason-kairos[m]>
Are there any good alternatives to using an heap allocator like `heapless` ? (I don't really want to write yet another custom buffer in the name of efficiency/performance/etc.)
<JamesMunns[m]>
heapless isn't an allocator, btw.
<JamesMunns[m]>
it is collections that have a max size, usually on the stack
<JamesMunns[m]>
so `length` would have an upperbound, like `Vec<u8, 16>`
<jason-kairos[m]>
that goes to show my inexperience and aversion to using the heap on embedded (in rust).
<jason-kairos[m]>
fragmentation 'scares me'
<JamesMunns[m]>
there's really no magic, if you want variable sized data, you have to figure out where to store it. you can have it locally, with a maximal upper bound (at the cost of "waste" when you don't use much), or you can use a general purpose alloc, or use your own pool alloc (again, with slots that may have variable "efficiency")
<JamesMunns[m]>
rust doesn't have anything like alloca, so there are no vlas or anything
<jason-kairos[m]>
I am not confident how it works under the hood, but I am beginning to suspect that it may allow me to allocate Boxes in different static mut heaps'
<jason-kairos[m]>
it's a shame boxed requires unstable
<sourcebox[m]>
heapless does not use a heap, hence the name. But yes, you can force it to use a heap if you really want it.
<jason-kairos[m]>
what is the 'arm_llsc' platform? ("low level single core?")
<jason-kairos[m]>
no implementators of BoxPool, and it doesn't seem to implement `free` so I guess it is sort of pointless
<jason-kairos[m]>
haobogu[m]: Does it implement 'free' ? (when the box is dropped, does it free the memory?)
<jason-kairos[m]>
I took a cursory glance at it and failed to convince myself that it does. ("I dunno") I guess I should build a prototype to find out
<haobogu[m]>
jason-kairos[m]: seems no. the `box_pool!` macro makes the pool a static singleton
<haobogu[m]>
In your case, I think a heapless::Vec with a big enough capacity is enough
<jason-kairos[m]>
that leads me back to wanting to use embedded-alloc with a custom (stable) box type that lets one specify the allocator ("How hard could it be to rewrite box, or find some crate that already has done the same?")
<dirbaio[m]>
heapless::Pool is not a heap, it allocates/frees N equal objects, it doesn't allow allocating/freeing objects of arbitrary size only known at runtime
<Noah[m]>
<Max[m]> "no change in the output" <- ok then I am not sure why that PR would be the first bad one :/
<Max[m]>
Noah[m]: maybe i had the wrong assumptions with the good commit
<Max[m]>
Max[m]: latest 0.29 gives the same output btw
<jason-kairos[m]>
Side tangent: I wish I could search crates.io for a function/method that takes a generic of type Allocator and contains the word new
<Noah[m]>
<Max[m]> "```─ ROM Table (Class 1), Design..." <- > should the output show both the m7 and m4 ?
<Noah[m]>
technically, I think it should. but those chips often do weird stuff that if debug facilities are powwered down they only show half the romtable and such
<Noah[m]>
Noah[m]: did you comment out both things now or just the first (I thought just the first did not change behavior earlier)
<Noah[m]>
* > should the output show both the m7 and m4 ?
<Noah[m]>
technically, I think it should. but those chips often do weird stuff that if debug facilities are powwered down they only show half the romtable and such
<jason-kairos[m]>
dang, core::Allocator is just as unstable as std::boxed::Box::new_in I should have seen that coming
jfsimon has quit [Ping timeout: 260 seconds]
<jason-kairos[m]>
in `no_std`
<jason-kairos[m]>
I'd like to confirm that the rust language crate `alloc` is different from `core::alloc` and that it really is necessary to `extern alloc` to use types like `Vec` ?
<jason-kairos[m]>
'feels weird' (but I guess it's just unfamiliar)
<JamesMunns[m]>
alloc is indeed a separate crate, technically core, alloc, and std are three different crates, std re-exports items from core and alloc, and adds addtional os-specific items.
<JamesMunns[m]>
so if you are no_std, then you need to explicitly bring in the alloc crate to obtain the items that exist there, but not in core.
<jason-kairos[m]>
and extern is the way to do it I guess? (rather than adding a cargo dependency, since its included with the compiler)
<JamesMunns[m]>
yes, you just need `extern crate alloc`, which was actually the old way of declaring ALL external crate dependencies. These days, you can use `use cratename` to do that, but only for crates declared as cargo deps, which you can't/don't do for `alloc`, because it is special.
<JamesMunns[m]>
you can also `extern crate std`, but it won't work for embedded targets that don't have a prebuilt `std` library.
<JamesMunns[m]>
(it does work on desktop targets that are marked no_std)
<jason-kairos[m]>
side tangent question: are there any other contexts in which one would use extern nowadays? (I can possibly imagine some "cursed" scenarios, but nothing legitimate)
<jason-kairos[m]>
* would use `extern, * extern` nowadays?
ana_briated has joined #rust-embedded
<jason-kairos[m]>
* would use `extern, * extern` nowadays?, * nothing legitimate for kernel, embedded, or normal rust programs)
<JamesMunns[m]>
not normally. there might be some cases where it's easier to do that in some feature-gated modules, it's not *wrong*, it's just not "idiomatic" in most cases these days.
<whitequark[cis]>
you still need to use extern crate x; if including a crate has side effects, no?
<whitequark[cis]>
like adding something your linker script expects
<JamesMunns[m]>
I think these days you can do use unused_crate as _;
<JamesMunns[m]>
like if you don't need any direct rust symbols from the crate, but it includes some static. you see that a bunch with `defmt_rtt` which includes a linker blob for the rtt header
<whitequark[cis]>
ohhh, makes sense, thanks
<JamesMunns[m]>
yeah, I THINK all the old reasons for using extern crate over use have gone away, EXCEPT for pulling in alloc or std when you have opted out of them with #![no_std]
<JamesMunns[m]>
(this definitely didn't USE to be the case, but I think editions 2018 and 2021 took care of most/all of those?
<JamesMunns[m]>
* of those?)
<JamesMunns[m]>
it was stuff like that, macro imports, maybe some other stuff I've forgotten?
<jason-kairos[m]>
another side question: is `Option<Box<T>>` just a pointer that is non-zero?
<jason-kairos[m]>
(ie. is it equivalent to `Option<NonNull<T>>`)
<JamesMunns[m]>
look up "niche packing", I think `Option<Box<T>>` is the same size as `Box<T>`
<firefrommoonligh>
Like if let, I'm not sure how it makes sense intuitively, but move past that; learn it; love it; don't get the syntax backwards
<firefrommoonligh>
* Like if let, I'm not sure how the syntax makes sense intuitively, but move past that; learn it; love it; don't get the syntax backwards
<jason-kairos[m]>
nevermind: that was a silly question. I think I forgot to import a trait related to embedded-alloc. so I couldn't directly access allocator functions
<jason-kairos[m]>
silly question about vec:
<jason-kairos[m]>
do we really have to `try_reserve` before each `push` to avoid a panic? I'm surprised there is no `try_push`
<jason-kairos[m]>
* silly question about `alloc::vec`
<jason-kairos[m]>
do we really have to `try_reserve` before each `push` to avoid a panic? I'm surprised there is no `try_push`
pcs38 has joined #rust-embedded
<thejpster[m]>
<jason-kairos[m]> "it is..." <- No, it is not. It is complicated.
<thejpster[m]>
You can read ~/.rustup/toolchains/stable-aarch64-apple-darwin/share/doc/rust/COPYRIGHT-library.html
<thejpster[m]>
ok, well, it is. But also it is complicated.
<jason-kairos[m]>
thejpster[m]: Is there a particular fashion that I should be aware of in which it might be complicated?
<thejpster[m]>
some of the libstd dependencies are not strictly MIT / Apache 2.0
<thejpster[m]>
if you are copy/pasting source code from it, most of the in-tree stuff is MIT || Apache 2.0, so you're fine if you meet those licence terms
<i509vcb[m]>
Listing fortanix-sgx-abi (MPL 2.0) is maybe a little too conservative in some ways since an aarch64/armv7 binary is not going to link with a x86_64-fortanix-unknown-sgx target.
<jason-kairos[m]>
Yup. (I didn't actually end up using it)
<jason-kairos[m]>
I have probably 40 pages of open source license disclosures that I've generated for the product I'm developing. Sort of a hassle.
<thejpster[m]>
i509vcb: the tooling is not target aware, no
<thejpster[m]>
it also isn't aware which parts of the tree are compiled in any given release. It just looks at the tree and at all the dependencies.
<jason-kairos[m]>
thejpster[m]: Seem reasonable (I didn't end up using it after all)
<jason-kairos[m]>
So far it seems like I've generated 40 pages of open source license disclosures and counting for the product I'm developing. Sort of a hassle to publish all of that and keep it up to date.
<jason-kairos[m]>
* I've generated what feels like 40 pages, * 40 pages (and counting) of open
<jason-kairos[m]>
* Seem reasonable (I didn't end up using it after all)
<jason-kairos[m]>
So far it seems like I've generated what feels like 40 pages (and counting) of open source license disclosures for the product I'm developing. Sort of a hassle to publish all of that and keep it up to date.
<thejpster[m]>
hence I wrote a tool to do it
<thejpster[m]>
the COPYRIGHT.html and COPYRIGHT-library.html files are auto-generated by bootstrap and shipped with the binary distributions
<thejpster[m]>
the MIT terms are much more onerous than people realise, and Cargo.toml's authors field is not sufficient (the licence doesn't say to repeat the authors field, it says to report the copyright line from the LICENSE-MIT file)
<thejpster[m]>
Also people love to modify the Apache 2.0 licence text, replacing brackets to make it markdown compliant, or indenting things a bit differently. Or incorrectly modifying the template appendix at the end, to require you to place you code under their copyright if you follow the instructions for putting your own code under Apache 2.0. Hence why that file contains a dozen copies of the licence text - I include it verbatim, mistakes
<jason-kairos[m]>
that stuff I am seeing looks sort of complicate to apply to a project (it's not like a cargo do-something utility that automatically spits out a zip file)
<jason-kairos[m]>
`cargo bundle-licenses`
<jason-kairos[m]>
`cargo about`
<jason-kairos[m]>
look easy, don't know if they really do the same thing
<JamesMunns[m]>
(note that this post predates `defmt`, which is why it isn't mentioned in this article)
<jason-kairos[m]>
I am envious of those who can use tools like defmt
<jason-kairos[m]>
I am held back by technical restrictions (interoperability with third party libraries and tooling)
<jason-kairos[m]>
* I am envious of those who can use tools like defmt
<jason-kairos[m]>
My project is held back from using that sort of technique due to technical restrictions (interoperability with third party libraries and tooling)
<jason-kairos[m]>
I need to read that more closely. But his remarks about the desirability of plugging in lighter-weight formatting machinery rings true with me.
<JamesMunns[m]>
(he is me)
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
<firefrommoonligh>
defmt slaps
<jason-kairos[m]>
<JamesMunns[m]> "(he is me)" <- Oh 😅
<jason-kairos[m]>
"I suppose that supports my claim that I need to read the article more closely" (heh...)
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]>
I was thinking to myself 'gee, how does he find those articles so quickly'
<jason-kairos[m]>
* so quickly' - faster than google could return a query
<JamesMunns[m]>
I also do a lot of consulting, so I do have a lot of citations and slide decks to hand to back up the things I claim :D
<JamesMunns[m]>
(even when I'm not the one that wrote it)
<therealprof[m]>
<JamesMunns[m]> "Sadly still true, 5.5y later." <- Much to my surprise it has recently gotten a lot better... After getting back from RustWeek I compiled an old project with the latest rustc and the binary shrunk from 18kB to 15.5kB mostly due to formatting code.
jbeaurivage[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]