ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <rjmp> Actually, this is worse than I thought. Even if I do not take the TSC as an argument, there are linking problems that prevent two different versions of the PAC from linking:
<re_irc> warning: Linking globals named 'DEVICE_PERIPHERALS': symbol multiply defined!
<re_irc> error: failed to load bitcode of module "stm32f0-9c614b73ce91b0b9.stm32f0.38c6535e-cgu.0.rcgu.o":
<re_irc> So is it the case that there is no way for two different PACs to link? And if so, am I also right that there's no way for a crate to deconflict? Even if I set the dependency to "stm32f0 = "*"", cargo pulls the most recent, while "stm32f0xx-hal" depends on an older one.
<re_irc> <rjmp> The background is that I want to create a driver crate for the ST touch controller that works for various families, and provides a driver for the controller as well as some processing of capacitance for the interface elements. So, it needs to use a PAC. I can select which pac (e.g. "stm32f0" or "stm32f3") by features, but I can't find anyway to tolerate changes in version of the pac used by the application....
<re_irc> <rjmp> I wonder if perhaps the definition of DEVICE_PERIPHERALS should be gated by the "rt" feature. That makes creating a peripheral driver in a crate at least _possible_. Ideally, the RegisterBlock would be provided to the crate driver just like to HAL drivers, but that truly does require a way to ensure the crate and app are using the same PAC version, I think.
dc740 has quit [Remote host closed the connection]
conplan has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<conplan> does anyone know what _stack_end_cpu0 means for an ESP32?
<conplan> I am trying to write code for the esp32
<Darius> does it print anything else?
<Darius> looking at https://github.com/esp-rs/esp32-hal/blob/master/memory.x suggests _stack_start_cpu0 is just a symbol defined in the linker map
<Darius> presumably the memory dedicated to CPU0
<Darius> (for stack)
<conplan> Darius: no
<Darius> what sort of code? have you done a hello world?
<conplan> it doesn't print anythint else. it just prints a memory address next to it and ??:?? out
<Darius> what toolchain? do you have a debugger?
<Darius> so t DOES print something else
<Darius> pastebin the exact text
<conplan> I guess? I'm not sure how useful it is
<Darius> it's not exactly voluminous so there is no harm in posting it
<conplan> here is the paste of the output of espflash
<conplan> Darius: ^
<Darius> conplan: what sort of program are you writing?
<conplan> LED blinker
<Darius> what sort of toolchain etc?
<Darius> https://esp-rs.github.io/book/ looks useful
<conplan> I'm using the esp toolchain installed with esp-pup
<conplan> It's exactly as stated in esp-rs
<Darius> dunno then sorry
<Darius> check you have exactly the correct CPU etc..
<conplan> can you elaborate on this point? are there multiple cpus for the ESP32-WROOM-32E?
<re_irc> <rjmp> I'm guessing a lot here as I've never used the esp toolchain at all, but is it at least possible that everything printed there is part of a normal programming and now your program is running? It's not clear to me if that output is an error or just a cryptic log of programming the code. It's possible it's programmed correctly but for some reason not blinking the LED
<conplan> I thought it was just a stock ESP32
<conplan> I find that unlikely, because there is no blinking LED.
<re_irc> <rjmp> I'm just suggesting not to get too hyperfocused on the log output there. Could be something as simple as not enabling a GPIO as output, having a loop {} before the LED blink...I dunno there's all kinds of ways to write programs intended to blink an LED but that actually don't :)
<conplan> rjmp: I appreciate that; its certainly good advice.
<conplan> I also haven't been able to get esp_println to work
<re_irc> <rjmp> I don't know...since you are getting output there, I guess you would get some output on a panic?
<re_irc> <rjmp> Could test by forcing a panic right away
<conplan> yeah, can confirm... it's not the program.. I can't even set the LED low
<conplan> rjmp: how to do this?
<re_irc> <rjmp> "panic!("I'm failing!");"
<re_irc> <rjmp> Of course, maybe it is in fact never loading or booting properly. Sorry I can't really help with that, I'm not at all familiar with the platfomr.
<re_irc> <rjmp> But good luck!
<conplan> okay, I force a panic. It worked, but before it said that, it gave a _stack_end_cpu0 error...
<conplan> so it may be generic output
<re_irc> <rjmp> I don't think a _stack_end_cpu0 error is a thing
<re_irc> <rjmp> I _suspect_ that when it prints, e.g. `load:0x40078000,len:17448
<re_irc> 0x40078000 - _stack_end_cpu0, that is because it is loading code between the address 0x4007800 and _stack_end_cpu0
<re_irc> <rjmp> You're saying when you add the panic! line, you get the message out?
<conplan> didn't get the message in the panic, it simply paniced
<conplan> *panicked?
<conplan> here is my code -> https://pastebin.com/Ve60uBJ2
<conplan> if you spot anything obvious tell me
<re_irc> <rjmp> No sorry, nothing jumps out at me. You are sure the LED is wired to GPIO15 I presume?
<re_irc> <rjmp> (and has power, with a sensible current limiting resistor etc).
<conplan> Not entirely... that was what was used in the example... Do you know of an ESP32-WROOM-32E pinout? I've had trouble finding one
<re_irc> <rjmp> I don't think the module comes with an LED?
<re_irc> <rjmp> So it depends on what it's mounted on
<re_irc> <rjmp> This is the datasheet for the module: https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf. But I'm guessing you have some carrier board which has that module on it? So you'd have to look at the docs for the carrier board to figure out if there is an LED and if so, which pin it connects to.
<conplan> OKAY!!! ITS WORKING!!!
<conplan> thanks guys for the help. Especially to ou rjmp. you turned out to be right
<re_irc> <rjmp> Congrats. Glad I could help reach the first blink milestone.
<conplan> do atomics work with the ESP32
<re_irc> <sydbayeck> How could I use LED as light sensor on microbit-v2? The hardware overview page of micro:bit say : "This LED matrix is also used to sense ambient light, by repeatedly switching some of the LED drive pins into inputs and sampling the voltage decay time, which is roughly proportional to ambient light levels." I can't figure out how to measure "the voltage decay time".
<Darius> I think that output is rfom the ESP bootloader BTW
<Darius> and by CPU check I mean make certain you are compiling for the one you have
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
genpaku has quit [Remote host closed the connection]
genpaku has joined #rust-embedded
<re_irc> <sydbayeck> rtt_init_print!();
<re_irc> let board = Board::take().unwrap();
<re_irc> let mut column1 = board.display_pins.col1.into_floating_input();
<re_irc> let saadc_config = SaadcConfig::default();
<re_irc> <sydbayeck> God, just using a display pin as a SAADC pin.
<re_irc> <sydbayeck> rtt_init_print!();
<re_irc> let mut column1 = board.display_pins.col1.into_floating_input();
<re_irc> let board = Board::take().unwrap();
<re_irc> let saadc_config = SaadcConfig::default();
<re_irc> <sydbayeck> fn main() -> ! {
<re_irc> rtt_init_print!();
<re_irc> let mut column1 = board.display_pins.col1.into_floating_input();
<re_irc> let board = Board::take().unwrap();
causal has quit [Quit: WeeChat 3.7.1]
steew has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc> < (@firefrommoonlight:matrix.org)> Does anyone have recommendations for learning Postcard syntax and capes? No ex folder on GH. Readme/Docs page shows byte arrays, String use. I'm curious how it works with options, enums, floats etc. As well as using arrays vice headless or alloc Vec
<re_irc> < (@firefrommoonlight:matrix.org)> (I assume to use arrays you'd modify the example to use .to_slice vice .to_vec)
<re_irc> < (@firefrommoonlight:matrix.org)> Does anyone have recommendations for learning Postcard syntax and capabilities? The readme and docs page shows byte arrays, String use. I'm curious how it works with options, enums, floats etc. As well as using arrays vice headless or alloc Vec
<re_irc> < (@firefrommoonlight:matrix.org)> Does anyone have recommendations for learning Postcard syntax and capabilities? The readme and docs page shows byte arrays, and String use. I'm curious how it works with options, enums, floats etc. As well as using arrays vice headless or alloc Vec
dc740 has joined #rust-embedded
conplan has quit [Remote host closed the connection]
<re_irc> < (@firefrommoonlight:matrix.org)> Does anyone have recommendations for learning Postcard syntax and capabilities? The readme and docs page shows byte arrays, and String use. I'm curious how it works with options, enums, floats etc. As well as using arrays, vice heapless or alloc Vec
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
seer has quit [Quit: quit]
seer has joined #rust-embedded
conplan has joined #rust-embedded
dequbed has quit [Quit: bye!]
conplan has quit [Quit: Leaving.]
conplan has joined #rust-embedded
conplan has quit [Remote host closed the connection]
<re_irc> <Crylo (he/they)> i got a microbit for my hs python programming class
<re_irc> <Crylo (he/they)> which is great because i can turn around and also learn rust with it once the semester is over
<re_irc> < (@jamesmunns:beeper.com)> : happy to answer questions, but it works with pretty much any data type.
<re_irc> It's not really a "syntax", you define some Rust data type, and then it can be serialized.
<re_irc> < (@jamesmunns:beeper.com)> There's also a lot of tests which show serialization of a bunch of data: https://github.com/jamesmunns/postcard/blob/56d0a58bcfebe8e80db9920410ea6036c3cab32f/src/ser/mod.rs#L279-L611
<re_irc> < (@jamesmunns:beeper.com)> conceptually, it takes any rust data type that impls Serialize (usually a top level struct that has all the fields you care about, which each all impl serialize), and you pick the method that matches your intended "destination".
<re_irc> "to_slice" will take a slice, and give you back the sub-slice that contains the serialized bytes (like you give it a 128 byte buffer, and if it took 73 bytes to serialize, it'll give you back a subslice of those 73 bytes)
<re_irc> "to_stdvec" or "to_vec" will give you an "alloc::Vec" or "heapless::Vec"
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc> < (@firefrommoonlight:matrix.org)> : Sweet; thank you!
<re_irc> < (@firefrommoonlight:matrix.org)> How does it handle "Option"? Prepend/postpend 1/0 byte? Some type of tighter packing? Thank you
<re_irc> < (@jamesmunns:beeper.com)> Whole wire spec is here, by type: https://postcard.jamesmunns.com/wire-format.html