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
dne has quit [*.net *.split]
kenny has quit [*.net *.split]
jr-oss has quit [*.net *.split]
hifi has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
dreamcat4 has joined #rust-embedded
jr-oss has joined #rust-embedded
hifi has joined #rust-embedded
kenny has joined #rust-embedded
dne has joined #rust-embedded
Socke has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit []
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
Socke has quit [Ping timeout: 246 seconds]
Socke has joined #rust-embedded
<re_irc> <@phaseonx11:matrix.org> Hello! Complete noob here...I just got an ESP32 on a micromod board (https://cdn.sparkfun.com/assets/learn_tutorials/1/2/0/8/MicroModESP32ProcessorBoard_a.pdf) and this ssd1306 mini display. I'm trying to get the example on ESP32-HAL to work, as they have one with this particular config (MCU + display controller).
<re_irc> I can't for the life of me get this to work...I've read a ton of data sheets to sanity check whether I was using the right pins:
<re_irc> //! I2C Display example
<re_irc> //! This example prints some text on an SSD1306-based
<re_irc> //! display (via I2C)
<re_irc> //!
<re_irc> //!
<re_irc> //! The following wiring is assumed:
<re_irc> //! - SDA => GPIO32
<re_irc> //! - SCL => GPIO33
<re_irc> #![no_std]
<re_irc> #![no_main]
<re_irc> use embedded_graphics::{
<re_irc> mono_font::{
<re_irc> ascii::{FONT_6X10, FONT_9X18_BOLD},
<re_irc> MonoTextStyleBuilder,
<re_irc> },
<re_irc> pixelcolor::BinaryColor,
<re_irc> prelude::*,
<re_irc> text::{Alignment, Text},
<re_irc> };
<re_irc> use hal::{
<re_irc> clock::ClockControl,
<re_irc> gpio::IO,
<re_irc> i2c::I2C,
<re_irc> peripherals::Peripherals,
<re_irc> prelude::*,
<re_irc> timer::TimerGroup,
<re_irc> Rtc,
<Darius> use a pastebin site..
<re_irc> };
<re_irc> use esp_backtrace as _;
<re_irc> use nb::block;
<re_irc> use ssd1306::{prelude::*, I2CDisplayInterface, Ssd1306};
<re_irc> #[entry]
<re_irc> fn main() -> ! {
<re_irc> let peripherals = Peripherals::take();
<re_irc> let mut system = peripherals.DPORT.split();
<re_irc> let clocks = ClockControl::boot_defaults(system.clock_control).freeze();
<re_irc> let timer_group0 = TimerGroup::new(
<re_irc> peripherals.TIMG0,
<re_irc> &clocks,
<re_irc> &mut system.peripheral_clock_control,
<re_irc> );
<re_irc> let mut timer0 = timer_group0.timer0;
<re_irc> let mut wdt = timer_group0.wdt;
<re_irc> let mut rtc = Rtc::new(peripherals.RTC_CNTL);
<re_irc> // Disable watchdog timer
<re_irc> wdt.disable();
<re_irc> rtc.rwdt.disable();
<re_irc> let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);
<re_irc> // Create a new peripheral object with the described wiring
<re_irc> // and standard I2C clock speed
<re_irc> let i2c = I2C::new(
<re_irc> peripherals.I2C0,
<re_irc> io.pins.gpio22,
<re_irc> io.pins.gpio21,
<re_irc> 100u32.kHz(),
<re_irc> &mut system.peripheral_clock_control,
<re_irc> &clocks,
<re_irc> );
<re_irc> // Start timer (5 second interval)
<re_irc> timer0.start(5u64.secs());
<re_irc> // Initialize display
<re_irc> let interface = I2CDisplayInterface::new(i2c);
<re_irc> let mut display = Ssd1306::new(interface, DisplaySize128x64, DisplayRotation::Rotate0)
<re_irc> .into_buffered_graphics_mode();
<re_irc> display.init().unwrap();
<re_irc> // Specify different text styles
<re_irc> let text_style = MonoTextStyleBuilder::new()
<re_irc> .font(&FONT_6X10)
<re_irc> .text_color(BinaryColor::On)
<re_irc> .build();
<re_irc> let text_style_big = MonoTextStyleBuilder::new()
<re_irc> .font(&FONT_9X18_BOLD)
<re_irc> .text_color(BinaryColor::On)
<re_irc> .build();
<re_irc> loop {
<re_irc> // Fill display bufffer with a centered text with two lines (and two text
<re_irc> // styles)
<re_irc> Text::with_alignment(
<re_irc> "esp-hal",
<re_irc> display.bounding_box().center() + Point::new(0, 0),
<re_irc> text_style_big,
<re_irc> Alignment::Center,
<re_irc> )
<re_irc> .draw(&mut display)
<re_irc> .unwrap();
<re_irc> Text::with_alignment(
<re_irc> "Chip: ESP32",
<re_irc> display.bounding_box().center() + Point::new(0, 14),
<re_irc> text_style,
<re_irc> Alignment::Center,
<re_irc> )
<re_irc> .draw(&mut display)
<re_irc> .unwrap();
<re_irc> // Write buffer to display
<re_irc> display.flush().unwrap();
<re_irc> // Clear display buffer
<re_irc> display.clear(BinaryColor::Off).unwrap();
<re_irc> // Wait 5 seconds
<re_irc> block!(timer0.wait()).unwrap();
<re_irc> // Write single-line centered text "Hello World" to buffer
<re_irc> Text::with_alignment(
<re_irc> "Hello World!",
<re_irc> display.bounding_box().center(),
<re_irc> text_style_big,
<re_irc> Alignment::Center,
<re_irc> )
<Darius> crikey still going
<re_irc> .draw(&mut display)
<re_irc> .unwrap();
<re_irc> // Write buffer to display
<re_irc> display.flush().unwrap();
<re_irc> // Clear display buffer
<re_irc> display.clear(BinaryColor::Off).unwrap();
<re_irc> // Wait 5 seconds
<re_irc> block!(timer0.wait()).unwrap();
<re_irc> }
<re_irc> }
<re_irc> I keep getting this:
<re_irc> !! A panic occured in 'src\main.rs', at line 74, column 20
<re_irc> PanicInfo {
<re_irc> payload: Any { .. },
<re_irc> message: Some(
<re_irc> called `Result::unwrap()` on an `Err` value: BusWriteError,
<re_irc> ),
<re_irc> location: Location {
<re_irc> file: "src\\main.rs",
<re_irc> line: 74,
<re_irc> col: 20,
<re_irc> },
<re_irc> can_unwind: true,
<re_irc> }
<re_irc> Is this defective hardware, or is my brain the defective thing in this equation?
<re_irc> <@phaseonx11:matrix.org> That's a really helpful comment. I'll do that. One sec.
<re_irc> <@phaseonx11:matrix.org> Hello! Complete noob here...I just got an ESP32 on a micromod board (https://cdn.sparkfun.com/assets/learn_tutorials/1/2/0/8/MicroModESP32ProcessorBoard_a.pdf) and this ssd1306 mini display. I'm trying to get the example on ESP32-HAL to work, as they have one with this particular config (MCU + display controller).
<re_irc> I can't for the life of me get this to work...I've read a ton of data sheets to sanity check whether I was using the right pins:
<re_irc> _pastebin incoming_
<re_irc> <@9names:matrix.org> irc bot not coping well with the big paste?
<re_irc> <@phaseonx11:matrix.org> Hello! Complete noob here...I just got an ESP32 on a micromod board (https://cdn.sparkfun.com/assets/learn_tutorials/1/2/0/8/MicroModESP32ProcessorBoard_a.pdf) and this ssd1306 mini display. I'm trying to get the example on ESP32-HAL to work, as they have one with this particular config (MCU + display controller).
<re_irc> I can't for the life of me get this to work...I've read a ton of data sheets to sanity check whether I was using the right pins:
<re_irc> _pastebin incoming_ (https://pastebin.com/DpA3hxqs)
<re_irc> <@avery71:matrix.org> ahh, irc bridge. I was wondering which client didn't condense it into a scrollable format
<Darius> it copes with the paste but reading code in my IRC client sucks
<re_irc> <@phaseonx11:matrix.org> Apologies. I've put up the code + error on pastebin. Didn't mean to break any rules...
<re_irc> <@phaseonx11:matrix.org> I'm a noob to embedded so forgive me if the answer to this is blatantly obvious to some of you
<re_irc> <@9names:matrix.org> so which pins are wired up to which signal on your LCD?
<re_irc> <@phaseonx11:matrix.org> They have this connector called QWIIC, it is wired to the primary I2C bus...on pins 21 + 22.
<re_irc> <@9names:matrix.org> which signal is on pin 21, and which is on pin 22?
<re_irc> <@phaseonx11:matrix.org> SCL is pin 21, SDA is pin 22. On the connector, there is also a 3.3v line and a ground.
<re_irc> <@phaseonx11:matrix.org> I've verified that its getting power via the 3.3v line if that helps at all...
<re_irc> <@9names:matrix.org> are you certain about that pin ordering? i think you've got them backwards.
<re_irc> <@phaseonx11:matrix.org> I assumed that this was it too. I've tried the reverse and get the same bus error. :(
<re_irc> <@9names:matrix.org> don't assume, check.
<re_irc> <@9names:matrix.org> once we're sure you're using the right pins, you can move on to the next stage of troubleshooting.
<re_irc> before then it will not matter what we try
<re_irc> <@avery71:matrix.org> is there a decent way to vectorize pins to change a bunch at once, or would the best way be to drop down to the PAC and use the unsafe bits function in the registers api?
<re_irc> <@9names:matrix.org> the latter
<re_irc> <@avery71:matrix.org> i unfortunately figured
<re_irc> <@9names:matrix.org> you can definitely make an array of type-erased pins, or make your own iterator for a struct of them, but it's obviously going to be a lot slower to set 1 at a time rather than all at once. plus a decent chunk of boilerplate code you won't enjoy writing.
<re_irc> that said, if i were writing a portable driver I'd just suck it up and deal with the boilerplate.
<re_irc> <@avery71:matrix.org> thats exactly what I figured and would want to avoid. I can drop down to the PAC
<re_irc> <@phaseonx11:matrix.org> Absolutely! Makes sense + thanks for your help.
<re_irc> From what I understand, Pins GPIO pins 21 and 22 on the ESP32 are wired to pins 12 and 14 on the board. Pin 12 on the board says its SDA from primary 12C, pin 14 on the board says its SCL for primary I2C.
<re_irc> When I use pins 12 and 14, the program runs without error...but nothing happens on the board, which would make sense...the HAL is expecting us to refer to those pins by their "internal" number. Right?
<re_irc> <@avery71:matrix.org> I'm also not good enough at rust for how I would want to write the generic code
<re_irc> <@phaseonx11:matrix.org> I also read this, which is what lead me to use pins and 22:
<re_irc> I2C
<re_irc> We love us some I2C! We've broken out two I2C buses, which can be used with our Qwiic system. The main I2C bus has dedicated GPIO pins 21/22 connected to MicroMod pads 12/14, along with a dedicated interrupt pin connected to GPIO pin 4, which is connected to pad 16 of the MicroMod connector.
<re_irc> <@9names:matrix.org> okay, that just sounds like what the pin numbers on the pdf i linked just stated (except a little less clear).
<re_irc> <@9names:matrix.org> the leftmost box is the pin number on the micromod edge connector. that only matters if you're making a board to interface with the micromod.
<re_irc> the rightmost box is the GPIO number, that's what your software needs to use to drive that pin.
<re_irc> <@9names:matrix.org> so i2c_scl is 22, and i2c_sda is 21. unless the board with the qwiic connector on it wired it up backwards for some reason
<re_irc> <@phaseonx11:matrix.org> let i2c = I2C::new(
<re_irc> io.pins.gpio21,
<re_irc> io.pins.gpio22,
<re_irc> 100u32.kHz(),
<re_irc> peripherals.I2C0,
<re_irc> &clocks,
<re_irc> &mut system.peripheral_clock_control,
<re_irc> );
<re_irc> ?
<re_irc> <@9names:matrix.org> yes
<re_irc> <@phaseonx11:matrix.org> Ok...when I do that, I get a BusError.
<re_irc> <@phaseonx11:matrix.org> Does that mean there's probably a hardware issue going on?
<re_irc> <@phaseonx11:matrix.org> (As an aside, is there a rule against copy/pasting things? 0.0)
<re_irc> <@9names:matrix.org> there's no rule against it as far as I know, it's just a lot easier to read a lot of text if it's placed in a gist or something.
<re_irc> <@avery71:matrix.org> yeah, the client on my phone likes to put blocktext all in one scrollable field that is one line tall and about an inch wide
<re_irc> <@phaseonx11:matrix.org> Usually, in "regular rust". I'm able to get a bit more info about the error...I feel like I'm missing something. In terms of debugging?
<re_irc> <@phaseonx11:matrix.org> To do that properly...I'm going to need a JTAG interface and to run openocd or something huh?
<re_irc> <@phaseonx11:matrix.org> : Ooof. Apologies :/
<re_irc> <@9names:matrix.org> not necessarily, no. you can often get enough context of what is going on by printing things out to your serial terminal
<re_irc> <@9names:matrix.org> and when the problem is wiring or addressing, you can often discover that by checking the datasheet of your hardware and comparing that to what is in your code
<re_irc> <@9names:matrix.org> so: which board have you got your micromod installed into, and which qwiic screen are you using?
<re_irc> <@phaseonx11:matrix.org> I've tried my best to figure out the pinning but ngl, its been a little overwhelming. I'm committed to learning though, so thank you for your help!
<re_irc> The pins seem to line up:
<re_irc> <@avery71:matrix.org> is there not a board support package?
<re_irc> <@phaseonx11:matrix.org> Mmm...I'm sorry, but I'm not sure I know what that means.
<re_irc> <@phaseonx11:matrix.org> This is the OLED screen, which is powered by the ssd1306 controller:
<re_irc> <@9names:matrix.org> okay, so we will assume that the boards have the connector wired up correctly, and that the GPIO numbers we've put in are correct.
<re_irc> now we need to know which i2c address your screen is on, and which one your driver expects.
<re_irc> if these are different, the screen will not respond to any requests which could be causing your error.
<re_irc> <@phaseonx11:matrix.org> Oh my god...that is such a good point. I didn't think to check that XD
<re_irc> <@9names:matrix.org> here's the datasheet for that sparkfun screen, find what the default i2c address is:
<re_irc> <@phaseonx11:matrix.org> Default addr is 0X3D
<re_irc> <@phaseonx11:matrix.org> Let me see what the driver expects...
<re_irc> <@phaseonx11:matrix.org> Ahaaaaa....I think you might be onto something with the address thing:
<re_irc> impl I2CDisplayInterface {
<re_irc> pub fn new<I>(i2c: I) -> I2CInterface<I>
<re_irc> /// Create new builder with a default I2C address of 0x3C
<re_irc> where
<re_irc> I: embedded_hal::blocking::i2c::Write,
<re_irc> {
<re_irc> Self::new_custom_address(i2c, 0x3C)
<re_irc> }
<re_irc> /// Create a new I2C interface with the alternate address 0x3D as specified in the datasheet.
<re_irc> pub fn new_alternate_address<I>(i2c: I) -> I2CInterface<I>
<re_irc> where
<re_irc> I: embedded_hal::blocking::i2c::Write,
<re_irc> {
<re_irc> Self::new_custom_address(i2c, 0x3D)
<re_irc> }
<re_irc> /// Create a new I2C interface with a custom address.
<re_irc> pub fn new_custom_address<I>(i2c: I, address: u8) -> I2CInterface<I>
<re_irc> where
<re_irc> I: embedded_hal::blocking::i2c::Write,
<re_irc> {
<re_irc> I2CInterface::new(i2c, address, 0x40)
<re_irc> }
<re_irc> }
<re_irc> <@phaseonx11:matrix.org> It thinks default addr is 0x3C, not 0x3D
<re_irc> <@phaseonx11:matrix.org> let me instantiate calling new_alternate_address instead of new
<re_irc> <@avery71:matrix.org> I don't feel like looking at the datasheet, does it have different addresses depending on how you have the i2c slave device pinned up?
<re_irc> <@phaseonx11:matrix.org> No worries, let me know any info you need an I'll look. Yes. By default it set to 0x3D. If you short a jumper on the bottom, it switches the the default address for the crate.
<re_irc> <@phaseonx11:matrix.org> So there's def a mismatch.
<re_irc> <@phaseonx11:matrix.org> Which would make sense as to why there's a bus error...you can't talk to something that doesn't exist
<re_irc> <@phaseonx11:matrix.org> No worries, let me know any info you need an I'll look. Yes. By default it set to 0x3D. If you short a jumper on the bottom, it switches to thethe default address for the crate.
<re_irc> <@avery71:matrix.org> so whats the alternative addr?
<re_irc> <@phaseonx11:matrix.org> IT TURNED ON!
<re_irc> let interface = I2CDisplayInterface::new(i2c);
<re_irc> <@phaseonx11:matrix.org> I changed this line:
<re_irc> To this:
<re_irc> let interface = I2CDisplayInterface::new_alternate_address(i2c);
<re_irc> <@phaseonx11:matrix.org> and it works!!!
<re_irc> <@phaseonx11:matrix.org> You nailed it right on the head. Driver though i2c addr was 0x3C but by default (on board) its 0x3D
<re_irc> <@phaseonx11:matrix.org> So of course, you can't talk to something that isn't there. I feel like I've learned an extremely valuable lesson here. Thank you so much!
<re_irc> <@avery71:matrix.org> there is just a lot of small stuff like that buried in datasheets and you couldn't know its a thing unless you read it front to back, or someone tells you that alternative addresses are a thing
<re_irc> <@avery71:matrix.org> * they
<re_irc> <@avery71:matrix.org> * alternative addresses
<re_irc> <@phaseonx11:matrix.org> There's quite a lot to this embedded stuff, but figuring out makes me want to keep learning. Thank you so much for your help! I really appreciate it...I've been trying to get this to work for 2 days :/
<re_irc> <@phaseonx11:matrix.org> It feels so alien from any other software I've made before. I really like that about it.
<re_irc> <@avery71:matrix.org> in my opinion, embedded is so much more fun because at the end, there is something that you can hold and touch. That just isn't something you can do with regular software
<re_irc> <@k900:conduit.0upti.me> One of my college professors used to joke that making hardware is kinda like writing software but you pay money for every line of code
<re_irc> <@k900:conduit.0upti.me> It's honestly not inaccurate
<re_irc> <@phaseonx11:matrix.org> : Yes, exactly! I have never been so happy to see little words blink on a screen XD
<re_irc> <@k900:conduit.0upti.me> There's a lot of decisions that are made on the basis of "we could do this the normal way or we could save $0.03 on the BOM"
<re_irc> <@phaseonx11:matrix.org> While I have you all here. What would be some better ways to debug in the future? I feel like...BusError is a bit too generic (which I supposed is the point with these HAL crates), but how can I get a bit more granularity in terms of debugging or error reporting?
<re_irc> <@k900:conduit.0upti.me> Not really
<re_irc> <@k900:conduit.0upti.me> At least not in this case
<re_irc> <@k900:conduit.0upti.me> The way I2C works is you just yeet some data onto the bus and hope a response comes back
<re_irc> <@k900:conduit.0upti.me> If it doesn't, you have no idea what happened
<re_irc> <@k900:conduit.0upti.me> Maybe there's nothing on the bus
<re_irc> <@k900:conduit.0upti.me> Maybe there's something on the bus but it's broken
<re_irc> <@phaseonx11:matrix.org> Sorta like UDP?
<re_irc> <@k900:conduit.0upti.me> Maybe there's no bus
<re_irc> <@phaseonx11:matrix.org> Ooof 0.0 worse than UDP lol
<re_irc> <@k900:conduit.0upti.me> It's an _extremely_ simple protocol
<re_irc> <@k900:conduit.0upti.me> Because making it more complex would cost money
<re_irc> <@avery71:matrix.org> well. There is a really good way to debug this, it just requires having a logic analyzer. But all it would have told you is that what you are sending is what you are thinking its sending, and that you aren't getting a response
<re_irc> <@phaseonx11:matrix.org> My longterm project is to learn how to write an i2c driver for something and contribute it to crates.io
<re_irc> <@phaseonx11:matrix.org> : Ooof...which is basically the same level of granularity I got with this error.
<re_irc> <@phaseonx11:matrix.org> A lot of this is just running up against a wall and getting better at it over time I suppose.
<re_irc> <@avery71:matrix.org> Luis Roel: this is where experience or thinking really card comes into play. If you assume that the board isn't broken, the only reason I can think of for it not responding is that you are using the wrong address
<re_irc> <@phaseonx11:matrix.org> : I know that now, for next time hehe. I'm not sure why it ever occurred to me that it was an address thing.
<re_irc> <@phaseonx11:matrix.org> My incorrect assumption was that all boards having the same controller, have the same address
<re_irc> <@avery71:matrix.org> one thing you could do is just look at driver code that others wrote, lots of them on here https://github.com/rust-embedded/awesome-embedded-rust#driver-crates
<re_irc> <@k900:conduit.0upti.me> Most I2C things have a way to change the address
<re_irc> <@k900:conduit.0upti.me> So you can connect more than one
<re_irc> <@k900:conduit.0upti.me> Most I2C things also implement it in the stupidest way possible because again, costs
<re_irc> <@avery71:matrix.org> Luis Roel: sometimes you want to have multiple of the same devices on the same bus, so they would have to be configured differently so that you can use different addresses for each
<re_irc> <@phaseonx11:matrix.org> There's another thing I sorta get, but not entirely. Pull up resistors. Even on a bus with multiple devices, there should only be a single set right? Since then there would be too much resistance to send messages?
<re_irc> <@avery71:matrix.org> the most cost efficient way to implement i2c is to actually use spi
<re_irc> <@phaseonx11:matrix.org> : _sigh_ that makes so much sense lol like...it seems so obvious, but its not something I thought of at the time
<re_irc> <@k900:conduit.0upti.me> The point of pullups isn't really to provide resistance, it's to avoid weird floating states on your pins
<re_irc> <@k900:conduit.0upti.me> It's not really something you need to worry about when using something like i2c
<re_irc> <@k900:conduit.0upti.me> Because those devices are (usually) built to spec so they'll have all the right components in the right places
<re_irc> <@avery71:matrix.org> K900: I'd say its so allow all devices to control the state of the bus without two devices accidentally trying to drive the bus to opposite states
<re_irc> <@phaseonx11:matrix.org> Every datasheet I read says that you should only have one pair of pullup resistors per bus. Is that accurate?
<re_irc> <@avery71:matrix.org> thinking about the clock, it allows the master to run the clock, but it also allows the slave to slow down the clock if it needs a longer cycle to do an operation
<re_irc> <@avery71:matrix.org> Luis Roel: yeah
<re_irc> <@k900:conduit.0upti.me> I mean you _can_ have more and it'll be fine
<re_irc> <@k900:conduit.0upti.me> It's just not going to do anything
<re_irc> <@avery71:matrix.org> its going to mess with the resistance and might throw the bus off, but if you had multiple and they added up to the correct amount, then it should be fine
<re_irc> <@k900:conduit.0upti.me> Well it depends on what you're connecting them to
<re_irc> <@k900:conduit.0upti.me> But if you just connect multiple resistors connected from the same source to the same bus in parallel, it'll work exactly like if you just had one
<re_irc> <@k900:conduit.0upti.me> Because physics
<re_irc> <@k900:conduit.0upti.me> (not actually _exactly_ but close enough)
<re_irc> <@phaseonx11:matrix.org> What logic analyzer do you guys recommend? What about USB -> JTAG?
<re_irc> <@k900:conduit.0upti.me> If you want super cheap, probably something like FX2LP
<re_irc> <@k900:conduit.0upti.me> (look it up on aliexpress)
<re_irc> <@avery71:matrix.org> logic analyzers look at the signals on the bus, so for this it would have been a 3rd viewpoint to verify that things work the way they do. One that I have experience with is the Analog Discovery 2, which looking at google its $300. If you feel like you really want to go deep into the hardware world, it could be a valuable asset, otherwise I might suggest something else
<re_irc> <@phaseonx11:matrix.org> Oh wow, that things looks like a beast!
<re_irc> <@k900:conduit.0upti.me> I can also shill https://www.crowdsupply.com/1bitsquared/glasgow because I just think it's extremely cool
<re_irc> <@phaseonx11:matrix.org> * thing
<re_irc> <@phaseonx11:matrix.org> K900: Oh wow, this is pretty nice. And its not super expensive either.
<re_irc> <@phaseonx11:matrix.org> And it has JTAG built in too...hmm
<re_irc> <@k900:conduit.0upti.me> "JTAG" is pretty vague and it's not _stupid_ fast so it will depend on what you're debugging
<re_irc> <@k900:conduit.0upti.me> But I believe was working on SWD for debugging ARM microcontrollers
<re_irc> <@avery71:matrix.org> One reason I really like the analog discovery is because the digilent software will decode serial modes for you
<re_irc> <@whitequark:matrix.org> it can be _stupid_ fast with an appropriate MCU-specific plugin
<re_irc> <@whitequark:matrix.org> but that's not something that exists (yet)
<re_irc> <@phaseonx11:matrix.org> Maybe I'm not understanding what JTAG is...but I saw something that basically allows you to step through your code and look at the internal state of the MCU within GDB. Sort of like when you debug a normal program.
<re_irc> <@whitequark:matrix.org> like, there's nothing stopping it from JTAGging as fast as your MCU can tolerate, or at 50 Mbps
<re_irc> <@phaseonx11:matrix.org> I wonder if the pins would melt lol
<re_irc> <@whitequark:matrix.org> the pins are good for about 2 amps
<re_irc> <@k900:conduit.0upti.me> Pins usually melt due to voltage and not speed
<re_irc> <@k900:conduit.0upti.me> * currnet
<re_irc> <@k900:conduit.0upti.me> * current
<re_irc> <@whitequark:matrix.org> current does increase with speed!
<re_irc> <@whitequark:matrix.org> this is actually one of the considerations I had when designing it
<re_irc> <@k900:conduit.0upti.me> And the Glasgow hardware has a lot of failsafes
<re_irc> <@whitequark:matrix.org> the drivers will source/sink something like 50 mA per driver
<re_irc> <@whitequark:matrix.org> which is 1/20th of the pin rating, so the pins are good even in short circuit conditions
<re_irc> <@avery71:matrix.org> Radios also have different power draw at different frequencies, but if my memory serves me right (which it very well might not be) it uses more current at lower frequencies
<re_irc> <@k900:conduit.0upti.me> FWIW I would want to help out with the SWD stuff if I ever get my board (first batch early bird)
<re_irc> <@k900:conduit.0upti.me> But that will require some, uh, uncoventional logistics
<re_irc> <@k900:conduit.0upti.me> * unconventional
<re_irc> <@phaseonx11:matrix.org> I was told that if I wanted to do line by line debugging of my program, while it was running, I would need somethin like the below that plugged into the boards JTAG pins and then to GDB....to do "in circuit debugging".
<re_irc> <@phaseonx11:matrix.org> Is there something that combines both a logic analyzer and something that lets me do in circuit debug?
<re_irc> <@k900:conduit.0upti.me> Not many things, but Glasgow can, yes
<re_irc> <@phaseonx11:matrix.org> K900: I would be so down, but they're saying it'll come up Feb of 2024 :(
<re_irc> <@phaseonx11:matrix.org> I might get one when they come out though. It seems like the best option, from what I've seen.
<re_irc> <@whitequark:matrix.org> Luis Roel: the original crowdsupply campaign was two years ago but the team doing it was hit super hard by the component shortage yea...
<re_irc> <@whitequark:matrix.org> : the mechanism is different with radios (RF coupling vs capacitive impedance)
kenny has quit [Ping timeout: 250 seconds]
<re_irc> <@avery71:matrix.org> : it seems really interesting, if I didn't have access to good stuff through my university, I probably would try to get my hands on one
<re_irc> <@phaseonx11:matrix.org> I want to thank everyone for their help! I will try not to come back and bother you too soon :)
<re_irc> <@avery71:matrix.org> please do come back
<re_irc> <@phaseonx11:matrix.org> Have a good morning/afternoon/night! Thanks again!
kenny has joined #rust-embedded
<re_irc> <@bugadani:matrix.org> Luis Roel: it's funny because this is the exact reason I like embedded but it's technically wrong :) you can touch a smart phone, and you can have blinking words on a screen with embedded, too.
<re_irc> the big difference, to me at least, is that you are much more intimate with the thing you work on
<re_irc> <@mali:grusbv.com> Good morning! Is there a way that I can analyse my binary size like cargo bloat or similiar?
<re_irc> <@k900:conduit.0upti.me> What's wrong with cargo bloat?
<re_irc> <@diondokter:matrix.org> mali ⚡️: "cargo nm" and "cargo size" are two other useful tools
<re_irc> <@diondokter:matrix.org> (part of cargo-binutils)
<re_irc> <@mali:grusbv.com> let me try nm
<re_irc> <@mali:grusbv.com> : Thanks, nm with the right args do the job pretty well
<re_irc> <@therealprof:matrix.org> mali ⚡️: What's wrong with cargo bloat?
<re_irc> <@mali:grusbv.com> Actually I now noticed that nothing is wrong
<re_irc> <@mali:grusbv.com> I am using the ferrous' embedded test crate structure
<re_irc> <@mali:grusbv.com> and sometimes I forgot to cd into the cross compiled crate
<re_irc> <@mali:grusbv.com> and call things from the parent crate which does not compile binaries
<re_irc> <@mali:grusbv.com> or I guess the workspace dir
<re_irc> <@therealprof:matrix.org> I do find cargo-bloat super helpful to identify which of the functions signifcantly contribute to the binary size of the firmwares.
<re_irc> <@therealprof:matrix.org> So I was worried it somehow was broken for you. 😅
<re_irc> <@mali:grusbv.com> Yes, I caught a dependency bloating
<re_irc> <@sourcebox:matrix.org> I also have a problem with code bloat on my Cortex-A7 project. LTO is only working in thin mode, is this a known thing?
<re_irc> <@sourcebox:matrix.org> What I see is that LTO doesn't strip out unused code paths from external crates that good as I thought.
<re_irc> <@sourcebox:matrix.org> At least with thin LTO.
<re_irc> <@sourcebox:matrix.org> What I get with full LTO is "out of range pc-relative fixup value"e.g. "ldr r3, =0x00086060", so the generated code is not correct.
starblue has quit [Ping timeout: 244 seconds]
<re_irc> <@diondokter:matrix.org> : Huh, strange. Maybe try a different linker? (just to see, it should work by default afaik)
<re_irc> <@sourcebox:matrix.org> I use the "armv7r-none-eabihf" target.
<re_irc> <@sourcebox:matrix.org> So you suggest to use the GNU linker from the ARM toolchain?
<re_irc> <@diondokter:matrix.org> Yeah, for example
<re_irc> <@sourcebox:matrix.org> Can have a look.
starblue has joined #rust-embedded
<re_irc> <@diondokter:matrix.org> If the official linker still does LTO wrong, then we'll know it's not the linker being wrong
<re_irc> <@sourcebox:matrix.org> "cannot find libc.a". I think some options have to be added for arm-none-eabi-ld.
<re_irc> <@sourcebox:matrix.org> I get the same error with the GNU linker.
<re_irc> <@diondokter:matrix.org> Ah
<re_irc> <@sourcebox:matrix.org> Is there a chance to see where this assembly code is generated?
<re_irc> <@diondokter:matrix.org> I think you can call objdump on the object files
<re_irc> <@diondokter:matrix.org> Do you have unsafe code? I've heard LTO can fail if you have UB
<re_irc> <@sourcebox:matrix.org> This I already do.
<re_irc> <@sourcebox:matrix.org> Yeah, lots of unsafe code. We're in embedded land :-)
<re_irc> <@diondokter:matrix.org> Haha, ok, not anything specific then
<re_irc> <@sourcebox:matrix.org> Ok, I've found it.
<re_irc> <@sourcebox:matrix.org> It's just my code enabling the FPU.
<re_irc> <@sourcebox:matrix.org> "vmrs r2, fpscr",
<re_irc> "ldr r3, =0x00086060",
<re_irc> "and r2, r2, r3",
<re_irc> "vmsr fpscr, r2",
<re_irc> <@sourcebox:matrix.org> Why does this fail?
<re_irc> <@9names:matrix.org> : i'm sorry, what? you said you target Cortex-A7 but you're actually targeting Cortex-R?
<re_irc> this doesn't make any sense at all
<re_irc> <@sourcebox:matrix.org> : Because it seems to be recommended. The platforms are nearly identical.
<re_irc> <@sourcebox:matrix.org> Maybe someone here knows it better. Cortex-R doesn't have an MMU, but that doesn't seem to be relevant for code generation.
<re_irc> <@9names:matrix.org> i really want to know who recommends this, got a link?
<re_irc> <@sourcebox:matrix.org> : Have to google for it again.
<re_irc> <@sourcebox:matrix.org> But I can tell that the code runs in general.
<re_irc> <@sourcebox:matrix.org> I thought I could easily replace "ldr r3, =0x00086060" with "ldr r3, #0x00086060" but then it fails with "instruction requires: thumb2"
<re_irc> <@sourcebox:matrix.org> My knowledge of ARM assembly is not that great, I have to admit.
<re_irc> <@9names:matrix.org> huh, i thought there was more difference between R and A
<re_irc> <@9names:matrix.org> thanks for the link
crabbedhaloablut has joined #rust-embedded
<re_irc> <@thejpster:matrix.org> I'm reminded that all the ARM targets fit into one GCC, and the question is basically "thumb or arm".
<re_irc> <@thejpster:matrix.org> But then a Cargo target also encodes the OS being used.
<re_irc> <@thejpster:matrix.org> I'm reminded that all the (edit: bare-metal) ARM targets fit into one GCC, and the question is basically "thumb or arm".
<re_irc> <@9names:matrix.org> yeah. but there's more to architecture and target support than which instructions are supported.
<re_irc> guess i hadn't really delved into whether there were different number of registers, if they had a different ABI, etc.
<re_irc> <@sourcebox:matrix.org> Ok, I wonder why "ldr r3, =0x00086060" is only rejected when LTO is used. Maybe because this is allowed only in Thumb2, the compiler knows it, but not the linker. Hmm.
<re_irc> <@9names:matrix.org> i'm still not sure why https://github.com/rust-lang/rust/pull/68253/files added only armv7a-none-eabi as a target but added spec files for both armv7a-none-eabi and armv7a-none-eabihf
<re_irc> <@9names:matrix.org> oh, it's in that PR - japaric reverted it.
<re_irc> > Fixing the build of that crate on armv7a-none-eabihf is going to require changes in the compiler-builtins crate's build script so I'm going to leave the rust-std build for that target out until that gets addressed upstream.
<re_irc> <@sourcebox:matrix.org> Ok, I was able to find some assembly code that works. Full LTO is now working and does some good job in reducing overall code size by about 10% in comparison to thin.
<re_irc> - opt-level=s or z (sometimes one is smaller, sometimes the other)
<re_irc> - lto=fat
<re_irc> <@dirbaio:matrix.org> if you want to reduce code size, try enabling these magic flags
<re_irc> - build-std=core
<re_irc> - build-std-features=panic_immediate_abort
<re_irc> <@sourcebox:matrix.org> What I already identified is inlining across crates.
<re_irc> > for now, do not build rust-std for the armv7a-none-eabihf target
<re_irc> > Fixing the build of that crate on armv7a-none-eabihf is going to require changes in the compiler-builtins crate's build script so I'm going to leave the rust-std build for that target out until that gets addressed upstream.
<re_irc> <@9names:matrix.org> oh, it's in that PR - japaric reverted it.
<re_irc> <@sourcebox:matrix.org> Btw. objdump gives a lot of "<unknown>" for the opcodes, making it not very usable when looking for crashes.
<re_irc> <@ryan-summers:matrix.org> : Is there a bbqueue that exists using user-provided slices?
<re_irc> <@jamesmunns:beeper.com> nope
<re_irc> <@jamesmunns:beeper.com> Well, sort of 😅, mnemos' bbqueue_ipc uses user provided buffers (ptr+len)
<re_irc> <@ryan-summers:matrix.org> Trying to figure out how hard it would be to allow an either-or approach. But it seems like the type would always have either a lifetime (for the borrow of the slice) or a const-generic (for the size of the buffer). If you unified them, it'd just be both specifies
<re_irc> <@jamesmunns:beeper.com> Yeah, I avoided this tbh, ideally I'd love to be generic over:
<re_irc> - A borrowed slice
<re_irc> - A heap allocated slice (Arc)
<re_irc> - An owned slice
<re_irc> <@jamesmunns:beeper.com> but there's not a _great_ way to do that without copy+paste or overhead or very tricky generics tbh
<re_irc> <@jamesmunns:beeper.com> you might be able to do it similar to how I do some other crates, and have a "Storage" trait, but it'd definitely be unsafe, and for something like Arc, you really want "increase refcount" and "decrease refcount" ability
<re_irc> <@jamesmunns:beeper.com> but fwiw, I DO think I "plumb" the lifetimes for all the structures, so it should be possible to switch to a borrowed slice without too invasive of a change once you change the BBBuffer type.
<re_irc> <@diondokter:matrix.org> Couldn't you do something like:
<re_irc> inner: M,
<re_irc> (Though you might still need a lifetime for that reference there)
<re_irc> pub struct MyContainer<M: AsMut<&[u8]>> {
<re_irc> }
<re_irc> <@ryan-summers:matrix.org> The use-case I have is that I want the user to provide some memory (i.e. borrowed, mutable slice) that I can use for buffering MQTT transmissions that require acknowledgement and potential retransmission
<re_irc> <@mabez:matrix.org> : Sounds like something https://crates.io/crates/managed could manage (heh) for you
<re_irc> <@mabez:matrix.org> but I will say the ergonomics of using that are a bit weird
<re_irc> <@ryan-summers:matrix.org> Yeah, managed was on my mind here
<re_irc> <@jamesmunns:beeper.com> yeah, I've poked around about this, I couldn't come up with a nice api for it all that didn't make it even more silly to use
<re_irc> <@jamesmunns:beeper.com> I'm very open to changes tho, if you find a nice way.
<re_irc> <@jamesmunns:beeper.com> https://github.com/tosc-rs/mnemos/blob/main/source/abi/src/bbqueue_ipc/bbbuffer.rs might be interesting for you
<re_irc> <@jamesmunns:beeper.com> that uses a raw pointer, and unsafe constructors for producer and consumer halves. The intent was to use it for IPC between kernel and userspace
<re_irc> <@jamesmunns:beeper.com> In the actual kernel, we allocate it with "Arc<UnsafeCell<[u8]>>" basically as storage: https://github.com/tosc-rs/mnemos/blob/main/source/kernel/src/comms/bbq.rs
<re_irc> <@jamesmunns:beeper.com> It does "cost" you one extra level of indirection for going from the header block to the storage block, whereas it's inline in "normal" bbqueue
<re_irc> <@ryan-summers:matrix.org> Maybe I just bite the bullet for now and use a const generic size arg and deal with this later
<re_irc> <@ryan-summers:matrix.org> I don't want to rewrite a bip-buffer just for this
<re_irc> <@jamesmunns:beeper.com> Yeah, bbqueue is in a weird place and I haven't given it much love lately because to have a really safe API, you need a REALLY specific API, and I find a lot of people are confused on how to use it right (which probably means I need more docs and examples), so in practice I use it a ton because it's silly good for what mnemos and my projects that use DMA need, but... yeah
<re_irc> <@ryan-summers:matrix.org> Huh, actually I don't know if bbqueue can actually be used in an internal library when the library owns the buffer. You can't store the bbbuffer + consumer + producer in the same struct because that would make it self-referential
<re_irc> <@ryan-summers:matrix.org> * bbbuffer.
<re_irc> <@ryan-summers:matrix.org> The only workaround would be to store the bbbuffer and split it as you need to read/write, then recombine, but the docs say the buffer is reinitialized on every split
<re_irc> <@ryan-summers:matrix.org> * zero-reinitialized
xnor has quit [Ping timeout: 240 seconds]
<re_irc> <@jamesmunns:beeper.com> Yeah, bbqueue-ipc just uses a raw pointer, so the storage is "you must make sure it lives long enough" - we do this in mnemos by using an Arc for the storage + grants
<re_irc> The storage "ArrayBuf" lives in "BBQStorage", all prod/cons/grants hold an Arc of that, so the backing buffer is dropped when "BBQStorage" is, which is when there are no grants/prod/cons are left.
<re_irc> This isn't actually self-referential, because "ArrayBuf" is a heap allocation as well. I have no idea how you'd do this borrowed.
<re_irc> <@jamesmunns:beeper.com> You _could_ get rid of the "clear on every split", code, that's not there for any particular correctness reasons, tho then there is no way to recover if you "forget" a handler and the queue is wedged.
<re_irc> <@ryan-summers:matrix.org> Tbh this is well into the realm of "I'm just writing another ring buffer"
<re_irc> <@ryan-summers:matrix.org> This is all no_std no_alloc and I'd prefer to do it safely and quickly
<re_irc> <@jamesmunns:beeper.com> like I said, you could probably eliminate a LOT of the complexity that bbqueue deals with if you get rid of thread safety and only want a local buffer.
<re_irc> <@mabez:matrix.org> Is there a (easy) way to ensure doc tests compile without having to use std? I just want to make sure the documentation examples stay up to date, I don't need to actually run the code.
<re_irc> <@ryan-summers:matrix.org> You can mark them "no_run"? Not sure if that solves the std part though
<re_irc> <@jamesmunns:beeper.com> : There's a "build don't run" attribute for doc tests, lemme find it, "no-run" maybe?
<re_irc> <@jamesmunns:beeper.com> yeah, "no_run"
<re_irc> <@diondokter:matrix.org> Yeah, there are a bunch of attributes: https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#attributes
<re_irc> <@mabez:matrix.org> Sorry I should have mentioned I found no-run, the problem is, is there a way I can invoke that compilation step _without_ "cargo test", because cargo test expects std
<re_irc> #![cfg_attr(not(test), no_std)]
<re_irc> <@diondokter:matrix.org> You can conditionally turn off no_std.
<re_irc> <@jamesmunns:beeper.com> ah, for mnemos most of what we do is... yeah, what dion said :D
<re_irc> <@diondokter:matrix.org> Best way I've found so far
<re_irc> <@jamesmunns:beeper.com> you might? be able to define a custom harness that's a no-op and doesn't require std? I'm less familiar with that tho
<re_irc> <@mabez:matrix.org> Yeah I'll go with that then, the problem is when you have inline asm or global asm in the project (or dep) you have to cfg that away too 😢
<re_irc> <@diondokter:matrix.org> Ah yep
<re_irc> <@diondokter:matrix.org> That is annoying
<re_irc> <@mabez:matrix.org> Hmm, I found the unstable "-Zdoctest-xcompile" which _seems_ to do exactly what I want, however the compilation tests never fail. Maybe I'm holding it wrong 🤔
emerent has quit [Ping timeout: 264 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
starblue has quit [Ping timeout: 244 seconds]
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@mabez:matrix.org> So, I got it working, here is a simple example of it: https://github.com/esp-rs/esp-hal/pull/693
GenTooMan has quit [Ping timeout: 260 seconds]
<re_irc> <@bugadani:matrix.org> : this is cool but I expect including all the targets will be somewhat complex
<re_irc> <@bugadani:matrix.org> +really
<re_irc> <@bugadani:matrix.org> the feature may be a really good fit for smaller, SoC dependent snippets
<re_irc> <@bugadani:matrix.org> : does this only work from the "esp-hal-common" folder? what happens when you run the command on the soc-specific crate? if that works, the command to invoke would be a lot shorter
GenTooMan has joined #rust-embedded
<re_irc> <@mabez:matrix.org> : Only works in esp-hal-common because doctests don't get run on dependencies
<re_irc> <@mabez:matrix.org> Found that out the hard way 😂
<re_irc> <@bugadani:matrix.org> : then I think you'll need a config.toml for S2 to work
<re_irc> <@bugadani:matrix.org> kinda like I had to add for esp-hal-smartled
<re_irc> <@mabez:matrix.org> : Yeah you're right, still a lot to do. I just wanted to plonk my findings somewhere before I forgot how it worked :D
<re_irc> <@bugadani:matrix.org> : haha, alright :) it's an exciting feature because it's really annoying to add a myriad of small example files just to showcase a tiny variation
<re_irc> <@bugadani:matrix.org> +on something
<re_irc> <@bugadani:matrix.org> * something, especially useful for the sleep API
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
starblue has joined #rust-embedded
crabbedhaloablut has quit []
dc740 has quit [Remote host closed the connection]