00:19 <ian_rees[m]> is there a crate somewhere that implements DelayNs using NOPs?

00:21 <ian_rees[m]> I'm looking for a struct that can be cloned, for use on Cortex-M0+ and M4, so something that works based on SYSTICK could be another option

04:49 <GuineaWheek[m]> there's https://docs.rs/cortex-m/latest/cortex_m/asm/fn.delay.html which doesn't do DelayNs

09:49 <ryan-summers[m]> By the way, for anyone interested, we just released a nice crate for managing device settings via a simple CLI interface - can be used for permanently stored settings (i.e. those saved with something like sequential-storage) and run-time settings. Take a look if you're interested! https://crates.io/crates/serial-settings

10:38 <ryan-summers[m]> Does anyone know of GPIO debouncer crates for e-h 1.0?

10:51 <thejpster[m]1> I use https://docs.rs/debouncr, but it's much more manual and doesn't emulate a de-bounced pin

10:55 <ryan-summers[m]> That honestly looks sufficient, thanks for the link. Didn't realize it didn't rely on the e-h, so I had skipped it in my crates-io search because the last update was so long ago

11:45 <sourcebox[m]> So the new friend has just arrived:

11:45 <sourcebox[m]> But not that much time for it now.

11:46 <sourcebox[m]> Also have to check which debug tools/probes already work with it.

11:46 <diondokter[m]> Just know, there's a hardware bug that has been found wrt the pull downs: https://hackaday.com/2024/08/28/hardware-bug-in-raspberry-pis-rp2350-causes-faulty-pull-down-behavior/

11:51 <sourcebox[m]> <ryan-summers[m]> "Does anyone know of GPIO..." <- I've written a crate some time ago, but it doesn't interface with e-h at all. It requires some time information in the form of ticks, but since it does not do any averaging, there's no initial delay. See here: https://crates.io/crates/timed-debouncer

12:46 <thejpster[m]1> E9 has been known for some time, but it looks like they now have more detail - the issue is that the pull-up is being enabled when it wasn't asked for, and so with pull up and pull down enabled you get stuck in the middle

12:47 <K900> We have finally found it

12:47 <K900> The legendary pull both directions resistor

12:48 <thejpster[m]1> The text in the datasheet doesn't match the screenshot on the hackaday article

12:48 <JamesMunns[m]> The first GPIO with resistor-based suspension to balance bounces in both directions

12:48 <thejpster[m]1> the 2024-08-21 datasheet (they are continuing to refuse to update the changelog when they push out updates, which is pissing me off) just says:

12:48 <thejpster[m]1> > This is caused by a fault in the analogue circuitry of the pad itself.

12:52 <dirbaio[m]> "Do you want pull up or pull down?"

12:52 <dirbaio[m]> "Yes."

12:53 <sourcebox[m]> thejpster: I read your launch blog post. I guess you used picotool for flashing. Or did you setup OpenOCD and some debug probe? I have a picoprobe, not sure if that is already supported.

12:54 <sourcebox[m]> * for flashing only. Or

12:58 <thejpster[m]1> I used both picotool and openocd. Either works.

12:58 <ruabmbua[m]> Wonder how I can abuse it as a feature 😅

12:58 <thejpster[m]1> OK, so I have this backwards. The screenshot is from the BusPirate masto thread, and it's taken from an NDA datasheet. The text was later revised to

12:58 <thejpster[m]1> > This is caused by a fault in the analogue circuitry of the pad itself.

