- 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

Re: [Pharo-iot] Firmata callbacks

by Rob van Lopik

On Sat, Jun 6, 2020 at 1:59 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > ÑÑ, 4 Ð¸ÑÐ½. 2020 Ð³. Ð² 21:40, Rob van Lopik <robvanlopik(a)gmail.com>: > >> 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. >> > > The code example would be helpful to think about it. > Hi Denis, I don't have a specific code example, because that depends on the design of the eventual application. But we can discuss use cases. The Firmata sketch has a sampling interval that can be set from 19 ms upwards. When reporting is enabled for an analog pin or a group of digital pins, their value is reported after each sample interval. The latest value is stored in an instance variable and can be read when convenient; it is never more than one sample-interval old. Inside the Firmata driver I can implement code that detects when the value changes, or exceeds a given limit. If that is the only thing I am interested in, the driver should notify me of such an occurrence, without the program having to continuously read the data. This is use case 1. Probably to be solved with an Announcer (see later for some implementation questions). Firmata has more input modes: - I2C - onewire - encoder These have a sysex command to initiate a reading, but the answer arrives asynchronously. I store the answer in an instance variable (of the Firmata instance) and the user code has to wait some time (probably the sample interval time) before reading. When we issue the read command we could mark these data as "stale". On the other hand, once again, we could announce the presence of valid data. The other mode of operation is to instruct the firmata sketch to continuously (at the sample rate) update the values. This is equivalent to the above mode for analog and digital inputs, so we can freely read them when convenient. The stepper motor control is a separate case. In principle you order the stepper to do a number of steps at a certain speed and possible with specified acceleration and deceleration.But you can't continue sending commands. Firmata reports back when a command is finished and we will have to wait for that notification before sending a new instruction. You will notice that I already seem to show a preference for the Announcer framework. I saw you contributed to a discussion of Announcers in 2016 ( http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-td4913008.html) so I hope you can answer the following question: Looking at the code it seems that in #when: Announcement do: aBlock the block will be executed in the thread that raised the announcement. Now, the way Firmata is set up this has to occur in the processInput thread. As this thread has to keep up with the incoming data from the Firmata sketch, I think we should minimize the amount of processing in that thread. (I even think we should consider raising its priority a bit). Is this reasoning valid? And would it be solved by only using #when:send:to: ? The other solution (that I also see e.g. in Pymata) is to do the processing of sysex messages in a different thread. Or create a new process/task for each message. It is said that process creation is not too expensive, and otherwise I could use taskit with a task pool. By the way: in the meantime I have all of these devices basically working. Both on a Uno and a Micro. And with sketches generated with Configurable Firmata. The I2C mode also works with the PCA9685 and the DS1307 for which I previously wrote drivers for WiringPi. All comments welcome; I will put some more questions on the present Firmata in a separate thread. cheers Rob van Lopik

June 9, 2020

Re: [Pharo-iot] Firmata callbacks

by Denis Kudriashov

ÑÑ, 4 Ð¸ÑÐ½. 2020 Ð³. Ð² 21:40, Rob van Lopik <robvanlopik(a)gmail.com>: > 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. > The code example would be helpful to think about it.

June 6, 2020

Re: [Pharo-iot] Firmata callbacks

by Denis Kudriashov

Hi Rob. About WiringPi callbacks. I tried to use OS interrupts to be notified about pin changes (do not remember what was the wiringPi function). But it just proved that FFI callbacks do not work from non VM process. With Pharo 9 we will have threaded FFI and it will be finely possible. ÑÑ, 4 Ð¸ÑÐ½. 2020 Ð³. Ð² 21:40, Rob van Lopik <robvanlopik(a)gmail.com>: > 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 > > >

June 6, 2020

Firmata callbacks

by Rob van Lopik

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

June 4, 2020

Re: [Pharo-iot] Telepharo and PharoThings on Pharo Launcher

by Marcus Denker

> On 28 May 2020, at 23:22, Allex Oliveira <allex.oliveira(a)msn.com> wrote: > > 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 > I would now just put a dedicated Category. Then we can later see if it makes sense to have some in official or not. > 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... > Yes, that might be an ideaâ¦ an explicit version check. Marcus

June 4, 2020

Telepharo and PharoThings on Pharo Launcher

by Allex Oliveira

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

May 28, 2020

Re: [Pharo-iot] Telepharo Pharo 7 deprecation

by Denis Kudriashov

