04:19 <re_irc> <@drewbus:matrix.org> Hey guys, greenie here. I’ve been learning embedded programming in rust and am having trouble with an MCP4725 that I’m trying to use to control motor speed via a motor controller. I’m using a jetson Xavier agx, and have the mcp wired to 3v3. I see the address as 0c60 in i2cdetect. Checked the wiring a hundred time. Tried all baud rates in the data sheet. I wrote a rust program to send a sawtooth wave, but I’m worried...

04:20 <re_irc> ... there may be library issues. I’m using I2cdev from Linux_embedded_hal and the mcp4725 library. I’ve determined that it errors out when I try to call set_dac in the mcp object. I get os error 121 a couple times, then os error 110, then os error 5 indefinitely.

04:20 <re_irc> I’m not married to the 4725, I had them lying around. I need a DAC to communicate with my controller though, and I’m trying to be a better engineer so I want to solve this one if I can. Any help appreciated.

04:20 <re_irc> <@drewbus:matrix.org> And I’m determined to make Rust my go-to language, so I’m going to fight this one until I figure it out.

04:50 <re_irc> <@theunkn0wn1:matrix.org> : your xavier user has the permissions to write to the I2C bus yeah?

04:51 <re_irc> <@theunkn0wn1:matrix.org> (and that you're writing to the right bus?)

05:09 <Darius> drewbus: can you post your code?

05:12 <re_irc> <@drewbus:matrix.org> I’m a member of the i2c group, and I’m writing to the correct bus

05:13 <re_irc> <@drewbus:matrix.org> One thing of note - every time I execute my program, the i2c on the jetson for that bus stops… working? I2cdetect doesn’t show anything anymore. I disconnect my MCP and reconnect it and then I can see addresses 60 and 74 are connected again

05:17 <re_irc> <@drewbus:matrix.org> Here’s the code. I’m not sure how to format it on my phone:

05:21 <Darius> pastebin or something?

05:22 <re_irc> <@drewbus:matrix.org> use std::{io::{self, Write}, println, eprintln};

05:22 <re_irc> use std::sync::atomic::{AtomicBool, Ordering};

05:22 <re_irc> use std::sync::Arc;

05:22 <re_irc> use ctrlc;

05:22 <re_irc> fn main() {

05:22 <re_irc> println!();

05:22 <re_irc> println!("Hello, MCP4725!");

05:22 <re_irc> print!("Please enter an i2c device. Not the directory, just the device name: ");

05:22 <re_irc> io::stdout().flush().unwrap(); // Flush stdout to ensure the prompt prints immediately

05:22 <re_irc> // Create a String to hold the user input

05:22 <re_irc> let mut i2cname = String::new();

05:22 <re_irc> io::stdin().read_line(&mut i2cname).unwrap();

05:22 <re_irc> i2cname = i2cname.trim().to_string();

05:22 <re_irc> let dev_path = format!("/dev/{}", i2cname);

05:22 <re_irc> println!("You typed {}", dev_path);

05:22 <re_irc> println!("Generating sawtooth wave signal on DAC output...");

05:22 <re_irc> let dev = I2cdev::new(&dev_path).expect("Failed to open device");

05:22 <re_irc> let address = 0x60; //default slave address

05:22 <re_irc> //Prepare atomic flag for SIGINT handling

05:22 <re_irc> let running = Arc::new(AtomicBool::new(true));

05:22 <re_irc> let r = running.clone();

05:22 <re_irc> //Set up SIGINT handling

05:22 <re_irc> ctrlc::set_handler(move || {

05:22 <re_irc> r.store(false, Ordering::SeqCst);

05:22 <re_irc> }).expect("Error setting Ctrl-C handler");

05:22 <re_irc> let mut dac = MCP4725::new(dev, address);

05:22 <re_irc> //generate sawtooth wave signal with amplitude from 0 to VDD

05:22 <re_irc> while running.load(Ordering::SeqCst) {

05:22 <re_irc> for dac_code in 0..4096 {

05:22 <re_irc> if let Err(e) = dac.set_dac(PowerDown::Normal, dac_code) {

05:22 <re_irc> eprintln!("Failed to set DAC: {}", e);

05:22 <re_irc> break;

05:22 <re_irc> }

05:22 <re_irc> }

05:22 <re_irc> }

05:22 <re_irc> println!("Ctrl-C received, cleaning up and exiting");

05:22 <re_irc> }

05:27 <Darius> so, what if you sleep after each write for a bit?

05:27 <re_irc> <@drewbus:matrix.org> I’m not getting a “failed to open device” error when I set up the dac.

05:28 <re_irc> <@drewbus:matrix.org> Let me try sleep.

07:26 <re_irc> <@thejpster:matrix.org> If you haven’t seen the Rust zulip, there’s a thread about the new Leadership Council and a document soliciting views on how the Launching Pad should work. I encourage you to check it out.

07:27 <re_irc> <@thejpster:matrix.org> It’s under #t-launching-pad

13:23 <re_irc> <@drewbus:matrix.org> Darius: aha! Well, first I took your sleep advice literally and passed out last night shortly after posting my message since it was after midnight here. Then this morning I threw a 10ms sleep in there and the errors are gone and the voltage is slowly changing. Thanks!

13:23 <re_irc> I’m making the kids breakfast so I can’t look, but I seem to remember something in either the embedded book or the discovery book about the need to not overshoot the clock. Am I on the right path to understanding what happened?

13:48 <Darius> drewbus: OK, I guess the question is why