12:59 <thejpster[m]1> (yes, I do have every copy of the datasheet I've ever seen. Why do you ask?)

13:00 <sourcebox[m]> ruabmbua[m]: Idea: since the pullup and pulldown values are slightly different, the resulting voltage may be used as bad seed for an RNG.

13:03 <ryan-summers[m]> Actually it's pretty common to do ADC reads on floating input pins to seed RNG engines. Just take the LSB from a number of measurements and you're good to go

13:04 <ryan-summers[m]> *This is not cryptographically-approved advice

13:04 <ruabmbua[m]> Yeah the problem is that this makes it trivial to influence rng

13:04 <ruabmbua[m]> Which is a problem with some threat models

13:11 <thejpster[m]1> yeah but also it has a hardware RNG and the ROM can give you a per-boot random number designed for seeding your PRNG

13:15 <sourcebox[m]> Of course it has. My proposal was not meant that serious.

15:18 <mkj[m]> spruik timing pullups makes a nice random source https://github.com/mkj/caprand

17:21 <bogdan[m]> Hello all! Does anyone know of any `HAL`s implemented with a `chiptool`-generated PAC? I've been working on writing a HAL based on an `svd2rust` generated PAC, but I'm curious about a chiptool-based PAC. Is chiptool still developed/maintained? https://github.com/embassy-rs/chiptool

17:22 <bogdan[m]> * Hello all! Does anyone know of any `HAL`s implemented with a `chiptool`-generated `PAC`? I've been working on writing a `HAL` based on an `svd2rust` generated `PAC`, but I'm curious about a chiptool-based `PAC`. Is chiptool still developed/maintained? https://github.com/embassy-rs/chiptool

17:52 <dirbaio[m]> embassy-stm32, embassy-rp use chiptool-based pacs

17:52 <dirbaio[m]> > Is chiptool still developed/maintained?

17:52 <dirbaio[m]> yes, of course :|

18:01 <bogdan[m]> no offence intended :)

18:03 <bogdan[m]> The only reason I'm asking is because I found the description of the differences between svd2rust and chiptool quite interesting

18:10 <bogdan[m]> I'll take a look at https://github.com/embassy-rs/embassy/tree/main/embassy-stm32 , thanks for the recommendation!

19:14 <andar1an[m]1> sorry if this is a silly question, but my hope has been to run an RTOS on CM4 or similar form factor riskv - does anything in Rust world currently support cortex-A for something like a CM4 - or a RiscV alternative like Mars CM? I have looked at Tock, Hubris, Embassy. I can probably get away with zephyr, but wanted to verify first. I should be getting hardware in a few months as long as lead times don't get extended again.

19:14 <K900> This is way out of typical RTOS territory

19:14 <K900> You probably just want Linux

19:15 <K900> But I know you will not like this answer and I will not argue further

19:15 <i509vcb[m]> The hardware is probably a bit overkill for an rtos

19:15 <andar1an[m]1> I am looking at alpine also. But it is not for the hardware strength that I am trying to experiment with RTOS on these devices

19:16 <i509vcb[m]> If you happen to need a real time system connected to the cm4, slap an MCU on your carrier board and write a driver to talk between the two

19:17 <K900> Or use Linux configured with PREEMPT_RT and extreme care

19:18 <andar1an[m]1> I want the CM4 to be the real time system lol

19:18 <K900> Then you want Linux

19:19 <K900> Or you can spend the next however many years porting drivers from Linux to your RTOS of choice, I guess

19:21 <andar1an[m]1> I dk, zephyr supports these boards. I am clearly ignorant about the driver aspect still. I will look into more

19:21 <K900> Zephyr "supports" those boards

19:22 <K900> Where "supports" means GPIO and one serial port

19:22 <K900> https://docs.zephyrproject.org/latest/boards/raspberrypi/rpi_4b/doc/index.html

19:22 <i509vcb[m]> The interesting stuff like the GPU will need a full MMU

19:22 <K900> And it's still running on top of vendor firmware which may or may not give you any timing guarantees

19:22 <K900> (it probably doesn't)

19:23 <andar1an[m]1> and uart lol

19:23 <i509vcb[m]> You might have a better luck if you have a load of money and see if QNX works on the cm4, but it's not supported by Raspberry Pi Trading so results will vary

19:23 <K900> UART is the one serial port, yes

19:23 <i509vcb[m]> But QNX opens a whole new Pandora's box

19:23 <K900> i509vcb[m]: Neither is Zephyr

19:24 <K900> The only software actually supported by the vendor on those things is Raspbian

19:24 <K900> Everything else is best-effort at best

19:24 <i509vcb[m]> So before we go into semantics, what real time system are you implementing on the theoretical RTOS you want

19:24 <K900> And generally their best effort is not very good

19:25 <andar1an[m]1> I wanted to play with the concept of treating a microservice as a microcontroller

19:25 <i509vcb[m]> (Let's avoid an XY problem pretty much)

19:26 <K900> You are saying words that don't mean things

19:26 <K900> (again)

19:26 <andar1an[m]1> Me?

19:26 <K900> What is a "microservice", and what does it mean to treat one "as a microcontroller"?

19:26 <andar1an[m]1> It means exactly what it sounds like lol

19:27 <K900> It sounds like buzzwords strung together with no context behind them, if I may be so frank

19:27 <andar1an[m]1> flashing firmware that represents a microservice onto a small piece of hardware

19:27 <K900> What is "a microservice"

19:27 <K900> An HTTP API server?

19:27 <andar1an[m]1> yes

19:27 <i509vcb[m]> What service is being provided

19:27 <K900> And what is a "small piece of hardware"

19:28 <K900> And what do you expect to gain from doing this

19:29 <andar1an[m]1> by minimizing the machine sizes I want to have a tighter control on resource consumption by making more discrete slices along a load curve for consumption

19:29 <andar1an[m]1> so instead of trying to fill up a bunch of big machines

19:29 <andar1an[m]1> I want to bring up a bunch of little machines when they are needed

19:30 <andar1an[m]1> most of the "api servers" or microservices I require are not complex

19:30 <andar1an[m]1> they do 1 thing, and can be very small

19:30 <K900> Then you can probably run all of them on one CM4

19:30 <K900> Or a bunch of Pi Picos or something, I guess

19:30 <K900> That would actually be "small"

19:30 <andar1an[m]1> I am going with cm4's right now because I ordered 10 raspberry pi blades to experiment with this and ipv6 and netboor

19:30 <K900> And you can run an RTOS on those

19:31 <andar1an[m]1> small relative to standard servers in a data center

19:31 <andar1an[m]1> you can get as discreet as you want, but this is for experimentation and learning

19:31 <K900> Well, if you want to run "bare metal" on those, that's basically never actually happening unless you reverse engineer the entire vendor firmware which is something people have tried and did not have much success with

19:32 <K900> Also, you'd have to implement an entire Ethernet and/or Wi-Fi stack to get any networking out of them

19:32 <andar1an[m]1> I ordered a bunch of these: https://computeblade.com/, so this is what I have to work with

19:32 <K900> Though at least with Ethernet you can probably layer something existing on top

19:32 <andar1an[m]1> It is all ethernet

19:33 <K900> Well you'd still have to write your own Ethernet driver and then figure out how to connect it to an existing network stack

19:34 <K900> And then you'll have a whole lot of other exciting things to reinvent, like remote management or monitoring or logging or other things people generally expect from servers

19:34 <andar1an[m]1> Yes, and how to flash frimware in a pxe like manner

19:34 <andar1an[m]1> Why? this is a microcontroller, just have it send api logs or go down

19:35 <K900> It is very much not a micro anything

19:35 <andar1an[m]1> The whole point is to try to cut out a lot of the stack and see what happens

19:35 <K900> And you'll probably want to know what is going on when the network goes down

19:37 <andar1an[m]1> Not understanding that

19:37 <andar1an[m]1> how would I find out what was wrong with it if the network was down?

19:38 <andar1an[m]1> Like go plug into it?

19:38 <K900> Real servers usually have management hardware for this

19:38 <K900> That's on a separate network

19:38 <K900> And is able to monitor and control the system

19:38 <andar1an[m]1> Yes, but if the network goes down it can't communicate

19:39 <K900> Which is why the BMCs are usually put onto a separate network

19:39 <andar1an[m]1> If my network goes down, I would be investigating my routers and switches first

19:39 <andar1an[m]1> anyways this is off topic now

20:27 <DavidHowells[m]> Is anyone using svdtools and knows what I need to put in the yaml patch file to get it to expand all arrays? I'm stuck, and any help would be much appreciated.