Addition to the 'next' generic serial plugin...

[Mark F]

I wasn't planning anything like this in the version of the serial plugin that I'm currently trying to test. HOWEVER, I will put it on the list of stuff to think about.

As usual, the actual logic would be easy. The hard part would be the user interface for defining which bytes go to which registers. It becomes a parsing problem and I don't really want to write a parser. I'll cover this in a different post.

Another problem, that this particular scenario will have is timing. The input (or hardware) plugins have no way of knowing when the previous register data has been used and, hence, don't know when they can update the data again. This is a problem in the current DVD/LCD solution as well.

Don't get me wrong, this is a good idea and has uses beyond your current problem. It just needs a bit more refinement to be fully functional. :smile:

[Bates]

All,

I know some of you (Mark, etc.) actively work on hardware plugin's and the multitude of us are very happy that you do. One thing that would be nice in a future version would be to allow part of the data that is received to be saved into registers so that other plugin's could get ahold of it. As you may know, I'm muddling around trying to figure out a simple way to map 3 byte mouse packets into usable Girder triggers. What would be nice in a serial plugin would be to have the trigger be simply the first byte of the three byte packet and have the other two bytes stored into numeric registers. In that way, when I detect a mouse like 1st byte, then I'd have the displacement information in registers that I could give to a mouse action plugin. Make sense?

This of course leads me to search for a mouse action plugin that would take data from a Girder register. Is there one that does that?

Jim