ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
aspe has quit [Quit: aspe]
causal has quit [Quit: WeeChat 3.5]
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #rust-embedded
<re_irc> <Clark Kozak> I'm starting to play around with a breadboard and I'm wondering what are common components that I'd need. I got an LED to light up and it came with the resistor I needed. Now I want to add a button and i'm unsure if I need a different type of resistor
<re_irc> <ian_rees> hi clarkkozak! Most microcontrollers have an internal resistor that can be configured to "pull up" or "pull down" a GPIO pin that's configured as an input. Is this still using the micro::bit?
<re_irc> <ian_rees> so, often you'd have a GPIO configured as input with pull-up, and the button would go between the GPIO pin and ground. If input reads as 1 then the button is released, if it's 0 then it's pressed
<re_irc> <ian_rees> however, there is a complication: the physical contacts in the switch often don't cleanly transition between "open" and "closed" on the timescale that the microcontroller works at, so you need to "debounce" the signal from the switch. There are a number of different approaches for that
<re_irc> <Clark Kozak> ian_rees: Well I wanted to use a basic switch to power an LED first tho if the microbit has what I need than sounds perfect :D
<re_irc> <Clark Kozak> ian_rees: Fascinating! I'll try one of the examples tomorrow
<re_irc> <ian_rees> ah, cool, so the switch can go anywhere "in series" with the LED circuit. Electrically, it's doing the same thing as plugging/unplugging any of the connections in your LED circuit
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
explore has joined #rust-embedded
<re_irc> ESP32-C5 has released, it has 2.4/5GHz Wi-Fi 6 peripheral and is powered by RISC-V
<re_irc> <luojia65> * 6, BLE 5,
aspe has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<re_irc> <TimSmall> ian_rees: Probably best to learn about LEDs and current limiting resistors if you don't know about that already... Micro-controller pins have a maximum allowable current specified by the manufacturer, and if you exceed that limit, then physical damage can occur to the chip (usually limited to just the drive transistors in the pin that it overloaded, but best not to go there). You'll find a few good explainers online...
<re_irc> ... (e.g. something like: "arduino microcontroller led drive pin current maximum limit resistor tutorial" might be a good thing to put into a search engine).
aspe has quit [Quit: aspe]
dc740 has joined #rust-embedded
Abhishek_ has joined #rust-embedded
<re_irc> <justacec> I have been doing some looking on how to accurately track the time since a device was powered on. So far I have seen "embedded_time" discussions, "chrono" discussions, and the "SysTick" timer. What is the best way (most efficient from a time/power perspective) to track this. Right now I was starting down the "chrono" path, but realized that all I really need to know is linear time from a single epoch (power on). What...
<re_irc> ... are peoples thoughts on this?
<re_irc> <justacec> I am specifically using an STM32WLXX series MCU
causal has joined #rust-embedded
<re_irc> <chemicstry> well, embedded_time and chrono are just representation layers of time, not related to hardware, which is what you seem to be asking. Your options depend on precision and power requirements. If you need high resolution (<1us) then your best bet are general purpose timers. Systick is similar to general purpose timers, but is very limited in configuration. If you want low power then look at RTC peripheral.
<re_irc> <justacec> I saw the RTC in there, but saw that it basically required that I enable the "chrono" package.
<re_irc> <justacec> I currently have that enabled, but was concerned about using that do only store durations (from a fixed time epoch that I set on the device)
<re_irc> <firefrommoonlight> I concur that there are multiple valid ways to do this, but RTC is most appropriate
<re_irc> <justacec> I am looking for 1e-6 subsecond resolution.
<re_irc> <justacec> So, I want to store the number of seconds plus the number of 1e-6 seconds
<re_irc> <firefrommoonlight> since the others are designed more for short term counting, while the RTC is designed for long term. Easier to set up in software too if you're not using it for anything else, since you can start it on program start, and simply read the time
<re_irc> <firefrommoonlight> Btw - I'm very finicky about dependencies, but chrono with standard features disabled is tiny
<re_irc> <firefrommoonlight> Chrono is the nicest datetime lib I've encountered in any programming language, FWIW
<re_irc> <firefrommoonlight> Its date and time types are simple copy types without much bullshit attached
<re_irc> <justacec> ok. So seems that general consensus is: Use the RTC and the "chrono" API. Then when I read my data, just assign a custom struct which hold the number of seconds in a u16 and then the number of 1e-6 seconds in a seperate variable (i guess u32). that would give me about 8 hours of differentiable time with the desired resolution.
<re_irc> <firefrommoonlight> I think its dates for example, are stored as a wrapped "i32"!
<re_irc> <firefrommoonlight> its time is 2 u32s
<re_irc> <justacec> So I can just set the calendar to some silly date like 1970-01-01 00:00:00 and then just grab an instant and derive the duration from that.
<re_irc> <chemicstry> don't make you life harder, just store as microseconds in u64 if you don't want to use any time lib
<re_irc> <firefrommoonlight> Yes
<re_irc> <justacec> Well, that is what I was thinking. In the past I have used a GP timer which incremented a counter. I just read time by reading the number of overruns (tracked by the counter) and then the timer's current value. Is this the better approach? (for my case?)
<re_irc> <firefrommoonlight> You could do that too
<re_irc> <chemicstry> for monotonic timer I think it makes more sense, RTC is generally designed to work with date+time. But then if you do deep sleep to save power, check how many uA's are consumed by GPT vs RTC
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc> <justacec> Humm, the datasheet states that the RTCAPB pulls 2.08 uA/MHz at full and then 1.50 uA/MHz during LPSleep. The TIM17 peripheral would pull 2.29 and 1.25 respectively for those same power levels.
<re_irc> <firefrommoonlight> This is a follow-your-heart scenario
<re_irc> <firefrommoonlight> praise the bounty of timing sources on stm32
<re_irc> <chemicstry> keep in mind that with TIM17 you will also have HSE oscillator (or HSI), PLL, various APB buses running, which will add to consumption
<re_irc> <adamgreig> justacec: I'd plan to use the time crate instead of chrono these days, time is the basic date time api that latest chrono exports aiui
<re_irc> <dirbaio> if you just want to track time-since-boot, maybe it's easier to use a LPTIM instead of RTC
<re_irc> <Clark Kozak> TimSmall: Something like this: ?
iyedonhismed has joined #rust-embedded
iyedonhismed has quit [Client Quit]
iyedonhismed has joined #rust-embedded
iyedonhismed has quit [Client Quit]
aspe has joined #rust-embedded
aspe has quit [Quit: aspe]
creich has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Remote host closed the connection]
creich has quit [Quit: Leaving]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
explore has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
nort has quit [Ping timeout: 246 seconds]