00:41 <re_irc> < (@762spr:matrix.org)> : Some of the more advanced timers have an encoder mode. It is basically a fancier counter timer. Ive used it to count rising and falling edges on two channels (A and B on the encoder) 1024 total edges per revolution at 24k rpm. You can also trigger compare interrupts all in hardware so it it very accurate and fast.

00:52 <re_irc> < (@762spr:matrix.org)> Theoretical question for those of you that have more expierience than me (low bar 😅)

00:52 <re_irc> I was watching some videos on engine tuning earlier. They use various tables that are basically graphs with say a temperature sensor on the Y axis and RPM on X and where they intersect would be fuel delivered or something along those lines... anyway there are a bunch of these lookup tables and I would assume they need to be polled fairly often as parameters change quickly.

00:53 <re_irc> So I started wondering on an embedded system with limited RAM, what would be a good way to do this? Read directly from storage media on the fly? Use external RAM? Use a uC that just has enough RAM to keep every all the tables in arrays in memory? Secondary core/ uC that is dedicated to running the calculations and reading the tables?

00:55 <re_irc> < (@dirbaio:matrix.org)> store them in flash, which is typically bigger? I imagine they don't need to change at runtime

00:57 <re_irc> < (@akevinclark:matrix.org)> Evening folks! I'm driving two RCWL-1601 ultrasonic sensors (HC-SR04 equivalent but 3.3V) on GPIO (0,1) and (2,3) with an esp32-c3 on a DevKitC-02 and I get bizarre values on power (numbers 8-9x larger than expected across both sensors) but if I hit the reset button or fire up espmonitor I'm seeing good values. I see GPIO2 is a strapping pin but it looks like it only applies during SPI or download...

00:57 <re_irc> ... boot and the second sensor (on 0,1) is showing the exact same behavior. Thoughts?

00:57 <re_irc> Code is here: https://github.com/kevinclark/greywater/tree/main/src

00:58 <re_irc> < (@akevinclark:matrix.org)> Behavior is consistent. On power up, values are too big. On soft reset, values are fine.

01:04 <re_irc> < (@762spr:matrix.org)> : At runtime no, but they need to be configured eg. The tuning videos I was watching. Is it possible to load from external storage to flash?

01:05 <re_irc> < (@dirbaio:matrix.org)> mcus typically allow firmware to write to the internal flash, yes

01:06 <re_irc> < (@dirbaio:matrix.org)> if you do need to change it whlie the engine is running, flash might not be the best option though... writing is usually slow and doesn't allow concurrent read accesses :D

01:07 <re_irc> < (@762spr:matrix.org)> Interesting I will have to look into it. Its not something immediatly pertinent, but while I was learning about tuning the thought occurred to me and got me thinking 😅

01:10 <re_irc> < (@762spr:matrix.org)> What about something like loading it from SD to qspi at boot and then work from there? I would assume that would have faster access times than SD alone

01:11 <re_irc> < (@dirbaio:matrix.org)> qspi flash?

01:11 <re_irc> < (@dirbaio:matrix.org)> I guess same problem would apply, writing to it is slow and you can't read while writing

01:13 <re_irc> < (@762spr:matrix.org)> Ah OK. Yeah these are the kinds of things where my lack of expierience really show haha but Im slowly learning!

01:19 <re_irc> < (@762spr:matrix.org)> I guess depending on how big the tables are it may be possible to just load them directly into memory too, just exercising the design extremes in my head...

06:31 <re_irc> <Sean Lyons> : Agree with . You want to offload as much calculation and preprocessing to a PC and then just store the most minimal representation of the table in flash. If the table is too big there are a couple things you could try each with a tradeoff:

06:31 <re_irc> 1. Change the data format (e.g. migrating rom u32 to u16 or from f64 to some fixed point). This might trade some accuracy since the coefficients aren’t as accurate.

06:31 <re_irc> 2. Reduce the number of points stored, this also reduces accuracy but because of another reason, because you have to interpolate more between points

06:31 <re_irc> 3. Some combination of 1-2

06:31 <re_irc> 4. Drop the look up table and calculate on the fly on device…this will be slow and take a lot of runtime, but if you really have no space left it could be an option.

06:47 <re_irc> <Sean Lyons> As for SD, qSPI, etc. It depends on your requirements for how fast you need to be able to read the data. Internal memory is fastest but most limited. Also if you assume no huge jumps in temp you could load part of the table e.g. between 20-30C into the internal memory and only swap to a lower temperature range when your temp sensor crosses a certain threshold

