Re: [Libphidget-devel] Documentation?

[Jack S. <js...@ja...>]

On Fri, 2002-09-06 at 23:01, Vadim Tkachenko wrote:
> According to Jack Strohm:
> 
> > On Fri, 2002-09-06 at 21:37, Vadim Tkachenko wrote:
> > > Jack Strohm wrote:
> 
> > > - What happens if wrong arguments are supplied (suppose, someone
> > > deallocated the phidget_type and forgot to discard the reference, and
> > > called a function again)?
> > 
> > since users don't allocate phidget_type they shouldn't ever deallocate
> > them.  
> 
> "shouldn't" and "wouldn't" are different things ;) As a paranoid type, I'd
> go as far as checking the heap (if it is accessible, of course) for the
> pointers to those phidget_type objects... I need to get my memories about
> C/C++ back, then I'd be able to give an educated guess on how to do it.

That does seem a bit extreme.  I can't really stop them from
deallocating any memory they aren't supposed to.  I mean you can type
free(234234); and it will compile, and maybe even run and deallocate
valid memory.  

I think that would be classified as a bug in their program, and not
mine, so I don't see why I should spend time guarding for it.  I do
agree with being careful (which is why the data structures are not
public), but I can't protect the user from all mistakes.

> 
> > > Let me play a devil's advocate for a while...
> > 
> > uh-oh, let me get my crosses and holy water  ;-)
> 
> Get some more ;)
> 
> > > > PhidgetManager's main reason for existence:
> > > > 
> > > >         1) it knows about all phidget devices on the system.  The user can
> > > > query for the existence of certain types of phidgets or for a specific
> > > > phidget and the manager handles this query.
> > > 
> > > Suppose I'm the user. Do I really care if it is a Phidget? Not really...
> > > To me, this is a USB device that just happens to be a Phidget, that's
> > > all. What I care about, instead, is that when this USB device arrives,
> > > its capabilities are accessible, and it would be a good thing if the
> > > arrival is announced. Possibly together with some device initialization,
> > > and possibly I'd like to have some persistent properties of this device
> > > restored.
> > 
> > I was looking at it from another point of view.  I own phidgets, I want
> > to interact with them.  I don't care that they are USB, I want to know
> > when they attach/detach, I want there firmware to be uploaded, and I
> > want to be able have a simple way to access all of there accessories. 
> > This was never meant to be generic beyond phidgets.
> 
> OK, good, now we're getting some use cases for the phidgets.
> 
> 1. read
> 2. write
> 3. upload firmware
> 4. receive arrival notification
> 5. receive departure notification
> 6. receive property change notification (?)

yes, while this is all done at the libphidget.so C library and not in
the C++ library.

> 
> What else?

hmmm, that seems to cover the general cases of what phidgets do.  

I also have the concept of a "unique device", of which a phidget is one
of.  Servo's are unique devices, digital I/O, etc.  All unique devices a
a unique identification number to locate them, for phidgets this is
there USB serial number.  (btw - remember serial number is only unique
within vendor Id's, I think)

> 
> > > All abovesaid somehow makes me think about the kernel drivers, though
> > > ;)))
> > 
> > Why is that?  I actually started playing with kernel drivers, but I kept
> > getting everyone telling me to stay in user space.
> 
> Funny question: is it possible to have a device driver that is running in
> user space?

Yes, libusb provides a generic interface in user space to access USB
devices.  This project will handle firmware updates and the various
communication protocols needed to get the devices to be functional.

> 
> > > Give you an example: if I have an LCD phidget, I'd probably like to
> > > treat it as a stream device supporting ANSI escapes so I can position
> > > the text and/or set the colors, if it is color... If it is an RFID (let
> > > me speculate that RFID is a chip that can be "scanned", exactly as the
> > > items are scanned on a checkout line in the store), then I'd probably
> > > like to have the device that will just send me arrival notifications
> > > from the RFID chips...
> > 
> > that is what I'd like to implement.  Although I don't have any input
> > devices to play with. (please Chester send me some!)
>  
> An example I forgot about when I was writing the previous message:
> 
> /dev/phidget/servo
>                   /controller/<id>
>                                   /propeties
>                                   /servo/<id>
>                                              /properties
>                                              /stream
>                                   
> 
> Something like that.

