Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Added Driver for Compute Module 3 #765
I'm having issues building on the PI directly, If I build via Ubuntu on WSL everything is fine and the compiled output runs on my devices however if I build on a PI I get the following errors:
Should I only be building on Ubuntu and then deploy artifacts to the device? Or is there an issue with the beta toolsets?
Before we move forward with this PR, I would like to understand what is the real pain point here. Is it just trying to use this driver for a device that provides extra gpio pins? If so, can we fix this problem differently? For example, we could have people manually pick the UnixDriver instead of the raspberryPi driver which should work, since it also makes me a bit worried the fact that I'm not sure if those extra Gpios are controlled the exact same way as with the RaspberryPi 3. We would have to read the datasheet since with the RaspberryPi3 driver we are accessing registers directly, which have a very specific address in memory, and I'm not sure if these extra pins would be represented in the same way, or if they would be located in the same location in memory.
To clarify the position. Essentially yes additional pin's is the issue. We use the Compute Module 3's and these provide 3 banks of GPIO, 0, 1 & 2. GPIO 2 is reserved for eMMC so is not an issue. GPIO 0 (I'm fairly certain although not 100%) is very similar to the RPI 3. GPIO 1 is then the additional range of pins that is not exposed.
I started this prior to the recent change with the register changes so haven't tested with that yet. My device testing of simply upping the maximum GPIO pin number has been working but I haven't fully tested every pin, only simple reading and writing.
If it's more advisable I can update our calling code to pass in the UnixDriver, I'm just also thinking how by default the Compute Module 3 falls into the RaspberryPI3 Driver via the default constructor.
I had considered whether to provide a constructor overload on the RaspberryPi3 driver that could enable the additional GPIO Bank 1 pins, or even have the driver auto detect its a compute module and enable them but this would still need to consider the above comments regarding registers.
What would be the next suitable steps?
I see, that makes sense. Thanks for clarifying. Also I do agree that having the RaspberryPi3 being the default driver that gets picked is not ideal in the case this driver won't be able to access all the functionality of the device. I liked the idea you proposed about simply modifying the RaspberryPi3 existing driver to detect if we are running in this specific device, and if so, changing how many pins would it provide.
The next steps in my mind would be to read the Compute Module 3's datasheet to ensure that all registers we use are located in the same address and that we will be able to access the new additional ones with the same logic that we have. I do recall when I initially implemented the driver that there were a few bits on the GPIO registers that were unused as I believe that two ints were used to represent the values of Gpios (1 bit per pin, which gave us 64) so given this special pi has 46 available pins, they would still fit in the same registers. That said other stuff may have shift, so lets first ensure that all of the addresses match and pins are controlled in the same way, and if so we can start planning on how to add support for this. Does that sound like a plan?