Support Portal

This question was answered privately via separate email.  Below is the reviewed answer for the general public benefit:
----------

The NBUS API is written, tested, and not meant to be modified. A close() is not needed in any way. If you take a close look at nbuslock() it will only open() the /dev/mem file on the first access (it will also initialize the GPIO settings for the bus pins after mmap()ing the address space). Through the running life of the application, further calls to nbuslock() will only lock the bus and then return as the /dev/mem file handle is already open and mmap()ed. Once the running application closes, the kernel will automatically close the one open file handle. If a call to nbusunlock() were to use a close, this means nbuslock() would have to also be modified to re-open() the file handle. This would add a lot of overhead every time the bus needs to be locked and is not needed here due to the current layout of the routines.

To be specific and say it another way, if this API is used in an application, the first call to nbuslock() will open() /dev/mem, further calls to nbuslock() will NOT re-open the file and the file handle is open and valid through the life of the running application. A close() is not needed during runtime nor is it recommended as always closing and opening that file handle adds a lot of overhead that is not needed.

As for your loop, that is correct and suggested behavior. If you intend to do a lot more access to the FPGA during the lifetime of your program, we do recommend using nbuspreempt() to give up the bus if there is another application waiting on it.