pharo-iot@lists.pharo.org

Pharo IoT Developers and Hardcore users

View all threads

Re: [Pharo-iot] new devices

DK
Denis Kudriashov <dionisiydk@gmail.com>
Sun, May 3, 2020 4:04 PM

Hi Rob.

Thank you, Allex, for your comments. When time permits, I will separate the issues into different posts. As a first step I have put code for two devices on Github: - https://github.com/robvanlopik/PCA9685-PWMExpander

It would be cool to push it to into PharoThings repo.

While working on the PWM module, it occurred to me that PharoThings has two different points of view. The first I would call "board-centric", where we tell the board what to do with its pins. That is also the way my PotPCA9685Device works. On the other hand there is the "pin-centric" view where pins have functions and are told what to do. This view is used in the inspectors. As the outputs of the PCA9685 look very much like GPIO pins, I wondered whether it would be worthwhile to model them as such. This doesn't seem possible in a direct way, so it would need the introduction of a PotBoardExpander. Maybe PotBoardConnector could be adapted for this purpose, but I think it should be something different. This reasoning also stems from my feeling that the Arduino is not really a PotBoard. For one thing, there is no reason why it would have to be a singleton; I can attach Arduinos through numerous serial and USB ports (and Bluetooth).

The #current variable is just for convenience. The main case it to have a board instance representing the actual physical thing where the image is running. So we can save the image and the "current board" will react on startup/shutdown events. Also we can access it from the remote image. Nobody should really use this singleton. Any logic should be modelled as devices where you have a board variable. At least that was an idea in my original design.

In case of arduino board it obviously don't need a current instance as nothing is running there. So it is the responsibility of user to maintain the connected arduino boards. PharoThings does not provide any model for that (not currently).

On the other hand it would very well fit the description of a PotBoardExpander. In that case PotBoard should have a superclass PotController that allows for having no pins of its own.. so any computer can control one or more Arduinos (To be precise, by "Arduino" I mean a Arduino-like Arduino-like board running the Firmata sketch and communicating through the Firmata protocol). The reason one would want to do this, is to have a uniform way of controlling pins, irrespective of board or device. Maybe this uniformity can also be achieved by implementing the protocol of PotBoardDriver for any device that has GPIO-like pins.

Yes. I think it is the right idea. I think implementing this kind of board expanders as devices is a good solution. But we need to introduce the notion of board extensions. The board extension is a special board (PotBoardExtension) plus a special driver (PotBoardExtensionDriver). The driver is created on extension device (PCA9685Device) which provides the actual access to extra pins.

This way all logic will be in devices. They implement "extra pin protocol" and provide configured  board as an extension using reusable classes. Something like:

PCA9685Device>>configureBoardExtension

boardExtension := PotBoardExtension from: self.

boardExtension addNewConnector: 'E1' with: {

3.3 powerPin. 5 powerPin.

17 gpio. 18 gpio: PotPWMFunction}.

Then we will need to extend board inspector with a knowledge about connected boards provided by devices. So we will be able to inspect them and access pins like in main board.

Hi Rob. > Thank you, Allex, for your comments. When time permits, I will separate the > issues into different posts. As a first step I have put code for two > devices on Github: - https://github.com/robvanlopik/PCA9685-PWMExpander > - https://github.com/robvanlopik/DS1307-TinyRTC It would be cool to push it to into PharoThings repo. > While working on the PWM module, it occurred to me that PharoThings has two > different points of view. The first I would call "board-centric", where we > tell the board what to do with its pins. That is also the way my > PotPCA9685Device works. On the other hand there is the "pin-centric" view > where pins have functions and are told what to do. This view is used in the > inspectors. As the outputs of the PCA9685 look very much like GPIO pins, I > wondered whether it would be worthwhile to model them as such. This doesn't > seem possible in a direct way, so it would need the introduction of a > PotBoardExpander. Maybe PotBoardConnector could be adapted for this > purpose, but I think it should be something different. This reasoning also > stems from my feeling that the Arduino is not really a > PotBoard. For one thing, there is no reason why it would have to be a > singleton; I can attach Arduinos through numerous serial and USB ports (and > Bluetooth). The #current variable is just for convenience. The main case it to have a board instance representing the actual physical thing where the image is running. So we can save the image and the "current board" will react on startup/shutdown events. Also we can access it from the remote image. Nobody should really use this singleton. Any logic should be modelled as devices where you have a board variable. At least that was an idea in my original design. In case of arduino board it obviously don't need a current instance as nothing is running there. So it is the responsibility of user to maintain the connected arduino boards. PharoThings does not provide any model for that (not currently). > On the other hand it would very well fit the description of a > PotBoardExpander. In that case PotBoard should have a superclass > PotController that allows for having no pins of its own.. so any computer > can control one or more Arduinos (To be precise, by "Arduino" I mean a > Arduino-like > Arduino-like board running the Firmata sketch and communicating through the > Firmata protocol). The reason one would want to do this, is to have a > uniform way of > controlling pins, irrespective of board or device. Maybe this uniformity > can also be achieved by implementing the protocol of PotBoardDriver for any > device that has GPIO-like pins. Yes. I think it is the right idea. I think implementing this kind of board expanders as devices is a good solution. But we need to introduce the notion of board extensions. The board extension is a special board (PotBoardExtension) plus a special driver (PotBoardExtensionDriver). The driver is created on extension device (PCA9685Device) which provides the actual access to extra pins. This way all logic will be in devices. They implement "extra pin protocol" and provide configured board as an extension using reusable classes. Something like: PCA9685Device>>configureBoardExtension boardExtension := PotBoardExtension from: self. boardExtension addNewConnector: 'E1' with: { 3.3 powerPin. 5 powerPin. 17 gpio. 18 gpio: PotPWMFunction}. Then we will need to extend board inspector with a knowledge about connected boards provided by devices. So we will be able to inspect them and access pins like in main board.
RV
Rob van Lopik <robvanlopik@gmail.com>
Sun, May 10, 2020 1:29 PM

On Sun, May 3, 2020 at 5:05 PM Denis Kudriashov dionisiydk@gmail.com wrote:

Hi Rob.

Thank you, Allex, for your comments. When time permits, I will separate the issues into different posts. As a first step I have put code for two devices on Github: - https://github.com/robvanlopik/PCA9685-PWMExpander

It would be cool to push it to into PharoThings repo.

Does that require any action from my part?

While working on the PWM module, it occurred to me that PharoThings has two ...

there is no reason why it would have to be a

singleton; I can attach Arduinos through numerous serial and USB ports (and Bluetooth).

The #current variable is just for convenience. The main case it to have a board instance representing the actual physical thing where the image is running. So we can save the image and the "current board" will react on startup/shutdown events. Also we can access it from the remote image. Nobody should really use this singleton. Any logic should be modelled as devices where you have a board variable. At least that was an idea in my original design.

I saw your recent remark on Discord. I don't care that much about evilness, as long as there is only one instance controlling the pins, because that obeys the physical reality. By the way, is there any framework to tell boards/pins/devices what to do on Pharo restart or device restart (with or without power down) . For example, you might would want to restart in a safe state, or in the previous state.

In the case of Arduino board it obviously don't need a current instance as

nothing is running there. So it is the responsibility of user to maintain the connected arduino boards. PharoThings does not provide any model for that (not currently).

Even here there is a hard constraint: you cannot open more Firmata instances on the same serial port. Luckily this is enforced by the OS

On the other hand it would very well fit the description of a PotBoardExpander. In that case PotBoard should have a superclass PotController that allows for having no pins of its own.. so any computer can control one or more Arduinos (To be precise, by "Arduino" I mean a Arduino-like Arduino-like board running the Firmata sketch and communicating through the Firmata protocol). The reason one would want to do this, is to have a uniform way of controlling pins, irrespective of board or device. Maybe this uniformity can also be achieved by implementing the protocol of PotBoardDriver for any device that has GPIO-like pins.

Yes. I think it is the right idea. I think implementing this kind of board expanders as devices is a good solution. But we need to introduce the notion of board extensions. The board extension is a special board (PotBoardExtension) plus a special driver (PotBoardExtensionDriver). The driver is created on extension device (PCA9685Device) which provides the actual access to extra pins.

This way all logic will be in devices. They implement "extra pin protocol" and provide configured  board as an extension using reusable classes. Something like:

PCA9685Device>>configureBoardExtension

boardExtension := PotBoardExtension from: self.

boardExtension addNewConnector: 'E1' with: {

3.3 powerPin. 5 powerPin.

17 gpio. 18 gpio: PotPWMFunction}.

Then we will need to extend board inspector with a knowledge about connected boards provided by devices. So we will be able to inspect them and access pins like in main board.

