Jump to content

Adding "state" to a HAL?


Recommended Posts

Hi all.. I've been playing around with various HAL implementations for a while now, and I have a question on implementing some simple "state" functionality in the HAL. I've attached one such example - It's just an abstraction layer for a range of I2C Adapter modules that I use (or intend to use in the future). So my parent class is an abstract I2cAdapter, with overridable (dynamic dispatch) methods and exposed private data, effectively forming my interface to upper layers. Then at run-time I will just instantiate one concrete 'product'. (By the way, when I say "Adapter", it's nothing to do with the GOF pattern). 

 

post-40077-0-32496300-1415401312.png

 

Now I also want to add some simple "state" functionality, and I'm hoping to get some pointers on the best way to approach this. The states I can identify in the HAL are:
 
1. Adapter physically disconnected (i.e. plugged out from the PC/laptop/whatever). I want upper layer(s) to know that this has happened.
2. Adapter connected, and enabled (normal operation).
3. Adapter connected, but disabled. Effectively I want the adapter to be in a high-Z state as far as the bus is concerned. (Of course this should happen automatically for a 'true' I2C adapter when its not accessing the bus, but unfortunately I can't guarantee that with the devices I'm using.) 
 
post-40077-0-66588300-1415401333.png
 
I've looked at the GOF State pattern, but I think it's too elaborate for this situation. Also, I'm not sure it really applies here anyway.
 
As I look at it, the Enabled/Disabled states can be done simply - just add one (or two) abstract method(s) in my parent class and let each concrete adapter implement the necessary functionality. But what's the best way to handle the Disconnected state? Should the concrete adapter implement some functionality and inform the upper layer if a disconnect has occurred? Or should the upper layer have some sort of a periodic check of connectivity? 
 
Maybe I should also add that one of the learning 'glitches' I'm having with LVOOP is the topic of collaboration between objects, and this post ties in with that to a certain extent. So any help would be appreciated.

 

 

Edited by dmurray
Link to comment

I'm not totally sure I understand everything you want to do, but I'll take a stab.

 

First, "Or should the upper layer have some sort of a periodic check of connectivity?" seems like an important part of the design. There is no way to discover the connected state unless you call some code, so the two options for that would be have some sort of thread attached to the object responsible for checking this state (ie something more like an actor) or to have the application code check periodically. To me, it feels like you only need to check for this condition when you try to talk on the network. For example, if your TCP client disconnects you don't know until you try to perform read or write. That is when LabVIEW informs you.

 

As for implementing these checks, it sounds to me like the answer might be the http://en.wikipedia.org/wiki/Template_method_pattern. As i understand this pattern, you would basically implement "ExecuteI2CTransaction" as static dispatch and then provide a series of steps you want to call ("check disconnected", "validate inputs", etc, etc "finalize transaction") and then some of those steps (like "validate" and "finalize") would be dynamic dispatch. This ensures that you have some structure you can enforce while still allowing for the objects to function as a HAL. 

 

Do either of these help, or am I missing the point entirely? :)

 

Link to comment

Thanks for the reply. I probably haven't explained what I'm doing very well and turned it into a difficult problem, when probably all I'm trying to do is implement some simple messaging. Even the Template pattern is too elaborate, to be honest. I've been playing around some more, and currently what I'm looking at is using the "Start Asynchronous Call" VI to run in the background and scan for connected I2C Adapters. If the status changes e.g. if the number of connected adapters goes from two to one, or one to zero, this VI sends a message to the higher level, and the higher level makes a decision on what to do. For example it just checks to ensure that the adapter it is using has not been disconnected. I'm using User Events to achieve this.

 

To be honest I don't really need this functionality in the HAL, as it just adds unnecessary complexity. But I'm struggling a bit with collaboration between objects in LVOOP and this seemed like a good opportunity to work through some of the concepts. I know there are a lot of good messaging threads on this forum but the discussion is often very deep and it's hard to pick out the fundamental techniques. So my new plan is to look through some of the implementations in the code repository to try and extract some of these fundamentals.

 

Thanks again for the reply.     

Edited by dmurray
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.