Re: [OT] Possible bulk buy on 128 by 64 graphic displays with touch screen

["Paul Robinson" <ukcueman@xxxxxxxxxxx>]

> Also, after my conversations with Paul I am thinking of creating the
> middleware chip using a Mega 64. If I did this it would be another PCB
> with all the gubbins on it and it would present a serial interface to
the
> world. The screen PCB would plug into it (to retain modularity) and
> everything would be generally very small as everything is surface
mount.
> It would take commands in order to draw on the screen (data) as well
as
> send back the position of any touch screen presses.
If you did that, I'd certainly relieve you of a few :-)

> Someone (and Paul may volunteer here) would have to create the PC
> application to format and feed this data the screen would need (I
would
> document the format) and interpret the finger presses returned. This
is no
> mean task in itself but once done would turn it into pretty much a
plug
> and play unit with the power of a PC behind it for the task of
building
> the screens. I already have all the programs to create pictures to
display
> on the unit from mono bmp images which will make life a lot easier.
This
> would pretty much hide the embedded code from everyone.
Yeah, I'd be up for that.

>
> This would not be xPL, xAP or anything else 'public' at this point. It
> would work as either a direct serial connection or through an MSS100
and
> each update to the screen would probably consist of 1k of data and
some
> handshaking. There would not be any reason that you could not put an
xPL,
> xAP front end or glue directly on the screen but I would say it was of
> limited value as the data is binary (well, sort of but not readable
> anyway). Having the PC application send xPL, xAP messages depending on
key
> presses would be a lot more worthwhile though but that will have to be
> taken up with the PC software writer. It could also display screens on
> receipt of a xPL, xAP  message, again very worthwhile. Something like
a
> plugin architecture where you could load your favourite version of
> communications language would be good (or write your own of course).
>
> What do you think? Where would your preferences lie?
I think a plug-in architdecture is exactly right. When finished, it should
be usable as an
xPL/xAP OSD as well as generating xPL/xAP messages in response to user
actions (so
messages go both ways). But initially it would work without xPL/xAP
support.

Would your API support graphics only, or text as well? Or put another way,
does the
display have built-in fonts that can be mixed with graphics?

> I would guess the Atmel based middleware would add to the unit cost as
it
> is a new PCB plus components, design and testing. I use boot loaders
on my
> Atmel designs so firmware could be upgraded/changed and I currently
plan
> to release the code to people who buy a unit.
I've just been looking at the spec for the Mega 64. I don't know how it
compares to the
various PICs out there, but it certainly looks very capable.

Now, if only you had a mega 64 simulator and a simulator for the display,
and connected
the two of them, I could do the job before even seeing the hardware :-)

Paul




___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com