As Weddington, Eric wrote: > > Likewise, the same goes for using nop(), as tempting as it is. > > Again, _NOP() would be fine, as will __nop().
> Hmm. I think that might be included as part of the new builtins for > the AVR port. I don't think there's a reason to have that as a builtin, when it can be so conveniently had as an inline asm statement. That's much different from __delay_cycles. (JTD bit) > We definitely need to create an API for this, and all other timed > sequences. There are a number of timed sequences in the xmega chips > that need to be added. > I know you don't care too much about xmega, because of inability to > program it with avrdude. But a visual inspection of the resulting > code from an inline assembly macro would be good enough for me. OK. > > If we decide for a new header file, how to name it? <avr/asm.h>? > > <avr/misc.h>? > I don't like misc as it is too vague. Then why not <avr/asm.h> or <avr/asmbits.h>? Linux and FreeBSD ship that kind of inline asm stuff in similarly named headers. > For the JTD timed sequence, why not a new <avr/jtag.h> file? It > doesn't matter to me that it may only have one macro in it. At least > it would be easy to remember. Well, it would rather be <avr/nojtag.h> :). Rather something like <avr/mcufeatures.h> or such. After all, it's about MCUCR/MCUCSR. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