Hi Allex. I would prefer to avoid branching if possible because it requires to maintain both targets (do not forget to merge into all of them). So until we drop pharo 7 support I would use little hack to check what method is supported by current image. (with kind of #respondsTo:). ÑÑ, 27 Ð¼Ð°Ñ 2020 Ð³. Ð² 12:09, Allex Oliveira <allex.oliveira(a)msn.com>: > 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 >

May 28, 2020

Telepharo Pharo 7 deprecation

by Allex Oliveira

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

May 27, 2020

Re: [Pharo-iot] new devices

by Denis Kudriashov

ÑÑ, 13 Ð¼Ð°Ñ 2020 Ð³. Ð² 21:21, Rob van Lopik <robvanlopik(a)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 > > >

May 13, 2020

Re: [Pharo-iot] new devices

by Rob van Lopik

On Mon, May 11, 2020 at 11:47 PM Denis Kudriashov <dionisiydk(a)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

May 13, 2020

Re: [Pharo-iot] new devices

by Denis Kudriashov

Ð¿Ð½, 11 Ð¼Ð°Ñ 2020 Ð³. Ð² 10:51, Rob van Lopik <robvanlopik(a)gmail.com>: > > > On Sun, May 10, 2020 at 6:53 PM Denis Kudriashov <dionisiydk(a)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 >

May 12, 2020

Re: [Pharo-iot] new devices

by Rob van Lopik

On Sun, May 10, 2020 at 6:53 PM Denis Kudriashov <dionisiydk(a)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

May 11, 2020

Re: [Pharo-iot] new devices

by Denis Kudriashov

Ð²Ñ, 10 Ð¼Ð°Ñ 2020 Ð³. Ð² 14:30, Rob van Lopik <robvanlopik(a)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 >

May 10, 2020

Re: [Pharo-iot] new devices

by Denis Kudriashov

Ð²Ñ, 10 Ð¼Ð°Ñ 2020 Ð³. Ð² 14:30, Rob van Lopik <robvanlopik(a)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:). >

May 10, 2020

Re: [Pharo-iot] new devices

by Denis Kudriashov

Hi Rob Ð²Ñ, 10 Ð¼Ð°Ñ 2020 Ð³. Ð² 14:30, Rob van Lopik <robvanlopik(a)gmail.com>: > > > On Sun, May 3, 2020 at 5:05 PM Denis Kudriashov <dionisiydk(a)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? >

May 10, 2020

Re: [Pharo-iot] new devices

by Rob van Lopik

On Sun, May 3, 2020 at 5:05 PM Denis Kudriashov <dionisiydk(a)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

May 10, 2020

Re: [Pharo-iot] new devices

by Denis Kudriashov

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.

May 3, 2020

Re: [Pharo-iot] test

by Denis Kudriashov

Hi Rob. I will answer to your mail today or tomorrow. ÑÑ, 30 Ð°Ð¿Ñ. 2020 Ð³. Ð² 17:21, Denis Kudriashov <dionisiydk(a)gmail.com>: > Yes. > Possibly I forgot to activate subscription > > ÑÑ, 30 Ð°Ð¿Ñ. 2020 Ð³. Ð² 17:20, Rob van Lopik <robvanlopik(a)gmail.com>: > >> Then we will also try a reply. Did you see the mail of the previous >> thread? >> >> On Thu, Apr 30, 2020 at 4:07 PM Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> somehow I did not get any mails >>> >>

May 1, 2020

Re: [Pharo-iot] test

by Denis Kudriashov

Yes. Possibly I forgot to activate subscription ÑÑ, 30 Ð°Ð¿Ñ. 2020 Ð³. Ð² 17:20, Rob van Lopik <robvanlopik(a)gmail.com>: > Then we will also try a reply. Did you see the mail of the previous thread? > > On Thu, Apr 30, 2020 at 4:07 PM Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> somehow I did not get any mails >> >

April 30, 2020

Re: [Pharo-iot] test

by Rob van Lopik

Then we will also try a reply. Did you see the mail of the previous thread? On Thu, Apr 30, 2020 at 4:07 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > somehow I did not get any mails >

April 30, 2020

test

by Denis Kudriashov

somehow I did not get any mails

April 30, 2020

new devices

by 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

April 23, 2020

getting started

by Rob van Lopik

Hello all, since last summer I have been looking at Pharo-IoT. I am not new to Smalltalk (from Digitalk, Dolphin to Squeak on my first Pi, using the VM that came with Scratch) but not a professional. I run Pharo directly on the Pi as the Pi3B+ and Pi4 are fast enough to give a reasonable user experience (using VNC). In that way I also can use diverse utilities and Python to control the GPIO's. In the meantime I have written some code for the DS1307 real time clock, and for the PCA9685 PWM/ServoÂ port expander. I want to put these on Github, but now I run into the problem that Iceberg doesn't run on the Pi because of a missing libgit2.so. How do you solve this problem? Just put up .st filesÂ (classic st or tonel?). Other questions that have arisen: What about Pharo version 8? It seems to run on the Pi (after tricking it by putting a symlink libgit2.so in the VM directory), but when I tried to load IoT in an 32 bits image on Windows I got lots of errors stemming from Calypso. Is somebody working on this? I am also interested in Arduino. There is some support for it, but it doesn't seem complete. Furthermore I would like to use different kind of Arduino-like boards. Again, is somebody working on this? If not, I could take this up. Maybe including "configurable Firmata". It looks like I will have some spare time for the next months (locked up due to Corona restrictions) and I would like to contribute something useful and not duplicate work other people are doing. Please let me know of your ideas. Rob van Lopik -- This email has been checked for viruses by AVG. https://www.avg.com

March 23, 2020

Test

by Torsten Bergmann

Sept. 6, 2019

Re: [Pharo-iot] Test

by Marcus Denker

geht. Footer werde ich noch anpassen. > On 5 Sep 2019, at 17:01, Norbert Hartl <norbert(a)hartl.name> wrote: > > > -- > Pharo-iot mailing list > Pharo-iot(a)lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-iot_lists.pharo.org

Sept. 5, 2019

Test

by Norbert Hartl

Sept. 5, 2019