Перейти к содержанию
Поиск
    

IvanPletnev

Участник
 Профиль  Обзор контента

  • Постов

    68

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные IvanPletnev

  1. Опубликовано · Пожаловаться

    Приветствую, уважаемые коллеги! Напишу здесь, может кому пригодится, как сделать так, чтобы контрольная сумма, вычисляемая блоком CRC STM32, совпадала с обычной CRC32 (в онлайн калькуляторах, библиотеках и т.п.). 

    В микроконтроллерах серии F4 блок CRC никак не настраивается, то есть нельзя настроить реверс бит на входе и на выходе блока CRC. Поэтому, для реверса бит, мы применяем инструкцию ARM rbit. Насколько мне известно, она присутствует в ARM, начиная с Cortex M3.

    Функция реверса выглядит так: 

      uint32_t reverse_32(uint32_t value)
  {
    uint32_t result;

    __ASM volatile ("rbit %0, %1" : "=r" (result) : "r" (value) );
    return(result);
  }

    Далее надо реверсировать вход и выход модуля CRC: 

    for (index = 0U; index < BufferLength; index++)
    {
      hcrc->Instance->DR = reverse_32(pBuffer[index]);
    }
    temp = reverse_32(hcrc->Instance->DR);

    И инвертировать выход. 

    return ~temp;

    Всё, теперь контрольная сумма соответствует CRC32. Правда, должен заметить, что если мы используем CRC для расчета контрольной суммы массива байт, то размер массива должен быть кратен четырём. Для расчета остатка меньше четырех байт нужно провести еще кое-какие операции.

  8. Опубликовано · Изменено пользователем IvanPletnev · Пожаловаться

    Уважаемые коллеги, добрый день! Ошибочно заказал в КОМПЭЛ 150шт PIC18F44K22 -I/P в корпусе DIP. Хотя нужно было в TQFP-44.

    Обратно не принимают. Отдам за 200 рублей/шт.

     

    UPD. Ой, простите, не заметил раздел форума с продажей компонентов, написал здесь

  9. Опубликовано · Пожаловаться

    1 hour ago, cybersonner said:

    Столкнулся с аналогичной пролемой на STM32F207. Retransmission при передаче больших страниц. Долго искал проблемы в программной части, оказалось- проблемы с питанием. 

    В моём случае точно не из-за питания, на одной и той же плате всё. Сейчас тестирую, всё работает отлично. 

  11. Опубликовано · Пожаловаться

    А и правда компилируется этот код. Но избавиться от подсветки "неактивного" кода мне так и не удалось. 

    #include "lwip/opt.h"
  
  #if LWIP_NETIF_STATUS_CALLBACK
  void netif_set_status_callback(struct netif *netif, netif_status_callback_fn status_callback){
     .....
  #error bla-bla
  }
  #endif

    Даёт ошибку. Значит, всё работает. Но эта подсветка сильно сбивает с толку.

  12. Опубликовано · Пожаловаться

    Здравствуйте, коллеги!! Может, конечно, глупый вопрос задам, не пинайте сильно. В который раз уже замечаю, что CubeIDE иногда отказывается реагировать на define. Вот пример: 

    В файле lwipopts.h  

    #define LWIP_NETIF_STATUS_CALLBACK 1

    в файле netif.c 

    #include "lwip/opt.h"
  
  #if LWIP_NETIF_STATUS_CALLBACK
  void netif_set_status_callback(struct netif *netif, netif_status_callback_fn status_callback){
     .....
  }

    Соответственно, в файле lwip/opt.h подключен файл lwipopts.h. 

    Всё, как обычно. Но! Код, который внутри #if #endif неактивен(подсвечен) и не компилируется. При наведении курсора на LWIP_NETIF_STATUS_CALLBACK в подсказке показывается 0. При этом в файле opt.h конструкция  

    #if !defined LWIP_NETIF_STATUS_CALLBACK || defined __DOXYGEN__
