<FrreJacques[m]>
I realized yesterday that the driver I am writing has a potentially bigger scope than just 16*02 LCDs as most of those dot matrix LCDs use the same chip.
<FrreJacques[m]>
With that information I looked up crates.io for a better name and found out that there exist even multiple async drivers.
<FrreJacques[m]>
Kind of a bummer, but I think since I invested a lot of time into it already, it might be okay to put it to crates.io too.
<M9names[m]>
crates.io is for sharing. if there's no reason for anyone else to use your crate, there's not really any reason to add it to the pile of crates that no-one is ever going to use.
<M9names[m]>
i'm sure you learned a lot implementing this driver though! and you can keep it in your github as a reminder of how far you got
<FrreJacques[m]>
Of course it's for sharing, but maybe someone would prefer mine?
<M9names[m]>
maybe! but unless you can tell them a reason they should choose yours over the rest I suspect they'll never even try yours
<FrreJacques[m]>
Sure. I think I might add support for 4 line displays that have a double controller.
<M9names[m]>
a double controller?
<bitts[m]>
A much better approach would be to add that support to one of the existing ones (the most used one preferably) and then make a pull request. That would be highly appreciated and we avoid fragmentation with a lot of similar crates that does a little bit each
<M9names[m]>
which one though, bitts? 🙈
<bitts[m]>
See, you already get the problem with fragmentation 😜 I am not familiar with lcd crates, maybe somebody else here have an opinion, but if not, checking number of downloads on crates.io and last updates on github (to check that it is active and a pull request would be accepted) is a good start
<bitts[m]>
Then you also don't have to commit to maintaining it for the next 5-10-15 years like you (ideally should) do if you publish on crates.io
<bitts[m]>
Ops, thought I was replying to Frère
<M9names[m]>
i think it is unreasonable to expect anyone to maintain a crate for 15 years unless they're getting paid to do it
<bitts[m]>
I agree. Even 1 year can be a long time when circumstances change. I was thinking of how long a crate could live if it gained some traction, but then normally more people will step in and contribute/take over.
<bitts[m]>
This is what makes rust so great, a lot of crates that has already been written. 😁 But yeah, sucks to discover it a bit late.
<M9names[m]>
<FrreJacques[m]> "Although I was really looking..." <- your work is still available if you put it on github.
<M9names[m]>
look, none of us can stop you if you want to do it anyway. if you're you're going to publish a +1 crate i think yet another hd44780 crate is probably the best place to do it.
<M9names[m]>
s/you're//
<FrreJacques[m]>
Because it's a nieche tinker device today anyway?
<M9names[m]>
basically yes. but also it's already a polluted namespace
<M9names[m]>
but also keep in mind that you can get 90% of "the process" with `cargo publish --dry-run` and `cargo doc --open`.
<M9names[m]>
i've spent way more time with those commands than actually publishing crates tbh
<Noah[m]>
Can anyone explain to me how SVD enumeratedValues work? Like are they supposed to all be of the same type? Or can the types (read/write/readwrite/none) be mixed? How does it work in a mixed case?
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
Noah Aren't the values defined per field (i.e. bitfield)? Each bitfield should be able to have a different read/write/etc type
<Lumpio[m]>
Or more specifically the enumeratedValues are just a list of numeric values, the field and access and such are defined on the level above them
<Noah[m]>
<Lumpio[m]> "Noah Aren't the values defined..." <- no the problem is that enumeratedValues is actually a list (Vec) of value lists. So each enumeratedValues entry holds an entry for each field
<dirbaio[m]>
in practice vendor SVDs are turbo garbage and misuse this in lots of ways
<Lumpio[m]>
And my description was a bit bad too. I think it's supposed to be either "one read-write" or "up to one read, and/or up to one write". But I wouldn't be surprised if the files out there are all broken in weird and wonderful ways.
<dirbaio[m]>
one I see a lot is: for write just "1 = clear"
<dirbaio[m]>
which is nonsense, you can write 0 just fine :(
<Noah[m]>
<dirbaio[m]> "Noah: you mean why is this a Vec..." <- correct
<dirbaio[m]>
and the way svd2rust implements support for this is also not great. for example if you do .modify() it will forward the values from the read to the write, which will write nonsense, or even values forbidden according to the enumeratedvalues for writing
<dirbaio[m]>
¯\_(ツ)_/¯
<Noah[m]>
<Lumpio[m]> "I think the only valid cases are..." <- there can also be "one none" :D nrf5430 does not specify any accessor details :D
<Noah[m]>
(which is valid)
<dirbaio[m]>
I think None means read-rwite
<dirbaio[m]>
s/rwite/write/
<Lumpio[m]>
The spec says the default is read-write if not specified
<dirbaio[m]>
svd-rs distinguishes them because the tag can either be present or not present in the xml :S
<dirbaio[m]>
honestly I wouldn't worry about it too much
<dirbaio[m]>
I guess you're using svds for adding register viewing to probe-rs?
<dirbaio[m]>
if so i'd recommend doing something like "if there's just one enumeratedValues use that. if there's multiple pick the one for Read, if not the one for None or ReadWrite, if not the one for Write"
<dirbaio[m]>
if you make it "lenient" like that it'll work ok with most broken svds
burrbull[m] has joined #rust-embedded
<burrbull[m]>
there is "usage" tag inside enumeratedValues which specify how to use it. If it is None, then field "access" say you what do
<burrbull[m]>
so there can be maximum 2 enumeratedValues in a field. 1st with "read" "usage" and 2nd with "write"
<dirbaio[m]>
svds from stm32-rs? or extract from stm32-data?
<Noah[m]>
dirbaio[m]: for now I go with stm32-rs. I wanna get a solution working to showcase probe-rs on the webpage directly basically and give people easy access to debug tooling :) and then in a second step I want to have some fancy script or whatever that generates all the svds every night or every commit from stm32-rs and the nrfx repo etc. Also, even with all the automatism we might still ahve to maintain some patch files.
<Noah[m]>
s/ahve/have/
<Noah[m]>
* for now I go with stm32-rs nightlies. I wanna get a solution working to showcase probe-rs on the webpage directly basically and give people easy access to debug tooling :) and then in a second step I want to have some fancy script or whatever that generates all the svds every night or every commit from stm32-rs and the nrfx repo etc. Also, even with all the automatism we might still have to maintain some patch files.
<burrbull[m]>
they are already generated on each commit
cinemaSundays has quit [Quit: Connection closed for inactivity]
<Noah[m]>
burrbull[m]: yes, but I need to get that mechanism fed into the probe-rs webpage somehow. Also, stm32-data based SVDs might be more accurrate. We'll see. and then I don't just need stm32 ones :) I want all brands and curate the list somehow :)