Doesn't seem to be working with Pi2 B+

[axos88]

root@raspberrypi:~/test# cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/testit`
Unable to determine hardware version. I see: Hardware	: BCM2835
,
 - expecting BCM2708 or BCM2709.
If this is a genuine Raspberry Pi then please report this
to projects@drogon.net. If this is not a Raspberry Pi then you
are on your own as wiringPi is designed to support the
Raspberry Pi ONLY.

Outdated wiringpi library?

[Ogeon]

That's probably the reason.

[Ogeon]

I don't own a Pi2 B+, so I can't test it myself. A pull request from someone who does is most appreciated. 🙂

[axos88]

Hmm, I just built master, and it seems to be working with that. Can you publish a new version to cargo.io based on that?

[axos88]

I'm super-new to rust - just started to read The Book 2 days ago - so keep that in mind. What I did was adding this to my project's toml file:

[dependencies.wiringpi]
path = "../rust-wiringpi"

And did a git clone of this repository to that directory.

[axos88]

Yep, definetly something wrong with version 0.2.3:

[dependencies.wiringpi]
path = "../rust-wiringpi"
#version = "0.2.3"

doing a cargo clean and a cargo build --target arm-unknown-linux-gnueabi with the path works, with version does exhibit the problem above.

[Ogeon]

Ok, I'm a bit confused. What works and what doesn't?

A:

[dependencies.wiringpi]
version = "0.2.3"

B:

[dependencies.wiringpi]
path = "../rust-wiringpi"

C:

[dependencies.wiringpi]
path = "../rust-wiringpi"
version = "0.2.3"

Run cargo clean before each one, and build with cargo build --target arm-unknown-linux-gnueabi. Also, make sure that the sub modules in rust-widingpi have not been updated.

[axos88]

With a fresh clone using git clone --recursive git@github.com:Ogeon/rust-wiringpi.git
Compilation command: cargo clean && cargo build --target arm-unknown-linux-gnueabi && scp target/arm-unknown-linux-gnueabi/debug/rpitest root@192.168.1.110:

A: error
B: works
C: works (is there a difference from B though?)

Note: I don't think it should make a difference, since it's almost certainly an old version of wiringpi.so getting statically linked to the binary, but I'm on a MacOS Sierra host, using

armv6-rpi-linux-gnueabi-gcc (crosstool-NG crosstool-ng-1.23.0) 6.3.1 20170109
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Ogeon]

B and C should be the same. I think I just found the problem. The submodule on my end wasn't up to date. If you run git submodule status in rust-wiringpi it should print:

 4d02d1e955f384677df67020baeba8ad5704446f WiringOP (heads/h3)
 96344ff7125182989f98d3be8d111952a8f74e15 wiringPi (2.42-1-g96344ff)

I had forgotten to update mine at some point.

[Ogeon]

I just published a new version. See if that one works. 🙂

[axos88]

Yup, works. Thanks for the help!

Btw, I've seen you have a development flag for enabling a mock implementation, which is pretty awesome. Is there a way to enable that based on the target?

I mean disable it for arm builds, enable it for x86_64 builds.

[Ogeon]

You may be able to make platform specific dependency entries: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

Something like:

[target.'cfg(target_arch = "arm")'.dependencies]
wiringpi = "0.2"

[target.'cfg(not(target_arch = "arm"))'.dependencies]
wiringpi = { version = "0.2", features = ["development"]}

Not sure if arm is the correct one. May be armv7 or something else.

[axos88]

Heh... yeah, i tried that, but it's not working. A bug in cargo as far as i understand: rust-lang/cargo#2524 :(

[Ogeon]

Aw, well, that's all I got. Anyway, I'm closing this as fixed.