- Pharo-iot - lists.pharo.org

Pharo Mailinglist moved to new setup: pharo-iot@lists.pharo.org

by Marcus Denker

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

July 30, 2026

PharoIoT future

by robvanlopik＠gmail.com

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

April 21, 2022

Re: can't clone PharoThings

by Rob van Lopik

Sorry, Marius should have been Marcus (and Denis also...) rob On Thu, Oct 1, 2020 at 2:08 PM Rob van Lopik <robvanlopik(a)gmail.com> wrote: > Thanks, Marius, shortening the image name did the trick! > But I would appreciate if someone could detail for me the steps to take to > submit a pull request for PharoThings (to add a method to > ArduinoFirmataDriver to access the Firmata I2C connection, to add some > devices, possible to add another Pi driver). What is the starting point, a > standard image or the CI-PharoThings Image. How do I load the repo. Do I > have to create a separate branch for each pull request. In short, I need > some step-by-step guidance from more knowledgeable people; Iceberg is a bit > daunting to me (as it should have been to the Titanic). > > cheers > Rob van Lopik > > On Mon, Sep 28, 2020 at 8:56 AM Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hello, >> >> yes, as much as I understand the path is limited on windows an has some >> max length. >> >> Maybe just using a shorter name for" Pharo9.0-64bit-PharoThings >> (continuous)sep22â could fix it? >> >> Marcus >> >> > On 23 Sep 2020, at 17:31, Rob van Lopik <robvanlopik(a)gmail.com> wrote: >> > >> > >> > 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/testInstallDeviceConfiguredWithHeaderNumberOfUnexistingConne >> ctor.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 >> >

Oct. 1, 2020

Re: can't clone PharoThings

by Rob van Lopik

Thanks, Marius, shortening the image name did the trick! But I would appreciate if someone could detail for me the steps to take to submit a pull request for PharoThings (to add a method to ArduinoFirmataDriver to access the Firmata I2C connection, to add some devices, possible to add another Pi driver). What is the starting point, a standard image or the CI-PharoThings Image. How do I load the repo. Do I have to create a separate branch for each pull request. In short, I need some step-by-step guidance from more knowledgeable people; Iceberg is a bit daunting to me (as it should have been to the Titanic). cheers Rob van Lopik On Mon, Sep 28, 2020 at 8:56 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > yes, as much as I understand the path is limited on windows an has some > max length. > > Maybe just using a shorter name for" Pharo9.0-64bit-PharoThings > (continuous)sep22â could fix it? > > Marcus > > > On 23 Sep 2020, at 17:31, Rob van Lopik <robvanlopik(a)gmail.com> wrote: > > > > > > 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/testInstallDeviceConfiguredWithHeaderNumberOfUnexistingConne > ctor.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 >

Oct. 1, 2020

Re: can't clone PharoThings

by Marcus Denker

Hello, yes, as much as I understand the path is limited on windows an has some max length. Maybe just using a shorter name for" Pharo9.0-64bit-PharoThings (continuous)sep22â could fix it? Marcus > On 23 Sep 2020, at 17:31, Rob van Lopik <robvanlopik(a)gmail.com> wrote: > > > 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

Sept. 28, 2020

Re: can't clone PharoThings

by Denis Kudriashov

Yes. It's an issue with FileTree code format and Windows. We will need to migrate to Tonel to avoid too long paths. Now as a workaround you can try to use some "close to root" directory for clone location. ÑÑ, 23 ÑÐµÐ½Ñ. 2020 Ð³. Ð² 16:32, Rob van Lopik <robvanlopik(a)gmail.com>: > > 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 >

Sept. 24, 2020

can't clone PharoThings

by Rob van Lopik

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

Sept. 23, 2020

another driver (for the Pi this time)

by Rob van Lopik

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

Aug. 11, 2020

updated Firmata

by Rob van Lopik

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

July 30, 2020

Firmata and concurrency

by Rob van Lopik

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

June 9, 2020