So with these computers I believe they use GPIO pins (please correct me if I am wrong). I believe there is a cargo package for RUst that allows to program GPIO pins.
My question is can I take the source code that I have made for the Raspberry Pi and transfer it to another mini computer? If I attached sensors to the Raspberry Pi and I took the source code to another mini computer such as the Odroid and attached the sensor(s) to Odroid in the exact same port, would it all work fine?
Also is the cargo package for Rust stable or is it in Beta?
If you use the low-level GPIO abstraction in embedded-hal it should be portable to any embedded device that has a hal crate based on it. You can't use the entire code as-is, there is always some board specific setup code to, for example, choose the right GPIO peripheral to use.
If you use a high-level GPIO abstraction of an operating system (all the ones you mention can run Linux as far as I know where you can use rust-sysfs-gpio), it's the same, but assuming the same architecture, it might even be possible for the code to run as-is on different computers without recompilation. If you allow for enough run-time configurability regarding mapping of GPIOs to cover all boards.
This is definitely true for basic GPIO functionality (input, output). Assigning specific functions such as I2C, SPI, analog, is pretty much always board specific.
So if I connect external device to the exact same port on the different device, I don't need to change the code such as which GPIO port I am using, right?
Does this apply if we used different languages as well (for examplel C++)?
By any chance do you know if this crate is in beta?
Ideally, yes. What is the same port, though? Different devices will have different ports, banks, even if they're numbered the same the HAL might expose them differently. Say, some setup code specific to stm32 would be:
let dp = stm32::Peripherals::take().unwrap();
let mut flash = dp.FLASH.constrain();
let mut rcc = dp.RCC.constrain();
let clocks = rcc.cfgr.freeze(&mut flash.acr);
let mut afio = dp.AFIO.constrain(&mut rcc.apb2);
let mut gpiob = dp.GPIOB.split(&mut rcc.apb2);
let scl = gpiob.pb8.into_alternate_open_drain(&mut gpiob.crh);
let sda = gpiob.pb9.into_alternate_open_drain(&mut gpiob.crh);
You'd write your peripheral driver code to abstract over that; take the GPIO pins to use as type trait argument. I've always found the ssd1306 crate a nice example of this. Then you'd have a top-level main.rs per board that does the setup and the rest of your code generic.
Yes. If anything, BSPs for other languages are further apart between boards, especially between vendors. The Rust developers are doing a good job trying to standardize here.
Definitely. The entire rust embedded ecosystem is in beta AFAIK. Some things like the GPIO abstraction traits have been through a few iterations and are pretty much stable for a while and unlikely to still change significantly—switching digital pins is straightforward after all. But whoknows…
As said though, if you're simply running, say, Linux on the board you don't need to mess around with the low-level rust-embedded stuff at all, the switching will go through a high-level sysfs interface and kernel drivers. All of the above is for bare-metal interface.
That's definitely low-level. High level would be the rust-sysfs-gpio crate.
No, that is a crate for controlling a SSD1306 OLED display, it is an example of a generalized driver based on traits for the GPIO and such abstractions to be board independent…