Alistair[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has joined #rust-embedded
<korken89[m]>
Does anyone know of a tool that can parse a C header file to an SVD? The manufacturer of a chip we need refuses to give out the SVD file, but we have the C header file that was generated from their internal SVD file.
<SiHo[m]1>
Talk about a wish for this type of tool. If the chip manufacturer support Zephyr walking back from DTS could be easier than provided header.
<SiHo[m]1>
If it's any consolidation my best guess is that the chip manufacturer generates 1 SVD and uses a tool to strip out the "testing/secret/internal" registers :)
<SiHo[m]1>
* "testing/secret/internal" registers from the headers :)
<korken89[m]>
I think so too, and I'm starting to accept my fate of C header parsing 🪦
<M9names[m]>
you know that you can send code + data to the cloud, right? via ssh.
<M9names[m]>
why bother pretending you have hardware locally when you could just run the program where the hardware lives, and just send back the result?
<mameluc[m]>
clink and tensorlink pretty much forwards cuda over the network
<mameluc[m]>
but how it relates to rust embedded idk 😅
<K900>
You've already asked this too
<K900>
In the main Rust room
<K900>
And the answer is "no, it does not work for a variety of reasons"
<SiHo[m]1>
<mameluc[m]> "clink and tensorlink pretty much..." <- I think he has his answer here :D It's already implemented and not a novel idea.
lehmrob has quit [Remote host closed the connection]
haobogu[m] has joined #rust-embedded
<haobogu[m]>
Hi everyone, I’m trying to write an universal spi flash library like https://github.com/armink/SFUD in rust. I want to implement embedded-storage trait, but I found it’s impossible because embedded-storage requires associated constant like WRITE_SIZE and READ_SIZE, which should be read from the flash in JEDEC’s SFDP standard. Im curious that is there any special reason that embedded-storage chose to use associated constant?
<dirbaio[m]>
the reason is with associated consts crates like ekv or sequential-storage can calculate the exact buffer sizes for their data structures et
<dirbaio[m]>
s/et/etc/
<dirbaio[m]>
the downside is it's fixed at compile time, yes
<dirbaio[m]>
you can make the user provide the values for the associated consts, and at runtime read the jedec thing and panic if the user got them wrong
<dirbaio[m]>
and/or make embedded-storage optional. one struct without generic params that implements your own api with sizes known at runtime, and another with the generic params that impls embedded-storage and does this checking
<haobogu[m]>
Is it safe to totally ignore the associated const and use the read value at runtime? That means users can fill any value to them.
<haobogu[m]>
Oh that might fail with the downside usages of ekv or sequential-storage
<dirbaio[m]>
yeah you'd be violating the trait contract if you did that
<dirbaio[m]>
if you put something in ERASE_SIZE libs will expect an erase can erase that size. things will break if the actual erase size is higher
<dirbaio[m]>
interestingly you can "lie" with a too high erase/read/write size because you can always emulate a bigger erase with N smaller erases
<dirbaio[m]>
but you can't lie with a too small size
<haobogu[m]>
Yeah, that seems not the right way todo it
<haobogu[m]>
And, is it possible to add a trait to embedded-storage without associate const, use something like get_write_size() instead? Some MCUs uses external flash may have similar problem imo
<dirbaio[m]>
having two traits would suck
<JamesMunns[m]>
I will say: There's a LOT to be done to build a good filesystem - I'd suggest figuring out what YOU need from an interface, before worrying about making the interface fit your needs!
<dirbaio[m]>
the whole point of these trait crates is to enable any driver crate to work with any database/filesystem crate
<JamesMunns[m]>
like - good to keep portability in mind! But it'll be much easier to figure out the interface/trait you need when you know what your library needs, API wise.
<dirbaio[m]>
IMO we should have one trait. Sizes either fixed at compile time, or obtained at runtime, not both.
<dirbaio[m]>
and obtaining the sizes at runtime would make life quite a bit harder for fs/db crates...
<dirbaio[m]>
if you want to support size obtained at runtime, i'd recommend you do the two APIs. Custom API with size obtained at runtime (no trait), and another struct wrapping that and implementing embedded-storage
<dirbaio[m]>
then you get the best of both worlds
<dirbaio[m]>
I think that gives you the best of both worlds
<dirbaio[m]>
because if you use a db/fs you're typically building "a complete product", so you pick one particular flash model, so fixing the sizes at compile time is not that bad
<dirbaio[m]>
it's a bit rare to want to use a db/fs but let the user plug in any arbitrary NOR flash for it I think
<dirbaio[m]>
vs for other use cases dynamically detecting the parameters can make sense. for example if you're making a flash reader/writer dev tool.
<dirbaio[m]>
in that case you don't need embedded-storage, because you're just building everything yourself, so having to use the custom api is not that bad
<dirbaio[m]>
(?)
<haobogu[m]>
I got your point. For end users, using fixed siezes at compile time is natural. I’m building the driver library, maybe providing two apis is the better way
<haobogu[m]>
Actually I don’t really care about the downside usages like db/fs. I’m just providing a universal flash write/read driver. That’s why I have this question. Thanks for your guys explaining the underlying considerations of the trait design. :)
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
<bartmassey[m]>
As far as converting device tree DTS to PAC, I looked at this a while back and concluded that the DTS generally doesn't have enough information to do a lot of it. It could be a starting point, but you'd still really have to work at it. I forget what was missing for the DTS I looked at, but it was enough to make me a bit skeptical.
<bartmassey[m]>
Another approach people have used is to write custom code to scrape the device reference manual to build an SVD: for example https://github.com/grinux/sunxi-svd. Those SVDs need some serious editing, though. This is pretty gross, but maybe possibly beats constructing the PAC manually?
cr1901_ is now known as cr1901
AtleoS has quit [Ping timeout: 260 seconds]
AtleoS has joined #rust-embedded
<dngrs[m]>
vollbrecht: I opened an [issue](https://github.com/rust-embedded/book/issues/375) for the embedded Rust book to explain futures size explosion, thanks again for your links and tips, I added them there; if there's anything you feel like adding I think it could be valuable
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
<RockBoynton[m]> "how does svd2rust handle this?..." <- Iirc, it models every register as a native platform integer. So the least significant bit of the int would be bit 0 and it would have the endianness of an integer, so usually LE
<diondokter[m]>
That doesn't work for device-driver though since registers can have arbitrary sizes and devices may have different opinions on endianness
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
korken89 po8: I wrote a tool that parses DTB (binary of DTS), and generates a SVD file. it needs to know about any peripherals on the SoC, and the current set it knows about is relatively small
<rmsyn[m]>
I've tried to make adding a new peripheral module fairly easy, and if you can share the chip you're working on, I can help you start adding missing peripherals
<bartmassey[m]>
@rmsyn That's cool. Thanks!
<rmsyn[m]>
thanks :)
<rmsyn[m]>
hopefully it helps
<rmsyn[m]>
currently going through the peripheral definitions to add write constraints where it makes sense + some QoL improvements
<rmsyn[m]>
mostly for an upgrade to the latest minor release of svd2rust
Gewinum[m] has quit [Quit: Idle timeout reached: 172800s]
<bartmassey[m]>
adamgreig: James Munns: et al I'm cancelling the Book Sprint for low participation. Thanks for offering to help. We'll try again for October.
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
rom4ik13 has joined #rust-embedded
vanner has joined #rust-embedded
rom4ik1 has quit [Quit: Ping timeout (120 seconds)]