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
emerent has quit [Ping timeout: 258 seconds]
emerent has joined #rust-embedded
sparky[m] has joined #rust-embedded
<sparky[m]> what sort of error is NoAcknowledge for an I2C device? pretty sure i got my driver written right for a basic "read the serial from the proper register" test, but i keep getting that back as an error code
crabbedhaloablut has joined #rust-embedded
<sparky[m]> hmm... looking more, i have no earthly idea whats going on? seems like its for the bus/device on bus doesnt exist, but i have the device address right and have verified the connecting pins line up. i wonder if it has to do with the hal as its clearly got a bunch of i2c pins not implementing the sda/scl traits even though the pinout diagram says it should? im using pins that implement it for the proper bus according to the diagrams
<sparky[m]> but... no changes. even cut back the wiring a lot as it used to be chained through multiple devices and now its direct. no changes ☹️
<waveguide[m]> Does anyone know offhand how many cycles a defmt::println might take on a standard ish cortex-m with defmt-rtt
<waveguide[m]> * with defmt-rtt? Seems to take a surprising number on an imxrt part, like 2000 or so cycles… or 3uS which seems longer than I would have expected for a dictionary logger to rtt setup
<waveguide[m]> For my own benefit I tried the same setup on a stm32f446 and got 858 cycles very consistently
<FlixtheNewbie[m]> I didn't see the conversation about FLASH yesterday, but never mind, I don't need it, it was a theoretical question. Just curious about what I can do or not.
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
Guest7221 has joined #rust-embedded
cr1901 has joined #rust-embedded
<thejpster[m]> <sparky[m]> "hmm... looking more, i have no..." <- Did you get 7 bit and 8 bit addresses mixed up? Often happens to me.
therealprof[m] has joined #rust-embedded
<therealprof[m]> <sparky[m]> "hmm... looking more, i have no..." <- Got pullups?
fu5ha[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
jake_001[m] has quit [Quit: Idle timeout reached: 172800s]
<sparky[m]> <thejpster[m]> "Did you get 7 bit and 8 bit..." <- datasheet did say 7 bit address. hows that vary in implementation/use in code from 8 bit ones??
<sparky[m]> <therealprof[m]> "Got pullups?" <- its a pico w with a daughterboard that has the sensor on it, so i assume so yes
<sparky[m]> s/??/?/
<JamesMunns[m]> sparky sometimes if the 7-bit address is noted as `0x7F` or `0b0111_1111`, some datasheets will shift it over to the left, e.g. `0xFE` or `0b1111_1110`
<JamesMunns[m]> This is because the lowest bit is actually the "write/read" bit
<JamesMunns[m]> so if the 7-bit address was 0x7F, the actual value would be 0xFE for write and 0xFF for read
<sparky[m]> well, i can try that. the docs i looked up elsewhere seem to indicate i have the address proper though... bmp390, looks like primary is 0x77 and secondary is 0x76, with the device currently configured to 0x77
<JamesMunns[m]> I think the convention for most HALs (I always have to check) you would do read 0x7F which actually writes0xFF on the wire, and write 0x7F which writes 0xFE on the wire
<sparky[m]> i see
<JamesMunns[m]> yeah, I would call that 0x76 or 0x77
<sparky[m]> dont i need to left shift it one though? or am i reading that wrong?
<JamesMunns[m]> Like I said, that's a convention thing. which HAL are you using?
<JamesMunns[m]> rp-hal or embassy?
<sparky[m]> embassy-rp
<JamesMunns[m]> yup, embassy-rp enforces that addresses are <= 0x7F, so you should use `0x77` or `0x76`.,
<JamesMunns[m]> s/`.,/`./
<JamesMunns[m]> What daughterboard are you using?
<JamesMunns[m]> Is your code public somewhere? That board does have pullups.
<sparky[m]> you want the driver or the driver+embassy side?
<JamesMunns[m]> So i'd probably guess some kind of wrong I2C configuration, possibly the pins or the interface speed
<JamesMunns[m]> probably both!
<sparky[m]> if its pins i swear ive checked the count and wiring diagrams and id be a bit upset at my ability to count if its wrong lol
<sparky[m]> JamesMunns[m]: k. give me a bit, and sorry for the quality lol
<sparky[m]> not much there beyond a lot of consts. for now, only trying to read and print the chip id register
<sparky[m]> * id register. super early days, so shouldnt have much cruft or extra to sort through
<JamesMunns[m]> The pico-w doesn't have a stemma-qt connector built in. Which four pins are you using with it?
<sparky[m]> JamesMunns[m]: should be 38 and 36 for power, then 14 as SDA and 15 as SCL assuming ive wired things right
<sparky[m]> * be 38 (gnd) and 36, * and 36 (3.3v) for power,
<JamesMunns[m]> is that GPIO14/15 or PAD14/15
<JamesMunns[m]> PAD 14/15 are GPIO10/11
<sparky[m]> yeah, 14/15 as shown in that image in light gray
<JamesMunns[m]> and GPIO 14/15 are PAD19/20
<JamesMunns[m]> this should probably be PIN_10 and PIN_11 then
<sparky[m]> is that what ive been getting wrong all this time? ugh
<JamesMunns[m]> in most HALs the GPIOs are indexed to the CHIP, not the BOARD
<JamesMunns[m]> sparky[m]: Hey, I'll take a silly problem with an easy fix over a complicated problem any day!
<sparky[m]> doesnt seem to have changed a thing
<JamesMunns[m]> hmmm
<JamesMunns[m]> well, I gotta run, but here's a dump of my thought process in case someone else can help:
<JamesMunns[m]> it looks like you might have that rotated 180 degrees
<JamesMunns[m]> notice how 36 and 38 are close to the "top right" with USB being "up"?
<sparky[m]> ugh...i just realized uart0 is on both "tops"
<sparky[m]> thats how its been flashing all this time and why i though i had it right...
<sparky[m]> well, let me try that 😆
<JamesMunns[m]> Yeah, all the other stuff looks right. you are using 3v3 for power (good), the default config is 100khz (good)
<JamesMunns[m]> I would bet it's just the pinout not matching.
<sparky[m]> and... now i see there is a power LED on the daughterboard
<sparky[m]> its now lit...
<JamesMunns[m]> Hey, that's progress!
<sparky[m]> so... any different using the "bottom" uart0 for flashing over the "top"?
<sparky[m]> assuming the top has teh USB port
<sparky[m]> s/teh/the/
<JamesMunns[m]> I'm not sure what you mean? Flashing usually happens over SWD or USB, not UART
<sparky[m]> well.. then i guess no problem lol
<JamesMunns[m]> yeah, if you're using probe-run, you flash over the SWD header (in the middle), not over UART.
<sparky[m]> wonder why it didnt look like it was working without the UART hooked up then?
<JamesMunns[m]> dunno! But probe-run definitely does not use the UART.
<sparky[m]> am using another pico to flash it, so maybe thats why?
<JamesMunns[m]> Really not sure!
<JamesMunns[m]> Is it possible you were shorting the board or something when you had the rest of the pins "backwards"?
<sparky[m]> thankfully, it doesnt seem so
<sparky[m]> everything was working fine except the above and it was the only thing taking power from this board
<sparky[m]> everything else is USB powered, so i dont think i got wires crossed anywhere in a dangerous fashion
<JamesMunns[m]> But yeah, IMO you only need:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JsdngiIpaFGbSNuBhxVAMMFq>)
<JamesMunns[m]> you shouldn't have any "more" wires than that connected.
<JamesMunns[m]> I would try with JUST those to start
<JamesMunns[m]> I do gotta run, but good luck, I think once you fix the pinout, and change the I2C pins (either on the board or in your code), it should probably work!
<sparky[m]> JamesMunns[m]: it isnt crashing anymore on running the init. just need to figure out why its not printing now 🙂 thanks for the assist, given it was entirely self inflicted 😆
<JamesMunns[m]> If it's blinking I think it worked! I don't see your code printing anywhere, it just blinks an LED in a loop
<sparky[m]> in the drivers init func, i take the returned data and print it. wont show in the embassy side
<sparky[m]> anyways.... thanksa again. really appreciate it!
<JamesMunns[m]> you only print in the Err cases, it looks like
<JamesMunns[m]> ah! your log level might be too low
<JamesMunns[m]> try switching that to println!
<JamesMunns[m]> I think defmt defaults to info-and-above
<JamesMunns[m]> (so NOT trace or debug)
<sparky[m]> yeah. changed it to info and no change. defmt::println! ?
<JamesMunns[m]> yep
<sparky[m]> Chip ID is 60 wonder why info! didnt work but println! did? i see other infos lol
<JamesMunns[m]> yeah, idk what's up with that :D
<JamesMunns[m]> maybe it's "info and above for the main crate", "warn and above for deps"?
<JamesMunns[m]> It's been a while. println never gets filtered out tho
<JamesMunns[m]> But hey, congrats! 🎉
<sparky[m]> now to make it more complicated, then clean it up with nicer abstractions lol
<sparky[m]> glad it wasnt my code at least! i really appreciate it
ilpalazzo-ojiis4 has joined #rust-embedded
<ilpalazzo-ojiis4> All errors appear related to .avrdude-B6zdW9.conf, but that's not a file I'd heard of before.
<JamesMunns[m]> What are you using to flash it? I would guess (based on it being random and in a temp dir) it is a generated file by whatever tool you are using
<JamesMunns[m]> (that being said: I have never tried to do Rust+AVR things, so I probably can't actually help)
<ilpalazzo-ojiis4> “What I'm using”? Just cargo run --release -- -P /dev/ttyACM0
<JamesMunns[m]> what is your cargo runner then? in .cargo/config.toml under the runner key
<ilpalazzo-ojiis4> runner = "ravedude mega2560 -cb 57600"
<JamesMunns[m]> I'd suggest checking out (or opening) an issue here: https://github.com/Rahix/avr-hal/tree/main/ravedude
<JamesMunns[m]> Perhaps you are using avrdude v7, which isn't supported yet?
<ilpalazzo-ojiis4> avrdude version 7.1
<ilpalazzo-ojiis4> The queer thing is that about a month ago I was doing things just fine.
<JamesMunns[m]> did you do a brew upgrade or something?
<JamesMunns[m]> (or equivalent package manager upgrade, e.g. apt-get upgrade, pacman -Syu, etc.)
<ilpalazzo-ojiis4> …yes, and my distribution went to sh██ as a result.
<ilpalazzo-ojiis4> (I still have no sound, and have to recover my Windows partition too at some point.)
<JamesMunns[m]> it's likely you or your package manage decided to update avrdude from 6.x to 7.x, which isn't supported by ravedude
<ilpalazzo-ojiis4> Still…
<ilpalazzo-ojiis4> …the error in the thing you posted is that it wouldn't flash.
<JamesMunns[m]> it looks like avrdude had a breaking change to their conf file format, which I'm guessing is generated by ravedude
<ilpalazzo-ojiis4> In my case it does flash, it just outputs some nonsensical warnings.
<JamesMunns[m]> if ravedude can't "talk" to avrdude "right", it'll get confused.
<JamesMunns[m]> your paths forward IMO are:
<JamesMunns[m]> * Assist with that linked issue to add support for avrdude 7.x to ravedude
<JamesMunns[m]> * revert to avrdude 6.x, pin the package somehow
<ilpalazzo-ojiis4> 3) see if maybe things work right now so I can stick my head in the sand and pretend nothing's wrong.
Guest7221 has left #rust-embedded [Error from remote client]
<korken89[m]> <dirbaio[m]> "I have an extended version..." <- I found the message! Yes please, I'm very interested to give it a try :D
<dirbaio[m]> 🤣
<korken89[m]> :D
<dirbaio[m]> will do, will need some time to split it from the main project
<korken89[m]> Thank you for making it available!
Guest7221 has joined #rust-embedded
<ilpalazzo-ojiis4> The ostrich method appears to have worked.
<ilpalazzo-ojiis4> * The so-called “ostrich method” appears to have worked.
raulvt[m] has joined #rust-embedded
<raulvt[m]> the community is still writing a driver every two weeks?
<raulvt[m]> read this somewhere on the wiki, is there some live coding?
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]> <dirbaio[m]> "will do, will need some time..." <- Btw, have you tested `salty`? Saw that it had support for both X25519 and Ed25519 (released 2 days ago): https://github.com/ycrypto/salty/
dsvsdveg[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> yeah
<dirbaio[m]> I don't remember if it was around back then
<dirbaio[m]> the emill asm is faster tho
<korken89[m]> Noticed the same, seems to be a bit different aims where they go for understandable code
<korken89[m]> Nice to see though :)
crabbedhaloablut has quit []
barafael[m] has joined #rust-embedded
<barafael[m]> I am seeing a BusWriteError while using an SSD1306. I'm driving it with 1MHz, the error does not happen with a lower frequency. My micropython firmware also uses this frequency and works reliably.
<barafael[m]> Looking at saleae, it appears to be a sudden NAK by the display.
<barafael[m]> notably, the Rust variant (second image) only takes 2ms, the micropython variant takes 11ms
<barafael[m]> I don't think it is my cabling, because my error isn't occurring with the micropython variant. The rust variant seems to "pack" the data into a compact frame while the micropython variant is more relaxed.
<barafael[m]> I'll try to get ssd1306 crate to not pack the data so tightly and see if that improves it
<FreeKill[m]> Are your microcontroller pins definitely set up the same both times? 1Mhz is fast for i2C, often you need to configure pins in a special "hi speed" mode to go that quick
<FreeKill[m]> Maybe the micropython does that for you, and the rust doesn't?
<barafael[m]> that could be, I'll check that, thanks
<FreeKill[m]> One trick you could pull is setting up your logic analyser as fast as it will go, and comparing the pulse width in both cases. If it is different, then you know they're doing something different in the hardware
<barafael[m]> rust: exactly 500ns, upython: sometimes 500, sometimes 563ns
<FreeKill[m]> Ehhh that might not mean much then
<FreeKill[m]> If it's flickering between two values then you're likely not high enough resolution to really measure it
ian_rees[m] has joined #rust-embedded
<ian_rees[m]> barafael: do you have an oscilloscope (or one of the Saleae Logics that can do analog)? As FreeKill says it could be that the rise/fall isn't quite fast enough for that clock speed
<barafael[m]> I measured again with 100ms/s, it looks like the clock signal looks right
<barafael[m]> s/it looks like//, s/looks/is/, s/right/identical/
<barafael[m]> 520ms every time
<barafael[m]> I'm not sure how i can configure the slew rate for a sda/scl pin in embassy, as the I2c::new_async and I2c::new_blocking constructors only take peripherals, not pins. I might have to configure the GPIOs, then mem::forget them, steal them again, and only then put them into the i2c constructor
<FreeKill[m]> Do you have a debugger?
<barafael[m]> yes
<barafael[m]> hs-probe
<FreeKill[m]> Then before you wonder about how to do it, better to check it's necessary
<FreeKill[m]> Pause your program after init and look at how your pins are configured
<barafael[m]> yeah, good idea. Never flipped bits without the UI in eclipse. I think I may do it using PAC access also?
<FreeKill[m]> It would be nice to believe you have access to a register viewer
<FreeKill[m]> But if you haven't got that set up then yeah you'll probably have to dump the register contents with the pac
<FreeKill[m]> But if you're seeing a clean 520ns on both implementations, this probably isn't the answer
<barafael[m]> but the signal really looks solid, yeah
<FreeKill[m]> Do you get nackd every time or just sometimes?
<barafael[m]> just sometimes, pretty random
<barafael[m]> I still suspect it's the packing that ssd1306 does
explodingwaffle1 has joined #rust-embedded
<explodingwaffle1> what mcu is this? seems kinda important 😅
<FreeKill[m]> What makes you think you can run this device at 1mhz
<barafael[m]> that it does work flawlessly since months using upython :D
<FreeKill[m]> Its datasheet says min clock period 2.5us, that's 400k
<FreeKill[m]> If you're operating beyond the bounds of it's spec, all bets are off
<FreeKill[m]> Maybe you're getting away with it in uPy because your data is spread out over a long time and somehow that plays nicely with the chip
<barafael[m]> it may be different display. It's a 2.5inch version of ssd1306
<barafael[m]> i'm looking for datasheet
<barafael[m]> hard to find, not a good sign. I am probably getting away with it somehow. I'll try not squishing the frames and see if that works
<barafael[m]> it's a RG12864C-YHW-V but that doesn't tell me anything about the driver chip
<FreeKill[m]> This?
kenny has joined #rust-embedded
<barafael[m]> yes
<barafael[m]> but I'm not sure what is the driver chip, as I use it as if it was an ssd1306
Guest7221 has left #rust-embedded [Error from remote client]
<barafael[m]> I set it to 400kHz and put a heavy box on the start button. I'll let it run till tomorrow to see if there is an issue at the lower frequency still
<FreeKill[m]> Well that says an nt7107
<FreeKill[m]> The pin out doesn't even look like i2c
<FreeKill[m]> What pins are you connected to?
<barafael[m]> yeah, it's strange... I'm interfacing with this exactly as an ssd1306, I even used a small normal ssd1306 as a prototype
<FreeKill[m]> Yeah so it's still a 400khz part
<FreeKill[m]> You're just clocking it much faster than it's designed to accept
<barafael[m]> ...
<FreeKill[m]> 🤷‍♀️ not the most fun answer maybe 😅
<barafael[m]> Clock Cycle Time minimum is 2.5us, so that's it
<barafael[m]> I'm absolutely confused how this could work for monts continuously.
<barafael[m]> Thank you for your help!
<FreeKill[m]> If you are out of spec, then it's just about if you happen to tickle the hardware just right
<FreeKill[m]> Maybe because python spaces stuff out, internal buffers in the display controller never fill up and it just happens to work
<FreeKill[m]> Who knows
<barafael[m]> I'll try blastingthe entire display in upython and see what happens
<barafael[m]> * I'll try blasting the entire display in upython and see what happens
<barafael[m]> takes a while, but happens
<FreeKill[m]> 😊
<FreeKill[m]> I hope you can live with 400khz
<barafael[m]> I can live with it, but it's definitely noticeable...
<FreeKill[m]> What's noticeable?
<barafael[m]> the python and fast rust version look snappy, the slower one definitely noticeable
_whitelogger has joined #rust-embedded
<barafael[m]> yeah, it's not critical... I may dig in here, or may leave it :D the display is anyhow underspecced for what we are trying to do. It's an existing design yada yada
<FreeKill[m]> Well good luck
<barafael[m]> thanks so much :) great help.
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has joined #rust-embedded
dav1d has quit [Ping timeout: 248 seconds]
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #rust-embedded
dav1d has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]