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

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 11, 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