XBee(s): Do you have to use Micropython to utilize I2C?

Question

I am kind of confused about the purpose for Micropython. At first I thought I would use it in my project... now I am not so sure. But I might have to use it?..

I can configure, set and get all the IO pin values just using python files. I am going to read a sensor's value and if that value is x then perform action y, else perform action z. I am going to make an I2C bus for my XBee. I guess the only reason I really need to use I2C is to act as a port expander for my device because I am going to use at least 21 IO ports (there are 15 IO pins). So, in that case I do need I2C but Micropython's purpose is confusing to me.Do I have to use Micropython for this?

Answer 1

Yes, you would need to use Micro Python to use the I2C interface. You can also use this interface to perform the logic you want as well.

Comments

Use micropython to load the hardware level code/firmware and then import the micropython into my main.py script?

I'll essentially need to have an I2C bus of sensors using Micropython and then, using python, the goal would be to reconfigure the NI of each remote xbee module depending on the sensor data. Does this make sense in reality?

---

No.  The i2c interface hardware and firmware already exist. Your Micro Python interface only needs to be able to pull the data, interpret and the address it came from. Then determine what you want to do with it.

---

I'm a novice so now I have come to more fundamental questions:

1.) Each I2C sensor on a I2C bus require a unique address. Is this specific to I2C or do sensors always hold a unique address by default regardless of the communication protocol?

2.) Normal python+xbee can't support I2C protocol by itself for reasons I dont understand, if you could make light of that concept separately that would be awesome for my brain.

So basically here was my original goal:
I have 10 mounting positions. I am going to have 10 remote_XBees. These XBees will be grabbed in random fashion and connected to a random mounting position.  Depending on the mounting position the XBee ends up in.. that XBee needs to function specific to that mounting position's needs. So at first I was thinking to run an I2C bus around to each position and have one sensor located at each mounting position. Then, when you connected the XBee to positionX, the xbee would see sensorX specific to that position and then that XBee would hit a set_NI("POSITIONX") line of code. and whalla, it would assume the functionality specific to that position because all the functionality is designed for particular NI string names. If you connected an xbee to positionZ, the xbee would see sensorZ and hit a set_NI("POSITIONZ") and so on and so forth.

But now I am thinking I was a bit off... An xbee module would "see" the whole line of sensors and not just one so it would have no clue it was in a specific mounting position right? I could instead have 10 separate I2C buses... one I2C bus at each of the 10 mounting positions. That way I dont need to link each mounting position together via wire. (2 reasons I am thinking of I2C, by the way.. 1. I am running out of I/O and so I2C will be my I/O expander solution.. and 2. I2C sensors have unique addresses and thus it makes for a good position indicator... if I'm not very very fundamentally wrong that is.

Thanks for your initial responses! and thanks in advance if you choose to engage with this long, multifaceted query lol. Much appreciated.

---

I am not an I2C expert by far but from my understanding, each device should have its own address.

Normal Python does not interface with the radio IO lines directly but via the UART.  The I2C port is not accessible via the radios direct Uart.

That is correct. The XBee would see the entire network connected to it so it would have no way of knowing where it is located in that loop.

---

Other non-I2C sensors don't have unique addresses?..


This is good stuff. Sparing me from saying silly things out loud to others like I've been doing apparently.