09:27 <re_irc> <@louis.renuart.qteal:matrix.org> Hello, I am trying to use "no_std" "prost" on "rp2040" however currently the "thumbv6m-none-eabi" has problems with "bytes"'s use of built-in atomics

09:27 <re_irc> Anyone has an idea to solve this ? Preferably without needing to rewrite the entire thing myself, thanks.

09:28 <re_irc> <@louis.renuart.qteal:matrix.org> Hello, I am trying to use "no_std" "prost" on "rp2040" however, currently the "thumbv6m-none-eabi"

09:28 <re_irc> has problems with "bytes"'s use of built-in atomics

09:28 <re_irc> Does anyone have an idea to solve this? Preferably without needing to rewrite the entire thing myself, thanks.

09:51 <re_irc> <@ryan-summers:matrix.org> Louis Renuart: https://crates.io/crates/atomic-polyfill/0.1.1 was designed for this use case

09:51 <re_irc> <@ryan-summers:matrix.org> Err, https://crates.io/crates/atomic-polyfill

09:52 <re_irc> <@ryan-summers:matrix.org> I think this means you'd have to modify "bytes" to use the polyfill instead? Not sure

09:58 <re_irc> <@sourcebox:matrix.org> There was a bit of discussion about it some time ago, but I'm still trying to find out if there's some support for Cortex-A7. I'm thinking about basic stuff like setting up the MMU etc.

10:24 <re_irc> <@thejpster:matrix.org> https://github.com/rust-lang/rust/pull/104525 :eyes: Mara's making core::fmt better.

10:37 <re_irc> <@sourcebox:matrix.org> : I'm wondering if that will affect the panic handler and therefore even reduce binary size if you don't use any formatting inside the application code.

13:08 <re_irc> <@jamwaffles:matrix.org> Hey all, if I want to make a battery powered device that talks to a base station over IR (a touch probe for a CNC machine), which Rust-supported MCU would you go for? Bonus points for as much peripheral support for IR and as little coding as possible.

13:08 <re_irc> <@diondokter:matrix.org> IR = infrared?

13:12 <re_irc> <@diondokter:matrix.org> If it's using the IrDA SIR protocol, then STM32 has support for it through the uart peripheral

13:17 <re_irc> <@thejpster:matrix.org> The RP2040's PIO engine can probably also be used to do infra-red protocols. Here's the C example for pretending to be a TV remote control or similar: https://github.com/raspberrypi/pico-examples/tree/master/pio/ir_nec

13:20 <re_irc> <@diondokter:matrix.org> This one looks nice (or another one in the series): https://www.st.com/en/microcontrollers-microprocessors/stm32l053c8.html

13:20 <re_irc> Down to 270nA with two wakeup pins active (so you can wake up from the incoming signal)

13:20 <re_irc> <@diondokter:matrix.org> Is the RP2040 good in low power?

13:20 <re_irc> <@jamwaffles:matrix.org> Yes, IR = infrared :). No specific protocol in mind but if I can reuse something else I'm all for it. Going for simple over awesome in this project 🙂

13:21 <re_irc> <@9names:perthchat.org> : Not really.

13:21 <re_irc> <@ryan-summers:matrix.org> battery powered + rust + IR seems + low code seems like an oxymoron. Does it have to be battery powered and can't be cabled? This seems like you could probably do some system analysis and eliminate the microcontroller + firmware entirely, but I obviously don't know your setup

13:22 <re_irc> <@ryan-summers:matrix.org> They're very competing requirements ;)

13:22 <re_irc> <@lavanya10010010:matrix.org> Hi,

13:22 <re_irc> I'm currently working with ATSAM4L board, writing a flash driver. I've written a basic erase command (by referring to the board's datasheet). I'm using probe-rs-cli to read and I think my erase function is not working. Any help in fixing it or point out what I'm missing? Any help at all is greatly appreciated! I've attached the code snippet below...

13:22 <re_irc> self.nvm.fcmd.write(|s|

13:22 <re_irc> self.nvm.fcmd.write(|s|

13:22 <re_irc> unsafe { s.key().bits(0xA5) });

13:22 <re_irc> unsafe { s.pagen().bits(starting_page.try_into().unwrap()) });

13:22 <re_irc> self.nvm.fcmd.write(|s|

13:22 <re_irc> unsafe { s.cmd().bits(0x02) });

13:22 <re_irc> loop{

13:22 <re_irc> let fsr_status = self.nvm.fsr.read().frdy().bit();

13:22 <re_irc> if fsr_status == true {

13:22 <re_irc> defmt::println!("Erase successful");

13:22 <re_irc> break;

13:22 <re_irc> }

13:22 <re_irc> }

13:24 <re_irc> <@marmrt:matrix.org> You need to so the writes as a single wirte, is my guess

13:24 <re_irc> <@jamwaffles:matrix.org> : My current probe is cabled, but it's annoying when orienting the spindle and it's a single command away from spaghettifying both the probe and my face lol. The industrial probes are wireless too so it does seem to work. It just has to be able to wake from deep sleep whenever it's in use, then go back to sleep when stored

13:24 <re_irc> <@marmrt:matrix.org> * write,

13:25 <re_irc> <@ryan-summers:matrix.org> I'm not saying it's impossible. Mainly saying that I would imagine those industrial probes have a decent amount of logic to make them work right

13:25 <re_irc> <@ryan-summers:matrix.org> I often find projects blow up bigger than I anticipate them to :)

