|
|
| Re: emBRICK modul [message #1779453 is a reply to message #1779302] |
Mon, 08 January 2018 10:00   |
 Jose Maria Jesus Cabral Lassalle
Messages: 199
Registered: February 2016 |
Senior Member |
|
|
Hi,
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.
Regards,
Jose
|
|
|
| Re: emBRICK modul [message #1779469 is a reply to message #1779453] |
Mon, 08 January 2018 11:16 |
Michael G.
Messages: 10
Registered: December 2017 |
Junior Member |
|
|
Hi Jose,
i just wanted to use the EMbrick as a template,
i want to configure our own IO´s with 4DIAC.
Mr. Zoitl has shown me this module and made me friendly on it, but i have not yet come to the right...
My solution currently looks like this:
> i have mapped our IOs to groups in FB´s
> in this FBs the interfaced to read/write are initialized
> each IO has a unique ID and gets a name from this config-FB
> the IO block, like QX check on init if her param compare from this IO-list and saved the ID from there
> the ID is used to decide wich function is made for read/write
So i can with configuration blocks (SIFB) assign all my inputs,outputs,modules etc...
Best regards
[Updated on: Mon, 08 January 2018 11:21] Report message to a moderator |
|
|
|
|
Powered by
FUDForum. Page generated in 0.03315 seconds
] 
Search
Help
Register
Login
Home
