Re: writing usb drivers under 8.x
Jim Bryant wrote: > well, i can't speak for K&R 1978, as i can't currently find my copy, > but, for a quick brush up, you might want to read pages 80 and 81 > from K&R 2nd Ed. 1988. > > your idea that the preprocessor will evaluate > > #define thirtytwok (1<<15) > > into 0x8000 > > at compile time is totally incorrect, and in fact wouldn't be in > compliance with standards. i have iso and fips handy, care for > quotes? Who said anything about the preprocessor? The preprocessor is supposed to only do text substitutions, so you're right that _it_ doesn't (or at least, shouldn't) replace (1<<15) with 0x8000. The *compiler* does it. Look up "constant expressions". If you find a C compiler that generates a load and shift to evaluate (1<<15) at runtime, your next move should be to file a bug report with its maintainer -- unless you're dealing with a processor which can do the load and shift in less time or space than a direct load of 0x8000. And BTW, please don't top-post. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
On Monday 30 August 2010 04:18:56 Jim Bryant wrote: > well, i can't speak for K&R 1978, as i can't currently find my copy, > but, for a quick brush up, you might want to read pages 80 and 81 from > K&R 2nd Ed. 1988. > > your idea that the preprocessor will evaluate > > #define thirtytwok (1<<15) > For bit 31, you should consider adding a U, so that the values is not treated like a negative value. 1U << 31 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
but then gnu does it's own thing too. my point stands though. any
actual evaluation of thirtytwok into something OTHER THAN (1<<15) in the
actual emitted code is IMPLEMENTATION-SPECIFIC.
in the case if gnu, you do appear to be right though, in disregard to K&R.
one could also argue that my return(0) is implementation-specific, as
exit(0) would be proper by the numbers.
my point still stands, that although it may be cute to have (1<<15) in
the define, it is not good practice.
9:21:33pm orb(13): cat bs4.c
#include
#define thirtytwok (1<<15)
int main(void)
{
int toshiftornottoshift = thirtytwok;
printf("%d\n", toshiftornottoshift);
return(0);
}
9:21:39pm orb(14): cc -S -O2 -o bs4.s bs4.c
9:21:56pm orb(15): cat bs4.s
.file "bs4.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB3:
subq$8, %rsp
.LCFI0:
movl$32768, %esi
movl$.LC0, %edi
xorl%eax, %eax
callprintf
xorl%eax, %eax
addq$8, %rsp
ret
.LFE3:
.size main, .-main
.section.eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zR"
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB3
.long .LFE3-.LFB3
.uleb128 0x0
.byte 0x4
.long .LCFI0-.LFB3
.byte 0xe
.uleb128 0x10
.align 8
.LEFDE1:
.ident "GCC: (GNU) 4.2.1 20070719 [FreeBSD]"
9:22:00pm orb(16):
Jim Bryant wrote:
well, i can't speak for K&R 1978, as i can't currently find my copy,
but, for a quick brush up, you might want to read pages 80 and 81 from
K&R 2nd Ed. 1988.
your idea that the preprocessor will evaluate
#define thirtytwok (1<<15)
into 0x8000
at compile time is totally incorrect, and in fact wouldn't be in
compliance with standards. i have iso and fips handy, care for quotes?
microsoft used to do compile-time eval of preprocessor statements
instead of substitution, but that was implementation-specific and
non-standard.
From K&R, 2nd Ed. pp80-81 (1988):
4.11.2 Macro Substitution
A definition has the form
#define name replacement text
It calls for a macro substitution of the simplest kind - subsequent
occurrences of the token
name will be replaced by the replacement text. The name in a #define
has the same form as a
variable name; the replacement text is arbitrary. Normally the
replacement text is the rest of
the line, but a long definition may be continued onto several lines by
placing a \ at the end of
each line to be continued. The scope of a name defined with #define is
from its point of
definition to the end of the source file being compiled. A definition
may use previous
definitions. Substitutions are made only for tokens, and do not take
place within quoted
strings. For example, if YES is a defined name, there would be no
substitution in
printf("YES") or in YESMAN.
Any name may be defined with any replacement text. For example
#define forever for (;;) /* infinite loop */
defines a new word, forever, for an infinite loop.
It is also possible to define macros with arguments, so the
replacement text can be different
for different calls of the macro. As an example, define a macro called
max:
#define max(A, B) ((A) > (B) ? (A) : (B))
Although it looks like a function call, a use of max expands into
in-line code. Each occurrence
of a formal parameter (here A or B) will be replaced by the
corresponding actual argument.
Thus the line
x = max(p+q, r+s);
will be replaced by the line
x = ((p+q) > (r+s) ? (p+q) : (r+s));
So long as the arguments are treated consistently, this macro will
serve for any data type;
there is no need for different kinds of max for different data types,
as there would be with
functions.
81
If you examine the expansion of max, you will notice some pitfalls.
The expressions are
evaluated twice; this is bad if they involve side effects like
increment operators or input and
output. For instance
max(i++, j++) /* WRONG */
will increment the larger twice. Some care also has to be taken with
parentheses to make sure
the order of evaluation is preserved; consider what happens when the
macro
#define square(x) x * x /* WRONG */
is invoked as square(z+1).
Nonetheless, macros are valuable. One practical example comes from
, in which
getchar and putchar are often defined as macros to avoid the run-time
overhead of a
function call per character processed. The functions in are
also usually
implemented as macros.
Names may be undefined with #undef, usually to ensu
Re: writing usb drivers under 8.x
well, i can't speak for K&R 1978, as i can't currently find my copy,
but, for a quick brush up, you might want to read pages 80 and 81 from
K&R 2nd Ed. 1988.
your idea that the preprocessor will evaluate
#define thirtytwok (1<<15)
into 0x8000
at compile time is totally incorrect, and in fact wouldn't be in
compliance with standards. i have iso and fips handy, care for quotes?
microsoft used to do compile-time eval of preprocessor statements
instead of substitution, but that was implementation-specific and
non-standard.
From K&R, 2nd Ed. pp80-81 (1988):
4.11.2 Macro Substitution
A definition has the form
#define name replacement text
It calls for a macro substitution of the simplest kind - subsequent
occurrences of the token
name will be replaced by the replacement text. The name in a #define has
the same form as a
variable name; the replacement text is arbitrary. Normally the
replacement text is the rest of
the line, but a long definition may be continued onto several lines by
placing a \ at the end of
each line to be continued. The scope of a name defined with #define is
from its point of
definition to the end of the source file being compiled. A definition
may use previous
definitions. Substitutions are made only for tokens, and do not take
place within quoted
strings. For example, if YES is a defined name, there would be no
substitution in
printf("YES") or in YESMAN.
Any name may be defined with any replacement text. For example
#define forever for (;;) /* infinite loop */
defines a new word, forever, for an infinite loop.
It is also possible to define macros with arguments, so the replacement
text can be different
for different calls of the macro. As an example, define a macro called max:
#define max(A, B) ((A) > (B) ? (A) : (B))
Although it looks like a function call, a use of max expands into
in-line code. Each occurrence
of a formal parameter (here A or B) will be replaced by the
corresponding actual argument.
Thus the line
x = max(p+q, r+s);
will be replaced by the line
x = ((p+q) > (r+s) ? (p+q) : (r+s));
So long as the arguments are treated consistently, this macro will serve
for any data type;
there is no need for different kinds of max for different data types, as
there would be with
functions.
81
If you examine the expansion of max, you will notice some pitfalls. The
expressions are
evaluated twice; this is bad if they involve side effects like increment
operators or input and
output. For instance
max(i++, j++) /* WRONG */
will increment the larger twice. Some care also has to be taken with
parentheses to make sure
the order of evaluation is preserved; consider what happens when the macro
#define square(x) x * x /* WRONG */
is invoked as square(z+1).
Nonetheless, macros are valuable. One practical example comes from
, in which
getchar and putchar are often defined as macros to avoid the run-time
overhead of a
function call per character processed. The functions in are
also usually
implemented as macros.
Names may be undefined with #undef, usually to ensure that a routine is
really a function, not
a macro:
#undef getchar
int getchar(void) { ... }
Formal parameters are not replaced within quoted strings. If, however, a
parameter name is
preceded by a # in the replacement text, the combination will be
expanded into a quoted string
with the parameter replaced by the actual argument. This can be combined
with string
concatenation to make, for example, a debugging print macro:
#define dprint(expr) printf(#expr " = %g\n", expr)
When this is invoked, as in
dprint(x/y)
the macro is expanded into
printf("x/y" " = &g\n", x/y);
and the strings are concatenated, so the effect is
printf("x/y = &g\n", x/y);
Within the actual argument, each " is replaced by \" and each \ by \\,
so the result is a legal
string constant.
The preprocessor operator ## provides a way to concatenate actual
arguments during macro
expansion. If a parameter in the replacement text is adjacent to a ##,
the parameter is replaced
by the actual argument, the ## and surrounding white space are removed,
and the result is rescanned.
For example, the macro paste concatenates its two arguments:
#define paste(front, back) front ## back
so paste(name, 1) creates the token name1.
The rules for nested uses of ## are arcane; further details may be found
in Appendix A.
Exercise 4-14. Define a macro swap(t,x,y) that interchanges two
arguments of type t.
(Block structure will help.)
Jim Bryant wrote:
u.. you were saying???
8:58:44pm orb(19): cat bs3.c
#include
int main(void)
{
int toshiftornottoshift = 0x8000;
printf("%d\n", toshiftornottoshift);
return(0);
}
8:58:48pm orb(20): cc -S -O2 -o bs3.s bs3.c
8:58:53pm orb(21): cat bs3.s
.file "bs3.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB3:
subq$
Re: writing usb drivers under 8.x
u.. you were saying???
8:58:44pm orb(19): cat bs3.c
#include
int main(void)
{
int toshiftornottoshift = 0x8000;
printf("%d\n", toshiftornottoshift);
return(0);
}
8:58:48pm orb(20): cc -S -O2 -o bs3.s bs3.c
8:58:53pm orb(21): cat bs3.s
.file "bs3.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB3:
subq$8, %rsp
.LCFI0:
/*
* this doesn't look like the compiler generates a shift to me.
*/
movl$32768, %esi
movl$.LC0, %edi
xorl%eax, %eax
callprintf
xorl%eax, %eax
addq$8, %rsp
ret
.LFE3:
.size main, .-main
.section.eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zR"
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB3
.long .LFE3-.LFB3
.uleb128 0x0
.byte 0x4
.long .LCFI0-.LFB3
.byte 0xe
.uleb128 0x10
.align 8
.LEFDE1:
.ident "GCC: (GNU) 4.2.1 20070719 [FreeBSD]"
per...@pluto.rain.com wrote:
Jim Bryant wrote:
what kind of idiot defines a constant assignment for a 32k buffer as a
15 bit left shift of 1?
clever, yes. but in production, stupid.
a constant should be just that, a constant, and thus require no
computation at runtime.
Er, did you bother to look at the generated code before spouting off?
Most compilers, even as far back as K&R 1st edition, will compute
constant expressions like that at compile time.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
Jim Bryant wrote: > what kind of idiot defines a constant assignment for a 32k buffer as a > 15 bit left shift of 1? > > clever, yes. but in production, stupid. > > a constant should be just that, a constant, and thus require no > computation at runtime. Er, did you bother to look at the generated code before spouting off? Most compilers, even as far back as K&R 1st edition, will compute constant expressions like that at compile time. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
thanks. am doing that now. I already have one patch for this one what kind of idiot defines a constant assignment for a 32k buffer as a 15 bit left shift of 1? clever, yes. but in production, stupid. a constant should be just that, a constant, and thus require no computation at runtime. i'm old school, and what a lot of kids don't understand today is that small and efficient is still as applicable today as it was then. *** ulpt.c~ Thu May 6 22:28:17 2010 --- ulpt.c Sat Aug 28 01:42:11 2010 *** *** 87,93 &ulpt_debug, 0, "Debug level"); #endif ! #define ULPT_BSIZE (1<<15) /* bytes */ #define ULPT_IFQ_MAXLEN 2 /* units */ #define UR_GET_DEVICE_ID0x00 --- 87,93 &ulpt_debug, 0, "Debug level"); #endif ! #define ULPT_BSIZE 0x8000 /* bytes */ #define ULPT_IFQ_MAXLEN 2 /* units */ #define UR_GET_DEVICE_ID0x00 Hans Petter Selasky wrote: On Friday 27 August 2010 10:53:38 Jim Bryant wrote: it'll be a pair of character devices. lirc compat is a goal of this project though. most of the work is done on that front, i just need to port that over from linux. the features of the imon remote control are well-supported in lirc. /dev/lirc will exist in my driver. See sys/dev/usb/input/ulpt.c driver for how to create cdevs. Don't use cdev directly in the kernel. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
since the display is 16x2, i kind of think a tty device would be gumming up the works. no sense in cooking the output. scrolling is done manually. the entire display of both lines has to be sent in every write. the samsung vfd panel itself has far more features than soundgraph (the manufacturer of the imon) has put into this (at least based on what their windows software does.. i'd kind of doubt that they are holding back features from their own software teams). i've only witnessed six types of transactions in their software. vfd text downstream. bargraph downstream. set/display static standby text. set/display freerunning standby clock/date. knob/button upstream. remote control upstream. all upstream is interrupt. i have verified all funtions in small test programs. bargraph is munged (i'm assuming that the bargraph is partially obfuscated by the fact that their display buffer seems to be only 16 bytes per line, when the samsung panel itself has 40 byte buffers for each 16 char line. line 1 left char is address 0 in the panel, and line 2 left char is address 40h, with 40 chars (28h) per line's display ram. i also suspect some intentional obfuscation involved in their bargraph scheme in a lame anti-reverse engineering attempt (their windows software always lags the music, and that's on an intel E8200, with large disk and 4 gigs of ram (3.9G addressable) the low-speed interface might also be a factor. personally, i'd do this at no less than 12mbit if i was the engineer...the chips are cheap enough. there seems to also be no support for the panel's on/off command (although i'm willing to bet it's there). there is no apparent support for the clear screen function (soundgraph's software does this by writing spaces to the display in five packets, when the vfd display itself supports a one-byte command to do so). no cursor functions (the cursor line is only active in bargraph mode). no brightness control (the panel supports 4 brightness levels). the display's built-in scrolling only scrolls both lines left or right, not individual lines, so, i can see why they chose to not use that. the panel supports blinking text, but that is also unsupported. some of the information that does not apply to my unit, i will derive from Alexander Popov's imon-0.1 driver which is not 8.x compat. he lists several other id's for enumeration, and has a quirk for some older versions that need a 6th fixed dummy packet for writing text to the display. the current generation drive-bay version mass-marketed by antec (veris elite) which i have doesn't require it, but apparently, his silverstone lc16 chassis does. he also didn't figure out the bargraph, knob/button, or clock/static standby display, his driver only displayed text, decoded the remote. overall, the device is rather simplistic as packaged with the soundgraph controller board backing the panel. the samsung vfd used seems to be far more powerful than the soundgraph endpoint supports. again, i'm using their own software, sniffed, to determine the functionality and commands. the display is so simplistic, a tty interface would be overkill. just character devices in this, and due to the multiple functions, the write() interface will be via variable length typed packets (type, length, data), the read() interface envisioned will be similar if i implement buffering of knob input, or single bytes otherwise, one for each of the three active states. anyhow. time for bed. nite. Jim Bryant wrote: it'll be a pair of character devices. the imon vfd is oem'ed to virtually EVERY high-end vfd-equipped htpc case on the market, all such tend to have the remote control interface as well built into the unit. the difference exists with the knob/button, some have it, others don't. the knob/button uses interrupt packets like the remote, but a totally different kind of packet, and i don't see support for it in lirc, so, i'll probably integrate it into the vfd device as the only read, and leave the remote as a seperate 100% lirc device. if people want to tie the knob/button to the volume/mute function exclusively, they can do so outside of the lirc framework. imho, the knob/button has better use as a function selector associated with menus on the vfd, although it can be used for volume/mute with little modification to existing lirc-related code. another possibility would be to use a function in the vfd driver to switch it between the vfd device for discrete use, or to switch it to the /dev/lirc device and have it link directly to the lirc codes for the remote for the volume up/down/mute buttons, with the capability to switch it back with another call to the /dev/vfd device. this is the direction i'm leaning. since the vfd panel, knob/button, and lirc-compat remote are all going to be in this driver, it's kind of a no-brainer. the option to use the knob/button for either should be left t
Re: writing usb drivers under 8.x
On Friday 27 August 2010 10:53:38 Jim Bryant wrote: > it'll be a pair of character devices. > > lirc compat is a goal of this project though. most of the work is done > on that front, i just need to port that over from linux. the features > of the imon remote control are well-supported in lirc. /dev/lirc will > exist in my driver. See sys/dev/usb/input/ulpt.c driver for how to create cdevs. Don't use cdev directly in the kernel. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
it'll be a pair of character devices. the imon vfd is oem'ed to virtually EVERY high-end vfd-equipped htpc case on the market, all such tend to have the remote control interface as well built into the unit. the difference exists with the knob/button, some have it, others don't. the knob/button uses interrupt packets like the remote, but a totally different kind of packet, and i don't see support for it in lirc, so, i'll probably integrate it into the vfd device as the only read, and leave the remote as a seperate 100% lirc device. if people want to tie the knob/button to the volume/mute function exclusively, they can do so outside of the lirc framework. imho, the knob/button has better use as a function selector associated with menus on the vfd, although it can be used for volume/mute with little modification to existing lirc-related code. another possibility would be to use a function in the vfd driver to switch it between the vfd device for discrete use, or to switch it to the /dev/lirc device and have it link directly to the lirc codes for the remote for the volume up/down/mute buttons, with the capability to switch it back with another call to the /dev/vfd device. this is the direction i'm leaning. since the vfd panel, knob/button, and lirc-compat remote are all going to be in this driver, it's kind of a no-brainer. the option to use the knob/button for either should be left to the end-user/programmer. most people would rather use a remote control for volume/mute anyway. although there is very rudimentary support in linux under LCDd for the imon vfd, i'm thinking about not going that route. the end product may not end up being lcdproc /dev/lcd compat. it has limitations i don't like, and it wouldn't take advantage of the features the imon has. lirc compat is a goal of this project though. most of the work is done on that front, i just need to port that over from linux. the features of the imon remote control are well-supported in lirc. /dev/lirc will exist in my driver. Hans Petter Selasky wrote: On Thursday 26 August 2010 23:29:35 Jim Bryant wrote: Actually, all of my test programs (for testing my reverse engineering efforts) have been done in libusb-1.0. I would actually like to write kernel-level drivers though for these. Then you should look at existing drivers in /sys/dev/usb/xxx, which match your device class. What kind of API do you want to userspace? tty-device, character device? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
On Thursday 26 August 2010 23:42:46 Jim Bryant wrote: > does the libusb interface apply to kernel-level drivers, or is it userland? > > Hans Petter Selasky wrote: > > On Thursday 26 August 2010 22:32:44 Hans Petter Selasky wrote: > >>> where can i find documentation on this subsystem? > > > > man libusb > > > > --HPS It is user-space only. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
On Thursday 26 August 2010 23:29:35 Jim Bryant wrote: > Actually, all of my test programs (for testing my reverse engineering > efforts) have been done in libusb-1.0. > > I would actually like to write kernel-level drivers though for these. > Then you should look at existing drivers in /sys/dev/usb/xxx, which match your device class. What kind of API do you want to userspace? tty-device, character device? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
i was under the impression that it is userland-only. Jim Bryant wrote: does the libusb interface apply to kernel-level drivers, or is it userland? Hans Petter Selasky wrote: On Thursday 26 August 2010 22:32:44 Hans Petter Selasky wrote: where can i find documentation on this subsystem? man libusb --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
does the libusb interface apply to kernel-level drivers, or is it userland? Hans Petter Selasky wrote: On Thursday 26 August 2010 22:32:44 Hans Petter Selasky wrote: where can i find documentation on this subsystem? man libusb --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
Actually, all of my test programs (for testing my reverse engineering efforts) have been done in libusb-1.0. I would actually like to write kernel-level drivers though for these. Hans Petter Selasky wrote: On Thursday 26 August 2010 19:59:18 Jim Bryant wrote: i have some usb devices, in the hid class, that i am wanting to write some drivers for. seeing that one of these previously had an older non-submitted driver for 5.x-7.x online, i thought that might be a good starting point (the imon vfd/lirc driver), but that does not work, due to the changes in the usb subsystem. where can i find documentation on this subsystem? are there any decent skeletons to start with, or does this need to be from scratch? i'd like to start with a driver for the pcsensor temper usb thermometer, for which i already wrote a libusb util for, since these are widely sold, and very popular (and usually around $5 USD), and since it only has one transaction (read current temp), I figure it would be easier to start with while I learn the usb driver framework. as for the imon vfd unit, i'd like to tackle that next. i have written libusb utilities for all of the display functions supported, and have documented the knob/button interrupt packets (only three packet types, clockwise, counterclockwise, and button down). all of the remote control functions are well-documented in lirc. i've been looking through the sources in the sys tree, but would like to find some comprehensive documentation of the new usb subsystem, and maybe someone who can give me pointers as i go. jim Hi, Feel free to post patches here. Some choices you have: Use libusb v1.0 or v0.1 if you need portability. Else use libusb v2.0. All three versions are contained in -lusb on FreeBSD 8+. Sylvestre Gallon had some libusb examples in his USB P4 repositorium. Else if you have questions regarding libusb you can ask either here or at: libusb-de...@lists.sourceforge.net --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
On Thursday 26 August 2010 22:32:44 Hans Petter Selasky wrote: > > where can i find documentation on this subsystem? man libusb --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
On Thursday 26 August 2010 19:59:18 Jim Bryant wrote: > i have some usb devices, in the hid class, that i am wanting to write > some drivers for. > > seeing that one of these previously had an older non-submitted driver > for 5.x-7.x online, i thought that might be a good starting point (the > imon vfd/lirc driver), but that does not work, due to the changes in the > usb subsystem. > > where can i find documentation on this subsystem? > > are there any decent skeletons to start with, or does this need to be > from scratch? > > i'd like to start with a driver for the pcsensor temper usb thermometer, > for which i already wrote a libusb util for, since these are widely > sold, and very popular (and usually around $5 USD), and since it only > has one transaction (read current temp), I figure it would be easier to > start with while I learn the usb driver framework. > > as for the imon vfd unit, i'd like to tackle that next. i have written > libusb utilities for all of the display functions supported, and have > documented the knob/button interrupt packets (only three packet types, > clockwise, counterclockwise, and button down). all of the remote > control functions are well-documented in lirc. > > i've been looking through the sources in the sys tree, but would like to > find some comprehensive documentation of the new usb subsystem, and > maybe someone who can give me pointers as i go. > > jim Hi, Feel free to post patches here. Some choices you have: Use libusb v1.0 or v0.1 if you need portability. Else use libusb v2.0. All three versions are contained in -lusb on FreeBSD 8+. Sylvestre Gallon had some libusb examples in his USB P4 repositorium. Else if you have questions regarding libusb you can ask either here or at: libusb-de...@lists.sourceforge.net --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
On Thu, 26 Aug 2010, Jim Bryant wrote: also, i'd like to hook up with a committer, as i'd like to have the finished drivers in the official tree. both devices (the temper, and the imon) have uses suited to both home/workstation use, as well as server use, in fact my imon is installed in orb, which is a home multi-server (music, books, tv shows, movies, mysql, samba, etc), and i intend to use the imon vfd as a tool to get server info without having to login to the server (using the knob/button to select from a menu on the vfd), and it has uses in both home and enterprise server realms. i think the source tree would benefit from having both drivers once completed. Agreed, and I would also like to see a working LIRC module. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: writing usb drivers under 8.x
also, i'd like to hook up with a committer, as i'd like to have the finished drivers in the official tree. both devices (the temper, and the imon) have uses suited to both home/workstation use, as well as server use, in fact my imon is installed in orb, which is a home multi-server (music, books, tv shows, movies, mysql, samba, etc), and i intend to use the imon vfd as a tool to get server info without having to login to the server (using the knob/button to select from a menu on the vfd), and it has uses in both home and enterprise server realms. i think the source tree would benefit from having both drivers once completed. Jim Bryant wrote: i have some usb devices, in the hid class, that i am wanting to write some drivers for. seeing that one of these previously had an older non-submitted driver for 5.x-7.x online, i thought that might be a good starting point (the imon vfd/lirc driver), but that does not work, due to the changes in the usb subsystem. where can i find documentation on this subsystem? are there any decent skeletons to start with, or does this need to be from scratch? i'd like to start with a driver for the pcsensor temper usb thermometer, for which i already wrote a libusb util for, since these are widely sold, and very popular (and usually around $5 USD), and since it only has one transaction (read current temp), I figure it would be easier to start with while I learn the usb driver framework. as for the imon vfd unit, i'd like to tackle that next. i have written libusb utilities for all of the display functions supported, and have documented the knob/button interrupt packets (only three packet types, clockwise, counterclockwise, and button down). all of the remote control functions are well-documented in lirc. i've been looking through the sources in the sys tree, but would like to find some comprehensive documentation of the new usb subsystem, and maybe someone who can give me pointers as i go. jim ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
writing usb drivers under 8.x
i have some usb devices, in the hid class, that i am wanting to write some drivers for. seeing that one of these previously had an older non-submitted driver for 5.x-7.x online, i thought that might be a good starting point (the imon vfd/lirc driver), but that does not work, due to the changes in the usb subsystem. where can i find documentation on this subsystem? are there any decent skeletons to start with, or does this need to be from scratch? i'd like to start with a driver for the pcsensor temper usb thermometer, for which i already wrote a libusb util for, since these are widely sold, and very popular (and usually around $5 USD), and since it only has one transaction (read current temp), I figure it would be easier to start with while I learn the usb driver framework. as for the imon vfd unit, i'd like to tackle that next. i have written libusb utilities for all of the display functions supported, and have documented the knob/button interrupt packets (only three packet types, clockwise, counterclockwise, and button down). all of the remote control functions are well-documented in lirc. i've been looking through the sources in the sys tree, but would like to find some comprehensive documentation of the new usb subsystem, and maybe someone who can give me pointers as i go. jim ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
