259 c1_tx_fifo_in_gc++; \ 0000001C .... LDI R30, LOW(c1_tx_fifo_in_gc) \ 0000001E .... LDI R31, HIGH(c1_tx_fifo_in_gc) \ 00000020 .... LDI R19, (c1_tx_fifo_in_gc) >> 16 \ 00000022 BF3B OUT 0x3B, R19 \ 00000024 8100 LD R16, Z \ 00000026 9503 INC R16 \ 00000028 8300 ST Z, R16 260 c1_tx_fifo_in_gc &= (MAX_TX_FIFO - 1); \ 0000002A 9110.... LDS R17, LWRD(c1_tx_fifo_in_gc) \ 0000002E 9310.... STS LWRD(c1_tx_fifo_in_gc), R17 \ 00000032 E000 LDI R16, 0 \ 00000034 BF08 OUT 0x38, R16
please explain the above, I am unable to understand the Assembly routines for the above two "C Statements".
Do you really think that the most likely reason for that lies in the assembly code that the compiler has generated?
Do you not think that it is far more likely to be something wrong with your 'C' code...?
www.catb.org/.../smart-questions.html
Have you successfully got a simple "Hello World" program to work - thus demonstrating that you can correctly configure and use the UART?
http://www.keil.com/support/man/docs/uv4/uv4_ex_hello.htm
http://www.keil.com/support/man/docs/gsac/
What Debugging have you done?
What did you discover?
Note that (this is C code, not assembler) having an 8-bit index variable for spanning a 2^8 element large FIFO isn't so fun. No fun at all.
You have an array that can store 0 to 256 elements - which is 257 alternatives. You have an index pointer that can store 0 to 255 values - which is 256 alternatives.
Dropping down to decoding the assembler instructions isn't the first step to do when something doesn't work. It takes understanding to catch a bug, and many times that understanding works better on the C code where a compiler haven't added lots of noise while trying to remap your ideas into efficient sequences of instructions.
Dear Neil and Per , Thanks for your suggestions..