Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-entrancy requirements #12

Open
DavidMBrennan opened this issue Aug 22, 2024 · 3 comments
Open

Re-entrancy requirements #12

DavidMBrennan opened this issue Aug 22, 2024 · 3 comments

Comments

@DavidMBrennan
Copy link

Is this mutex strictly required for all API calls?

        mutex_lock(&g_bbapi.mutex);

I have utilized this code base as a guide to implement a BBAPI for another operating system. But I am finding that certain calls (BIOSIOFFS_CXPWRSUPP_DISPLAYLINE1/2) are very slow (up to 5ms). This is then blocking my ability to make calls to (BIOSIOFFS_CXPWRSUPP_GETBUTTONSTATE) in a timely manner from a separate thread. I would like to have a separate mutex for each "function" that requires re-entry protection, if that is allowed.

Is there any documentation for the actual bios call itself? Or is this code the entirety of the public documentation?

@pbruenn
Copy link
Member

pbruenn commented Aug 23, 2024

Unfortunately, the short answer is: "there is no finer grained locking possible". The bios implementation is hardware dependent so the actual implementation and fine grained locking would be hardware dependent.

You sound like you implemented your own version of the driver. So in your position I would simply try to call DISPLAYLINE and GETBUTTONSTATE in parallel. But I can't give you a guarantee this will always work and doesn't break on different hardware or even same hardware with different BIOS version.

In general if you need more documentation about the API calls, ask your Beckhoff support contact for "Beckhoff BIOS-API manual" we mention in the readme.

@DavidMBrennan
Copy link
Author

Thank you, Patrick. I have skimmed through the "Beckhoff BIOS-API manual rev 2.1" that was sent to me earlier by support. There is no mention in that documentation that the BIOS call is not re-entrant. When I asked them for more detailed information, they responded to ask my questions here.

As a secondary route, is there documentation for the peripherals themselves? ie. PCI information to write a driver without using the BIOS call? In my particular case, I am only interested in a "driver" for the CX2100-0014. There is a diagram that shows the S-UPS and it has spots labelled as see "S-USV" documentation and see "PWRCTRL" documentation. But I don't know if those are just software sections of this manual, or if there is specific programming documentation available for the CX2100-0014.

@pbruenn
Copy link
Member

pbruenn commented Aug 23, 2024

Of course you are right you shouldn't need the BBAPI if you access the hardware directly. Unfortunately, I can't tell you more than ask your support contact again. Maybe they are able to provide you with additional documentation on the specific hardware you use. I don't have more documentation myself and even if I had, I am missing the authority to provide such documents to the public. But ask our support when you tell them you are developing a driver for your own operating system they should be quite helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants