------- Additional Comments From bob dot paddock at gmail dot com 2005-03-03 13:13 ------- (In reply to comment #5)
>Personally see no problem. The quote above has specifically to do with how to >write a logical 16-bit timer/counter value into a pair of otherwise distinct >8-bit registers, which controls a specific peripheral function which presumes a >specific write sequence to maintainthe logical integrety of that specific timer/counter value; it has nothing to with 16-bit pointers, >the sequencing of multi-byte logical data type transactions, or the compiler in >general. It is specific to the pointer case because the correct order of operations is generated in all other cases. Due to the limited Flash space of the AVR it is common to have structures of pointers pointing to the hardware registers, so that the same code will work with both Output Compare One, and Output Compare Three for example. The Input Capture and Output Compare registers are truly 16-bits in length, they are not distinct 8-bit registers. They are accessed 8-bits at a time. To access the 16-bit registers 8-bits at a time without use of the hardware latching mechanism would require that interrupts be disabled. In many embedded applications this is unacceptable, hence the hardware is provided to deal with this problem. By not disabling interrupts and not using the hardware latching mechanism the embedded device, be it a Cruse Control or Phase Control System, is going to have outputs that are off by a factor of 256 at apparently "random" times. If the complier can not be made to generate correct code for this case then the compile should fail. Consider that if the the order of 16-bit operations I/O was wrong in all cases then the GCC would not be usable on the AVR. "Asynchronous Hardware/Firmware" by Jack Ganssle at http://www.ganssle.com/articles/asynchf.htm goes into the gory details of why this type of failure in a embedded device is down right dangerous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
