- Pharo-iot - lists.pharo.org

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

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