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