mraardvark / pyupdi

Python UPDI driver for programming "new" tinyAVR and megaAVR devices
MIT License
210 stars 73 forks source link

UPDI over remote serial port #39

Open sbaxter-izo opened 4 years ago

sbaxter-izo commented 4 years ago

Hi, we've been using pyupdi to program ATTiny devices from an i.MX6 SL. This works for our development, but we'd like to avoid running having to include/run python on the linux board.

I've looked at the updi/physical.py implementation that uses pyserial to establish a serial port connection, and believe it should be possible to implement a "remote serial port connection" by exposing the serial port over tcp/ip using ser2net. I imagine we could implement a common UpdiConnection interface that is basically, send, receive, sib, and send_double_break, which UpdiPhysical and a potential UpdiSer2Net could both implement. This would allow updi/link.py to remain unchanged in how it uses the UpdiConnection interface, and just allow the constructor to configure whether it creates a physical connection or a remote connection over tcp/ip.

I have a couple questions

Thanks!

sbaxter-izo commented 4 years ago

An update from some investigations today, pyserial has an RFC2217 client that even provides the same Serial class abstraction as updi/physical.py uses, so this wouldn't require much new code at all, just support for a different COM port formatted as rfc2217://host:port. I will look into integrating pyserial.rfc2217 support some more tomorrow.

sbaxter-izo commented 4 years ago

I've managed to get pyupdi working over an RFC2217 serial connection using ser2net! Now that this is functional, please let me know if you would be interested in taking this upstream.

There are relatively few code changes (mostly refactoring logic from UpdiPhysical into a common UpdiConnection base class), and the CLI just takes a comport formatted as either rfc2217://host:port or /dev/ttyX and creates the proper serial connection under the hood.

mraardvark commented 4 years ago

Wow, very cool indeed @sbaxter-izo :) I have had a go at something similar a while ago, but could not find the right network library, hacked something by hand, then gave up :/ Anyway, as cool as this is, I would prefer to keep pyupdi "clean" and as generic as possible. Perhaps more as a reference for other projects than directly useful. This means I can generally test all device support and features without getting too advanced. How about keeping it a fork and give it a nicer name like "remotepyupdi"?