- Pharo-iot - lists.pharo.org

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