This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with _global_reg()

Hi guys,

I use a _global_reg var in my program to avoid save/load:

_global_var uint32_t finished_pixels;

this variable is updated in ADC interrupt.

In main, I have following code:

register uint32_t processed_pixels = 0;

finished_pixels = 0;     // Initial global reg

while (processed_pixels >= finished_pixels)

{

     // Process new pixel

     ...

}

But the armcc will optimize all code in while loop, i.e, "// Process new pixel" section.

I tried "volatile _global_var uint32_t finished_pixels;", but the compiler says it has no effect and the same thing happens;

Now I use "volatile register uint32_t processed_pixels = 0;" to avoid the trap, but it looks ugly.

Is that a compile bug?

Any bettrer solutions?

Thanks a lot!

Parents
  • Yes, double buffer + DMA will be a good solution.

    But I wonder if STM32F302@72MHZ could process 1024 pixels within 256us.

    It seams hard, but you two guys have give me useful suggestions.

    Anyway, is "_global_reg(x) in condition will be optimized as the value will never change" an armcc compile bug?

    Thanks again.

Reply
  • Yes, double buffer + DMA will be a good solution.

    But I wonder if STM32F302@72MHZ could process 1024 pixels within 256us.

    It seams hard, but you two guys have give me useful suggestions.

    Anyway, is "_global_reg(x) in condition will be optimized as the value will never change" an armcc compile bug?

    Thanks again.

Children
  • I'm not sure what you are saying about global_reg.

    The timing looks very tight. I think it should be possible. I think it may be possible to time the getting of the ADC values with the DMA which would be nice. If you do two values at a time and pack them in halfwords I think you probably can just about do the job using the SIMD instructions.

  • The problem is, a _global_reg variable can't be specified as volatile.

    Thus, ARMCC compiler will consider it never changes.

  • You could talk to them about marking it as volatile which I think is the cleanest way of saying it could change at any time, as their documentation says at the moment they don't currently support that. I would be rather loath to depend on such a facility unless the ABI and RTOS supported having a register reserved in such a way so I guess they haven't had any requests for it. If you are are careful placing your loads and stores so they don't cause holdups they an be quite cheap so if in C one had some calculations followed by testing the value of a volatille variable the load of the volatile can be moved back over the calculation.