31–40 of 96 posts
Is Rust the future? As a C++ (hobby), Java (full time) developer, should I invest my time in Rust?
I have the perfect project for this! Generate a signal using the GPIO ports to drive a mirror and camera in a synchronized fashion. Does anyone know if the RPi GPIOs can be driven at around 80KHz? I've seen reports that this is possible, but that the USB or video driver tends to lock the CPU for long times, messing with timings - but hopefully running on bare metal would take care of that.
You could do this with much less than an RPi. I would recommend using an AVR or better yet a 555 timer if all you need is an 80KHz signal. Let me know if you want help with this I'm looking for projects like this or something much more complicated.
Earlier quoted context omitted.
I started playing around with Rust a few weeks ago and fell in love; it has some quirks for sure (the whole borrowing system is a bit tough to grok at first) but it didn't take long for me to start seeing things the "Rust way." My only hang-up with it right now is that so many of the most useful packages in Cargo depend on the nightly build of Rust.
Could you list which packages you tried to use which were blocked on a nightly? In many cases a package can be moved off nightly with trivial changes, I can try to do it.
Earlier quoted context omitted.
You could do this with much less than an RPi. I would recommend using an AVR or better yet a 555 timer if all you need is an 80KHz signal. Let me know if you want help with this I'm looking for projects like this or something much more complicated.
I wouldn't recommend an AVR. That is outdated technology. Even Atmel mostly makes ARM microcontrollers now (and they are much nicer than their AVR ones).
I have the perfect project for this! Generate a signal using the GPIO ports to drive a mirror and camera in a synchronized fashion. Does anyone know if the RPi GPIOs can be driven at around 80KHz? I've seen reports that this is possible, but that the USB or video driver tends to lock the CPU for long times, messing with timings - but hopefully running on bare metal would take care of that.
Is Rust the future? As a C++ (hobby), Java (full time) developer, should I invest my time in Rust?
If you're just concerned about employment then you'll probably be fine with java (maybe go in the future). If you're looking for self-improvement then its always a good idea to learn a new language, especially if it does something different like Rust's borrow checker. Outside of that, I also used to do all my hobby code in C++ and after learning Rust I'm never going back to C++.
Go is not going to replace Java in the future. For a language which cannot even lock dependencies to a version, people sure like to pretend it is the holy grail because Google made it.
As a long time C programmer this is not very convincing. A C program to do the same requires far less voodoo. All you need to do is take the address of the GPIO register then toggle the bit. No name mangling. No error handlers to override. Don't get me wrong I know rust does have some compelling features. It does seem odd to me that so many of what would be compiler options in C are hard coded.
Don't get me wrong. Rust is an interesting language. The thing described in this post is well within its capability, i.e. IMO there isn't really anything that worths bragging about. Such trivial thing neither demonstrates the real potential of Rust, nor answers important questions from real world engineering perspective.
I'm all for having better tool to write low level stuff. I have dabbled with Rust and the experience was eye-opening. I think Rust still have a lot to catch up though.
Earlier quoted context omitted.
This might be of interest: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-...
Excellent, thanks! So GPIO performance won't be a problem, but they note that OS multitasking can cause issues: "What is not evident from the snapshots, however, is that due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc" Running on bare metal should take car…
With a few simple tweaks (isolcpus + irqbalance + setting cpu affinity), you can get rid of the overwhelming majority of interruptions a specific userland program running on a Linux machine could encounter.
If this quote is talking about kernel context switches, choice of I/O scheduler and tick rate in the kernel could be tweaked for better performance.