Fastest development cycle


I’m addicted to fast development iterations so I can make small changes and immediately see them working (or not…). In particular, it makes a big difference if there’s not enough time to switch to some other window/activity between hitting “compile&flash” and seeing the resulting debug output from the app.

Before receiving a pile of xenons, argons, and borons I was using STM32 uC’s with a black magic probe. With platformio I could always have the serial monitor open in one window and then run pio in another. After saving my edits all I needed to do is switch windows, up-arrow, enter and <5 seconds later I’d see the app start in the serial monitor window.

With particle it looks like po-util is my best bet and a similar alt-tab, up-arrow, enter should kick off the process. Compilation and upload is fast too. But then I’m sitting there waiting for various blink patterns indicating “connecting” of sorts before my app actually starts. Plenty of time to switch to a browser window and start reading some blog and get side-tracked for 20 minutes… oops!

I’m sure one of you wise folks have figured this out :smile:


Is there a question to this? Do you want to have a discussion about the era of “immediate gratification”, or specific solutions to a problem you’re facing. Right now I’m unsure if this is about:

  • Sharing your development experience
  • Complaining about slow flashing/boot times
  • Lack of quick flashing options from native tools
  • Po-Util related stuff (@nrobinson2000)
  • :man_shrugging:

Setting up a connection takes time, little that can be done about that. If you’re in need of intimidate output, regardless of the connection state, you might want to look into System modes and Threading.


Like @Moors7 has mentioned, System threading is your best bet to run your code immediately.


Sorry, I should have been explicit, the question is “am I missing something?”.

Thanks for the suggestion, I’ll read up on that!

What do you guys do for edit-compile-debug cycle? Wait 20s-30s patiently while it goes through its motions before you see any result?

Is there a CI set-up that makes it easy to test things without involving any hardware?


Compared to how long it used to take to work on something like this, I find those 20-30s enjoyable short. I find this to be even shorter from time to time, even though I’m flashing from the Web IDE as opposed to over USB. I also try to make compiles more meaningful, and not flash it every single line I code. Depending on what kind of debugging you require, functions could be implemented in code that’d allow you to change variables in runtime.


I must be dense… but I’m still stuck…

I’m using po-util to flash a xenon. Once the flashing is done it takes a few seconds for the xenon to connect. I see the app running by the flashing pattern on the blue LED. How do I get Serial output printed in the setup() function? I takes my linux box anywhere from 5 to 30 seconds before it will let screen or miniterm connect to the usb-serial port. The error I get in miniterm is

could not open port '/dev/ttyACM0': [Errno 16] could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

The command line I use is

po dfu open -d /dev/ttyACM0; po xenon run compile-user; \
po xenon run flash-user; sleep 2; /dev/ttyACM0 115200

What I see in the system log after the flashing is:

Jan 20 18:13:21 soumak kernel: usb 1-2.4.2: USB disconnect, device number 39
Jan 20 18:13:22 soumak kernel: usb 1-2.4.2: new full-speed USB device number 40 using ehci-pci
Jan 20 18:13:22 soumak kernel: usb 1-2.4.2: New USB device found, idVendor=2b04, idProduct=c00e, bcdDevice= 1.00
Jan 20 18:13:22 soumak kernel: usb 1-2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 20 18:13:22 soumak kernel: usb 1-2.4.2: Product: Xenon CDC Mode
Jan 20 18:13:22 soumak kernel: usb 1-2.4.2: Manufacturer: Particle
Jan 20 18:13:22 soumak kernel: usb 1-2.4.2: SerialNumber: e00fce68a8f4dc1358b533f5
Jan 20 18:13:22 soumak kernel: cdc_acm 1-2.4.2:1.0: ttyACM0: USB ACM device
Jan 20 18:13:39 soumak ModemManager[466]: <warn>  Could not grab port (tty/ttyACM0): 'Cannot add port 'tty/ttyACM0', unhandled serial type'
Jan 20 18:13:39 soumak ModemManager[466]: <warn>  Couldn't create modem for device '/sys/devices/pci0000:00/0000:00:12.2/usb1/1-2/1-2.4/1-2.4.2': Failed to find primary AT port
Jan 20 18:14:01 soumak kernel: audit: type=1006 audit(1548036841.335:313): pid=20308 uid=0 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=240 res=1

After the last 3 messages I can open /dev/ttyACM0 and serial output works, but I’ve lost everything that happened since the xenon’s reset.

So there seems to be some driver issue at play, any suggestions?


You can do

particle serial monitor --follow

To auto-reconnect to the xenon.

Also, flash-user will automatically put the xenon into dfu, compile, and flash.


That’s not what I’m seeing. See room… Two issues:

  • po dfu open doesn’t work because dfu-util -l only outputs the copyright notice when the xenon is running (blue light pulsing), I have to specify the device explicitly.
  • po xenon run compile-user doesn’t link due to error arm-none-eabi/bin/ld: cannot open linker script file module_user_memory.ld: No such file or directory

Hey, I’m grateful for po-util, I’m sure the above can be sorted out or my mistakes can be corrected. So thank you!


ModemManager is a big culprit. I’ve now

sudo systemctl stop ModemManager
sudo systemctl disable ModemManager

and I’ve added ENV{ID_MM_DEVICE_IGNORE}="1" to the udev rules in the 50-particle.rules. I’m not sure whether the latter is required, but now the /dev/ttyACM device becomes available within a second or two.


You’re using rc.27 right?



BTW, this may be easier on…


I haven’t tested po-util on Arch much. I’ve mostly only tested on Linux Mint, Ubuntu, and macOS


can you help me troubleshoot on po-util lobby…


Summary of problems encountered with suggested fixes: