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 On Tuesday, August 9, 2016 at 11:21:26 AM UTC+2, [email protected] wrote: > > 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 > > > On Tuesday, August 9, 2016 at 1:07:31 AM UTC+2, William Hermans wrote: >> >> Ug, I see rust also uses generic types similar to C++. . . >> >> On Mon, Aug 8, 2016 at 4:04 PM, William Hermans <[email protected]> wrote: >> >>> 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 ! >>> >>> On Mon, Aug 8, 2016 at 3:18 PM, <[email protected]> wrote: >>> >>>> 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 >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/beagleboard/bfef07e8-af2e-4547-a943-d33e4397234f%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/beagleboard/bfef07e8-af2e-4547-a943-d33e4397234f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6d90b380-cbd3-43ed-bc80-3a4bbb49ac04%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
