LWIP 1.4.1, FreeRTOS, kdepak, nejde...

Pátek Říjen 18 19:12:07 CEST 2013

S tim jsem se osobně nesetkal, normálně podle mého běhá po síti tolik broadcast paketů, že zařízení nemá šanci být "neaktivní".
Pokud budete chtít posílat nějaký paket jen tak - určitě ničemu neublížíte, pokud zvolíte "Gratuitous ARP". Osobně jsem si doplnil vyslání tohoto paketu při startu a po každém připojení kabelu. Užitečné, pokud "rychle" přepojujete jedno zařízení do různých míst sítě.
Martin. persich na transcon.cz

  ----- Original Message ----- 
  From: Jaroslav Buchta 
  To: HW-news 
  Sent: Friday, October 18, 2013 6:59 PM
  Subject: Re: LWIP 1.4.1, FreeRTOS, kdepak, nejde...

  Jeste otazecka - je mozne, ze AP nebo router zacne pripojene zarizeni ignorovat, kdyz je dlouho neaktivni? Zase po prijezdu z nakupu mrtvola, po odpojeni a pripojeni kabelu (bez restartu) OK. Myslim, ze neblikala ani ledka na konektoru, takze router na tu adresu asi nic neposilal... Tady by pomohlo zrejme posilat periodicky nejake broadcasty ze zarizeni - jake nejlepe?

  Dne 18.10.2013 17:31, Jaroslav Buchta napsal(a):

    Ja uz se z toho picnu, zatim to vypada, ze se neco nekde predbiha - kdyz prelozim kod neoptimalizovany, pravdepodobnost seknuti se snizi tak 5x, kdyz to pripojim primo k compu, tak to je taky v pohode a ted jsem dal zpozdeni po zpracovani prichoziho paketu a to zda se chodi take dobre (to bylo puvodne kvuli tomu abych videl, ze blika ledka...)

    void ethernetif_input( void * pvParameters )
    {
      struct pbuf *p;

      for( ;; )
      {
        if (xSemaphoreTake( s_xSemaphore, emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE)
        {
          STM32F4_Discovery_LEDOn(LEDO);

          p = low_level_input( s_pxNetIf );
          if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
          {
            pbuf_free(p);
            p=NULL;
          }
          vTaskDelay(10);    <-----------------------------------------------------------------------
          STM32F4_Discovery_LEDOff(LEDO);
        }
      }
    }

    A taky obcas pomuze odpojit a pripojit kabel - jakoby router uz pakety po nejake dobe do zarizeni neposilal - je to mozne, kvuli nejake chybne reakci - odpovedi na nejaky dotaz atp? 

    Dne 18.10.2013 6:45, Jaroslav Buchta napsal(a):

      Tak bohuzel, vypadalo to nadejne ale je to nejak velmi nahodny proces... Pamet haldy jsem zvetsil extremne, ale jak jsem zjistil ze statistik, neni vubec pouzivana, dokud nepouziju nejake hiugh level funkce (coz samozrejme behem testu nepouzivam)... Takze zbyva zkoumat obsluhu hardware, funkci ISR, DMA a hlavnesynchronizace tasku, kde to vyhnije.... Ostatni casti programu a tasky normalne bezi, i VCP na USB, takze vetsi destrukce pameti nenastava.

      Dne 17.10.2013 8:09, František Burian napsal(a):

        Bude to tim MEM_SIZE, u mne se to chovalo stejne, jednou za cas se neuvolnil paket (nebyl volny buffer ethernetoveho rozhrani) a strasne jsem se divil ze mi po case roste pametova narocnost. Pro overeni ze je to tento problem bych doporucil MEM_SIZE nastavit stejne, kolik mate deskriptoru v hw ethernetu, to pak padne hned pri prvnim neuvolnenem bloku.

        Tipuji ze jste jen problem oddalil ale nevyresil. Spis bych zvetsil pocet deskriptoru na RX i TX kontrolovanych DMA ethernetu.

        Franta.

        ---------- Původní zpráva ----------
        Od: Jaroslav Buchta <jaroslav.buchta na hascomp.cz>
        Datum: 17. 10. 2013
        Předmět: Re: LWIP 1.4.1, FreeRTOS, uz snad vse jde

          Tak snad konecne uspech, celou noc bezi stabilne a komunikativne - provedl jsem par zmen v nastaveni options jako syntezu z ruznych projektu a podle uvazeni, co by mohlo pomoci....
          Az bude trochu casu, zkusim iteracni metodou zjistit, ktere nastaveni bylo to dulezite ;-)
          Nove (rozdilne) bylo nastaveno toto:

          #define ETHARP_TRUST_IP_MAC             1
          #define IP_FRAG_USES_STATIC_BUF         1
          #define LWIP_AUTOIP                     1
          #define SYS_LIGHTWEIGHT_PROT    1                    // toto tipuji jako klicove
          #define MEM_SIZE                (8*1024)                       // predtim 5*
          #define DEFAULT_THREAD_STACKSIZE        1000    // predtim 500, ale zasobniky jsem vypisoval a docela rezerva byla

          Tak snad uz OK, ted zacnu resit ty servery, mam dojem, ze nejaky projekt tu kdysi probehl ale nemohu to najit.

          Dne 16.10.2013 22:35, Martin Persich napsal(a):

            Nezaregistroval jsem, jaký hardware máte použit, ale já jsem realizoval zařízení s MCU Atmel AVR32 (AT32UC3xx) a DP83848 (National Semiconductor). Použil jsem driver dodaný firmou Atmel pro vývojový kit EVK1100 a tam byla (a troufám si tvrdit, že přestože jsem firmu Atmel již dvakrát na toto upozornil, že tam ještě je) chyba, která se projevuje přesně, jak píšete. V okamžiku, kdy řadič vyhodnotí chybu během odesílání paketu, řadič zablokuje další vysílání, ale driver toto nezaregistruje a neprovede jeho reset. Samozřejmě - nejčastěji toto vzniká při kolizi paketu, když je vše připojeno na "obyčejný" HUB (ano, pořád si pro ladění Ethernetových komunikací jeden schovávám, je to nesrovnatelně pohodlnější, než nastavovat monitorování pro nějaký inteligentní switch).
            Alespoň si člověk zvedne sebevědomí, že ani tito "světoví" vývojáři nejsou bez chyby, když pak zjistí, že zapomněli v návrhu na dva rezistory uvedené v datasheetu ... cca dvacet kusů zařízení je ok, další dvě stávkují ... Jo, člověk nesmí věřit všemu, co najde na internetu ...
            A s příkazem "ping" mám také ještě jeden nevyřešený problém. Pokud pustím "ping" na dvou mých zařízeních (perioda 200 ms, paket 400 Byte) proti sobě, jede to měsíc bez zaškobrtnutí, 100 % úspěšnost. Pokud však do těchto zařízení ještě pustím druhý "paralelní" ping z normálního PC (perioda 1 s), klesně úspěšnost na cca 98 %. Asi se tam ještě něco přepisuje, ale vím o tom a prozatím jsem to neměl čas řešit.

            Martin. persich na transcon.cz
              ----- Original Message ----- 
              From: Jaroslav Buchta 
              To: HW-news 
              Sent: Wednesday, October 16, 2013 7:37 PM
              Subject: Re: LWIP 1.4.1, FreeRTOS, nejde PING

              Hmmm je to nejake divne, obcas to zdechne - nekdy to vydrzi minutu, nekdy pul dne... Ted to zkousim primo pripojene k compu, abych mohl sledovat veskerou komunikaci a zatim to funguje,neni znamy nejaky bug, ktery by treba delal problemy s nekterymi routery a tak? Cely system nespadne, funkcni tasky bezeji dal, zrejme to i pakety prijima ale nevysila... Ale to se blbe overuje, zrovna u teto desky nemam zadnou jinou komunikaci - asi budu muset zprovoznit SWO pres STLINK, ale s tim tady nekdo taky hlasil problem, ze se ztraci cast dat, ze...

              Dne 15.10.2013 6:36, František Burian napsal(a):

                Stabilita muze byt uvolnovanim. Taky jsem to resil az jsem prisel na to ze pokud volani lwip funkce ktera ma jako parametr pbuf, a ma ho uvolnit, selze, pak musim uvolnit tu pamet sam ! Zejmena jde o lowlevel send a receive ... Asi tyden mi to dalo nez jsem pochopil.

                Franta.

                ---------- Původní zpráva ----------
                Od: Jaroslav Buchta <jaroslav.buchta na hascomp.cz>
                Datum: 15. 10. 2013
                Předmět: Re: LWIP 1.4.1, FreeRTOS, nejde PING

                  Tak vyreseno, ve stare verzi nebylo prekryti definice
                  #define CHECKSUM_GEN_ICMP
                  takze to tam misto souctu nedavalo 0 a HW to spatne zda se spocital....
                  No ale pekne jsem si osvezil sitove protokoly za ty 2 noci :-P
                  Tak jeste ta stabilita, to bude asi nejaky zasobnik nejakeho tasku zase...
                  _______________________________________________
                  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

_______________________________________________
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

_______________________________________________
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
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20131018/60be5c2d/attachment.htm>