Я работаю над проектом, в котором я использую программу Nodejs с Node Serialport для отправки данных изображения через USB в пользовательский клон Maple Mini, а Maple Mini Clone использует библиотеку ADAFRIT_ILI9341_STM, чтобы написать данные изображения на экране TFT. Он отлично работает, за исключением того, что мне нужно замедлить его, чтобы заставить его работать.

По сути, то, что я делаю, - это посылание каждого 16 -битного пикселя на 2 байта. Клен считывает два байта и объединяет их в UINT16_T и устанавливает цвет пикселя, используя ADAFRIT_ILI9341_STM и Adafruit GFX LIB с передачей DMA. Если я добавлю задержку 200 микросекунд после каждого набора пикселей, она работает отлично, просто медленнее, чем ID, как. Если я уменьшаю задержку или удаляю ее полностью, это как бы работает. Похоже, что он проходит все данные, но пропускает много байтов. Все изображения искажены, но он делает этот процесс очень быстро. Мне нравится скорость, но не сброшенные биты.

Поэтому я копаюсь в этом, но прежде чем заглянуть слишком далеко, я хотел посмотреть, есть ли у кого -нибудь какие -либо идеи. Я думаю, что передача USB работает нормально, в противном случае он переполнится хуже, когда я замедляю его. (Я могу ошибаться). Я предполагаю, что проблема в передаче DMA. Я не на 100% уверен, как работает передача DMA, но я понимаю, что вы в основном сбрасываете байты для переноса в область памяти (буфер), а микроконтроллер передает его на «фоне». Это правильно? Если это так, я предполагаю, что область памяти или буфер, поскольку передача DMA переполняет байты через UBS, чтобы заблудиться или перезаписан в буфере.

Я почесал голову на это несколько дней. Любая помощь или идеи будут оценены.

ОБНОВЛЯТЬ

Я сделал программу, чтобы продемонстрировать проблему.
https: // github.com/jaretburkett/arduino ... age_loader

Я думаю, что вам сначала нужно изолировать проблему, выяснив, находится ли она на Usserial Side или на стороне SPI.
Может быть, вы можете распечатать на последовательном порту количество полученных данных, с добавленными задержками и без них.
Если это то же самое, то проблема, скорее всего, со стороны SPI.
Если нет, возможно, USBERIAL теряет некоторые полученные байты.
В таком случае, возможно, вы можете добавить протокол по сбору ручной работы в свой перевод, даже может быть, проверка CRC.

Спасибо, Мартинайотт. Я провел несколько тестов. Я получаю правильное количество байтов от USB на полной скорости. Он также записывает правильное количество байтов на экране TFT (изображение - правильный размер).

Вот что происходит, когда я запускаю его с 200 микросекундной задержкой между Pixel Wrises.



И вот что происходит, когда я запускаю его без задержки.



Как видите, он, кажется, получает все пиксели. Некоторые из 16 -битных кодов имеют перевернутые MSB и LSB, а группы пикселей находятся не в том пространстве, но в конце. Это точно правильное количество байтов для полного изображения. Я как раз собирался сказать, что это похоже на стек вызовов, как в JavaScript, звонки ставят в неправильный заказ. Что ж, я использую Nodeserial от JavaScript, чтобы подтолкнуть изображения к кленку, поэтому я думаю, что это может быть проблем Эта проблема. Я не исключаю это, но это не первое место, чтобы выглядеть, так как изменения, чтобы она работала, все сделаны на клене, а не на скрипте Nodejss. Любые идеи?

В другом проекте у меня были аналогичные проблемы с большим количеством байтов, отправленных синей таблеткой на ПК.
Проблема, скорее всего, вызвана переполнением USB Serial TX, хотя количество отправленных байтов, как и в вашем случае, было правильным.
Как предположил Мартинайотт, рукопожатие помогло.

Вы, вероятно, могли бы изменить ядро, чтобы выделить больше байтов в USB -серийный буфер, которого может быть достаточно, чтобы написать пиксели с одним экраном, стоимостью которых без каких -либо задержек

Или, возможно, быстрее считываться из серийного буфера USB и реализовать буферизацию, между информационными данными USB и данными на экране.

Выполнять одно пиксель на экране очень неэффективно и медленно.

