Re:Raspberry Pi Bare Metal Programming with Rust
by brobinson on Saturday January 16, 2016 @06:18PM
(#10917348)
>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.
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.
Re:Raspberry Pi Bare Metal Programming with Rust
by roywiggins on Saturday January 16, 2016 @07:21PM
(#10917569)
You could probably use an Arduino for this, they connect to a computer using serial-over-USB.
You can do GPIO bit-twiddling pretty fast: http://skpang.co.uk/blog/archives/323
Re:Raspberry Pi Bare Metal Programming with Rust
by timow1337 on Saturday January 16, 2016 @02:46PM
(#10916519)
The new raspberry pi zero can be run as a device, so you could use that.
Re:Raspberry Pi Bare Metal Programming with Rust
by Aeolos on Saturday January 16, 2016 @03:07PM
(#10916612)
O.o this $5 puppy could essentially replace the 1.5K National Instruments DAQ I'm using right now. Even better, I won't have to deal with their horrendous API documentation anymore.
Of course that would require a Linux kernel, so not bare metal anymore, but there might be a way to make this work!
Now I just need to get my hands on one, it's out of stock everywhere within a radius of 300km...
Re:Raspberry Pi Bare Metal Programming with Rust
by ajb on Saturday January 16, 2016 @04:52PM
(#10917022)
They haven't committed to making more, or if they do, to the $5 price point.
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 care of that, so the only remaining problem is how to synchronize the signal generation on the RPi with the recording of data on the host computer. (Sigh, if only RPi had a USB3 port...)