Yes I did understood that, but putting a pseudo-var for this seems overkill to me, and doesn't fix potential issue either . FSR & POSTINC usage is already centralized in this _usb_copy_arry_to_ram() procedure. (and it could be put in an external library, as it can be useful not only for USB).
If necessary, we could use asm as you suggested, to avoid conflicting with compiler. Seb 2011/4/3 Oliver Seitz <[email protected]> > > >But what would be the benefits ? > > >>2. Create a inline usb_out_buffer'get function for POSTINC1 > > If one day the compiler starts to use FSR1 internally, only this 'get > function will have to be modified. Or, it can directly be written like > > Increment pointer > ASSEMBLER > Load FSR with that pointer > Read back value from INDF > END ASSEMBLER > > This would be safe for any additional FSRs the compiler may require. It > will be a bit slower, but you can't always have maximum speed and > versatility. > > Greets, > Kiste > > -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
