A lot of Plain assembly syntax is experimental and will be reviewed as we move forward. I think it is important to get concept ideas out in the open for discussions – we can always optimize keywords and syntax later.
In Distributed Systems we need to synchronizing data between multiple modules and this creates a need for a distributed database system. The transaction mechanism we created earlier fit straight into this, but I need to review the concept to cover a few loose ends.
use System Module LedHat Object LedGroup Bit Led1 Bit Led2 Bit Led3 End Interface C LedGroup leds[1..6] ... End
My previous example shows how I can call a function located on a different device. In this New example I want to set the leds directly from 32xIO by sharing data.
use System use LedHat Module 32xIO Transaction LedHat.leds[1] LedHat.leds[1].Led1=1 Update End
The “leds” array is declared as interface allowing other modules to access it, so we can as well just access the array from 32xIO inside a Transaction statement. What happens is that we use DRA to connect between LedHat and 32xIO as previously explained, but we now need to (1) send a message to lock access, (2) make the changes, (3) commit changes. We get two extra messages, but less code this way. This was the easy part!
The system illustrated above is two systems wired as one just to complicate things. 32xIO #1 need to connect to LedHat #1 and 32xIO #2 need to connect to LedHat #2. This creates ambiguity as we by default will connect at random – first request will get first LedHat in list etc.
One way of solving this would be to use different module names – this is possible – but you will end up maintaining separate code for multiple devices depending on how they are used. Let’s try to avoid that as much as possible! In this case I have two “domains”, each with an array of 3 x 6 leds using the same name. And as I don’t want to hard-code the domain name I need something else.
A classic solution would be a complicated configuration, but I do not want that either – I have spent to many hours configuring complex communication systems to walk into that trap.
The concept I want to test out is a “System Diagram” – some kind off high level description of our system with modules, devices and how they connect. With this in place I would only need to tell my module what role it play in that system – lets give it a try:
use LedHat use 32xIO System SpiderRobot Domain green owner LedHat LedHat greenLedGroup 32xIO greenIO End Domain blue owner LedHat Ledhat blueLedGroup 32xIO blueIO End End
The example above create a system “SpiderRobot” with two domain’s – “green” and “blue”.
I did consider using xml for this, but decided that this actually is part of our code and should use Plain syntax. I like xml because it is an excellent data storage format that can be edited manually if we need to – but, as xml syntax also can be very cryptic – difficult to read logic – this should not be part of any programming language – IMO!
pd 32xIO SpiderRobot -d blue
This is a proposed pd (program download) command. I will review the utility command line later, so this is just a quick & dirty proposal – 32xIO and SpiderRobot are plain assembly (*.pln files). -d blueIO tell the pd that the module can see domain “blue” in addition to global domain.
As the 32xIO now request a LedHat it will only be given access to the LedHat in the same domain. As we start LedHat and 32xIO we also report what domain we are, or that we are unassigned – in the later case we need to be assigned domain visibility & roles by an utility later.
use LedHat use 32xIO System SpiderRobot Domain green owner LedHat LedHat greenLedGroup 32xIO greenIO End Domain blue owner LedHat Ledhat blueLedGroup1 Ledhat blueLedGroup2 32xIO blueIO1 32xIO blueIO2 Wire blueIO1 to blueLedGroup1 Wire blueIO2 to blueLedGroup2 End End
This example complicate our story a bit because I decided to add a 2nd LedHat and 32xIO to domain “blue”. In this case I still do not what LedHat to connect to so we need to “wire” the system manually since auto-wiring will not work anymore.
The added “wire” statement solves this, but I just decided that having two LedHat’s was a bit much, so I want to use only one and let the two 32xIO Hat’s access different led Groups.
use LedHat use 32xIO System SpiderRobot LedHat greenLedGroup 32xIO greenIO 32xIO blueIO wire greenIO to leds[1] wire blueIO to leds[2] as leds[1] End
In this case I actually don’t need domain grouping so I just specify my 3 Hat’s and how they are wired together. The wire statement only specify visibility and how we view content. The code does in this case program leds[1] so as I wire blueIO to use leds[2] I also need to specify that this is seen as leds[1].
My concern here is that we introduce too many error scenarios, and as this is a highly experimental concept we need to be open minded for better solutions or loose ends.