Re: [avr-gcc-list] Howto put constants on fixed address
"Stu Bell" <[EMAIL PROTECTED]> wrote: > My feeling is that you are asking quite a bit too much from the > linker to expect it to "flow" code around an obstacle in the middle > of it's memory map. I agree. If at all, I'd simply use the last (upmost) ROM location for that "magic number" or "magic string". Another option would be to use a real "magic string" right behind the vectors table. Just introduce it by a known 32-bit word that can never be part of the vectors table itself. This is basically the way the old revision control system SCCS worked with its "@(#)" magic number, which was then found and extracted by the "what" command. -- cheers, J"org .-.-. --... ...-- -.. . 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] Fine Tuning code timings
I just adjusted the initial bit time by a few counts to offset the delay. Subsequent bits were sampled/output through the same code path so I just continued to add the bit time to the OCxx register for the next interrupt. In my code I used TIMER3 as CPU/8. I had to adjust my initial delays by 10 counts (~80 cycles) to eliminate the ~75 clocks of ISR entry code (determined by inspection of generated assembly). All subsequent adjustments to the OC3X register were just the bit time for the next compare. I for Rx I used IC3 to capture the start time and adjusted that -10 cycled so the first OC3X interrupt would sample at the right time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Shepherd Sent: Saturday, December 22, 2007 11:17 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] Fine Tuning code timings Hi Guys, I'm trying to fine tune some C code timing issues for a software UART written in AVRGCC. Essentially when I go to transmit a byte, I capture the value of Timer1, set the output compare value to the current timer value + the bit period, activate the Tx pin and then wait for the interrupt handler to output the rest of the bits in the byte. The problem I'm having is that the latency between the timer interrupt firing and the code in the interrupt handler that drives the pin state is causing some error. I need some way to calculate the amount of time to reduce the initial timer period by so that the pin state driving logic in the interrupt handler executes at the right time. What I would like to try and find out (and why I'm asking on this list): Is there any way to figure out using compiler tricks/magic how far into a function or interrupt handler a line of code is so that I can use this offset value to tune the initial start-bit timer value. The subsequent bit timings are ok as they are generated using the same code path? I have experimented using LABELS in the code and trying to do pointer arithmetic but they don't seem to be accessible outside the function or I was just doing it wrong. Merry Christmas Alex Shepherd ___ 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] Fine Tuning code timings
Hi Alex, I am not sure why you are capturing the timer1 value, unless you are using the timer for other purposes as well. If not then the easiest method is to: 1. Enable time over flow interrupt. 2. Load the timer withe the required delay for the chosen baud rate. The port pin can be made low here itself as the start bit. 3. When the timer over flow occurs, send the bit and re-load the timer with the earlier value (so the interrupt will occur at the same time for the next bit) If your baud rate is high (19,200 or more) then it makes sense to use an 8 bit timer as the higher byte of a 16 bit timer may have to be 0xff. One rough method to get the timing s to pulse the port pin and monitor it on a scope and adjust the timer re-load value. When stop bit is sent, you may stop the timer to prevent unnecessary interrupts eating into processor time. Hope this helps. Partha Alex Shepherd <[EMAIL PROTECTED]> wrote: Hi Guys, I'm trying to fine tune some C code timing issues for a software UART written in AVRGCC. Essentially when I go to transmit a byte, I capture the value of Timer1, set the output compare value to the current timer value + the bit period, activate the Tx pin and then wait for the interrupt handler to output the rest of the bits in the byte. The problem I'm having is that the latency between the timer interrupt firing and the code in the interrupt handler that drives the pin state is causing some error. I need some way to calculate the amount of time to reduce the initial timer period by so that the pin state driving logic in the interrupt handler executes at the right time. What I would like to try and find out (and why I'm asking on this list): Is there any way to figure out using compiler tricks/magic how far into a function or interrupt handler a line of code is so that I can use this offset value to tune the initial start-bit timer value. The subsequent bit timings are ok as they are generated using the same code path? I have experimented using LABELS in the code and trying to do pointer arithmetic but they don't seem to be accessible outside the function or I was just doing it wrong. Merry Christmas Alex Shepherd ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list - Never miss a thing. Make Yahoo your homepage.___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
