prusst: a library to talk to your PRU from Rust

[quinte...@gmail.com]

Hello all, just wanted to announce the release of a Rust relative to the prussdrv C library, available at:
https://github.com/sbarral/prusst
(see also the API docs: https://sbarral.github.io/prusst-doc/prusst/)

This initially started as a modest effort to wrap prussdrv, but the process made me realize how difficult it is to infer what prussdrv is doing under the hood without analysing the source code (is this 'event' argument a system event or an event out? Does this function ever actually return -1 and if yes when? What exactly is prussdrv_pru_clear_event() doing?).
So I ended up contemplating the general design of a more explicit UIO interface that would exploit the Rust type system to better codify the work-flow. The result is a native Rust library that does not actually link to prussdrv but offers a very similar functionality.

I have strived to produce a clean API and implementation, but keep in mind that this is a 0.1 release so I am definitely open to criticism from the PRU experts here. Even if you are not a Rust aficionado, suggestions for improvements or new functionality are very appreciated.

Serge

[William Hermans]

Looks pretty good. I've never actually seen rust in the wild, and I'm not even sure I've even heard of the language until now . . . Since there seems to be a language born every 5 seconds now days. I've personally no interest in learning all.

May I make a suggestion ?

An example that blinks the on board USR LEDs could be handy. In that a person could run the code without having to hook up any external electronics. I know this is nothing super special, but it would allow beginner hobbyist to see something right away.

I've been considering writing a 'bit pattern interface' between userspace and the PRU's myself. In order to control the on board USR LEDs. Just as a demonstration. But alas my assembly skills are far rustier( no pun intended ) than I care to admit. I've also even considered writing a modified uio_pruss driver. . .but first I would have to read up on several things. Then, find the time.

In the meantime I think I'll try to learn something form what you've done here. Thanks for sharing !

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bfef07e8-af2e-4547-a943-d33e4397234f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Ug, I see rust also uses generic types similar to C++. . .

[quinte...@gmail.com]

William,
Thank you very much for the suggestion, it is a very good idea indeed and may also avoid the user to mess around with loading a specific overlay; I suspect the default cape-universal overlay on newer Bone distributions may be OK for that (I need to investigate though).

As for Rust, yes, fully buzzword-compliant and with generics ;-)
That being said, it is the only of those hype languages that relies on manual memory management (no GC) and stays as close to the metal as C and C++ (no runtime, system threads only, and similar performance).
Coming from C++, it certainly is a breath of fresh air and I have found the generics to be quite enjoyable (similarity to C++ templates is only superficial). The generics turn out to actually improve error messages, rather than ...well, let's not talk about template error messages in C++.
For a C programmer, though, it may or may not be a worthy alternative. It is definitely not a minimalistic language as C is and its safety paranoia is not always a good fit for low-level stuff like pointer arithmetic (you can do it all, though). OTOH  the type system is extremely helpful to catch bugs at compilation time. As always, it is a question of personal preference.

Serge

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[quinte...@gmail.com]

A follow-up: as per William's suggestion, the blink and parallel_blink examples have been converted to use the on-board USR LEDs, with the added bonus that these examples now work right away with any PRU-enabling cape (including cape-universal and friends).

Serge