- Pharo-iot - lists.pharo.org

Pharo Mailinglist moved to new setup: pharo-iot@lists.pharo.org
by Marcus Denker July 30, 2026

July 30, 2026

Hello ! We have moved the Pharo Mailinglists to a new setup. WARNING: We sadly could not migrate the settings for the subscribers (e.g. Digest) Please sign up at http://lists.pharo.org/accounts/signup to create an account to configure the lists as you need them. WARNING: one state *not* migrated includes "NO MAIL", this was used e.g. by people to send with different From:, but in addition, it seems that the old system did put subscribers with delivery problems in this state (without anyone getting notified). If you do not want to be in this list, please unsubscribe, see footer or just send a mail to me, I will remove you. Marcus

1 0

PharoIoT future
by robvanlopik＠gmail.com April 21, 2022

April 21, 2022

As announced on Discord, I would like to start a discussion on the future of Pharo-of-Things (PoT from now on). I have to begin with noting that PoT, at the moment, has all signs of an abandoned project. To mention a few points: \- get.pharoiot.org delivers Pharo7 \- iot.pharo.org mentions PiBakery (last updated in 2018). Why two web sites anyway? And we also have pharoiot.com \- Pharothings option in Pharo Launcher doesn't work \- github://pharo-iot/Pharothings last update 2020, README mentions pharo 6(!). \- WiringPi is deprecated and not included in latest Raspbian \- Does not work in P9 or P10 Maybe it is time for some spring cleaning :-) I came across PoT about three years ago and started first to extend the Firmata driver to (almost) the full protocol. After that I did PiGPIO as an alternative to WiringPi. Noting some things missing in the board model of PoT, I experimented with a slightly alternative approach that I named PoTs (with the "s" from simplified). Unfortunately I had less time than I hoped, so I did not push this very hard, also because of the lack of a SerialPort implementation since the end of 2019 (new headless VM). By now my project is "usable"; the design has proven to be able to cope with three different types of processors and a mix of pin functions. It needs cleaning up, of course. In the repo (github.com/robvanlopik/Pots) there is also a document on the design: "Pot-to-Pots.md" During the recent Pharo Days, I have discussed this with Marcus Denker and Allex Oliveira. We think that TelePharo does not have to be part of PoT; it is an interesting project, but needs more time and, IMHO, needlessly complicates the use of PoT. As to my work, we thought it was best to let the community decide whether or how to incorporate it, so that is the purpose of this post. PoT or PoTs is named after the Internet-of-Things (IoT), but fills only a small part of the subject. The role Pharo could play in that much larger context can be the subject of another post. PoT by itself only encapsulates the control of sensors and actuators in a Pharo object model, relying on drivers and lower level software/firmware to actually control the GPIO pins of an MCU. As such, it can be used in bigger projects, but then you would have to put more effort in robustness, reliability and recoverability (think power fails, electric interference etc.) I think up till now it has mostly been used for teaching and experimentation. In that case simplicity, availability and cost are important. Pots directly works on any computer with an attached Pi, Arduino or Pico. No need for Telepharo, as any recent Pi (even the Pi Zero) is capable of running Pharo 9 or 10 in UI mode. Pots API is simple: for I/O, PWM, servo, ADC only the messages #value or #value: are needed. The cost of a Pico is â¬5. When you blow it up it is easily replaced, in contrast to a Pi of â¬140. On the other hand there is ample documentation for PoT: the booklet, installation guides, the lessons in pharoiot.org etc. Installation is less of a problem, now that the Pi also has Iceberg so one Metacello script suffices for all scenarios. As far as teaching material goes, I plan to write some of my own, but I am also willing to adapt existing texts. My own target audience would be people who are used to electronics and microprocessors and would like to try out the benefits of Pharo. I welcome all comments, both on the future of PoT and the role my Pots project can play in that future. In the meantime I will continue polishing my projects and start writing some tutorials, probable on Github pages. Greetings from Portugal, Rob van Lopik

1 0

can't clone PharoThings
by Rob van Lopik Oct. 1, 2020

Oct. 1, 2020

When I try to add the PharoThings repository to my image I get the following error in Iceberg: Failed to stat file 'C:/Users/robva/Documents/Pharo/images/Pharo9.0-64bit-PharoThings (continuous)sep22/pharo-local/iceberg/robvanlopik/PharoThings/src/PharoThings-Hardware-Core-Tests.package/PotBoardTests.class/instance/testInstallDeviceConfiguredWithHeaderNumberOfUnexistingConnector.st': The filename or extension is too long. Would this be Windows specific? It happens both in a Pharo8 and a Pharo9 image cheers Rob van Lopik

3 4

another driver (for the Pi this time)
by Rob van Lopik Aug. 11, 2020

Aug. 11, 2020