Вам может быть лучше отправить одну целую линии областей экрана, чтобы дисплей Lib Lib и делать вещи более оптимально и использовать DMA (хотя и блокируя DMA)

Rogerclark написал:Вам может быть лучше отправить одну целую линии областей экрана, чтобы дисплей Lib Lib и делать вещи более оптимально и использовать DMA (хотя и блокируя DMA)

Я не думаю, что где -то есть какое -то переполнение буфера, иначе байты были бы ошибочными.
Чтобы доказать это, возможно, вам следует попробовать отправить определенный шаблон для всей линии сканирования и проверить, разбит ли шаблон на приемной.
Если рисунок не нарушен, но все еще перевернут/поменялся на дисплее на разных линиях сканирования, это означает, что коррупция замены является передачей на ЖК -дисплей.

Вы также можете генерировать данные программатически для всего изображения, я.эн. Отправить шахтер данных на основе вывода пары для петли. Это полностью устранит USB -сторону вещей.

Ахулл написал:Вы также можете генерировать данные программатически для всего изображения, я.эн. Отправить шахтер данных на основе вывода пары для петли. Это полностью устранит USB -сторону вещей.

Вы только что попытались отправить увеличенный счетчик через USB и просто прочитали его через USB, так как было бы легко увидеть, если его падающие байты и т. Д.

Rogerclark написал:Вы только что попытались отправить увеличенный счетчик через USB и просто прочитали его через USB, так как было бы легко увидеть, если его падающие байты и т. Д.

ХОРОШО
Я не отправил много данных на устройство, я использовал их только для отправки данных на ПК
Это всегда работало нормально, хотя и идет быстрее, если вы не отправляете новеньши. Я не уверен, почему это замедляется, если вы слишком часто отправляете новую линию E.глин. Интенсивно я отправлял несколько чисел в виде текста, разделенного вкладками, чтобы я мог вставить данные в шишку

Я посылал x, y, z ускорение, а затем новая линия, но это было медленно, так что я в итоге отправил
X, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, Y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z
X, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, Y, z, x, y, z, x, y, z, x, y, z, x, y, z, x, y, z

