Home/Support/Support Forum/So, you can run firmware(MicroPython Project) and software(Python Project) concurrently(same time).

So, you can run firmware(MicroPython Project) and software(Python Project) concurrently(same time).

0 votes
So, you can run firmware(MicroPython Project) and software(Python Project) concurrently(same time) on an XBee3 network? Like if I turn on an xbee that has micropython uploaded to the device (firmware) that runs automatically when powered on, and at the same time I run my main Python program that has all the GUI buttons and functionality already developed... is that fine/good/normal/ok?

Overview:

I have an XBee3 network where my GUI developed in Python allows you to press buttons and stuff (widgets) which run functions that turn on/off pins on the XBee3 chip. I ran out of I/O so I attached a slave device MCP23017 i2c I/O expander on an i2c bus facilitated by each XBee remote router module acting as the master. (Each router module is the master to its respective io expander slave on its own i2c bus)

So the i2c interface on the XBee3 is accessible via MicroPython. Separately, once an XBee3 module is powered on, MicroPython runs on the chip in a way that sends the coordinator an AT command telling the coordinator that router module's MAC address so then the coordinator can reply back with a configuration profile that the router must apply to itself (the powered on router reconfigures depending on where it is plugged in).

All this works as long as:
1.) Python program and MicroPython program both may run same time.
and
2.) sending and receiving back and forth between micropython and python is fine and good.

Anything critically flawed with my understanding here?

thank you very much.

thanks!
asked Jul 30 in MicroPython by edunn106 New to the Community (24 points)

Please log in or register to answer this question.

1 Answer

+2 votes
 
Best answer
Hi,

Absolutely, that is fine.

You really can think of MicroPython running on an XBee 3 device completely separately from any programs you run on a host device (such as Python in your case). The XBee 3 device is completely agnostic to what kind of program is communicating with it.

You could do any of the following:
- Have no MicroPython program on any nodes of the network, and do all the programming on one or more hosts. (This is the only option when using just older XBee models that do not support MicroPython programmability.)
- Have no programs talking to the XBee 3 at all, and run only MicroPython on nodes in your network. (That wouldn't be a very useful network without a way to get data/messages out to some host, but nothing's stopping you.)
- Run MicroPython on one or more XBee 3 nodes, and use Python/Java/C/C++/any programming language (or manual entry of API frames if you're desperate!) to manage communicating with the XBee 3. You can use User Data Relay API frames to communicate between MicroPython and the serial port.

Hope this helps.
answered Jul 31 by tckr Veteran of the Digi Community (404 points)
selected Jul 31 by edunn106
The nodes on a network can have any combination of ATAP settings.  The coordinator can use ATAP=1 and the routers can use ATAP=4.

ATAP is only used to control how the serial port of the XBee works.  0="transparent" mode (raw, unframed data), 1 and 2 are API modes (framed data) and 4 is MicroPython (REPL and running program output on serial port).
ok I lied, when I switch the routers to ATAP=4 and then run the python where it discovers them like usual, program runs fine..

what the fudge. the intro documentation makes you think API is for multi-node.. AT is for 2 devices in total.

guess not.
ok so..

in my network of 3 devices (1 coord, 2 routers)

if both routers are in AT modes Coordinator in API... python program ive developed works fine.

if all 3 in AT mode... then I get that immediate error saying Unsupported operating mode: AT mode


So the coordinator is what matters with the whole api vs at modes??? only the coordinator lol?

so I can indeed have the coordinator in API mode..

and all the routers in AT=4 or AT=1 mode and poof all the things ive been going on about the past week don't matter at all?

I can send all the stuff I want in python or micropython, transmit receive between the two no problem??

whats the point of having the routers in api vs at modes then.. why aren't routers/end devices just always in AT modes without the option to switch if they can do it all in AT modes?..

but then I guess the firmware transmit ******* I did yesterday/today with having the JN=1 on each router device so it sends an API packet wont work if the routers are in AT mode.. cuz then they won't send the API packet that I've parsed...

so I can just go back to my micropython start-up thing maybe


thanks btw
It's much simpler than that.  Re-read my message about what ATAP means.

AT mode (0) means the serial port is configured for transparent data.
API mode (1, 2) means the serial port is configured for framed data.
MicroPython mode (4) means the serial port is configured for the MicroPython REPL and running program.

Different customers will use different modes for their deployed network.  In general, if you have another microprocessor interfaced to the XBee via its serial port, you'll want to run in "API mode" so you're sending and receiving API frames.  If you have a "dumb" device that can't parse data, you typically run in "AT mode" to transparently send/receive serial data.

It has nothing to do with whether it's a coordinator or a router.  It has everything to do with what you're going to connect to the serial port.  Your coordinator has a PC running Python code expecting an XBee module in API mode.  Your routers don't (as far as I can tell) have ANYTHING wired to the serial port.  So your routers can use ATAP=4 mode to work around the current XBee3 Zigbee bug where xbee.discover() doesn't work otherwise.
BTW, please send a link to the introductory documentation that wasn't clear, and we'll try to improve on it.
...