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] 
> <javascript:>> 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] <javascript:>> 
>> 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] <javascript:>.
>>> 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/6c3ca915-9c5a-4a58-be8e-af8201f06145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to