Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

Esp8266->spi->tft (ili9341) без внешнего mcu

Тема в разделе "Другие проекты", создана пользователем Perfer, 1 фев 2015.

  1. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Подождите, серьезно? Вы говорите, что можно удвоить частоту ядра и ничем за это не заплатить? А чего его тогда не заставить все время работать на 160? Где подвох? А что за волшебные битики выставляются?
     
  2. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.397
    Симпатии:
    1.271
    Я всегда, в своих проектах, гоняю модули на 160MHz. Включаю 160MHz в первых командах инициализации и постоянно, когда открыты соединения по TCP. Не выключаю никогда (но периодически отключает SDK в процедуре, вызывающейся периодически через несколько секунд и опрашивающей массу условий - вроде названа и выводит в отладку "periodic_call").
    Плата в том, что немного больше греется и немного больше жрет. Но она компенсируется увеличением производительности с лихвой (трансфер WEB сервера поднимется почти в 2 раза, иногда и более - зависит от асинхронностей обработки пакетов WiFi).
    Это битик переключает делитель на CPU и далее вызов процедуры, указывающей остальным процедурам BIOS и SDK, что частота на CPU переключена и мы не в "режиме экономии". На остальную периферию CPU это не влияет - у них свои делители.
    SDK создана для опроса одного датчика и Iot - им и не требуется производительность от CPU, а наоборот. Но менее 80MHz не поставить, по массе причин.
     
    Последнее редактирование: 15 фев 2015
  3. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Интересно, спасибо за информацию.
    Прескейлер для SPI в этом случае, естественно, придется тоже увеличить в два раза.
    А 160 - это максимум, на который способен кристалл?
     
  4. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.397
    Симпатии:
    1.271
    160 номинал.
     
  5. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Т.е. если в момент, когда частота ядра 80, SPI-делитель сконфигурировать так, чтобы SPI тактировался на 10 (т.е. делитель 8), а потом выставить частоту ядра 160, то частота SPI все равно останется 10? Я так параноидально переспрашиваю, потому что мне это кажется странным. Точнее интуитивно некорректным кажется утверждение "на периферию это не влияет". Одно дело периферия, частота которой явно не конфигурируется, понятно, что ответственность по поддержанию ее работоспособности не лежит на плечах программиста, ведь он даже не знает как тактовая частота ядра влияет на такую периферию. Другое дело периферия, такт которой явно задается программистом как частота ядра, поделенная на заданный программистом коэффициент. В этой ситуации как реализовать парадигму "IO не зависит от частоты ядра"? Автоматически менять делитель?
     
  6. Andy Korg

    Andy Korg Moderator Команда форума

    Сообщения:
    413
    Симпатии:
    74
    Для переферии свои шины со своими источниками тактов, если мне склероз не изменяет (вроде как шина AHB)
     
  7. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    На самом деле единственный практический вопрос - что фиксируется в момент выставления делителя частоты - делитель или посчитанная на его основе частота.
    Если первое, то прыжок к частоте 160 ядра приведет к увеличению частоты SPI. Если второе - то ничего не произойдет.
     
  8. Andy Korg

    Andy Korg Moderator Команда форума

    Сообщения:
    413
    Симпатии:
    74
    Не важно, т.к. CPU тактируется от своего источника, а SPI от своего. И они никак не связаны. Или я чего-то не допонял.
     
  9. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Не понятно в таком случае вот что: почему бы не дать тогда просто выставить частоту SPI напрямую? Он-то ведь выставляется делителем относительно частоты ядра. Зачем такие экзорцизы, если тактовые генераторы независимы? Зачем связывать их тогда фиктивным делителем?
     
  10. Andy Korg

    Andy Korg Moderator Команда форума

    Сообщения:
    413
    Симпатии:
    74
    Не ядра, а частоты тактового генератора 80МГц.
     
  11. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Ну это сути-то вопроса не меняет, если тактовые генераторы независимы, зачем программный API устроен так, чтобы задавать соотношение между ними. Почему бы не дать возможность просто задавать частоту такта для SPI?
     
  12. Andy Korg

    Andy Korg Moderator Команда форума

    Сообщения:
    413
    Симпатии:
    74
    Оно и независимо.
    Выглядит это так

    тактовый генератор (80 МГц) -->> делитель для SPI -- >> блок SPI
    |
    +---->> делитель для CPU --->> CPU
    Подробнее можно прочитать тута
     
  13. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Я когда я выставляю частоту ядра 160, я что делаю - конфигурирую тактовый генератор или выставляю делитель для ядра в 0.5?

    Если второе, тогда все понятно.
     
  14. Andy Korg

    Andy Korg Moderator Команда форума

    Сообщения:
    413
    Симпатии:
    74
    второе
     
  15. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    8.397
    Симпатии:
    1.271
    REG_SET_BIT(0x3ff00014, BIT(0)); // меняет мультиплексор - переключает только шину тактирования ядра CPU к внутреннему делителю от общей PLL на выход 160MHz или 80MHz
    os_update_cpu_frequency(160); // = ets_update_cpu_frequency(x) и запоминает значение x в памяти 0x3fffc704, чтобы отдать его по ets_get_cpu_frequency() и является чисто информационной, т.к. регистр переключения частоты шин CPU в 0x3ff00014 не читается (аппаратно не сделано его отображение - только установка/запись).
    Все остальное у данного чипа работает со своими делителями от общей PLL.
    I/O порты тактируются с периодом в 75ns (быстрее их не переключить), а SPI от своей тактовой, как и всё остальное.
     
    Последнее редактирование: 17 фев 2015
  16. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Спасибо, теперь кристально ясно.
     
  17. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Пришли железки. Получил первый рабочий вариант своей библиотеки для ILI9341. Удалось достичь примерно чуть более чем двухкратного увеличения pixel rate по сравнению с кодом уважаемого perfer. В основном за счет аппаратного управления CS (на выводе MTDO) и чуть более заточенной организации функций (минимальный набор параметров во всех функциях, однократное конфигурирование SPI только на передачу).
    Заметил, что у трансфера по SPI есть какая-то странная дыра после передачи (ну или перед, не принципиально).
    Вот код, который стреляет двухбайтными 0xFFFF в SPI:
    Код (Text):
    1.     *spi_fifo = 0xFFFF;
    2.     uint32_t bitcount = 2 * 8 - 1;
    3.     WRITE_PERI_REG(SPI_FLASH_USER1(HSPI), (bitcount & SPI_USR_OUT_BITLEN) << SPI_USR_OUT_BITLEN_S);
    4.     for (int i = 0; i < 100; i++)
    5.     {
    6.         SET_PERI_REG_MASK(SPI_FLASH_CMD(HSPI), SPI_FLASH_USR);
    7.     }
    8.  
    На выводах получаем вот что:
    [​IMG]
    Интересно, чем обусловлены паузы между передачами, которые съедают 30% пропускной способности?
     
    parallelno111 нравится это.
  18. Perfer

    Perfer Новичок

    Сообщения:
    27
    Симпатии:
    3
    Уважаемый Sermus, поздравляю Вас с получением "железок", а также с Вашим даром находить упущения в коде и исправлять их!
    Расскажите нам всем, как вы смогли догадаться до аппаратного управления CS? Это немыслимо великолепный ход!
    Меня, да я думаю и не только меня, захватывают Ваши достижения в части эффективнейшего использования памяти контроллера и непрерывного требования от последнего передачи Ваших данных по SPI. Это немыслимо круто!
    Овации в честь Sermus :D
     
  19. Sermus

    Sermus Читатель

    Сообщения:
    110
    Симпатии:
    15
    Ну как догадался? Мозгом подумал.
    Очень жаль, что Вы восприняли мой пост как уничижение Ваших достижений, он таким ни в коей мере не был. Я крайне благодарен Вам за этот код, потому что он послужил хорошей стартовой площадкой для моих экспериментов.
    Уж очень толстый сарказм, лучше б помогли.
     
  20. Perfer

    Perfer Новичок

    Сообщения:
    27
    Симпатии:
    3
    А если без тролинга:
    1) попробуйте не долбить HSPI постоянным выставлением бита на передачу и ждать окончания отправки содержимого буфера, хоть в начале хоть в конце.
    2) проведите измерения на передачи двух двухбайтных сообщений, так будет чуть понятнее
    3) если вам так нужна сверх производительность может стоит взглянуть на дизасемблировааный код?! Как это сделать я не знаю, думаю pvvx может подсказать
     

Поделиться этой страницей