Giters

panda-official / TimeSwipe

PANDA Timeswipe driver and firmware

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

if timeswipe driver runs on raspberry and other one tries to connect: error message

LeilaPiri opened this issue · comments

commented

Definition of Done

  • code for mentioned task is complete. examples & documentations are complete.

  • build chains are tested

  • corresponding branch is closed

  • merging is done

commented

Whats meant by this is: Reading from Hardware-Buffer can only be done once at a time (otherwise clocking would cause weird behavior), we should add handling for that.

We could add this by requesting EnableADmes over SPI before sending own one and returning error if this is already 1. Would it work with two SPI instances? Or would that even be another indicator? Ideas please.

commented

maybe It is better to add a general-purpose locking system based on lock files into the library (/var/lock)

commented

so trying to run lib would result in error when another instance is already using it? Would that be most simple/stable implementation? @begodev any additional thoughts?

commented

yes, lock for library instance
This is the most simple implementation because it is a widely used pattern for any type of application

commented

@iluxa what would be result trying to open second instance - proper error message?

commented

API call for second instance get fails and print some message to stderr

commented

so onError would fire - or just global err?

commented

After the user application made the first API call to the library (driver) - lock file is created with PID number of the user app
if another app tries to make any API call - library checks that lock file exist and correspond PID is alive then this call fails with global error

commented

Ok, let’s give it a try. When first api call is closed lock file will be deleted right?

commented

so trying to run lib would result in error when another instance is already using it? Would that be most simple/stable implementation? @begodev any additional thoughts?

Would it be possible just to add a kind of Spin Lock (Mutex, Critical Section) inside the calling methode: then another instance will wait until the first one complete the request?

commented

Then a number of instances could run simultaneously?

commented

Hmm would make it more complicated atm, since what's "completed request" then?
I guess it would be nice in further steps to have shared memory - so if one is fetching data, other instances could also access that. But no need for now.

commented

Hmm would make it more complicated atm, since what's "completed request" then?

I mean an atomic transfer for the board: send a request, wait, return the data received. And the current instance blocks the bus, for example, with a mutex. Of course, all this concerns SPI communication only. Not for other driver's activity.

commented

Ok, this would also need to be done for memory controller then.

Let’s go for global locking for now. @iluxa will that approach also work for instances from py, js, cpp - with prebuilt binaries?

commented

will that approach also work for instances from py, js, cpp - with prebuilt binaries?

Yes, for any instances - will be on the library level
One limitation for this solution read-write filesystem is required, so it will not work on systems without filesystem or read-only filesystem

commented

since we're running on linux anyway - this shouldn't be a problem I guess.

commented

Couldn't test DataLogging (non static) on Timeswipe because dpkg is missing? (couldn't install the package).

commented

On Raspbian it seems pid file lock is working properly