00:21 <re_irc> <@laura7089:matrix.org> Is there a way to get "eh" alpha-compatible stuff out of the "cortex-m" crate?

00:22 <re_irc> <@dirbaio:matrix.org> what do you mean with "get stuff"? :)

00:29 <re_irc> <@laura7089:matrix.org> I'm developing a driver for an altimeter, and the only hardware I have for it has it soldered to a board with an RP2040, so my "self-tests" test sub-crate for on-device testing relies on "cortex-m" to create a "Delay" object to wait for the altimeter's boot-up time and sample time, but the altimeter driver is targeting the latest "embedded-hal" alpha whereas "cortex-m" is using the non-alpha releases, so getting it to work...

00:29 <re_irc> ... previously used "embedded-hal-compat" to glue them together, but that's fallen out of step with the latest eh alphas

00:30 <re_irc> <@laura7089:matrix.org> So I thought I'd ask if there's a way to cut out the middle man and get compatible delays directly from "cortex-m"

00:30 <re_irc> <@laura7089:matrix.org> I don't actually have any functions in the driver expecting a delay though, only in the tests, so I suppose I could depend on two different versions of EH and rename one (does rust let me do that?)

00:30 <re_irc> <@dirbaio:matrix.org> ahhhokay

00:31 <re_irc> <@dirbaio:matrix.org> yes, cortex-m doesn't support the alphas

00:32 <re_irc> <@firefrommoonlight:matrix.org> I would set up the altimeter in a way so that's not required

00:32 <re_irc> <@dirbaio:matrix.org> > I could depend on two different versions of EH and rename one (does rust let me do that?)

00:32 <re_irc> yep, you can do it like this:

00:32 <re_irc> embedded-hal-02 = { package = "embedded-hal", version = "0.2.6", features = ["unproven"] }

00:32 <re_irc> embedded-hal-1 = { package = "embedded-hal", version = "=1.0.0-alpha.10" }

00:33 <re_irc> <@dirbaio:matrix.org> from the code use "embedded_hal_02" or "embedded_hal_1"

00:33 <re_irc> <@firefrommoonlight:matrix.org> Make a setup fn to write the config, set up a buffer for readings, and write the start/stop ISRs

00:33 <re_irc> <@dirbaio:matrix.org> (you can also rename only one of them too, if you want to keep the 1.0 as the "main" one for example)

00:33 <re_irc> <@firefrommoonlight:matrix.org> What altimeter, btw?

00:33 <re_irc> <@laura7089:matrix.org> : to clarify, the altimeter doesn't require that you pass it a "delay" object (because I anticipated this problem), it requires that the caller wait themselves or block on the device's ready flag

00:33 <re_irc> <@laura7089:matrix.org> : it's an HP203B

00:34 <re_irc> <@laura7089:matrix.org> The code's here: https://github.com/Laura7089/hp203b-rs

10:11 <re_irc> <@diondokter:matrix.org> Oh this is cool!

10:11 <re_irc> Anyone fancy a cortex-m3 that can connect to the satellite communication system? :D

10:11 <re_irc> https://www.qualcomm.com/products/technology/modems/212s-modem#Overview

10:12 <re_irc> <@diondokter:matrix.org> Announcement here: https://www.qualcomm.com/news/releases/2023/06/qualcomm-launches-new-satellite-iot-solutions-to-provide-uninter

10:46 <re_irc> <@dkhayes117:matrix.org> I had ideas about a device with this capability, I didn't know they existed. I wonder what the power consumption is.

10:48 <re_irc> <@dkhayes117:matrix.org> Hmm. Advertised as ultra low power.

11:10 <re_irc> <@jamesmunns:beeper.com> Gotta be careful with that, sometimes "ultra low power" only means when you're powered off, and then it's 300mA to associate/send/receive data :D

11:11 <re_irc> <@jamesmunns:beeper.com> which is _fine_ if your plan is "wake up once a day to send data", not so much if you are trying to do something fancier :D

11:11 <re_irc> <@jamesmunns:beeper.com> (I have no idea about this specific chip tho, but that seems to be par for the course for any radio really like cellular, wifi, or even some of the lora-ish stuff)

11:19 <re_irc> <@ryan-summers:matrix.org> Yeah, anything that goes farther than BT LE range (20-30m) tends to have a pretty high power consumption when on

11:19 <re_irc> <@ryan-summers:matrix.org> But "low power" and "high power" are incredibly relative terms. For some caes, <10 mA is super low power, but some systems define that as pA ;)

11:19 <re_irc> <@diondokter:matrix.org> LoRa isn't too bad either because you can get away with a signal strength at the receiver that is a couple of decibels under the noise floor

11:19 <re_irc> <@jamesmunns:beeper.com> add "portable" to that list

11:20 <re_irc> <@jamesmunns:beeper.com> sometimes it means "fits in a pocket". Sometimes it means "can be towed by a truck" :D

12:04 <re_irc> <@pollyglot:pyjam.as> On this page https://docs.rust-embedded.org/embedonomicon/exceptions.html it says the following

12:05 <re_irc> > The address of the Reset handler can be seen in the disassembly above, being 0x44.

