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 ti
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)
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 r
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
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.r
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 gene
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 runtim
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 manufact
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
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/butt
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
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/
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?
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
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 th
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
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
> imo
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,
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, boo
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
20 matches
Mail list logo
