11:53 <steew> Coincidentally, this also helps me, thank you

15:00 <re_irc> <Ralph> is there an (easy) way to write a crate which interacts with a device connected via UART and using DMA in a HAL-independent way? i found embedded-dma (https://docs.rs/embedded-dma/latest/embedded_dma/) and i _think_ that "embedded-hal" has some traits to read from a serial port (i don't need to write to it at the moment), but i didn't see a way to actually handle the whole DMA buffer rotation, e.g. i didn't see any trait...

15:00 <re_irc> ... which would cover the "Transfer::next_transfer" (https://docs.rs/stm32f4xx-hal/latest/stm32f4xx_hal/dma/struct.Transfer.html#method.next_transfer) of the "stm32f4xx-hal".

15:00 <re_irc> i'm just wondering how much logic i can put into a device-independent crate and how much needs to be in the main (device-specific) project.

15:11 <re_irc> <Ralph> btw: i'd like to bump this question. i'd like to know whether i should now turn my current code into a driver specific for this motor driver or a more generic one (mainly a naming thing at this point)

16:10 <re_irc> < (@adamgreig:matrix.org)> hey , any idea why i might keep getting "ERROR panicked at 'rfbusys timeout pwr.sr2=0x1F6 pwr.subghzspicr=0x8000 pwr.cr1=0x200'" on stm32wlxx-hal while transmitting lora on a seeed lora-e5?

16:11 <re_irc> < (@adamgreig:matrix.org)> I am guilty of just gluing a bunch of your testsuite subghz file together until it seemed to be transmitting, and the specan suggests it is transmitting packets, but after a while (sometimes soon, sometimes a minute or two) it hits that panic

16:13 <re_irc> < (@newam:matrix.org)> I have a long history with hitting that condition (which is why I put that panic in), I'm probably still driving the radio wrong. It seems to be related to low power modes, I have one device running that has been running for ~2 months now without seeing that panic, but my battery operated devices hit it about twice a month.

16:13 <re_irc> The testsuite shouldn't be doing any low power stuff though, so that's probably something else.

16:13 <re_irc> < (@newam:matrix.org)> Hmmm

16:14 <re_irc> < (@adamgreig:matrix.org)> I'm using the git version of the hal, and my code's https://dpaste.com/8WW4YENDB but there's nothing that's not from the test suite (and i don't think anything missing but who knows...)

16:14 <re_irc> < (@adamgreig:matrix.org)> just wondering if you had any particular ideas though, i can dig into it a bit and see if anything stands out

16:19 <re_irc> < (@newam:matrix.org)> Hmmm, the only thing that stands out is that payload length isn't set before the TX.

16:19 <re_irc> I usually do "sg.set_packet_params(&BASE_PACKET_PARAMS.set_payload_len(buf.len() as u8))?;" before "write_buffer" and "set_tx"

16:20 <re_irc> < (@newam:matrix.org)> Also the frequency is 868MHz, but the image calibration is set for the 434MHz band

16:20 <re_irc> < (@adamgreig:matrix.org)> well that latter is definitely on me for bulk copy-pasting

16:22 <re_irc> < (@adamgreig:matrix.org)> : aren't I essentially doing this in sg.set_lora_params where LORA_PACKET_PARAMS has set_payload_len()?

16:22 <re_irc> < (@adamgreig:matrix.org)> .....which I then don't use, right, cool

16:23 <re_irc> < (@adamgreig:matrix.org)> oh, no, they do get set

16:23 <re_irc> < (@newam:matrix.org)> oh yeah that's all fine then, the buffer length matches that

16:24 <re_irc> < (@adamgreig:matrix.org)> same panic with the image cal set for 868

16:25 <re_irc> < (@newam:matrix.org)> What function call sees that panic?

16:26 <re_irc> < (@adamgreig:matrix.org)> "stm32wlxx_hal::subghz::{impl#2}::poll_not_busy" via set_tx()

16:32 <re_irc> < (@newam:matrix.org)> Another thought: you may want to poll on the IRQ status instead of command status:

16:32 <re_irc> let (status, irq_status) = sg.irq_status().unwrap();

16:32 <re_irc> if irq_status & Irq::TxDone.mask() { /*...*/ }

16:32 <re_irc> ...I should change that in the testsuite too

16:38 <re_irc> < (@adamgreig:matrix.org)> that does seem to work, but no impact on the panic

16:49 <re_irc> < (@adamgreig:matrix.org)> I'm also bravely hoping the stock seeed firmware on my other e5-mini can receive the lora packets but sadly it's not printing anything even though the specan sees some sort of transmission

16:50 <re_irc> < (@adamgreig:matrix.org)> (using "AT+MODE=TEST AT+TEST=RFCFG,868,SF7,125,8,12,14,ON,OFF,OFF AT+TEST=RXLRPKT" to get it to listen to generic lora instead of just lorawan/LR)

16:56 <re_irc> < (@jannic:matrix.org)> I don't know if it's relevant for generic lora. For lorawan the downlink somehow inverts I/Q, so if you want to see an uplink transmission with a second device, you have to reconfigure the radio accordingly.

16:57 <re_irc> < (@adamgreig:matrix.org)> huh. I did try the "invert IQ" option at one point without success but have mostly left it off, but since I'm just doing plain lora from one to another I don't think it should be getting inverted

16:57 <re_irc> < (@adamgreig:matrix.org)> any idea why they do that?

16:58 <re_irc> < (@jannic:matrix.org)> I think that way up and downlink interfere less.

17:01 <re_irc> < (@jannic:matrix.org)> Seems like plain Lora doesn't do that. But I know next to nothing about that, I just played with an stm32wl for some hours.

17:01 <re_irc> < (@adamgreig:matrix.org)> that's about my level of experience right now too 😆

18:26 <re_irc> < (@firefrommoonlight:matrix.org)> Ralph: Probably not, given DMA impls are hardware -specific

18:26 <re_irc> < (@firefrommoonlight:matrix.org)> At least in the general approach. I'm open to ideas

18:27 <re_irc> < (@firefrommoonlight:matrix.org)> * Do you have any ideas in particular re the API?

20:13 <re_irc> <Nitin> I've written a GPIO interrupt program in PSOC6 µC. I'm getting an error when the interrupt is triggered.

20:13 <re_irc> While debugging observed that interrupt is in pending state. But during interrupt unmasking in NVIC error is coming. I don't what is going wrong. Attached the code here looking for some input.

20:13 <re_irc> <Nitin> #![no_std]

20:13 <re_irc> #![allow(unused_imports)]

20:13 <re_irc> #![no_main]

20:13 <re_irc> use core::cell::{Cell, RefCell};

20:13 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/SLuCFpoFN7k8dVvOPGjQtXSbvZNvTIY3 (62 lines)

20:13 <re_irc> <Nitin> Logs

20:13 <re_irc> Open On-Chip Debugger 0.11.0+dev-4.3.0.1746 (2021-09-16-07:59)

20:13 <re_irc> Licensed under GNU GPL v2

20:13 <re_irc> For bug reports, read

20:13 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/M1JcuqKYxNNjRpkYXIl1LmcUWQwMgWkm (83 lines)

20:14 <re_irc> <Nitin> Logs

20:14 <re_irc> Open On-Chip Debugger 0.11.0+dev-4.3.0.1746 (2021-09-16-07:59)

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

20:14 <re_irc> Licensed under GNU GPL v2

20:14 <re_irc> For bug reports, read

20:15 <re_irc> <Nitin> I've written a GPIO interrupt program in PSOC6 µC. I'm getting an error when the interrupt is triggered.

20:15 <re_irc> While debugging observed that interrupt is in pending state. But during interrupt unmasking in NVIC error is coming. I don't no what is going wrong. Attached the code here looking for some input.

21:48 <re_irc> <thebox> My rust program handles setting up the system, managing threads, and listening for external events. The intention is for this to act as a library and a user will write code to manage what happens when these external events trigger. How can I architect my program in such a way that the user can write the implementations for these functions that my library will call ideally without stepping into unsafe territory?

23:46 <re_irc> < (@adamgreig:matrix.org)> , any idea what voltage the seeed tcxos are? i noticed the tcxo trim is set to 1v7 but no idea what it actually wants...

23:46 <re_irc> < (@adamgreig:matrix.org)> wish they had a schematic or anything really

23:48 <re_irc> < (@newam:matrix.org)> I have it at 1.8V in my code that uses the seeed module, but I don't recall where that came from

23:55 <re_irc> < (@adamgreig:matrix.org)> as good a number as any I guess