I might have a look at this, when I have finished my attempt to expand Firmata. Is there any documentation of the design of PharoThings, especially because there are no class comments or other explanation. For example: I would like to know why the connector class exists. Why can't boards simply have pins? After all, it seems irrelevant to the working how they are physically exposed. And when I also see a Header class I get confused. Same for PinModes; why define SDA and CLK (and others) where you will never access these pins directly in that function. I am interested in this PinMode stuff because you also run into that when you want to handle the Firmata capability-report-request. How do we handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a situation that can very well occur in practice)

That's it for the time being Rob

On Sun, May 3, 2020 at 5:05 PM Denis Kudriashov <dionisiydk@gmail.com> wrote: > Hi Rob. > > >> Thank you, Allex, for your comments. When time permits, I will separate >> the >> issues into different posts. As a first step I have put code for two >> devices on Github: - https://github.com/robvanlopik/PCA9685-PWMExpander >> - https://github.com/robvanlopik/DS1307-TinyRTC > > > It would be cool to push it to into PharoThings repo. > Does that require any action from my part? > > >> While working on the PWM module, it occurred to me that PharoThings has >> two >> ... > > > there is no reason why it would have to be a >> singleton; I can attach Arduinos through numerous serial and USB ports >> (and >> Bluetooth). > > > The #current variable is just for convenience. The main case it to have a > board instance representing the actual physical thing where the image is > running. So we can save the image and the "current board" will react on > startup/shutdown events. Also we can access it from the remote image. > Nobody should really use this singleton. Any logic should be modelled as > devices where you have a board variable. At least that was an idea in my > original design. > > I saw your recent remark on Discord. I don't care that much about evilness, as long as there is only one instance controlling the pins, because that obeys the physical reality. By the way, is there any framework to tell boards/pins/devices what to do on Pharo restart or device restart (with or without power down) . For example, you might would want to restart in a safe state, or in the previous state. In the case of Arduino board it obviously don't need a current instance as > nothing is running there. So it is the responsibility of user to maintain > the connected arduino boards. PharoThings does not provide any model for > that (not currently). > Even here there is a hard constraint: you cannot open more Firmata instances on the same serial port. Luckily this is enforced by the OS > > >> On the other hand it would very well fit the description of a >> PotBoardExpander. In that case PotBoard should have a superclass >> PotController that allows for having no pins of its own.. so any computer >> can control one or more Arduinos (To be precise, by "Arduino" I mean a >> Arduino-like >> Arduino-like board running the Firmata sketch and communicating through >> the >> Firmata protocol). The reason one would want to do this, is to have a >> uniform way of >> controlling pins, irrespective of board or device. Maybe this uniformity >> can also be achieved by implementing the protocol of PotBoardDriver for >> any >> device that has GPIO-like pins. > > > Yes. I think it is the right idea. > I think implementing this kind of board expanders as devices is a good > solution. But we need to introduce the notion of board extensions. The > board extension is a special board (PotBoardExtension) plus a special > driver (PotBoardExtensionDriver). The driver is created on extension device > (PCA9685Device) which provides the actual access to extra pins. > > This way all logic will be in devices. They implement "extra pin protocol" > and provide configured board as an extension using reusable classes. > Something like: > > PCA9685Device>>configureBoardExtension > > boardExtension := PotBoardExtension from: self. > > boardExtension addNewConnector: 'E1' with: { > > 3.3 powerPin. 5 powerPin. > > 17 gpio. 18 gpio: PotPWMFunction}. > > > Then we will need to extend board inspector with a knowledge about > connected boards provided by devices. So we will be able to inspect them > and access pins like in main board. > I might have a look at this, when I have finished my attempt to expand Firmata. Is there any documentation of the design of PharoThings, especially because there are no class comments or other explanation. For example: I would like to know why the connector class exists. Why can't boards simply have pins? After all, it seems irrelevant to the working how they are physically exposed. And when I also see a Header class I get confused. Same for PinModes; why define SDA and CLK (and others) where you will never access these pins directly in that function. I am interested in this PinMode stuff because you also run into that when you want to handle the Firmata capability-report-request. How do we handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a situation that can very well occur in practice) That's it for the time being Rob
DK
Denis Kudriashov <dionisiydk@gmail.com>
Sun, May 10, 2020 2:30 PM

Hi Rob

вс, 10 мая 2020 г. в 14:30, Rob van Lopik robvanlopik@gmail.com:

