<AdinAck[m]>
can i also configure cargo or probe-rs to not do this?
<adamgreig[m]>
yea, you should find it's just .log files
<adamgreig[m]>
I think in the latest versions of probe-rs it automatically rotates out old logs, so it may be you just need to delete those and make sure you're using the newest probe-rs
<adamgreig[m]>
oh, in fact the latest release turns off logging by default, so they won't get made at all
<vollbrecht[m]>
<AdinAck[m]> "can i also configure cargo or..." <- funny anecdote because of this you were sometimes limited by your hdd/ssd speed when flashing a binary and not limited by the connection =) but yeah its gone now in the latest release and only opt in
<AdinAck[m]>
<vollbrecht[m]> "funny anecdote because of this..." <- haha!
<cgc17[m]>
let's say I want to turn a pin into an output and also set it to high... how would I do that here? My main question is around the ID piece (A/B) - I'm not sure how to differentiate when I do, for example, *ptr1 = 1. My goal is simply to turn two pins on and make an LED on the microbit LED matrix turn on. Stictly for learning purposes, I'm doing this with raw pointers.
<adamgreig[m]>
A is bit 0, B is bit 1, so writing 0x0000_0001 to the register sets it to an output (A=1) with input buffer connected (B=0)
<adamgreig[m]>
to actually set the pin high or low, use the OUT or OUTSET/OUTCLR registers
<adamgreig[m]>
(OUT sets all pins at once, OUTSET/OUTCLR lets you individually set/ignore or clear/ignore individual pins, where clear means set to 0)
<cgc17[m]>
^ and that is not working... I double checked using the BSP is_set_high() and is_set_low() and row1 is still low and col1 high so I'm probably not doing this piece right.
kenny has quit [Ping timeout: 255 seconds]
<JamesMunns[m]>
any non-volatile writes you do might be totally removed by the compiler
<JamesMunns[m]>
Also, cgc17 apologize if you've already answered this - is there a reason that you aren't using the PAC for the nrf52 family or any of the existing HALs?
<cgc17[m]>
true on the question about doing nothing for `x |= 0 << 27`... before I was thinking they both needed to be high so that's probably not needed.
<cgc17[m]>
JamesMunns[m]: I did up above, no worries... I'm doing this strictly for learning. Otherwise i use the HAL or BSP typically
<JamesMunns[m]>
which handles all the volatile stuff and field addressing stuff
<JamesMunns[m]>
If you're aware of it, no worries :)
<JamesMunns[m]>
you will need to use `read_` and `write_volatile` for all interactions with memory mapped peripherals, to tell the compiler not to reorder, remove, or otherwise "optimize" anything about those reads and writes.
<JamesMunns[m]>
unlike in C, where fields/bindings are volatile (or not), in Rust, access is volatile (or not).
<JamesMunns[m]>
so there are no volatile pointers or statics, only volatile read/writes of pointers.
<cgc17[m]>
okay that helps! I feel like once I can do this once "manually" it will help me better understand what the PAC/HAL/BSP have been doing on my behalf and give me some context along the way so thanks for bearing with me.
notgull has quit [Ping timeout: 240 seconds]
kenny has joined #rust-embedded
<cgc17[m]>
well... the wrong lights are lighting up, but I can confirm I'm at least doing something now! ha... the sticking point was I first have to turn col1 low and then make row1 high and it works (must be in that order, I was setting col1 low second which didn't work for some reason). I forgot in the embedded book I noticed the same thing.
<cgc17[m]>
I won't take up more space with this, but will keep playing with it. Seriously thanks again to you both for your help!
<cgc17[m]>
* col1 low - using OUTCLR instead of OUTSET - and then
notgull has joined #rust-embedded
stuw1 has joined #rust-embedded
notgull has quit [Ping timeout: 260 seconds]
m5zs7k has quit [Ping timeout: 260 seconds]
m5zs7k has joined #rust-embedded
Noah[m]1 has joined #rust-embedded
<Noah[m]1>
<adamgreig[m]> "I think in the latest versions..." <- also, they get pruned even if they are old ones :)
mameluc[m] has joined #rust-embedded
<mameluc[m]>
I am trying to figure out if I could use standby mode on my stm32wl chip. Standby resets the chip on wake up but I can keep SRAM2.
<mameluc[m]>
How do I put a variable at a specific memory location?
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Generally by making a custom link section and putting that variable into the specified section with compiler attribute macros
<ryan-summers[m]>
Well, you can't put a local variable with a link section
<ryan-summers[m]>
So yeah, I guess it would be static's only. Anything local would be stack allocated
<mameluc[m]>
I think I confuse staic and const
<mameluc[m]>
s/staic/static/
<ryan-summers[m]>
static just means "global"
<JamesMunns[m]>
const is just a value, not a binding.
<JamesMunns[m]>
so: it's the payload, not the container. If you want something to BE SOMEWHERE, you have to place the CONTAINER, not the VALUE, if that makes sense
<JamesMunns[m]>
you often need a VALUE to be const so you can BIND it to a static, because statics must be initialized with a value at compile time, and only const values are known at compile time.
<mameluc[m]>
that makes sense
<mameluc[m]>
I could probably use StaticCell for this
<mameluc[m]>
I still need to figure out how to differentiate uninitialized (first boot) from later resets
<JamesMunns[m]>
If you're doing Fancy Things, you might need to have those as separate linker sections, and handle the initialization itself. (soft) Rebooting and using memory that isn't initialized, but the code assumes IS initialized, will make everything go sideways
<mameluc[m]>
I need to initialize this memory at run time. My plan is to put lorawan Mac data there
<mameluc[m]>
I guess I could initialize to None
<mameluc[m]>
or whatever a empty StaticCell is
<JamesMunns[m]>
I have a meeting, but if the code goes back through init, it will wipe it every time you boot
<mameluc[m]>
not with sram2 retention in standby mode
<JamesMunns[m]>
if it does, you need to use a separate uninit section, and probably a magic value, and/or a crc check
<mameluc[m]>
thanks for the tips!
IlPalazzo-ojiisa has joined #rust-embedded
starblue has joined #rust-embedded
AdamHorden has quit [Changing host]
AdamHorden has joined #rust-embedded
<mameluc[m]>
<JamesMunns[m]> "I have a meeting, but if the..." <- took me a while to understand what you meant
<mameluc[m]>
rust kind of assumes the variables should be inited before use after boot. I have to figure out how to do this
<mameluc[m]>
looking at uninit now, kind of goes over my head
<JamesMunns[m]>
I can't help in detail until later, but I'm working on a crate called [grounded](https://docs.rs/grounded/latest/grounded/) to hopefully make managing uninit and late init data easier
<mameluc[m]>
amazing! thanks. Ill try to understand your code but it looks exactly like what I am looking for
<JamesMunns[m]>
The idea would be: every time you modify the data, you update the magic number/CRC, so you can tell the difference between "noise in uninit ram" and "valid data".
<JamesMunns[m]>
If you wait for tonight I'll build it for you, since that's a thing I want to add to grounded anyway. but not now :)
<mameluc[m]>
okay I have to think about how that aligns with the needs of persisting the mac status for lorawan. I control when the device goes to standby so I should be able to add some flags before that. On panic or other reset I want to start from scratch anyway
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<chrysn[m]>
Debugging some nRF52 I2C issues, I'm looking for reference implementations of embedded-hal 1.0 transactions on that platform. I've checked the nrf-rs crate, but those are ancient by embedded-hal standards, and embassy-nrf's fn transaction() is a big todo!(). Are there any others I could check?
<JamesMunns[m]>
embassy-nrf?
<JamesMunns[m]>
or are you debugging embassy-nrf?
<chrysn[m]>
embassy-nrf has read and write but a big todo!() in transaction.
<JamesMunns[m]>
ahhh! sorry, I misread
<dirbaio[m]>
it's todo, PRs welcome
<dirbaio[m]>
it shouldn't be too hard to implement
<dirbaio[m]>
except this "Data from adjacent operations of the same type are sent after each other without an SP or SR."
<mameluc[m]>
so sys_reset doesn't clear memory only peripherals?
<JamesMunns[m]>
Correct. Only cortex-m-rt resets memory
<JamesMunns[m]>
at startup, ram contents are unspecified.
<chrysn[m]>
<dirbaio[m]> "because https://devzone...." <- argh, that's the precise issue chat troubles me :-(
<dirbaio[m]>
hah
<dirbaio[m]>
yeah there's no way to fix it :(
<dirbaio[m]>
hardware just .. can't
<dirbaio[m]>
other than using the legacy TWI peripheral from nrf51 (no DMA)
<chrysn[m]>
is that reliable info there? i'd have hoped that the suspend state would help
<dirbaio[m]>
suspend doesn't allow swapping to another buffer
<dirbaio[m]>
(without doing a repeated start)
stuw1 has quit [Ping timeout: 268 seconds]
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<chrysn[m]>
Did you look into whether the EasyDMA does allow doing this? (Not that it'd help me given the RIOT OS interfaces I'm going through, but at least that'd allow the embedded-hal trait to be actually implemented; otherwise by the guidance around it (['In no case should "not supported" errors be returned. This ensures maximum compatibility'](https://github.com/rust-embedded/embedded-hal/blob/master/docs/migrating-from-0.2-to-1.0.md) we
<chrysn[m]>
can't use that trait there without going through TWI).
<chrysn[m]>
* Did you look into whether the EasyDMA does allow doing this? (Not that it'd help me given the RIOT OS interfaces I'm going through, but at least that'd allow the embedded-hal trait to be actually implemented; otherwise by the guidance around it (['In no case should "not supported" errors be returned. This ensures maximum compatibility'](https://github.com/rust-embedded/embedded-hal/blob/master/docs/migrating-from-0.2-to-1.0.md))
<chrysn[m]>
we can't use that trait there without going through TWI.
<dirbaio[m]>
yeah I've already looked into this, the answer is you can't
<dirbaio[m]>
* you can't with EasyDMA
<dirbaio[m]>
I'm the one that opened that Nordic DevZone thread
<chrysn[m]>
(Where I'm interpreting panicking on not-implemented as just a worse way of erring with not-supported -- a ToDo is practical, but a long-term error indicates things are really troubled)
<dirbaio[m]>
you can still implement it by copying through an intermediate buffer
<dirbaio[m]>
for each consecutive run of write operations, concat all their data into the intermediate buffer, then write that
<chrysn[m]>
... in which case there is a hard limit on the length of data to be transferred.
<dirbaio[m]>
if buffer is too small, error. then give some knob to the user to tune the buffer size maybe
<dirbaio[m]>
yeah
<dirbaio[m]>
but you can't do any better to be honest
<chrysn[m]>
OK, thanks!
<dirbaio[m]>
there's already a similar problem with "easydma can't read from flash", that also needs copying through a RAM buffer
<chrysn[m]>
(Maybe I'll look at the TWI peripheral, that might be a usable alternative at least for my concrete case)
<chrysn[m]>
Hmpf -- none of those are, like, Unusable Design, but they do make a dent in my so-far held gut feeling that nRF are the best chips you can get these days.
<chrysn[m]>
(if you can get them ;-) )
<chrysn[m]>
Thanks for sharing your experience with those, saved me a lot of trying-things.
<dirbaio[m]>
yeah I got the same impression when I ran into this, it's a quite annoying design blunder
<dirbaio[m]>
in an otherwise fantastically-designed set of peripherals 🥲
<chrysn[m]>
Did you in your exploration of the peripheral find how to wait for completion of an operation that doesn't use a LASTRX->STOP condition? If I send the STOP all is fine (I can wait for the STOPPED interrupt), but if I don't send a STOP because there will be a followup operation, by the time LASTRX triggers, the peripheral only just started (and didn't complete) the last byte.
<chrysn[m]>
Granted, for most transfers (that are write,read) that is not critical, because the LASTTX condition is good enough as the value is loaded before the ISR can free the data, and after an RX there is usually a STOP, but I'm worried I'm building a subtle and rare race condition if I allow the buffers to be freed already when the LAST?X interrupt is received.
<dirbaio[m]>
i'm not sure
<dirbaio[m]>
i think it's designed so you can enable the shorts
<dirbaio[m]>
LAST* -> START if you want to do another transfer, or LAST* -> STOP if you want to stop
IlPalazzo-ojiisa has quit [Ping timeout: 252 seconds]
<mameluc[m]>
standby mode works very well on stm32wl. Wake up from button works now, I "just" have to get the rtc ticking again
<mameluc[m]>
without rtc it only takes 940nA
<dirbaio[m]>
:D
<dirbaio[m]>
in the end you ended up using standby manually, not embassy-stm32 low-power feature?
notgull has joined #rust-embedded
<mameluc[m]>
dirbaio[m]: yeah, low_power with stop2 messes with the clocks. Could not figure out how to turn them back on
<mameluc[m]>
I got it working in a way that it woke up like 10 times without a beat and then suddenly the clocks did not turn on correctly and it continued running on LSE or some other slow clock
<mameluc[m]>
tried adding LPTMR but could not figure it out this time
<mameluc[m]>
then I opted for standby with SRAM2 retention, lets see how it pans out
IlPalazzo-ojiisa has joined #rust-embedded
<dirbaio[m]>
I see
<dirbaio[m]>
yeah, damn, still a long way to go for stm32 low power 🫠
<dirbaio[m]>
* go for mature stm32 low, * low power support 🫠
<mameluc[m]>
yeah, embassy is a really wide project and low power requires a lot. Changing the clocks or re-initing them is hard to do as a lot of stuff is dependent on clock stuff. sys_reset is a pretty nice workaround if I can get it to work.
<mameluc[m]>
all the drivers needs to be re-created anyway for low power so there is not much that is lost for a simple application
HumanG33k has quit [Quit: WeeChat 3.8]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Client Quit]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Client Quit]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Client Quit]
HumanG33k has joined #rust-embedded
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Is it worth it to support reclocking if it makes it slightly less convenient for everyone else? I am imagining that you would need to pass a `Clocks<'a>` zst token to every driver that depends on the clock speeds
<dirbaio[m]>
probably not
<GrantM11235[m]>
I think that's what the esp people do
<dirbaio[m]>
for this low-power use case you don't need reclocking though, you just need "restore the clock config that we already had before sleeping"
StephenD[m] has joined #rust-embedded
<StephenD[m]>
I am also curious about low power stm32 stuff, specifically with rtic on an stm32f411
<StephenD[m]>
I'd like to have my mcu sleep at some low power state, and wake up every x seconds to run some code
<StephenD[m]>
Is that doable with rtic or should I just throw out rtic and do it all myself?
<dirbaio[m]>
it's a feature of the HAL, it's orthogonal to using RTIC or not
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<StephenD[m]>
<dirbaio[m]> "it's a feature of the HAL, it'..." <- Right, but if I start shutting things down and then starting them back up, will RTIC get confused?
<dirbaio[m]>
RTIC doesn't interact with stm32 peripehrals, just with the Cortex-M NVIC
<StephenD[m]>
hm okay
<StephenD[m]>
I guess I'll revise my question to how good is the stm32f411 hal for power saving stuff?
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
notgull has quit [Ping timeout: 246 seconds]
notgull has joined #rust-embedded
<firefrommoonligh>
RTIC doesn't care
<firefrommoonligh>
As dirbaio said
<firefrommoonligh>
Also, setting the basic sleep mode is v easy; I think it's a single bit in a cortex_m register for most STM32s
<firefrommoonligh>
Things only get messy if you are altering clock speed on the fly etc, or doing a stop mode or deeper; then you have to be careful about how you can wake it, if you're using the RTC with dedicated xtal etc
<firefrommoonligh>
You just set the bit (Which may actually be set by default??) And do cortex_m::wfi(). It will take a nap
<StephenD[m]>
Ah yeah I'm familiar with wfi
<StephenD[m]>
I'd like to go deeper than that though
<firefrommoonligh>
There is a trick though if you have a debugger...You need to set 3 bits in the DBGMCU_CR register, or it will hang until you do a boot0-held flash erase
<firefrommoonligh>
Generally titled "sleep", "stop", "standby" or w/e. I guess you only need the correct one. Also you may have to enable a DMA periph if you don't already. This is an eratta
<firefrommoonligh>
stop is easy too, but involves setting some bits in the STM32 pwr or something. Just note what you need to do to wake it
<firefrommoonligh>
(I can't speak to that lib; check the docs/examples?)
<firefrommoonligh>
*To stop an F4, set SCB_SET_DEEPSLEEP(), clear the PWR_CR PDDS and PPDS bits, then do wfiorwfe`
<firefrommoonligh>
* *To stop an F4, set SCB_SET_DEEPSLEEP(), clear the PWR_CR PDDS and PPDS bits, then do wfiorwfe\
<mameluc[m]>
<firefrommoonligh> "There is a trick though if you..." <- I usually put in a delay at startup so the debugger always has time to grab it on power on
<firefrommoonligh>
Does this work?
<firefrommoonligh>
If you don't do the steps I posted, it's not a "it maybe will cause trouble", it's a "it will probably hang the first time you use wfi with a debugger connected, and refuse to flash until you boot it with boot0.
<firefrommoonligh>
So, if that doesn't happen, I guess your delay works too.
<firefrommoonligh>
At least for most STM32 variants
<firefrommoonligh>
* If you don't do the steps I posted, it's not a "it maybe will cause trouble", it's a "it will probably hang the first time you use wfi with a debugger connected, and refuse to flash until you power it on with boot0 high."
swaits[m] has joined #rust-embedded
<swaits[m]>
Hey all. I just picked up a nRF52840-MDK USB dongle from makediary. I am in that newbie-idiot phase here... but having gone through all the probe-rs docs, etc, I'm still stuck. Anyone used s similar board and had success connecting to it via probe-rs? I installed probe-rs with cli & ftdi, but no matter what I do I get No probes found.
<swaits[m]>
s/makediary/makerdiary/
salsasteve[m] has quit [Quit: Idle timeout reached: 172800s]
<swaits[m]>
* Hey all. I just picked up a nRF52840-MDK USB dongle from makerdiary. I am in that newbie-idiot phase here... but having gone through all the probe-rs docs, etc, I'm still stuck. Anyone used s similar board and had success connecting to it via probe-rs? I installed probe-rs with cli & ftdi, but no matter what I do I get No probes found. ETA: I'm on macOS and the probe setup instructions for that all seems to act like there's
<swaits[m]>
nothing more to do? /shrug
<swaits[m]>
* Hey all. I just picked up a nRF52840-MDK USB dongle from makerdiary. I am in that newbie-idiot phase here... but having gone through all the probe-rs docs, etc, I'm still stuck. Anyone used s similar board and had success connecting to it via probe-rs? I installed probe-rs with cli & ftdi, but no matter what I do I get No probes found. ETA: I'm on macOS and the [probe setup