[avr-gcc-list] LX-800 Printer driver
Hi,
Does anyone ever make a LX-800 printer driver for AVR ?
I make a code but it didn't work at all.
Here my code :
void InitPrinter(void)
{
//
// Set Data Printer Direction as output
DDRB = 0xFF;
PORTB = 0;
// Set Input BUSY signal
cbi(DDRD,BUSY);
sbi(PORTD,BUSY);
// Set Output INIT signal
sbi(DDRD,INIT);
sbi(PORTD,INIT);
// Set Output Strobe signal
sbi(DDRD,STROBE);
sbi(PORTD,STROBE);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
// Send INIT Signal
cbi(PORTD,INIT);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
sbi(PORTD,INIT);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
}
void SendCharToPrinter(unsigned char data)
{
//
unsigned int timeout_print;
// Check busy
timeout_print = 0;
while ((PIND _BV(BUSY)) == 0){
timeout_print++;
if (timeout_print == MAX_BUSY_LOOP){
return;
}
}
// Send Data
PORTB = data;
// Send Strobe Signal
cbi(PORTD,STROBE);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
sbi(PORTD,STROBE);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
asm(nop);
}
void SendStringToPrinter(unsigned char *datastring)
{
//
InitPrinter();
while (*datastring)
{
SendCharToPrinter(datastring++);
}
}
int main(void)
{
SendStringToPrinter(System Ready !\r\n);
for (;;){
}
}
Anyone can help me ?
Thanks
Andi
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
Hi. I wish to add: .. 3. builtin similarly to IAR '__delay_cycles'; .. This unfinished patch add '__builtin_avr_delay_cycles(long delay)' builtin to the avr backend. The 'delay' parameter should be constant. If 'delay' is 1 or 2 then one or two 'nop' instructions is generated. If 'delay' is from 3 to 756 then code: ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. For 'delay' from 757 to 196605 loop is: 1:sbiw Rx,1 brne 1b For 'delay' from 196606 to 83886075 loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 brne 1b And for 'delay' from 83886076 to 0x loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 sbci %D0,0 brne 1b Adding '__builtin_avr_delay_cycles' builtin will allow to remove restrictions on max possible values of parameter for '_delay_us' macro and reduce code size for long delay of '_delay_ms' macro. Also it will simplify porting code from IAR C, if define '__delay_cycles' as '__builtin_avr_delay_cycles'. As you consider, this builtin will be useful? Anatoly.___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
I wish to add:
..
3. builtin similarly to IAR '__delay_cycles';
..
This unfinished patch add '__builtin_avr_delay_cycles(long delay)' builtin
to the avr backend. The 'delay' parameter should be constant.
The patch attached.
Anatoly.Index: gcc/config/avr/avr.md
===
--- gcc/config/avr/avr.md (revision 134368)
+++ gcc/config/avr/avr.md (working copy)
@@ -52,12 +52,25 @@
(UNSPEC_STRLEN 0)
(UNSPEC_INDEX_JMP 1)
- (UNSPEC_SEI 2)
- (UNSPEC_CLI 3)
+ (UNSPEC_SWAP2)
+ (UNSPEC_FMUL3)
+ (UNSPEC_FMULU 4)
+ (UNSPEC_FMULSU 5)
(UNSPECV_PROLOGUE_SAVES 0)
- (UNSPECV_EPILOGUE_RESTORES 1)])
+ (UNSPECV_EPILOGUE_RESTORES 1)
+ (UNSPECV_SEI2)
+ (UNSPECV_CLI3)
+ (UNSPECV_NOP4)
+ (UNSPECV_SLEEP 5)
+ (UNSPECV_WDR6)
+ (UNSPECV_DELAY_CYCLES 100)
+ (UNSPECV_DELAY_CYCLES_1 101)
+ (UNSPECV_DELAY_CYCLES_2 102)
+ (UNSPECV_DELAY_CYCLES_3 103)
+ (UNSPECV_DELAY_CYCLES_4 104)])
+
(include predicates.md)
(include constraints.md)
@@ -2751,7 +2764,7 @@
;; Enable Interrupts
(define_insn enable_interrupt
- [(unspec [(const_int 0)] UNSPEC_SEI)]
+ [(unspec_volatile [(const_int 0)] UNSPECV_SEI)]
sei
[(set_attr length 1)
@@ -2760,7 +2773,7 @@
;; Disable Interrupts
(define_insn disable_interrupt
- [(unspec [(const_int 0)] UNSPEC_CLI)]
+ [(unspec_volatile [(const_int 0)] UNSPECV_CLI)]
cli
[(set_attr length 1)
@@ -2860,3 +2873,158 @@
expand_epilogue ();
DONE;
})
+
+;;delay_cycles_delay_cycles_delay_cycles_delay_cycles_delay_cycles_delay
+;; delay_cycles
+
+(define_expand delay_cycles
+ [(set (match_operand:SI 0 register_operand =r)
+ (unspec_volatile:SI [(match_operand:SI 1 immediate_operand i)]
+UNSPECV_DELAY_CYCLES))]
+
+
+ rtx loop_reg;
+
+ if (0 == (INTVAL (operands[1])))
+{
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 1, 2))
+{
+ emit_insn (gen_nop ());
+ if (2 == (INTVAL (operands[1])))
+ emit_insn (gen_nop ());
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 3, 756))
+{
+
+ loop_reg =
+ copy_to_mode_reg (QImode,
+gen_int_mode (INTVAL (operands[1]) / 3, QImode));
+ emit_insn (gen_delay_cycles_1 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 757, 196605))
+{
+ loop_reg =
+copy_to_mode_reg (HImode,
+ gen_int_mode (INTVAL (operands[1]) / 3, HImode));
+ emit_insn (gen_delay_cycles_2 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 196606, 83886075))
+{
+ loop_reg =
+ copy_to_mode_reg (SImode,
+ gen_int_mode (INTVAL (operands[1]) / 5, SImode));
+ emit_insn (gen_delay_cycles_3 (loop_reg));
+
+ DONE;
+}
+ else if (IN_RANGE((INTVAL (operands[1])), 83886076, 0x))
+{
+ loop_reg =
+ copy_to_mode_reg (SImode,
+ gen_int_mode (INTVAL (operands[1]) / 6, SImode));
+ emit_insn (gen_delay_cycles_4 (loop_reg));
+
+ DONE;
+}
+ )
+
+(define_insn delay_cycles_1
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES)
+ (match_operand:QI 0 register_operand r)
+ (clobber (match_dup 0))]
+
+ 1:dec %0\;brne 1b
+ [(set_attr length 2)
+ (set_attr cc clobber)])
+
+(define_insn delay_cycles_2
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES_2)
+ (match_operand:HI 0 register_operand w)
+ (clobber (match_dup 0))]
+
+ 1:sbiw %0,1\;brne 1b
+ [(set_attr length 2)
+ (set_attr cc clobber)])
+
+(define_insn delay_cycles_3
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES_3)
+ (match_operand:SI 0 register_operand d)
+ (clobber (match_dup 0))]
+
+ 1:subi %0,1\;sbci %B0,0\;sbci %C0,0\;brne 1b
+ [(set_attr length 4)
+ (set_attr cc clobber)])
+
+(define_insn delay_cycles_4
+ [(unspec_volatile [(const_int 0)] UNSPECV_DELAY_CYCLES_4)
+ (match_operand:SI 0 register_operand d)
+ (clobber (match_dup 0))]
+
+ 1:subi %0,1\;sbci %B0,0\;sbci %C0,0\;sbci %D0,0\;brne 1b
+ [(set_attr length 5)
+ (set_attr cc clobber)])
+
+;; CPU instructions
+
+;; NOP
+;(define_insn nop
+; [(unspec_volatile [(const_int 0)] UNSPECV_NOP)]
+;
+; nop
+; [(set_attr length 1)
+; (set_attr cc none)
+; ])
+
+;; SEI, Enable Interrupts
+;(define_insn enable_interrupt
+; [(unspec_volatile [(const_int 0)] UNSPECV_SEI)]
+;
+; sei
+; [(set_attr length 1)
+; (set_attr cc none)
+; ])
+
+;; CLI, Disable Interrupts
+;(define_insn disable_interrupt
+; [(unspec_volatile [(const_int 0)] UNSPECV_CLI)]
+;
+; cli
+; [(set_attr length 1)
+; (set_attr cc none)
+; ])
+
Re: [avr-gcc-list] Add builtins in avr target.
Anatoly Sokolov schreef: Hi. I wish to add: .. 3. builtin similarly to IAR '__delay_cycles'; .. This unfinished patch add '__builtin_avr_delay_cycles(long delay)' builtin to the avr backend. The 'delay' parameter should be constant. If 'delay' is 1 or 2 then one or two 'nop' instructions is generated. For a 2 cycles delays an rjmp can be used. Saves an instruction! If 'delay' is from 3 to 756 then code: ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. For 'delay' from 757 to 196605 loop is: 1:sbiw Rx,1 brne 1b For 'delay' from 196606 to 83886075 loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 brne 1b And for 'delay' from 83886076 to 0x loop is: 1:subi %0,1 sbci %B0,0 sbci %C0,0 sbci %D0,0 brne 1b That is a high registers usage. 4 register used just for burning cycles? On the other hand burning cycles this way will probably never be used in real code. Adding '__builtin_avr_delay_cycles' builtin will allow to remove restrictions on max possible values of parameter for '_delay_us' macro and reduce code size for long delay of '_delay_ms' macro. Also it will simplify porting code from IAR C, if define '__delay_cycles' as '__builtin_avr_delay_cycles'. As you consider, this builtin will be useful? Yes it is useful, especially the really short ones. Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192
Andy H schreef: I think I have found a simple fix. I changed gcc so that offsets added to assembler symbols are doubled. So in c when we use foo+2 this gets send to assembler/linker as gs(foo+4). This has the effect that offsets or arithmetic are consistently in words - on a word pointer. (which makes more sense) Now it does not matter if optimisation creates p=foo+2 OR p=foo, p=p+2 as the result will be the same. I attach test program I used to check several variant and it worked. Apart from normal warning messages about linker stubs. There also lst and lss files you can look at what gets send to assembler and code produced. It looks ok to me (just looking at the lss, not rebuilding gcc) but the code is not optimal. It is moving to r18 doing the operation and then moving it back to r24. Is this because of your patch? Or something else? HTH, Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] optimization flags causes problems??
Hello,
I have started using AT90CAN128 with WinAVR-20080402.
I am having problem with with optimizatin flags.
1- When I use the following code along with -O1, -O2,-O3, -O4, -Os
and whenI debug it, I do not see any change in PORTA. But when I built
it with -O0, I see the changes in PORTA as I expected.
DDRA=0xFF;
for(i=0;i8;i++)
{
PORTA=0x01;
PORTA=0x02;
PORTA=0x04;
PORTA=0x08;
PORTA=0x10;
PORTA=0x20;
PORTA=0x40;
PORTA=0x80;
}
2-I am using EEPROM_Write/Read functions in my project. When I compile
the project with -O0 option, and start dtata transfer to EEPROM memory,
I do not see any transfer to EEPROM memory. With other optimization
options, I can transfer it.
See the functions below
void EEPROM_write (unsigned int uiAddress, unsigned char *ucWrData,
unsigned int uiBufSize)
{
volatile unsigned int i=0;
asm(cli);
for(i=0;iuiBufSize;i++)
{
/* Wait for completion of previous write */
while(EECR (1EEWE));
while(SPMCSR (1SPMEN));
/* Set up address and data registers */
EEAR = uiAddress++;
EEDR = *(ucWrData++);
/* Write logical one to EEMWE */
EECR |= (1EEMWE);
/* Start eeprom write by setting EEWE */
EECR |= (1EEWE);
}
EECR=0x00;
asm(sei);
}
void EEPROM_read(unsigned int uiAddress, unsigned char
*ucRdData,unsigned char ucRdDataSize)
{
volatile unsigned int i=0;
asm(cli);
for(i=0;iucRdDataSize;i++)
{
/* Wait for completion of previous write */
while(EECR (1EEWE));
while(SPMCSR (1SPMEN));
/* Set up address register */
EEAR = uiAddress++;
/* Start eeprom read by writing EERE */
EECR |= (1EERE);
/* Return data from data register */
*(ucRdData++)=EEDR;
}
EECR=0x00;
asm(sei);
}
COULD YOU PLEASE TELL ME IF ANYONE IS HAVING SIMILAR PROBLEMS?
IF SO, IS THERE ANY SOLUTION FOR THIS.
Best Regards
R. Kerek
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] optimization flags causes problems??
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Ramazan Kerek Sent: Thursday, April 17, 2008 1:16 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] optimization flags causes problems?? Hello, I have started using AT90CAN128 with WinAVR-20080402. There are known code generation problems with 20080402, and I had to pull the release. Please use 20080411. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] optimization flags causes problems??
Ramazan Kerek schreef: Hello, I have started using AT90CAN128 with WinAVR-20080402. I am having problem with with optimizatin flags. Do not use 20080402, use 20080411. HTH Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] optimization flags causes problems??
Thanks alot. I will try it. Best Regards Ramazan Kerek -Original Message- From: Wouter van Gulik [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 11:31 AM To: Ramazan Kerek Cc: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] optimization flags causes problems?? Ramazan Kerek schreef: Hello, I have started using AT90CAN128 with WinAVR-20080402. I am having problem with with optimizatin flags. Do not use 20080402, use 20080411. HTH Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] optimization flags causes problems??
I have installed 20080411 and seen the same problems as I did in 20080402. Is there anything else I should try? Best Regards R. Kerek -Original Message- From: Weddington, Eric [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 11:31 AM To: Ramazan Kerek; avr-gcc-list@nongnu.org Subject: RE: [avr-gcc-list] optimization flags causes problems?? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Ramazan Kerek Sent: Thursday, April 17, 2008 1:16 AM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] optimization flags causes problems?? Hello, I have started using AT90CAN128 with WinAVR-20080402. There are known code generation problems with 20080402, and I had to pull the release. Please use 20080411. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] optimization flags causes problems??
Ramazan Kerek wrote: I have installed 20080411 and seen the same problems as I did in 20080402. Is there anything else I should try? What compiler flags did you use? If you compile the code you gave, use -O0 and -Os, what is the generated assembly code? Incidentally, why are you writing your own eeprom functions rather than using the ones from the library? mvh., David ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] optimization flags causes problems??
Please see my comment on your questions below. Best Regards R. Kerek What compiler flags did you use? - -Wall, -gdwarf-2, -std=gnu99, -O0, -funsigned-char, -funsigned-bitfields, fpack-struct, -fshort-enums If you compile the code you gave, use -O0 and -Os, what is the generated assembly code? -I do not know how and where I can get the generated assembly code. I am new to this environment. Incidentally, why are you writing your own eeprom functions rather than using the ones from the library? -I am trying not be much dependent on the libraries as possible since I will be more flexible changing my own code. mvh., David ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop 4 cycles: rjmp . rjmp . 5 cycles: rjmp . rjmp . nop 6 cycles: rjmp . rjmp . rjmp . All code portions use no more program words than delay loop and not use any register. 7 cycles delay requires four instructions and delay loop is more efficient in code size: If 'delay' is from 3 to 756 then code: 7 to 756 ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. and removed ldi instruction execution time (1 cycle) for 7+ cycles will produce less relative error than for 3..6 cycles delay -- wbr, ReAl ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
2008/4/17, Oleksandr Redchuk [EMAIL PROTECTED]: 7 to 756 ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. and removed ldi instruction execution time (1 cycle) for 7+ cycles will produce less relative error than for 3..6 cycles delay May be ldi rX, ((delay+1)/3) will be better for small delays -- wbr, ReAl ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] optimization flags causes problems??
Ramazan Kerek wrote:
Please see my comment on your questions below.
Best Regards
R. Kerek
What compiler flags did you use?
- -Wall, -gdwarf-2, -std=gnu99, -O0, -funsigned-char,
-funsigned-bitfields, fpack-struct, -fshort-enums
Try compiling with -mmcu=atmega128. Without an appropriate -mmcu flag,
the compiler doesn't know which chip you are targeting, and the
avr/io.h include file will not get the right definitions for the port
registers.
Are you actually including avr/io.h, or are you defining DDRA, PORTA,
etc., manually yourself? If you are, then you've probably defined them
incorrectly (such as forgetting volatile) - you should *always* use
the definitions that come with the compiler/library.
If you compile the code you gave, use -O0 and -Os, what is the generated
assembly code?
-I do not know how and where I can get the generated assembly code. I am
new to this environment.
Add something like flags -fverbose-asm, -Wa,-ahlsd=${basename [EMAIL PROTECTED]
to the flag line in your makefile.
Incidentally, why are you writing your own eeprom functions rather than
using the ones from the library?
-I am trying not be much dependent on the libraries as possible since I
will be more flexible changing my own code.
Sometimes it is useful to be independent of libraries, but other times
it is just a waste of effort. The avr-libc is very good - the code is
compact and efficient. You can expect that for the same function (and
the same sort of implementation), the library code will be at least as
good as anything you write yourself. It will also work across the range
of avr devices, unlike your routines. So unless you are thinking of
using avr-gcc without avr-libc (theoretically possible), or writing code
that must work on different avr compilers, stick to the library
functions for this sort of thing.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] optimization flags causes problems??
Ramazan Kerek [EMAIL PROTECTED] wrote: 2-I am using EEPROM_Write/Read functions in my project. When I compile the project with -O0 option, and start dtata transfer to EEPROM memory, I do not see any transfer to EEPROM memory. As you told the compiler to not optimize, the generated code is just that: not quite optimal. As such, it's too slow to follow the timing requirements for an EEPROM write operation. As others already suggested, if you use the library-provided EEPROM routines, they'll work with any optimization level. (This is because they use hand-tuned inline assembly statements so they are independent of compiler optimizations within the timing-critical region.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
Hi. 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. 7 cycles delay requires four instructions and delay loop is more efficient in code size: If 'delay' is from 3 to 756 then code: 7 to 756 ldi rX, (delay/3) 1:dec rX brne 1b is generated. 'ldi' instruction can be removed by optimizer. and removed ldi instruction execution time (1 cycle) for 7+ cycles will produce less relative error than for 3..6 cycles delay Ok. I shall check it. Anatoly.___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Add builtins in avr target.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Anatoly Sokolov Sent: Thursday, April 17, 2008 3:44 PM To: Oleksandr Redchuk; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Add builtins in avr target. Hi. 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. AFAIK, linker relaxation will do JMP-RJMP transformations only. Going the other way is not a size optimization. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Add builtins in avr target.
On Friday 18 April 2008 12:56, Weddington, Eric wrote: 2008/4/17, Wouter van Gulik [EMAIL PROTECTED]: For a 2 cycles delays an rjmp can be used. Saves an instruction! And so on: 3 cycles: rjmp . nop I shall try to replace 'nop' with 'rjmp .' for two cycle delay. It is necessary to check that the linker relaxation pass will not remove the 'rjmp .' instruction. Now I do not wish to complicate a code and to optimize 3..6 cycles delays. AFAIK, linker relaxation will do JMP-RJMP transformations only. Going the other way is not a size optimization. Alas, not only. Linker relaxation replaces the (R)CALL,RET sequence into (R)JMP,RET. Note, the linker does not differ the C and ASM functions and can spoil the delay routine like: long_delay: rcall . middle_delay: rcall . short_delay: ret or may destroy the program where the 'return to next level' trik is used, like Avr-libc's old (1.4 and early) float library. The Binutils-2.17 makes such replacement unconditionally. The 2.18 has an option to disable it: '--no-call-ret-replacement'. IMHO, such replacement must be disabled by default. Note, GCC for some targets can itself optimize tailing call. This is better, as the second instruction (RET) is deleted. Regards, Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] LX-800 Printer driver
On Thursday 17 April 2008, Andi wrote:
Hi,
Does anyone ever make a LX-800 printer driver for AVR ?
I make a code but it didn't work at all.
Here my code :
snip code
int main(void)
{
SendStringToPrinter(System Ready !\r\n);
for (;;){
}
}
Anyone can help me ?
This probably belongs on AVR-chat rather than avr-gcc-list.
I don't see any problem with your code, though I don't know what interface you
are using to the printer.
The only thing I can suggest is that you may want to issue a form feed (0x0c)
to the printer after your test string, as the printer may be buffering the
data and waiting for the end of the page to start printing.
Blake
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] optimization flags causes problems??
Thank very much for the detailed answer about EEPROM timing and why using the lib is better chose. Best Regards Ramazan Kerek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joerg Wunsch Sent: Thursday, April 17, 2008 11:11 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] optimization flags causes problems?? Ramazan Kerek [EMAIL PROTECTED] wrote: 2-I am using EEPROM_Write/Read functions in my project. When I compile the project with -O0 option, and start dtata transfer to EEPROM memory, I do not see any transfer to EEPROM memory. As you told the compiler to not optimize, the generated code is just that: not quite optimal. As such, it's too slow to follow the timing requirements for an EEPROM write operation. As others already suggested, if you use the library-provided EEPROM routines, they'll work with any optimization level. (This is because they use hand-tuned inline assembly statements so they are independent of compiler optimizations within the timing-critical region.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