On Sun, May 3, 2020 at 5:05 PM Denis Kudriashov dionisiydk@gmail.com wrote:

Hi Rob.

Thank you, Allex, for your comments. When time permits, I will separate the issues into different posts. As a first step I have put code for two devices on Github: - https://github.com/robvanlopik/PCA9685-PWMExpander

It would be cool to push it to into PharoThings repo.

Does that require any action from my part?

Can you make PR?

Hi Rob вс, 10 мая 2020 г. в 14:30, Rob van Lopik <robvanlopik@gmail.com>: > > > On Sun, May 3, 2020 at 5:05 PM Denis Kudriashov <dionisiydk@gmail.com> > wrote: > >> Hi Rob. >> >> >>> Thank you, Allex, for your comments. When time permits, I will separate >>> the >>> issues into different posts. As a first step I have put code for two >>> devices on Github: - https://github.com/robvanlopik/PCA9685-PWMExpander >>> - https://github.com/robvanlopik/DS1307-TinyRTC >> >> >> It would be cool to push it to into PharoThings repo. >> > > Does that require any action from my part? > Can you make PR? >
DK
Denis Kudriashov <dionisiydk@gmail.com>
Sun, May 10, 2020 2:40 PM

вс, 10 мая 2020 г. в 14:30, Rob van Lopik robvanlopik@gmail.com:

By the way, is there any framework to tell boards/pins/devices what to do on Pharo restart or device restart (with or without power down) . For example, you might would want to restart in a safe state, or in the previous state.

There is very little support for this: Devices implement #connect/#disconnect methods. They are called by system accordingly when pharo is restarted (see PotBoard class>>#startUp:/#shutDown:).

вс, 10 мая 2020 г. в 14:30, Rob van Lopik <robvanlopik@gmail.com>: > > By the way, is there any framework to tell boards/pins/devices what to do > on Pharo restart or device restart (with or without power down) . For > example, you might would want to restart in a safe state, or in the > previous state. > There is very little support for this: Devices implement #connect/#disconnect methods. They are called by system accordingly when pharo is restarted (see PotBoard class>>#startUp:/#shutDown:). >
DK
Denis Kudriashov <dionisiydk@gmail.com>
Sun, May 10, 2020 5:52 PM

вс, 10 мая 2020 г. в 14:30, Rob van Lopik robvanlopik@gmail.com:

Is there any documentation of the design of PharoThings, especially because there are no class comments or other explanation.

No documentation of design, sorry. Or maybe Alex wrote something but it was probably examples. It's definitely should be fixed but I have no time for this now.

For example: I would like to know why the connector class exists. Why can't boards simply have pins?

Connectors represent physical connectors on the board. My first Raspberry was model B revision 2. It has two connectors P1 and P5. In different docs such "local group of pins" are named differently. I chose the "connector" name for this. Connectors are needed to show the pinout scheme of the board like in docs.

After all, it seems irrelevant to the working how they are physically exposed. And when I also see a Header class I get confused.

You probably mean GPIOHeaderReference and subclasses. There are various ways to reference GPIO pins using physical location:

  • by absolute number of header considering the order from the left to right and from the top to down
  • by row/column position on the connector (there are two columns and multiple rows depending on the connector configuration). So subclasses of GPIOHeaderReference represent these types of references. They are about physical location of GPIO pin headers. In the code they allow to get pins from the board:

board pinAtHeader: 3 gpioHeader "absolute number of pin header". board pinAtHeader: (2@1) gpioHeader "at 2 row and 1 column) board pinAtHeader: 1 gpioHeader @ #P5. "first header at P2 connector"

(There are PotBoardTests with these examples)

Same for PinModes; why define SDA and CLK (and others) where you will never

access these pins directly in that function.

The main purpose of the board model is to document the concrete board type and its connected peripherals. The idea is to see in the inspector exactly what you see in docs but with possibility to get much more information because it is a live view on the board state. Currently most of PotGPIOFunction's are only used to show the pinout in inspector. But who knows what we can get from them in future.

I am interested in this PinMode stuff because you also run into that when you want to handle the Firmata capability-report-request. How do we handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a situation that can very well occur in practice)

Do you have an example? I did not see how it is related to the board model.

That's it for the time being Rob

