From: Kevin Hester <kevinh@ge...> - 2004-04-30 03:45:54
My module is a publicly available device:
Complete withauser domain I2C 'driver':
My first task is going to be to make a 'real' character driver that
speaks characters written to it. However, there will be about a week
delay. When I opened the box, I discovered the wrong board was shipped
to me - some sort of PIC thing with no Winbond WTS701 to be seen. I'm
going to be using this for a piece of custom aviation datalogger I
already have running on an Amtel AVR microcontroller. I'm moving to
Gumstix because I need more 'head room' (Mainly MMC writing) ;-). My
avionics will be used on http://www.geeksville.com/plane.
On Apr 29, 2004, at 8:08 PM,
> From: Zach Welch <zw@...>
> Is your module a custom piece or something readily available? URL for
> its datasheet? As you discovered, the patches haven't been tested in
> every detail, but I appreciate your feedback. I look forward to seeing
> whatever patches you produce and the possibility of collaborating on
> I2C infrastructure required for our devices (the stuff recently spared
> from being spewed to lkml).
Kevin Hester wrote:
> Hi Zach,
> My module is a publicly available device:
> Complete withauser domain I2C 'driver':
Well, that does make it easier.
> My first task is going to be to make a 'real' character driver that
> speaks characters written to it.
Sounds like a good plan. Despite your parts mix-up, you can probably
start rolling on the driver before you get the right hardware; it does
make it harder to find motivation though. I strongly urge you to look
at the the driver for the Epson 8564 RTC chip, as recently posted to
lkml by Stefan Eletzhofer, and the surrounding discussion.
As that thread indicates, the kernel I2C code needs better
device/function abstraction. I would urge you to look at trying to
implementing a (or hooking into an existing) generic speech character
driver, factoring out the specific implementation details for your
module into the low-level I2C driver.
That separation allows drivers for other module implementations to be
written without having to rewrite the /dev and /sys interface portions;
further, it allows you to reuse the low level device driver from within
other areas of the kernel....
One example would be the system console. It looks like the synthesizer
could be piped general output if lines are wrapped at 80 characters,
though I don't imagine the dmesg output would sound very coherent
without significant extra processing of the stream. That makes a
speaklogd daemon an interesting next architectural leap, though there
must be some existing projects to extend once you've reached user space.