pharo-iot@lists.pharo.org

Pharo IoT Developers and Hardcore users

View all threads

new devices

RV
Rob van Lopik <robvanlopik@gmail.com>
Thu, Apr 23, 2020 8:16 PM

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:

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). 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 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.

I have not been able to find a description of the design of PharoThings, but maybe someone wants to comment on these thoughts.

In the meantime I will start looking at Firmata.

cheers, Rob van Lopik

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 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). 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 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. I have not been able to find a description of the design of PharoThings, but maybe someone wants to comment on these thoughts. In the meantime I will start looking at Firmata. cheers, Rob van Lopik