<re_irc> <@firefrommoonlight:matrix.org> How do you deal with I2C on devices that use 9-bit words, on hardware that only supports 8-bit words (eg STM32)? For example, the audio coded I'm using uses 7-bit register addresses, and 9-bit payloads, instead of 8 and 8. Do I just transmit as multiple bytes?
<re_irc> <@firefrommoonlight:matrix.org> Would I smoosh the address bits in with the data bits and still transfer 2 words, or transfer 3 words?
<re_irc> <@firefrommoonlight:matrix.org> eg:
<re_irc> <@firefrommoonlight:matrix.org> 1: Perfect world where I2C periph can support diff word lengths (Like you can with UART and SPI on this hardware)
PyroPeter has quit [Ping timeout: 268 seconds]
PyroPeter has joined #rust-embedded
<Darius> firefrommoonlight: I don't think that would work unless the receiver I2C device has some "compat mode"
<Darius> bit bang i2c? :D
<re_irc> <@henrik_alser:matrix.org> firefrommoonlight: What device is that? Are you sure it uses 9 bit words? That would not be valid i2c according to the specs… Sure the timing diagram is not just drawn in a confusing way so that the 9th clock cycle (that isn’t a bit but a line condition waiting for ack) looks like it’s part of the data?
loki_val has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@henrik_alser:matrix.org> I’ve had cases where the device was using 9 bit words internally for data, but still expected it to be split across 2 bytes, like [7 bit address, read/write bit], [7 bit register address, highest data bit], [lowest 8 data bits]
<re_irc> <@henrik_alser:matrix.org> Could this be what you’re after?
<re_irc> <@henrik_alser:matrix.org> bytes[0] = ((register << 1) & 0xfe) | ((data >> 8) & 0x01);
<re_irc> <@henrik_alser:matrix.org> bytes[1] = data & 0xff;
<re_irc> <@gauteh:matrix.org> gauteh:matrix.org: Ordered segger j-tag edu mini. Hopfully that works, if anyone has tried it already please let me know!
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> It's a WM8960 codec. From DS:
<re_irc> <@firefrommoonlight:matrix.org> > The WM8960 is controlled by writing to registers through a 2-wire serial control interface. A control
<re_irc> <@firefrommoonlight:matrix.org> word consists of 16 bits. The first 7 bits (B15 to B9) are address bits that select which control register
<re_irc> <@firefrommoonlight:matrix.org> is accessed. The remaining 9 bits (B8 to B0) are data bits, corresponding to the 9 bits in each control
<re_irc> <@firefrommoonlight:matrix.org> henrik_alser: I think that's a reasonable option 4
<re_irc> <@firefrommoonlight:matrix.org> Like option 3 but with most of the bits on the right
<re_irc> <@firefrommoonlight:matrix.org> I've been working off this to test option 2:
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> /// This codec uses a non-standard 7-bit-address, 9-bit data setup, so we use
<re_irc> <@firefrommoonlight:matrix.org> /// a custom function to manage this.
<re_irc> <@firefrommoonlight:matrix.org> And as you point out, i2C is a 8-bit protocol, so on the MCU (STM32), there isn't even an option for higher-bit words like there are for most comm periphs
<re_irc> <@firefrommoonlight:matrix.org> The data register is a fixed 8 bits
<re_irc> <@firefrommoonlight:matrix.org> Found a diagram in the DS. Looks like it's #2
<re_irc> <@firefrommoonlight:matrix.org> So theoretically that function I have should work
<re_irc> <@firefrommoonlight:matrix.org> Although it's still ambiguous about about which bits are which. I'm assuming it's all left-to-write
<re_irc> <@henrik_alser:matrix.org> Cool, yes that diagram shows exactly what i meant :)
<re_irc> <@firefrommoonlight:matrix.org> Looks like I misread! I think what we posted are equivalent
<re_irc> <@henrik_alser:matrix.org> (I just left out the addr + r/w bit in my code example)
<re_irc> <@firefrommoonlight:matrix.org> Getting a pile of nacks, working through that now
<re_irc> <@henrik_alser:matrix.org> How are you doing your addr? Some of those devices have a confusing way of specifying address in the datasheet
<re_irc> <@firefrommoonlight:matrix.org> This fits that category
<re_irc> <@firefrommoonlight:matrix.org> I'm interpreting `19h` as `0x19`
<re_irc> <@firefrommoonlight:matrix.org> What's odd is that the device access is specified using the `x` notation: `The device address is 0011010 (0x34)` (and binary)
<re_irc> <@firefrommoonlight:matrix.org> Wait that doesn't make sense
<re_irc> <@firefrommoonlight:matrix.org> those aren't het same number
<re_irc> <@firefrommoonlight:matrix.org> Unlelss you bitg shift
<re_irc> <@firefrommoonlight:matrix.org> URGG I think you're on to something
<re_irc> <@firefrommoonlight:matrix.org> that's horribly confusing/conflicting
<re_irc> <@henrik_alser:matrix.org> Haha yes super annoying
<re_irc> <@firefrommoonlight:matrix.org> I don't think even ST does anything that off the wall
<re_irc> <@henrik_alser:matrix.org> So could be that you need to left shift it or not
<re_irc> <@firefrommoonlight:matrix.org> I'm now curious if the other addresses need a shift as well
<re_irc> <@henrik_alser:matrix.org> And ”and”/”or” the r/w bit
<re_irc> <@firefrommoonlight:matrix.org> Very likely could be
<re_irc> <@henrik_alser:matrix.org> firefrommoonlight:matrix.org: Yes, the code i suggested should be the way to do it
<re_irc> <@firefrommoonlight:matrix.org> awesome
<re_irc> <@firefrommoonlight:matrix.org> I'll give it a try
<re_irc> <@henrik_alser:matrix.org> Cool! Hope it works!
<re_irc> <@firefrommoonlight:matrix.org> I appreciate the help - I don't think I'd have ever figured this out on my own
<re_irc> <@henrik_alser:matrix.org> Happy to help, this has had me confused aswell in the past :)
<re_irc> <@henrik_alser:matrix.org> (To clarify, i mean that depending on if your i2c driver code does an addr left shift and the r/w bit set/clear you might have to right shift the i2c address given in the datasheet by 1 `ADDR >> 1`
<re_irc> <@firefrommoonlight:matrix.org> That sounds reasonable based on the device address notation
<re_irc> <@firefrommoonlight:matrix.org> Although I can't get it to ack on the device address
<re_irc> <@henrik_alser:matrix.org> If you use `0x34 >> 1` in the address position of the hal’s write fn?
<re_irc> <@firefrommoonlight:matrix.org> Yea, that's how you have to do it
<re_irc> <@firefrommoonlight:matrix.org> STM32 has a specific address field
<re_irc> <@firefrommoonlight:matrix.org> And it's the shifted one you need to put in there
<re_irc> <@firefrommoonlight:matrix.org> evidently
<re_irc> <@firefrommoonlight:matrix.org> But still NACK
<re_irc> <@firefrommoonlight:matrix.org> Wait you're right; the HAL code bit shifts it by one in teh address field
<re_irc> <@firefrommoonlight:matrix.org> and then another field sets read/write
<re_irc> <@firefrommoonlight:matrix.org> So, it's failing before we even get to the device's command registers
<re_irc> <@henrik_alser:matrix.org> Strange… did you triple check the connections and pullup resistors? Running at the right speed?
<re_irc> <@firefrommoonlight:matrix.org> Could be something like that. I'm using a weird Raspberry Pi Waveshare HAT
<re_irc> <@firefrommoonlight:matrix.org> Checking valid speed range now
<re_irc> <@firefrommoonlight:matrix.org> I2C line is set up for 100kHz
<re_irc> <@henrik_alser:matrix.org> Pullups are in place? Can you scope it?
<re_irc> <@firefrommoonlight:matrix.org> I have a scope here in addition to the LA. What should I scope?
<re_irc> <@firefrommoonlight:matrix.org> Using software PUs
<re_irc> <@firefrommoonlight:matrix.org> I2C speed is fine; just needs to be < 500K
<re_irc> <@henrik_alser:matrix.org> If you probe the SCL and SDA lines it might give some electronic clues you can’t see on the LA
<re_irc> <@henrik_alser:matrix.org> Stm32 internal pullups are a bit on the high side (40k) but should be ok at 100k
<re_irc> <@firefrommoonlight:matrix.org> I wonder if I just have something wired up wrong etc as you said
<re_irc> <@firefrommoonlight:matrix.org> The docs for this board are kinda crap
<re_irc> <@firefrommoonlight:matrix.org> I'm basically visualizing the pinout overlaid onto a Raspbery Pi pins
<re_irc> <@firefrommoonlight:matrix.org> It *should* work, since all the pins I need from the chip are exposed
<re_irc> <@henrik_alser:matrix.org> Yes double check the SCL, SDA and GND connections and that the device has power :)
<re_irc> <@firefrommoonlight:matrix.org> haha good point
<re_irc> <@firefrommoonlight:matrix.org> Oh fuck I'm reviewing the schematic
<re_irc> <@firefrommoonlight:matrix.org> The Chip can go down to low voltages, but I think the board uses a 5V pin with a reg for everything...
<re_irc> <@firefrommoonlight:matrix.org> So it probably doesn't have power
<re_irc> <@henrik_alser:matrix.org> Also, sometimes you have to put a delay before you try to communicate with it in case the rail is brought up at the same time as your mcu
<re_irc> <@henrik_alser:matrix.org> firefrommoonlight:matrix.org: Ahh, and you don’t power that 5v rail?
<re_irc> <@firefrommoonlight:matrix.org> correct
<re_irc> <@firefrommoonlight:matrix.org> Trying to figure out how to get probes onto various parts of this thing
<re_irc> <@firefrommoonlight:matrix.org> I think the "3.3V" I powered just means that's the raspberry pi pin
<re_irc> <@firefrommoonlight:matrix.org> I don't think I have any current going to the board!
<re_irc> <@firefrommoonlight:matrix.org> So, you correctly diagnosed, again
<re_irc> <@firefrommoonlight:matrix.org> I'm tempted to jsut make a board and get it ordered. Might be easier than dealing with this
<re_irc> <@firefrommoonlight:matrix.org> (obviously teh turnaround isn't ideal...)
<re_irc> <@firefrommoonlight:matrix.org> Hmm, have it powered now (At the the regulator is getting 5V and outputting 3.3V) Still nack. Will keep testing stuff
<re_irc> <@firefrommoonlight:matrix.org> Got a probe onto the chip's QFN power pin. Getting juice now
<re_irc> <@henrik_alser:matrix.org> Good progress, and what does it look like on the scope?
<re_irc> <@henrik_alser:matrix.org> Do you have some delay before trying talking to it, to allow the voltages to stabilize on boot if it’s powered from a devboard 5v?
<re_irc> <@firefrommoonlight:matrix.org> No
<re_irc> <@henrik_alser:matrix.org> If it’s reset on flashig
<re_irc> <@firefrommoonlight:matrix.org> Good point
<re_irc> <@firefrommoonlight:matrix.org> I'll try a delay
<re_irc> <@firefrommoonlight:matrix.org> (it is indeed powered (now) by a devboard 5v)
<re_irc> <@firefrommoonlight:matrix.org> Still nacking with delay. Going to find some wires to properly connect the scope with
<re_irc> <@henrik_alser:matrix.org> Yeah! Gotta go make dinner, bbl!
<re_irc> <@firefrommoonlight:matrix.org> later! Thanks again
<re_irc> <@henrik_alser:matrix.org> Any scoping insights?
<re_irc> <@firefrommoonlight:matrix.org> Nah - will take a look this afternoon
<re_irc> <@firefrommoonlight:matrix.org> I have teh LA hooked up with female-to-male-pins, but need to grab some male ones to clip the scope leads to
<re_irc> <@firefrommoonlight:matrix.org> You think on the SCL/SDA signals, there may be anomalies not shown on LA's discrete levels?
<re_irc> <@firefrommoonlight:matrix.org> Insights collected so far: Board (now) has power. Chip (now) has power. MCU appears to be sending the correct I2C data. Codec is NACKING
<re_irc> <@henrik_alser:matrix.org> It can reveal if you have problems with the pullup resistors etc
<re_irc> <@firefrommoonlight:matrix.org> You think I should try hardware PUs?
<re_irc> <@henrik_alser:matrix.org> It’s the more dependable option to do but if you verify the signals are ok then it should work with the internal ones
<re_irc> <@henrik_alser:matrix.org> I always go for external
<re_irc> <@henrik_alser:matrix.org> Also double check you didn’t swap SDA and SCL :)
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 245 seconds]
<re_irc> <@firefrommoonlight:matrix.org> Hah. Quadruple-checked that one!
<re_irc> <@firefrommoonlight:matrix.org> Big trap since the pins are in a diff order on MCU board and codec board from my perspective
<re_irc> <@firefrommoonlight:matrix.org> I had them swapped on the LA at first
<re_irc> <@henrik_alser:matrix.org> Classic :)
<re_irc> <@henrik_alser:matrix.org> Did you continuity check those lines all the way from the mcu to the codec pins?
<re_irc> <@firefrommoonlight:matrix.org> Nope
<re_irc> <@firefrommoonlight:matrix.org> The schematic for the codec board shows a direct connection to the chip, buy I should check that once I get back
<re_irc> <@firefrommoonlight:matrix.org> The probe seems fine enough to hit the qfn pins if I'm lucky
<re_irc> <@henrik_alser:matrix.org> How long do you wait after boot up now?
<re_irc> <@firefrommoonlight:matrix.org> 500ms
<re_irc> <@firefrommoonlight:matrix.org> Systick delay
<re_irc> <@henrik_alser:matrix.org> Should be enough i guess, but depending on what capacitance is on those rails it might take a while to charge up (especially it it’s an audio board chances are it’s got pretty big caps)
<re_irc> <@henrik_alser:matrix.org> But maybe you retry in a loop?
<re_irc> <@firefrommoonlight:matrix.org> Good call
<re_irc> <@firefrommoonlight:matrix.org> I should be able to test again later today
DepthDeluxe has joined #rust-embedded
DepthDeluxe has quit [Remote host closed the connection]
DepthDeluxe has joined #rust-embedded
DepthDeluxe_ has joined #rust-embedded
DepthDeluxe_ has quit [Remote host closed the connection]
<re_irc> <@firefrommoonlight:matrix.org> Good continuity between chip leads and SDA/SCL pins
DepthDeluxe has quit [Ping timeout: 264 seconds]
DepthDeluxe has joined #rust-embedded
<re_irc> <@henrik_alser:matrix.org> firefrommoonlight: did you try with a longer power up delay?
<re_irc> <@firefrommoonlight:matrix.org> No. Trying now
<re_irc> <@firefrommoonlight:matrix.org> (This is probably something real dumb like an unconnected wire etc)
<re_irc> <@firefrommoonlight:matrix.org> Nack even with 2s delay
<re_irc> <@henrik_alser:matrix.org> firefrommoonlight:matrix.org: Lol, that’s usually what it is
DepthDeluxe has quit [Ping timeout: 264 seconds]
DepthDeluxe has joined #rust-embedded
DepthDeluxe has quit [Ping timeout: 264 seconds]
Shellhound has quit [Quit: ZNC 1.8.2 - https://znc.in]
emerent_ has joined #rust-embedded
emerent is now known as Guest2829
emerent_ is now known as emerent
Guest2829 has quit [Ping timeout: 268 seconds]
Shell has joined #rust-embedded
Shell has quit [Remote host closed the connection]
Shell has joined #rust-embedded
DepthDeluxe has joined #rust-embedded