On Mon, May 11, 2020 at 11:47 PM Denis Kudriashov <dionisiydk@gmail.com> wrote:

Possibly you��will��need to��extend the design to address your needs.��Current model only covers what there��were in our hands:

Board classes define a configuration of pins where they specify a function for every pin. There is only function��for given pin (where PotBasicIOFunction is a default value).��
Functions have not much��responsibility now. They are mostly here for documentation purpose: having the board instance it should be clear what pins are able to do.
I can imagine that we should allow pins to have multiple functions.

IO mode of the pin (PotIOPinMode) is low level thing to implement input/output operations with pins. From the other side they represent how we can interact��with pin��and��It looks like a function. Maybe they can be merged. But that is what we have now.
��
About��"capability request". It would be cool to not specify pin scheme manually.
You can just request pinout/functions in YourBoard>>connect method.

Thanks for your insights. Yes, introspection would be nice . In the same way you might have a generic PiBoard that first tries to discover on what hardware it is running (WiiringPi��helps) and maybe after��that does a become:�� to the correct class.

Indeed function and mode may be to sides of the same coin. We will have to think about that. At the moment the total number of classes (and concepts) in PharoThings is a bit overwhelming.

For now I will concentrate on Firmata. A small Arduino is the cheapest way to add analog input to a Raspberry for example. This capability stuff also brings constraints��with it: when a pin only allows some modes, how do I make sure we don't assign an illegal mode to it? My question is not how to code that, but what is the Smalltalk way to handle it (report error, ignore, ....) bearing in mind that an IoT application in the end��is meant to be used by non-technical people.

Other questions I will reserve for other threads.

rob