crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Félix the Newbie> I wonder how powerful is the CPU of my stm32f303. Is it realistic to call 72 references to functions (so, no inline) in less than 1ms? The thing the functions do is trivial, I'm just worried about the fact that they are not all at once in the cache (afaik)
<re_irc>
<Félix the Newbie> I have no idea about the oom of its power.
<re_irc>
< (@ryan-summers:matrix.org)> The answer is "it depends" - depends on how many args etc. each function has. You can do the math on the actual instructions available to you based on your processor clock cycle as well
<re_irc>
< (@ryan-summers:matrix.org)> But also, I don't think that chip/product line have a cache, so that aids in your calculations
<re_irc>
< (@ryan-summers:matrix.org)> But in general, the calculation is "Num_Cycles_Available=Required_time/(1/F_CPU)". In your case, that's 1ms / (1/fCPU). If you're running at 72MHz, that gives you 72000 CPU cycles to execute your 72 functions, so 1k cycles per function
<re_irc>
< (@ryan-summers:matrix.org)> Seems pretty doable if your functions are short. Depends how you call them etc. as well
<re_irc>
< (@ryan-summers:matrix.org)> You'll also need to think about if something is going to interrupt you in your window, and if that affects your timing :) Real-time systems are complex
<re_irc>
< (@k900:0upti.me)> 72 looks like a weird number
<re_irc>
<Félix the Newbie> It's the number of keys in my keyboard.
<re_irc>
< (@k900:0upti.me)> Or rather, it looks weird that you know the number ahead of time this precisely
<re_irc>
< (@k900:0upti.me)> Why do you need 72 distinct functions?
<re_irc>
<Félix the Newbie> I _may_ have that many functions. It's a bit more complicated: each key has an event, which is an enum, which may have several functions, like "on_press", "on_release", etc.
<re_irc>
< (@k900:0upti.me)> That will very much shoot you in the foot as soon as you want to implement chords or anything requiring you to keep state between events
<re_irc>
<Félix the Newbie> I want to replicate the QMK features, and more, so I need some solid and general mechanism
<re_irc>
< (@ryan-summers:matrix.org)> Are you scanning all the keys 1 time per MS? Is that how keyboards do it? I always assumed they just awaited ISRs, then determined what was pressed
<re_irc>
< (@k900:0upti.me)> The mechanism you probably want is to have a stream of key events
<re_irc>
< (@k900:0upti.me)> And then observers on that stream
<re_irc>
< (@k900:0upti.me)> : USB HID is poll so you kinda have to
<re_irc>
< (@k900:0upti.me)> You could scan in response to the poll or you could do it on a timer
<re_irc>
< (@k900:0upti.me)> But you'll still get polled every X milliseconds
<re_irc>
< (@ryan-summers:matrix.org)> Yeah, but you can keep some list in software of events, then just pull from that list whenever HID polls
<re_irc>
< (@ryan-summers:matrix.org)> Anyways I'm no expert when it comes to HID/keyboards, so ignore my ignorance
<re_irc>
<Félix the Newbie> : I do keep the state between events, that's the whole point of my system.
<re_irc>
<Félix the Newbie> : Indeed
<re_irc>
< (@k900:0upti.me)> You need to keep state _across multiple keys_
<re_irc>
< (@k900:0upti.me)> Which means you either have to use icky globals
<re_irc>
< (@k900:0upti.me)> Or you need to have the same thing process more events
<re_irc>
<Félix the Newbie> : Why tho?
<re_irc>
< (@ryan-summers:matrix.org)> caps lock for example?
<re_irc>
<Félix the Newbie> : I don't need that. It's handled by the OS.
<re_irc>
< (@k900:0upti.me)> Because you will probably want to have layers and chords and things like that
<re_irc>
<Félix the Newbie> : What are you calling chords?
<re_irc>
<Félix the Newbie> When I keep pressed a key to go to another layer, then typing another key, for example?
<re_irc>
< (@k900:0upti.me)> What QMK calls Combos
<re_irc>
<Félix the Newbie> Ohh
<re_irc>
<Félix the Newbie> Yes, it cannot fit in my system directly.
<re_irc>
< (@k900:0upti.me)> So e.g. mapping multiple keypresses (in order) to an action
<re_irc>
<Félix the Newbie> Mmh, in that situation, I need another separate system.
<re_irc>
< (@k900:0upti.me)> The stream of events model can do that easily with a custom observer
<re_irc>
< (@k900:0upti.me)> And it can do the basic things you described too
<re_irc>
<Félix the Newbie> : Do you have any example? Also, sometimes, I need to update the state even when there is no event (for example during a macro). Not sure how that would fit in it.
<re_irc>
< (@k900:0upti.me)> QMK is technically an example, though they build a pile of very questionable abstractions on top
<re_irc>
< (@k900:0upti.me)> You can update things in the background by spawning more tasks with timers
<re_irc>
< (@k900:0upti.me)> Assuming you're using RTIC
<re_irc>
< (@k900:0upti.me)> Or Embassy or whatever
<re_irc>
<Félix the Newbie> : Thanks. I use a functional style, like: "update(state: State) -> State", maybe I should use a mutable reference. It may consume less cycles.
<re_irc>
<Félix the Newbie> : That's what I use. Honestly, I don't wanna read the QMK code 😅
<re_irc>
< (@k900:0upti.me)> I don't have my prototype on hand but I basically just had a Rust channel of events like "Event::Up(Key::A)"
<re_irc>
< (@k900:0upti.me)> And then a bunch of functions that would propagate those events and maybe do side effects
<re_irc>
< (@k900:0upti.me)> Elm style
<re_irc>
<Félix the Newbie> I don't see how an observer can observe only the keys it's interested in. It seems kinda wasteful.
<re_irc>
< (@k900:0upti.me)> It can't, but you can't either
<re_irc>
< (@k900:0upti.me)> Like, the act of calling the right function is effectively doing the same check
<re_irc>
< (@k900:0upti.me)> Just moving it to the dispatcher instead of the observer
<re_irc>
<Félix the Newbie> Hum, indeed.
<re_irc>
<Félix the Newbie> : That seems really cool that way, I must admit :D
<re_irc>
< (@k900:0upti.me)> Also, you can use generics to build the entire event routing statically at compile time
<re_irc>
<Félix the Newbie> Can I?
<re_irc>
< (@k900:0upti.me)> Which will allow LLVM to then mutilate it into something very efficient
<re_irc>
< (@k900:0upti.me)> The original inspiration for my prototype wasn't really Elm, it was Warp, a Rust web framework that basically did that for web requests
<re_irc>
<Félix the Newbie> In your mechanism, there are only 2 hardware types of event, right? press and release. That's how you think LLVM can optimize it?
<re_irc>
< (@k900:0upti.me)> It actually works really well
<re_irc>
< (@ryan-summers:matrix.org)> Félix the Newbie: Use godbolt to analyze the assembly of various call signatures if you want to find the most optimal call method. I have a feeling rust will optimize things to do it mostly right in any case: https://rust.godbolt.org/
<re_irc>
< (@k900:0upti.me)> If you don't mind the exploding compile times
<re_irc>
<Félix the Newbie> : If there is a place where runtime matters most than compile time, I think it's embedded…
<re_irc>
<Félix the Newbie> I like engineering stuff and cool architectures, so that looks like something I want to do 🤔
<re_irc>
I just hope it won't end up being heavy too much.
<re_irc>
< (@k900:0upti.me)> Félix the Newbie: And that wasn't really the point
<re_irc>
< (@k900:0upti.me)> The point was being able to write something like
<re_irc>
< (@k900:0upti.me)> Very rough sketch but that's the idea
<re_irc>
< (@k900:0upti.me)> If you know all the types statically, LLVM should be able to inline 99% of it
<re_irc>
<Félix the Newbie> Thanks, I've copy/pasted it somewhere to understand the context. I'm not sure how it fits in an Elm-like architecture. IIRC, there are:
<re_irc>
- the model
<re_irc>
- the view, which sends the report to the OS, here
<re_irc>
- the reactor, which calls the update function and processes the command
<re_irc>
- the update function, which takes a message + model, and returns a model + command
<re_irc>
< (@k900:0upti.me)> It's mostly the first two
<re_irc>
< (@k900:0upti.me)> So basically you have a function that takes an event, updates a bunch of internal state and then (maybe) returns an event
<re_irc>
< (@k900:0upti.me)> Though I ended up also having a channel for events so I could do macros in the background
<re_irc>
< (@k900:0upti.me)> Which made it less Elm and more, uh, BEAM on acid?
<re_irc>
< (@dirbaio:matrix.org)> it's a keyboard lol
<re_irc>
< (@dirbaio:matrix.org)> just write code to make it do keyboard things
<re_irc>
< (@k900:0upti.me)> If I wanted to do keyboard things, I'd run QMK
<re_irc>
< (@dirbaio:matrix.org)> fancy architectures with so much generics is a bit overengineered :D
<re_irc>
< (@k900:0upti.me)> (in fact I am currently running QMK)
<re_irc>
<Félix the Newbie> : It has bugs, and stuff it doesn't support. And I don't want to touch that crappy code.
<re_irc>
< (@k900:0upti.me)> What I actually wanted to do was oddly specific things that weren't possible to encode in QMK
<re_irc>
<Félix the Newbie> : That's what we're discussing :3
<re_irc>
<Félix the Newbie> For example, modifiers “bleed” to other keys, there is only one implementation for tap/hold and tap/double tap (afaik) which creates latency where there is no need to, etc.
<re_irc>
<Félix the Newbie> : How would you handle the fact that the event queue is full? You can send a report with rollover to the OS, then continue to process the events like there's nothing wrong? That may lead to unexpected stuff. But you cannot empty the queue, because there are some events you don't want to interrupt, like the macro ones.
<re_irc>
< (@k900:0upti.me)> I, uh, don't?
<re_irc>
< (@k900:0upti.me)> I just made a very big queue
<re_irc>
< (@k900:0upti.me)> lol
<re_irc>
< (@k900:0upti.me)> I'm pretty sure it would panic on overflow
<re_irc>
< (@k900:0upti.me)> It's a prototype ok
<re_irc>
<Félix the Newbie> I'm trying to create a prod firmware, that's why I think about it.
<re_irc>
<Félix the Newbie> If my, uh, dog (I don't have a cat) sleeps on the keyboard, I don't want the firmware to panic 😆
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@diondokter:matrix.org)> Hey all, so I may get some time to contribute to the Rust embedded RISC-V ecosystem.
<re_irc>
Would you be interested in:
<re_irc>
- A way to target a virtual RISC-V microcontroller with simple (embedded-hal) peripherals (or maybe programmable peripherals) so you can test your code? Or is QEMU good enough for your needs?
<re_irc>
- AFAIK, there is no unified interrupt system like NVIC on Cortex-M. I could start work on a unified system that can target different controllers. This should make it easier to get RTIC and Embassy working on RISC-V. (From my googling I couldn't find an effort like this)
<re_irc>
Just trying to gauge interest to see if any of these projects is worth it to work on
<re_irc>
<Félix the Newbie> : Which channel implementation do you use? It should be a MPSC I guess.
<re_irc>
< (@dirbaio:matrix.org)> embassy already works on riscv (on main thread only, using WFI, no InterruptExecutor)
<re_irc>
< (@dirbaio:matrix.org)> interrupt handling is delegated entirely to the HAL
<re_irc>
< (@diondokter:matrix.org)> Oh, I only saw a cortex-m crate and not a riscv crate
<re_irc>
< (@diondokter:matrix.org)> +in embassy
<re_irc>
<Félix the Newbie> : BTW, is there somewhere a summary of RTIC vs Embassy?
<re_irc>
"embassy-cortex-m" contains stuff to handle interrupts so that it could be reused between the HALs, but there's no reason that could be all built into the HAL
<re_irc>
< (@dirbaio:matrix.org)> even if the hal is out-of-tree. that's what the Espressif folks are doing
<re_irc>
< (@diondokter:matrix.org)> : Oh cool! See, that's why I ask first haha
<re_irc>
< (@mabez:matrix.org)> For the second point, RISCV is converging (and has converged? Not sure if its finalized yet) towards PLIC, platform level interrupt controller which will provide a NVIC like interface, but you're right I dont think there is any work in the rust ecosystem to try and abstract around it, I think that would be really cool to see and definitely something I want to use :D
<re_irc>
< (@diondokter:matrix.org)> : Yeah, PLIC seems to be the most standardized
genpaku has quit [Remote host closed the connection]
<re_irc>
< (@jamesmunns:beeper.com)> Interesting that they are finally making the call to pass on chalk
<re_irc>
< (@hegza:matrix.org)> : On point 1: I'm actually using Renode instead of QEMU for this purpose. It's quite convenient with an ability to rapid prototype peripherals in Python. and the developers are very involved in RISC-V.
<re_irc>
On point 2: yep, PLIC is quite standard for application processors, though I don't think it's popular in embedded, and might not even meet the right needs for those kinds of use cases.
<re_irc>
< (@almindor:matrix.org)> : Oh wow, peripherals! I need to check this thing out
<re_irc>
< (@almindor:matrix.org)> one thing I always missed on emulators was the lack of [easy] addition of peripherals, they all do the core stuff nice but no or just some basic emulated peripherals are added. No idea why coz it should be fairly simple to do possibly even from SVD or such
<re_irc>
< (@almindor:matrix.org)> : I wonder what rust-analyzer will do once chalk gets too disconnected to be useful anymore
<re_irc>
< (@korken89:matrix.org)> : I really hope the CLIC becomes the MCU standard
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
< (@dkhayes117:matrix.org)> : It looks like the CLIC, labeled as Fast Interrupt in the ratification process I believe, is a little further behind then the PLIC. It is currently in step 1 (start) of the ratification status.
<re_irc>
< (@dkhayes117:matrix.org)> * listed as in step 1 (start) of the ratification process.
<re_irc>
< (@korken89:matrix.org)> CLIC is more or less feature equal to NVIC
<re_irc>
< (@dirbaio:matrix.org)> there's no ARM equivalent for the PLIC, in cortex-m land? I don't recall having seen anything like it
<re_irc>
< (@korken89:matrix.org)> Same
<re_irc>
< (@jamesmunns:beeper.com)> GIC, maybe?
<re_irc>
< (@jamesmunns:beeper.com)> Seen that on a couple of ArmV7A cores.
<re_irc>
< (@jamesmunns:beeper.com)> the bigger socs from broadcom probably have their own whatever though. it's not standard like the NVIC, or as common as the PLIC
<re_irc>
< (@dirbaio:matrix.org)> ah in -A cores. i'm not familiar with those at all :D
<re_irc>
< (@jamesmunns:beeper.com)> yeah, agree that CLIC -> NVIC, and my best guess is that PLIC -> GIC
<re_irc>
< (@jamesmunns:beeper.com)> I've also seen CLINT in a bunch of MCU cores? I think it's similar to the CLIC tho?
<re_irc>
< (@korken89:matrix.org)> It's more like interrupts on AVR imo
<re_irc>
< (@jamesmunns:beeper.com)> I guess CLINT is specifically "core local"
<re_irc>
< (@jamesmunns:beeper.com)> not sure what you mean by "like AVR" :D
<re_irc>
< (@korken89:matrix.org)> I mean not preemtive:)
<re_irc>
< (@korken89:matrix.org)> But it's good enough for a lot
<re_irc>
< (@korken89:matrix.org)> I really hope will see stone CLIC implementations soon
<re_irc>
< (@korken89:matrix.org)> * some
<re_irc>
< (@jamesmunns:beeper.com)> Ah yeah, the PLIC has a single "actual interrupt" for hardware messages, which is muxed down from N hardware event/interrupt signals
<re_irc>
< (@jamesmunns:beeper.com)> I think the GIC works similarly
<re_irc>
< (@jamesmunns:beeper.com)> you can have preemption in the PLIC, (e.g. from non-hw/periph IRQs like IPC signals), but I think the plic will always just give you the single highest prio peripheral/hw interrupt signal at a time with the "mclaim" interface.
<re_irc>
< (@jamesmunns:beeper.com)> Or rather, the PLIC _IS_ the MUX, which plugs into the "*External" line
<re_irc>
< (@korken89:matrix.org)> Ah i meant CLINT
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> (like "MachineExternal", for example)
<re_irc>
< (@jamesmunns:beeper.com)> ah
<re_irc>
< (@korken89:matrix.org)> It's like CLIC light
<re_irc>
< (@korken89:matrix.org)> I don't really work with application processors :)
<re_irc>
< (@jamesmunns:beeper.com)> uhhhh
<re_irc>
< (@jamesmunns:beeper.com)> ¯\_(ツ)_/¯
<re_irc>
< (@jamesmunns:beeper.com)> I'd have to go look at my notes lol
<re_irc>
< (@korken89:matrix.org)> Hehe
<re_irc>
< (@jamesmunns:beeper.com)> I've only run RISC-V on an application processor, so my knowledge outside of that is pretty shaky (it was also a couple months ago)
<re_irc>
< (@korken89:matrix.org)> I want to see more riscv MCUs
<re_irc>
< (@jamesmunns:beeper.com)> ask the esp32 folks, they'll know better than I do :p
<re_irc>
< (@korken89:matrix.org)> The ones from CH32 has a nice interrupt controller
<re_irc>
< (@dkhayes117:matrix.org)> : CLINT mode supports interrupt preemption, but only based on privilege mode
<re_irc>
< (@korken89:matrix.org)> I'm waiting for dev boards
<re_irc>
< (@korken89:matrix.org)> Oh it is? When I read it did not seem to have priority
<re_irc>
< (@korken89:matrix.org)> It was more like an interrupt was an interrupt, first come first served
<re_irc>
< (@korken89:matrix.org)> I might be misremembering though :)
<re_irc>
< (@korken89:matrix.org)> CLINT not from what I understand
<re_irc>
< (@korken89:matrix.org)> CLIC = NVIC
<re_irc>
< (@korken89:matrix.org)> +clone
<re_irc>
< (@korken89:matrix.org)> Even had the same registers but with different names :D
<re_irc>
< (@dirbaio:matrix.org)> hehehe no wonder you want mcus to use CLIC :D
<re_irc>
< (@dirbaio:matrix.org)> so you can RTIC them
<re_irc>
< (@korken89:matrix.org)> Exactly ;)
<re_irc>
< (@korken89:matrix.org)> I want to try on CLINT as well but it work just be one priority
<re_irc>
< (@korken89:matrix.org)> So maybe not that nice
<re_irc>
< (@korken89:matrix.org)> I want to try on CLINT as well but it would just be one priority
<re_irc>
< (@korken89:matrix.org)> User experience i mean
<re_irc>
< (@dirbaio:matrix.org)> seems very basic
<re_irc>
< (@dirbaio:matrix.org)> reminds me of armv4/armv5 interrupts
<re_irc>
< (@dirbaio:matrix.org)> yeah
<re_irc>
< (@korken89:matrix.org)> It'll probably work fine, we got RTIC running on AVR once upon a time :D
<re_irc>
< (@korken89:matrix.org)> Old RTFM though, but still
<re_irc>
< (@dirbaio:matrix.org)> omg, why
<re_irc>
< (@dirbaio:matrix.org)> 😂
<re_irc>
< (@korken89:matrix.org)> Why not :D
<re_irc>
< (@korken89:matrix.org)> I can't recommend though 😅
<re_irc>
< (@dkhayes117:matrix.org)> The HiFive1 Rev B (FE310-G002) has both PLIC and CLIC I think
<re_irc>
< (@korken89:matrix.org)> Oh
<re_irc>
< (@dkhayes117:matrix.org)> No it had CLINT not CLIC
<re_irc>
< (@dkhayes117:matrix.org)> along with the PLIC
<re_irc>
< (@korken89:matrix.org)> Auw
<re_irc>
< (@korken89:matrix.org)> I have only seen the reference implementation yet that's available, but not in hardware
<re_irc>
< (@korken89:matrix.org)> I'm really hoping to see one soon
<re_irc>
< (@mabez:matrix.org)> Isn't CLIC for single core only? If you have multiple cores you need PLIC to mux between multiple harts?
<re_irc>
< (@korken89:matrix.org)> The CLIC docs said something like a CLIC per core
<re_irc>
< (@korken89:matrix.org)> And PLIC between cores
<re_irc>
< (@mabez:matrix.org)> Ah I see, that makes sense
<re_irc>
< (@korken89:matrix.org)> So it's just the same as with the NVIC
<re_irc>
< (@korken89:matrix.org)> I'm almost certain they just sneakily looked at the NVIC while making the CLIC:D
<re_irc>
< (@korken89:matrix.org)> Like copy homework and mix it up a bit
<re_irc>
< (@tmgross:matrix.org)> What is the best way to program flash with a hex file over SWD, when it's too big to fit the whole thing on my processor's flash? This isn't _strictly_ Rust specific, but I'm wondering if there's a good way
<re_irc>
< (@dirbaio:matrix.org)> if it's too big, you can't flash it
<re_irc>
< (@dirbaio:matrix.org)> not sure what you mean exactly
<re_irc>
< (@tmgross:matrix.org)> *external flash, sorry I didn't specify
<re_irc>
< (@tmgross:matrix.org)> Like a qspi chip
<re_irc>
< (@tmgross:matrix.org)> Not with program code that has to run, just with a blob that has to be there for another chip
<re_irc>
< (@dirbaio:matrix.org)> ah you want to write to an external flash, without copying through the internal one because it doesn't fit
<re_irc>
< (@tmgross:matrix.org)> Correct. If it's tiny I would just include_bytes! and write it myself, but I can't do that here
<re_irc>
< (@dirbaio:matrix.org)> it's possible to do it with probe-rs, if you have the right flash algorithm for the external flash
<re_irc>
< (@dirbaio:matrix.org)> which mcu is it?
<re_irc>
< (@tmgross:matrix.org)> It's a SAMD5 series, I'll take a look at the probe-rs docs
<re_irc>
< (@dirbaio:matrix.org)> it's... not very documented 😅
<re_irc>
< (@tmgross:matrix.org)> My brief looking has led me to the same conclusion 😆
<re_irc>
< (@dirbaio:matrix.org)> so if you setup the yaml right, when you flash something to the address range of the external flash, it'll get flashed there
<re_irc>
< (@yatekii:matrix.org)> hmm I should document this
<re_irc>
< (@yatekii:matrix.org)> whenever I wanna write docs I feeel like there is nothing to write :/
<re_irc>
< (@dirbaio:matrix.org)> ... and when you do find something to write you have no energy? :D
<re_irc>
< (@dirbaio:matrix.org)> that always happens to me 😂
<re_irc>
< (@tmgross:matrix.org)> Ooh, those are some great links
<re_irc>
< (@tmgross:matrix.org)> Thank you for all the info
<re_irc>
< (@tmgross:matrix.org)> I'll have to try it out
<re_irc>
< (@yatekii:matrix.org)> : nah for me it's litterally: "ok gonna write docs for this. ok, what do we have, ok, 1, 2, 3, 4 and 5. hmm, 1 is obvious, check, 2 is ovious too, check, damnt they are all obvious, ok empty docs"
<re_irc>
< (@yatekii:matrix.org)> like idk
<re_irc>
< (@dirbaio:matrix.org)> lololol
<re_irc>
< (@yatekii:matrix.org)> I should write what you wrote here just now
<re_irc>
< (@yatekii:matrix.org)> hmm
<re_irc>
< (@yatekii:matrix.org)> I wonder if I can place it somewhere good in rustdocs
<re_irc>
< (@dirbaio:matrix.org)> something that would be great to have is
<re_irc>
< (@yatekii:matrix.org)> or if I need to put it in our guide
<re_irc>
< (@yatekii:matrix.org)> I am really not too lazy to write docs
<re_irc>
< (@dirbaio:matrix.org)> - an "official" rust template for writing a flash algo
<re_irc>
- a way to *log* stuff from the flash algo (RTT?)
<re_irc>
< (@yatekii:matrix.org)> I just feel really incompetent :/
<re_irc>
< (@yatekii:matrix.org)> : ohhh that would be great
<re_irc>
< (@yatekii:matrix.org)> great eveningproject actually
<re_irc>
< (@yatekii:matrix.org)> bunking on the fact we only upload data and just read it on the host without it ever overflowing.
<re_irc>
< (@yatekii:matrix.org)> ah maybe that is stupid tho because it needs a big buffer
<re_irc>
< (@yatekii:matrix.org)> hmmm
<re_irc>
< (@yatekii:matrix.org)> lets move to #probe-rs:matrix.org (https://matrix.to/#/#probe-rs:matrix.org)
<re_irc>
< (@tmgross:matrix.org)> It would be super cool to be able to checksum the flash to see whether the flash needs to be updated 🤔 Writing 10M over SWD probably isn't slow slow, but it is slower than the 512k microcontroller
<re_irc>
< (@tmgross:matrix.org)> But maybe it already does that, I need to get this thing working at all first
<re_irc>
< (@dirbaio:matrix.org)> that'd be a neat feature indeed (probe-rs doesn't do it currently)
<re_irc>
< (@tiwalun:matrix.org)> : Isn't the problem here that Rust doesn't support position independent code properly, on ARM?
<re_irc>
< (@tiwalun:matrix.org)> I thought that was one of the reasons for not writing flash algos in Rust
<re_irc>
< (@dirbaio:matrix.org)> it kinda works with "-C relocation-model=pic"
<re_irc>
< (@dirbaio:matrix.org)> I think stuff like vtables or pointers-in-statics are broken
<re_irc>
< (@yatekii:matrix.org)> : I think we do not need those?
<re_irc>
< (@dirbaio:matrix.org)> but it's enough to write a flash algo
<re_irc>
< (@yatekii:matrix.org)> actually RTT init might be tricky with pic :D
<re_irc>
< (@yatekii:matrix.org)> ah maybe not tho
<re_irc>
< (@dirbaio:matrix.org)> ah RTT control block is a static with pointers, indeed
<re_irc>
< (@tiwalun:matrix.org)> Maybe something like semihosting would work better?
<re_irc>
< (@dirbaio:matrix.org)> actually, fixing it in the flash algo case is less hard than fixing it in general: probe-rs could process the elf relocations at flash algo load time
<re_irc>
< (@dirbaio:matrix.org)> less hard because you can do it on the pc side
<re_irc>
< (@dirbaio:matrix.org)> no need to do it on the mcu
<re_irc>
< (@yatekii:matrix.org)> : hmm but it hard kills perf and needs an entirely new interface, no?
<re_irc>
< (@dirbaio:matrix.org)> semihosting is really bad yes
<re_irc>
< (@mabez:matrix.org)> Is pic required for the arm flash loaders? I added a `load_address` field to flash non pic algos for the c3, maybe that would simplify things for adding stuff like RTT to them?
<re_irc>
< (@dirbaio:matrix.org)> oh right
<re_irc>
< (@dirbaio:matrix.org)> totally
<re_irc>
< (@dirbaio:matrix.org)> it's supported on arm's too I guess?
<re_irc>
< (@dkhayes117:matrix.org)> what pic in this context?
<re_irc>
< (@yatekii:matrix.org)> : nup it does not :)
<re_irc>
<riskable> You can do it with the pin going to +voltage too but that method is slightly riskier from a static electricity standpoint
<re_irc>
< (@yatekii:matrix.org)> IO is enough :)
<re_irc>
< (@dirbaio:matrix.org)> ah so the touch is connecting the pin through the flesh to gnd?
<re_irc>
<riskable> There's two ways to do it, actually... There's the pin-to-ground way and then there's the pin-to-pin way. I prefer the pin-to-ground way since it's safest
<re_irc>
< (@dirbaio:matrix.org)> that's not _capacitive_ though, is it?
<re_irc>
< (@dirbaio:matrix.org)> that's more like a pushbutton with very high resistance
<re_irc>
< (@dirbaio:matrix.org)> with real capacitive your finger touches just 1 wire, instead of connecting 2 together
<re_irc>
<riskable> : Yeah that's basically the same except by sending it to ground you protect against static electric shock
<re_irc>
< (@dirbaio:matrix.org)> not capacitive! :P
<re_irc>
<riskable> No, you're measuring the capacitance!
<re_irc>
< (@dirbaio:matrix.org)> how?? 😂
<re_irc>
<riskable> You set the pin HIGH then set it to INPUT with pull-down and measure how long it takes to hit 0. When a finger touches the pin it takes longer
<re_irc>
<riskable> Oh cool: There's some PIO code to do it
<re_irc>
< (@dirbaio:matrix.org)> ohhhhhh
<re_irc>
< (@dirbaio:matrix.org)> got it
<re_irc>
< (@dirbaio:matrix.org)> and that works well enough in the real world? 🤯
<re_irc>
< (@yatekii:matrix.org)> yup it works just fine :)
<re_irc>
< (@yatekii:matrix.org)> did it many times :)
<re_irc>
< (@yatekii:matrix.org)> basically depends on the electrode only
<re_irc>
< (@dirbaio:matrix.org)> i've always used dedicated ICs in our products
<re_irc>
< (@yatekii:matrix.org)> cant hurt except for your purse :P
<re_irc>
< (@dirbaio:matrix.org)> there's one advantage with dedicated ICs: they can do the thing autonomously, and wake the MCU with an interrupt pin on touch
<re_irc>
< (@yatekii:matrix.org)> : yup :)
<re_irc>
< (@dirbaio:matrix.org)> which you need for low-power :P
<re_irc>
< (@yatekii:matrix.org)> hmm actually
<re_irc>
< (@yatekii:matrix.org)> I think you just have to wake a bit more
<re_irc>
< (@yatekii:matrix.org)> I wonder what the impact is
<re_irc>
< (@mabez:matrix.org)> On that note, the TSC in ST's L series chips is garbage, I wish I never used it and got a dedicated IC
<re_irc>
< (@dirbaio:matrix.org)> and some can monitor N pads through just one i2c, so they're useful to not waste N pins as well
<re_irc>
<riskable> For my purposes I have a board I just made that could use some rarely-used buttons. Normally I'd use some tactile buttons for that but in this case a very gentle touch would be better. Also, I've got a zillion unused pins on my RP2040 :D
<re_irc>
< (@mabez:matrix.org)> There is no way to use it in a low power way (constant polling or a timer that wakes the cpu and polls), and it doesn't work when the chip is in sleep mode - okay vent over :D
<re_irc>
< (@yatekii:matrix.org)> yeah I mean the IO method is ofc just cost saving
<re_irc>
< (@dirbaio:matrix.org)> ST royally fucking up peripheral design, as always
<re_irc>
< (@tmgross:matrix.org)> riskable: Er - just to be pedantic, you're not at any different risk for using ground vs. another signal pin. The greatest voltage differential you can generate with two pins is 3.3-5V, which is the same as the differential between any pin and ground (assuming by ground you mean "IC current return", as "literal earth" or "mains safety connection" ofc wouldn't work for a floating device)
<re_irc>
< (@yatekii:matrix.org)> it's worse in every other regard
<re_irc>
< (@tmgross:matrix.org)> +not
<re_irc>
< (@tmgross:matrix.org)> +which
<re_irc>
<riskable> Ahh screw it: There's no existing crate but there's existing PIO code. I should just get the board made and figure it out after the fact 😄
<re_irc>
< (@chemicstry:matrix.org)> I've used this IO capacity sense trick for a single-component (attiny) capacitive soil moisture sensor, worked quite well. You don't really need PIO as the decay time is quite fast, so doable on any chip with busy poll
<re_irc>
< (@yatekii:matrix.org)> riskable: can make a crate around the PIO :)
<re_irc>
< (@9names:matrix.org)> : CLIC is used in all the boufallo chips. bl602 and bl702 use custom sifive e2x core which implement the 2018 draft CLIC spec, and the newer bl616 and bl808 use t-head e907 that also implements CLIC (though I am unsure which version)
<cr1901>
I bought ox64 specifically to use the LP chip, and wouldn't you know it- there's almost no documentation on the LP chip. Wheee...
<re_irc>
< (@9names:matrix.org)> yeah, fun times!
<re_irc>
<Julia> I may have a weird question, but if you have any ideas I'd love to hear it.
<cr1901>
jamesmunns: Immediate context is: I have examples for my tcn75a crate that target only linux: https://github.com/cr1901/i2c-server/blob/master/tcn75a/examples/limits.rs#L7-L9. Using pretty-hal-machine would make the examples _markedly_ more generic, but it would still be nice to spawn a process locally that grabs the buses if already on Linux and using the GPIO layer
<cr1901>
So that way the examples don't really change in the Linux case
<cr1901>
(i.e. the classic fork/exec a server process that the client subsequently connects to. But I'm just thinking out loud rn)
<re_irc>
< (@jamesmunns:beeper.com)> I admit, my brain is totally somewhere else, but I replied on cohost :)