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

["Frank Mc Alinden" <frankmc@xxxxxxxxxxxxxxxx>]

Hi Ian


> I first got one of these screens working on a Mega32 which is 32k
flash
> and either 2k or 4k ram. You need 1k of screen RAM to buffer the
output
> (i.e. mirror what is on the display)

My pic,s arent going to be much good then , not enough ram on the
16F876....

> 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.

> What do you think? Where would your preferences lie?

This sounds ok.....My only concern would be developement time...As your
currently  travelling back and forth to the states i cant see this  being
available any time soon ???

Any ideas of when they would be ready if you go down this path ???

Frank


----- Original Message -----
From: <ian.bird@xxxxxxx>
To: <ukha_d@xxxxxxx>
Sent: Wednesday, November 09, 2005 12:44 AM
Subject: Re: [ukha_d] [OT] Possible bulk buy on 128 by 64 graphic displays
with touch screen


> Hi Frank
>
> Nice to hear from you again.
>
> I first got one of these screens working on a Mega32 which is 32k
flash
> and either 2k or 4k ram. You need 1k of screen RAM to buffer the
output
> (i.e. mirror what is on the display) as my routines do not read from
the
> display. Rather they read and write to the ram buffer and when
complete
> dump the changed bits to the display. Simpler and faster for me. Other
> memory requirements are fairly modest and depend what you are doing in
the
> rest of the program.
>
> 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.
>
> 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.
>
> 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 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.
>
> Thanks
>
> Ian
>
>
>
>
>
>
>
> "Frank Mc Alinden" <frankmc@xxxxxxx>
> Sent by: ukha_d@xxxxxxx
> 08/11/2005 03:37
> Please respond to ukha_d
>
>
>        To:     <ukha_d@xxxxxxx>
>        cc:     (bcc: Ian Bird/CV/Novartis)
>        Subject:        Re: [ukha_d] [OT] Possible bulk buy on 128 by
64
> graphic displays with
> touch screen
>
>
> Hi Ian
>            I might be interested in a couple , but  as you know i dont
> program in a high level language ;-(.....Plus the requirements for 2
> serial
> ports ...although  i suppose you could use one of those i2c to serial
> chips
> ?? ..What sort of memory requirements for these things ?? I was
thinking
> of
> using the 16F876 chip which is an 8k device...Havent yet played with
the
> pic18F series which i believe may have 2 serial ports ....
>
> Frank
>
>
> ----- Original Message -----
> From: <ian.bird@xxxxxxx>
> To: <ukha_d@xxxxxxx>
> Cc: <ian@xxxxxxx>
> Sent: Tuesday, November 08, 2005 4:06 AM
> Subject: [ukha_d] [OT] Possible bulk buy on 128 by 64 graphic displays
> with
> touch screen
>
>
>> Hi all
>>
>> I am looking at buying some of these (see below) touch screen
displays
>> from Apollo for a project I am working on but the supplier has
upped the
>> minimum order quantity to 1000 pounds plus VAT and delivery. This
is a
>> little more than I wanted to spend so I am looking to share the
burden.
>>
>> The displays are available in either blue/white mode or amber/dark
blue
>> mode. They have a 4 wire resistive touch screen pre bonded onto
them.
> You
>> can see the non touchscreen version in action at the beginning of
the
> last
>> UKHA video. You can get a taster of the work I will do from this
page
>> although there are no details of the touch controller chip on
there.
>>
>> http://www.mollyology.com/ProjectsGraphicDisplayInterface.php
>>
>> I am thinking it would be best to sell these on with the touch
> controller
>> and other hardware fitted onto a small daughter board otherwise
>> interfacing would be problematic for most. I would bring out the
>> connectors to standard headers unless anyone wanted something
different.
>> The PCB's would be professionally produced - not home made.
>>
>> Here is the link to the suppliers page about the screens
>>
>> http://www.apollodisplays.co.uk/51553.php
>>
>> This would mean anyone could get into really neat touch screens
for
> their
>> home made devices at relatively low cost.
>>
>> I also have some C code to talk to these units using the parallel
>> interface as well as a library of functions for circles, ovals,
lines,
>> rectangles, text, custom characters and pictures which I will
share. The
>> code is written for the AVR CodeVision C compiler but should be
pretty
>> portable. I ported some of it from another compiler in the first
place
>> anyway.
>>
>> The touch screen outputs the touch coordinates with a T prefix
followed
> by
>> two 4 digit comma separated sets of coordinates. A release action
sends
>> the same string but the prefix is an R e.g. T0123,0232 or
R0212,0232.
>> Coordinates are sent across a serial link at 9,600 or 19,200 as
long as
>> the screen is being pressed. This enables dragging to be supported
if
> you
>> are really keen.
>>
>> If anyone is interested please mail me at ian at mollyology dot
com or
> on
>> list if applicable.
>>
>> I would expect the screen, associated electronics and PCB
completely
>> assembled and tested to be about 50 to 60 quid. I am not making
any
> money
>> out of this, just breaking even. I simply cannot afford the have
1200
>> quids worth of screens sitting on the bench for the next year or
two
> until
>> I complete my current rather complex project.
>>
>> I am not knocking the LCD shop or other sources of screens but I
do
>> believe these prices compare very favourably with lesser screens
e.g.
> the
>> 20 by 4 line display Keith mentioned earlier at 20 pounds in
single
>> quantities. They are simpler to interface but have no touch screen
> option
>> and are far less versatile.
>>
>> As always, feedback and suggestions welcome.
>>
>> Thanks
>>
>> Ian
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>