<re_irc>
<@dkhayes117:matrix.org> Using DMA to write ADC measurements continuously to external flash (maybe SD card?), then using the cpu to poll the flash with a certain window size (not being written to of course) and run some analysis on it. Each data point would be an ADC value and a timestamp. I would be doing high sample rate with the ADC like several thousand samples per sec, flash wear-out might be a problem.
<re_irc>
<@dkhayes117:matrix.org> I'm continuing my thoughts on a project that I have in mind...
<re_irc>
<@dkhayes117:matrix.org> Any opinions is appreciated, if so inclined :)
<re_irc>
<@firefrommoonlight:matrix.org> Other than the flash wear-out (Which may or may not be something you can mitigate by balancing the sectors used), that's straightfwd to set up
<re_irc>
<@firefrommoonlight:matrix.org> Whether that's the right approach for your project requirements... not enough info
<re_irc>
<@firefrommoonlight:matrix.org> I think the best way to set it up is a periph-to-mem transfer, using QSPI, memory-mapped
<re_irc>
<@firefrommoonlight:matrix.org> You'd have to take some care on how you start and stop the transfers etc when managing which block you're writing to. I think that's where the technical subtlety and potential mistakes would come in
<re_irc>
<@firefrommoonlight:matrix.org> I guess you could just set certain criteria that triggers the transfer to stop, then restart it pointing to the next block
<re_irc>
<@dkhayes117:matrix.org> I definately have some more studying to do. I'm looking at implementing continuous point-on-wave (CPOW) monitoring for power systems. Typical phasor measurement units (PMUs) typically take 30-60 samples per sec, run through a low pass filter and force fit to a sine wave.
<re_irc>
<@dkhayes117:matrix.org> CPOW would take thousands of samples per sec with little filtering with no force fitting. This will help identify unclassified disturbance events and document fast acting transients that PMUs can miss.
<re_irc>
<@dkhayes117:matrix.org> I basically will just document the a scalar valuse with an associated utc timestamp.
<re_irc>
<@adamgreig:matrix.org> could you write to ram? thousands of samples per second sounds like an awful lot of data to be continuously writing to flash, and you'll need to work really hard to work around erasure times and stuff
<re_irc>
<@adamgreig:matrix.org> hmm, sd card easier for sure
<re_irc>
<@adamgreig:matrix.org> especially if you have an actual sd card peripheral on your microcontroller and it can dma, it's probably not awful, but if you're planning on leaving this going indefinitely it's gonna wear out or fill up...
<re_irc>
<@dkhayes117:matrix.org> Yeah, that is what I'm trying to figure out. I need to run some sort of undetermined analysis on the data without impeding sample taking. I thought that writing to flash then polling "old" data would allow for writing and analysis to be mutually exclusive?
<re_irc>
<@firefrommoonlight:matrix.org> Or shit, send it to a PC over USB, then log on a HD if it's a lot of data
<re_irc>
<@firefrommoonlight:matrix.org> You could do it via a serial protocol easily
<re_irc>
<@firefrommoonlight:matrix.org> with appropriate firmware on the PC written in whatever lang you want, Rust included
<re_irc>
<@firefrommoonlight:matrix.org> that would handle the actual logging, retrieval, display etc
<re_irc>
<@9names:matrix.org> FRAM could also work for this.
<re_irc>
<@9names:matrix.org> Also seen a few projects where they just use bank switching between multiple spi ram chips too
<re_irc>
<@adamgreig:matrix.org> having to both read and write the flash at the same time, then load the old data into memory for analysis, seems like it would only add complexity
<re_irc>
<@dkhayes117:matrix.org> I'm not sure that keeping the data is so important. I would hold as much data as possible where analysis would determine if a disturbance event happened, which would trigger a data dump. These will be remotely deployed in the field. Writing over old data wouldn't be an issue.
<re_irc>
<@firefrommoonlight:matrix.org> How big of a block size are we talking?
<re_irc>
<@dkhayes117:matrix.org> as long as no significant data was detected
<re_irc>
<@firefrommoonlight:matrix.org> I'm with Agg that if you can go smaller (RAM) or larger (A more robust storage medium) it would be better
<re_irc>
<@adamgreig:matrix.org> so perhaps you can have enough RAM to store your analysis period/window, and dump that to flash occasionally when you detect an event?
<re_irc>
<@firefrommoonlight:matrix.org> Flash isn't the right tool for continuous writes
<re_irc>
<@adamgreig:matrix.org> at least not for data you don't need to keep
<re_irc>
<@adamgreig:matrix.org> if you wanted to log thousands of samples/second for months or years _and keep the data for later_ then you don't have much choice, but i'd send it over a network or something to an SSD or HDD
<re_irc>
<@adamgreig:matrix.org> but if you just need to keep it long enough to analyse and probably throw away, RAM's the thing, I think
<re_irc>
<@adamgreig:matrix.org> might be fun to see just how quickly you wear out an SD card :P
<re_irc>
<@adamgreig:matrix.org> but it's so much work to read and write that data, and you'll have to buffer it through RAM anyway - sd cards can just pause for a few hundred msec while they think about things, and you'd be reading back the stored data to analyse, so...
<re_irc>
<@dkhayes117:matrix.org> I see what you guys are saying, I'm in personally uncharted territory :P
<re_irc>
<@dkhayes117:matrix.org> This is for my thesis by the way :) I'm working on putting my proposal together.
<re_irc>
<@firefrommoonlight:matrix.org> You know roughly the data rate. I think the next step is determining block size
<re_irc>
<@firefrommoonlight:matrix.org> And questions like "Is this system causal?". Eg, do you need any look-fwd? If so, how much? How will you keep track of state, or will you analyze discrete blocks?
<re_irc>
<@firefrommoonlight:matrix.org> How much delay is acceptable etc
<re_irc>
<@dkhayes117:matrix.org> Yep, more questions I need to answer. I've got plenty of food for thought now. I'll get back when I have some more answers to the design requirements.
<re_irc>
<@dkhayes117:matrix.org> Thanks!
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<re_irc>
<@huntc:matrix.org> Perhaps not strictly an embedded question, but has anyone here tried doing anything with Matter, formally Project CHIP? Seems that the approach is to use C++ from a reference perspective. I’m looking for a spec, or better, a start in implementing Matter with Rust. Thanks.
<re_irc>
<@ryan-summers:matrix.org> Man, it's really hard to create a useful timer driver in a HAL that works for everyone - I've yet to see an implementation I like, but also see why it's super hard
<re_irc>
<@firefrommoonlight:matrix.org> What issue have you run into Ryan?
<re_irc>
<@ryan-summers:matrix.org> Generally, I want to use timers in all kinds of ways, but often my applications are so specific that all I want out of the HAL is the ability to set the frequency of counting and the max count value
<re_irc>
<@ryan-summers:matrix.org> Then I just check for overflows etc. manually in register land
<re_irc>
<@ryan-summers:matrix.org> E.g. using timers to timestamp incoming ADC samples, use timers for a system timer running at 10KHz for embedded-time, etc.
gsalazar_ has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> I don't really want the HAL to give me super high level "Count Downs or anything like that, I just want it to give me the flexibility to use the timer without me having to worry about the semantics of the RCC enables etc.
<re_irc>
<@ryan-summers:matrix.org> Because I'll likely always have to use register manipulation in some way, e.g. if you want to chain timers together to get more capture channels
gsalazar has quit [Read error: Connection reset by peer]
<re_irc>
<@ryan-summers:matrix.org> Generally, I just take the opinion that timers are so versatile that it's not super feasible to have a generic high-level API that satisfies everyone
gsalazar__ has joined #rust-embedded
gsalazar_ has quit [Ping timeout: 240 seconds]
<re_irc>
<@therealprof:matrix.org> huntc:matrix.org: Isn't Matter just a weird conglomerate of companies throwing a ton of random approaches into a pot and somehow trying to make all of that interoperate? I haven't seen any tangible material yet indicating that they have a proven plan, so far it seems to be all just "vision" and marketing fluff.
gsalazar__ has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<@chrysn:matrix.org> Is there an established crate that passes something 'a into a closure as 'static from the knowledge that the closure will not terminate (and having the proper guards to prevent unwinding)?
<re_irc>
<@chrysn:matrix.org> I think that should be sound to do, and should just be a few lines, but I'd prefer to use a crate in whose documentation the full argument is made. (That might all be similar to `take_mut`, or `pin_utils::pin_mut`).
<re_irc>
<@chrysn:matrix.org> s/take_mut/replace_with/ in embedded use cases -- but same thing.
<re_irc>
<@chrysn:matrix.org> fn main() -> ! {
<re_irc>
<@chrysn:matrix.org> The alternative to the pattern of
<re_irc>
<@chrysn:matrix.org> let x = something_local();
<re_irc>
<@firefrommoonlight:matrix.org> ryan-summers:matrix.org: I don't think anything you posted is too specific or hard to implement with HAL-level APIs
<re_irc>
<@ryan-summers:matrix.org> It's not, but I've seen many HALs that don't do that and opt for the high level API
<re_irc>
<@ryan-summers:matrix.org> And then you have to steal registers from underneath them to do your own manipulations/probings etc.
<re_irc>
<@firefrommoonlight:matrix.org> You've inspired me to take a pass over timer HAL code again. Needs work
<re_irc>
<@dirbaio:matrix.org> stm32 timers are monsters
<re_irc>
<@ryan-summers:matrix.org> If you want a sample of what I mean, I had a specific use case where I needed to chain two timers in slave configurations to have multiple capture channels running with a common time base - https://github.com/quartiq/stabilizer/blob/master/src/hardware/timers.rs
<re_irc>
<@ryan-summers:matrix.org> This is with the stm32h7 family
<re_irc>
<@ryan-summers:matrix.org> Which actually did a really nice job of providing a relatively low API, but I still had to fight it
<re_irc>
<@dirbaio:matrix.org> it's a hard problem yep :S
<re_irc>
<@ryan-summers:matrix.org> Like I said, timers are incredibly complex, and like you said, particularly stm32 timers
<re_irc>
<@ryan-summers:matrix.org> Generally all I want from the HAL is for it to tell me what the source clock is
<re_irc>
<@firefrommoonlight:matrix.org> The overlapping feature sets across stm32 timers and variants is a pain
<re_irc>
<@ryan-summers:matrix.org> I'll do prescaling/period register configurations myself with that intel, but finding out which clock is sourcing is generally non-trivial because it depends on the APB
<re_irc>
<@firefrommoonlight:matrix.org> I understand why it's easier for you to use registers directly here
<re_irc>
<@firefrommoonlight:matrix.org> But hopefully we can resolve this
<re_irc>
<@ryan-summers:matrix.org> Although I think I could do the clock differently with the API, it ended up just being easier to use regs
<re_irc>
<@dirbaio:matrix.org> I kinda think it's impossible to write a stm32 timer HAL exposing all the functionality, without it becoming as complex as the PAC (thus useless) :S
<re_irc>
<@ryan-summers:matrix.org> Yeah, I agree, which is why I haven't really tried to land any of this in the HAL
<re_irc>
<@ryan-summers:matrix.org> The possibilities are just crazy with flexibility
<re_irc>
<@dirbaio:matrix.org> maybe it's "okay" for HALs to focus on higher-level use cases
<re_irc>
<@dirbaio:matrix.org> maybe even multiple drivers for the same hw peripheral (countdown timer, rolling timer, counter, pwm..)
<re_irc>
<@dirbaio:matrix.org> and then accept that more advanced users will have to use the PAC directly...
<re_irc>
<@ryan-summers:matrix.org> It would just be nice if they exposed the basic timer operations like getting the input clock in an accessible manner so you can manually do things with registers after that
<re_irc>
<@firefrommoonlight:matrix.org> I'm worried you might be right, but an compelled to test it
<re_irc>
<@dirbaio:matrix.org> yeah, providing the right "escape hatches" would be cool
<re_irc>
<@ryan-summers:matrix.org> Getting the source clock for a timer peripheral tends to be the most convoluted part imo
<re_irc>
<@ryan-summers:matrix.org> Obviously platform dependent here
<re_irc>
<@ryan-summers:matrix.org> Especially on stm32s because you also have to reset/enable the timer peripheral in the RCC before using it
<re_irc>
<@dirbaio:matrix.org> indeed
<re_irc>
<@dirbaio:matrix.org> embassy has this, I think many stm32xx-hals also have something similar
<re_irc>
<@dirbaio:matrix.org> that's exactly the "escape hatch" we want here, right? :D
<re_irc>
<@dirbaio:matrix.org> it's for internal use only though, maybe it should be public
<re_irc>
<@dirbaio:matrix.org> it's impl'd for all peripheral singletons, like TIM3, TIM4...
<re_irc>
<@ryan-summers:matrix.org> I particularly dislike any time HALs do "sealed" type traits :(
<re_irc>
<@ryan-summers:matrix.org> But also usually understand it, just get frustrated out of inconvenience
<re_irc>
<@dirbaio:matrix.org> well, in this particular case you don't want to impl the trait yourself, just use it, right?
<re_irc>
<@dirbaio:matrix.org> so it'd just need moving the methods from the sealed (private) trait to the public one
<re_irc>
<@firefrommoonlight:matrix.org> What's the use case specifically for pulling the timer clock used on STM?
<re_irc>
<@firefrommoonlight:matrix.org> Eg from a Timer struct directly
<re_irc>
<@ryan-summers:matrix.org> Generally the higher level use case is to just set a tick frequency
<re_irc>
<@firefrommoonlight:matrix.org> The perk is not needing to look up which apb clock it uses, but I don't follow the next step, vice handling that with a Clocks periph
<re_irc>
<@firefrommoonlight:matrix.org> Isn't that handled internally?
<re_irc>
<@firefrommoonlight:matrix.org> Eg you set the tick, and the timer method sets it appropriately
<re_irc>
<@dirbaio:matrix.org> if it's handled internally by the HAL it's all fine
<re_irc>
<@ryan-summers:matrix.org> Not all HALs do it like that
<re_irc>
<@dirbaio:matrix.org> if you want to manually do raw reg writes because the HAL doesn't do what you do, you need to calculate prescalers/dividers on your own
<re_irc>
<@dirbaio:matrix.org> and for that you need the HAL to tell you "the input freq to the timer block is X hz"
<re_irc>
<@huntc:matrix.org> Attaining the draft spec seems impossible right now unless you pay us$7k.
<cr1901>
Thankfully I build Rust/LLVM about once every 2 release cycles to prime sccache
<cr1901>
So shouldn't take me long to get it back
<re_irc>
<@chrysn:matrix.org> irc_libera_cr1901:psion.agg.io: I swallowed pretty hard too. Fortunately, of all the llvm_asm I'm getting from C2Rust transpilation, it turned out only 5-6 snippets are actually used, so now I have a small implementation of `llvm_asm!` that can change a very very very limited and hardcoded set of assembly.
<cr1901>
I don't actually know LLVM. I don't even know if the LLVM impl follows TI's ABI
<re_irc>
<@kevlan:matrix.org> For folks running rust on nRF52/nRF53 what are you doing for the Bluetooth library?
<re_irc>
<@kevlan:matrix.org> I took a look at Rubble but since it is not certified yet I'm not sure I want to go ahead and throw it into a product.
<re_irc>
<@kevlan:matrix.org> Is there a reasonable way to wrap Nordic's library to call it from Rust?
<cr1901>
Would I need to look at the generic TargetLowering::getRegForInline... and see what restrictions that function provides on its inputs?
<cr1901>
(There's two RegisterClasses... GP8 and GP16. For better or worse, that sounds about right for msp430 b/c PC, SP, etc are user visible)
<re_irc>
<@dirbaio:matrix.org> Amanieu's messages aren't showing for me on the matrix side, maybe there's something broken with the bridge?
<re_irc>
<@adamgreig:matrix.org> ugh, weird, it's meant to have a fallback for that too
<re_irc>
<@adamgreig:matrix.org> I'll give it a kick
<cr1901>
They saw my messages and responded earlier, FWIW
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> you're both natively on IRC
<agg>
(testing)
<cr1901>
Ahhh
<agg>
weird, messages from me aren't going through either but yours are?
<re_irc>
<@adamgreig:matrix.org> ugh, the bridge is sending messages to the homeserver OK it seems
<re_irc>
<@adamgreig:matrix.org> ah, there we go? it's just very slow?
<agg>
testing again
<re_irc>
<@therealprof:matrix.org> huntc:matrix.org: The problem here is manifold. There's no clear objective, there's no published architecture, not even sure there's a plan. The initiative set out to unify all the major "IoT" approaches out there, mainly Apple HomeKit, Google Nest (and potentially others?), Amazon Alexa something and whatnot. My best guess would be that it was started to preempt regulators from looking too deep into all...
<re_irc>
... the proprietary and incompatible environments; they allude to that goal in https://github.com/project-chip/connectedhomeip#current-status-of-matter. What is currently in the GH repo is just some failed pieces of junk cobbled together to demonstrate activity; I'm seeing a large piece of (failed) Thread stack, some experiements from Apple in the IoT world and some other stuff. "Let's focus on low power devices" is code for give...
<re_irc>
... people a bone and distract them from actually interoperating with off-shelve-hardware from the big manufacturers. They haven't even managed to redraw the few diagrams and pictures to feature the new name announced many months ago...
<cr1901>
How does LLVM get the MVT from an inline assembly expression?
<re_irc>
<@k900:0upti.me> ends_with matches on full components
<re_irc>
<@dirbaio:matrix.org> oooooooh 😂
<re_irc>
<@dirbaio:matrix.org> thanks!
<re_irc>
<@dirbaio:matrix.org> it's a nice footgun then, it does something completely different than `ends_with` on strings, and paths are "kind of almost like strings"....
<re_irc>
<@k900:0upti.me> Yeah, it's better to think of `Path`s as a `Vec<String>`
<re_irc>
<@k900:0upti.me> Kind of
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<agg>
(testing)
<re_irc>
<@adamgreig:matrix.org> hopefully bridge is OK now...
<Amanieu>
cr1901: From LLVM I can see that the register accepts i8 and i16 types.
<Amanieu>
The MVT is the type of whatever variable is passed in as an argument. We need to restrict this on the rustc side to only allow i8/i16.
<Amanieu>
Registers r0-r4 are reserved by LLVM.
<re_irc>
<@2:0x2c.org> hey!
<cr1901>
Ahhh I didn't look at the reserved registers yet. I was writing the boilerplate into rustc_target/asm/mod.rs. And now I'm eating dinner. Afterwards, I will start impl'ing :)
<re_irc>
<@kevlan:matrix.org> dirbaio:matrix.org: Thanks, that's exactly what I was looking for! I haven't looked into it much but it seems like on the nRF53 it would be possible to just throw the bluetooth stack on one of the cores that Nordic provides and then run pure rust on the other core for the application logic. I'll have to look into how Nordic structures their SDK if we decide to go with that chip.
<re_irc>
<@dirbaio:matrix.org> kevlan: the problem for nrf53 is they only provide the "softdevice controller", which is the "controller" part of the stack only, you need to supply the "host" part yourself
<re_irc>
<@dirbaio:matrix.org> they use zephyr's host stack for that
<re_irc>
<@tarfu:matrix.org> The amount of times the nrf53 topic comes up seems like it really needs a nrf53/ble-host stack group :D
<re_irc>
<@dirbaio:matrix.org> a rust ble host stack would be super useful for lots of chips: nrf52, stm32wl..
<re_irc>
<@dirbaio:matrix.org> but it's complex
<re_irc>
<@dirbaio:matrix.org> and requires certification if you want to use it in a final product 💰️
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: stm32wl is for generic GFSK/LoRa, the stm32wb is for Bluetooth
<re_irc>
<@tarfu:matrix.org> dirbaio:matrix.org: Maybe a group effort could finance it. I (my company :D ) would put something in ...
<cr1901>
Amanieu: Is there any particular reason that the InlineAsmRegClasses are only inherent impls and not part of a trait?
<cr1901>
They all seem to have the same methods
<Amanieu>
There was no reason to make a trait. The enum dispatching in the common code doesn't need traits.
<Amanieu>
As a general rule, only use traits when you *need* to, not when you *can*.
<cr1901>
ahhh
<cr1901>
I'm educated guessing what each function does by looking at other AsmRegClass impls do
<cr1901>
(if it were a trait, then all the documentation would be in one place. <-- this is me just thinking out loud)
<re_irc>
<@kevlan:matrix.org> dirbaio:matrix.org: Is it possible to run Zephyr on just the network processor on the nrf53 and then run rust on the applications processor?
<re_irc>
<@dirbaio:matrix.org> yeah each run its own independent firmware
<re_irc>
<@dirbaio:matrix.org> you'd have to invent your own IPC to tell the zephyr side what to do, which could be annoying
<re_irc>
<@dirbaio:matrix.org> but it's doable
<re_irc>
<@kevlan:matrix.org> Cool, that might be something I look into then if we choose that part.
<re_irc>
<@pinealservo:matrix.org> The host part of a bluetooth stack is not an insignificant piece of software.
<cr1901>
Amanieu: Hopefully last q for tonight... I got a prototype written. I'm testing it out before refining it 1/2
<cr1901>
If I have e.g. 'llvm_asm!(concat!("mov", $asm_suffix, " $1, $0")
<Amanieu>
I think something like that? Where @ is for register-indirect addressing
<cr1901>
Alternatively "mov r5, @r6" could be used, where "r6" contains the value of-
<cr1901>
yea, that works
<cr1901>
I was looking at my msp430 manual trying to remember the syntax (LABEL is PC-relative access, &LABEL is absolute, #LABEL is "a mess")
<cr1901>
Amanieu: Anyways, this'll be a good stopping point for tonight, tyvm for the help. Hopefully things will continue to go semi-smoothly
<Amanieu>
Sure! Let me know if you want me to review an early draft of the implementation.
<cr1901>
Amanieu: I appreciate it. I'll ping you tomorrow and link to my branches (rust and the two msp430 repos that need updating- one of them is trivial!)