07:49 <re_irc> < (@barafael:matrix.org)> Dlaw: Awesome, thanks!!!

08:57 <re_irc> < (@762spr:matrix.org)> Sean Lyons: True, with cleverness you could only load the range you are working with. I guess most parameters would be fairly stable like temperature and barometric pressure, while stuff like RPM would be more volatile. Its an interesting situation for sure. Fun to think about! I appreciate everyone's input!

09:40 <re_irc> <Sean Lyons> Is there any spec or guidance for making pacs? I am new to rust but experienced with embedded, and wanted to learn by doing. I looked around the Nordic, ST, and TI TM4C repos and they seem to be all slightly different. Any advice on which to follow? So far, I am copying the "nrf-pacs" since I was able to get up and running with "tixml2svd" and then "svd2rust".

09:40 <re_irc> Background is that the microcontrollers I know most about are not oxidized yet. General advice is appreciated.

09:42 <re_irc> <Sean Lyons> Some specifics:

09:42 <re_irc> 1. How to handle chip families that have lots of shared peripherals but some _slight_ differences between them?

09:42 <re_irc> 2. How to test pacs before the HALs exist? How to know that what comes out of svd2rust is correct?

09:45 <re_irc> < (@9names:matrix.org)> the more common problem is is that the SVD is wrong, which you can only really verify by comparing against the datasheet and/or the C SDK

09:48 <re_irc> < (@9names:matrix.org)> the first point has many different answers, but perhaps you should try to get something for one chip variant before diving too deep on how to deal with more.

09:48 <re_irc> the answers you get may not be particularly helpful at this stage

09:57 <re_irc> < (@burrbull:matrix.org)> Sean Lyons: 1. There is no built-in possibility to share SVD between devices. You need to have 1 SVD per device. If differences are small you could create 1 common SVD(xml or similary looked yaml) and then you "svdtools patch" to make changes you need for other devices.

09:57 <re_irc> 2. You don't need HAL to test result. "pac" + "cortex-m" have all you need to create minimal working firmware.

09:58 <re_irc> <FredrikLL> I have a SoC that has peripherals with normal registers first, followed by set, clr and tgl register blocks for each of them. The set, clr and tgl registers are missing from the svd file. What would be the best way of adding them? Is that what the cluster or array elements are for?

09:58 <re_irc> My current strategy is to derive them from the normal register and override the offset and the reset value. This causes a naming conflict so I have a rename all the normal registers as well. This becomes a lot of work so was hoping for some type of shorthand. Anyone know of a better way?

10:00 <re_irc> < (@burrbull:matrix.org)> "set, clr and tgl register blocks" what are those and why you need them?

10:02 <re_irc> < (@xiretza:xiretza.xyz)> : they allow you to set/clear/toggle bits with one write instead of a read-modify-write

10:07 <re_irc> < (@burrbull:matrix.org)> are addresses of those registers identical or different?

10:09 <re_irc> <FredrikLL> The normal registers have offset 0x00xx, set 0x10xx, clr 0x20xx and tgl 0x30xx

10:09 <re_irc> < (@burrbull:matrix.org)> ok. understood

10:11 <re_irc> <Sean Lyons> : Good advice. I will start with the format of the "nrf-pac" repo and support a single chip and go from there.

10:12 <re_irc> <Sean Lyons> : Thanks, I will build some minimal FW to exercise the pac and compare with datasheet.

10:12 <re_irc> < (@explodingwaffle101:matrix.org)> https://github.com/rp-rs/rp-hal/blob/bac6714f09f887cbfc168590291c03f580bc107a/rp2040-hal/src/atomic_register_access.rs rp2040 has something similar and have this in the hal

10:13 <re_irc> <FredrikLL> I have tried to manipulate the svd file the naïve way, just adding everything verbosely which made the svd file huge and compiling the pac took forever.

10:14 <re_irc> < (@burrbull:matrix.org)> FredrikLL: you could try to write small script using svd-parser + svd-encoder for this

10:19 <re_irc> <duskmoon (Campbell He)⚡️> Maybe writing some scripts to generate the missing part. As svd is actually xml, any tool is ok (e.g. python)