13:25 <re_irc> <@ryan-summers:matrix.org> Sounds like a cool one though

13:26 <re_irc> <@jamwaffles:matrix.org> Good point haha. I'm hoping to get to "good enough". Maybe that involves a manual on-off switch so I don't have to worry about power too much or something. I was mainly looking for a starting point, and STM32 + IrDA periph sounds ok enough to be that

13:39 <re_irc> <@diondokter:matrix.org> Lavanya R: It's been a really long time since I worked with the 4L and I've never touched the flash.

13:39 <re_irc> But that key seems a bit short. Shouldn't that be a full u32 key?

13:40 <re_irc> <@marmrt:matrix.org> : They're making three writes to the same register, while only touching the tamper key once. The second and third write gets ignored

13:41 <re_irc> <@diondokter:matrix.org> : Ah good catch! Yeah, that write should probably done in one go

13:41 <re_irc> <@diondokter:matrix.org> +be

13:43 <re_irc> <@diondokter:matrix.org> So that would be

13:43 <re_irc> s.key().bits(0xA5)

13:43 <re_irc> .cmd().bits(0x02)

13:43 <re_irc> .pagen().bits(starting_page.try_into().unwrap())

13:43 <re_irc> self.nvm.fcmd.write(|s| unsafe {

13:43 <re_irc> });

13:44 <re_irc> <@lavanya10010010:matrix.org> : Thank you, will try this!

13:49 <re_irc> <@diondokter:matrix.org> Seems like you can simplify this as well:

13:49 <re_irc> self.nvm.fcmd.write(|s|

13:49 <re_irc> s.key()..key()

13:49 <re_irc> );

13:49 <re_irc> .pagen().variant(starting_page as u16)

13:49 <re_irc> .cmd().ep()

13:49 <re_irc> Though the "pagen" might not work that way. Not sure

13:49 <re_irc> <@diondokter:matrix.org> * s.key().key()

15:46 <re_irc> <@TimSmall:matrix.org> : I've done IrDA SIR reception in Rust on stm32f4 (HAL now has support), as has also been noted the rp2040's hardware UART peripheral also has support. I used a sharp irda receiver IC. Transmit is straightforward electronically speaking I believe, just find an IR led of the correct wavelength.

15:47 <re_irc> <@jamwaffles:matrix.org> Awesome! I think I'm going to go with STM32L0 so good to know it works on other STMs. What receive HW is needed?

15:48 <re_irc> <@TimSmall:matrix.org> Oh, actually re-reading it wasn't noted that the rp2040 had support, but I believe the UART peripheral (which is the same ARM design as the one used on the Raspberry Pi 1/2/3) is of just the right vintage that IrDA was a must-have feature.

15:49 <re_irc> <@thejpster:matrix.org> rustfmt is happier if you write:

15:49 <re_irc> self.nvm.fcmd.write(|s|

15:49 <re_irc> s.pagen().variant(starting_page as u16);

15:49 <re_irc> s.key().key();

15:49 <re_irc> s.cmd().ep();

15:49 <re_irc> s

15:49 <re_irc> );

15:56 <re_irc> <@TimSmall:matrix.org> : There are IrDA compliant receivers, but many parts are now obsolete (not a problem if for a 1-off tho of course). I think you can do a very simple receiver with an analogue comparator, a photo-transistor and a capacitor (but a purpose-made one is probably better). I used a Sharp IS1U20.

15:56 <re_irc> <@jamwaffles:matrix.org> Good to know, thanks! I was gonna just throw a photodiode on a GPIO but I guess it needs a cleaner input signal than that

15:58 <re_irc> <@therealprof:matrix.org> : That brings back memories!

16:08 <re_irc> <@TimSmall:matrix.org> : IIRC from my testing on the STM32F4, you couldn't just receive arbitrary data over the UART there was a minimum number of sync bytes that had to be received first or something (in line with the published IrDA protocol I think)? That didn't seem to be documented in the programming manual tho'.

17:11 <re_irc> <@thejpster:matrix.org> https://libera.chat/news/matrix-deportalling - does this affect us? I can't remember how the IRC bridge stuff works.

17:21 <re_irc> <@TimSmall:matrix.org> : AFAIK, this room is connected to libera.chat via a plumbed bridge, so it shouldn't impact.

17:26 <re_irc> <@TimSmall:matrix.org> The thing they are wanting disabled is the automatic access to arbitrary Libera IRC channels from Matrix via specially named matrix rooms (these have funky Matrix names like "#irc_chan_name@libera.chat"). The Matrix <-> IRC bridge effectively owns and manages those rooms. In contrast, plumbed rooms are those that are explicitly bridged (and existed as Matrix rooms in their own right first before they were ever connected to...

17:26 <re_irc> ... an IRC channel).

17:54 <re_irc> <@thejpster:matrix.org> ok, cool