00:01 <adamgreig[m]> Mebus: there's an example here you can copy: https://github.com/stm32-rs/stm32h7xx-hal/blob/master/memory.x

00:02 <adamgreig[m]> but all you need is:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FBsQNyUdfrlnFOeOBcnasPTm>)

00:03 <M9names[m]> <thejpster[m]1> "Has anyone shipped a RISC-V..." <- Boufallo lab Bl602/bl702 are sifive e2 cores, they have CLIC

00:03 <adamgreig[m]> the stm32h7 is quite a complicated chip, so it has a lot of different RAMs you can use for different things, but if you're just starting out that should work fine

00:06 <Mebus[m]> ah, yeah thanks. This happens to be exactly the same file I am already using.

00:06 <M9names[m]> M9names[m]: The microcontroller cores in bl616/bl808 are t-head e907, which also implement CLIC

00:06 <Mebus[m]> I am using this example:

00:06 <Mebus[m]> https://github.com/astraw/nucleo-h743zi

00:06 <Mebus[m]> in the beginning the LEDs were blinking on the board according to the blinky program, but now they don't - but i didn't change anything.

00:06 <Mebus[m]> any ideas?

00:09 <adamgreig[m]> when did they stop? does it help to power-cycle the board?

00:09 <adamgreig[m]> does it still program OK?

00:09 <Mebus[m]> they actually stopped after I unplugged the board

00:10 <Mebus[m]> that's what I get. so it seems that it starts, but no led blinking

00:11 <adamgreig[m]> any difference if you cargo run --bin blinky --release?

00:12 <adamgreig[m]> (added --release)

00:12 <adamgreig[m]> oh, it seems like you're running a program for an stm32h743, but your board is an stm32h745?

00:12 <Mebus[m]> yes, I don't know where to change that.

00:13 <Mebus[m]> no, --release does not help

00:13 <Mebus[m]> it's a STM32H745ZIT6

00:14 <adamgreig[m]> are you sure the first time they blinked it wasn't just whatever code was on there before?

00:15 <Mebus[m]> I changed the type of blinking, so it should have worked

00:15 <Mebus[m]> how can I set probe-run to the correct chip?

00:16 <adamgreig[m]> there's a couple of changes you should make - https://github.com/astraw/nucleo-h743zi/blob/main/Cargo.toml#L17 and https://github.com/astraw/nucleo-h743zi/blob/main/.cargo/config#L4

00:16 <adamgreig[m]> for a -Q nucleo board you also need to set up the power supply correctly, it uses the SMPS controller built-in to the stm32

00:17 <adamgreig[m]> on this line: https://github.com/astraw/nucleo-h743zi/blob/main/src/bin/blinky.rs#L30

00:17 <adamgreig[m]> try  let pwrcfg = pwr.smps().freeze();

00:19 <adamgreig[m]> I think in Cargo.toml you want the stm32h7xx-hal feature set to stm32h747cm7

00:21 <adamgreig[m]> whereas in config.toml you want --chip STM32H745ZITx

00:21 <adamgreig[m]> I think those three changes hopefully will be enough, so give them a try first, but it looks like https://github.com/antoinevg/nucleo-h7xx directly supports your nucleo board so might also be worth a look

00:24 <Mebus[m]> I geht this error: https://hastebin.com/share/lohofutebu.bash something seems to be wrong with the power settings

00:24 <adamgreig[m]> have you tried power cycling it since programming that?

00:24 <Mebus[m]> no, one second

00:24 <adamgreig[m]> ie remove all the cables so it totally turns off, then plug in again

00:24 <Mebus[m]> Hey, the LED blinks 😃😃😃

00:25 <adamgreig[m]> nice!

00:25 <Mebus[m]> Thanks a lot!

00:25 <adamgreig[m]> this is a weird "feature" of some of the stm32h7 chips, the power config is write-once until you remove power, even through a reset/reprogram

00:25 <adamgreig[m]> and if you write it wrong, it fails to boot

00:25 <adamgreig[m]> and it has to be set to the right thing for your particular PCB...

00:25 <Mebus[m]> are these *.svd files in the projects directory used in any way?

00:25 <Mebus[m]> or are they just there to be there?

00:26 <adamgreig[m]> however it is a really nice feature of the chip when you're designing your own PCBs, just quite annoying to get started on a nucleo board

00:26 <adamgreig[m]> not sure what they're doing there. look pretty old

00:26 <adamgreig[m]> I think it's probably to help with debugging - some debuggers can load them up

00:26 <adamgreig[m]> https://stm32-rs.github.io/stm32-rs/stm32h757_cm7.svd.patched might be more up-to-date for your chip

00:28 <Mebus[m]> Error 404 🤔

