The big problem I want to avoid is creating and managing a mutex in a dozen different places, managing filenames and everything for anything that thinks about using SPI.
My thought is creating a library file that contains a “SPI_Mutex” class that would manage the whole thing for me - from placing the lock-file in the correct location to managing the lock and arbitrating the access.
With this I could include SPI_Mutex as mutex and then use the methods, (for example mutex.get and mutex.release), in each of the various things I want to have a mutex for the SPI buss.
Would you give me a good class template that I can use?
I really hate doing that unless the posts are 99% angst and another 10% frustration talking, as I believe the process that gets you to the destination is as important as the destination itself. There’s usually a lot of irreplaceable experimental knowledge along the way!
And You deleted all the example classes!!! I wanted to copy them!!! (Growl, growl, hiss, hiss)
Wasn’t it Einstein who said “I’ve learned much more from my failures than I ever did from my successes.”
I’m sorry that I can’t give that posting five or ten likes as it is absolutely the correct solution, (Qualifier: Within the context of the GoPiGo robot, but that’s the requirement anyway so it’s all good!)
Thanks SO MUCH for all your help and effort you’ve put into to this project. And the education you’ve given me along the way!
You mean the several “doesn’t work” and the one “hard” way to do it on the GoPiGo3? No one should ever look at those. One of the principles of learning is never learn wrong stuff, and another is don’t learn from bad examples.
If you want an example - read the beautiful code the amazing DI folks wrote (on your robot at): /home/pi/Dexter/lib/Dexter/RFR_Tools/miscellaneous/di_mutex.py
. . . and there was discussion of making the use of the mutex the default.
Question:
Aside from the “pedagogical benefit” of making an inadvertent fool out of the unsuspecting student, is there any real disadvantage to having the mutex on full-time?
Does this mean you do this, but accept the risk that you may end up hung somewhere if the mutex gets deadlocked[1]?
If that’s true, how often do you experience this, if at all?
========== Footnotes ==========
That is, the risk is POSSIBLE though UNLIKELY, as in “going outside” has various risks, (getting hit by lightning[2], an errant airplane landing on your head, getting bitten by a biker-gang of badgers, etc.), though the probability may be quite small.
That actually happened to an uncle of mine many years ago.
He was out playing golf at a golf course in Norfolk, Va., with a bunch of his buddies on a warm and sunny day, and he was using an iron to get from the fairway to the green. When he swung the club it got struck by lightning, (from who-knows-where), and it struck him dead on the spot. Nobody knows for sure, but the suspicion is “heat lightning”. (i.e. A “bolt from the blue” as noted below.)
Yes I have to use mutex=True, and even one step further for programs which need read access to the GoPiGo3 but will never issue any effector commands, I created a no_init_easygopigo3.py which allows the initialization option (use_mutex=True, no_init=True) to turn off resetting the GoPiGo3 default speed to 300. Most of my programs set the default to 150 DPI, so if a second program that just wants to read the battery resets the speed to 300, the first program’s commands can be changed mid-motion.
Both Carl and Dave set use_mutex=True and roughly once every 4 to 9 months I have to reboot to clear the I2C error 5 of unknown cause.
Don’t know if you recall, but I had to create an I2C mutex protected BNO055 DI EasyIMU class - for some reason the DI IMU did not get the use_mutex=True option when they added the Software I2C with three channel I2C mutex (global, AD1, and AD2 connected I2C).
Dave no longer has a DI IMU (requiring clock stretching), and I have removed his DI Distance Sensor in light of having a 360 degree LIDAR). I have not seen an I2C error 5 on Dave since.
I do not think I have ever seen the mutex zombie locked, but Carl’s health checker does not test for it.
It is “daily thunderstorm season” here, so much of my days are spent counting the speed of sound seconds before venturing out of the house. We have “armour piercing lightning” roll through that did not read the book on Faraday Shields.
When I was “a wee lad” growing up in the southeast corner of Virginia, there was one steadfast, engraved in depleted Uranium, don’t even THINK of disobeying rule:
Thunder stops EVERYTHING and everyone immediately goes indoors.
Even if it’s not raining, if you hear thunder - that’s it.
On the other hand, a summer shower, sans thunder, was a treat because it was God’s sprinkler we kids used to cool off in the 90°+ heat.
Really? You are trying to solve “world peace” for all the non-Dexter uses? Good luck.
Previously when attempting to solve the generalized SPI mutex problem, you balked at having to put a generalized mutex code somewhere accessible to all SPI users. So now where are you going to put it? In a venv?
Stick with solving your problem and be happy if the DI mutex solves your problem on your robot. Do you really want to invest all the time and effort to making a generic solution which in actuality is one specific solution for a virtual crowd of “users” you don’t know and don’t know you?
Question:
If you “enclose” a bit of class method code within a mutex block as above, does all the code referenced by that code get included?
Assumptions:
I am assuming that nothing is multi-threaded.
Actually, I don’t know if ANYTHING within the GoPiGo library code is multi-threaded.
Everything necessary has already been included.
I am also assuming that the pseudo-code I’ve written “works”. (Though you can correct obvious usage errors.)
Viz.:
[class instances]
spi = SPI_Communication_Library
spi_mutex - SPI_Mutex
something_else = Some_Other_SPI_Class
[. . . . some code goes here . . . .]
# Do an SPI communication transaction
try:
spi_mutex.acquire()
spi.comm(data, address, [r|w])
finally:
spi_mutex.release
Where within “spi.comm” there is a reference to “something_else.method”
Viz.:
def spi.comm(data, address, direction)
[some code]
# "Some_Other_SPI_Class is an additional class that's
# essential for SPI communication.
# (maybe it bit-bangs the bytes?)
something_else.method(parm1, parm2, parm-n)
[more code]
return(result)
Do enclosed classes/methods “inherit” the mutex’s protection?
When I questioned Waveshare about mutexes to see if they’ve already done anything like this, (and if they’ve already proved it doesn’t work, why reinvent the wheel?), they requested a pull request to their repo if I got a mutex working.
So, I figured I’d give it a try.
All I’m going to do is provide the mutex library in the same way that Waveshare provides its own libraries. If the user wants to put this stuff in a venv, that’s the moose’s problem.
“spi_transfer_array” is the method called by everything else in the class(es) for any SPI communication
def spi_transfer_array(self, data_out):
"""
Conduct a SPI transaction
Keyword arguments:
data_out -- a list of bytes to send. The length of the list will determine how many bytes are transferred.
Returns a list of the bytes read.
"""
result = GPG_SPI.xfer2(data_out)
return result
However, spi_transfer_array references another class/method, “GPG_SPI.xfer2”, which is defined near the top as:
So you have to create a setup to create the egg with the mutex code, or you have to fork the entire waveshare library and add your mutex to their codebase and egg setup.
And BTW, setup tools is deprecated and I don’t know what the new library creation tool is. My modified-for-Bookworm GoPiGo3 API still uses setup, and I ignore the deprecated warning.
