<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
<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
<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>
…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
<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]>
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
<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
<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]