AVR-Chat

Apologies in advance for the thoroughly non-AVR question but I'm really 
tearing my hair out with an LCD problem and I'm sure there are some 
really clever/experienced LCD'ers here (grovel, scrape) ...

We've recently switched to yet another cheaper, brighter, 16x2, HD44780 
compatible LCD (Ampire AC162DY1LY). A small number of these latest 
displays lock-up after correctly initialising and executing a (variable) 
number of display commands. By "lock-up" I mean that the busy-flag stays 
set for at least 150ms, after which time the watchdog resets the micro, 
which then attempts to re-initialise the display, and fails, presumably 
because it's still busy. Display shows the last written text overwritten 
by blocks on the top line, bottom line blank. The display controller 
appears to still be alive because the successive E-cycles show different 
data-bit patterns for the alternate BF and AC3 cycles (4-bit mode).

The LCD driver code has been untouched over 15 years, several thousand 
displays and half-a-dozen different display types. I've double-checked 
the timings and they're not even close to marginal. Code below [ok, it's 
an 80C196 but the comments are in english - 12MHz - port writes take 
833ns, branches 833/1500ns - I'll claim it's a deliberate reminder of 
how what a marvel AVR RISC is].

Has anyone experienced anything like this? Should I suspect faulty 
displays? Or my code?

TIA,
Mark

void LMFWriteData( void ) {
  /* on entry LMDATA contains DB0-7 */
  /* check busy status */
  asm bbc lmNoDisplay,0,checkBusyFlag ;
  asm br lmfwdEnd ;
checkBusyFlag:
  ioport1 = 0x2f ;                  /* rw=1, db4-7=weak1, e=rs=0 */
  ioport1 = 0x6f ;                  /* e=1, db7->busy flag */
  asm bbc ioport1,3,busyFlagClr ;
  ioport1 = 0x2f ;                  /* e=0 */
  ioport1 = 0x6f ;                  /* e=1, db7->AC3 */
  asm br checkBusyFlag ;
busyFlagClr:
  ioport1 = 0x2f ;                  /* e=0 */
  ioport1 = 0x6f ;                  /* e=1, db7->AC3 */
  ioport1 = 0x2f ;                  /* e=0 */
  /* write instr */
  asm ldb LMDATAHI,LMDATA ;
  asm shrb LMDATAHI,#4 ;            /* LMDATAHI.0-3=hi data */
  asm andb LMDATA,#0x0f ;           /* Clr LMDATA.4-7 */
  asm ldb ioport1,#0x1f ;           /* put rs=1,r/w=0,db4-7=weak1,e=0 */
  asm addb ioport1,LMDATAHI,#0x50 ; /* e=1,db4-7=hi data */
  asm addb ioport1,LMDATAHI,#0x10 ; /* e=0 */
  asm addb ioport1,LMDATA,#0x50 ;   /* put lo data,e=1 */
  asm addb ioport1,LMDATA,#0x10 ;   /* e=0 */
lmfwdEnd: ;
}

Hi Mark,

If your program has been working with other HD44780 display drivers, I'd 
assume some problem with the displays. I haven't seen that they changed 
anything within that chip.

Or does HD44780 compatible mean it actually uses an HD44780? Or something 
else?

Zack

On Wed, 22 Aug 2007, Mark Nowell wrote:

>
> We've recently switched to yet another cheaper, brighter, 16x2, HD44780
> compatible LCD (Ampire AC162DY1LY). A small number of these latest
> displays lock-up after correctly initialising and executing a (variable)
> number of display commands. By "lock-up" I mean that the busy-flag stays
> set for at least 150ms, after which time the watchdog resets the micro,
> which then attempts to re-initialise the display, and fails, presumably
> because it's still busy. Display shows the last written text overwritten
> by blocks on the top line, bottom line blank. The display controller
> appears to still be alive because the successive E-cycles show different
> data-bit patterns for the alternate BF and AC3 cycles (4-bit mode).
>

