<re_irc>
<@firefrommoonlight:matrix.org> xiretza: Your code snippet for the raw pointer indexing worked
tokomak has joined #rust-embedded
starblue1 has quit [Ping timeout: 265 seconds]
starblue1 has joined #rust-embedded
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@jacobrosenthal:matrix.org> firefrommoonlight:matrix.org: still feels pretty C with the in/out args. Not sure if move semantics will save you if you return an array
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure how to avoid that without using an allocator
<re_irc>
<@firefrommoonlight:matrix.org> That's how I've been doing all data manipulation in embedded. Ie, passing array refs that are allocated upstream
<re_irc>
<@firefrommoonlight:matrix.org> What would you recommend? Is the `heapless` dependency your example uses related?
<re_irc>
<@firefrommoonlight:matrix.org> Or, stated another way: How would you do it?
<re_irc>
<@firefrommoonlight:matrix.org> In a decoupled, standalone-fn way
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> The most egregious in the API I posted is the `filter_coeffs: &[f32],` parameter: This is boilerplate, and the only reason it's passed is so you can allocate the memory for it in a way that satisfies the compiler. Would love to remove that. And the output buffer as well
<re_irc>
<@firefrommoonlight:matrix.org> *I mean `fir_state: &mut [f32],`
<re_irc>
<@firefrommoonlight:matrix.org> `filter_coffs` is very important!
<re_irc>
<@firefrommoonlight:matrix.org> *tangent: I'm messing with the Q31 stuff now. Not too bad. Subtleties about them are documented in the CMSIS doc, like how sin is 0 to .999, so I have code like this for floats:
<re_irc>
<@firefrommoonlight:matrix.org> ```rust
<re_irc>
<@firefrommoonlight:matrix.org> for i in 0..TEST_SIZE {
<re_irc>
<@firefrommoonlight:matrix.org> result[i] = unsafe { arm_sin_f32(freq * 2. * PI * i as f32 / TEST_SIZE as f32) };
<re_irc>
<@firefrommoonlight:matrix.org> It also seems to make perfectly efficient use of the whole 32-bit space to represent sin values
<re_irc>
<@firefrommoonlight:matrix.org> for insane resolution
<re_irc>
<@jacobrosenthal:matrix.org> firefrommoonlight:matrix.org: I don't know :) I never did it. Const generics something something
<re_irc>
<@jacobrosenthal:matrix.org> But to me it doesn't gain too much over the underlying yet
e-snail has quit [*.net *.split]
Amadiro has quit [Ping timeout: 252 seconds]
Amadiro has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
wose has quit [*.net *.split]
wose has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
dcz_ has joined #rust-embedded
creich has joined #rust-embedded
gsalazar has joined #rust-embedded
dfgweb has joined #rust-embedded
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
xnor has quit [Ping timeout: 252 seconds]
xnor has joined #rust-embedded
gsalazar_ is now known as gsalazar
dcz_ has quit [Ping timeout: 264 seconds]
fabic has quit [Ping timeout: 264 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
xnor has quit [Changing host]
xnor has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> This is so weird; I'm copying `defmt` output from Stm32 into an iPython terminal, and Scipy filter coefficients back to STM32 code, and it's working as expected
<re_irc>
<@firefrommoonlight:matrix.org> (Of course it is, but it's still a surprising workflow)
GenTooMan has quit [Read error: No route to host]
GenTooMan has joined #rust-embedded
dcz_ has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
dcz has joined #rust-embedded
dcz_ has quit [Ping timeout: 265 seconds]
<re_irc>
<@lachlansneff:matrix.org> If an SPI peripheral is configured for 24 bit words, how should I go about communicating with it with embedded hal?
<re_irc>
<@lachlansneff:matrix.org> Related question: to do analog reads of say 30 sensors at once, would the best approach be to use a couple ADCs that can do multiple channel sampling?
<re_irc>
<@newam:matrix.org> ADCs are a difficult topic, what you can do really depends on the signal you're sampling, though if it's low frequency then you can get away with anything.
<re_irc>
<@lachlansneff:matrix.org> The signals are not AC, they're constant voltage outputs from various kinds of sensors.
<re_irc>
<@lachlansneff:matrix.org> But I want to sample all 30ish sensors at 100 Hz, which seems to be more complicated than I thought it would be
<re_irc>
<@newam:matrix.org> Oh yeah, you definitely get away with anything then. You'll probably want a delta-sigma ADC with a giant mux... Though going for 15 cheap ADCs may be more cost effective if board space isn't a consideration.
<re_irc>
<@lachlansneff:matrix.org> I was looking at using a few ADCs with large muxes, but it seemed like sampling each channel, one after another, was going to take way too long
<re_irc>
<@lachlansneff:matrix.org> Maybe that was just a slow adc I was looking at
<re_irc>
<@newam:matrix.org> Muxes can be slow to switch, you can get ADCs with a built-in round robin mode to automatically switch to the next input after sampling the previous.
<re_irc>
<@newam:matrix.org> If you don't need high resolution you can get 8-bit SAR ADCs with giant muxes, they have basically no sample and hold time so you can switch between inputs real fast, but they are costly if you need high resolution
<re_irc>
<@lachlansneff:matrix.org> Yeah, I think I need more like 16 bit
<re_irc>
<@newam:matrix.org> Ahh, yeah, for that you'll probably be looking at lots of 2/4/8 channel delta-sigma ADCs.
<re_irc>
<@lachlansneff:matrix.org> Ah, gotcha
<re_irc>
<@lachlansneff:matrix.org> And lots of SPI multiplexing i guess
<re_irc>
<@newam:matrix.org> Yeupp. Though do prototype a bit. 16-bits is a lot, and often you can get away with lower resolutions and firmware oversampling (if you have the cycles for it on your CPU)
<re_irc>
<@lachlansneff:matrix.org> Hmm, I will look into that
<re_irc>
<@lachlansneff:matrix.org> Most of the sensors are thermocouples, and we probably want resolution of a degree or so
<re_irc>
<@lachlansneff:matrix.org> Maybe we could get away with 12 bit
<re_irc>
<@firefrommoonlight:matrix.org> Set up a sequence using DMA for best performance
<re_irc>
<@firefrommoonlight:matrix.org> It has up to 5 independent ADCs, each with many channels
<re_irc>
<@lachlansneff:matrix.org> You can do an automatic dma sequence like that?
<re_irc>
<@firefrommoonlight:matrix.org> Yep
<re_irc>
<@newam:matrix.org> And most ST ADCs have round-robin modes too
<re_irc>
<@firefrommoonlight:matrix.org> You configure the sequences in the ADC registers, then fire the DMA once and it can do them all in seq (Maybe fire the DMA 4 or 5 times for each ADC? Not sure if there's a shortcut for linking multiple ADCs)
<re_irc>
<@firefrommoonlight:matrix.org> I think you could do a circular buffer too for a continuous cycling of the channels, but I"m not sure and haven't tried it
<re_irc>
<@lachlansneff:matrix.org> Looks like the chip I already have has 16 channels or 24 channels, it’s a little difficult to tel
<re_irc>
<@firefrommoonlight:matrix.org> You can do something similar on any STM32, but I mention G4 since it has the most independent ADCs
<re_irc>
<@firefrommoonlight:matrix.org> And again, package size matters here so you can get enough pins
<re_irc>
<@firefrommoonlight:matrix.org> If that has enough channels, yea, F4 is fine too
<re_irc>
<@firefrommoonlight:matrix.org> Looks like that's 3 independent ADCs with 16 channels too. Should be fine
<re_irc>
<@firefrommoonlight:matrix.org> Check out your MCU's RM, sections 13.8.1 and 13.8.2. The former decribes doing sequences using DMA. The second without
<re_irc>
<@firefrommoonlight:matrix.org> See section 13.9 Multi ADC mode, for linking up multiple ADCs, which you need in this case
emerent is now known as Guest7280
Guest7280 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
emerent has joined #rust-embedded
dcz has quit [Read error: Connection reset by peer]
dcz has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> *maybe not need. You could manage them all independently too, but perhaps the linking functionality will make things simpler
tokomak has quit [Read error: Connection reset by peer]
dcz has quit [Ping timeout: 252 seconds]
<re_irc>
<@lachlansneff:matrix.org> Ah thank you, that’s all really helpful
<re_irc>
<@lachlansneff:matrix.org> adamgreig: What is CTCFT?
<re_irc>
<@dirbaio:matrix.org> Cross-Team Collaboration Fun Times
<re_irc>
<@adamgreig:matrix.org> the website has some info and FAQs, it's been a few months since the last one! the main agenda item today is a panel with the various working groups
<re_irc>
<@lachlansneff:matrix.org> firefrommoonlight:matrix.org: I read through the documentation and that all makes sense, thanks. I'll be going with this approach for all the sensors that are single-ended or that we convert from differential to single-ended.
<re_irc>
<@adamgreig:matrix.org> btw for those ADCs, it's worth working out if you require all channels sampled simultaneously or not, sometimes that matters (like if you're doing analysis later and want to know the temperature everywhere at once), sometimes not so much (if you are mostly concerned with slower trends or time series of specific points)
<re_irc>
<@adamgreig:matrix.org> in general doing it simultaneously is harder
<re_irc>
<@lachlansneff:matrix.org> That’s a good question. In this case, I want all the channels sampled close to each other in time. But if they’re a millisecond or two off, it’s not a big deal.
<re_irc>
<@adamgreig:matrix.org> if you can record the actual time you sampled each channel, you can often interpolate to find a common timebase, too
<re_irc>
<@adamgreig:matrix.org> on the stm32 for example adc1/2/3 can sample at the same time while switching between the inputs, so you can do 3 simultaneous across any of the ~16 input channels, while sweeping through them in a circle
<re_irc>
<@adamgreig:matrix.org> but yea, if it's thermocouples at ~100Hz samples per second per channel, probably not too bad to get right
<re_irc>
<@adamgreig:matrix.org> how are you measuring the cold junction temperature?
<re_irc>
<@lachlansneff:matrix.org> That is a great question.
<re_irc>
<@adamgreig:matrix.org> any digital temperature sensor that you can put in thermal contact with the cold junction can work well, and since you can usually talk to them over i2c or spi, it doesn't use up an analogue channel
<re_irc>
<@lachlansneff:matrix.org> Yeah, I have now looking into thermocouples more
<re_irc>
<@lachlansneff:matrix.org> I guess my best bet would be to just use a max13855, which can do all that for me
<re_irc>
<@lachlansneff:matrix.org> But I’ll need 10 of them, so a bunch of spi muxing
<re_irc>
<@lachlansneff:matrix.org> I wonder what the latency for each read would be
<re_irc>
<@lachlansneff:matrix.org> Damn, conversion time on one of those is 70 ms
<re_irc>
<@adamgreig:matrix.org> yea, those sorts of chips are super nice for easy-reading of thermocouples (no other analogue components needed at all!) but often really slow
<re_irc>
<@adamgreig:matrix.org> for loads of use cases the speed just isn't important because so few things can change temperature faster than like 10Hz anyway
<re_irc>
<@adamgreig:matrix.org> doing cold junction compensation isn't magic though, you just need to know the temperature of the junction where the thermocouple wire meets copper, typically the connector on your pcb
<re_irc>
<@adamgreig:matrix.org> so any digital temperature sensor can tell you that, and it doesn't usually change quickly, then you just add that temperature to the thermocouple voltage to get the actual thermocouple temperature
<re_irc>
<@lachlansneff:matrix.org> Ah, that makes sense. So I can update the reference at like 10 Hz or whatever, but grab the thermocouple temp at 100 or 1000 Hz.
<re_irc>
<@adamgreig:matrix.org> yea, exactly
<re_irc>
<@adamgreig:matrix.org> if you use an analogue temperature sensor for that, you can just sample it as part of your normal adc sampling routine, but it uses up an analogue channel... hard to say which is easier
<re_irc>
<@adamgreig:matrix.org> you can buy ICs/sensors that output a voltage that's proportional to (absolute) temperature, or there are various tricks using any diode/transistor too
<re_irc>
<@adamgreig:matrix.org> (but I think a digital temperature sensor is probably easiest and most accurate)
<re_irc>
<@lachlansneff:matrix.org> Ah, okay.
<re_irc>
<@lachlansneff:matrix.org> This is great information, thank you.
<re_irc>
<@adamgreig:matrix.org> if your thermocouple connectors might be at different temperatures (because they're on different boards, or there's some temperature gradient across the board or something), you might want more than one cold junction sensor, but it sort of depends what accuracy you care about too
<re_irc>
<@adamgreig:matrix.org> some things just guess the cold junction is about 20C because it's about room temperature, and if it's wrong by 20C it doesn't really matter if you're measuring like 1500C lol
<re_irc>
<@lachlansneff:matrix.org> That’s a good point lmao
<re_irc>
<@adamgreig:matrix.org> but best to correct for it :p