My hardware does not have access to the secondary MicroPython serial port. Not something that can be changed at this point.
I want to have MicroPython code running on startup that sends telemetry data to the DRM. Similar to the drm_http_requests sample for the XBC.
This works well using PyCharm when I have direct access to the XBC-V1-UT-001 in the dev kit, but as soon as I do a power cycle I lose access to the serial port. The code is still running, I can see it in DRM, but it does not respond to ctrl-anything or +++ etc on the serial port. Had to put it back in the dev kit and do a recovery process to get it back.
From what I have read so far, seems like there are several ways to do this. Just want some idea of the dangers and advantages of each one so I can pick the best architectural design.
1. Keep the serial port in Transparent mode and use ATFS commands to place the telemetry data in the file system, timestamp in the file name. Python code would just check for new files. JSON formatted status files. Control program would have to keep track of flash usage and purge old files.
2. Run the whole system in REPL mode, no programs running at startup, use stdin and stdout for JSON formatted status messages and control. A lot more work in the control micro end.
3. Run the whole process in REPL mode and simply launch a program with the telemetry data as an argument. The program would send the telemetry packet, log it and exit back into transparent mode. Don't know if another program can be running concurrently that keeps in touch with DRM, allowing access to the file system and program updates, or if this is necessary. Seems like the DRM can access the file system regardless of other code that may be running. Don't know if a power cycle will "kill" the REPL session and make the module inaccessible. Or does it just need a reset or DTR pin change to wake it up again? Maybe we have to go back to transparent mode before power cycle, but what about unanticipated power cyles?
4. Cobble up a MicroPython MODBUS master app that works over a pretend RS485 that is really the main serial port. Probably a ridiculous idea but if someone has already done it...
5. Configure RTS/CTS or DIO0 bits as GPIO and do a bit-bang I2C over those two bits. Super slow but that won't matter, there is a new 300 byte telemetry packet every half hour on this system.
Please realize, again, I have no access to the secondary serial port. Whatever we do, it has to be done with DIN/DOUT and /RESET, /DTR/DIO8, /CTS/DIO7, on/Sleep (via transistor, can't send to XBEE DIO9), AD0/DIO0. Pins 1,2,3,5,9,12,16,20.