First, thanks for merging my Firmata additions. There is a bit more to be done and I will certainly look into the suggestions for further refactoring. Because I didn't like the fact that WiringPi requires su and is limited in PWM and servo support, I looked at pigpio (( http://abyz.me.uk/rpi/pigpio/index.html) This has pwm and servo on all pins, and a lot more. Moreover it runs as a daemon (started with sudo) so no privileges are needed for the client. When I saw that the daemon has a socket interface, I decided to give it a go. The result is in https://github.com/robvanlopik/PiGPIO. This was fully developed on Windows10, with a Pharo8-IOT image from Pharo Launcher, against a remote Pi3B and a Pi4. I also wrote the corresponding PotBoardDriver. It works with an RpiBoard3B and also with the DT1307 I2C device that I had written. without code changes. I plan to add some more of the pigpiod functions, like SPI, pulse, maybe waveforms (that can be used to drive stepper motors). I would appreciate your feedback. Especially with regard to eventual inclusion in the IOT image. Next I want to look at PharoThings itself. The inclusion of Firmata (or Arduino devices) is a bit hindered by the connector concept (many of them haven't any or mostly it is single row). I would prefer to have this stuff away in an optional BoardLayout class, that you don't need for your everyday work. All persons are different. Personally I am less inclined to use the board inspector, as I would rather hook up an oscilloscope to the board (just as I used a logic protocol analyzer to check Firmata messages).Also the question of "modes" versus "functions" versus "capabilities" needs to be investigated. Another thing I want to think about is the need for subclasses for different devices. With configurable Firmata you can have many different devices, but the driver itself knows what the capabilitie are of the device; just like a Pi driver knows what type of Pi you are running on. It is holiday time now, but I am really interested to know what parts of Pharo-iot iare worked on now, by whom and what it is used for. Personally I will start using it for some moving objects within projects by my wife (she is a plastic artist) and I am planning to do some educational writing. Cheers Rob van Lopik

1 0

updated Firmata
by Rob van Lopik July 30, 2020

July 30, 2020

Hi All, It took a bit longer than expected (or I had less time available than hoped for), but a extended version of Firmata is available at https://github.com/robvanlopik/Firmata. The main changes are: - added support for i2c, stepper and encoder - limited thread safety - announcements for change of digital input and end of stepper motion - access to capability request and analog mapping - supports configurable Firmata - easier to add new devices (accelstepper and one-wire are on my list) - added a description of the API I tested with different Arduino boards from a Windows system through a USB connection. I hope you will take a look at the code and see whether it is worthy to replace the present version. cheers Rob van Lopik

1 0

Firmata and concurrency
by Rob van Lopik June 9, 2020

June 9, 2020

Hi All, When I first looked at Firmata, almost a year ago, I noticed that access to acquired data was shared between the thread that reads from the Arduino and the user code. This should be an uninterruptible operation. Later I learned that arrays #at: and #at:put: are atomic operations. As far as I can see this is not by design, but because they are primitives. Changing the workings of the VM could also change that. By the way, it is not very evident from any documentation that this is the case. It so happens that these data are in arrays, so it would be safe. But when adding other devices I also have to use some dictionaries, so now I will have to introduce a Mutex to coordinate access to these instance variables. Please let me know if you don't agree with this analysis. The part that sends commands to the Arduino also has concurrency problems. I expect a measurement and control system to be composed of different processes (threads in Pharo), while there can be only one instance of Firmata. So thread safety is important for all writes to the serial port. Full thread safety may not be necessary, as long as different processes access different functions of Firmata, e.g. one thread controls servo motors, another one steppers and a third one pwm output (the latter already is tricky, because both use analog writes). Anyway this is something the user should be aware of and take care of. But at least inside Firmata sending a sysex string to the serial port should be protected. I don't know whether the actual primitive operation (serialPort >> primWritePort: portNumber from: byteArray startingAt: startIndex count: count) is atomic. But serialPort>>netPutAll: contains (very little) Pharo code. I guess that it is sufficient when each method does only one "port nextPutAll:", so the byte array to be sent has to be prepared in advance. Separate sends of startsysex and endsysex should not be used. The same holds for all non-sysex sends. If not, I will have to protect all writes to the serial port with a mutex. Thirty years ago I once taught an "introduction to real time programming" for agricultural researchers. The main thing I wanted to convey was to be aware of possible problems. That attitude has remained with me, after all those years. But I thought I could better check with people like you, who have more actual/recent experience. The last realtime things I have done were with Arduino code. There a short critical section is easily accomplished by turning off all interrupts. cheers and thanks for any comments. rob van lopik

1 0

Firmata callbacks
by Rob van Lopik June 9, 2020

June 9, 2020

Hi all, During the last couple of weeks I have worked on implementing most of the sysex-based messages. This was great fun, because it greatly facilitates interaction between Pharo on any platform and the real world with a variety of devices. Now I am at the point where I have to address the fundamentally asynchronous nature of the Firmata protocol. At present we store the answers from requests in instance variables, but we don't know when these are available. Sometimes the protocol allows for continuous updates, so reading the data is semi-realtime. This happens with analog inputs, but can also be used with i2c devices or encoders. Driving a stepper motor really needs a callback or notification mechanism. When you instruct the stepper to do a number of steps you must be notified when it is ready for the next move. At this point I want your input on what is the "Pharoic" way of doing this. I can think of announcements or using Taskit, or simply passing a block to be executed when the answer becomes available. Maybe someone can point me to examples in existing packages. By the way, in WiringPi this callback facility also is missing (wiringPiISRPin: pinNumber edgeType: edgeType function: aFunctionPointerOrCallback >> shouldBeImplemented). regards rob van lopik

2 3

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