[3.14 0]

Пользуюсь FreeRTOS+SAM7x256

Разъясните плиз попопулярнее как засовывать свои обработчики прерывания и какие тонкости в контексте операционки следует учитывать.

[zltigo 1]

Разъясните плиз попопулярнее как засовывать свои обработчики прерывания

Как обычно, системе все равно.

и какие тонкости в контексте операционки следует учитывать.

Ну кроме использования вариантов некоторых системных вызовов ориентированных на вызов из обработчиков прерывания - никаких.

[3.14 0]

1) создал асмову обложку

        RSEG ICODE:CODE
        CODE32
        EXTERN vUSARTISR
        PUBLIC vUSARTISREntry
#include "ISR_Support.h"
vUSARTISREntry:
    portSAVE_CONTEXT            
    bl    vUSARTISR                
    portRESTORE_CONTEXT            
    END

2) объявил

extern void vUSARTISREntry( void );
__arm void vUSARTISR( void );

3) обработчик

__arm void vUSARTISR(void)
{
    write_char_USART0 ('A');
     USART_pt->US_CR = AT91C_US_RSTSTA;
}

4) в инициализации USART-а добавил

AT91F_AIC_ConfigureIt ( AT91C_BASE_AIC, AT91C_ID_US0, USART_INTERRUPT_LEVEL,AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL, ( void (*)( void ) ) vUSARTISREntry);
AT91F_AIC_EnableIt (AT91C_BASE_AIC, AT91C_ID_US0);

 

 

Вроде все на месте а не фурычит :(

[3.14 0]

Блин, сижу как дыбыл ничего не понимаю, за соседним столом такие-же исходники (но под кейлом), работает ...

[Пришелец 0]

 
    /* End the interrupt in the AIC. */
    AT91C_BASE_AIC->AIC_EOICR = 0;

 

нужно добавить в конец обработчика

 

 

а вообще проще взять целиком пример из исходников FREERTOS - там же ведь он есть

[3.14 0]

пробовал, поведение не меняется

[zltigo 1]

Блин, сижу как дыбыл ничего не понимаю, за соседним столом такие-же исходники (но под кейлом), работает ...

А это под чем?

[3.14 0]

Под IAR-ом.

[zltigo 1]

Под IAR-ом.

 

Тогда для начала незачем асмовские оберки городить

__irq __arm void vUSARTISREntry( void )
{
....
}

Дальше разбирайтесь с инициализацией AVRовского железа....

[3.14 0]

А в чем тогда смысл этих оберток (это кейловское "наследие")?

Просто в примере с uIP сокетом, обработчик прерывания MAC-а написан по вышеупомянутой схеме.

 

Насчет AVR, хотите сказать что в периферии SAM7 многое от AVR?

Меня, если честно, больше на филлипс тянет но пока ни образцев ни тем более серийных экземпляров их арм-ов с MAC-ами нет.

[zltigo 1]

А в чем тогда смысл этих оберток (это кейловское "наследие")?

Для тех, кто без __irq

 

Насчет AVR, хотите сказать что в периферии SAM7 многое от AVR?

Хотел написать Atmel :-)

 

Меня, если честно, больше на филлипс тянет но пока ни образцев ни тем более серийных экземпляров их арм-ов с MAC-ами нет.

Внешний на SPI - и все проблемы..

[3.14 0]

Меня, если честно, больше на филлипс тянет но пока ни образцев ни тем более серийных экземпляров их арм-ов с MAC-ами нет.

Внешний на SPI - и все проблемы..

Не нравится.

[Kitsok 0]

Вчера нарвался на грабли с IARом.

 

Суть такая. Беру FreeRTOS, из него - демку под SAM7S64, которая USB-джойстик.

Для начала все выкинул лишнее, оставил только USB и мигание диодами.

Потом решил добавить обработчик на ADC. Сделал все точно так-же, как у них в демке сделано для USB. Единственная разница - я не запускаю отдельной задачей весь "пакет" с инициализацией, а просто инициализирую ADC, разрешаю прерывание и все. Да, необходимое уточнение. Файлы я назвал ADC.s79 и ADC.c. В первом - асмовая обертка, во втором - инициализация и собственно обработчик.

 

Дальше компилю, заливаю во флеш (тут еще один вопрос, задам в отдельной ветке), и..... глухо, даже диоды не моргают.

 

Удивляюсь, оставляю код, но выкидываю запуск инициализации (по идее, все по дефолту - прерывания не разрешены, и т.д. и т.п., просто есть кусок кода в бинарнике, который никогда не выполняется) - те-же грабли.

 

Попробовал в отладчике запустить и, что меня удивило, запуск начинается почему-то не в Cstartup.s79, а в ассемблерной обертке обработчика ADC. Ну в общем меня посетила странная мысль и я переименовал файлы из ADC.* в xADC.*. После этого все заработало.

 

Это что, такая мода у компилятора - менять точку входа в зависимости от имени файлов?

Ну и, заодно, вопрос. Правомерно ли после инициализации ADC выполнять AT91F_AIC_ConfigureIt и AT91F_AIC_EnableIt и забывать о всех проблемах? Достаточно ли этого?

[Kitsok 0]

Дело было не в бобине ;)

 

Я не учел, что четыре из восьми каналов АЦП завернуты на кнопки и светодиоды ;) Соответственно, ничего не жило и не моргало.

 

Вот только теперь - вопрос.

 

Вот обработчик:

static __arm __irq void vADC_ISR(void)
{
  unsigned portCHAR i = 0;
  unsigned portCHAR sr =0;
  
  // Read status register
  sr = a_pADC->ADC_SR & 0xff;
  
  /*
  sADC_RAW[0]=a_pADC->ADC_CDR4;
  sADC_RAW[1]=a_pADC->ADC_CDR5;
  sADC_RAW[2]=a_pADC->ADC_CDR6;
  sADC_RAW[3]=a_pADC->ADC_CDR7;
  */
  
  sBUTTONS[7]=sr;
  for (i=0;i<8;i++)
   {
     if ( (sr >> i) & 0x01)
      {
        // Bit is set, put data to array
        sADC_RAW[i]= (*( AT91C_ADC_CDR0 + (0x04*i))) & 0xff;
      }
   }
  
  // Start new conversion
  a_pADC->ADC_CR = 0x2;
  
  /* End the interrupt in the AIC. */  
  AT91C_BASE_AIC->AIC_EOICR = 0;
}

 

Что не так в цикле? ;) Не работает ;)

[vmp 0]

Вчера нарвался на грабли с IARом.

Да, необходимое уточнение. Файлы я назвал ADC.s79 и ADC.c.

Да, интересные грабли. Получается, что IAR после трансляции должен создать два объектных файла с одинаковыми именами ADC.r79. Естественно, останется только один из них.

Так что надо давать файлам разные имена.