Mark Nowell wrote:
> Apologies in advance for the thoroughly non-AVR question but I'm really 
> tearing my hair out with an LCD problem and I'm sure there are some 
> really clever/experienced LCD'ers here (grovel, scrape) ...
> 
> We've recently switched to yet another cheaper, brighter, 16x2, HD44780 
> compatible LCD (Ampire AC162DY1LY). A small number of these latest 
> displays lock-up after correctly initialising and executing a (variable) 
> number of display commands. By "lock-up" I mean that the busy-flag stays 
> set for at least 150ms, after which time the watchdog resets the micro, 
> which then attempts to re-initialise the display, and fails, presumably 
> because it's still busy. Display shows the last written text overwritten 
> by blocks on the top line, bottom line blank. The display controller 
> appears to still be alive because the successive E-cycles show different 
> data-bit patterns for the alternate BF and AC3 cycles (4-bit mode).
> 
> The LCD driver code has been untouched over 15 years, several thousand 
> displays and half-a-dozen different display types. I've double-checked 
> the timings and they're not even close to marginal. Code below [ok, it's 
> an 80C196 but the comments are in english - 12MHz - port writes take 
> 833ns, branches 833/1500ns - I'll claim it's a deliberate reminder of 
> how what a marvel AVR RISC is].
> 
> Has anyone experienced anything like this? Should I suspect faulty 
> displays? Or my code?

I have had problems with Ampire displays and static, I found that by 
grounding the LCD Bezzle I could stop this problem.


> TIA,
> Mark
> 
> void LMFWriteData( void ) {
>   /* on entry LMDATA contains DB0-7 */
>   /* check busy status */
>   asm bbc lmNoDisplay,0,checkBusyFlag ;
>   asm br lmfwdEnd ;
> checkBusyFlag:
>   ioport1 = 0x2f ;                  /* rw=1, db4-7=weak1, e=rs=0 */
>   ioport1 = 0x6f ;                  /* e=1, db7->busy flag */
>   asm bbc ioport1,3,busyFlagClr ;
>   ioport1 = 0x2f ;                  /* e=0 */
>   ioport1 = 0x6f ;                  /* e=1, db7->AC3 */
>   asm br checkBusyFlag ;
> busyFlagClr:
>   ioport1 = 0x2f ;                  /* e=0 */
>   ioport1 = 0x6f ;                  /* e=1, db7->AC3 */
>   ioport1 = 0x2f ;                  /* e=0 */
>   /* write instr */
>   asm ldb LMDATAHI,LMDATA ;
>   asm shrb LMDATAHI,#4 ;            /* LMDATAHI.0-3=hi data */
>   asm andb LMDATA,#0x0f ;           /* Clr LMDATA.4-7 */
>   asm ldb ioport1,#0x1f ;           /* put rs=1,r/w=0,db4-7=weak1,e=0 */
>   asm addb ioport1,LMDATAHI,#0x50 ; /* e=1,db4-7=hi data */
>   asm addb ioport1,LMDATAHI,#0x10 ; /* e=0 */
>   asm addb ioport1,LMDATA,#0x50 ;   /* put lo data,e=1 */
>   asm addb ioport1,LMDATA,#0x10 ;   /* e=0 */
> lmfwdEnd: ;
> }

-- 
Regards,

Kat.

According to the display datasheet it's apparently a "KS0066U or 
Equivalent", and according to Google, the KS0066U is compatible with the 
HD44780 apart from some timing differences in the initialisation 
sequence, where it seems I'm well within spec for both devices. Having 
said which, the 4-bit init sequence in the KS0066U datasheet doesn't 
appear identical to the HD44780 init that I'm using. If nothing else 
turns up I may try tweaking the init to see if that makes any 
difference, though if the init was wrong I'd have thought it would fail 
there, rather than working normally for a while.

Mark



Zack Widup wrote:

> Hi Mark,
>
> If your program has been working with other HD44780 display drivers, I'd 
> assume some problem with the displays. I haven't seen that they changed 
> anything within that chip.
>
> Or does HD44780 compatible mean it actually uses an HD44780? Or something 
> else?
>
> Zack
>
> On Wed, 22 Aug 2007, Mark Nowell wrote:
>
>   
>> We've recently switched to yet another cheaper, brighter, 16x2, HD44780
>> compatible LCD (Ampire AC162DY1LY). A small number of these latest
>> displays lock-up after correctly initialising and executing a (variable)
>> number of display commands. By "lock-up" I mean that the busy-flag stays
>> set for at least 150ms, after which time the watchdog resets the micro,
>> which then attempts to re-initialise the display, and fails, presumably
>> because it's still busy. Display shows the last written text overwritten
>> by blocks on the top line, bottom line blank. The display controller
>> appears to still be alive because the successive E-cycles show different
>> data-bit patterns for the alternate BF and AC3 cycles (4-bit mode).
>>
>>     
>
>
>  
> Yahoo! Groups Links
>
>
>
>