12:05 <re_irc> > However I can't see where the address 0x44 is written. It's in the GDB output, but not the dissassembly.

12:05 <re_irc> <@pollyglot:pyjam.as> On this page https://docs.rust-embedded.org/embedonomicon/exceptions.html it says the following

12:05 <re_irc> > The address of the Reset handler can be seen in the disassembly above, being 0x44.However I can't see where the address 0x44 is written. It's in the GDB output, but not the dissassembly.

12:05 <re_irc> <@pollyglot:pyjam.as> On this page https://docs.rust-embedded.org/embedonomicon/exceptions.html it says the following

12:05 <re_irc> > The address of the Reset handler can be seen in the disassembly above, being 0x44.

12:05 <re_irc> > However I can't see where the address 0x44 is written. It's in the GDB output, but not the dissassembly.

12:05 <re_irc> <@pollyglot:pyjam.as> ->

12:18 <re_irc> <@pollyglot:pyjam.as> am i just blind or is this a mistkae

12:18 <re_irc> <@pollyglot:pyjam.as> * mistake

12:40 <re_irc> <@ryan-summers:matrix.org> Looks like a mistake to me, I also don't see any reference to 0x44

12:43 <re_irc> <@pollyglot:pyjam.as> if you ctrl+f 0x44 it shows up in the statement I copy pasted, and at the bottom when setting a breakpoint at HardFault,,, which I realise as I'm typing this isn't relevant lol

12:43 <re_irc> <@pollyglot:pyjam.as> I'll report it

14:51 <re_irc> <@pronvis:matrix.org> Hello mates!

14:51 <re_irc> Is there any rust projects for BigTreeTech boards?

14:52 <re_irc> <@pronvis:matrix.org> Hello mates! Is there any rust projects for BigTreeTech boards?

15:01 <re_irc> <@jamesmunns:beeper.com> pronvis: Haven't seen those boards specifically, if you know the chips on them, you might be able to find some more general building blocks out there though!

15:03 <re_irc> <@pronvis:matrix.org> : that one: https://github.com/bigtreetech/BIGTREETECH-SKR-E3-DIP-V1.0/blob/master/Hardware/SKR%20E3-DIP-V1.1-PIN.pdf Ye, I know the chip, but it is a lot of hardware there. I am not sure that I am able to build software for that board by my own

15:07 <re_irc> <@ryan-summers:matrix.org> It looks like they use standard MARLIN 3D printer firmware for that board. Are there any Rust MARLIN project equivalents?

15:07 <re_irc> <@ryan-summers:matrix.org> That'd be a good start. Those 3D printer boards are actually all really standardized surprisingly

15:07 <re_irc> <@jamesmunns:beeper.com> Gotcha! Seems to be running an STM32F103, which there are lots of projects here - but I don't think I've seen someone set up a project with all the external parts and logic and things

15:07 <re_irc> <@jamesmunns:beeper.com> (schematic here (https://github.com/bigtreetech/BIGTREETECH-SKR-E3-DIP-V1.0/blob/master/Hardware/SKR-E3-DIP-V1.0-SCH.pdf))

15:12 <re_irc> <@pronvis:matrix.org> : Rust Marlin equivalent would be awesome to find. Cause my project is similar in some case (have 4 stepper drivers).

15:17 <re_irc> <@jamesmunns:beeper.com> If you find something, definitely add it to https://github.com/rust-embedded/awesome-embedded-rust

15:17 <re_irc> <@jamesmunns:beeper.com> that's usually where I look for "does this exist" first :)

15:26 <re_irc> <@ryan-summers:matrix.org> https://github.com/nviennot/turbo-resin ?

15:26 <re_irc> <@pronvis:matrix.org> : looking into it right now :), tjamls

15:26 <re_irc> <@pronvis:matrix.org> * thanks

18:52 <re_irc> <@jamesmunns:beeper.com> Anyone here worked with stuff like IP blobs from companies like Mentor Graphics?

18:52 <re_irc> I'm planning on USB OTG support for the allwinner D1, which _appears_ to use some MG IP (link to kernel docs (https://github.com/torvalds/linux/blob/8a28a0b6f1a1dcbf5a834600a9acfbe2ba51e5eb/drivers/usb/musb/musb_core.c#L11-L21).

18:52 <re_irc> I might end up working backwards from the linux kernel impl, but I was wondering are there usually reference manuals for this stuff, either:

18:52 <re_irc> - From the designer (MG)

18:52 <re_irc> - From the implementer (Allwinner)

18:52 <re_irc> The Allwinner user manual doesn't have anything (including register defs!) in it regarding usb-otg, I was wondering if there is some PDF out there that I could find, like if someone with an NDA happened to leave it somewhere indexable :D

18:53 <re_irc> <@jamesmunns:beeper.com> not sure if you're in the USB game still, or if you happened to know how these IP blocks work :D

19:00 <re_irc> <@jamesmunns:beeper.com> Oh look, a pdf that fell off the truck: https://linux-sunxi.org/images/7/73/Musbmhdrc.pdf

19:00 <re_irc> <@jamesmunns:beeper.com> :D

20:38 <cr1901> Better not right-click save that PDF before putting it back on the truck