Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support for RPi3/BCM2835 on Raspbian 4.9 #88

Open
michaltalaga opened this issue May 26, 2017 · 16 comments
Open

Add Support for RPi3/BCM2835 on Raspbian 4.9 #88

michaltalaga opened this issue May 26, 2017 · 16 comments

Comments

@michaltalaga
Copy link

On Raspbian with Kernel 4.9 the Raspberry.Processor (from Raspberry.System) enum return Unknown.

This makes GpioConnectionSettings.DefaultDriver (from Raspberry.IO.GeneralPurpose) return null.

As far as I was able to tell it's because newest version of Raspbian report the hardware to be BCM2835 instead of BCM2709.

@moelski
Copy link

moelski commented May 30, 2017

Hi !

I think this could be fixed by changing the "ProcessorName" Function in Board.cs (which belongs to Raspberry.System):

        public string ProcessorName
        {
            get
            {
                // https://wiki.openwrt.org/toh/raspberry_pi_foundation/raspberry_pi
                switch (Model)
                {
                    case Model.A: return "BCM2708";
                    case Model.APlus: return "BCM2708";
                    case Model.BRev1: return "BCM2708";
                    case Model.BRev2: return "BCM2708";
                    case Model.BPlus: return "BCM2708";
                    case Model.ComputeModule: return "BCM2708";
                    case Model.B2: return "BCM2709";
                    case Model.Zero: return "BCM2708";
                    case Model.B3: return "BCM2709";  // BCM2710
                    default: return "UNKNOWN";
                }
            }
        }

Maybe there should be another addon to add the hardware type BCM2710 for the Pi 3. But it works with 2709, too.

regards Dominik

@michaltalaga
Copy link
Author

I have implemented my own fix, but can we please have it fixed in the official NuGet package?

@moelski
Copy link

moelski commented May 30, 2017

@michaltalaga
Could you share your fix, too ?

@michaltalaga
Copy link
Author

michaltalaga commented May 30, 2017

I ended up changing 2 files:

in Raspberry.System/Processor.cs
I've added:

    /// <summary>
    /// The Raspberry Pi processor.
    /// </summary>
    public enum Processor
    {
        /// <summary>
        /// Processor is unknown.
        /// </summary>
        Unknown,

        /// <summary>
        /// Processor is a BCM2708.
        /// </summary>
        Bcm2708,

        /// <summary>
        /// Processor is a BCM2709.
        /// </summary>
        Bcm2709,

        /// <summary>
        /// Processor is a BCM2835
        /// </summary>
        BCM2835  // <- added this one
    }

and in Raspberry.IO.GeneralPurpose/GpioConnectionDriver.cs

  private static uint GetProcessorBaseAddress(Processor processor)
        {
            switch (processor)
            {
                case Processor.Bcm2708:
                    return Interop.BCM2835_GPIO_BASE;

                case Processor.Bcm2709:
                    return Interop.BCM2836_GPIO_BASE;

                case Processor.BCM2835: // <- added this one
                    return Interop.BCM2836_GPIO_BASE;

                default:
                    throw new ArgumentOutOfRangeException("processor");
            }
        }

@moelski
Copy link

moelski commented May 30, 2017

Hi !
Ok, that would work, too.
But as far as I know all boards are reportet as BCM2835 now.
So maybe this won´t work for all Pi´s out there ...

Dominik

@michaltalaga
Copy link
Author

That is the very reason I haven't created a pull request. I'm no expert in this. Did not want to break some other implementations.

I just know my RPi3 worked with old 4.4 Kernel and stopped with 4.9. I've nailed it down to a different Processor being reported by the system. I know I did no hardware change in my RPi so I gave it a shot with the simplest thing I could think of: make the library treat BCM2835 the same as BCM2709.

@moelski
Copy link

moelski commented May 30, 2017

Maybe I will place my solution as a PR.
For a first fix it´s better than the actual situation. :-)

@Petermarcu
Copy link

Hit this too. Would be nice to get an update that supports Pi3. Workaround as noted above worked.

@Petermarcu
Copy link

I ended up forking this project and making the fixes here as well as converting the libraries to support netstandard2.0. I'd like to get the changes in to this branch but there doesn't appear to be a lot of activity.

https://github.com/petermarcu/Pi
https://www.nuget.org/packages/Pi.IO/0.0.2-preview1

@JTrotta
Copy link

JTrotta commented Nov 6, 2017

@Petermarcu This project seems to be dead. I did a fork like you, publishing all the libraries on nuget, and refactoring I2C library now working with start/stop and repeated start conditions https://github.com/JTrotta/raspberry-sharp-io.

I would like to support 2.0 netstandard too. Why not working on a common "new" project?
JJ

@Petermarcu
Copy link

Appears that way although it's been a good library so far. I was hoping to hear back from the project owner. I don't have the bandwidth to drive an additional project but would be happy to contribute to yours if you want to carry it forward. I had to do a bunch of significant project restructuring/simplification to get to netstandard2.0 and the new sdk style projects. I cut a few corners but those may be worth cutting for the long run anyways.

@moelski
Copy link

moelski commented Nov 7, 2017

Hi JTrotta, Petermarcu,

Why not working on a common "new" project?
Since I use this project for a personal project I would love to see some progress on this.
And I would try to add some useful documentation / fixes.

@Petermarcu
Copy link

@JTrotta I'm happy to "contribute" the changes I have in my fork towards anything that is "alive" and want's to move this space forward. As I said, I restructured a lot of it to move it to .NET Standard and the new SDK style projects but I turned off a bunch of stuff to make that happen and there would be work to do to bring it back. I don't have time right now to do that but may be able to make slow progress over time.

I think since my changes are much more structural around where sources live, it may be easier to to merge the source code bug fixes you have made into my branch. I can then republish some packages. I also merged a couple repo's into one because I didn't see a reason to have System be seperate.

Once all the changes are merged together, whoever wants to carry things forward can just take it from there, copy it into whatever repo makes sense and ...

@JTrotta
Copy link

JTrotta commented Nov 12, 2017

@Petermarcu
I think this repository is dead. It'a pity. But many of us still need this library and its features, and also need many improvements. My fork resolves some issues, yours others.
I think the best way would be to start a new project from scratch, starting from this, yours and my library, that will work on all Pis and new kernel.
We could be 4 : me, @Petermarcu , @moelski , and Chris Dodge.
Your repository could be a good start point. What do you think?

@Petermarcu
Copy link

I'm fine with that or even fine with seeding another repository with what I've got and letting people party away. I don't want to be in the way and will help where I can.

@Petermarcu
Copy link

Ok, I created a new repo and a team where I added you and a few others that have commit rights. Here it is: https://github.com/pi-dotnet/Pi

Go ahead and make changes to it to incorporate your work into it. When you are ready, I can build and push an update to NuGet.org from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants