<cr1901>
It is _absolutely_ overkill for its intended purpose, which is basically "set and blink LEDs based on the output of cronjobs (and print to an LCD eventually)". But it was fun to write and I learned how to use postcard-rpc and smol. So it's okay if it's overengineered.
<JamesMunns[m]>
Nice! I'll give it a look soon :)
<cr1901>
JamesMunns[m]: High level overview... it's two threads. One runs a smol LocalExecutor and is a UDP server. The other is a blocking thread that talks to all i2c peripherals. All communication is done via channels, with all the boilerplate that that entails.
<cr1901>
To avoid match hell, I return errors from the i2c thread as Box<dyn Any + Send> and downcast/unwrap. I got _a bit_ lazy today and some errors need to be filled in :), but I have some plans for that
<rjmp[m]>
michael.desilva: Reading your STM32H7 issue, that really sounds to me like a power config issue. Note that some of the power config registers can only be written once per power cycle, which could cause the power cycle persistance you're seeing. I would try LDO mode. I think that would be `let mut pwrcfg = pwr.ldo().freeze();`.
<rjmp[m]>
Yeah, that check will fail because the power-up value of the register is to enable the SMPS, but that board you are using grounds the SMPS output, and provides VDD_LDO directly. So I think what is happening is that the bootloader sets the PWR peripheral into LDO mode, and then it doesnt matter what your app does, it will stay in that mode until a POR.
<rjmp[m]>
That actvosrdy bit will never go high because it is waiting for the SMPS voltage to come up.
<rjmp[m]>
* That actvosrdy bit will never go high because it is waiting for the SMPS voltage to come up (and it never will!)
<michaeldesilva[m>
rjmp[m]: Wow that works now!!
<michaeldesilva[m>
So right now, I'm flashing the bare metal blinky to 0x08000000, which means I've wiped the mbed core bootloader. Previously, I tried to flash the unstable blinky to 0x08040000 with the mbed bootloader and on power cycle it didn't work. (1) Is there any point to using the default bootloader with bare metal code (2) should I just continue burning to 0x08000000?
<michaeldesilva[m>
<rjmp[m]> "Yeah, that check will fail..." <- "but that board you are using grounds the SMPS output, and provides VDD_LDO directly"
<michaeldesilva[m>
Did you read this somewhere, in the docs etc?
<rjmp[m]>
If I remember correctly, if the SMPS is enabled, the actvosrdy bit waits for the VFBSMPS input to reach the correct level. That's the feedback pin for the switching regulator, but the SMPS is optional and not used on that board.
<michaeldesilva[m>
<rjmp[m]> "There's a schematic :) https://..." <- thanks!
<michaeldesilva[m>
Any tips on setting up serial comms over USB? https://github.com/stm32-rs/stm32h7xx-hal/tree/master the examples here are for other UART/USART peripherals, but those need to be accessed over separate pins
<michaeldesilva[m>
s/tips/examples/
a2800276 has quit [Read error: Connection reset by peer]
<michaeldesilva[m>
How can I force `stm32h7xx-hal` to use `synopsys-usb-otg = ^0.4`? it keeps flipping and resolving to 0.2.9
<michaeldesilva[m>
* Ahh... got the led to blink but not seeing the USB serial port. Hmm.
<michaeldesilva[m>
* Ahh... got the led to blink but not seeing the USB serial port. Hmm. I double checked the schematic to use the right pins for usb_hs.
<JamesMunns[m]>
Does that chip have a built in HS PHY? or is that something you have to set up externally
<JamesMunns[m]>
Yep, those pins in your code (PB14/15) go to the USB-A pins. You are probably plugged into the USB-C cable, which uses the USB_FS peripheral with pins PA11/12
<JamesMunns[m]>
You could probably make an illegal cable to connect to the USB-A port, not sure what you're trying to do michael.desilva
<JamesMunns[m]>
It's always a good idea to look at the schematic and read the datasheet if you're not sure how things are wired up.
<michaeldesilva[m>
JamesMunns[m]: That top schematic shows USB_FS also going to the USB-C right?
<michaeldesilva[m>
<JamesMunns[m]> "Screenshot 2024-02-02 at 09.01.4..." <- Sorry, this one I mean?
<JamesMunns[m]>
You'll need to use:
<JamesMunns[m]>
* the USB-FS peripheral
<JamesMunns[m]>
* with pins PA11 and PA12
<JamesMunns[m]>
the STM32H7 on your board does not appear to have a built-in USB-HS PHY, nor does it have an external one, so you are likely limited to USB-FS on both ports.
<michaeldesilva[m>
Right, yeah the pinout is right, just usb_hs is wrong as you say :)
<michaeldesilva[m>
thanks!!
<JamesMunns[m]>
> the pinout is right
<JamesMunns[m]>
Your code gist was using PB14/15, which are wired to the USB-A port, not USB-C.
<JamesMunns[m]>
Yeah, sorry, end of my guesses, I've never used that chip. Might be worth waiting for someone else to comment, or ask in #stm32-rs:matrix.org
<michaeldesilva[m>
JamesMunns[m]: I can see /dev/cu.usbmodemTEST_PORT_11 and it seems to work
<michaeldesilva[m>
JamesMunns[m]: thanks
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
michael.desilva: Feel free to ping me with questions on usb + stm32h7, I maintain most of the USB stack stuff at this point and most of my rust projects are also stm32h7 chips. Not sure what you're trying to get working, but we have stabilizer running usb on an stm32h7 just fine with usbd-serial if you ever want a reference design: https://github.com/quartiq/stabilizer
<ryan-summers[m]>
One of my next TODO things is to stabilize the usb stack. We've had some users report that it won't enumerate properly on windows, so that could also be something that's happening
<ryan-summers[m]>
Ah the last message says you got it working, nevermind
<JamesMunns[m]>
We showed up on the github blog for e-hal 1.0 release:
<firefrommoonligh>
My hardware interface code is a thin wrapper over [stm32-usbd](https://github.com/stm32-rs/stm32-usbd), but that hasn't been updated recently, so I'm not sure how to approach this.
<ryan-summers[m]>
Indeed its just updating the UsbBus trait. You probably need to update the stm32-usbd crate. It shouldn't be hard - the API did not change very much
<firefrommoonligh>
That's at the latest: 0.6.0
<dirbaio[m]>
you need all crates to depend on the same usb-device version
<firefrommoonligh>
ryan-summers[m]: It is interesting how there are 3 crates involved. I can never remember how to use them, but C+P goes a long way
<jessebraham[m]>
Sorry we forked `synopsys-usb-otg`
<ryan-summers[m]>
Gotcha, that makes more sense
<jessebraham[m]>
Not sure why we maintain that instead of upstreaming, maybe the upstream wasn't maintained at the time? I didn't do this work haha
<firefrommoonligh>
I haven't tried the synopsys upgrade yet!
<jessebraham[m]>
But updating the 2 aforementioned packages did cause me some pain awhile back haha
<ryan-summers[m]>
Yeah I don't know if anyone still uses stm32-usbd?
<ryan-summers[m]>
Its indeed quite old
<firefrommoonligh>
OK
<firefrommoonligh>
I think that's the problem
<firefrommoonligh>
I'm using stm32-usbd which hasn't been updated in years
<firefrommoonligh>
What's a good alternative?
<firefrommoonligh>
Or should I fork?
<ryan-summers[m]>
What chip are you using it for?
<firefrommoonligh>
G4
<firefrommoonligh>
Although it's the same hardware on almost everythign except H7 and F4
<ryan-summers[m]>
Ah then you can't use synopsys-usb-otg probably.
<ryan-summers[m]>
Maybe take over maintaining it?
<firefrommoonligh>
COrrect
<ryan-summers[m]>
The update to usb-device 3 is super easy
<ryan-summers[m]>
In fact, it may not require any changes
<ryan-summers[m]>
* to usb-device 0.3 is
<firefrommoonligh>
I am using that lib on other projects, but I am tackling this one at a time!
<firefrommoonligh>
(I tried upgrading that too and also had errors, but didn't look into it yet)
<ryan-summers[m]>
Your errors were probably because your dep tree has different versions of usb-device and usbd-serial going throughout. cargo-tree can help
<firefrommoonligh>
Specifically what's breaking, is `usbd-serial: 0.1.1 -> 0.2.0`, and `usb-device: 0.2.9 -> 0.3.1`
<ryan-summers[m]>
Yeah, that's all you've gotta do
<firefrommoonligh>
I was thinking that too. Tried cargo clean also
<ryan-summers[m]>
But do it throughout the whole dep tree. Which is why it sucks
<firefrommoonligh>
So, you don't think the unmaintained stm32-usbd library is related?
<ryan-summers[m]>
So your HAL, the driver crates, and your app all need it updated
<ryan-summers[m]>
It is, because stm32-usbd uses usb-device
<ryan-summers[m]>
firefrommoonlight: Can you try the `master` branch of stm32-usbd to make sure those changes worked? I don't have any hardware to test on. If you do that, I'd be happy to release it
<firefrommoonligh>
And ignoring the error doesn' twokr
<firefrommoonligh>
Empty buffer
<firefrommoonligh>
I may call it quits on this in a bit and swithc back to the old verison
<firefrommoonligh>
ryan-summers: Verified working on hardware with master branch; thx for the merge
khionu[m] has quit [Quit: Idle timeout reached: 172800s]
khionu[m] has joined #rust-embedded
<khionu[m]>
I've determined that I'm getting a Nack when trying to read from my device's configuration after writing to user space. It doesn't seem to matter what or where I write in user space, it triggers the issue.
<khionu[m]>
I tried reading from the Dynamic Configuration as well as System Configuration, both fail with a Nack
<dirbaio[m]>
have you tried adding a sleep? :D
<khionu[m]>
Please don't speak to me or my cup of caffeine again 🤪
<khionu[m]>
(I'll give it a shot)
<khionu[m]>
20ms sleep, no dice
<khionu[m]>
khionu[m]: Sorry, I'm not the most awake and my humor is in a worse state than this board
<JamesMunns[m]>
What line is it crashing on now?
<khionu[m]>
Multiple. Any that writes to read or write to the System Configuration or Dynamic Configuration spaces
<khionu[m]>
s/writes/tries/
<khionu[m]>
But again, only if I have already written to user space
<khionu[m]>
I'm not crossing the "areas" that it warns about, nor am I writing more data than it supports in a single go
<JamesMunns[m]>
did you pick 20ms since that's > 19.7ms?
<khionu[m]>
The first two bytes of any write operation move the memory cursor to the corresponding address, so I did make sure that I'm not giving it a weird address
<khionu[m]>
I pulled it out of thin air
<khionu[m]>
I'm still pretty green to all this
<JamesMunns[m]>
Ah, Wt_Block is 19.7ms if you write 4 blocks
<JamesMunns[m]>
(Table 253)
<JamesMunns[m]>
writing memory often takes a decent amount of time for flash or EEPROM
<khionu[m]>
Interesting
<khionu[m]>
I'll add a little more, then, JIC
<JamesMunns[m]>
yeah, whole second couldn't hurt
<khionu[m]>
.3ms is a bit tight
<khionu[m]>
Well dang
<khionu[m]>
That did it
<JamesMunns[m]>
yeah I dunno how they measure blocks and how many blocks you were actually writing
<khionu[m]>
I wish they referenced that in the I2C write section
<khionu[m]>
16bytes
<khionu[m]>
Or crossing a 16 block boundary
<khionu[m]>
s/block/byte/
<khionu[m]>
Thank you very much!
<Ecco>
I'm trying to enable the RADIO subsystem on STM32WBA, yet no matter what I do the RADIOCLKRDY bit will never turn to 1. Do you guys have any idea what I might be doing wrong?
<khionu[m]>
25ms was too short, 40ms worked.
<khionu[m]>
30ms even was too short
<JamesMunns[m]>
yeah, it's actually table 243 to look at
<JamesMunns[m]>
the other one was for RF writes I guess?
<JamesMunns[m]>
it says 5ms per 4 bytes?
<khionu[m]>
You sure on that table number?
<JamesMunns[m]>
Table 243, tW
<JamesMunns[m]>
I2C write time
<JamesMunns[m]>
I2C write time for 1, 2, 3, or 4 bytes in EEPROM (user memory and system configuration), provided they are all located in the same memory
<JamesMunns[m]>
page, that is, the most significant memory address bits (b16-b2) are the same.
<khionu[m]>
Yeahhhhh, these docs are both thorough and... chaotic
<khionu[m]>
(Hence my crate name)
<khionu[m]>
Well, that solves that issue, thanks
<JamesMunns[m]>
yeah, whenever you are doing writes or erases of nonvol memory, it's worth going to find the table of t sub ... to tell you how long its gunna take
<JamesMunns[m]>
I think there's a flow chart showing a status register you can poll to see when its done, lemme see if I can find it again
<JamesMunns[m]>
6.4.3 is the important part, it's in the "I2C write operations" section
<JamesMunns[m]>
ah, it basically just says "keep addressing the device until it stops NAKing" lol
<JamesMunns[m]>
> During the internal write cycle, the device disconnects itself from the bus, and writes a copy of the data from its internal latches to the memory cells. The maximum I²C write time (tw) is shown in Table 248. I2C AC characteristics (up to 85 °C) and Table 249. I2C AC characteristics (up to 125 °C), but the typical time is shorter.
<khionu[m]>
I cri
<khionu[m]>
I'm gonna need async sooner than later
<JamesMunns[m]>
I think a NAK should return immediately
<JamesMunns[m]>
you know what I mean? The async isn't the load bearing part in "retry until success"
<khionu[m]>
Yeah, I understand, I made like three jumps to reach the "need async" statement
<JamesMunns[m]>
Fair :)
<khionu[m]>
"writing data times out because the alignment of the written data hits 1.5x the number of blocks and ergo 1.5x the length of write time" is... quite the evaluation of an error.
<khionu[m]>
I'm unsure why, but the 5ms is definitely not the maximum, 8ms is closer, and times three because I don't think the 8-byte value I'm writing is aligned perfectly to 2 blocks, which means it's writing to 3 blocks
<JamesMunns[m]>
Yeah, I assume it's 5ms per 4-byte block you hit
<khionu[m]>
Right, but I'm saying I think the reality is closer to 8ms per
<JamesMunns[m]>
so yeah if your 8 bytes is like 2 + 4 + 2, then yeah I assume it'd be 15ms
<JamesMunns[m]>
ah
<khionu[m]>
Given what I'm observing
<khionu[m]>
And I have a 30ms window for the thing I'm trying to do :D
<JamesMunns[m]>
Yeah, that table is just all I saw in a first skim
<khionu[m]>
It's more info than I was able to extract
<khionu[m]>
I think it's time for me to head off and leave it to well-rested me.
<JamesMunns[m]>
You're definitely making progress! It goes like this sometimes
<khionu[m]>
Thanks! I do feel like I'm making progress, just lots of toe stubbing too. It is basically a new-to-me field, so to be expected.
<khionu[m]>
Big kudos to Embassy, though. I've been very happy with how straight forward it's been compared to the examples I've seen in C and C++
<khionu[m]>
Anyways, later!
kevlan[m] has quit [Quit: Idle timeout reached: 172800s]
spinfast[m] has quit [Quit: Idle timeout reached: 172800s]
djdisodo[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco>
dirbaio[m]: I've been thinking about embassy's STM32 interface. Currently, my understanding is that there's an "init" function that will try and configure RCC registers, PLL, wait states, etc…
<Ecco>
It feels to me like this is "not enough"
<Ecco>
Shouldn't it be some kind of a state machine?
<Ecco>
What if you need to switch to a lower-power mode for example?
<Ecco>
Much of the same logic would apply
<dirbaio[m]>
what thing can't you do with the curent init() that you'd be able to do with a state machine?
<Ecco>
let's consider the wait states logic for example
<Ecco>
if you want to change clock speeds, you may need to recompute the wait states
<Ecco>
the init function doesn't do anything *wrong* (hopefully :))
<dirbaio[m]>
the idea is it's automatic: if there's no peripheral requiring a higher-power state, and the core goes to sleep (with a WFI, automatically when all async tasks are sleeping), then the executor automatically changes the chip to a lower STOP mode
<Ecco>
ok, fair enough
<dirbaio[m]>
it's much easier to use than some typestate-based API like "now the chip is in mode X so you can do things Y, Z but not Q"
<dirbaio[m]>
especially because you usually want to handle these things across multiple tasks, so typestates don't work well
<Ecco>
Well, it's easier but does it really work?
<Ecco>
Don't get me wrong
<Ecco>
Embassy is pretty cool, it's very easy to get started with (-> great!)
<Ecco>
but many embedded projects will end up having very strict requirements in terms of power usage
<Ecco>
(which is often the main reason why you'd use an MCU instead of an SoC)
<dirbaio[m]>
embassy-nrf already has the auto-low-power fully implemented, and my company is using it to ship 4 battery-powered products with battery lasting ~1 year
<Ecco>
so you kind of need to be able to do things like "ok, now gate the clocks to this GPIO because I'm not going to use it"
<dirbaio[m]>
so yes it does work 🙃
<Ecco>
yes, I absolutely believe it does
<Ecco>
I guess I didn't find the right words :)
<dirbaio[m]>
Ecco: we're doing it the other way: you tell the HAL you no longer want to use this GPIO (or UART or whatever) by dropping it, then the HAL goes to a lower-power state when all the high-power-requiring things are unused
<Ecco>
I feel like there are some use cases where you don't have just two states "active" vs "sleepy"
<Ecco>
hmm
<Ecco>
interesting
<Ecco>
I guess I'll need to look at that code more then :)
<dirbaio[m]>
be warned it's currently very WIP for stm32
<dirbaio[m]>
but that's the idea embassy's going for
<Ecco>
cool, I'll try and look at the nrf code too then :) Thanks!
<ithinuel[m]>
ithinuel[m]: You are trying to link together two libraries where 1 was built with the VFP flag set, and the other not.
notgull has joined #rust-embedded
<ithinuel[m]>
ithinuel[m]: From the lines you shared, I’d assume that the rust library was built with (since you’re targeting thumbv7em-none-eabi**hf**)
<ithinuel[m]>
ithinuel[m]: You can try building for `thumbv7em-none-eabi` instead.
<ithinuel[m]>
ithinuel[m]: You won’t get hardware accelerated floating point operations but you should be able to link.
<ithinuel[m]>
* From the lines you shared, I’d assume that the rust library was built with (since you’re targeting thumbv7em-none-eabi**hf**)
<ithinuel[m]>
( and that the second line says it explicitly)
<ithinuel[m]>
ithinuel[m]: I’m wondering though why are you pulling gcc’s libc when building a rust application.
<ithinuel[m]>
I didn’t know that rust was using libc’s snprintf.
<ragarnoy[m]>
ithinuel[m]: rust isn't, but i'm using c functions
<ragarnoy[m]>
ragarnoy[m]: i'm making a cffi wrapper library
<ragarnoy[m]>
ragarnoy[m]: but the c library was compiled using hf
notgull has quit [Ping timeout: 256 seconds]
<ragarnoy[m]>
<ragarnoy[m]> "but the c library was compiled..." <- but afaik i can't recompile libc to have hf, which is what the error is basically saying
jmgr[m] has quit [Quit: Idle timeout reached: 172800s]