Re: arm-gcc: avoid calling other system functions

From	pozz <pozzugno@gmail.com>
Newsgroups	comp.arch.embedded
Subject	Re: arm-gcc: avoid calling other system functions
Date	2018-05-18 09:07 +0200
Organization	A noiseless patient Spider
Message-ID	<pdlu31$43o$1@dont-email.me> (permalink)
References	<pdjt34$18n$1@dont-email.me> <pdk5qi$qbm$1@dont-email.me>

Show all headers | View raw

Il 17/05/2018 17:06, David Brown ha scritto:
> On 17/05/18 14:37, pozz wrote:
>> I'm trying to put all ISRs in RAM[*]. Unfortunately, depending on the 
>> code, arm-gcc could call some system functions that are located in Flash.
>>
>> For example, if I use a switch statement, the compiler calls a piece 
>> of code of system libraries (that are in Flash) that use a table 
>> lookup to manage the switch.
>>
>> Is it possible to force arm-gcc to avoid calling system functions from 
>> ISRs, so it can be executed completely in RAM?
> 
> There is, AFAIK, no way to force this.  It is not normally a problem as 
> ISRs should generally be as short and fast as possible.

I always try to keep the ISR short, simple and fast.  However a simple 
switch statement (a different way to write a sequence of if statements) 
is compiled in assembler code that uses "libgcc functions".

> For functions that must be run from ram, don't call other functions 
> unless it is unavoidable.  

And usually I don't call functions directly from my ISR (it's gcc that 
calls its libgcc functions).

Only a few times I need to call functions from inside the ISRs. It 
usually happens when I want to create a sufficiently generic low-level 
driver.

For example, consider a UART driver. Most of the time I push the 
received bytes in a FIFO buffer during ISR. The mainloop polls the FIFO 
buffer and pop byte by byte and process them.
However I sometimes need to process bytes as soon as they are received, 
so in ISR. For example, because the frame is addressed and I need to 
receive the frame only if it is directed to me (maybe because a frame 
addressed to another node could be much longer than the frame I can manage).
In order to have a generic driver, the application calls a 
uart_set_callback(). In this case, the driver calls the "user" callback 
function when a byte is received, *during ISR*.

Another example is an ADC driver that I wrote some time ago. I had 20 
analog signals that I needed to convert in 4 different states, depending 
on the ADC value and depending on the configuration of each signal.

    switch(signal_conf[signal_idx]) {
      case CONF1:
        if (adc_value < 100) signal_status[signal_idx] = ALARM;
        if (adc_value < 200) signal_status[signal_idx] = IDLE;
        if (adc_value < 300) signal_status[signal_idx] = SABOT;
        if (adc_value < 400) signal_status[signal_idx] = SABOT+ALARM;
        break;
      case CONF1:
        if (adc_value < 150) signal_status[signal_idx] = ALARM;
        if (adc_value < 250) signal_status[signal_idx] = IDLE;
        if (adc_value < 350) signal_status[signal_idx] = SABOT;
        break;
      ...
    }

In order to have a sufficiently generic ADC driver, the application 
calls adc_set_callback() and the ADC ISR calls this "user callback" when 
a new sample is available.

> And when you do, mark those functions as 
> being in the RAM section, or as __attribute__((always_inline)).  This 
> doesn't work for language support functions - you avoid these by 
> avoiding using such language features (such as division or software 
> floating point).

Or switch statements...

>> [*] This is why I need to erase/write Flash memory and during these 
>> operations the Flash can't be read and code in Flash can't be executed.
> 
> Note that you can't use ISRs during flash operations unless the vector 
> table is also moved to ram.

I know.

> While you are erasing or writing flash, it is usually easiest to simply 
> disable interrupts.  If you really need an interrupt or two running, 
> disable all but the critical ones and make sure these are short and fast.

I'm trying to use MCU Flash to save some non-volatile configuration 
parameters. The user can change the configuration when he wants. At this 
moment, the Flash must be erase/written, however the device should work 
as usual.

Thread

arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-17 14:37 +0200
  Re: arm-gcc: avoid calling other system functions Grant Edwards <invalid@invalid.invalid> - 2018-05-17 13:27 +0000
    Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-17 15:35 +0200
      Re: arm-gcc: avoid calling other system functions Grant Edwards <invalid@invalid.invalid> - 2018-05-17 14:18 +0000
        Re: arm-gcc: avoid calling other system functions David Brown <david.brown@hesbynett.no> - 2018-05-17 17:08 +0200
        Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-18 08:47 +0200
  Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-17 15:30 +0200
  Re: arm-gcc: avoid calling other system functions David Brown <david.brown@hesbynett.no> - 2018-05-17 17:06 +0200
    Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-18 09:07 +0200
      Re: arm-gcc: avoid calling other system functions David Brown <david.brown@hesbynett.no> - 2018-05-18 09:51 +0200
        Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-21 09:14 +0200
          Re: arm-gcc: avoid calling other system functions David Brown <david.brown@hesbynett.no> - 2018-05-21 12:50 +0200
        Re: arm-gcc: avoid calling other system functions Joe Chisolm <jchisolm6@earthlink.net> - 2018-05-21 10:15 -0500
          Re: arm-gcc: avoid calling other system functions David Brown <david.brown@hesbynett.no> - 2018-05-21 19:31 +0200
            Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-22 09:05 +0200
              Re: arm-gcc: avoid calling other system functions David Brown <david.brown@hesbynett.no> - 2018-05-22 10:59 +0200
              Re: arm-gcc: avoid calling other system functions Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-05-22 15:24 +0300
                Re: arm-gcc: avoid calling other system functions pozz <pozzugno@gmail.com> - 2018-05-22 14:55 +0200
  Re: arm-gcc: avoid calling other system functions Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-05-18 12:41 +0300

csiph-web