<re_irc>
<omar_u8> Importing the 0.2.7 embedded HAL, I get an unresolved import error if trying to import the "digital::v2::InputPin". Only the "OutputPin" trait seems to be recognized. Thing is the documentation shows that it should be there. Is this a known issue?
<Lumpio->
A simple GPIO input is "unproven"...? wat
<re_irc>
<omar_u8> I still struggle with syntax that looks like the one below. What is the "Mode = Mode" supposed to mean? If somebody can please shed some light.
<re_irc>
<9names (@9names:matrix.org)> maybe easier to explain with pseudocode?
<re_irc>
pub const MODE: Mode;
<re_irc>
// Instantiate an object of type Mode, and store that in MODE
<re_irc>
// create a constant of type Mode with the name MODE
<re_irc>
MODE = Mode {};
<re_irc>
<omar_u8> Ok, so instantiating and declaring in the same time so to speak?
<re_irc>
<burrbull> yes, contants always require to specify type
<re_irc>
<omar_u8> Ok makes sense.
m5zs7k has quit [Ping timeout: 265 seconds]
<re_irc>
<omar_u8> On a side note, are there any useful code documentation tools? Meaning the ones that take something like text or markdown and convert to documentation compatible syntax.
<re_irc>
<9names (@9names:matrix.org)> do you know about rustdoc?
<re_irc>
<omar_u8> Now that you mention it, yes :D it immediately clicked.
<re_irc>
<omar_u8> * 😬
m5zs7k has joined #rust-embedded
<re_irc>
<MathiasKoch> dirbaio: Huh.. Turns out i have been using a very old RA extension all this time, because vscode on Arch change to using open-vsx as extension repo.. Thanks for helping me figure this out 👍️
<re_irc>
<chrysn (@chrysn:matrix.org)> PSA -- A pattern for references with a context:
<re_irc>
For idiomatic Rust wrappers in RIOT-OS, I often hold references to a kind of Mutex that can be blocked on -- but only in certain contexts (when running in a thread), not in others (when running in an ISR).
<re_irc>
Conceptually, Mutex needs to be Sync, but _at least for some operations_, having them on "&Mutex" would mean that they're callable in an ISR, leading to crashes, and nobody likes a BSOD (Linux's strictness on that topic is what inspired me to be more precise here).
<re_irc>
The solution I'm leaning to is to have a "WereInAThread<&Mutex>" wrapper around it, which can be constructed from passed-around non-Send tokens, or just (at a small cost) at runtime; methods that are only to be called in a thread context are implemented on that rather than "&Mutex".
<re_irc>
To ensure that documentation is all in a place, I declare "#[cfg_attr(doc, fundamental)] struct WereInAThread<T> { ... }", which makes all the relevant methods show up with Mutex again.
gsalazar has joined #rust-embedded
emerent has quit [*.net *.split]
gsalazar has quit [*.net *.split]
hifi has quit [*.net *.split]
neceve has quit [*.net *.split]
cr1901 has quit [*.net *.split]
fooker has quit [*.net *.split]
Darius has quit [*.net *.split]
seer has quit [*.net *.split]
dc740 has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
Shellhound has quit [*.net *.split]
tafa has quit [*.net *.split]
Socke has quit [*.net *.split]
WSalmon has quit [*.net *.split]
vancz has quit [*.net *.split]
wose has quit [*.net *.split]
genpaku has quit [*.net *.split]
sknebel has quit [*.net *.split]
jasperw has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
Amanieu has quit [*.net *.split]
seds has quit [*.net *.split]
dnm has quit [*.net *.split]
faern has quit [*.net *.split]
dequbed has quit [*.net *.split]
agg has quit [*.net *.split]
re_irc has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
mightypork has quit [*.net *.split]
richardeoin has quit [*.net *.split]
Rahix has quit [*.net *.split]
starblue has quit [*.net *.split]
thomas25 has quit [*.net *.split]
dne has quit [*.net *.split]
cyrozap has quit [*.net *.split]
edm has quit [*.net *.split]
limpkin has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
stephe has quit [*.net *.split]
ni has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
jr-oss has quit [*.net *.split]
xnor has quit [*.net *.split]
gsalazar has joined #rust-embedded
dc740 has joined #rust-embedded
starblue has joined #rust-embedded
cr1901 has joined #rust-embedded
neceve has joined #rust-embedded
emerent has joined #rust-embedded
m5zs7k has joined #rust-embedded
Foxyloxy has joined #rust-embedded
genpaku has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
Shellhound has joined #rust-embedded
fooker has joined #rust-embedded
limpkin has joined #rust-embedded
Darius has joined #rust-embedded
Socke has joined #rust-embedded
seer has joined #rust-embedded
tafa has joined #rust-embedded
faern has joined #rust-embedded
thomas25 has joined #rust-embedded
jr-oss has joined #rust-embedded
hifi has joined #rust-embedded
agg has joined #rust-embedded
WSalmon has joined #rust-embedded
re_irc has joined #rust-embedded
dne has joined #rust-embedded
vancz has joined #rust-embedded
wose has joined #rust-embedded
richardeoin has joined #rust-embedded
dnm has joined #rust-embedded
mightypork has joined #rust-embedded
Rahix has joined #rust-embedded
dequbed has joined #rust-embedded
Lumpio- has joined #rust-embedded
seds has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
Amanieu has joined #rust-embedded
jasperw has joined #rust-embedded
sknebel has joined #rust-embedded
edm has joined #rust-embedded
stephe has joined #rust-embedded
cyrozap has joined #rust-embedded
dreamcat4 has joined #rust-embedded
ni has joined #rust-embedded
xnor has joined #rust-embedded
gsalazar has quit [Ping timeout: 264 seconds]
bjc has joined #rust-embedded
<re_irc>
<hdoordt> Hi, I've been hobbying around with a tool I call "powertest", which uses Nordics Power Profiler Kit II (PPK2) to measure the current use during "defmt-test" unittests. My idea is to use this tool on CI to do some automatic benchmarking of current usage. I've published the tool here (https://github.com/hdoordt/powertest), and my crate for interacting with the PPK2 here (https://github.com/hdoordt/ppk2-rs). I'd love some feedback on this....
<re_irc>
... Is this something anyone would like to use for their own projects? Is there something cool that's currently lacking?
<re_irc>
<James Munns> I have a PPK2, and have been meaning to play with it, that looks awesome!
<re_irc>
<dirbaio> ooh i'll definitely use ppk2-rs. I had on my TODO list writing something like it, to use it in factory tests
<re_irc>
<dirbaio> on powertest, if you're using defmt-rtt, how do you avoid the increased current draw from having SWD active?
<re_irc>
<hdoordt> dirbaio: I'm not using that, actually. The idea is to extract the number of tests that are going to be run from the ELF, and signal the host that a test is being run by toggling a pin. Only thing is, I've got no way yet to detach the debugger and reset the device after flashing yet
<re_irc>
<dirbaio> aah okay, you run the tests "blind"
<re_irc>
<hdoordt> Yeah, it's a bit tricky in that sense I think
<re_irc>
<dirbaio> if you try it let me know the results 👀
<re_irc>
<hdoordt> dirbaio: Will do!
<re_irc>
<dirbaio> hdoordt: with a custom defmt backend you could buffer all logs to RAM, then have powertest attach again and retrieve them after all the testing is done
<re_irc>
<dirbaio> or perhaps after each test
<re_irc>
<dirbaio> 🤔
<re_irc>
<dirbaio> or maybe with defmt-rtt itself, just let all the logs accumulate in the rtt buffer itself
<re_irc>
<hdoordt> How many logs do you think would fit in there?
<re_irc>
<dirbaio> default is 1kb, you can customize it with DEFMT_RTT_BUFFER_SIZE
<re_irc>
<dirbaio> 1k is quite a lot already, defmt compresses very nicely
<re_irc>
<hdoordt> Oh cool. Cause one thing thats a bit rough is handling failed tests. Curently, "defmt-test" panics on a false assertion, aborting all tests. I'd like to have it at least run some clean up function before it dies, but reading logs in between tests would maybe allow "powertest" to handle this situation better
<re_irc>
<dirbaio> perhaps instead of having the fw run all tests sequentially, have it read from a magic RAM location which one to run
<re_irc>
<dirbaio> and either on success, or panic/hardfault set the gpio saying "i'm done"
<re_irc>
<dirbaio> then the debugger can reach in to retrieve the results, and reset the chip to run the next test
<re_irc>
<dirbaio> with this you can keep running tests after a failure
<re_irc>
<hdoordt> Thanks a lot, that'll keep me off the streets for a while
<re_irc>
<dirbaio> i'm not very fan of defmt-test's "run all tests in one binary" ...
<re_irc>
<dirbaio> I tried to use it for my factory tests, but it was too easy for one test to screw up the chip state for the next, and managing the peripheral singletons etc was somewhat painful
<re_irc>
<dirbaio> in the end what i'm doing is a complete separate binary per test 🤣
<re_irc>
<dirbaio> each bin exits with either success (bkpt) or failure (panic/hardfault), then the runner loads+starts the next binary
<re_irc>
<hdoordt> That's a lot of loading then, but having to take into account state from tests prior to the current one is indeed pretty painful
<re_irc>
<dirbaio> there's another trick, you can link the bins to run from RAM, which is way faster than flashing :)
<re_irc>
<hdoordt> How cool
<re_irc>
<hdoordt> Ok so these would be a pretty nice goals for powertest:
<re_irc>
- Have tests use magic RAM location indicating which test to run
<re_irc>
- Accumulate defmt logs in rtt buffer, decode in powertest after each test
<re_irc>
- Run tests from RAM (although that'd be up to the user, but I could at least give an example)
<re_irc>
<hdoordt> Thanks a lot dirbaio !
<re_irc>
<dirbaio> if you do N binaries then you don't need magic to tell the bin which test to run
<re_irc>
<dirbaio> it's implied by which bin you load
<re_irc>
<dirbaio> but yeah it requires more scaffolding from the user
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/iH7zyhE-QVmI462Jgk8T4A, please add anything you'd like to announce or discuss and we'll kick off in a few mins :)
<re_irc>
<James Munns> Update: twitter showcase didn't happen because my brain, will get scheduled for some day this week, probably tomorrow, if you want to sneak in last second suggestions tonight, please do :)
dc740 has quit [Remote host closed the connection]
<re_irc>
<adamgreig> ok, let's go! there were a whole load of embedded-hal crate releases after last week's meeting, including the first version of embedded-hal-nb which splits it out of the main embedded-hal crate (which is now only blocking traits), a new embedded-hal 1.0 alpha release, a new -async release, and the first new embedded-can release since splitting it back out of embedded-hal
<re_irc>
<adamgreig> which means we are getting closer to and closer to perhaps a sort of embedded-hal 1.0.0-beta.0 😆
<re_irc>
<adamgreig> last week we discussed some issues implementing the new e-h spi traits on top of linux spidev, i don't think there's been any progress since then though
<re_irc>
<dirbaio> the transactional i2c has the same problem I think
<re_irc>
<therealprof> Baby steps... 😅
<re_irc>
<dirbaio> also I think it's the only think blocking the 1.0.0 release
<re_irc>
<dirbaio> * thing
<re_irc>
<adamgreig> hmm, i haven't looked at linux's i2c support at all but it would be frustrating if it had the same problem indeed
<re_irc>
<dirbaio> IMO we have to decide whether to keep it (and do workarounds for linux) or can it (for both i2c and spi)
<re_irc>
<adamgreig> at least it doesn't have the cs pins problem
<re_irc>
<therealprof> Not sure how they're solving the I2C transactional problem though.
<cr1901>
Btw, no one upstream has triaged the cs bloat issue yet
<cr1901>
so, nothing really to report
<re_irc>
<dirbaio> status of the bus/device traits fo linux is:
<re_irc>
spi: can be implemented if the transaction is (write, write, write..., read), OR if you manage CS with GPIO directly
<re_irc>
i2c: can be implemented if the transaction is (write, write, write..., read)
<re_irc>
<adamgreig> and the transaction doesn't contain any blocking or various other things?
<re_irc>
<dirbaio> no
<re_irc>
<dirbaio> the reason it can be impl'd if the transaction is"(write, write, write..., read)" is you can buffer all the writes, then flush everything on read
<re_irc>
<dirbaio> but then after the read the transaction is "done", so if you get another read/write you can't do it
<re_irc>
<eldruin> (provided you have memory for all the writes)
<re_irc>
<dirbaio> if you have linux I bet you have enough memory :P
<re_irc>
<adamgreig> if the transaction calls flush manually you're in trouble too then, because linux will deassert cs when you flush and before the transaction ends?
<re_irc>
<therealprof> I want my 20GB I2C transactions!
<re_irc>
<adamgreig> which I guess is covered by saying it must be (write, write, ..., write, read)
<re_irc>
<dirbaio> ah yeah you can't flush either
<re_irc>
<dirbaio> in regex notation, the implementable transactions are "w*r?f?" :D
<re_irc>
<dirbaio> * "w*r?f*"
<re_irc>
<eldruin> well, "w*r*f*" right?
<re_irc>
<dirbaio> no, you HAVE to flush after the first read you see
<re_irc>
<dirbaio> because you have to give the data to the application
<re_irc>
<dirbaio> and you can't flush without ending the transaction with i2cdev/spidev.. :(
<re_irc>
<dirbaio> so, possible solutions:
<re_irc>
<dirbaio> 1. give up on bus/device, return to the previous design where you do a transaction that's a "&mut [Operation]"
<re_irc>
<dirbaio> 2. keep bus/device as-is even if it isn't fully implementable in linux. Perhaps adding a note like "for max compat, drivers should only do "w*r?" transactions" to docs.
<re_irc>
<dirbaio> 3. something else, like somehow change the API to enforce there can be only one read ...?
<re_irc>
<adamgreig> I guess you could have something like that where whatever is given to the transaction closure is consumed when it reads, but meh
<re_irc>
<dirbaio> I think most drivers already do only "w*r?" transactions, so #2 wouldn't be that bad
<re_irc>
<newam> I would prefer avoiding 1, I've been using the alpha traits and the bus/device is really quite nice to work with.
<re_irc>
<adamgreig> you'd maybe end up needing two SpiBus types, one that's for directly accessing a bus and/or manual cs control, and another that's given to transaction() for SpiDevice that gets consumed by reading
<cr1901>
what's wrong with adding a new type?
<re_irc>
<adamgreig> I guess if you _did_ do that split then at least on linux you simply wouldn't offer the first type (since it can't really support it) and could more easily offer the SpiDevice-only
<re_irc>
<therealprof> dirbaio: 2*. Pray for Linux receiving a saner interface so the bus becomes properly implementable
<re_irc>
<adamgreig> but 2 might be the most practical, it's likely to work for the majority of things
<re_irc>
<adamgreig> hah yea I guess one day they might add the options we need to spidev too but i'm not holding my breath
<re_irc>
<adamgreig> phase 1: get rust code in linux ✅
<re_irc>
<henrik_alser> Weird is on-brand for i2c though
<re_irc>
<dirbaio> * the end
<re_irc>
<dirbaio> but either way this is orthogonal to the linux issue
<re_irc>
<dirbaio> both APIs aren't fully implementable on linux i2cdev
<re_irc>
<eldruin> if we forego the transaction semantics surrounding the closure it might be easier
<re_irc>
<eldruin> I am not sure how if at all though. just an idea
<re_irc>
<dirbaio> hmm but we want to give guarantees on how read/write are grouped in transactions somehow
<re_irc>
<dirbaio> if you do "write, read" you want these to be sent as a single transaction
<re_irc>
<dirbaio> if I ask the linux impl to do something it can't, I'd rather have it return some "not supported" error than have it do something else (do several transactions)
<re_irc>
<eldruin> yeah the transaction model is really nice, especially for SPI. in I2C it's just that you can abuse it and do multiple ones and things like that
<re_irc>
<dirbaio> not with this API
<re_irc>
<dirbaio> with this one it's enforced you can do only one transaction
<re_irc>
<dirbaio> but it doesn't fix the linux issue
<re_irc>
<eldruin> no, you can do "stop(); restart();"
<re_irc>
<dirbaio> the api would return a "transaction" object that can only do "read, write, restart, flush"
<re_irc>
<dirbaio> not the raw bus
<re_irc>
<eldruin> no stop?
<re_irc>
<eldruin> hmm
<re_irc>
<dirbaio> no stop, you stop by exiting from the closure
<re_irc>
<dirbaio> this would make the API the most consistent with SPI
<re_irc>
<adamgreig> having a distinct transaction object is kind of interesting in terms of splitting out the "raw bus" capabilities with the "bus accessed through a device/in a transaction"
<re_irc>
<adamgreig> like, that transaction object could be "fn write(&mut self)" and "fn read(self)"
<re_irc>
<eldruin> yeah that sounds pretty good
<re_irc>
<adamgreig> and then it can be done on linux, but you can't read-and-restart
<re_irc>
<eldruin> it adds the real "transactional" for the I2C
<re_irc>
<dirbaio> "read, restart, read" isn't implementable on linux
<re_irc>
<dirbaio> only "read, stop, start, read" is
<re_irc>
<dirbaio> so that's fine
<re_irc>
<adamgreig> yea, that's what i mean, so if the transaction object consumes self on read, no one can express 'read, restart, read', even though it might be supported on other platforms
<re_irc>
<adamgreig> question is whether it's worth constraining our spi and i2c traits to only transactions that can be done on linux (or any other similar platform where you have to buffer all calls until the final flush/end)
<re_irc>
<adamgreig> but with a distinct "transaction" type that's used to access the bus it seems like it would be possible to do so
<re_irc>
<dirbaio> yea it feels a bit scary
natan_ has joined #rust-embedded
<re_irc>
<adamgreig> i think it's either that, or we continue to allow expressing transactions that wouldn't work on linux and just hope they end up being rare enough that it doesn't cause people woe
<re_irc>
<adamgreig> if they're that rare though, do we need to support them...
<re_irc>
<dirbaio> also reminder, you CAN implement any SPI transaction on linux if you manually manage CS
<re_irc>
<eldruin> well, the methods are all fallible so the linux implementation could return an error on the second call to read or stuff like that
<cr1901>
I kinda like that approach more
<cr1901>
as opposed to assuming only things shaped like embedded Linux are supported
<re_irc>
<eldruin> dirbaio: so the question is rather, how often is hardware CS used in a linux system
<re_irc>
<dirbaio> also, if we bake the limitation into the trait, we can't lift it later without a breaking change
<re_irc>
<adamgreig> I think it's probably better to call it "kernel cs" because it's still just a gpio typically
<re_irc>
<dirbaio> eldruin: it's more like "kernel-managed CS" (hardware or software) vs "userspace-managed CS" (via gpio-cdev for example)
<re_irc>
<adamgreig> but it's driven by the kernel instead of the userspace program
natan_ has quit [Remote host closed the connection]
<re_irc>
<adamgreig> and then i think it's "basically everyone uses that" because it's what works with spidev and linux kernel drivers and everything else
<re_irc>
<dirbaio> with userspace-managed CS you can do everything
<re_irc>
<adamgreig> so the tradeoff is that for people serious about using rust, they change the platform tree file to only have one CS pin on some unused gpio, and use gpio for all their real CS
<re_irc>
<adamgreig> the nuisance is that for someone just on some rpi board, it will already have two CS pins managed by spidev, and maybe hardware hooked up to them, and they can't "just use it"
<re_irc>
<dirbaio> there's no way to tell spidev "clock these bytes out without toggling cs"?
<re_irc>
<adamgreig> you can yea
<re_irc>
<adamgreig> but you can't toggle the cs pin
natan has joined #rust-embedded
<re_irc>
<adamgreig> i.e. you can't use gpio to access a pin that's assigned cs
<re_irc>
<dirbaio> ah you have to "detach" it from spidev to be able to use it with gpio-cdev
<re_irc>
<dirbaio> bah
<re_irc>
<adamgreig> yea
<re_irc>
<dirbaio> well you could still use another pin :P
<re_irc>
<adamgreig> indeed
<re_irc>
<dirbaio> I dunno
<re_irc>
<adamgreig> the only project i have that's ever used spidev is someone else's hardware with two CS pins wired to the rpi's two CS pins though :P
<re_irc>
<dirbaio> the fact that you CAN workaround the issue on linux makes me uncomfortable at the idea of baking the limitation into the trait
<re_irc>
<dirbaio> for spi at least
<re_irc>
<adamgreig> so I'll have to change the device tree business to remap those pins elsewhere to run my software
<re_irc>
<adamgreig> yea, on balance I think same
<re_irc>
<adamgreig> dunno what the situation is like for i2cdev
natan has quit [Remote host closed the connection]
<re_irc>
<dirbaio> yea for i2c I don't think there's a fix
<re_irc>
<dirbaio> other than bitbanging? 🤣
natan has joined #rust-embedded
<re_irc>
<dirbaio> or bypassing the kernel with /dev/mem which I think some rpi gpio libs do (?)
<re_irc>
<adamgreig> but it seems like between "you can fully work around it by changing device tree or using other gpio for cs", and "probably most drivers will work fine anyway if they are w*r?", and "it can give an error about this specific situation"...
natan has quit [Remote host closed the connection]
<re_irc>
<dirbaio> but if we don't nerf the spi trait, I wouldn't nerf the i2c trait either for consistency
<re_irc>
<adamgreig> I guess it's annoying also that this does leave linux-embedded-hal having to buffer up all the transactions and then run them, I don't know if that causes nuisances for people manually managing CS who don't need it
<re_irc>
<dirbaio> dunno
<re_irc>
<adamgreig> yea, you can talk to the rpi broadcom spi peripheral directly, it's a thing, but then you need a driver for each platform instead of using linux's drivers
<re_irc>
<dirbaio> transactions tend to be small (<256 bytes), I don't think buffering is an issue on linux
<re_irc>
<adamgreig> (and i think you still can't then drive the cs gpio? maybe you can talk to the gpio peripheral directly too)
natan has joined #rust-embedded
<re_irc>
<dirbaio> chips themselves often have a very low max transaction limit
<re_irc>
<adamgreig> hmmm
<re_irc>
<adamgreig> I initialise my fpga by sending like a megabyte in one spi transaction
<re_irc>
<adamgreig> but... on linux even 1MB is not likely to be a gigantic problem
natan has quit [Remote host closed the connection]
<re_irc>
<dirbaio> does that 1MB download get broken if you raise/lower CS halfway? :P
<re_irc>
<dirbaio> anyway
<re_irc>
<therealprof> dirbaio: Probably not even connected. 😛
<re_irc>
<dirbaio> is there further "research" we can do to get more info to inform the decision on what to do?
<re_irc>
<adamgreig> yea, need to keep CS asserted throughout
<re_irc>
<dirbaio> if not, shall we make a decision now? :S
<re_irc>
<adamgreig> I think the main thing is "try implementing it in linux-embedded-hal" and see how it feels
<re_irc>
<adamgreig> not because I think it will change the decision on the current concept, but just in case something especially horrible comes up?
<re_irc>
<adamgreig> on balance it seems like we should go with "keep it as it is, maybe document more of the edge cases, and the l-e-h docs will also have some explaining to do"
<re_irc>
<adamgreig> for spi, anyway. for i2c it seems like thinking about the name of the method and whether it does implicit-only start/stop is worth pondering
<re_irc>
<dirbaio> ah it asserts/deasserts CS for every read/write, not the whole transaction
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> the spidev crate does let you create a kernel transaction that does multiple read/writes within one CS, but it's maybe not simple
<re_irc>
<adamgreig> or is it just a case of calling "transfer_multiple()" and getting some options right?
<re_irc>
<adamgreig> anyway, it should be possible with the buffering, hopefully
<re_irc>
<adamgreig> ugh
<re_irc>
<adamgreig> it might need separate types for SpiBus and whatever it exposes through SpiDevice
<re_irc>
<adamgreig> but at least that would make doing the error detection we talked about easier
<re_irc>
<dirbaio> hmm
<re_irc>
<dirbaio> would it even impl SpiBus? an spidev node represents a device, implementing Bus for it is wrong
<re_irc>
<dirbaio> I mean, other than within a transaction
<re_irc>
<adamgreig> well that's the problem
<re_irc>
<dirbaio> like, currently the "Spidev" struct implements both Bus and Device
<re_irc>
<adamgreig> but if you don't expose SpiBus at all, people can't use some other crate to do software CS
<re_irc>
<adamgreig> so you need an SpiBus type that consumes a particular spidev device (with associated CS pin), and then configures it to not actually toggle CS
<re_irc>
<dirbaio> ah
<re_irc>
<dirbaio> so yea we want both, but separate structs yup
<re_irc>
<adamgreig> and the Bus associated type on the SpiDevice will have to be something the user can't actually construct themselves I guess
<re_irc>
<adamgreig> they'll get the SpiDevice directly from the Spidev device
<re_irc>
<dirbaio> yep
<re_irc>
<adamgreig> cool, well, it's a plan I guess
<re_irc>
<adamgreig> if someone feels like trying it out please do, otherwise I will as soon as I get back to this linux project lol
<re_irc>
<eldruin> adamgreig: could you summarize the plan in some issue at l-e-h?
<re_irc>
<adamgreig> will do
<re_irc>
<adamgreig> cool, that's all for today then, thanks!
<re_irc>
<adamgreig> in other news, newam I was searching for a way to have clap use hex valued arguments and am now using your clap_num crate, thanks :D
<re_irc>
<newam> adamgreig: Glad that it's working for you! 😁
natan has joined #rust-embedded
natan has quit [Remote host closed the connection]
natan has joined #rust-embedded
natan has quit [Remote host closed the connection]
cr1901 is now known as cr1901_
<cr1901_>
adamgreig: Just to reiterate... upstream hasn't triaged my issue yet, so nothing to report. I may know a gross workaround for my needs though
<cr1901_>
(workaround == "create a critical-section crate of my own that I patch into the dependency graph at the top-level crate of my application, with acquire/release defined within the crate without "extern")
<re_irc>
<almindor> adamgreig: sorry I missed this meeting due to another meeting is there a "traits will now look like this" somewhere, I can try this on the e310x-hal setup in a branch next week or so
Foxyloxy has quit [Ping timeout: 260 seconds]
<re_irc>
<almindor> or did I misunderstand that there's a need to change the traits?
Foxyloxy has joined #rust-embedded
<re_irc>
<almindor> +SPI device/bus
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
natan has joined #rust-embedded
natan has quit [Remote host closed the connection]
<re_irc>
<adamgreig> also the only embedded linux computer with spi I can run code on is inside my EV chargepoint on the wall of my house, and hooked up to the 40A mains circuit, lol
<re_irc>
<adamgreig> so it's quite fun to push code to it over spi and hope it sends the right messages etc, but it's quite inconvenient to get the logic analyser on it
<re_irc>
<adamgreig> i should buy an rpi or something...
<re_irc>
<dirbaio> they're High Unobtainium right now
<re_irc>
<adamgreig> alas
<re_irc>
<adamgreig> oooh i wonder if my old CHIPs would work
<re_irc>
<adamgreig> i have like three or four of them... wonder how new a linux they'll run
<re_irc>
<9names (@9names:matrix.org)> The CHIP was Allwinner, right? They're in mainline, you should be able to run 6.0 if you're okay with a subset of all hardware. Spi/i2c/UART/networking should be fine, graphics maybe if you're lucky.
<cr1901>
I can confirm CHIP works fine w/ at least the i2c linux APIs
<re_irc>
<9names (@9names:matrix.org)> Okay maybe no ethernet, unless you're cool with USB ethernet adaptor 🙊
<re_irc>
<9names (@9names:matrix.org)> Oh no nand support either so you have to boot off USB... Maybe a bbb would be better 🤣
<re_irc>
<9names (@9names:matrix.org)> is irc bridge broken again (I can't see cr1901's message on matrix)
cr1901 is now known as cr1901_
<cr1901_>
9names: Indeed
<cr1901_>
Also, I feel less bad about using IRC b/c this is how the channel is publicly logged
<cr1901_>
Maybe I can chat w/ an admin about getting the bridge properly set up for this room
<re_irc>
<9names (@9names:matrix.org)> I think it's worth chasing that again
<re_irc>
<adamgreig> 9names: i managed to find it and flash a new community image that has 5.15, it seems it was a custom kernel at the time so idk how annoying anything newer is, it is an allwinner a13 iirc though
<re_irc>
<adamgreig> r8 soc
<re_irc>
<adamgreig> it's got onboard nand that's working with this image, and usb gadget ethernet to connect to desktop (and built in wifi)
<re_irc>
<adamgreig> but for some reason this image is just doing usb serial and doubling up line endings, sigh lol
<re_irc>
<adamgreig> yay, wifi is connected and downloading ssh...
<re_irc>
<adamgreig> it's a real pity ntc went bankrupt, these are great
<cr1901_>
I could've done without the complete radio silence from NTC as they went bankrupt
<re_irc>
<adamgreig> :(
<re_irc>
<adamgreig> hmm, well, no spidev as-is, guess i need to something something device tree