![]() This makes some intuitive sense: since I☬ is an open-collector bus that is pulled up, if no device responds, the default value will be a logic '1'. All the following bytes (and ACK bits) involve either the selected device or the host all other devices stop listening after the address until the next Start condition. What this diagram doesn't show is that an I☬ transaction starts with a byte consisting of the 7-bit device address and a read/write (R/#W) bit, followed by an acknowledge bit (ACK) from the slave if a device recognized the address. Data is therefore clocked out on the falling edge of the clock and clocked in on the rising edge. In the data phase, data always transitions when the clock is low if the data transitions during a high clock, it's an out-of-band framing signal. The Start condition (denoted by S) consists of a falling SDA (Serial DAta) while SCL (Serial CLock) is high, while the Stop condition (denoted by P) is the opposite (SDA rising while SCL is high). Here's a diagram of a (simplified) I☬ transaction: Simple I☬ transaction read from a device immediately after you've written the register address. In certain circumstances you can issue a "repeated Start" without issuing a Stop condition to e.g. It uses specific Start and Stop sequences to begin and end transmissions devices start listening to their address after a Start condition and stop listening to everything after a Stop until another Start is issued. I☬ is designed as a low-speed protocol for connecting lots of devices together reliably. Both protocols clock data in on the rising edge of the clock. The question was: would I be able to run both protocols over the same wire without a) unnecessarily loading things, or b) triggering spurious commands on a device I wasn't actually talking to? Common elementsīoth protocols share some common elements: They are both two-wire, multipoint bus protocols which communicate over open-collector lines (this is a bit hand-wavy in I☬, both the data and clock lines are open-collector because slave devices can stall the clock line to get more time to complete a command, while in MDIO the clock is generally only driven push-pull from the master, but none of that is going to hurt us here). I'll link to the Wikipedia pages for both, which provide decent summaries (and I'm going to steal some images from them below): I☬ and MDIO are both pretty simple protocols (MDIO being the simpler of the two). So I decided to investigate outright sharing. The latter is out of the question there are no spare pins on the ESP32, and putting the selector pin on an I☬ GPIO line would be problematic because once you switched away from I☬, there'd be no way to switch back. What I was hoping was that I might be able to share the MDIO and I☬ lines either outright or with some sort of multiplexing arrangement using an external multiplexer and a select line. However, again, there's just not a spare pin even for one chip select line. I had hoped to include SPI for higher-speed peripherals (for example, I☬ is fine for character-oriented displays, but it's miserable for pixel-oriented ones, not least because the ESP32's I☬ unit isn't DMA-capable). MDIO is used to configure the Ethernet PHY. Windy uses I☬ for one or more GPIO expanders and the temperature sensor, and potentially LCD/OLED output displays. For all its merits as a microcontroller (and there are a lot), I wish they'd come out with a larger package with more pins (a 64-pin package would allow them to bond all the internally available GPIOs and then some). As I mentioned in the previous log, I'm a little short on pins to hit every function on the ESP32.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |