<firefrommoonligh>
I think a side effect of remove LSE is you lose the ability to calibrate (or one way of calibrating?) other internal oscillators; which I haven't been doing anyway
<therealprof[m]>
I haven't seen that capability yet. Which chips support that?
<adamgreig-m>
most stm32s have a timer or two connected to the clock sources as mux options, e.g. stm32f405 can have lse/lsi/hse/hsi feed tim5 or tim11
<firefrommoonligh>
I'd have to look, but IIRC it's what adamgreig said: Ie many support it
<adamgreig-m>
and then the HSI can often be adjusted
<adamgreig-m>
not sure I've ever bothered fitting an LSE
<firefrommoonligh>
So, this also lets you use USB with an LSE, but not HSE
<firefrommoonligh>
hah. I think I'm going to remove it from this design. Now
<therealprof[m]>
adamgreig: Interesting. But yeah, the LSE needs to have significantly better accuracy (magnitudes) to make calibration of HSI even possible.
<adamgreig-m>
dirbaio: if you want a real trip, check out the J at the end of e.g. stm32f205vgt6j
<therealprof[m]>
<adamgreig-m "I would expect LSI to be lower p"> I'd be surprised. Internally they can finetune the loading of the oscillator perfectly.
<adamgreig-m>
that's what I'm saying, the internal one would be lower power
<firefrommoonligh>
Ok, LSE extricated from this design
<adamgreig-m>
on the P and Q options: having VCAP/VDD12 exposed lets you use an off-chip regulator for the core voltage, bypassing the usual built-in LDO, so you can be more efficient, and the Q version has an SMPS as well as an LDO so you can just fit an inductor and use it to run the core instead of putting a separate smps on
<therealprof[m]>
<adamgreig-m "that's what I'm saying, the inte"> Oh sorry, I misread that.
<adamgreig-m>
also the internal is likely an RC oscillator and the external needs to drive a quartz crystal
<dirbaio[m]>
<adamgreig-m "dirbaio: if you want a real trip"> what is it? it's not in the XMLs
<adamgreig-m>
it seems to be out of stock everywhere, perhaps they bought them all and put them in a huge pit in the ground and burnt them
<adamgreig-m>
can't even find a datasheet that talks about them any more, though farnell and mouser still have out-of-stock product listings
<dirbaio[m]>
the fuck, seems mega cursed
<therealprof[m]>
The main benefit of the external LSE is really high accuracy if you need to run off the RTC for a long time without capitally drifting...
<firefrommoonligh>
That makes sense. I have a different project where that would be important
<adamgreig-m>
dirbaio: anyway, they embedded Java
<adamgreig-m>
that's what the J stands for
<therealprof[m]>
E.g. if you have "old school" devices without ability to get the current time via network.
<dirbaio[m]>
what? like a custom hardware core that runs Java bytecode? or a JVM firmware preflashed?
<therealprof[m]>
<therealprof[m] "E.g. if you have "old school" de"> Or frequently enough. Bad LSIs can easily drift many seconds per day.
<adamgreig-m>
they were ashamed enough to not renew the domain name
<adamgreig-m>
and -U parts were embedded java but for prototyping instead of production
<dirbaio[m]>
wooow :D
<dirbaio[m]>
> STMicroelectronics will create other J part numbers on demand: refer to ST local sales office or distributor.
<dirbaio[m]>
seems like preflashed FW..?
<adamgreig-m>
it seems like it's all gone now, but you can see that they had cursed documents like "STM32Java UI Reference Manual for STM32 F4"
<adamgreig-m>
preflashed FW makes zero sense because you still load the appication firmware over the debug interface
<adamgreig-m>
I think it was actually a licence thing
<adamgreig-m>
the J parts had a license for the embedded JVM they used
<adamgreig-m>
I was never brave enough to buy one back when they were in production
<dirbaio[m]>
wow, very strange
<adamgreig-m>
I mean the good news is you can defo ignore it but I thought you'd enjoy one more stupid suffix
<dirbaio[m]>
I hadn't even found it since it's not in the XMLs
<adamgreig-m>
a bunch of the -A parts are documented as being identical and it's an "internal code"
<adamgreig-m>
not a die bump since that's tracked separately, so I guess it's either a bigger redesign or a different fab process or something
<adamgreig-m>
automotive people care a lot about these kinda stupid details, probably a lot of people have qualified the original stm32f103 and want to only get that same original
<therealprof[m]>
Yeah. They could also be especially binned parts for certain sectors.
<adamgreig-m>
yea, though they are generally available for sale from digikey without any extra qualifiers as to what it means, they just say they're identical iirc
<therealprof[m]>
From a peripheral software perspective I'd treat everything with the same die as identical.
<adamgreig-m>
well, maybe, depends if you want to care about pinouts and available pins and so on too
<therealprof[m]>
Fusing a whole peripheral would cost a ton of money and anything else is not going to make any difference.
<adamgreig-m>
agreed that identical die means the same firmware will do basically the same thing
<adamgreig-m>
no point fusing off a peripheral for sure
<adamgreig-m>
same die in diff package has diff stuff available, so if you want to track that, it mattes
<therealprof[m]>
Well, but even if the pin is not bonded you could still use it for some purposes.
<therealprof[m]>
You just can't connect to them externally.
<adamgreig-m>
sure
<adamgreig-m>
oh, interesting, the A suffix means the low-density part in question has the same electrical characteristics as a medium-density part
<adamgreig-m>
which almost surely means it also has loads of extra flash and ram, lol
<adamgreig-m>
back in the bad old days ST categorised f1/f2 as 'low density', 'medium density', and 'high density' and it's kinda stupid
<adamgreig-m>
so low density had less flash and ram but also fewer peripherals
<dirbaio[m]>
the only important "fuckyou letter" difference I've found is in stm32l1
<dirbaio[m]>
STM32L151CBTx -> STM32L151CBTxA
<dirbaio[m]>
and others
<adamgreig-m>
like a low density f103 has fewer periphs than a high density f103, they stopped that shit later
<dirbaio[m]>
these even have different C headers
<adamgreig-m>
that's pretty bad, wonder what happened
<dirbaio[m]>
all other "fuckyou letters" are ignorable for PAC purposes
<dirbaio[m]>
at least the ones in XMLs
<dirbaio[m]>
I hope there's no fuckyou letters that matter that are not in the XMLs, that'd be horrible
<dirbaio[m]>
the Java J's aren't in the XMLs, the stm32f103c6t7a you mentioned isn't either
<adamgreig-m>
anyway you can't buy the Js any more and I assume anyone with one wouldn't be interested in running rust on it almost by definition
<dirbaio[m]>
and hardware is probably identical since they can "create other J part numbers on demand" 🕹️
<dirbaio[m]>
* and hardware is probably identical since they can "create other J part numbers on demand" 😂
<dirbaio[m]>
bingo, found another: stm32g0x1xx-N adds USB PD 💩
<dirbaio[m]>
mapping model names to C headers sucks 🤣
<dirbaio[m]>
for example STM32F101RF uses STM32F101xG.h 🤷♂️
<dirbaio[m]>
the reason the PACs are split by family (stm32f1, stm32f3, stm32f4...) is because the crates.io size limit?
<dirbaio[m]>
i've deduplicated packages for the same chip (so now there's one yaml per chip, not per package)
<dirbaio[m]>
and just the yamls is 7.8mb, rust code will likely be somewhat bigger, and crates.io size limit is 10mb :S
<thalesfragoso[m]>
you won't need the yamls to compile it, no ? You can just ignore them in Cargo.toml
<therealprof[m]>
<dirbaio[m] "bingo, found another: stm32g0x1x"> Are you sure? USB PD doesn't mean anything really other than the ability to currectly speak the protocol on the CC lines (which even an STM32F0 can do without problem and mentioning of PD anywhere on the datasheet or manual).
<therealprof[m]>
> <@dirbaio:matrix.org> bingo, found another: stm32g0x1xx-N adds USB PD 💩
<therealprof[m]>
* Are you sure? USB PD doesn't mean anything really other than the ability to correctly speak the protocol on the CC lines (which even an STM32F0 can do without problem and mentioning of PD anywhere on the datasheet or manual).
<adamgreig-m>
<therealprof[m] "Are you sure? USB PD doesn't mea"> Loads of newer stm32s have a pd peripheral, you need specific voltage comparators and specific pull up and pull down resistances, and it handles the BMC coding
<adamgreig-m>
Maybe you could do it with some external hardware and gpio but it would be way more work
<adamgreig-m>
<dirbaio[m] "the reason the PACs are split by"> Yes but note it's a 10mb size limit on the zipped .crate file, not uncompressed
<therealprof[m]>
Yes, indeed a built-in PD peripheral simplifies a lot of things. The difference of the N version is almost certainly just a different pinout...
<therealprof[m]>
Yepp, that's it. They're sacrificing a Wakeup pin and an ADC pin for the CC pins on the smaller packages.
<peauters[m]>
ignore me, I think I need to upgrade to 0.9.0
<peauters[m]>
apologies for rubber ducking =o)
oaky has joined ##stm32-rs
<oaky>
I recently got a STM32 Nucleo F091RC, trying to figure out how to send data from the microcontroller to my computer via USB, and display it in STM32CubeIDE, is this possible or do I need converters and such?
<henrik_alser[m]>
Is it for debugging via the onboard st-link or actual USB to the chip via something like an emulated serial port?
<henrik_alser[m]>
(Not sure the 091 has USB?)
<henrik_alser[m]>
If not i’d say your best choice would be to go with some ftdi chip that can do for example usb->uart
<henrik_alser[m]>
(Or spi or whatever)
<oaky>
Ok, I'm completely new to this and not really familiar with the different interface to be honest
<oaky>
But so the F091RC doesn't know how to communicate with the USB protocol, so I need to get an USB to UART converter, because the F091RC speaks UART but not USB?
<henrik_alser[m]>
Ahh welcome :) Yes exactly... or if you just want to be able to print stuff to a console during development, while you have your debug probe (st-link onboard your nucleo) attached i suggest you use for example rtt via probe-run
<oaky>
Thank you :)
<oaky>
I'm mainly looking to send data from the STM32 to my computer, so that I can read variables etc
<oaky>
Nope I haven't read it, I have coded in C and C++ before so it's not an issue programming in C, is there a particular reason to using Rust?
<TimSmall>
oaky: The language semantics allow for a lot of compile-time checking, which makes it much easier to write error free code, whilst also being roughly as performant as C. You also get a lot of high level language features which aren't present in C (and to some extent also missing from C++).
<TimSmall>
oaky: In particular it makes things like event driven interrupt oriented programming much more ergonomic and practical.
<henrik_alser[m]>
Ahh i thought you were getting into embedded Rust specifically (this channel is all about using Rust on stm32, thats the ”-rs” suffix :)) But yes, what TimSmall said... i made the switch from C/C++ a cpl years ago and never looked back, everything about this is so much nicer imo, the language, the tooling and not least the community
<oaky>
TimSmall: Ah okey, interesting. I should read up on it
<oaky>
henrik_alser[m]: Ah hehe, was curious what the -rs stood for :p Sound very promising so I'll keep it in mind
<oaky>
TimSmall: Nice, I've put it on my watch list
<henrik_alser[m]>
Try it! It might be a little frustrating at first because the compiler will check your every move and won’t let you get away with doing stuff that you shouldn’t be doing. So just remember it’s your best friend :) We’re many here willing to help if you get stuck, also check the Rust-embedded Matrix channel
<TimSmall>
#rust-embedded:matrix.org
<TimSmall>
... also mirrored to freenode.
<oaky>
Nice, thanks for the pleasant welcome :) I'm a bit overwhelmed with all the different things at the moment, just the STM32CubeIDE is so full of things which I don't understand. So don't know whether it's good to introduce yet another thing right now. I assume I would have to use a different toolchain to use Rust?
<TimSmall>
In general you'd not use the STM32CubeIDE at all. Just your favourite editor, or IDE (many people use Visual Studio Code), and the rust toolchain (which is pretty easy to install).
<TimSmall>
What coding environment do you usually use?
<henrik_alser[m]>
The rust toolchain is much easier to get up and running in my experience and you can just use your ide of choice, together with rust-analyzer
<oaky>
TimSmall: I'm in university right now and so far (and before university) I've mainly just used a simple text editor (sublime text), and only used an IDE when the project has been complicated enough that an IDE actually provided benefit.
<oaky>
TimSmall: I like to keep things simple and not bloated with things I never use
<oaky>
Have used Visual Studio Code a bit
<oaky>
henrik_alser[m]: sounds promising, and is uploading code also straight forward?
<TimSmall>
OK, me too (my editor is vim). You may want to use https://github.com/sublimelsp/LSP (or other LSP option is there is one, I'm not too familiar with sublimetext), together with rust-analyzer.
<TimSmall>
(rust-analyzer is an lsp server for the rust language).
<henrik_alser[m]>
<oaky "henrik_alser: sounds promising, "> Yes that’s one of the best parts, there’s a nice demonstration in the video i posted above
<TimSmall>
It'll give you syntax highlighting, variable completion, and various other IDE type features if you want to use them (go to definition, rename variable, syntax errors and tips).
<TimSmall>
... and more.
<TimSmall>
You don't need to use it to get started, but it will speed things up in general, and is really useful in my experience.
<henrik_alser[m]>
<oaky "Have used Visual Studio Code a b"> Yes VS code is a great fit too
<TimSmall>
... VS Code has an LSP client built in (it was the first implementation of LSP), and is also a reasonable option, but Rust isn't dictatorial about editors (so VSCode, Sublime Text, and vim will all give you roughly the same feature set when writing rust).
<oaky>
Alright I see
<oaky>
But so you would recommend going with Rust immediately and ditch the STM32CubeIDE?
<henrik_alser[m]>
Definately!
<oaky>
(as a beginner) that needs to get things done relatively quickly (not just doing it for the learning, it's a university project)
<oaky>
(for free-time learning*)
<oaky>
henrik_alser[m]: Alright, I'll start reading then :p
<oaky>
Something tells me that most jobs still require that you know C primarily right? Is Rust used in industry aswell?
<henrik_alser[m]>
Yes rust is still young and C isn’t going anywhere, but i think more and more companies are starting to look into rust
<henrik_alser[m]>
Learning rust will also make you a better C programmer :)
<firefrommoonligh>
For job peruposes, learn C. For personal projects or your own companies, use Rust if you like it
<oaky>
I see, ok
<henrik_alser[m]>
On the other hand, there’s already millions of C programmers out there and now that the big giants like Apple and Microsoft etc has started digging into Rust lately, i suspect there will be a big demand vs supply of Rust programmers in a few years
<henrik_alser[m]>
But yes C will probably always be in demand, if you can stand it
<henrik_alser[m]>
* But yes C will always be in demand, if you can stand it
<firefrommoonligh>
Hey dudes. Looking for wisdom on how internal pull ups (ie for I2C lines) work when the MCU is in `stop` mode. I'm attempting to implement this from a datasheet:
<firefrommoonligh>
````NOTE: In order to limit the current consumption to the typical 2.5μA Melexis recommends that the SCL pin is kept low during sleep as there is leakage current trough the internal synthesized zener diode connected to SCL pin. This may be achieved by configuring the MD driver of SCL pin as Push-Pull and not having Pull-Up resistor connected on SCL line.
<firefrommoonligh>
```
<firefrommoonligh>
* Hey dudes. Looking for wisdom on how internal pull ups (ie for I2C lines) work when the MCU is in `stop` mode. I'm attempting to implement this from a datasheet:
<firefrommoonligh>
> NOTE: In order to limit the current consumption to the typical 2.5μA Melexis recommends that the SCL pin is kept low during sleep as there is leakage current trough the internal synthesized zener diode connected to SCL pin. This may be achieved by configuring the MD driver of SCL pin as Push-Pull and not having Pull-Up resistor connected on SCL line.
<firefrommoonligh>
I put this device in `sleep` mode right before putting the MCU is in `stop` mode. So, my thought is yank the hardware PU on the SCL line (and keep it for the SDA line), then configure SCL from AF to Output, and set it low. When waking the MCU from stop, reconfigure SCL as AF4
<firefrommoonligh>
Would this work? My intuition says its fine, other than I don't know what the pull status will be when the MCU is in `stop`. Ie it might be floating?
<firefrommoonligh>
* I put this device in `sleep` mode right before putting the MCU is in `stop` mode. So, my thought is yank the hardware PU on the SCL line (and keep it for the SDA line), enable software pullup for it normally. Before entering `stop`, configure SCL from AF to Output, and set it low. When waking the MCU from stop, reconfigure SCL as AF4
<firefrommoonligh>
Ie this would be straightfwd to do when sleeping the sensor, but `stop`ing the MCU at the same time makes me confused