вс, 10 мая 2020 г. в 14:30, Rob van Lopik <robvanlopik@gmail.com>: > > Is there any documentation of the design of PharoThings, especially > because there are no class comments or other explanation. > No documentation of design, sorry. Or maybe Alex wrote something but it was probably examples. It's definitely should be fixed but I have no time for this now. > For example: I would like to know why the connector class exists. Why > can't boards simply have pins? > Connectors represent physical connectors on the board. My first Raspberry was model B revision 2. It has two connectors P1 and P5. In different docs such "local group of pins" are named differently. I chose the "connector" name for this. Connectors are needed to show the pinout scheme of the board like in docs. > After all, it seems irrelevant to the working how they are physically > exposed. And when I also see a Header class I get confused. > You probably mean GPIOHeaderReference and subclasses. There are various ways to reference GPIO pins using physical location: - by absolute number of header considering the order from the left to right and from the top to down - by row/column position on the connector (there are two columns and multiple rows depending on the connector configuration). So subclasses of GPIOHeaderReference represent these types of references. They are about physical location of GPIO pin headers. In the code they allow to get pins from the board: board pinAtHeader: 3 gpioHeader "absolute number of pin header". board pinAtHeader: (2@1) gpioHeader "at 2 row and 1 column) board pinAtHeader: 1 gpioHeader @ #P5. "first header at P2 connector" (There are PotBoardTests with these examples) Same for PinModes; why define SDA and CLK (and others) where you will never > access these pins directly in that function. > The main purpose of the board model is to document the concrete board type and its connected peripherals. The idea is to see in the inspector exactly what you see in docs but with possibility to get much more information because it is a live view on the board state. Currently most of PotGPIOFunction's are only used to show the pinout in inspector. But who knows what we can get from them in future. > I am interested in this PinMode stuff because you also run into that when > you want to handle the Firmata capability-report-request. How do we handle > an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a > situation that can very well occur in practice) > Do you have an example? I did not see how it is related to the board model. > > That's it for the time being > Rob >
RV
Rob van Lopik <robvanlopik@gmail.com>
Mon, May 11, 2020 9:50 AM

On Sun, May 10, 2020 at 6:53 PM Denis Kudriashov dionisiydk@gmail.com wrote:

Same for PinModes; why define SDA and CLK (and others) where you will

never access these pins directly in that function.

The main purpose of the board model is to document the concrete board type and its connected peripherals. The idea is to see in the inspector exactly what you see in docs but with possibility to get much more information because it is a live view on the board state. Currently most of PotGPIOFunction's are only used to show the pinout in inspector. But who knows what we can get from them in future.

I am interested in this PinMode stuff because you also run into that when you want to handle the Firmata capability-report-request. How do we handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a situa'tion that can very well occur in practice)

Do you have an example? I did not see how it is related to the board model.

Firmata has a  "capability request"  where it tells you for every pin what its present mode is, and what other modes it supports. In Firmata a mode is just a number (from 0 = digital input to 11, which includes PWM. Servo, OneWire, I2C, Stepper, ...). I can make these available to the caller, including putting them in FirmataConstants. But I wondered if I could use the Pharothings framework of PotGPIOFunction and PotIOPinMode to bring it in line with PharoThings. Of course I can read the sources, but maybe a short explanation from your side can save me a lot of time. Does PharoThings have the concept of capabilities, that is, a list of possible/allowed pinmodes for each pin of a board?

regards, rob

On Sun, May 10, 2020 at 6:53 PM Denis Kudriashov <dionisiydk@gmail.com> wrote: > > > Same for PinModes; why define SDA and CLK (and others) where you will >> never access these pins directly in that function. >> > > The main purpose of the board model is to document the concrete board type > and its connected peripherals. The idea is to see in the inspector exactly > what you see in docs but with possibility to get much more information > because it is a live view on the board state. > Currently most of PotGPIOFunction's are only used to show the pinout in > inspector. But who knows what we can get from them in future. > > >> I am interested in this PinMode stuff because you also run into that when >> you want to handle the Firmata capability-report-request. How do we handle >> an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a >> situa'tion that can very well occur in practice) >> > > Do you have an example? I did not see how it is related to the board model. > Firmata has a "capability request" where it tells you for every pin what its present mode is, and what other modes it supports. In Firmata a mode is just a number (from 0 = digital input to 11, which includes PWM. Servo, OneWire, I2C, Stepper, ...). I can make these available to the caller, including putting them in FirmataConstants. But I wondered if I could use the Pharothings framework of PotGPIOFunction and PotIOPinMode to bring it in line with PharoThings. Of course I can read the sources, but maybe a short explanation from your side can save me a lot of time. Does PharoThings have the concept of capabilities, that is, a list of possible/allowed pinmodes for each pin of a board? regards, rob
DK
Denis Kudriashov <dionisiydk@gmail.com>
Mon, May 11, 2020 10:46 PM