Kathy Quinlan wrote:
> I have had problems with Ampire displays and static, I found that by 
> grounding the LCD Bezzle I could stop this problem.
>
>
>   
Have had a quick go at this but no change - did you get the same 
symptoms or did the static problem perhaps stop it working completely?

Mark

Mark Nowell wrote:
> Kathy Quinlan wrote:
>> I have had problems with Ampire displays and static, I found that by 
>> grounding the LCD Bezzle I could stop this problem.
>>
>>
>>   
> Have had a quick go at this but no change - did you get the same 
> symptoms or did the static problem perhaps stop it working completely?
> 
> Mark
I had a symptom where the display would lock up with (on a 2x16) bottom 
row blank top row black squares.

I was using 8 bit mode and used the init sequence from the relevent 
Ampire datasheet :)

-- 
Regards,

Kat.

Mark Nowell wrote:
> Kathy Quinlan wrote:
>> I have had problems with Ampire displays and static, I found that by 
>> grounding the LCD Bezzle I could stop this problem.
>>
>>
>>   
> Have had a quick go at this but no change - did you get the same 
> symptoms or did the static problem perhaps stop it working completely?
> 
> Mark

Thinking about it, it could have been a complete lockup as I do not 
monitor the busy flag, I use brute force (long delays)


-- 
Regards,

Kat.

On Thu, 23 Aug 2007, Kathy Quinlan wrote:

> Mark Nowell wrote:
>> Kathy Quinlan wrote:
>>> I have had problems with Ampire displays and static, I found that by
>>> grounding the LCD Bezzle I could stop this problem.
>>>
>>>
>>>
>> Have had a quick go at this but no change - did you get the same
>> symptoms or did the static problem perhaps stop it working completely?
>>
>> Mark
>
> Thinking about it, it could have been a complete lockup as I do not
> monitor the busy flag, I use brute force (long delays)
>

I've done it both ways.  Both have seemed to work fine provided you have 
long enough delays programmed in before the next command.

I think all the devices I've used had the actual HD44780 in them. I've 
never had one of them lock up.

Zack

Mark,
Being HD44780 compatible only means that they cloned the command set developed by Hitachi some 20 years ago.  In my collection of LCDs (and I have a lot of them), I've only ever seen 1 unit that had real hitachi HD44780 chips  (it's really old and required the 8 bit interface!).  The original LCD modules required several driver and controller chips to run the display.  That's way we now have displays, like the 16x4, where the pcb is twice as big as the glass.  Everything has changed except the archaic command set and the oversized footprint.

I've run into this lockup problem once several years ago while trying to control a 1 HP motor.  Every so often the noise from the motor would lock up the LCD module.  The problem was related to the ribbon cable running to the display.  (That's why in all our prototype development kits we keep the lcd connection as short as possible.)  Another option is to control the power to the LCD module so you and reset it if it locks up.

There is a huge difference in the quality of LCD modules and I don't think the problem is with your design.  I wouldn't try to patch it if it's worked for 15 years; tell your purchasing agent to go back to the old supplier; he didn't save you any money.

Regards,

