FreeRTOS, task umre pri cekani na semafor...

[Jaroslav Buchta]

Takze chyba zda se mezi klavesnici a zidli, pochopeni systemu priorit a 
subpriorit preruseni vedlo k tomu, ze jsem zjistil, ze je to blbe...
Snad uz tech zasadnich chybicek nebude moc... ;-)
FTP server chodi dobre, zapis na SD asi 190kB/s, cteni skoro 1MB/s, 
limitujici je asi cteni po 1 sektoru - RAM opravdu neni nikdy dost a pri 
128+64kB uz vubec ne.
HTTP take OK, problem s prodlenim close po odeslani obsahu poresilo 
uvedeni delky obsahu v hlavicce - u vsech testovanych klientu je spojeni 
ukonceno klientam a jinak tam mam timeout. Dalsi problem byl, ze 
browsery nacitaji obsah ve vice vlaknech (treba obrazky) a ja odmital 
dalsi pripojeni nez bylo vyrizeno jedno (zas malo pameti :-( ) Cekani 
par s az se dokonci prvni spojeni toto vyresilo. Na obrazky 10MB+ to 
samozrejme neni ;-)

Kdy uz bude k sehnani STM32F429 ke kteremu lze pripojit SDRAM? 
(discovery kit uz mam, super hracka)
Pripojivat SRAM asi nema smysl, to je hrozne pomale pro vsechny potrebne 
ucely (halda, -> zasobniky tasku...)


Dne 30.10.2013 13:55, Jaroslav Buchta napsal(a):
> je to takto:
>
> #define INCLUDE_vTaskSuspend            1
>
> a ISR komplet:
> void ETH_IRQHandler(void)
> {
>   portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
>
>   /* Frame received */
>   if ( ETH_GetDMAFlagStatus(ETH_DMA_FLAG_R) == SET)
>   {
>     /* Give the semaphore to wakeup LwIP task */
>     xSemaphoreGiveFromISR( s_xSemaphore, &xHigherPriorityTaskWoken );
>   }
>
>   /* Clear the interrupt flags. */
>   /* Clear the Eth DMA Rx IT pending bits */
>   ETH_DMAClearITPendingBit(ETH_DMA_IT_R);
>   ETH_DMAClearITPendingBit(ETH_DMA_IT_NIS);
>
>   /* Switch tasks if necessary. */
>   if( xHigherPriorityTaskWoken != pdFALSE )
>   {
>     portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
>   }
> }
>
> ale kdyby chybelo portEND_SWITCHING_ISR tak se snad nic nestane krome 
> vetsiho zpozdeni, ne?
> to ETH_DMAClearITPendingBit je umistene spatne ale jine preruseni 
> stejne neni povoleno a mam overeno, ze se skutecne nevyskytuje.
>
> jeste me napada, ze je trosku dopraseny port modulu sys_arch, ktery 
> jsem syntetizoval z vice zdroju, ale stejne problemy byly i s verzi 
> LWIP 1.3.x kde byl projekt prevzaty cely takze spis ne...
>
>
>
> Dne 30.10.2013 13:37, Stano napsal(a):
>> Este jedna vec, ako mate nastavenu premennu
>> INCLUDE_vTaskSuspend v konfiguracii RTOS
>>
>> Jaroslav Buchta  wrote / napísal(a):
>>> Stale bojuju s STM32F4 a LWIP, docela to funguje ale občas umře... 
>>> Nyni resim zahadu se synchronizaci, cast  funkce (task) pro prijem 
>>> paketu redukovana na podstatne aktualne vypada takto:
>>>
>>>   for( ;; )
>>>   {
>>> STM32F4_Discovery_LEDOn(LEDO);
>>>     int bSync = xSemaphoreTake( s_xSemaphore, 20); 
>>> //emacBLOCK_TIME_WAITING_FOR_INPUT); 
>>> <------------------------------------- tady to umre, ledka zustane 
>>> svitit
>>> STM32F4_Discovery_LEDOff(LEDO);
>>>     portTickType tckRcv = xTaskGetTickCount();
>>>     {
>>>       while (ETH_CheckFrameReceived())
>>>       {
>>>           p = low_level_input( s_pxNetIf );
>>>           LedSetRx();
>>>           if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
>>>           {
>>>             pbuf_free(p);
>>>             p=NULL;
>>>           }
>>>           bSmallDelay = pdTRUE;
>>>           while (bSync && xTaskGetTickCount() - tckRcv < 3) 
>>> vTaskDelay(3); <---------------------------------- bez tohoto 
>>> zpozdeni to umre behem par minut, takhle za par hodin az dni
>>>       }
>>>     }
>>>
>>> Semafor je uvolnovan z ISR ale to funguje (pomaleji a se ztratami 
>>> nekterych paketu) i bez toho diky timeoutu a nemelo by se snad stat, 
>>> ze by to z cekani po 20ms zas nevypadlo...
>>> Problem je, ze tento task ma nejvyssi prioritu jako jediny, ma v 
>>> chybovem stavu status READY (bezne vetsinou BLOCKED) a vesele si pri 
>>> tom funguji tasky s nizsi prioritou a i IDLE. Tomuto scheduler 
>>> proste procesor neprideli, budu dal badat - zatim reseno watchdogem 
>>> coz samozrejme neni idealni... Divne je, ze to je casove zavisle (to 
>>> zpozdeni ma i jiny vyznam kvuli stabilite prenosu vetsich objemu 
>>> dat, dalsi cil badani - mozna to souvisi) a nezda se, ze by selhani 
>>> melo nejakou vazbu na intenzitu komunikace (je na to vetsinou 
>>> PINGano po 2s)
>>> Zasobniky tasku jsou dostatecne, stav vsech tasku si muzu normalne 
>>> vypsat pres USB, zas to bude asi nejaka blbost ale slusna zabava na 
>>> dlouhe vecery je jista ;-)
>>>
>>> No budu se muset nejak zorientovat v tech systemovych frontach, 
>>> pokud nekdo neco podobneho neresil.
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list