Repository navigation
Replies: 11 comments 46 replies
|
You are right, there is a bit of "split" between these two repositories, as one originates from the FHNW university based on the CrowPi, and the other one is the efforts done by @taartspi to provide example code for all types of devices... I love your idea, but I'm afraid this would require a lot of work and not sure if someone is available to pick this up. |
|
P.S: I didn't realize https://github.com/Pi4J/pi4j-example-devices is still actively maintained. My reason for reviving this thread is that I have added / cleaned up some drivers in my "client" project, but would prefer to not have them in there directly. So my options seemed to be:
Like I said, my main problem with the example projects is that they don't look like something that's designed to depend on. So even if they would fully fit my needs from a design perspective, the names would still be quite odd. But I'd be certainly interested in @taartspi 's opinion if / how we could get to a reliable driver project. @mores I just assumed it's was a "hobby" project for you, and that available time is partially a function of how much fun it is to work on? So my question was more like why / how do you think it stop being attractive to work on? |
|
Originally the example was done as an app. Supply the chip id and it looked where located. If behind a mux configure the mux for you. I later removed most of this as it seemed to complicate answering a more basic question. I started seeing post where someone bought a pi an IC, loaded pi4j and was stuck. I didn't intend to explain datasheets but just supply a simple example to see how to access their chip. Most of those examples were used to provide to a post. I mention this to say. Yes we could clean these up. But the example itself needs to remain simple to understand. Something a newbe could copy and paste the main features of the example into what they are trying to develop. Driver. Are you thinking one download and the user has all the examples and an API to select which executes and how to supply the required parms ? Or is each example unique but using a common driver infrastructure? Also. When i first did this i was asked to have each device be a module. |
|
What I'd like to see is a set of device-specific feature-complete APIs that "just" abstract raw IO calls ( I think this would provide significant benefits:
Each example using a re-usable driver would stay unique; it would basically be reduced to a "main" method that shows how to use a specific device. There would be no "generic" common driver infrastructure, although I could imagine supporting some shared interfaces at a later stage potentially. Abstractions are easy to get wrong early and hard to refactor later, so that's something I'd prefer to defer (edit: except from code sharing for device variants such as BMP280 vs. BME280). IMHO one module per driver would be too much overhead. One general driver repository would already bring in many of the benefits, for instance avoiding additional dependencies outside of pi4j core that might be used in examples for illustration purposes. P.S: BME/P280 might be a good pilot because of how many copies could be cleared up.... |
|
@stefanhaustein - yes it is a "hobby" project. For me to continue I think I just need to start buying more stuff - mux and ePaper are on my list. I started working on a different project - it is a esp-now to uart/usb gateway that uses an esp32c6. I was going to start using the pi again - but noticed serial functionality was removed.
Perhaps I was looking to collaborate more on this project with others. At this point - what makes the most sense to you to advance this project ?
|
|
(somehow replied top-level instead of here by accident |
|
I like the spirit of your project, but I think it's too ambitious -- at least in the starting stages. So what I'd prefer to do is to set up a new pi4j subproject collecting hardware-specific "drivers" providing feature complete APIs for common hardware. Basically separating out the re-usable parts of existing example projects and making it easy to re-use them. From your project, this could be Adafruit5880.java, Adafruit3787.java etc. with external/high-level dependencies stripped. As we go, we'd ideally simplify the existing examples projects to use these drivers -- or contribute new examples there if we are adding drivers for new devices. This would be dropping the higher level "components" aspect of your project for now. Don't get me wrong -- I don't think it's not useful, but it's hard to provide good high level abstractions, in particular at an early stage with a limited set of examples. And I doubt the lack of high level abstractions is what's stopping beginners. I'd expect that typically, people come here looking for a way to hook up the hardware they have, and it won't be a big problem for them if the API of a particular device is very specific to the hardware -- as long as it's a reasonable Java API (opposed to sending bits through a pipe manually and figuring out after a day of debugging that the byte order is wrong). For us, this separation would provide a clear focus, avoiding getting lost in higher level design, which might be quite hard, given the variance in capabilities. @taartspi: Perhaps a better pilot might be a SCD41 driver (i2c indoor CO2, temperature & humidity), as it would provide something new rather than "just" cleanup -- including a blogging opportunity? |
|
PS: I think the 1-wire situation is another argument for a "drivers" subproject |
|
PPS: @FDelporte what would be the requirements for a driver project in pi4j / the right steps to get there? |
|
On holiday, will pick up this thread next week... |
|
@stefanhaustein - a submodule called "drivers" has been added to https://github.com/mores/pi4j-extensions/ |
|
Let's see if we can convince Frank next week that would be probably less code (just by consolidating all the BME/BMP 280 drivers) and not more work -- before jumping into cooking something up externally O:) |
|
I haven’t had time to work on Robo4J for quite some time, but I believe Miro is still contributing. Perhaps you could contribute to the hardware abstractions there?robo4j/robo4j-hw-rpi/src/main/java/com/robo4j/hw/rpi at master · Robo4J/robo4jgithub.comKind regards,Marcus - Excuse me if terse; sent from my phone.On 10 Aug 2025, at 16:14, Stefan Haustein ***@***.***> wrote:
(somehow replied top-level instead of here by accident ¯\_(ツ)_/¯ )
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
It's GPL (opposed to Apache here) and the "discoverability" advantage of a "proper" pi4j sub project would be lost. The existence and import section of AbstractI2CDevice.java doesn't look like something I'd like to depend on. |
The Robo4J project is something I started doing with Miro for fun, but shortly after both of us ran out of time (I switched roles and company, Miro had a kid). I am sure there are plenty of opportunities to clean things up. That said, there are already a hardware abstractions for some popular I2C and SPI devices in there. If GPL is huge problem, I'd be happy to start a discussion for Robo4J to switch to Apache. The project is just sitting there anyways. |
|
I think it would benefit Robo4J to factor out drivers. For me, in addition to the license issue, it has similar scope concerns as the original proposal. I think it's another case that shows why pi4j should have a discoverable place for drivers. I wouldn't want my "main" project to depend on it, which makes it unattractive for contributions. That said, if somebody would create a dedicated driver repository somewhere (e.g. Robo4J/pi4j-drivers) as a staging ground for back-porting to pi4j (with a matching license so examples can be cleaned up -- and ideally some simple design guard rails), I'd be happy to contribute there. |
|
Even though the driver code is in the same repo in Robo4J, the intention was always that you should be able to use them separately without the rest of the framework. It is a separate module, with rather few dependencies IIRC. (Just took a look, and there is one or two dependencies that really should not be there - I see that there has been some build system changes since I contributed them. I’ll try to fix them soon.) https://github.com/Robo4J/robo4j/tree/master/robo4j-hw-rpi It shouldn’t be a big problem to have GPL with CPE, as you wouldn’t be able to use Java in the first place if that was a problem. For 1-wire protocols, IIRC, there is a bunch of different ones: |
|
I'm liking the discussion on this topic, and i really do think we should define a project for such drivers. The example project is really good for that: examples on how to do communicate with a device using pi4j. But a driver project can help define something reusable which could have a clear API and then be imported as a library into one's own project, as opposed to copying the example code from and changing it to ones own liking. I am pretty sure that the target audience is different for two such repositories and thus might attract additional developers. The elephant in the room is the same as always: Who would be willing to write such drivers? Or rather who wants to start it and how? Additionally this would then need a proper release management, which i can take over as part of releasing pi4j. @stefanhaustein i am sure hoping that you would provide an implementation for your pixtend HW. Taking this with the new FFM changes, might give pi4j a little boost. I myself am waiting for FFM before i move my Strolch-PLC code to pi4j version 3, as i currently am still on 1.4. Never got around to upgrading and was always eyeing FFM... |
|
I'd be happy to contribute a set of drivers (currently have Bmx280Driver.java and Scd4xDriver.java and can offer a PiXtendDriver if there is interest, but it’s a bit more “esoteric” and currently lacks pwm support; would also like to add a character lcd driver after some more cleanup. I'd also be happy to help with defining scope / guard rails; I have created this doc as a starting point: https://docs.google.com/document/d/1b4roM_tD9WqEWBtq4itqgsoPNN0jqcFHJoI9s-8Q83U/edit?usp=sharing |
|
I would be happy to contribute a set of drivers as well. I have bunch of them under https://github.com/Robo4J/robo4j/tree/master/robo4j-hw-rpi. I think it would be nice to have a single source for such abstractions. |
|
Great work with the document @stefanhaustein. I have taken te liberty to make it part of the README of the new repository: https://github.com/pi4j/pi4j-drivers/ |
|
The example repo devices are each a module that can be pulled into an app but no consistent interface across io-types and the driver repo can solve that After its completion i can review how future device examples are implemented to allow use as an individual module and within the driver And i agree with Roberts point these repos serve different audiences |
|
Hi, I have developed a device library on top of PI4J that breaks down to I2C, SPI and 1-wire and then sensors, storage, displays etc. The point of the library is to auto detect I2C devices and then load them for use or use the sensor directly. It has a very simple rest api server that can be used to display or write to devices and read registers etc. It is used to integrate devices directly into our messaging server. its all open and you can take what you want or expand it. Each device has the hardware layer exposed by a corresponding API and then a controller layer that can be used to provide unified access to the device. https://github.com/Maps-Messaging/device_integration If interested let me know Matt |
|
currently have support for DS3231 ,AM2315, AM2320 ,AS3935 ,BH1750 ,BMP280, BNO055 ,INA219, PMSA003I, TLS2561, DFRobot Gas Sensors, LPS25 ,LPS35HW, PCA9685, Adafruit 7-Segment, Adafruit Alphanumeric, AT24C32/64, MCP3004, MCP3204, MCP3008, MCP3208 |
|
I agree with a lot of the topics discussed here. Historically, drivers have been removed from the core-repo as they require specific tests and all the hardware to be able to do so. But as there is a lot of similar requests for a driver-library, we could indeed start it as a separate project. This would - in the end - eventually make these repos no longer needed (and could be archived) if we focus on the driver repo:
In my opinion, this could be the best approach to organize this:
Main bottleneck: who is "the lead" for this repo? Or will this organically grow? We have seen in the Pi4J core project that people come and go, but there are a few main contributors who can maintain the repository's stability. Should we assume the same will happen for the driver repo? Anyway, we can move this project forward quickly! I can prepare an empty Maven project and start the repository. Then it's up to you all in this discussion to contribute your implementations and find a common "best approach" to structuring the code. |
|
Should the V4 change affect client / driver code at all -- could we "just" start based on V3, keeping momentum? I think I'd prefer a slightly smaller scope, keeping |
|
client/driver code won't change in V4, as it's "just adding" (*) a new provider, so yes, it can be based on V3. (*) = it's a big job done by @DigitalSmile, so I definitely don't want to minimize the efforts ;-) |
|
OK, decided to have drivers-only in the new repo, and add examples in the pi4j-example-devices repository. |
|
Awesome, thanks! |
|
Hmm... for some weird reason i'm not getting github mails anymore, so missed that this discussion continued... If we don't want to push the example project to maven central, then it should be a separate repository, as this would otherwise complicate the maven repo imho. I very much like the document from @stefanhaustein and think this should govern the new driver's document. One addendum, which is probably clear to all participants: Should all go over PRs. I am quite happy on how this is going and new contributors are showing up and have a good feeling about this. I see that we have a lot of different devices and that many potential contributors have implemented the same device, so i am looking forward to a good discussion on having great quality drivers for these devices. About the releases: I'll do the same as i do for pi4j-core and a release is a short step and i can do it whenever necessary. Frank can/could do it too. In future we can discuss adding additional developers for release management. It should also always coincide with documentation on the pi4j website and social media notifications, so that we can ride this new wave of momentum. |
|
Dear Pi4J enthusiasts: do your magic! |
|
Thanks a lot! Do you mind some more "policy" discussion?
|
|
PS: Maybe add a "don't depend on this while we seed this repository" warning -- so we are not bound to APIs immediately as they might mature a bit initially? |
|
feel free to further extend/improve the readme! that would be an awesome first merge request test ;-) |
|
Do you mind if I split it, i.e. reduce the README to usage information / the most important bits and move the rest to a separate file (CONTRIBUTING.md?) |
|
Please do! |
|
Should any tests be included in com.pi4j.drivers ? |
|
Unit tests are a struggle for the complete Pi4J project, as they require electronic components to conduct a full test... However, please add unit tests for helper methods and other testable methods. It's decided to have "full blown examples" separately in the pi4j-example-devices repository. public static void main(String[] args) {
// This driver needs component X, connected to Y.
// This is a minimal example of how to use this driver:
and here some example code
} |
|
In my utopian world - I envision 1 video display test - any video display driver added to com.pi4j.drivers should be able to pass this test. |
|
I'd prefer to avoid a "main" in drivers -- it will be partially redundant with the "proper" example and might pull in extra imports / utilities... |
|
I agree, that the driver project should not contain main classes. We can always add a main class in test. We would need to think how to start that, but i suppose this leads as back to adding a PR to the examples project as well, which will show how to use the driver and can then be executed from the JAR. Thus we can extend the examples project to build an executable JAR with perhaps a console menu to select which driver's example to run. |
|
Circling back to unit tests: with the examples being in a separate repository, I just realized there is no straightforward way to test changes without a more complicated local setup making sure the drivers are pulled from a local maven repository. How about using Assumptions to skip over tests for hardware that's not present? |
|
For each driver - should the repo also contain a datasheet ? |
|
Extra documentation is excellent, but it should not increase the size of the created library jar. Perhaps we could add a |
|
I have included a link to the vendor datasheet at the class level javadoc. A link to a copy might be better in terms of stability, but the corresponding subfolder will complicate the repository license... Not sure about a better option though... |
|
My goal in the examples repo was each device readme had a url to a datasheet. If one was available as some chips the manufacturer provides python and C code but no real datasheet. Url leaves the chance it goes stale. So a copy is better |
|
The problem is that links change or disappear overtime. |
Uh oh!
There was an error while loading. Please reload this page.
I feel like pi4j needs a new top level repository, pi4j-extensions. This repository would contain reusable device drivers and components. Basically promoting much of what is already written in pi4j-example-devices AND pi4j-example-components.
It would define interfaces like:
DualState ( on, off )
TriState ( on, off, held )
ColorDisplay
MonoDisplay
LinearPosition
Pixel
Components:
PixelColor used as input to set color of Pixel or Displays
SimpleButton implements TriState
SimpleSwitch implements DualState
ST7789 implements ColorDisplay
Adafruit5880 implements LinearPosition, TriState, Pixel
Both pi4j-example-devices AND pi4j-example-components would still exist. These projects now depend on pi4j-extensions. These projects would still define the logging framework, assets, launchers and executables.
All reactions