Received: from decel.ecel.uwa.oz.au by karazm.math.UH.EDU with SMTP id AA24018 (5.65c/IDA-1.4.4 for ); Wed, 23 Oct 1991 01:42:45 -0500 Received: from accfin.ecel.uwa.oz.au by decel.ecel.uwa.oz.au with SMTP (5.61+IDA+MU) id AA17208; Wed, 23 Oct 1991 14:40:59 +0800 From: jcross@ecel.uwa.oz.au (Jennifer Cross - pgmr) Message-Id: <9110230650.AA17992@accfin.ecel.uwa.oz.au> Subject: Re: Standards To: glove-list@karazm.math.uh.edu Date: Wed, 23 Oct 91 14:50:15 WST X-Mailer: ELM [version 2.3 PL11] Forwarded message: > From: Bernie Roehl > Subject: Standards > Some micellaneous thoughts on standards: > > After some careful thought, I've come to the conclusion that the various > VR input devices will be too varied to make a single, universal interface > practical. Depends at which level of abstration you use. SGI have a neat tool called "ConMan" which uses a pipe type metaphor to "connect" processes. With this, you could "connect" each of the PG output steams to various functions and customise the interface without any programming. (each process specifies it's input and output sockets to ConMan, and it manages the data flow). [...] > Since we wll probably have a set of routines for each VR input device we > develop, I would propose a naming convention: all the routines related to > the glove we love will have names prefixed with "glove_". Thus our ^^^^^^^^ no no no! Suffixed! hence init_glove() (perhaps open_glove() might be better) read_glove() reset_glove() (Still has a place in life - to reset glove parameters!) close_glove() (alternative to quit_glove) This allows like routines to be grouped by function (again abstracting from the specific). This would also make (next level up) routines like init(GLOVE) reasonable. > initialization routine would be glove_init(), our reading routine would > be glove_read(), and our wrapup routine would be called glove_quit() > (which, as an earlier poster pointed out, is probably more meaningful > than "glove_reset()"). Alternatively, would using a "standard" nameing, like those in X or Silicon Graphics GL standard (now being adopted by several major vendors) be better? > > As to the issue of external microcontrollers... I think it would be nice > to standardize a protocol for talking to them. Even though I don't have > one (yet; we have a 68HC11, and I'm just waiting for the person who has > the code to post it), here is what I propose: > > Host sends 'H' to board to put glove in hi-res mode > Host sends 'P' to board to poll it for a 6-byte packet > Host sends 'C' to board to tell it to send full 12-byte packet continuously > Host sends 'S' to board to stop continuous sending > Host sends 'D' to board, followed by a 1-byte byte count, followed by > that number of bytes of data to load into a buffer and execute Single byte char command sequences will prove limiting very quickly (esp. if you want to stick to "meaningful" assignments ?What does D stand for anyway Debug/Dump/Directly exec?) use numeric commands and reserve (top?) bit for "extended command" - 127 "risc" standard commands and 127 _Groups_ of additional commands. so a command like "init" might use a group - init/all, init/fingers, init/pos, etc. but a command like poll current position might be 82 (hex 0x52) anyone know the char? :-) > -- > Bernie Roehl, University of Waterloo Electrical Engineering Dept > Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca > BangPath: watmath!sunee!broehl > Voice: (519) 885-1211 x 2607 [work] > Great Job - managed to provoke me to submit! (No I dont have a PG yet, just can't afford a DG!) -- ___ ( > /) (voice) +61 9 362 6680 __/_/> ____ ____ o // _ __ (home) cjcross@DIALix.oz.au / / (__/ / <_/ / <_<_//__ (work) jcross@ecel.uwa.oz.au