Replies: 6 comments 9 replies
-
|
My only word on this topic is caution to include any device implementations that are directly associated with the project. In the past Pi4J V1 codebase, many contributors were happy to contribute/add new device and/or chipset extensions to the project but this became problematic over time as issues would come in asking for support/assistance/instruction and the original author was no longer around to assist. Additionally there was no real method/strategy for the Pi4J project to properly test all the unique devices and expansion chipsets. I realize that we are not including these devices/extensions as part of the Pi4J V2 core repository, but if they are listed under the Pi4J organization, then I fear the same trouble will come along if these become unmanageable. I also do think its a good idea for the project to have a few (well supported) examples of commonly used devices and extensions/expanders to serve as examples for other developer. So I'm not against having some limited device support -- I just think we have to be careful and judicious here. My suggestion is to have each device/extension as a separate repository so that it can stand on it own and have its own place for instructions, issue tracking and support. I think having these as smaller independent repositories may also help to encourage users to contribute changes back when not having to deal with a large source tree/project. This may also encourage users to create and manage their own extensions outside of the Pi4J project. Lastly we could have a single repository whose sole intent is a location to aggregate and list Pi4J extensions. But it would be information only and provide links to the repository for each plugin project. I think generically speaking, all of the extensibility modules are called "PLUGINS". A We may ultimately move some of the core plugins out of the core project as well -- that why I listed a few above. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robert |
Beta Was this translation helpful? Give feedback.
-
|
See my comments in the thread below to @hackerjimbo. I created a plugin shell project to help him get started. In his case the CAP1116 chip simply provides 6 digital INPUTs and 6 digital OUTPUTs so that plugin only needs to implement a Digital Input Provider and Digital Output Provider. I have not reviewed all of the device implementation you have created but you might want to find a simple one to start with such as a simple GPIO expander chip. This will be a learning exercise for all of us and I'm pretty sure we will need to augment the framework to handle some concepts that have not yet been considered/addressed such as the multiple instances and configuration needs for the plugins. Take a look at the starter shell plugin below (https://github.com/savageautomate/pi4j-plugin-microchip-cap1116) and at the real PiGPIO plugin here: https://github.com/Pi4J/pi4j-v2/tree/main/plugins/pi4j-plugin-pigpio. The PiGPIO plugin is a set of I/O providers for just about every supported I/O type with the exception of analog inputs and outputs. Thanks, Robert |
Beta Was this translation helpful? Give feedback.
-
Maybe your intention was only to create examples (which I see can be very useful/helpful) -- my brain made the leap to the v1 So sorry if I somewhat hijacked the discussion to talk about Thanks, Robert |
Beta Was this translation helpful? Give feedback.
-
|
Hi-jack is fine. |
Beta Was this translation helpful? Give feedback.
-
|
PS .. I realize what is listed in https://github.com/Pi4J/pi4j-device-tca9548 are not currently built as Pi4J plugins. |
Beta Was this translation helpful? Give feedback.
-
|
I've been looking at these and I'm a bit confused. Let me explain my concrete case and we can take it from there. I'm using a CAP1166 chip which has various LED outputs on it (not so much of a problem). However, its key feature is that it is a capacitive touch sensor. What I want to achieve is a way of configuring the device and then being able to ask it to provide a DigitalInput object that I can do all the good things like add a listener to. I want to make it look as much like an ordinary DigitalInput as possible. What would be the best way to go about this? Should the CAP1166 object have a create method? How like the one that hangs of the Context object should this look like? Should be be on the default context object by adding in a new provider? How would that be done? Should it use a DigitalInputConfigBuilder? If so, where would it find one? In essence, I'm trying to determine the right way to plug this functionality into the Pi4J-v2 architecture. Any pointers would be most welcome! |
Beta Was this translation helpful? Give feedback.
-
|
In my opinion .... I intended the Pi4J V2 architecture to support this concept (adding expansion I/O devices/chipsets) as a plugin. Specifically an I/O Provider plugin .... in this case a simple GPIO Digital Input Provider for the cap touch and a GPIO Digital Output Provider for the LEDs. Pi4J v1 has the concept of devices and components which were a higher level of abstractions -- but that really never got very far .. so V2 only includes simple I/O and not the higher level abstractions. None of this is really documented yet and there really are not any isolated examples to follow. Once this plugin JAR is compiled and placed into the classpath of your application alongside the other Pi4J JARs, the Pi4J framework should auto-detect and load this plugin on startup. In your consuming application you could access the custom I/O providers by name or class. Here is an example: // Initialize Pi4J with an auto context
var pi4j = Pi4J.newAutoContext();
// print which providers were detected in classpath
pi4j.providers().digitalOutput().describe().print(System.out);
pi4j.providers().digitalInput().describe().print(System.out);
// create custom INPUT and OUTPUT providers for the Microchip CAP1116
DigitalInputProvider dip = pi4j.provider("microchip-cap1116-digital-input");
DigitalOutputProvider dop = pi4j.provider("microchip-cap1116-digital-output");
// create INPUTS
DigitalInput touchSensor1 = dip.create(1);
DigitalInput touchSensor2 = dip.create(2);
DigitalInput touchSensor3 = dip.create(3);
DigitalInput touchSensor4 = dip.create(4);
DigitalInput touchSensor5 = dip.create(5);
DigitalInput touchSensor6 = dip.create(6);
// create LEDs
DigitalOutput led1 = dop.create(1);
DigitalOutput led2 = dop.create(2);
DigitalOutput led3 = dop.create(3);
DigitalOutput led4 = dop.create(4);
DigitalOutput led5 = dop.create(5);
DigitalOutput led6 = dop.create(6);
// shutdown Pi4J context now
pi4j.shutdown();The addressing scheme for creating input and output instances is really up to each implementation but in the case of CAP1116 it seems simple and straight forward to just use the fixed numbers 1-6 for both inputs and outputs. The part I don't have fully worked out in my head is how to handle the case of needing to instantiate multiple copies of the plugin; perhaps your project needs multiple CAP1116s. I'm not sure if the current architectural impl will even support that -- but it seems like something we will need to address. Perhaps this type of plugin should not auto-load and users could manually add them to the context with something like this. var contextBuilder = Pi4J.newContextBuilder()
.add(MicrochipCap1116DigitalInputProvider.newInstance());
.add(MicrochipCap1116DigitalOutputProvider.newInstance());
var pi4j:Context = contextBuilder.build();This brings up another important concept and that's how to pass config data to the provider. In the case of CAP1116 you may need a reference to the SPI or I2C provider it will need to communicate on the system. When the plugin/provider is created, it does get a reference to the Pi4J context so it could create its own I2C/SPI but it would still need some config data to do this. I sort of prefer the idea that a user created SPI or I2C instance is passed to the plugin on creation rather than the plugin trying to create it. It seems less magical and puts the user in complete control. For the time being you could pass config properties via the Pi4J context, but these are only simple property key/values. Again using the custom context where users create their own instances of the providers, perhaps something like this where a config object is needed to create the provider instance. var contextBuilder = Pi4J.newContextBuilder()
.add(MicrochipCap1116DigitalInputProvider.newInstance(---config---));
.add(MicrochipCap1116DigitalOutputProvider.newInstance(---config---));
var pi4j:Context = contextBuilder.build();I'll think on it some more and perhaps as you work on a real world implementation some of this may become more clear. Thanks, Robert |
Beta Was this translation helpful? Give feedback.
-
|
Just a little more playing, I have confirmed the following sample code will generate the following output using the prototype shell plugin. Note I also show various methods supported for the user to create INPUT and OUTPUT instances. Sample Code // create a Pi4J context builder and add the custom plugin providers
var contextBuilder = Pi4J.newContextBuilder()
.add(MicrochipCap1116DigitalOutputProvider.newInstance())
.add(MicrochipCap1116DigitalInputProvider.newInstance());
// Initialize Pi4J with a custom context
var pi4j = contextBuilder.build();
// create custom INPUT and OUTPUT providers for the Microchip CAP1116
DigitalInputProvider dip = pi4j.provider(MicrochipCap1116DigitalInputProvider.ID);
DigitalOutputProvider dop = pi4j.provider(MicrochipCap1116DigitalOutputProvider.ID);
// create INPUTS (various supported methods)
DigitalInput touchSensor1 = dip.create(1);
DigitalInput touchSensor2 = dip.create(2);
DigitalInput touchSensor3 = dip.create(3);
DigitalInput touchSensor4 = pi4j.provider(MicrochipCap1116DigitalInputProvider.class).create(4);
MicrochipCap1116DigitalInput touchSensor5 = pi4j.din().create(5);
DigitalInput touchSensor6 = pi4j.create(DigitalInputConfig.newBuilder(pi4j)
.provider(MicrochipCap1116DigitalInputProvider.ID)
.address(6).build());
// create LEDs (various supported methods)
DigitalOutput led1 = dop.create(1);
DigitalOutput led2 = dop.create(2);
DigitalOutput led3 = dop.create(3);
DigitalOutput led4 = pi4j.provider(MicrochipCap1116DigitalOutputProvider.class).create(4);
MicrochipCap1116DigitalOutput led5 = pi4j.dout().create(5);
DigitalOutput led6 = pi4j.create(DigitalOutputConfig.newBuilder(pi4j)
.provider(MicrochipCap1116DigitalOutputProvider.ID)
.address(6).build());
// print which providers were detected in classpath
pi4j.providers().digitalOutput().describe().print(System.out);
pi4j.providers().digitalInput().describe().print(System.out);
pi4j.registry().describe().print(System.out);
// shutdown Pi4J context now
pi4j.shutdown();Output: |
Beta Was this translation helpful? Give feedback.
-
|
I really like where this discussion is leading to :-) I have to admit I "pushed" @taartspi towards the example direction, but with the extra info given here by @savageautomate it is more clear now the framework really allows us to "extend" this further (and probably better) into the plugin direction. Summarized, a preferred approach would then take two paths:
I think for the examples, with the ongoing work of the FHNW students, we will have enough inside the GitHub project itself. Regarding the providers, it will indeed be a challenge to consider the documentation, testability, and support provided by the contributor to decide if we want to include this or refer to its own repository. A starting point to provide more info is available on https://pi4j.com/architecture/advanced/plugins/ but definitely will need more content. With the given info and if we fully take this approach, it would even make sense to make to move this to a main menu item with links to the own and external GitHub projects with a Pi4J plugin. |
Beta Was this translation helpful? Give feedback.
-
|
After the conversations and plug-in details: The devices I implemented as modules and not plug-in's could be ok for the moment as a usage of V2. But Frank/Robert if you think they will confuse the preferred issue of using plugins remove the link, or alter the description of the link. |
Beta Was this translation helpful? Give feedback.
-
|
One of the things that i read out of this discussion, is that there is a requirement for logical devices. I.e. a touch sensor or some such. The pi4j core library currently only offers an API for buses or low level I/Os which are simple, on/off etc. Adding logical devices e.g. a touch sensor, or a display etc. should completely wrap these low level APIs and then expose an API to communicate with the logical device and not with DigitalInput or DigitalOutput. At least this is how i would like to work with these devices. This layering could then always be brought to the next level, so that then one could logically group multiple cap1166 devices if needed to provider some specific logical device. For instance when one has a picade, then one would want to detect if button 3 is pressed. Thus one would have a Picade object, and add a listener to button three: this addListener method would then in turn add the listener to the real DigitalInput of the Pi4j core library. In my projects i work with a lot of MCP23017 devices. Here i would also have a logical MCP23017 device object, with which i would interface. It would then wrap the I2C bus and from a user of this API i would not need to use any pi4j I2C libraries. This is just my two sense and how i would like to interact with the API. What do you guys think? |
Beta Was this translation helpful? Give feedback.
-
Logical devices (and components) is what was removed from Pi4J V2. These previously included things like I think this is an ambitious effort and why I removed it from Pi4J v1.4 & 2.0. I never got the impression that it was adopted by very many users and you could imagine that its scope would be much larger than Pi4J raw I/O. Of course, I did not do much to promote it either and what exists is fairly limited. We are of course welcome to add it back in, but I think that effort should be re-evaluated after we get the core 2.0 I/O released. You can also see how aggregate devices were created in the previous version:
In the previous v1. API vernacular ...
I think the MCP23017 would be best implemented as a plugin with a digital input and digital output provider. It would need to be configured to use a I2C instance for its raw communication, but in the end, its just providing/expanding additional RAW I/O capability. I could see how one might want to use it in a logical device/component scenario if it were permanently attached to a fixed RELAY board/HAT and the user would never be concerned with the underlying RAW I/O state. Similar to PiFace here: https://github.com/Pi4J/pi4j/tree/release/1.3/pi4j-device/src/main/java/com/pi4j/device/piface |
Beta Was this translation helpful? Give feedback.
-
|
Wow! These are much better answers than I could ever have hoped for! There's a lot to read and digest here. You mentioned the ability to have the plugins auto load. I'm unsure how that would work. How does the core system find all the plugins available and plug them in? Clearly it's added to the list of providers but I'm unsure how it would go from the named provider (e.g. In this specific case I'm much more inclined to have instantiating an object register the providers. There are two reasons for this. Firstly, the cap1166 is one of a family of devices and secondly they can have different I²C addresses. Perhaps it should have some sort of interface that for a given cap1166 (or other related device) you give it the I²C bus and address and that creates an instance. That instance might have a specific name, for example Note that I haven't mentioned outputs. That's because the outputs are more than pure digital. They can be set to on, off or pwm but there is only a single PWM value for all the outputs. It's quite a subtle chip! I think the outputs are better handled by some chip-specific methods to deal with this. |
Beta Was this translation helpful? Give feedback.
-
Technically speaking the plugin implementation implements a Pi4J known " See:
The Pi4J core framework looks at all JARs in the classpath and attempts to load it if it defines a Pi4J V2 includes a
I think I may agree on not auto-loading these types of plugins -- at least for the time being. Especially because they require specialized/custom config. We may start with just manually creating and registering these providers to get up and running. Later we can evaluate the possibility of some config injected into the context that could auto create these provider instances and provide them unique IDs and config. I have started playing with some sample code on a means to pass in config and/or IO instances for the necessary I²C communication. I'll post an update when I have something worthy. In the meantime to get started, just hard-code your I2C config when the provider gets created.
I could just be implemented as an added standard PWM provider on the same plugin -- but with the caveat that modifying any PWM pin value actually applies to all PWM pins. The provider implementation would have to take care to sync everything. I would just focus on digital inputs and outputs and we can come back and take care of PWM later. Thanks, Robert |
Beta Was this translation helpful? Give feedback.
-
To bring back Pi4J to the "core", support for specific devices was removed from the library for V2.
Tom (@taartspi) created the project https://github.com/Pi4J/pi4j-device-tca9548 to illustrate how the Pi4J project still can provide device support, but as separate projects, not included in the "core".
He also created the below proposal which is a great piece of work I want to share here.
Please share your opinion on the best approach how to provide device support to the Pi4J V2 project.
Intro
Pi4J V1 had a large library of example devices. None of these were migrated to Pi4j V2.
A small sample of devices now exists in a separate Pi4J V2 git project, https://github.com/Pi4J/pi4j-device-tca9548. The intent was to create a set of examples that others would follow when they supplied more devices. These devices went through a review by some team members, comments were implemented with the exception of using ‘jcommand’ to parse user arguments. I decided jcommand was too ‘new’ to rely upon.
The following items are the remaining discussions to complete Example Devices.
Example Device Repository
Relocate the present examples. The current project name is incorrect as the contained devices have increased. Also later it will include ‘bus’ types other than I2C so various contexts will be required.
This device repo ‘repository’ should be separate from the pi4j_v2 product repo. The product repo carries with it an assumed level of testing that I believe will not exist as the number of donated example devices increases.
Minimal Requirements for Example Device
The device must use a data sheet for its implementation. The data sheet used should be documented in the README. If some registers or functions within a register are not implemented those details should be documented in the README. This requirement will result in some devices never being added, as not all manufactured willingly supply a data sheet.
Use the Maven build environment, matching the Pi4j V2.
The run.sh file using java --module-path .--module com.pi4j?????
Testing
This is more difficult to enforce. At the point in time, the device is ‘pulled’ into the repo the README examples serve as an initial test using the current level of Pi4J_V2 code. When a new version of Pi4J_V2 is released, it would be difficult to enforce all contributors to retest their devices. This fact being the main reason I stated the example device repo be separate from the product repo.
Beta Was this translation helpful? Give feedback.
All reactions