Tim Gilbert
JEM Innovation Inc.
303-926-9053 (office)
303-437-4342 (cell)
720-890-8582 (fax)
www.jeminnovation.com
www.pdksolutions.com

  ----- Original Message ----- 
  From: Mark Nowell 
  To: AVR-Chat@yahoogroups.com 
  Sent: Wednesday, August 22, 2007 6:59 AM
  Subject: [AVR-Chat] OT: HD44780 LCD lock-up - busy flag stays set


  Apologies in advance for the thoroughly non-AVR question but I'm really 
  tearing my hair out with an LCD problem and I'm sure there are some 
  really clever/experienced LCD'ers here (grovel, scrape) ...

  We've recently switched to yet another cheaper, brighter, 16x2, HD44780 
  compatible LCD (Ampire AC162DY1LY). A small number of these latest 
  displays lock-up after correctly initialising and executing a (variable) 
  number of display commands. By "lock-up" I mean that the busy-flag stays 
  set for at least 150ms, after which time the watchdog resets the micro, 
  which then attempts to re-initialise the display, and fails, presumably 
  because it's still busy. Display shows the last written text overwritten 
  by blocks on the top line, bottom line blank. The display controller 
  appears to still be alive because the successive E-cycles show different 
  data-bit patterns for the alternate BF and AC3 cycles (4-bit mode).

  The LCD driver code has been untouched over 15 years, several thousand 
  displays and half-a-dozen different display types. I've double-checked 
  the timings and they're not even close to marginal. Code below [ok, it's 
  an 80C196 but the comments are in english - 12MHz - port writes take 
  833ns, branches 833/1500ns - I'll claim it's a deliberate reminder of 
  how what a marvel AVR RISC is].

  Has anyone experienced anything like this? Should I suspect faulty 
  displays? Or my code?

  TIA,
  Mark

  void LMFWriteData( void ) {
  /* on entry LMDATA contains DB0-7 */
  /* check busy status */
  asm bbc lmNoDisplay,0,checkBusyFlag ;
  asm br lmfwdEnd ;
  checkBusyFlag:
  ioport1 = 0x2f ; /* rw=1, db4-7=weak1, e=rs=0 */
  ioport1 = 0x6f ; /* e=1, db7->busy flag */
  asm bbc ioport1,3,busyFlagClr ;
  ioport1 = 0x2f ; /* e=0 */
  ioport1 = 0x6f ; /* e=1, db7->AC3 */
  asm br checkBusyFlag ;
  busyFlagClr:
  ioport1 = 0x2f ; /* e=0 */
  ioport1 = 0x6f ; /* e=1, db7->AC3 */
  ioport1 = 0x2f ; /* e=0 */
  /* write instr */
  asm ldb LMDATAHI,LMDATA ;
  asm shrb LMDATAHI,#4 ; /* LMDATAHI.0-3=hi data */
  asm andb LMDATA,#0x0f ; /* Clr LMDATA.4-7 */
  asm ldb ioport1,#0x1f ; /* put rs=1,r/w=0,db4-7=weak1,e=0 */
  asm addb ioport1,LMDATAHI,#0x50 ; /* e=1,db4-7=hi data */
  asm addb ioport1,LMDATAHI,#0x10 ; /* e=0 */
  asm addb ioport1,LMDATA,#0x50 ; /* put lo data,e=1 */
  asm addb ioport1,LMDATA,#0x10 ; /* e=0 */
  lmfwdEnd: ;
  }



   

[Non-text portions of this message have been removed]

At 02:01 AM 23/08/2007, you wrote:

>Kathy Quinlan wrote:
> > I have had problems with Ampire displays and static, I found that by
> > grounding the LCD Bezzle I could stop this problem.
>
> >
>Have had a quick go at this but no change - did you get the same
>symptoms or did the static problem perhaps stop it working completely?

I have temperature related failures of LCDs. On a hot day and after
running for a while the LCD stops working correctly, the same code
works well with other brands of LCDs, don't know what chip it uses,
just 2 blobs.

I have heard of people putting small caps (15pf or so) in the E line,
don't know if this will help with your problem or mine.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

I have a few 4X40 LCD's that display rubbish without adding a 220nf cap to gnd on the lcd bios pin.
  Owen.

John Samperi <samperi@ampertronics.com.au> wrote:
          At 02:01 AM 23/08/2007, you wrote:

>Kathy Quinlan wrote:
> > I have had problems with Ampire displays and static, I found that by
> > grounding the LCD Bezzle I could stop this problem.
>
> >
>Have had a quick go at this but no change - did you get the same
>symptoms or did the static problem perhaps stop it working completely?

I have temperature related failures of LCDs. On a hot day and after
running for a while the LCD stops working correctly, the same code
works well with other brands of LCDs, don't know what chip it uses,
just 2 blobs.

I have heard of people putting small caps (15pf or so) in the E line,
don't know if this will help with your problem or mine.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495 Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************



         

       
---------------------------------
Get the World's number 1 free email service. Find out more.

[Non-text portions of this message have been removed]

Owen A wrote:
> I have a few 4X40 LCD's that display rubbish without adding a 220nf cap to gnd on the lcd bios pin.
>   Owen.
> 
> John Samperi <samperi@ampertronics.com.au> wrote:
>           At 02:01 AM 23/08/2007, you wrote:
> 
>> Kathy Quinlan wrote:
>>> I have had problems with Ampire displays and static, I found that by
>>> grounding the LCD Bezzle I could stop this problem.
>> Have had a quick go at this but no change - did you get the same
>> symptoms or did the static problem perhaps stop it working completely?
> 
> I have temperature related failures of LCDs. On a hot day and after
> running for a while the LCD stops working correctly, the same code
> works well with other brands of LCDs, don't know what chip it uses,
> just 2 blobs.
> 
> I have heard of people putting small caps (15pf or so) in the E line,
> don't know if this will help with your problem or mine.

