AsyncPropLoader

ostrich

I have just released a new prop loader:
https://github.com/chris-siedell/AsyncPropLoader
http://siedell.com/projects/AsyncPropLoader/docs/full/

Dependencies:
HSerial
https://github.com/chris-siedell/HSerial
Serial
https://github.com/wjwwood/serial

The underlying Serial library is portable, so this loader should work on Mac, Linux, and Windows (I've only tested it on Mac).

I know that this is a solved problem but I wanted a loader with specific features for a project I have in mind. I also wanted an interesting project to work on as I learned C++. (My previous paid programming work was in Flash, which isn't that marketable these days.)

This loader is object based, asynchronous, multi-threading safe, and its operations are cancellable. It provides updates, including timing estimates, as it loads. When errors occur it provides (hopefully) useful information.

The intermediate layer between itself and the Serial library -- HSerial -- is something I wrote which allows coordinated serial port use. Serial port objects (controllers in HSerial terminology) can ask to use a serial port (be made active), and the currently active controller can accept the request, or refuse while providing useful information. A communications object can continue listening right up until the loader wants to use the port. Or a loader can refuse to relinquish the port until its task is done or is cancelled (as AsyncPropLoader does).

My ultimate goal is to use this work as part of a set of CPython extensions I have in mind. I am currently using the HSerial library to create an object for communicating with a prop using a command response model. This generic communications layer, PropCR, will then be used to build a python extension that will allow users to query and interact with a prop at a high level. A user will be able to read and write exposed properties of the prop as easily as working with a variable. More complicated objects -- queues, buffers, signals, watches, callbacks -- are also possible.

Python appeals to me because its read-eval-print loop invites play. With inexpensive computers such as the Raspberry PI it can be deployed anywhere. The propeller appeals to me because its cogs make it the ultimate real-time peripheral for such a computer. Combining the two just makes sense.

I don't know when I will have the time to see all of these ideas to completion, but I know that there's plenty left in the propeller to hold my interest for a long time.

jmg

ostrich wrote: »

My ultimate goal is to use this work as part of a set of CPython extensions I have in mind. I am currently using the HSerial library to create an object for communicating with a prop using a command response model. This generic communications layer, PropCR, will then be used to build a python extension that will allow users to query and interact with a prop at a high level. A user will be able to read and write exposed properties of the prop as easily as working with a variable. More complicated objects -- queues, buffers, signals, watches, callbacks -- are also possible.

Python appeals to me because its read-eval-print loop invites play. With inexpensive computers such as the Raspberry PI it can be deployed anywhere. The propeller appeals to me because its cogs make it the ultimate real-time peripheral for such a computer. Combining the two just makes sense..

If you want a basis for a loader using Python, you could look at this work using the AVR
https://github.com/mraardvark/pyupdi
The new AVR UPDI is 115200 half duplex.
I'm not sure what Baud rates Python can manage, but P1 loaders have modest speeds so the AVR speed should be fine.

ostrich

The loader was not the end goal, it was just the first logical step.

The idea I'm following is writing the underlying support libraries in platform-independent, end-agnostic C++. This loader could just as easily be used for native GUI apps.

Writing a CPython extension (instead of directly in python) allows the code to execute in background threads and interrupt as information arrives. Plus, it should be much faster.

David Betz

Very nice code! I didn't look it over in depth but you might want to look at the Parallax PropLoader code for an idea to speed up loading. It uses a second-stage loader that uses the crystal on most Propeller boards to achieve much higher load speeds. The Propeller ROM loader is just used to load the second-stage loader and then another protocol takes over to load the user's program. I suspect it would be pretty easy to adapt your code to use this approach.

https://github.com/parallaxinc/PropLoader

Edit: PropLoader also supports using the Parallax WX Wi-Fi module for wireless downloads using a simple HTTP protocol.

ostrich

Thanks for the compliment.

I added a delegation feature to HSerial in anticipation of making a two stage loader. I plan to make a generic bootstrapping controller that can be inherited from for implementing a fast loader, an EEPROM manager, etc. I will definitely study PropLoader when/if I get to that stage.

David Betz

ostrich wrote: »

Thanks for the compliment.

I added a delegation feature to HSerial in anticipation of making a two stage loader. I plan to make a generic bootstrapping controller that can be inherited from for implementing a fast loader, an EEPROM manager, etc. I will definitely study PropLoader when/if I get to that stage.

I'm afraid that the PropLoader code is not as beautiful as yours but I'm happy to answer any questions you might have should you decide to look at it. The second-stage loader was written by Jeff Martin of Parallax and you could probably use it directly. Also, even the first stage loader code in PropLoader packs more into the byte stream than the original Propeller loaders did. Jeff created that code as well and I just translated his code from Pascal to C++.