S12 / MagniV MicrocontrollersのトピックRe: Clearing the bit

Clearing the bit

admin — Thu, 15 Jan 2009 15:59:23 GMT

Hello All,

My doubt is that in certain microcontrollers like MPC5554 ,certain bits are cleared by writing a '1' on it .Why is it so? Normally bits are cleared by writing a '0'.

Re: Clearing the bit

Lundin — Thu, 15 Jan 2009 18:22:49 GMT

Because Freescale refrains from making their mcu peripherals logical and intuitive whenever possible...

Clear by writing 1 or clear by reading are very annoying features of some peripherals, that surely must cause millions of bugs for all Freescale users, especially those who are using C. I bet every single user sooner or later runs into classic Freescale bug 1: "the debugger is eating my SCI/SPI flags" and classic Freescale bug 2: "my timer flags are destroyed because I clear a flag with TIMER_REG |= 0x01 rather than TIMER_REG = 0x01".

But the C language has only been standardized for 18 years, so if we give Freescale more time they might at some point adapt their micros to support this new fancy language.

Re: Clearing the bit

kef — Thu, 15 Jan 2009 20:24:25 GMT

Lundin,

this issue isn't easy to fix. Would you like slowing down CPU like it's done in Microchip MCUs to solve this? Maybe slowing down peripherals? More complicated circuit and more expensive chip? One flag per register leading to more address space occupied by registers block (something like in S08 family, but first compare how many flags does S12D family have)? I wouldn't.

Egg vs chicken. Is C more important than everything else?

Re: Clearing the bit

Lundin — Thu, 15 Jan 2009 23:34:57 GMT

Changing logic level from 1 to 0 can hardly be expensive. The clear-by-read issues in SCI/SPI are seem to be there for backwards compatibility only.

Another case where the C language has clearly not been considered is the address map. A write to address zero should yield an error interrupt on a micro designed for the C language, to prevent null pointer access.

Also, companies like Freescale spend huge amounts of cash on things like AUTOSAR to reduce software bugs. In my opinion they should start fixing the simple things first.

Re: Clearing the bit

kef — Fri, 16 Jan 2009 13:01:11 GMT

You don't like NOTsimple change of logics from 1 to 0, do you? Let's think about timer flags. Currently, to clear bit0 and keep other bits in their current state you write

TFLG1 = 1;

After change of logics 1->0, above would become

TFLG1 = 0xFE;

But neither

TFLG1 &= ~1; // (BCLR TFLG1,#1)

nor

TFLG1_C0F=0; // (also BCLR TFLG1,#1)

would work properly! Both variants would clear more bits than you expect!

And backwards compatibility is another issue non issue.

Re: Clearing the bit

admin — Fri, 16 Jan 2009 16:32:25 GMT

Hello All

I dont know whether everyone understood my doubt,Lets consider this bit in register

EQADC_FISRn of MPC5554.

EOQFn End-of-queue flag n. Indicates that an entry with an asserted EOQ bit was transferred from CFIFOn to the on-chip ADCs or to the external device. . When the eQADC

completes the transfer of an entry with an asserted EOQ bit from CFIFOn, EOQFn will be

set. Writing a 1 clears the EOQFn bit. Writing a 0 has no effect.

0 Entry with asserted EOQ bit was not transferred from CFIFOn

1 Entry with asserted EOQ bit was transferred from CFIFOn.

How again writing a "1" clears that bit ?

Re: Clearing the bit

kef — Fri, 16 Jan 2009 17:59:43 GMT

Probably there's something like FISRn trigger, AND gate and "chip select" circuit, all wired so that when EQADC register is selected and WRite is high and data bus bit corresponding to FISRn bit position is '1', then FISRn trigger is reset. Simple.

BTW MPC5554 is not a 16bits MCU.

Re: Clearing the bit

admin — Mon, 19 Jan 2009 16:26:22 GMT

Hello All

Thank you for your kind information.