The 44780 internal clock may be slowing with temperature, and silicon
gets a bit slower with heat too iirc. I'd put more time delays between
every operation to narrow down where the timing problem is.

At 01:09 PM 23/08/2007, you wrote:
>The 44780 internal clock may be slowing with temperature, and silicon
>gets a bit slower with heat too iirc. I'd put more time delays between
>every operation to narrow down where the timing problem is.

May try and run it at 4MHz instead of 8, if it works then it may be
a matter of just adding a few nops...will need to wait for summer
and a hot day.... :-) LOL


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

John Samperi wrote:
> At 01:09 PM 23/08/2007, you wrote:
>> The 44780 internal clock may be slowing with temperature, and silicon
>> gets a bit slower with heat too iirc. I'd put more time delays between
>> every operation to narrow down where the timing problem is.
> 
> May try and run it at 4MHz instead of 8, if it works then it may be
> a matter of just adding a few nops...will need to wait for summer
> and a hot day.... :-) LOL

A hot-air gun and freeze spray can be very telling. I've found
temperature-sensitive crystal problems with that.

At 01:28 PM 23/08/2007, you wrote:
>A hot-air gun and freeze spray can be very telling.

That sounds like torture, ve hafe vays to make you toc! LOL :-)

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Hello guys
   
  I am trying to make build my own AVR ISP programmer. I have seen the schematic from sixca.com but the component IC they are using is AT90S2313 which is now obsolete. I also read that AT90S2313 is compatible with ATtinay2313. I can only download the compiled hex file. Can i load this to ATtiny2313? Any help?  Anyone has code for AVR ISP programmer? 
   
  link below is the schematic for ISP programmer using AT90S2313
   
  http://www.sixca.com/eng/articles/avr_isp/
   
  thanks
   
  regards,
  mago
   

       
---------------------------------
Got a little couch potato? 
Check out fun summer activities for kids.

[Non-text portions of this message have been removed]

At 07:01 PM 23/08/2007, you wrote:
>Can i load this to ATtiny2313? Any help?  Anyone has code for AVR 
>ISP programmer?

The code is right here in the files area, look for AVR910JS_2313_v3_3.asm

It SHOULD work but you have lots of fuses to set in the Tiny2313.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

----- Original Message ----- 

From: "mago Umandam" <magzky02@yahoo.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Thursday, August 23, 2007 10:01 AM
Subject: [AVR-Chat] AT90S2313 hex code to ATtiny2313


> Hello guys
>
>  I am trying to make build my own AVR ISP programmer. I have seen the 
> schematic from sixca.com but the component IC they are using is AT90S2313 
> which is now obsolete. I also read that AT90S2313 is compatible with 
> ATtinay2313. I can only download the compiled hex file. Can i load this to 
> ATtiny2313? Any help?  Anyone has code for AVR ISP programmer?

It should work 'as is'.

Leon

Tim et al,

Thanks all for lots of useful advice. I've tried various recommendations 
but haven't fixed the problem. I added a loop counter to the busy flag 
check to limit the busy checking to max 1.6ms, then just went ahead and 
sent the instruction regardless of the busy flag. This didn't work.

I'm coming to the conclusion described by Tim below - it's probably an 
LCD quality problem and nothing I do with code, caps etc is going to fix 
it. I don't have the option to control power to the LCD but it's an 
option to consider for future designs.

Thanks again,
Mark


Tim Gilbert wrote:

> Mark,
> Being HD44780 compatible only means that they cloned the command set developed by Hitachi some 20 years ago.  In my collection of LCDs (and I have a lot of them), I've only ever seen 1 unit that had real hitachi HD44780 chips  (it's really old and required the 8 bit interface!).  The original LCD modules required several driver and controller chips to run the display.  That's way we now have displays, like the 16x4, where the pcb is twice as big as the glass.  Everything has changed except the archaic command set and the oversized footprint.
>
> I've run into this lockup problem once several years ago while trying to control a 1 HP motor.  Every so often the noise from the motor would lock up the LCD module.  The problem was related to the ribbon cable running to the display.  (That's why in all our prototype development kits we keep the lcd connection as short as possible.)  Another option is to control the power to the LCD module so you and reset it if it locks up.
>
> There is a huge difference in the quality of LCD modules and I don't think the problem is with your design.  I wouldn't try to patch it if it's worked for 15 years; tell your purchasing agent to go back to the old supplier; he didn't save you any money.
>
> Regards,
>
> Tim Gilbert
> JEM Innovation Inc.
> 303-926-9053 (office)
> 303-437-4342 (cell)
> 720-890-8582 (fax)
> www.jeminnovation.com
> www.pdksolutions.com
>
>
>   ----- Original Message ----- 
>   From: Mark Nowell 
>   To: AVR-Chat@yahoogroups.com 
>   Sent: Wednesday, August 22, 2007 6:59 AM
>   Subject: [AVR-Chat] OT: HD44780 LCD lock-up - busy flag stays set
>
>
>   Apologies in advance for the thoroughly non-AVR question but I'm really 
>   tearing my hair out with an LCD problem and I'm sure there are some 
>   really clever/experienced LCD'ers here (grovel, scrape) ...
>
>   We've recently switched to yet another cheaper, brighter, 16x2, HD44780 
>   compatible LCD (Ampire AC162DY1LY). A small number of these latest 
>   displays lock-up after correctly initialising and executing a (variable) 
>   number of display commands. By "lock-up" I mean that the busy-flag stays 
>   set for at least 150ms, after which time the watchdog resets the micro, 
>   which then attempts to re-initialise the display, and fails, presumably 
>   because it's still busy. Display shows the last written text overwritten 
>   by blocks on the top line, bottom line blank. The display controller 
>   appears to still be alive because the successive E-cycles show different 
>   data-bit patterns for the alternate BF and AC3 cycles (4-bit mode).
>
>   The LCD driver code has been untouched over 15 years, several thousand 
>   displays and half-a-dozen different display types. I've double-checked 
>   the timings and they're not even close to marginal. Code below [ok, it's 
>   an 80C196 but the comments are in english - 12MHz - port writes take 
>   833ns, branches 833/1500ns - I'll claim it's a deliberate reminder of 
>   how what a marvel AVR RISC is].
>
>   Has anyone experienced anything like this? Should I suspect faulty 
>   displays? Or my code?
>
>   TIA,
>   Mark
>
>   void LMFWriteData( void ) {
>   /* on entry LMDATA contains DB0-7 */
>   /* check busy status */
>   asm bbc lmNoDisplay,0,checkBusyFlag ;
>   asm br lmfwdEnd ;
>   checkBusyFlag:
>   ioport1 = 0x2f ; /* rw=1, db4-7=weak1, e=rs=0 */
>   ioport1 = 0x6f ; /* e=1, db7->busy flag */
>   asm bbc ioport1,3,busyFlagClr ;
>   ioport1 = 0x2f ; /* e=0 */
>   ioport1 = 0x6f ; /* e=1, db7->AC3 */
>   asm br checkBusyFlag ;
>   busyFlagClr:
>   ioport1 = 0x2f ; /* e=0 */
>   ioport1 = 0x6f ; /* e=1, db7->AC3 */
>   ioport1 = 0x2f ; /* e=0 */
>   /* write instr */
>   asm ldb LMDATAHI,LMDATA ;
>   asm shrb LMDATAHI,#4 ; /* LMDATAHI.0-3=hi data */
>   asm andb LMDATA,#0x0f ; /* Clr LMDATA.4-7 */
>   asm ldb ioport1,#0x1f ; /* put rs=1,r/w=0,db4-7=weak1,e=0 */
>   asm addb ioport1,LMDATAHI,#0x50 ; /* e=1,db4-7=hi data */
>   asm addb ioport1,LMDATAHI,#0x10 ; /* e=0 */
>   asm addb ioport1,LMDATA,#0x50 ; /* put lo data,e=1 */
>   asm addb ioport1,LMDATA,#0x10 ; /* e=0 */
>   lmfwdEnd: ;
>   }
>
>
>
>    
>
> [Non-text portions of this message have been removed]
>
>
>
>  
> Yahoo! Groups Links
>
>
>
>

thanks leon and John... 
   
  cheers
  mago
   
  

Leon <leon355@btinternet.com> wrote:

          ----- Original Message ----- 
From: "mago Umandam" <magzky02@yahoo.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Thursday, August 23, 2007 10:01 AM
Subject: [AVR-Chat] AT90S2313 hex code to ATtiny2313

> Hello guys
>
> I am trying to make build my own AVR ISP programmer. I have seen the 
> schematic from sixca.com but the component IC they are using is AT90S2313 
> which is now obsolete. I also read that AT90S2313 is compatible with 
> ATtinay2313. I can only download the compiled hex file. Can i load this to 
> ATtiny2313? Any help? Anyone has code for AVR ISP programmer?

It should work 'as is'.

Leon



         

       
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 

[Non-text portions of this message have been removed]