#define LWIP_NETIF_STATUS_CALLBACK      0
#endif

    работает. И если нажать в файле netif.c на LWIP_NETIF_STATUS_CALLBACK с зажатым ctrl, то редактор перекидывает на этот дефайн в файле lwipopts.h, где стоит единица.

    Такое регулярно случается, потом проходит само собой. Почему это происходит и как бороться с этим, кто нибудь может объяснить?

  13. Опубликовано · Пожаловаться

    В общем, экспериментальным путём я выяснил, что эта проблема появляется, когда код генерируется CubeMX v. 6.2.1 и STM32Cube F4 v. 1.26.1. 

    Когда код сгенерирован CubeMX v. 6.1.1 или 6.1.2 и STM32Cube F4 v. 1.25.2 всё работает отлично. Заметил, что в версии 1.26.1 обновлена FreeRTOS до 10.3.1. Пока не разбирался, в чём там отличия.

  14. Опубликовано · Пожаловаться

    Больше нет никакой разницы. Просто мне понадобился web интерфейс на устройство, которое уже почти готово. Для того, чтобы потренироваться с http сервером я не стал встраивать его сразу в устройство, а решил сначала сделать для него отдельный проект. Взял CubeIDE, настроил LWIP, сгенерировал, запустил. И потом несколько дней провозился собственно с сабжем. Пока не создал проект в CubeMX с точно такими же настройками. Всё совершенно одинаково, но проект из CubeMX работает хорошо, а из CubeIDE нет. Теперь вот надо прикручивать SGI и SSI. Если кто-то поделится опытом в этом смысле, буду благодарен.

  17. Опубликовано · Пожаловаться

    Сегодня проверил то же самое с F746-DISCO. Собрал пример от ST, закинул свою страницу, запустил. Всё работает отлично, несмотря на то, что стек жалуется на нехватку памяти. Но с нехваткой памяти я знаю, как справиться. А когда генерирую новый проект из CubeIDE, http сервер работает медленно и генерирует ретрансмиты. Код сервера беру из этого же примера. Три дня уже потратил в поисках проблемы. Куда смотреть, подскажите пожалуйста. 

  18. Опубликовано · Пожаловаться 

    void http_server_serve(struct netconn *conn)
{
 struct netbuf *inbuf;
 err_t recv_err;
 char* buf;
 u16_t buflen;
 struct fs_file file;

 /* Read the data from the port, blocking if nothing yet there.
  We assume the request (the part we care about) is in one netbuf */
 recv_err = netconn_recv(conn, &inbuf);

 if (recv_err == ERR_OK)
 {
   if (netconn_err(conn) == ERR_OK)
   {
     netbuf_data(inbuf, (void**)&buf, &buflen);

     /* Is this an HTTP GET command? (only check the first 5 chars, since
     there are other formats for GET, and we're keeping it very simple )*/
     if ((buflen >=5) && (strncmp(buf, "GET /", 5) == 0))
     {
       if ((strncmp((char const *)buf,"GET / ",6)==0)||(strncmp((char const *)buf,"GET /index.html",15)==0))
       {
         fs_open(&file, "/index.html");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /port1.html",15)==0)
		  {
			fs_open(&file, "/port1.html");
			netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
			fs_close(&file);
		  }
		  else if (strncmp((char const *)buf,"GET /IMG/logo.png",17)==0)
       {
         fs_open(&file, "/IMG/logo.png");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /NotoSerif.woff",19)==0)
       {
         fs_open(&file, "/NotoSerif.woff");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /style.css",14)==0)
       {
         fs_open(&file, "/style.css");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /IMG/img1.jpg",17)==0)
       {
         fs_open(&file, "/IMG/img1.jpg");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /IMG/img2.jpg",17)==0)
       {
         fs_open(&file, "/IMG/img2.jpg");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /IMG/img3.jpg",17)==0)
       {
         fs_open(&file, "/IMG/img3.jpg");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else if (strncmp((char const *)buf,"GET /IMG/arrow.png",18)==0)
       {
         fs_open(&file, "/IMG/arrow.png");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       else
       {
         fs_open(&file, "/404.html");
         netconn_write(conn, (const unsigned char*)(file.data), (size_t)file.len, NETCONN_NOCOPY);
         fs_close(&file);
       }
       printf("Heap minimum size %u\r\n",xPortGetMinimumEverFreeHeapSize());
     }
   }
 }
 /* Close the connection (server closes in HTTP) */
 netconn_close(conn);

 /* Delete the buffer (netconn_recv gives us ownership,
  so we have to make sure to deallocate the buffer) */
 netbuf_delete(inbuf);
}

    На самом деле, сейчас функция передачи это функция из примера ST. Только с моими файлами и путями. Только в примере она работает, как нужно, а у меня пока нет. Сейчас смотрю в сторону приоритетов прерываний, сравниваю пример с моими.

  20. Опубликовано · Пожаловаться

    Уважаемые коллеги, здравствуйте!

    Делаю http сервер на sockets API, всё в целом работает, но во-первых, иногда (не всегда) страница 60кб довольно долго грузится (3-4c), а во-вторых, wireshark показывает ретрансмиты (см. картинку). Статистика LWIP показывает, что всего хватает. И памяти, и буферов. Ошибки в статистике все по нолям. И в общем, эти ретрансмиты не мешают, но всё равно хочется избавиться от них.

    Пробовал делать параллельный сервер (отдельная задача на каждый сокет), но во-первых это не помогло уйти от ретрансмитов, а во-вторых появилась проблема некорректного закрытия сокетов, которые со временем накапливались и вешали приложение напрочь.

    В общем, подскажите, пожалуйста, может у кого-то есть решение вышеперечисленных проблем?

    Screenshot_67.png

    Screenshot_66.png

  24. Опубликовано · Пожаловаться

    Уважаемые коллеги, здравствуйте!

    Делаю устройство на STM32F427 с использованием LWIP Sockets. Отправляю в сокет пакеты длиной 9 байт с частотой 120Гц. На приёмной стороне среднее количество полученных девятибайтовых пакетов за секунду 120. То есть все пакеты доходят до адресата отлично. Но! Wireshark мне показывает вот такую картину. Он говорит, что за секунду отправляется 5 TCP пакетов с payload 216 байт. То есть 24 девятибайтовых посылки в одном пакете. Мне нужно передавать быстроменяющийся сигнал, и за 200мс он безнадежно устареет.

    Вопрос такой. Как сделать, чтобы LWIP старался отправить TCP пакет сразу, а не накапливал данные в буфере? Я понимаю, что такой подход неэффективен, но нужно именно так.

    Заранее благодарю за ответы.

    Screenshot_59.png

    Screenshot_60.png

  25. Опубликовано · Пожаловаться

    Уважаемые коллеги, не нашел на форуме ветки про ESP32, поэтому напишу здесь. Тем, кто изучает этот МК полезно будет это знать. Начал знакомиться с этим МК, запустил пример TCP сервера из комплекта SDK, всё работает замечательно. Решил пропинговать пакетами по 64 байта, заметил, что время пинга значительное - от 80 до 200мс. Начал изучать документацию, оказалось, что начиная с версии 3.1, по умолчанию стоит режим пониженного потребления (WIFI_PS_MIN_MODEM). Это значит, что в промежутке между маяками точки доступа WiFi спит. Чтобы включить нормальный режим, нужно вызвать функцию  

    esp_wifi_set_ps(WIFI_PS_NONE);

    Время пинга теперь составляет от 2 до 5 мс.

    Пользуйтесь.

×
×
  • Создать...