00:35 <adamgreig[m]> hm, should be https://stm32-rs.github.io/stm32-rs/stm32h747cm7.svd.patched

00:39 <Mebus[m]> I pushed my changes to here: https://github.com/Mebus/nucleo-h743zi/tree/stm32h747cm7 - maybe it helps somebody. I might clean it up a little later.

04:00 <RansfordHyman[m]> I've noticed while looking up companies that are leveraging Rust in the embedded space are all in Europe. Is there any reason that is the case? Is there any list maintained where it is noted of companies that are leveraging Rust in the embedded space. I'm not in this space but I find it's usage with Rust interesting

04:07 <M9names[m]1> maybe the companies using embedded rust in europe are more likely to publicize that fact?

04:45 <RansfordHyman[m]> <M9names[m]1> "maybe the companies using..." <- Perhaps 🙂

08:48 <Radu[m]> Hi, I want to do a mechanism like automatic door opening for college, also, I'd like to send an event to a server every time a door was opened(someone got close to that sensor) and also to be on batteries. Is it possible? Can you give me some steps to follow for this project?

08:49 <Radu[m]> Sorry because it's not exclusively rust related, I want to write the code in rust

08:49 <Mebus[m]> Probably with a ESP32 for example.

08:57 <K900[m]> I'm really curious as to why you need batteries if the door opening mechanism is right there and presumably powered somehow

09:00 <Radu[m]> K900: over engineering to make the teacher happy, also, I'm couriouse how that can be done

09:01 <K900> Exactly the same way as you would with a power supply, really

09:01 <K900> Except the power supply is a battery

09:02 <K900> Most pre-built developer boards take 5V or 3.3V both of which are easily available from, well, batteries

09:02 <K900> Also pro tip: phone power banks are surprisingly useful for prototyping in the field

09:11 <Radu[m]> thanks a lot

11:59 <Orange_Murker[m]> <K900> "Also pro tip: phone power..." <- Yep. But some of them turn off while you are using them when the current draw is not high enough.

13:13 <Mebus[m]> Hi, when I build this: https://github.com/antoinevg/nucleo-h7xx... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DUpVbTAraDMtsFcDHMpYRWZs>)

13:21 <M9names[m]> Looks sus to me.

13:21 <M9names[m]> Maybe you should write up an issue on GitHub to let the author know?

13:22 <Mebus[m]> What do you mean by "sus" ?

13:25 <M9names[m]> Sorry. Suspicious. The code and the error make me suspect there is a bug here

13:36 <Mebus[m]> Why is it using stm32h7xx-hal-0.9.0/src/ethernet/eth.rs -> there should be a new version available. can I change this somehow?

13:42 <M9names[m]> You can check who is depending on the old version using `cargo tree`.

13:42 <M9names[m]> If there's a Cargo.lock it can sometimes keep you on an old version.

16:29 <dirbaio[m]1> what's the best practice for SPI chips that require a delay after asserting CS?

16:29 <dirbaio[m]1> - Driver adds a Delay operation in the transaction for each transaction (now that SpiDevice can do delays)

16:29 <dirbaio[m]1> - Treat it as "configuration" of the SpiDevice, similar to frequency: the driver doesn't insert Delay operations, instead the user is responsible for providing a properly-configured SpiDevice that will do these for all transactions

16:29 <dirbaio[m]1> * what's the best practice for SPI chips that require a delay after asserting CS?

16:29 <dirbaio[m]1> - Driver adds a Delay operation in the transaction for each transaction (now that SpiDevice can do delays)

16:29 <dirbaio[m]1> - Treat it as "configuration" of the SpiDevice, similar to frequency: the driver doesn't insert Delay operations, instead the user is responsible for providing a properly-configured SpiDevice that will do the delay for all transactions

16:31 <diondokter[m]> With the new traits I would go with the second option

16:33 <dirbaio[m]1> it'd be something like delay_before, delay_after fields in embedded-hal-bus SpiDevice impls?

16:33 <dirbaio[m]1> I dunno

16:33 <dirbaio[m]1> it feels cleaner that the driver doesn't have to insert the delay operations itself every time

16:33 <dirbaio[m]1> but on the other hand it feels redundant to have two ways of requesting delays

16:35 <diondokter[m]> How often does it happen where you have to care? Most chips are fine without delay. So I don't think the default SpiDevice implementation should implement something like it. Would be more generics again.

16:35 <diondokter[m]> Also, some hardware SPIs can do it for you iirc

16:41 <dirbaio[m]1> > Would be more generics again.

16:41 <dirbaio[m]1> not really, we already are generic on a Delay 🤪

16:41 <dirbaio[m]1> > Most chips are fine without delay