(что было намного быстрее, хотя мне пришлось обработать данные, чтобы превратить их обратно в

X, y, z
X, y, z

Теперь я исключил, что это проблема с Node Serialport, в пределах определенной степени уверенности. То, что я сделал, было журналом консоли байтового массива для изображения. Затем я написал сценарий Python с помощью Pyserial. Я скопировал там массив байтов и отправил его с помощью Pyserial. Я получаю абсолютно идентичные результаты. Отлично работает с небольшой задержкой. Схватка без одного.

У меня также были проблемы с сериалом Nodejs от HTML и JavaScript, поэтому я наконец отказался от этого.
Вместо этого я написал свою небольшую коммунальную программу в обработке, которая, помимо прочего, отправляет и получает данные в/из Maple Mini Over Serial.
Более гибкий и, что более важно: более надежно!

Обновление: я решил попробовать тот же набросок с Teensy. Это работает безупречно на полной скорости. Сначала я собираюсь проверить, как Teensy использует библиотеку ILI9341 и редактировать ее, если это необходимо. Если это не проблема, я собираюсь посмотреть на перенос подросткового CDC в STM32 или, по крайней мере, некоторые из них. Я действительно надеюсь, что проблема заключается в LIB ILI9341, потому что переписывание CDC станет гораздо большим проектом, и я знаю, что многие люди не захотят вносить такую ​​значительную модификацию ядра в репозитории, понятно.

Если проблема заключается в CDC, вы можете ждать, пока Vassilis завершит добавление CDC в новое ядро ​​STM, поскольку это использует официальный CDC STM
Или вы можете помочь Vasasilis заставить CDC работать

Rogerclark написал:Если проблема заключается в CDC, вы можете ждать, пока Vassilis завершит добавление CDC в новое ядро ​​STM, поскольку это использует официальный CDC STM
Или вы можете помочь Vasasilis заставить CDC работать

Я так не думаю.

Попробуйте писать ему

Можно попробовать увеличить размер серийного буфера USB RX на Maple Mini.
Причина: сериал Nodejs может отправлять байты в виде пары байтов, но они будут сначала сгруппированы в большую упаковку серийным драйвером, а затем отправлены.
Это означает, что с ПК всегда есть более 2 байтов. Если буфер меньше этого номера байта, произойдет переполнение, хотя количество байтов может быть правильным.

Стивестронг написал:Можно попробовать увеличить размер серийного буфера USB RX на Maple Mini.
Причина: сериал Nodejs может отправлять байты в виде пары байтов, но они будут сначала сгруппированы в большую упаковку серийным драйвером, а затем отправлены.
Это означает, что с ПК всегда есть более 2 байтов. Если буфер меньше этого номера байта, произойдет переполнение, хотя количество байтов может быть правильным.

Если бы вы могли поделиться кодом для синей таблетки и какого-то инструмента для ПК, как воспроизводить, я был бы рад дважды проверить.

Есть тонна кода с обеих сторон. Загрузка изображения - это крошечная часть, но я могу сбрасывать полный проект загрузки изображения TFT Code/Arduino TFT. Дайте мне несколько часов, и я отправлю обратно по ссылке.

Вот ссылка на быструю программу, которую я взбил. Это простой загрузчик изображения. Он должен открыть программу с разделом изображения и кнопкой просмотра. Он ищет последовательный порт STM32 на основе VID PID. В верхней части есть круг, который становится зеленым при подключении, а окно изображения автоматически регулируется. Вам нужно будет иметь Nodejs. Инструкции на readme. В настоящее время установлен с задержкой. Информация об удалении задержки находится в Readme. Вы можете удалить его и добавить, чтобы попробовать оба, чтобы увидеть, о чем я говорю.

https: // github.com/jaretburkett/arduino ... age_loader

Дайте мне знать, если у вас есть проблема с установкой. Я могу пройти тебя через это. Должен работать над Mac, Win, Linux. Linux, вам нужны правила Maple Udev, но вы, вероятно, уже сделали это, если вы используете там Arduino.

РЕДАКТИРОВАТЬ: Я использую свой пользовательский порт Adafruitili9341, но он должен работать с тем, что в репо STM32Duino также также. Я только что запускаю обновленную версию. Он также должен работать с любым комбинацией экрана TFT/LIB, который использует Adafruit GFX LIB.

Ну, я не друг Linux, поэтому я не мог использовать вашу среду.
Мне пришлось внедрить инструмент для ПК для Windows и приложение Blue Pill.
На стороне STM32 есть интерпретатор команды, который получает команды через USB -сериал для обработки дисплея, управляемого Adafruit Lib (8 -битный параллель), адаптированный к STM32 (опубликовано в одном потоке).
На стороне ПК есть эскиз на основе обработки, который генерирует некоторые из этих команд.
Итак, я открываю картинку с обработкой и отправляю данные Pixel на таблетку.
В своем тесте я преобразовал картинку в серого, чтобы отправить только один байт на пиксель. Тем не менее, эти байты были отправлены один за другим без каких -либо задержек, буферизации на стороне обработки, просто прочитайте из пиксельного буфера изображения и отправьте его непосредственно в серийный порт.
Таблетка получает байты, преобразует их один за другим (как получен) в формат Color565 (два байта) и записывает их на дисплей, используя функцию pushColors ().

Результаты:
Я попробовал два решения.
1. 100x100 пикселей (байты) отправлены менее чем на 1 секунду, все пиксели отображаются правильно.
2. 240x320 пикселей (байты) отправлены менее чем на 7 секунд, все пиксели отображаются правильно.

Я запускал тесты несколько раз, каждый раз без какого -либо неуместного пикселя.
Как видите, я не мог воспроизвести вашу проблему.

Теперь, когда я сравниваю свой комментарий и вашу информацию, я понял, что проблема моей эндсианты полученных данных.
В вашем случае это случилось, что на стороне ПК байты собираются и передаются серийным драйвером USB в пакетах, состоящих из нескольких байтов.
Но количество байтов в пакете может варьироваться. Если это странно, эндянса полученных и обработанных байтов может быть нарушена...

Я проверю свое приложение, чтобы отправить данные Pixel в формате Color565 (два байта на пиксель).
В качестве альтернативы, вы также можете попытаться отправить данные Pixel в формате серого (1 байт на пиксель) и преобразовать их с помощью чипа STM32.

Стивестронг написал:Теперь, когда я сравниваю свой комментарий и вашу информацию, я понял, что проблема моей эндсианты полученных данных.
В вашем случае это случилось, что на стороне ПК байты собираются и передаются серийным драйвером USB в пакетах, состоящих из нескольких байтов.
Но количество байтов в пакете может варьироваться. Если это странно, эндянса полученных и обработанных байтов может быть нарушена...

Я проверю свое приложение, чтобы отправить данные Pixel в формате Color565 (два байта на пиксель).
В качестве альтернативы, вы также можете попытаться отправить данные Pixel в формате серого (1 байт на пиксель) и преобразовать их с помощью чипа STM32.

Стивестронг написал:Ну, я не друг Linux, поэтому я не мог использовать вашу среду.
Мне пришлось внедрить инструмент для ПК для Windows и приложение Blue Pill.

А .EXE работает, открывает изображение, ЖК -дисплей отображает черный фон, показывающий «ожидание изображения от USB», но потом больше ничего не происходит.
Погрузчик изображения показывает красный заполненный круг в верхней части изображения (отключен?).
Что я должен делать?

Стивестронг написал:А .EXE работает, открывает изображение, ЖК -дисплей отображает черный фон, показывающий «ожидание изображения от USB», но потом больше ничего не происходит.
Погрузчик изображения показывает красный заполненный круг в верхней части изображения (отключен?).
Что я должен делать?

Хорошо, вам просто нужны повышенные разрешения по какой -то причине. Я работаю над исправлением, но сейчас вы можете запустить программу в качестве администратора.

Хорошо, я перезапустил компьютер, и сейчас, кажется, работает.
Я вижу ошибки спорадической группы пикселей, как и у вас. В одной строке последовательно ~ 20 пикселей неверны.
В моем случае ошибка существует, хотя задержка все еще активна.

РЕДАКТИРОВАТЬ
HM, это работало только для одного сеанса. Я удалил задержку, и теперь, если я закрою погрузчик, в следующем старте кружок на секунду станет зеленым, то он поворачивается и остается красным.
TFT обнаруживает соединение, а фон поворачивается и остается черным. Но передача данных не происходит.

Теперь я изменю свое программное обеспечение, чтобы проверить 2 -байт/пиксельную версию.

Редактировать 2
Цикл питания (перейдите в режим ожидания и просыпайтесь) и перезагрузка погрузчика помогает погрузчику оставаться зеленым.
С удаленной задержкой изображение загружается за секунду! УХ ТЫ! Но, к сожалению, полностью искаженно ...

Спасибо за все усилия. Я очень ценю это. И извините, моя программа все еще багги, я просто очень быстро сбросил ее, чтобы продемонстрировать проблему. Я наталкивал обновление, чтобы вам не пришлось каждый раз перенаправлять изображение. Я только что обновил релиз. У меня нет необходимости перезагрузить проблему, поэтому я не уверен, как это исправить. Любая идея, что здесь может быть гонгом? Похоже, внизу есть некоторые пустые пиксели, но это не просто пиксель или два. Это целая линия (около 20 px), которая, кажется, перемещается и искажает весь процесс.

Примат писал:Похоже, внизу есть некоторые пустые пиксели, но это не просто пиксель или два. Это целая линия (около 20 px), которая, кажется, перемещается и искажает весь процесс.

Примат писал:Стивестронг написал:Теперь, когда я сравниваю свой комментарий и вашу информацию, я понял, что проблема моей эндсианты полученных данных.
В вашем случае это случилось, что на стороне ПК байты собираются и передаются серийным драйвером USB в пакетах, состоящих из нескольких байтов.
Но количество байтов в пакете может варьироваться. Если это странно, эндянса полученных и обработанных байтов может быть нарушена...

Я проверю свое приложение, чтобы отправить данные Pixel в формате Color565 (два байта на пиксель).
В качестве альтернативы, вы также можете попытаться отправить данные Pixel в формате серого (1 байт на пиксель) и преобразовать их с помощью чипа STM32.

Я немного посмотрел на приложение Loader, кажется, что оно последовательно пытается открыть COM4, ​​и, конечно, оно терпит неудачу со второго раза, так как он был открыт в первый раз. Вот почему я вижу круг в зеленом.
Я добавил линию журнала консоли в основном.JS Line 70 до if (!attached) {

Хорошо, я думаю, я нашел ошибку.
В своем эскизе для STM32 вы читаете два последовательных байта из серийного, но вы не проверяете, доступен ли серийный байт или нет.
Итак, что происходит, так это то, что вы читаете недействительные байты, образуя сериал.
Если вы вставляете задержку, за это время станут доступны новые байты, так что даже если вы не проверяете доступность, байты, скорее всего, доступны, готовы к чтению.
Я изменил ваш код:
for (uint16_t y = 0; y < tft.height(); y++) { for (uint16_t x = 0; x < tft.width(); x++) { while ( Serial.available()<=0 ); // wait till byte is available b1 = Serial.read(); // MSB while ( Serial.available()<=0 ); // wait till byte is available b2 = Serial.read(); // LSB // combine bytes to a 16 bit uint16_t pixColor = b1 << 8 | b2; tft.drawPixel(x, y, pixColor);

Я думаю, я знаю, что происходит. У меня есть сканирование в интервале. Таким образом, это заставляет другое сканирование перед завершением вашего сканирования, если это займет больше времени, чем секунду, а затем чертовски разрывается. Я только что подтолкнул новый релиз и обновил репо, поэтому он установил сканирование тайм -аута после того, как оно будет сделано сканировать. Должен решить вашу проблему. Извините за это. Это старая проблема программиста "ну, это работает в моей системе" ха -ха -ха. Я ценю, что вы разрабатываете ошибки в моем дерьмовом приложении для загрузки, чтобы вы могли увидеть проблему.

Стивестронг написал:Хорошо, я думаю, я нашел ошибку.
В своем эскизе для STM32 вы читаете два последовательных байта из серийного, но вы не проверяете, доступен ли серийный байт или нет.
Итак, что происходит, так это то, что вы читаете недействительные байты, образуя сериал.
Если вы вставляете задержку, за это время станут доступны новые байты, так что даже если вы не проверяете доступность, байты, скорее всего, доступны, готовы к чтению.
Я изменил ваш код:
for (uint16_t y = 0; y < tft.height(); y++) { for (uint16_t x = 0; x < tft.width(); x++) { while ( Serial.available()<=0 ); // wait till byte is available b1 = Serial.read(); // MSB while ( Serial.available()<=0 ); // wait till byte is available b2 = Serial.read(); // LSB // combine bytes to a 16 bit uint16_t pixColor = b1 << 8 | b2; tft.drawPixel(x, y, pixColor);

Примат писал:Так что это сработало для вас без задержки?

Я проверил обновление, к сожалению, все еще пытается открыть дважды серийный порт:
main.js:76 Device Found: main.js:77 {"comName":"COM4","manufacturer":"Microsoft","pnpId":"USB\\VID_1EAF&PID_0004\\6&7F0CE88&0&2"} main.js:76 Device Found: main.js:77 {"comName":"COM4","manufacturer":"Microsoft","pnpId":"USB\\VID_1EAF&PID_0004\\6&7F0CE88&0&2"} main.js:89 Error: Error {message: "Opening COM4: Access denied"} main.js:90 Device Error

Если вы скажете, что с Teensy он работал без промедления и без проверки сериала, это означает, что STM32 USBCDC намного медленнее, чем Teensy USBCDC.

Я решил переключить булавку в TFT Pixel, напишите, чтобы увидеть, как часто это называется.
Что ж, используя мой инструмент обработки, данные написаны равномерно распределены вовремя. В первых 11..12 мс. Среднее распределение импульсов было на каждые 400 микросек, впоследствии оно было на каждые ~ 150 микросек. Это объясняет, почему ваша задержка (150microsecs !) заставило работу работать, не теряя байтов.

Теперь вопрос: почему серийный прием USB подростков быстрее, чем это?

В том же контексте скорость загрузки DFU для STM32 также кажется намного выше, чем эта.

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

Я ПОНЯЛ. Но это идет с проблемой. Мне пришлось изменить 2 строки в USB_CDCACM.c Файл. Я сейчас пишу весь экран примерно через 1 секунду. Две изменились в 2 места в 2 местах.


В функциях
** РЕДАКТИРОВАТЬ, Перечислено Имя неправильной функции ** uint32 usb_cdcacm_rx(uint8* buf, uint32 len) {

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

Стивестронг написал:Попробую это изменение сегодня позже.
Примат писал: Простая работа вокруг - это петля для сериала, недоступная. Но если вы не поставите его на быстрое чтение, вы будете скучать по байтам.

Я пытаюсь загрузить изображения на вспышку (SST26) через последовательный порт, используя (модифицированный) Serialflash и сценарий Python, включенный в дополнения, но я также столкнулся с некоторыми потерями данных.

После некоторой проб и ошибок я наконец решил создать эскиз и скрипт Python, чтобы проверить серийное соединение.
Я пытаюсь отправлять 4000 байтов за раз в STM32, но я получаю только 39xx большую часть времени.
Пытался установить скорость передачи бодов на более низкую скорость (115200), но проблема сохраняется.
Может, я попробую исправление кода USB CDC, опубликованное здесь...

serial_python_test_stm32.Ино

(7.83 киб) скачано 160 раз

Рекснанет написал:Я пытаюсь загрузить изображения на вспышку (SST26) через последовательный порт, используя (модифицированный) Serialflash и сценарий Python, включенный в дополнения, но я также столкнулся с некоторыми потерями данных.

После некоторой проб и ошибок я наконец решил создать эскиз и скрипт Python, чтобы проверить серийное соединение.
Я пытаюсь отправлять 4000 байтов за раз в STM32, но я получаю только 39xx большую часть времени.
Пытался установить скорость передачи бодов на более низкую скорость (115200), но проблема сохраняется.
Может, я попробую исправление кода USB CDC, опубликованное здесь...
serial_python_test_stm32.Ино

У меня сейчас нет проблем со вспышкой. Я получил поддержку и протестировал это, и он работает нормально.
Дисплей также работает нормально, нет проблем.
Так что я не буду и начал видеть, правильно ли информация прибыла к STM32.

Мне пришлось изменить исходный код из rawfile_uploader.PY, потому что то, как он обрабатывал «побег» байты, которые изменили бы некоторые байты и «повреждены» изображение. Я изменил «условие конечного цикла», чтобы получить количество байтов, соответствующих размеру файла вместо этого.

Но я не получил полный размер файла на STM32, хотя сценарий Python сказал, что отправил их все.

Поэтому я сделал этот небольшой тест и обнаружил, что где -то есть проблема на пути серийного общения.

Хорошо, спасибо за помощь.

Похоже, та часть кода, которую вы изменили, была совершена 25 января 2015 года в репо.
https: // github.com/rogerclarkmelbourne/ ... 85BC2A5C07
Я не понимаю, почему этот коммит был необходим, какая проблема была решена через это.

Стивестронг написал:Похоже, та часть кода, которую вы изменили, была совершена 25 января 2015 года в репо.
https: // github.com/rogerclarkmelbourne/ ... 85BC2A5C07
Я не понимаю, почему этот коммит был необходим, какая проблема была решена через это.

Я могу признать: применение предлагаемого изменения, скорость передачи данных USB Serial RX значительно увеличилась.

Журнал консоли от обработки:
Serial port COM4, 115200, 8, 'N', 1 opened successfully. W240; H320; W240; H320; > sending 76800 image pixels ... filling buffer with pixel data...(153600 bytes in 46 millis) done. sending buffer ...(1079 millis) done. > image transmission done.

Примат писал:
В функциях uint16 usb_cdcacm_get_pending(void) {

Стивестронг написал:Я могу признать: применение предлагаемого изменения, скорость передачи данных USB Serial RX значительно увеличилась.

Я прикрепил использованные источники.

Файл INO должен быть адаптирован к использованной библиотеке TFT.

Обработка наброска PD. Вы должны нажать на него и нажать два раза "0" (ноль) (проверьте окно консоли).
Затем нажмите «S» для передачи изображения в таблетку.

Я буду действовать позже.

КСТАТИ.

Возможно, стоит связаться с Тимом, который сделал PR, который представил проблему, так как он, возможно, помнит, какая ошибка была исправлена.

Вероятно, на форуме была ветка об этом, возможно, кто -то мог искать по сообщениям Тима, чтобы увидеть, проливает ли он свет на вещи.

Роджер, я могу найти только эту ветку:
http: // форум.Ардуино.CC/INDEX.PHP?Тема = 265904.1200
Но я не мог определить проблему позади.

Кроме того, я не могу найти (открытый или закрытый) пиар, связанный с этим.

Стив

Я подозреваю, что мне пришлось вручную объединить файлы Тима.

Я напишу ему в личку через форум Arduino, так как я не знаю, зарегистрировался ли Тим на этом форуме. (Он определенно не активен сейчас)

«Исправление» не повлияло на мою установку

Удивительно, но USB кажется меньшей задержкой между блок -трансферами.
Если я засыпаю (на стороне питона) 0.1sec между 128 байтскими кадрами (чтобы дать время для сохранения данных для вспышки, когда он достигает 4Kbytes) Передача данных висит после нескольких блоков (всего около 2 тыс. Но если я отправлю их все вместе (только отпечаток между ними), он достигнет 152 тыс. (Только на несколько сотен меньше, чем 153600 байт размера изображения).
Все еще некоторые байты отсутствуют... И я не знаю, что и почему с этой настройкой.


@stevestrong Спасибо! Я посмотрю на это

Похоже, Тим не опубликовал на Arduino.CC более года.

Я не могу вспомнить, есть ли у него учетная запись, так как людям не нужно давать свои настоящие имена. Все, что я могу получить, это добавление электронной почты, и часто люди используют загадочные адреса Gmail

В любом случае, он может ответить на мой PM на Arduino.скандал

Рекснанет написал:«Исправление» не повлияло на мою установку

Удивительно, но USB кажется меньшей задержкой между блок -трансферами.
Если я засыпаю (на стороне питона) 0.1sec между 128 байтскими кадрами (чтобы дать время для сохранения данных для вспышки, когда он достигает 4Kbytes) Передача данных висит после нескольких блоков (всего около 2 тыс. Но если я отправлю их все вместе (только отпечаток между ними), он достигнет 152 тыс. (Только на несколько сотен меньше, чем 153600 байт размера изображения).
Все еще некоторые байты отсутствуют... И я не знаю, что и почему с этой настройкой.


@stevestrong Спасибо! Я посмотрю на это

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

Я изменяю код, чтобы читать по одному байту за раз и посмотреть, изменится ли что -то.

Я не верю в это!!!!!!!!!!!!!!!!!!!!!!!!!!!

uint16_t available = Serial.readBytes(usbBuffer, USB_BUFFER_SIZE);

Хорошо выглядит

КСТАТИ.

Вы, ребята, используете DMA на дисплее?

Я знаю, что это в настоящее время блокирует, но было бы относительно легко (я надеюсь) добавлять не блокирующий DMA, так что, если вы можете отправить как минимум 1 строку в время на дисплей, он будет значительно быстрее, чем не DMA

Даже блокирование DMA быстрее, потому что он не тратя время (строки кода C), проверяя рег Status SPI

Rogerclark написал:Хорошо выглядит

КСТАТИ.

Вы, ребята, используете DMA на дисплее?

Я знаю, что это в настоящее время блокирует, но было бы относительно легко (я надеюсь) добавлять не блокирующий DMA, так что, если вы можете отправить как минимум 1 строку в время на дисплей, он будет значительно быстрее, чем не DMA

Даже блокирование DMA быстрее, потому что он не тратя время (строки кода C), проверяя рег Status SPI

Написание людей имеет огромные накладные расходы, потому что из того, что я помню, x, y каждого пикселя необходимо перенести на дисплей, за которым следует данные пикселя (цвет).

Код вовсе не оптимизирован и, помимо необходимости отправлять, вероятно, в 3 раза больше данных, чем необходимо на дисплей, код также будет иметь несколько накладных расходов на вызов и т. Д.

Я определенно рекомендую вам посылать целые линии как минимум, и если у вас достаточно оперативной памяти, отправьте несколько строк (хотя это будет уменьшать доходность при увеличении количества строк).

Я использую Adafruit_tftlcd_stm32 lib, работает с 8 -битным параллельным.
Конечно, можно оптимизировать код для записи данных для быстрее отображения.
Но дело в, USB Fix работает!

Rogerclark написал:Хорошо выглядит

КСТАТИ.

Вы, ребята, используете DMA на дисплее?

Я знаю, что это в настоящее время блокирует, но было бы относительно легко (я надеюсь) добавлять не блокирующий DMA, так что, если вы можете отправить как минимум 1 строку в время на дисплей, он будет значительно быстрее, чем не DMA

Даже блокирование DMA быстрее, потому что он не тратя время (строки кода C), проверяя рег Status SPI

Рекснанет написал: Но, что касается исправления USB, для меня это не повлияло на результаты. Даже когда я читал весь буфер за раз. Может быть, сценарий Python медленнее, чем код обработки, и я не вижу этой проблемы...?
С Python я получил около 30 КБ/с. Это равняется максимуму. Скорость бодского производства 250000bps, которые я вижу на раскрывающихся вариантах, поэтому должен быть довольно близко к полной серийной скорости USB...

Стивестронг написал: Вы используете файл ino, который я разместил ранее?

@Rexnanet,
Можете ли вы сказать, что исправление оказывает (любое) влияние на вашу систему?
Пожалуйста, обратите внимание на отправлять Данные в больших блоках. Может ли сценарий Python Отправить данные в больших блоках?

Кстати, INO происходит от @primateio, я только что добавил ожидание сериала, доступное до сериала, чтение байта.
Рекснанет написал: uint16_t available = Serial.readBytes(usbBuffer, USB_BUFFER_SIZE);

Стивестронг написал:@Rexnanet,
Можете ли вы сказать, что исправление оказывает (любое) влияние на вашу систему?
Пожалуйста, обратите внимание на отправлять Данные в больших блоках. Может ли сценарий Python Отправить данные в больших блоках?

Кстати, INO происходит от @primateio, я только что добавил ожидание сериала, доступное до сериала, чтение байта.
Рекснанет написал: uint16_t available = Serial.readBytes(usbBuffer, USB_BUFFER_SIZE);

Стивестронг написал:@Rexnanet,
Можете ли вы сказать, что исправление оказывает (любое) влияние на вашу систему?
Пожалуйста, обратите внимание на отправлять Данные в больших блоках. Может ли сценарий Python Отправить данные в больших блоках?

Кстати, INO происходит от @primateio, я только что добавил ожидание сериала, доступное до сериала, чтение байта.

Хм, я должен проверить это.

В качестве альтернативы, вы можете попытаться использовать функцию: Serial.read(void *buf, uint32 len);

Рекснанет написал: С потерей данных: //We assume the serial receive part is finished when we have not received something for 3 seconds while(Serial.available() || (lastReceiveTime + 10000 > millis()) ){ uint16_t available = Serial.readBytes(usbBuffer, USB_BUFFER_SIZE); if (available){ lastReceiveTime = millis(); } Serial2.print("available:"); Serial2.println(available); for (uint16_t usbBufferIndex = 0; usbBufferIndex < available; usbBufferIndex++){ uint8_t b = usbBuffer[usbBufferIndex]; ...

Стивестронг написал: В качестве альтернативы, вы можете попытаться использовать функцию: Serial.read(void *buf, uint32 len);

Рекснанет написал: @primateio ok, но разве это не обработано "доступным"? Если бы я получил только 1 байт, я бы прочитал только 1 байт на «USBBuffer» и только обработаю этот байт.
А затем подождите следующие байты (ы)...

Примат писал:Рекснанет написал: @primateio ok, но разве это не обработано "доступным"? Если бы я получил только 1 байт, я бы прочитал только 1 байт на «USBBuffer» и только обработаю этот байт.
А затем подождите следующие байты (ы)...

По этой теме также есть новая разработка, а также добавлен здесь.
По сути, исправление хорошо для чтения байтов один за другим, но не для чтения нескольких байтов.
Я использовал: Serial.read(usbBuf, 60);

Я бы подумал, что проблема будет в серийном чтении в буферной функции. Поскольку все, что он делает, это читать по одному байту за раз в буфер, я посмотрю на него.

Как информация, я опубликовал здесь Новая версия серийного файла USB, где я также добавил функциональность Buffered TX.

Ошибка произошла из-за условия гонки с прерыванием NVIC_USB_LP_CAN_RX0, которое произошло только во время передачи с высокой пропускной способностью.

Это исправлено в:
https: // github.com/rogerclarkmelbourne/ ... 6FABB3092C

Я опубликовал пиар.

TX-Buffer Work от Stevestrong кажется хорошей идеей, но я думаю, что мое исправление RX-Buffer-это путь. Комментарии приветствуются.

С уважением
Расмус Фрис Кьелдсен