Hi Michael,
It seems we share a similar philosophy. The first edition of our product
is essentially an HD44780 device attached to the cheapest USB GPIO
controller out there.
In the future, we might decide to add some hardware specific
functionality, but we'd much rather avoid doing anything that increases
the BOM of our devices.
The device is actually even dumber than the USBLCD unit - it requires
the HD44780 commands to be effectively bitbanged on the interface chips
GPIO.
Is there a convenient way to implement that? it seems to be able to
benefit with some code reuse from drv_HD44780?
Cheers,
Tomasz
On 01/18/11 22:46, Michael Reinelt wrote:
> Hi Tomasz,
>
>> For the sake of manufacturing simplicity and cost efficiency, we are
>> using a fixed function USB interface chip, whose
>> GPIO lines are used to toggle HD44780-compatible LCDs. Thus, we want
>> to go down the route of implementing a libusb
>> based control software, that would use USB interrupts to send control
>> commands to the LCD.
>
>> As advised in the
>> http://ssl.bulix.org/projects/lcd4linux/wiki/driver_howto, I'm posting
>> on this list in hopes of
>> finding some clues (beyond reading drv_USBLCD.c) on what we need to be
>> on the lookout for.
>
> I'm afraid I can't help you with electronics design, but as there's more
> than one driver for USB-based HD44780 displays, you probably want to
> read several different drivers...
>
> From my (lcd4linux-focused) point of view, I prefer "dumb" displays that
> doesnt have to much intelligence built in, but provide a more or less
> "raw" HD44780 interface on USB.
>
> MatrixOrbital and Crystalfontz for example are "intelligent" displays,
> writing a driver may be much more complicated than LCD2USB (wich is a
> very simple and very clean design).
>
>
>
> Regards, Michael
>
|