That's what I was originally going for, but the usb device driver guys
seemed to think I'd be better served using libusb.  I get the same
functionality, libusb does:

/proc/bus/usb
             /devices (text file)
             /drivers (text file)
             /001
                /001 (device 1 on bus 1)
             /002
                /001 (device 1 on bus 2)
                /002 (device 2 on bus 2)

I basically connect to these devices and use them.


> 
> > > (granted, the RFID example was farfetched, I have no idea how it works)
> 
> If I guessed it right, then
> 
> /dev/phidget/rfid/<id>
>                       /properties
>                       /stream

see they way I see it is:

PhidgetManager = /dev/phidget
PhidgetServo = /dev/phidget/servo/controller/<id>
Servo = /dev/phidget/servo/controller/<id>/servo/<id>

Now I know these aren't accessible at the shell level.

> 
> > The Phidget manager is a "singleton" object, there is one, and can only
> > be one created, if you access it, it is created automatically.
> 
> Damn, C++ guys have it easy - in Java, there's always a possibility to end
> up with multiple "singletons" if you start fiddling with class loaders, and
> there's always a possibility that you're not the only who tries to
> instantiate the same singleton, often with different parameters -
> singletones and Java just don't mix...

It took me awhile of searching before I found a singleton template
example that I was happy with.

> 
> > > But, if you talk about introspection, then the picture changes... I'd
> > > rather be able to walk the device tree and find all the abstractions,
> > > but again, does it have to be a Phidget or a generic USB device? Open to
> > > speculation...
> > 
> > Well this project is just for interacting with phidgets.
> 
> Well, probably, but the phidgets are more than just toys - they're real
> world devices, and it's quite possible that some people (count me in) will
> try to treat them as grown-up things ;)

I'm not saying that they will be toys (although I plan on "playing" with
them).  I'm just saying that the point of this library is to interface
with phidgets, anything more is for another library.  


> > So that's why it's just phidgets and not all USB devices.  There are other
> > USB drivers for other devices.  I wanted to abstract away the entire USB
> > API so the user wasn't exposed to it (cause it can get a little weird).
> 
> I'm with you here... Almost ended up rewriting the USB subset for Java, and
> the only thing that prevented me from doing it was lack of time and the fact
> that I've finished scratching my itch.

I wish USB was a bit simpler, that's what I'm trying to provide for the
user.  I don't like the interfaces, different ways to read and write
data, I just want a stupid file handle or a socket, but that's not how
USB works, oh well.

> > > Another thing I don't know how to approach - in Java, one is spoiled
> > > with listeners and asynchronous notifications. In C++, this will involve
> > > multithreading context, which I'm not ready to take on 'cause last time
> > > I've touched it was in OS/2 in 1994... Can you shed some light on this,
> > > please?
> > 
> > Me and a friend thought about this a lot, and we decided just polling
> > for events would be easier to implement and get the job done just as
> > well.  Most applications aren't MT.
> 
> Maybe it is so in C++ world. However, speaking for myself, I've spent last 7
> years in Java and got eventually fed up with it for one simple reason: it's
> BIG. OK, you can put together something in a day that you'd spend a month
> doing in C++ (collections, threading, etc.), fine, but the weight of the
> resulting code is just overwhelming.

when you say weight, what do you mean?

> 
> Now, I feel that I'm not the only one... And people who turn back to C++
> from Java *are* spoiled - all in all, it's a beautiful environment. I want
> my threads. I want my semaphores. I want my <name it>.

I'm actually been looking at doing some projects in java (jsp/EJB and
all that crap)

> 
> And the real world applications of phidgets will most probably be MT.

why do they need to be MT?  

I always thought MT was very cool, but the large the system the harder
MT seems to be to deal with. (specially if your OS has thread bugs,
*solaris*, *windows*).

I'm actually having a threading issue in another project.  A 3D graphics
engine I wrote that has 2 threads.  One draws everything, the other does
all the heavy LOD calculations.  Runs very smooth in Linux.  I ported it
to windows and it is CRAP.  the background thread gets schedules about
every few seconds for about 100th of a second.  If you increase the
threads priority any it nearly locks the machine up cause the kernel
can't get any time to process.