Jump to content

    

AlanDrakes

Участник
  • Content Count

    130
  • Joined

  • Last visited

Community Reputation

0 Обычный

About AlanDrakes

  • Rank
    Частый гость
  • Birthday 01/31/1988

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1439 profile views
  1. Вам не нужно гнаться за частотой кадров. Рекомендую наоборот - использовать аппаратный таймер, который будет запускать процесс копирования данных из буфера экрана в буфер дисплея. И лучше использовать частоту не очень близкую к частоте обновления дисплея. В прошлой ссылке есть на эту тему информация. Так же рекомендую пролистать даташит на сам контроллер ЖК панели, применённый в дисплее. Как увеличить его частоту обновления я писал. У себя не стал заморачиваться с эффектами из-за ограниченной памяти (кроме экрана требуется ещё много чего), потому отрисовка идёт через Chrome-ART ускоритель с преобразованием из "сжатых" пикселей (indx-16) в RGB-16. Картинка имеет максимум 16 цветов, зато скорость отрисовки радует. А эффекты... ну лично мне они не особо нужны в проекте.
  2. Либо можете на стороне контроллера рендерить картинку с расчётом смещения стрелки, следом, прозрачностью и прочим, и уже готовое изображение выводить на дисплей. Да, это затратно по ресурсам, да это медленно, да требует память под буфер, но зато будет отображаться на всех дисплеях одинаково. Так же можете попробовать повысить частоту отрисовки самого дисплея (Ссылка на обсуждение). Разве что в сообщении указано странное число. Для ILI9486L 100Гц достигается (96 или 117 на самом деле) при значениях 0xB1 = 0xD110 / 0xE110 / 0xF110 (Параграф 8.2.51 даташита). Нужно смотреть уже на месте. Но проблему мерцания это скорее всего не устранит. И я бы всё равно рекомендовал использовать отрисовку на стороне контроллера.
  3. Грубоватый вариант, но... В тот момент, когда буфер заполнен не полностью, получить прерывание HTIF, заранее вычислить значение DMAx_ChannelY->CNDTR, на котором требуется остановиться, и в цикле ожидать достижения этого значения. При совпадении - остановить DMA. Да, выглядит как костыль и является костылём :(
  4. Думаю, про простейший алгоритм действий будет таким: Проверить, был ли получен новый байт в терминале. Если не принят - вернуться к п.1. Прочитать байт из терминала Записать байт в терминал Вернуться к п.1. Profit.
  5. Посмотрите в примерах: https://github.com/stm32duino/WiFi-ISM43362-M3G-L44/tree/master/examples Хотя там по большей части работают через [WiFi].read() [WiFi].write() и тому подобные абстракции, а библиотека пусть сама разбирается.
  6. UART - подразумевает возможность наличия на одной шине нескольких местеров. Чисто технически. Если только один мастер и один ведомый, то режим Push-Pull на выходе ничего не изменит. Но если используется только одна двунаправленная линия (такое бывает, если замкнуть TX-RX и обмениваться данными по одному проводу), то этот режим может стать проблемой. Как обходной манёвр - отключать передатчик и переводить пин TX из альтернативного режима в аналоговый или вход. По третьему блоку - Да, только пункт 2.14.4. Первые три относятся к SPI модулю в режиме ведомого. Технически, в этом случае может возникать только дополнительный такт в самом конце передачи. Не целый байт, а один лишний бит. Не совсем понятно, будет ли возникать данная ошибка в случае установки максимальной частоты BR[2:0] = '000' (fPclk/2). Естественно, в этом случае частота SPI шины будет выше и не должно формироваться дополнительного строба (судя по тому, что указано только для fPclk/4).
  7. Насчёт Slackware - не подскажу, но один раз пришлось собирать avr-gcc-5.x под Ubuntu. Уж не помню зачем, но потребовалось. Собрался нормально. Нареканий к нему нет. В итоге со скрипом обновил систему и автоматом поставился какой-то более новый билд.
  8. Флеш шьётся по 16 бит за один проход. Сталкивался я с этой же проблемой, пытаясь сохранять конфигурацию в последних страницах флеша на L433. Там ровно аналогичная ситуация. Нельзя просто так взять и сбросить бит во флеше - нужно обязательно стереть страницу и писать ТОЛЬКО в чистые ячейки. Если такое поведение можно поймать в отладке - попробуйте его поймать и считайте все регистры относящиеся к Flash->xxx и страницу, которая в этот момент пишется (в том числе, тот адрес куда пишется) для проверки. Не уверен, что в F07x такие сильные отличия, но мне помогли просто дополнительные проверки на выравнивание доступа к записываемой памяти и единовременная запись WORD'ами вместо побайтной. =] А барьерчик помогает в другом месте %)
  9. На самом деле, хоть в блокноте. На RPi можно как скомпилировать приложение, так и писать его на интерпретируемых языках. Да хоть PHP, хотя там будет очень костыльно. Хотите Си? Пишите на Си. Кросс-компилятор Вам в помощь. Хотите на Питоне? Нет ничего проще. Устанавливаете питона, пишете. Перл? Тоже можно. Хотя не уверен, что там можно удобно подключиться к видео. Пример с родной камерой малинки. Кстати, на питоне: https://randomnerdtutorials.com/video-streaming-with-raspberry-pi-camera/ https://www.raspberrypi.org/forums/viewtopic.php?t=49530 Запись видео с помощью штатной утилиты. Читать можно из того же файла, либо нарезать на части и читать отдельные части. Грубо, но возможно. Технически можно писать и с нескольких камер.
  10. Если только брать нафаршированый -F7 (во всяком случае, нашёл только в нём встроеный JPEG кодер/декодер)... С внешней памятью - не всё так гладко. Нужные объёмы - это SDRAM чипы, а у них имеется латентность при переключении чтение/запись, а это лишние такты. Либо пытаться захватывать кадр во внешнюю память, затем жать во внутреннюю, писать на карту. Вот здесь есть пример по захвату аналогового видеосигнала. Картинка в итоге 320 * 240 жмётся 5мс. Грубо говоря, изображение 640 * 480 должно жаться уже около 20мс (4 раза больше чем 320 * 240). Только объём памяти требуется уже значительно больше чем у контроллера. Только внешняя. Плюс такты шины... можно получить 25-30мс на кадр. И это в лучшем случае. Получаем (без времени записи) - до 30FPS - пока всё хорошо, но запись на карту может быть очень долгой. На -F7 можно получить скорее всего лучшую производительность, сгрузив кодирование на аппаратный блок, но опять же, упираемся во внешнюю память (а она будет постоянно дёргаться то на чтение, то на запись). Плюс, полученные данные нужно успеть залить на карту памяти. У меня выходило кое-как 250кБ/с на рабочем проекте (SDIO + FatFS + RTOS). Тоже может стать узким местом, особенно если собрано с минимальным объёмом памяти. В общем, всё довольно грустно. Я бы в итоге рекомендовал Raspberry Pi Zero и уже в ней всё это делать. Там и камера есть, вторую можно напаять на USB хост. И скорость работы с картой выше. И памяти достаточно. Ну и собственно, видеокодек аппаратный.
  11. Начнём с самого простого. Чтобы записать кадр, его нужно получить, пережать в поток (либо добавить в MJPEG) и записать. С двух камер - соответсвенно, два кадра. Процесс сжатия требует минимум памяти ещё на кадр (а лучше - значительно больше для хранения прошлых кадров, чтобы вычислять дельту). Допустим, камеры совсем никакие - 640 * 480. Потребуется 921кБ памяти на RGB картинку. Ой. И это только ОДИН кадр. А нужен кадр со второй камеры - ещё 921к. Но у F4 НЕТ таких объёмов памяти, и внешняя память - не выход. Упс. Используйте Малинку и вешайте камеры на USB шину. Там памяти хватает и производительности процессора. А программу можно писать хоть на питоне.
  12. Из основной прошивки попасть в загрузчик просто. NVIC_SystemReset(); - Вылетает мгновенно (с дёрганьем пина /Reset изнутри). Гарантирует сброс всего. Не гарантирует сохранность данных. Из загрузчика в прошивку - обычным образом можно. У меня реализовано поиском прошивки (из нескольких вариантов в разных адресах) и передачей управления на неё. А дальше код сам разбирается и копирует таблицу прерываний в RAM. Естественно, переход из кода в загрузчик тоже возможен. Нужно запретить все прерывания и перейти на метку _RESET в коде. Кстати, можно аналогичным образом - подтянуть значения стэка и адрес первой инструкции.
  13. stm32 i2c

    https://www.totalphase.com/support/articles/200349176-7-bit-8-bit-and-10-bit-I2C-Slave-Addressing Конкретно изображение:
  14. Устройство не может быть ведущим. Да и не все ПК будут устанавливать что-то непонятное с подключеного USB. Но можете попробовать. В корне диска обязательно должен быть autorun.inf, ссылающайся на исполняемый файл, или .bat скрипт, который и будет устанавливать что-либо на систему. Естественно, нужно определять какая именно система на ПК. А некоторые даже этот самый волшебный файл будут игнорировать (автозапуск отключен и запрещён).
  15. OTP регион памяти в контроллере? Кажется, специально создан для чего-то подобного.