пн, 11 мая 2020 г. в 10:51, Rob van Lopik robvanlopik@gmail.com:

On Sun, May 10, 2020 at 6:53 PM Denis Kudriashov dionisiydk@gmail.com wrote:

Same for PinModes; why define SDA and CLK (and others) where you will

never access these pins directly in that function.

The main purpose of the board model is to document the concrete board type and its connected peripherals. The idea is to see in the inspector exactly what you see in docs but with possibility to get much more information because it is a live view on the board state. Currently most of PotGPIOFunction's are only used to show the pinout in inspector. But who knows what we can get from them in future.

I am interested in this PinMode stuff because you also run into that when you want to handle the Firmata capability-report-request. How do we handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi (a situa'tion that can very well occur in practice)

Do you have an example? I did not see how it is related to the board model.

Firmata has a  "capability request"  where it tells you for every pin what its present mode is, and what other modes it supports. In Firmata a mode is just a number (from 0 = digital input to 11, which includes PWM. Servo, OneWire, I2C, Stepper, ...). I can make these available to the caller, including putting them in FirmataConstants. But I wondered if I could use the Pharothings framework of PotGPIOFunction and PotIOPinMode to bring it in line with PharoThings. Of course I can read the sources, but maybe a short explanation from your side can save me a lot of time. Does PharoThings have the concept of capabilities, that is, a list of possible/allowed pinmodes for each pin of a board?

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.

regards, rob

пн, 11 мая 2020 г. в 10:51, Rob van Lopik <robvanlopik@gmail.com>: > > > On Sun, May 10, 2020 at 6:53 PM Denis Kudriashov <dionisiydk@gmail.com> > wrote: > >> >> >> Same for PinModes; why define SDA and CLK (and others) where you will >>> never access these pins directly in that function. >>> >> >> The main purpose of the board model is to document the concrete board >> type and its connected peripherals. The idea is to see in the inspector >> exactly what you see in docs but with possibility to get much more >> information because it is a live view on the board state. >> Currently most of PotGPIOFunction's are only used to show the pinout in >> inspector. But who knows what we can get from them in future. >> >> >>> I am interested in this PinMode stuff because you also run into that >>> when you want to handle the Firmata capability-report-request. How do we >>> handle an Firmata-Arduino board connected to an USB port of a Raspberry Pi >>> (a situa'tion that can very well occur in practice) >>> >> >> Do you have an example? I did not see how it is related to the board >> model. >> > > Firmata has a "capability request" where it tells you for every pin what > its present mode is, and what other modes it supports. In Firmata a mode is > just a number (from 0 = digital input to 11, which includes PWM. Servo, > OneWire, I2C, Stepper, ...). I can make these available to the caller, > including putting them in FirmataConstants. But I wondered if I could use > the Pharothings framework of PotGPIOFunction and PotIOPinMode to bring it > in line with PharoThings. Of course I can read the sources, but maybe a > short explanation from your side can save me a lot of time. Does > PharoThings have the concept of capabilities, that is, a list of > possible/allowed pinmodes for each pin of a board? > 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. > regards, > rob >
RV
Rob van Lopik <robvanlopik@gmail.com>
Wed, May 13, 2020 8:20 PM

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

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
DK
Denis Kudriashov <dionisiydk@gmail.com>
Wed, May 13, 2020 9:49 PM

ср, 13 мая 2020 г. в 21:21, Rob van Lopik robvanlopik@gmail.com:

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.

Currently it is done for PWM IO mode:

PotGPIO>>bePWMOutput

function enablePWMOutputIn: self

Where only PotPWMFunction really understands #enablePWMOutputIn:. So any pins without pwm function will raise DNU.

Other questions I will reserve for other threads.

rob

ср, 13 мая 2020 г. в 21:21, Rob van Lopik <robvanlopik@gmail.com>: > 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. > Currently it is done for PWM IO mode: PotGPIO>>bePWMOutput function enablePWMOutputIn: self Where only PotPWMFunction really understands #enablePWMOutputIn:. So any pins without pwm function will raise DNU. > Other questions I will reserve for other threads. > > rob > > >