May 2020 - Pharo-iot - lists.pharo.org

Telepharo and PharoThings on Pharo Launcher
by Allex Oliveira June 4, 2020

June 4, 2020

Hi everyone, I was syncing with Christophe how we can put TelePharo and PharoThings on Pharo Launcher, and I created a tool to generate the images of any repository in each commit using Travis CI and release the images on Github. So now it's easy to do that. But there are some questions: "Then, you should think under which category we should put Telepharo? Official templates? A dedicated category? If it is the official one, we should have max 2 entries for Telepharo I think. If you want to have all combinations, a dedicated category? Also one thing that could be annoying is that it is a continuous build, no stable (reproducible) version." I think we could have 2 entries in official one (Full Telepharo and PharoThings to Pharo 8 64) and to have an IoT category with telepharo and pharothings to pharo 7/8/9 32/64 client and server, minimal image, etc About the continuous build, maybe we can use the tag releases to PharoLaucher. But I think we need to think about a better way to see which version is running on the server, to download the same specific version of the client. Maybe when the client connects, it realizes some kind of test and shows a popup saying it's the same version or not, and which one is supposed to use... What do you think guys? Allex Oliveira

2 1

Telepharo Pharo 7 deprecation
by Allex Oliveira May 28, 2020

May 28, 2020

Hi, With Marcus I'm debugging Telepharo to Pharo 9 and there are some methods deprecated. For example: https://github.com/oliveiraallex/TostSerializer/commit/5e0554438c8ebd9fb38c… https://github.com/oliveiraallex/TelePharo/commit/5ba2a1040eae7f340e2d610ce… What's the better way? Create now a Telepharo branch of pharo7 (like the branch pharo6) and continue working in it applying these commits to work in pharo8/9 in the master branch? Allex Oliveira

2 1

Re: [Pharo-iot] new devices
by Denis Kudriashov May 13, 2020

May 13, 2020

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.

2 8

test
by Denis Kudriashov May 1, 2020

May 1, 2020

somehow I did not get any mails

2 3