16:41 <dirbaio[m]1> the enc28j60 needs it 😭

16:42 <diondokter[m]> > <@dirbaio:matrix.org> > Would be more generics again.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/iGefHpTqHlwaRwYnzYUYAPek>)

16:42 <dirbaio[m]1> required to support in-transaction delays

16:43 <diondokter[m]> Yeah, then some sort of config. There are three kinds of delays I guess.

16:43 <diondokter[m]> After CS assert, before CS deassert and between deassert and assert

16:44 <dirbaio[m]1> yeah

16:44 <dirbaio[m]1> grrr

16:45 <dirbaio[m]1> the "between deassert and assert" one is especially annoying to do with just Delay, no way to do it other than wasting the delay before each assert just in case

16:45 <diondokter[m]> Yep, only option when you don't have access to the time

16:47 <dirbaio[m]1> perhaps the question is: how common is it, does it warrant including in embedded-hal-bus or not

16:47 <dirbaio[m]1> * perhaps the question is: how common is it, does it warrant including in embedded-hal-bus or not?

16:48 <diondokter[m]> If it can't be made zero-cost, then we should probably not include it in the default SpiDevice

17:39 <adamgreig[m]> i think pretty much all spi devices require some delay asser-to-first-clock and last-clock-to-deassert but it's usually measured in a few ns, so you just ignore it because you get the delay for free from the cpu having to do things in sequence

17:44 <diondokter[m]> There's something to be said for letting drivers set all this up. Both delays and the frequency. In principle the driver should know best. And if we're looking to the future, a 1-2 GHz microcontroller could in theory assert the CS pin and start the SPI transaction in less than a nanosecond.

17:46 <diondokter[m]> Is there hardware out there that can't change the SPI frequency between transactions?

19:30 <likewise[m]> It is quite common for chips to have a delay after CS or CS#. The I/O elements of a SoC cannot keep up with the driving frequency inside the core, which is why it mostly works without delays.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YaNMtsUGYFOElhodlABnujQD>)

19:31 <likewise[m]> * It is quite common for chips to have a delay after CS or CS#. The operating frequency of the I/O elements of a SoC cannot keep up with the core frequency, which is why it mostly works without delays.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/fiSIHyZACpTdafOGwwHAFJuT>)

19:59 <lynaghk[m]> Can anyone recommend a serialization library or approach that I can use to generate a web UI for reading/writing structs with an embedded device (over, e.g., web serial)? I'm imagining something that would emit (at compile-time) an annotated schema of a struct definition which could then be rendered by some JavaScript into HTML inputs, combo boxes, checkboxes, etc.

20:00 <lynaghk[m]> I could almost certainly do this with a bunch of proc macros and build.rs hijinks, but I'd love to avoid reinventing the wheel if there is prior art here. Something like https://docs.rs/schemars/latest/schemars/ for JSON Schemas is the closest thing I'm aware of.

21:24 <dngrsspookyvisio> <lynaghk[m]> "Can anyone recommend a serializa..." <- I have written such a thing! https://github.com/spookyvision/embedded-web-ui

21:24 <dngrsspookyvisio> it's not well documented at the moment. hmu if you want help/collab :)

21:25 <dngrsspookyvisio> you can also make it work with WebSerial, I was just annoyed at the mandatory chrome so I built a server to translate serial to WebSockets (it's in the repo)

21:25 <dngrsspookyvisio> * you can also make it work with WebSerial, I was just annoyed at the mandatory use of Chrome so I built a server to translate serial to WebSockets (it's in the repo)

21:27 <lynaghk[m]> Ah, very neat! I'm just looking at the first example I could find (https://github.com/spookyvision/embedded-web-ui/blob/ce37fb02bc14d21b705bb94388bedcb9b49387aa/stm32f4-app/src/main.rs#L122) and it seems like the idea is to define UI elements in the firmware and then listen for changes that come in based on component ID.

21:29 <lynaghk[m]> I was thinking something closer to a single annotation on a type and default mappings of type -> UI control, with any changes on the frontend yielding an entire new type value. (Or maybe waiting for a "send" on the frontend). Still, definitely relevant and related work, thanks!

21:29 <dngrsspookyvisio> yeah, that's basically it. you can also send data back, e.g. this demonstrates an FFT done on-device and rendered in the browser: https://www.youtube.com/watch?v=OVQCu2fmVps

21:29 <dngrsspookyvisio> (second half of the video has audible audio)

21:30 <dngrsspookyvisio> at the moment the chart is made with d3, but I'm planning to move to plotters-rs

21:31 <dngrsspookyvisio> dngrsspookyvisio: the code for this is not in the repo but I can post it (it's just not very polished)