<Lumpio[m]>
Also is that VBUS net label actually attached to the USB connector? I would probably also put the ferrite in a different spot so all the power rails go through it.
<Lumpio[m]>
Also your capacitor has a sneaky wire going through it, which also shouldn't be there
<AdamHott[m]>
Lumpio[m]: Thanks!
<AdamHott[m]>
<Lumpio[m]> "image.png" <- Thanks!
<AdamHott[m]>
<Lumpio[m]> "Also is that VBUS net label..." <- Yeah the VBUS is connected to the USB connector, that was something that was laid out in the tutorial, I'm not sure if I should deviate from that since the next steps are also based upon what was already done.
<AdamHott[m]>
From my understanding this chip has built in EMI, and I think the video mentions that this is just a very basic example to get started with, maybe not ideal best practices.
<AdamHott[m]>
I'm still learning about these components as I go
<AdamHott[m]>
Sorry for going off on a tangent, what I was trying to get to the bottom of was that Pin 5 and Pin 6 ERC warning...
<Darius>
AdamHott[m]: there is a #kicad IRC channel BTW
<AdamHott[m]>
Ah didn't realize, can I get to that through Element?
<Darius>
(not that I think asking here is bad just FYI)
<Darius>
uh
<Darius>
dunno :)
<AdamHott[m]>
no worries
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
Ello - '24 is the year of properly digging into embedded rust and contributing, so I'm looking for a project to get my feet wet.
<FreeKill[m]>
Currently I'm thinking of something like a mouse emulator? Plug it in, enumerate over USB, do input somehow (buttons, accelerometer, idk).
<FreeKill[m]>
Does that sound like a feasible intro for someone with a lot of embedded C but only a little embedded Rust? The ecosystem USB crates look pretty cool (and magical, to be honest).
<FreeKill[m]>
So now i'd like to aim for something that'll force me to tackle more
<AdamHott[m]>
Ah okay, I'm not aware of how complicated the project your entailing would be actually
<AdamHott[m]>
I'm green to this world
<M9names[m]>
Depending on how much you're willing to let other crates do the heavy lifting, this task could range from trivial to pretty involved.
<M9names[m]>
You can use usbd-human-interface-device or usbd-hid to get a USB mouse up and going very quickly, these crates have examples and several HALs have example as well.
<FreeKill[m]>
That was my feeling too - the USB ecosystem seemed extremely cool. Just plugging in class implementations to a generic driver is wild, coming from C
<M9names[m]>
Yup. Does mean you can spend more time on the fun bit :)
<FreeKill[m]>
So I think getting going quickly would be great, then I can dig into how exactly everything is working. I am familiar with the STM32 USB at a hardware level, and I know how the ST USB stack works, so I think it'd be a good point of reference
<FreeKill[m]>
How runtime agnostic are these things? I assume the stm32-usbd impl has to hijack the usd pcd interrupt
<FreeKill[m]>
I guess the device layer has to do that itself, than hand off a UsbPeripheral?
jannic[m] has joined #rust-embedded
<jannic[m]>
I don't know details about stm32-usbd, but as it seems to implement the usb_device API, it probably doesn't "hijack" any interrupt. Instead, it provides a poll method which needs to be called periodically (at least every 10ms according to the docs). In practice, there's probably some interrupt (perhaps the "pcd interrupt" you mentioned?) that could be used to trigger the polling.
<FreeKill[m]>
Oh interesting. That's very curious
<FreeKill[m]>
Normally I'd expect to serve the usb endpoint complete interrupt and check if there's more data to copy, that kind of thing
<FreeKill[m]>
But cool!
<FreeKill[m]>
Excited to learn more
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
But the actual crate docs should clarify
<adamgreig[m]>
I think in practice you typically can just call it every time there's a usb interrupt, from the interrupt handler, and don't additionally need to poll it periodically
<jannic[m]>
And be warned about a common pitfall. This sentence from poll's docs is important: "Note: The list of classes passed in must be the same classes in the same order for every call while the device is configured, or the device may enumerate incorrectly or otherwise misbehave."
<FreeKill[m]>
Makes sense
thejpster[m] has joined #rust-embedded
<thejpster[m]>
ugh, I have a device that needs a custom linker script and I keep linking it with the standard cortex-m-rt linker script and getting sad that nothing works. I've done it at least five times now.
<AdamHott[m]>
<thejpster[m]> "ugh, I have a device that..." <- I'm sorry you feel sad
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
<holo[m]>
what is strange when i try to compile example from this crate im getting same amount of such errors, is this crate for sure working?
<holo[m]>
s/all/lot/
<holo[m]>
* sure working or i picked wrong one?
<holo[m]>
* sure working or i picked wrong one and there is some better choice?
thumbcore[m] has joined #rust-embedded
<thumbcore[m]>
<farooqkz> "I will get a better one later" <- Maybe you could check if your local Library or maker space has a soldering iron you could use. That way you could practice without buying one.
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
ijager[m] has quit [Quit: Idle timeout reached: 172800s]
burrbull[m] has joined #rust-embedded
<burrbull[m]>
<holo[m]> "Hey, flowing your advice i..." <- looks like "core" is absent. check what "target" is really used and install it with rustup
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
<holo[m]>
ok i didnt move .cargo/config.toml from my embassy project now it looks better but still getting core errors (but in much less amount)
<eZioPan[m]>
you may want to disable default feature of scd4x-rs
<eZioPan[m]>
its default feature seems depending on linux-embedded-hal
Farooq has joined #rust-embedded
<Farooq>
<thumbcore[m]> "Maybe you could check if your..." <- no such things here. I've got a better iron. The only thing left is a chisel
<Farooq>
Which should be one the way
<Farooq>
s/one/on/
<eZioPan[m]>
BTW, what kind of solder wire do you use?
<eZioPan[m]>
A "low temperature" solder wire can make things much easier. If you use a no-lead solder wire, it can be hard to solder by hand, since it requires much higher solder temperature.
<holo[m]>
<eZioPan[m]> "its default feature seems..." <- It helped, after fixing some other errors and warnings, left something like that:
<holo[m]>
ok i have something on osciloscope, need to play with it to find what it is
<holo[m]>
need to apply more time between commands to catch it one by one
<holo[m]>
any other possibility to catch what i want? "single seq" option will catch only first and if i dont have enought time to push it again im loosing next readings
starblue has quit [Quit: WeeChat 3.8]
<eZioPan[m]>
maybe find a button labeled "acquire " or something similar
<eZioPan[m]>
There should be some batch acquiring setting?
IlPalazzo-ojiisa has quit [Ping timeout: 256 seconds]
<holo[m]>
im not seeing there any option to record this
<holo[m]>
but anyway i just added that time between commands and it looks like
<holo[m]>
samtimes sequence even will go to reading but then data is degraded
<holo[m]>
at least my osciloscope can not read it
<holo[m]>
but i do not have such problem with my code with "vanilla" embassy
<holo[m]>
s/samtimes/sometimes/
<holo[m]>
yay its working
<holo[m]>
i removed wakeup
<holo[m]>
from the lists of commands
<holo[m]>
but still dont know why my osciloscope not decoding all commands properly
<holo[m]>
its not happenieng on my code, but anyway its working, i see even temperature more accurate to what is reaaly in room
<holo[m]>
yep wakeup command was problematic, im guessing when i flash sensor its already waked up so its not needed
<holo[m]>
* not needed only when sensor is starting by itself with controller
<holo[m]>
eZio Pan: Thank you for helping me with it!
<holo[m]>
One more question do you recomend some login analyzer working under linux? Because this decoding option in my oscilloscope is not too good. Or maybe some other device for such decoding things will be better?
<holo[m]>
s/login/logic/
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<eZioPan[m]>
any analyzer work with PulseView should work on Linux
<eZioPan[m]>
analyzer capture speed should be 5 times above your max signal speed to get stable result
<eZioPan[m]>
and I would recommend not to modify your tools(eg. your oscilloscope), unless you got another backup
IlPalazzo-ojiisa has joined #rust-embedded
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
Shell has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
Shell has joined #rust-embedded
starblue has joined #rust-embedded
<Lumpio[m]>
<holo[m]> "any other possibility to catch..." <- The feature to do multiple captures of events with time inbetween can be called "segmented memory" or "record" or something similar - maybe check the manual for your scope
<Lumpio[m]>
Not all scopes have that though.
jessebraham[m] has quit [Quit: Idle timeout reached: 172800s]
<AdamHott[m]>
I've been working in PCB Editor for quite some hours now, ran the DRC and receive a warning on all of my GND Vias. Wondered what's up with that. Also, I tried to create a GND Via for Pin 5 on the USB, and got an error that says "The routing start point violates DRC"? Would anyone mind taking a look? I'm very close now! https://github.com/CodingInGreen/project_green_storm/blob/master/DRC_Warnings/DRC_Warnings.png
<holo[m]>
<Lumpio[m]> "The feature to do multiple..." <- Thanks for name of feature i will check it. I but i didnt saw anything like that when i was playing with it
<holo[m]>
even decoding feature which i have is limited only to one catch on screen, to see more data which is behind i need to move horizontal position and recap signal again
<holo[m]>
so doubt it have recording
<Lumpio[m]>
<AdamHott[m]> "I've been working in PCB..." <- Do you have a hidden ground plane? Many of those vias don't seem to connect to anything
vaknin[m] has quit [Quit: Idle timeout reached: 172800s]
<Lumpio[m]>
I think you meant to have a ground plane on the bottom layer. You'll have to add it manually.
<AdamHott[m]>
Yep, I have a ground plane!
<AdamHott[m]>
Do I need to select an option to get those vias connected to the ground plane?
<Lumpio[m]>
They need to be connected to the GND net. That should be automatic if you put them down after the plane. Otherwise gotta edit the properties (or probably faster to just delete and replace)
<Lumpio[m]>
Oh and do make sure your ground plane is also assigned to the GND net
huszty[m] has joined #rust-embedded
<huszty[m]>
Hi! I am working with an STM32H7 board (a Daisy seed audio dev board) and I ran out of internal flash space (it is only 128k). I cannot further optimize the compilation and the project is still far from completion. The board has an 8M QSPI flash, so I wonder if there is any existing solution in the embedded rust ecosystem to program it directly and run the firmware from there.
<Lumpio[m]>
Hmm I don't think the default linker script is made for using XIP flash so you might have to tweak it huszty
<thejpster[m]>
huszty: which programmer are you using? It probably doesn't know how to erase and write to external flash? Also, can your STM32H7 boot from external flash or can it only boot from internal flash?
<Lumpio[m]>
Or maybe you could assign the entire FLASH region to external flash and then assign only the setup code for XIP to the real flash, I dunno. You also need some way to update that external flash mind you.
<Lumpio[m]>
s/real/internal/
<AdamHott[m]>
<Lumpio[m]> "Do you have a hidden ground..." <- Wait, if I make all other layers invisible other than B.Fu, I don't see my ground plane, is that where it should be?
<Lumpio[m]>
AdamHott[m]: B.Cu? I think that's (the blue layer) where it should be judging by your picture. Make sure you haven't hidden all planes too.
<AdamHott[m]>
Lumpio[m]: Yes that's the B.Cu layer
<thejpster[m]>
OK, it needs a bootloader (the ROM can't do it). You could ask in #stm32-rs:matrix.org but personally I've never needed external flash on an STM32. They do parts with *loads* of flash so I just pick those!
<thejpster[m]>
What software are you driving the ST-Link with? probe-rs-cli? openocd?
crabbedhaloablut has quit []
<Lumpio->
I've never seen anything that actually needs XIP for code on STM32 either...
<Lumpio->
Just out of interest what is this 128kB of code doing? If it all code?
<huszty[m]>
I cannot change the MCU unfortunately, this is a ready-made board 🤷♂️
<huszty[m]>
I use probe-rs at the moment with vs-code
<Lumpio->
It's probably less of a hassle to put data in external flash if some of that is data and not code
<thejpster[m]>
OK, you could ask the #probe-rs:matrix.org people whether they support programming external flash on the STM32.
<huszty[m]>
I am just learning how to determine what consumes the flash with cargo bloat, but nothing obvious is taking a lot...
<thejpster[m]>
if it doesn't, I would write a bootloader for the STM32 that I could talk to over USB Serial or UART and I would have the bootloader erase and write external flash for me, and jump to a valid application if it finds one.
<huszty[m]>
how I can find out if hard-float is used? (sorry for the dumb questions :) )
<thejpster[m]>
what is your --target xxx?
<thejpster[m]>
It will either use -eabi or -eabihf
<huszty[m]>
thumbv7em-none-eabihf
<huszty[m]>
yep, hf
<thejpster[m]>
and if you need to squeeze out more space, you could try LTO
<thejpster[m]>
and you should use the release profile, unless you really want the debug asserts included
<firefrommoonligh>
<thejpster[m]> "OK, it needs a bootloader (the..." <- > <@thejpster:matrix.org> OK, it needs a bootloader (the ROM can't do it). You could ask in #stm32-rs:matrix.org but personally I've never needed external flash on an STM32. They do parts with *loads* of flash so I just pick those!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WicFolyNdAEvNbbzuboJittg>)
<firefrommoonligh>
Could you confirm the opt level used? You can make the bin size much smaller by changing it
<huszty[m]>
opt-level is set to "s"
<thejpster[m]>
"z" is currently broken if you use LTO, but if you don't use LTO you could try it
<huszty[m]>
thejpster: with release (and very same cargo.toml flags) the size is ~10k smaller, so it actually fit for now :-) didn't know release build will be different with the exact same cargo.toml settings as dev
<thejpster[m]>
there's a bunch of stuff in libcore that is #[cfg(debug)]
<AdamHott[m]>
These yellow arrows are pointing at copper fill issues, any ideas on where the problem could be?
<AdamHott[m]>
I did the Ground copper fill correctly it looks like
<adamgreig[m]>
It looks like you wanted a copper pour for 3v3 but didn't assign it to the 3v3 net, so it's just floating unconnected copper
<adamgreig[m]>
But the arrows should have an accompanying error or warning that tells you what they are
<AdamHott[m]>
adamgreig[m]: Thanks, that solved it!
<huszty[m]>
<thejpster[m]> ""z" is currently broken if you..." <- Okay, I didn't realize that my release config had lto as well! So both release build and also LTO reduces the bin size with 10kB. At the moment this is enough to proceed.
<huszty[m]>
Thanks for the help guys! I hope writing a bootloader from 0 will not be part of this project, but in that case I will come back with more questions 😄
<AdamHott[m]>
If I've modified sections of a silkscreen layout for example a switch where the switch head extends beyond the board edge, and I removed the silkscreen elements that extend beyond the board edge, it's normal to get a warning about that not matching whats in the library, is that correct?
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
<adamgreig[m]>
Yea, that's normal
<AdamHott[m]>
ok thanks, all errors resolved thanks everyone!
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
notgull has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
example links in the readme don't work
<diondokter[m]>
<dirbaio[m]> "example links in the readme don..." <- Yeah, got an issue with that already. They do work on the GitHub page. Readme's in workspaces are awfull
<diondokter[m]>
Don't really know how to fix that without duplicating the readme
<dirbaio[m]>
use absolute urls
<dirbaio[m]>
it's a pain, but less bad than duplicating it
<dirbaio[m]>
interesting that relative urls somewhat work in crates.io though, I thought they'd completely break. wonder how that works