|Re: emBRICK modul [message #1779453 is a reply to message #1779302]
||Mon, 08 January 2018 10:00
| Jose Maria Jesus Cabral Lassalle
Registered: February 2016
Can you give more information about what exactly are you planning to implement?
If you want to use the embrick hardware, you shouldn't need anything else. Everything should be there, unless you want new modules that aren't implemented yet.
Unfortunately, there isn't any documentation yet about the new module's architecture. I started looking at it to have an understanding. I uploaded an image with the most important classes and relations between them. I'll try to give below some information about it to see if it's understandable for the later documentation:
The ConfigFB are all classes related to the configuration FBs that are mapped in 4DIAC in a separated resource (where you write the name of the IX in the data inputs). Normally you have a master and many slaves. The master communicates with the slaves and most important, it creates the DeviceController when initializes. The DeviceController is the only part of the code that actually interacts with the Hardware, the rest interacts with the DeviceController.
The Mapper is an independent part of the code that just takes the IX/QX and similar from one side, and the Handlers from the ConfigFB from the other side, and when he finds the same name, it connects them, veryfing direction and repetition.
So when the Configuration FBs are initialized, the DeviceController is created, and each module of the ConfigFB reads the names given in its inputs and creates a HandleDescriptor that is known to the DeviceController. The HandleDescriptor is passed from the slave to the master, and from the master to the DeviceControlller. The DeviceController finally creates a Handle from the HandleDescriptor and passes this new Handle to the mapper, which will then make the connection to the IX/QX with the same name.
In a normal running, when you want to write a QX for example, through the processInterface, the QX calls the Handle to write a value, which in turn updates its value and tells the DeviceController that a new value has been written. The DeviceController then writes the value to the actual Hardware.
For the inputs, the DeviceController is checking constantly in its own thread the input Handles for new values, and when there's one, it lets the Handle know about it, which then calls the IX/IW to update its IN data output, and finally the DeviceController starts the new event chain from the IX.
The amount of classes can be overwhelming at the beggining, but most of them are doing all the job, so you just need to implement less code.
I hope this make things cleared than before.
Regarding the i2c, spi, gpio and so on, probably a good architecture would be to have a master for each one of them, so you could easily connect slaves to them and would be easi to understand the architecture.
Powered by FUDForum
. Page generated in 0.02333 seconds