10:19 <re_irc> <FredrikLL> : I was considering doing something like this in the pac. But doing this in the Hal seems like a better solution. However it would be really nice if the pac would follow the reference manual. I guess it comes down to a choice between correctness and compilation time.

10:22 <re_irc> <FredrikLL> duskmoon (Campbell He)⚡️: I have tried doing this, the svd file got huge and compilation of the pac took ~15x longer

10:22 <re_irc> < (@9names:matrix.org)> in rp2040-hal we considered adding them to the SVD or the PAC but there were unresolved questions around how to ensure exclusive ownership of a register as svd2rust expects. using the free-functions on existing registers is not ergonomic but it resolved that particular issue.

10:22 <re_irc> <duskmoon (Campbell He)⚡️> Oh, that seems really huge

10:24 <re_irc> < (@explodingwaffle101:matrix.org)> embassy-rp (with the chiptool pac) does this https://github.com/embassy-rs/embassy/blob/83c2f8f4169877961971438100e915aa68e9f331/embassy-rp/src/lib.rs#L138

10:34 <re_irc> <FredrikLL> : This is great, thanks!

10:37 <re_irc> < (@burrbull:matrix.org)> FredrikLL: oh. I'm stupid. Similar thing should work in svd2rust 0.28 with atomic feature

10:38 <re_irc> < (@burrbull:matrix.org)> * option

10:39 <re_irc> < (@burrbull:matrix.org)> although not. It is different from what you want

10:40 <re_irc> < (@burrbull:matrix.org)> it uses atomic operation on same register

10:40 <re_irc> < (@burrbull:matrix.org)> when you want to use specialized registers

10:45 <re_irc> < (@burrbull:matrix.org)> The only good solution I see is to add other trait to svd2rust (similar to atomic one) which will add methods you need

10:47 <re_irc> < (@burrbull:matrix.org)> or just change Atomic trait implementation

10:49 <re_irc> <FredrikLL> Seems like that could be a good solution, since there seems to multiple vendors having this feature. I don’t have the know how to do it unfortunately.

10:49 <re_irc> < (@burrbull:matrix.org)> FredrikLL: Is there no exceptions?

10:52 <re_irc> <FredrikLL> There are very few exceptions.

10:54 <re_irc> < (@burrbull:matrix.org)> cc Could do you have thoughts?

10:56 <re_irc> <FredrikLL> The only exception is devinfo

12:09 <re_irc> < (@chrysn:matrix.org)> I'm in a project where I primarily use "defmt", but now I'm in a debug situation where the crate whose behavior I'd like to debug already has decent opt-in abilities through the "log" crate.

12:10 <re_irc> < (@chrysn:matrix.org)> As I can afford the overhead of going through Debug etc during debugging: Is there some feature / crate around defmt which I can opt in to that'd be a backend to the classical "log", and allows me to get messages out through the defmt channel which I already get for free?

12:10 <re_irc> < (@chrysn:matrix.org)> (Should be a rather straightforward thing, probably -- like, have a 80-byte buffer, make log write into that, and emit the buffer's content as a plain &str through defmt at the right level).

12:25 <re_irc> < (@jannic:matrix.org)> Looks like knurling anticipated such a feature, but didn't implement it yet: https://crates.io/crates/defmt-logger

12:31 <re_irc> < (@chrysn:matrix.org)> Hm, looks functional, except that it depends on log/std

12:31 <re_irc> < (@chrysn:matrix.org)> I might manage to patch that out, though.

13:05 <re_irc> < (@jannic:matrix.org)> Oh - I didn't even notice it actually contains code 🤣 I thought it was an empty placeholder to reserve the name.

13:06 <re_irc> < (@chrysn:matrix.org)> Seems quite outdated though -- like, it might have been created when defmt was started, and then functionality moved and it became the log recipient side of things. Looks like it's more easily re-implemented, looking at that right now.

14:02 <re_irc> < (@chrysn:matrix.org)> OK, it's _really_ trivial to do if you don't care about anything -- still, would be nice to have a crate that does it right.

14:03 <re_irc> true

14:03 <re_irc> < (@chrysn:matrix.org)> struct DefmtLogger;

14:03 <re_irc> fn enabled(&self, _: &log::Metadata) -> bool {

14:03 <re_irc> impl log::Log for DefmtLogger {

14:03 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/haPh6PlsTDlPDKy1bUc4U84Cb4ay4tUf (20 lines)