AVR-Chat

It depends on what AVR you are using however this shoul help..

void RS232_init(void)
{
   outp(0x18, UCR);
   //outp((char)UBR, UBRR);
   outp(8, UBRR);       // 12=38400 8=57600 3=115200
   sbi(USR, TXC);       // UART Trnsmt complete (clear TXC flag but logical
1)

   cbi(DDRD, PD0);      // RXD (UART input line)
   sbi(DDRD, PD1);      // TXD (UART ouput line)

}

uint8_t cin(void)
{
   loop_until_bit_is_set(USR,RXC);
   return(inp(UDR ));
}

void cout(uint8_t a)
{
   outp(a, UDR);
   loop_until_bit_is_set(USR,TXC);
   sbi(USR, TXC);       // UART Trnsmt complete (clear TXC flag but logical
1)
}


then  in main ..

    cout((cin());

Hope this helps..

Javier

For transmit, does checking TXC instead of UDRE limit the max 
transmit speed?  And what is the lag between writing to UDR and it 
getting put into the transmit shift register?

Mike


--- In AVR-Chat@yahoogroups.com, JChavez@s... wrote:
> 
> 
> 
> 
> 
> 
> It depends on what AVR you are using however this shoul help..
> 
> void RS232_init(void)
> {
>    outp(0x18, UCR);
>    //outp((char)UBR, UBRR);
>    outp(8, UBRR);       // 12=38400 8=57600 3=115200
>    sbi(USR, TXC);       // UART Trnsmt complete (clear TXC flag but 
logical
> 1)
> 
>    cbi(DDRD, PD0);      // RXD (UART input line)
>    sbi(DDRD, PD1);      // TXD (UART ouput line)
> 
> }
> 
> uint8_t cin(void)
> {
>    loop_until_bit_is_set(USR,RXC);
>    return(inp(UDR ));
> }
> 
> void cout(uint8_t a)
> {
>    outp(a, UDR);
>    loop_until_bit_is_set(USR,TXC);
>    sbi(USR, TXC);       // UART Trnsmt complete (clear TXC flag but 
logical

> 1)
> }
> 
> 
> then  in main ..
> 
>     cout((cin());
> 
> Hope this helps..
> 
> Javier

At 11:56 AM 10/8/2004, upand_at_them wrote:



>For transmit, does checking TXC instead of UDRE limit the max 
>transmit speed? 

Well, you can't shove chars in faster than they go out..

> And what is the lag between writing to UDR and it 
>getting put into the transmit shift register?

Essentially zero.
I've never measured it, but it's not much.

> Well, you can't shove chars in faster than they go out..

Obviously.

But I noticed the two stage pipeline.  and if you wait until 
something comes out the end of the pipe before you put anything in it 
cuts the speed down.  I just didn't know the lag between data 
register and transmit register.  If it's just a clock cycle or two, 
then you're right, it won't matter.

MK

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:

> At 11:56 AM 10/8/2004, upand_at_them wrote:
> 
> 
> 
> >For transmit, does checking TXC instead of UDRE limit the max 
> >transmit speed? 
> 
> Well, you can't shove chars in faster than they go out..
> 
> > And what is the lag between writing to UDR and it 
> >getting put into the transmit shift register?
> 
> Essentially zero.
> I've never measured it, but it's not much.

Wierd.. I can erase the chip just fine, and it DOES erase, but it won't program!

Here's the output, that shows that it does see the STK-500.

STK500 v 1.51 (C) 2000-2004 Atmel Corp. 

Scanning port.. com4 STK500 detected!
Done.
informational - project has no EEPROM file
Programming and Verifying FLASH...
"C:\Program Files\Atmel\AVR Tools\STK500\Stk500.exe" -z -dAT90S8515 -ccom4  -e -pf -vf -ifE:\Software\Cstuff\LedThing\ledthing.hex

STK500 v 1.51 (C) 2000-2004 Atmel Corp. 

Scanning port.. com4 Port not present or in use by another application

STK500 not detected!Done: there are error(s). Exit code: 1

Cannot program or verify Flash

ISP programming done.


So it isn't succeding, but I don't see why..

Ideas?

is it possible to program the STK500 using just the ICCAVR?

Dave VanHorn <dvanhorn@dvanhorn.org> wrote:
Wierd.. I can erase the chip just fine, and it DOES erase, but it won't program!

Here's the output, that shows that it does see the STK-500.

STK500 v 1.51 (C) 2000-2004 Atmel Corp. 

Scanning port.. com4 STK500 detected!
Done.
informational - project has no EEPROM file
Programming and Verifying FLASH...
"C:\Program Files\Atmel\AVR Tools\STK500\Stk500.exe" -z -dAT90S8515 -ccom4  -e -pf -vf -ifE:\Software\Cstuff\LedThing\ledthing.hex

STK500 v 1.51 (C) 2000-2004 Atmel Corp. 

Scanning port.. com4 Port not present or in use by another application

STK500 not detected!Done: there are error(s). Exit code: 1

Cannot program or verify Flash

ISP programming done.


So it isn't succeding, but I don't see why..

Ideas? 


Yahoo! Groups SponsorADVERTISEMENT


---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  
   To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
  
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 



		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!

remove whatever s connected to the ports and try...........see that nothing else is working with it
Dave VanHorn <dvanhorn@dvanhorn.org> wrote:
Wierd.. I can erase the chip just fine, and it DOES erase, but it won't program!

Here's the output, that shows that it does see the STK-500.

STK500 v 1.51 (C) 2000-2004 Atmel Corp. 

Scanning port.. com4 STK500 detected!
Done.
informational - project has no EEPROM file
Programming and Verifying FLASH...
"C:\Program Files\Atmel\AVR Tools\STK500\Stk500.exe" -z -dAT90S8515 -ccom4  -e -pf -vf -ifE:\Software\Cstuff\LedThing\ledthing.hex

STK500 v 1.51 (C) 2000-2004 Atmel Corp. 

Scanning port.. com4 Port not present or in use by another application

STK500 not detected!Done: there are error(s). Exit code: 1

Cannot program or verify Flash

ISP programming done.


So it isn't succeding, but I don't see why..

Ideas? 


Yahoo! Groups SponsorADVERTISEMENT


---------------------------------
Yahoo! Groups Links

   To visit your group on the web, go to:
http://groups.yahoo.com/group/AVR-Chat/
  
   To unsubscribe from this group, send an email to:
AVR-Chat-unsubscribe@yahoogroups.com
  
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 



		
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!

At 09:31 PM 10/8/2004, jay marante wrote:

>is it possible to program the STK500 using just the ICCAVR?

Yes.

Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

At 09:33 PM 10/8/2004, ramachandra bhat wrote:


>remove whatever s connected to the ports and try...........see that nothing else is working with it

I checked, nothing else is running that would talk to the programmer.

I shut down ICCAVR and restarted, now it's different.. :-P

When I rebuild the project, in very rapid succession, I get a message that the .lst file has changed, and a box that says "cannot program or verify EEPROM".

In the message box, (where the compiler output happens) I get the COM4 port not present message...

When I OK the box about the .lst file changed, then the EEPROM box, it goes off and then programs the chip!

At 09:39 PM 10/8/2004, ramachandra bhat wrote:

>u require AVRstudio link for prog STK500 using ICCAVR..........not possible without it

I have that, it's pointed into the studio4 directory and at STK500.exe

Resolved, sort of..
Works ok on COM1

On Com4, it is definitely flipping the bits to the chip, but something's not right.
I've used the same STK-500 through the same port with Studio, with no problems.
Possibly something in the command line it passes to STK500.exe, at least that's my guess.

So, up and running, but EVERYTHING wants COM1 and COM2!

For the UART and usual baudrates, this lag is
unimportant but I would like having a hardware buffer
for the SPI unit, and have additional flag indicating
byte move buffer to transmit shift register. Motorola
implements such feature in its micros.

Murat Karadeniz
http://www7.brinkster.com/mukas/

--- upand_at_them <upand_at_them@yahoo.com> wrote:

> 
> > Well, you can't shove chars in faster than they go
> out..
> 
> Obviously.
> 
> But I noticed the two stage pipeline.  and if you
> wait until 
> something comes out the end of the pipe before you
> put anything in it 
> cuts the speed down.  I just didn't know the lag
> between data 
> register and transmit register.  If it's just a
> clock cycle or two, 
> then you're right, it won't matter.
> 
> MK
> 
> --- In AVR-Chat@yahoogroups.com, Dave VanHorn
> <dvanhorn@d...> wrote:
> > At 11:56 AM 10/8/2004, upand_at_them wrote:
> > 
> > 
> > 
> > >For transmit, does checking TXC instead of UDRE
> limit the max 
> > >transmit speed? 
> > 
> > Well, you can't shove chars in faster than they go
> out..
> > 
> > > And what is the lag between writing to UDR and
> it 
> > >getting put into the transmit shift register?
> > 
> > Essentially zero.
> > I've never measured it, but it's not much.
> 
> 
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> 
> Resolved, sort of..
> Works ok on COM1
> 
> On Com4, it is definitely flipping the bits to the chip, but 
something's not right.
> I've used the same STK-500 through the same port with Studio, with 
no problems.
> Possibly something in the command line it passes to STK500.exe, at 
least that's my guess.
> 
> So, up and running, but EVERYTHING wants COM1 and COM2!



I get the same error..  Including on COM1 or 2..  

It seems to have originated in an update to AVR studio..  (Maybe 
4.09?)  I find myself using Avr Studio's built-in programmer to burn 
my chips, or giving the project a fake eeprom file.. (Once it fails 
to communicate the EEPROM, if successfull will program the Flash)

I've attached an example..  Here I've added a fake eeprom file so the 
flash will burn.. Without the eep, it fails on burning the flash.


---------------------------------------

"g:\Program Files\Atmel\AVR Tools\STK500\Stk500.exe" -z -dATMega169 -
ccom3

STK500 v 1.51 (C) 2000-2004 Atmel Corp.

Scanning port.. com3 STK500 detected!
Done.
Programming and Verifying EEPROM...
"g:\Program Files\Atmel\AVR
ools\STK500\Stk500.exe" -z -dATMega169 -ccom3  -e -pe -ve -
ieC:\CVSSource\AV
R\CIII\AnalogIO\AnalogIO.eep

STK500 v 1.51 (C) 2000-2004 Atmel Corp.

Scanning port.. com3 Port not present or in use by another application

STK500 not detected!Done: there are error(s). Exit code: 1
Programming and Verifying FLASH...
"g:\Program Files\Atmel\AVR
ools\STK500\Stk500.exe" -z -dATMega169 -ccom3  -pf -vf -ifIgntISO.hex

STK500 v 1.51 (C) 2000-2004 Atmel Corp.

Scanning port.. com3 STK500 detected!
Reading FLASH input file.. OK
Setting device parameters, serial programming mode ..OK
Entering programming mode.. OK
Programming FLASH using block mode..       OK
Reading FLASH using block mode..       OK
FLASH contents is equal to file.. OK
Leaving programming mode.. OK
Done.

ISP programming done.

>
>I get the same error..  Including on COM1 or 2..  
>
>It seems to have originated in an update to AVR studio..  (Maybe 
>4.09?)  I find myself using Avr Studio's built-in programmer to burn 
>my chips, or giving the project a fake eeprom file.. (Once it fails 
>to communicate the EEPROM, if successfull will program the Flash)
>
>I've attached an example..  Here I've added a fake eeprom file so the 
>flash will burn.. Without the eep, it fails on burning the flash.

Well that's pretty wierd.. I'll give it a try.