Arduino.ru

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

Ну понятно, значит в целом моя догадка верная, проблема только в деталях :) Выслал еще вариант на почту. надеюсь этот будет лучше.

ЗЫ при проверке нового варианта шаг скроллинга верните -1

Подниму тему.
ESP + STM32
https://youtu.be/d8CkC3jDkzw

Красиво!

а подробнее?

Через ESP получаю время, погоду, новости и по UART отправляю готовую строку на STM, благо аппаратных портов много и там и там. 115200 бод без ошибок передает.

Время у STM родное использую, только корректирую раз в день от ESP (получаю от NTP)

Кстати столкнулся с китайским клоном STM32, который не прошивается ST-Link

Вот решение проблемы

Thankfully I found this thread  

I replaced the set _CPUTAPID 0x1ba01477 as suggested by tsman in the ...\resources\openocd\st_scripts\target\stm32f1x.cfg file and also had to set the generator options to connection speed 4MHz and reset mode to software. Debugging is now working with STM32CubeIDE  

I'm also using Visual Studio Code with Platform IO. I had to modify the ...\.platformio\packages\tool-openocd\scripts\target\stm32f1x.cfg file to get that working.

The dodgy bluepill boards purport to have proper STM32 chips. See attached.

Т.е. заменить в файле строки

# this is the SW-DP tap id not the jtag tap id

      #set _CPUTAPID 0x1ba01477

      set _CPUTAPID 0x2ba01477

ага, эт прям напрашивается, делал что-то похожее (а точнее один в один :)

http://forum.amperka.ru/threads/%D0%A7%D0%B0%D1%81%D1%8B-%D0%BE%D1%84%D0%B8%D1%81%D0%BD%D1%8B%D0%B5-%D0%BD%D0%B0-stm32-esp-01-p10-dmd.19633/

библиотека матриц из этой темы или что-то другое?

Конечно библиотека из этой темы.

Не видел раньше тему на Амперке. Писал свою библиотеку для UART :)

Дмитрий, пока что у меня с проектом все хорошо, но стало немного неожиданным открытием, что drawString и drawMarquee не работает напрямую с классом String, только с массивами char. DMD2, с которым я работал до сих пор, работает со String без проблем.

можно поправить, хотя мне это всегда нравилось - я как-то сам недолюбливаю String, оно, если не вру, не используется ни в одном моем проекте :)

Не критично, в принципе String переводится в char без проблем прямо в аргументе функции. Мне String всегда нравился простотой работы со строками. Хотя я в курсе, что он очень любит кушать память, но пока это не критично - пусть жрет:)

Может кто-нибудь добавлял знак градуса в шрифты? Не могу найти вне в одном шрифте.

Можно самому нарисовать в редакторе

Нарисовал :) Огромная благодарность автору http://arduino.ru/forum/proekty/binfontstool-redaktor-shriftov-adafruitgfx-utft-na-ms-excel

Подскажите, плз, что означает сдвиг по вертикали?
DMD_GFX_Font FreeMono16((uint8_t*)&FreeMono16pt8b,(uint8_t*)&FreeMono16pt8b_rus, 0x80, 13);

Он одинаков для всех размеров шрифтов?

Я вообще все шрифты рисую сам, конвертированные шрифты мне не нравятся.

Лайфхак, коллега: иногда в символ я ставлю целые слова. Например тот же самый градус у меня выглядит так: "°С", а символ атмосферного давления состоит аж из трех слов, "мм (сверху) рт.(посередине) ст.(снизу)".

Это вертикальное смещение между, условно, верхней левой точкой текста и базовой линией фонта, проходящей по нижнему краю букв. Дело в том, что в библиотеке DMD базовой точкой вывода текста является левый верхний угол надписи, а фонтах Адафруит - левый нижний, поэтому при встраивании фонтов в библиотеку потребовался некий "костыль".

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

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

Спасибо, в принципе сам разобрался. Подбирается только эксперементально.

Все правильно. Утилита fontconvert дает лишь заготовку, некоторые буквы конвертируются криво, получаются неровные края, кое-где лишние пиксели, а где-то не хватает.

Сами авторы fontconvert рекомендуют после конвертации просмотреть каждую букву в ручном редакторе и поправить огрехи автомата.

Вот, кстати, о фонтах. Дмитрий, можешь просветить меня в одном вопросе?

#include <inttypes.h>
#include <avr/pgmspace.h>

#ifndef WEIGHT16_H
#define WEIGHT16_H

#define WEIGHT16_WIDTH 7
#define WEIGHT16_HEIGHT 16

static const uint8_t Weight16[] PROGMEM = {
    0x04, 0x42, // size
    0x07, // width
    0x10, // height
    0x2E, // first char
    0x0C, // char count
    
    // char widths
    0x01, 0x08, 0x06, 0x04, 0x06, 0x06, 0x06, 0x06, 0x06, 0x06, 
    0x06, 0x06, 
    
    // font data
    0x00, 0x40, // 46
    0xFA, 0x00, 0xFE, 0x02, 0x02, 0x02, 0x04, 0xF8, 0x7F, 0x00, 0x7F, 0x40, 0x40, 0x40, 0x20, 0x1F, // 47
    0xF8, 0x04, 0x02, 0x02, 0x04, 0xF8, 0x1F, 0x20, 0x40, 0x40, 0x20, 0x1F, // 48
    0x10, 0x08, 0x04, 0xFE, 0x00, 0x00, 0x00, 0x7F, // 49
    0x18, 0x04, 0x02, 0x02, 0xC4, 0x38, 0x60, 0x58, 0x46, 0x41, 0x40, 0x40, // 50
    0x02, 0x02, 0x82, 0x42, 0x22, 0x1E, 0x30, 0x40, 0x81, 0x81, 0x41, 0x3F, // 51
    0x00, 0x00, 0xE0, 0x18, 0xFE, 0x00, 0x1C, 0x13, 0x10, 0x10, 0x7F, 0x10, // 52
    0xFE, 0x82, 0x42, 0x42, 0x82, 0x02, 0x19, 0x20, 0x40, 0x40, 0x20, 0x1F, // 53
    0xF8, 0x84, 0x42, 0x42, 0x82, 0x04, 0x1F, 0x20, 0x40, 0x40, 0x20, 0x1F, // 54
    0x02, 0x02, 0x02, 0x02, 0xC2, 0x3E, 0x00, 0x00, 0x78, 0x07, 0x00, 0x00, // 55
    0x38, 0x44, 0x82, 0x82, 0x44, 0x38, 0x1E, 0x21, 0x40, 0x40, 0x21, 0x1E, // 56
    0x78, 0x84, 0x02, 0x02, 0x84, 0xF8, 0x18, 0x20, 0x41, 0x41, 0x20, 0x1F // 57
    
};

#endif

Вот совершенно рабочий фонт, который я использовал в одном проекте. Специально выбрал самый маленький - тут 10 цифр и точка. Сразу скажу - файл скомпилировал GLCD FontCreator2, я им рисую фонты.

В этом файле мне все понятно, кроме одного момента:    size =  0x04, 0x42, то есть 1090 байт в десятичной. Вот у меня вопрос: почему так много? Это фонткреатор гонит и лишнее отжирает или я чего то не знаю? Я не поленился, посчитал: 154 байта всего во всем фонте (включая собственно и 2 байта на size)...

Фонт сами создавали с нуля? - или брали готовый и редактировали? - если второе. может это размер исходного фонта?

Новый с нуля. Во всех фонтах размер намного больше компилирует.

UPD. Не поленился, вручную посчитал байты, прописал правильный размер - работает! Значит фонткреатор гонит...

Теперь возник другой вопрос: как считать эти байты в полноценном шрифте на два языка + все символы? Вручную совсем не комильфо, полдня считать будешь...

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

Ну тут надо курить библиотеку и смотреть как она там этот фонт читает и в пиксели превращает... Я не готов)

если речь о DMD - эти данные не используются.

Так то, оно конечно так, ежели этак...  Но вот все известные мне фонт-редакторы почему то пишут сначала старший байт, а потом младший.

Вот другой редактор

 * File Name           : droid_sans_12.h
 * Date                : 06.03.2013
 * Font size in bytes  : 5562
 /* тут много лишнего текста*/
static const uint8_t Droid_Sans_12[] PROGMEM = {
    0x15, 0xBA, // size

Какая разница - все равно ни то ни другое число не подходит:)

Слегка оживлю ветку :)

Вчерне прикрутил поддержку RGB матриц к библиотеке, уже показывает бегущую строку разными цветами:)

https://youtu.be/oS4WA0llml4

Но, конечно, до релиза еще далеко. Пока на гитхаб ничего не выкладываю.

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

Новая библиотека будет наследовать графику от Adafruit_GFX. Структура библиотеки планируется модульной, с одним родительским классом DMD_Stm32 и кучей дочерних классов для разных типов панелей и разных подключений. Код текущей библиотеки уже оформлен как класс

- DMD_MonoChrome_SPI

 еще планируются :

 - DMD_Monochrome_Parallel - (написан) -  с подключением каждой горизонтальной строки матриц к своему пину контроллера, что позволяет адресовать в 2-3 раза больше панелей при меньшей загрузке МК(ориентировочно - до сотни матриц на одной блюпилл)

 - DMD_RGB - пока разработка в самом начале, базовый класс для цветных матриц, очевидно будет ветвится для разных типов матриц, сканирований и тп

 В ядре библиотеки тоже планируются улучшения. Добавится двойная буферизация для более плавной прокрутки...

Будут и "ухудшения" - как же без них :) Скорее всего, после перехода на наследование от Адафруит придется отказаться от простеньких "стандартных" фонтов, оставить только адафруитские. Кроме того, очень многие из новых фич не рассчитаны на классические ардуино на чипах Атмел - и, вероятнее всего , дописывать этот функционал я не буду. Так что в полной мере библиотека будет работать только на СТМ - в соответсвии с названием.

Готов к предложениям и замечаниям. Есть еще несколько идей, совсем пока далеких от реализации, так что о них пока писать рано :) Где бы только время на все найти)

Если вы хотите поддержать разработку - на странице библиотеки на Гитхабе появилась кнопка для спонсоров :) Можно так же помогать матрицами, проводами и прочим... могу взять напрокат, потом верну. Анонимные спонсоры могут связаться со мной по почте :)

ИМХО лучше новую ветку. Существующая библиотека рабочая, лучшее враг хорошего :)

Стандартные фонты не очень и нужны при таком разнообразии адафрутовских, конвертора и редактора.

А на каких панелях пробуете? 
А не смог запустить вот такую панель с 1/4 на библиотеке pxMatrix.

Может кто может идентифицировать?

Модуль не узнал (я их не все на память помню), но вот то, что у него скан 1/2 - это прямо на модуле написано.

Дмитрий, а вот такую штуку можешь провернуть?

По одному каналу управлять монохромной панелью (хаб12), а по второму одновременно полноцветом (хаб75)?

1/2 скан?
Почему тогда есть входы A и B?

Наличие входа не означает его использование. Скорее всего плата стандартная, но ваш модуль точно 1/2. Об этом написано в артикуле: Р10 (шаг 10мм) - 2S (скан 1/2) - 3535 (размер диода 3,5*3,5 мм) - 3216 (разрешение модуля 32*16) - тут собственно серия модуля.

Спасибо. Даже не подумал 1/2 поставить, упорно смотрел на А и В.

в принципе наверно да, но возни много, а случай вряд ли распространенный

Как сказать. Я сразу навскидку могу пару применений такому контроллеру придумать.

Например: длинное монохромное табло с какой то информацией, а в начале один полноцветный модуль в качестве светофора: зеленая картинка "идите/проезжайте",  красная картинка "Стоп". Используется на всяких автомобильных тематиках: автомойка, парковка и тд...

Или тоже самое, но в электронной очереди, например в больнице: в монохроме ФИО пациента, и опять же красный/зеленый светофор в один модуль (модули бывают и квадратные, например 192*192 мм)

надо подумать

Затихла тема, а тем не менее все хорошо работает. Еще раз благодарность автору. 

Всплыла такая проблема на Chinese clone, namely CS32F103C8T6 from China Key System & Integrated

Как видно - идет пропуск строки.

https://youtu.be/yR1J_5dyWUs

Не вижу пропуска.... подскажите, куда смотреть.

ЗЫ Тема не затихла, просто с переводом библиотеки с одного единственного типа матриц на универсальный код для монохрома и RGB оказалось много мороки... несколько потерял концентрацию последние 2-3 недели, надеюсь скоро дело пойдет дальше.

Неудачный ракурс наверное.

Работают только нечетные строки (если считать сверху).

У меня такая фигня была однажды, я там что то с объявлением пинов напутал... Хоть убей, сейчас не вспомню что именно.

Вряд ли пины. "Оригинальная" STM32 работает нормально. Этот же код заливаю в клон и получаю черезстрочное отображение.

Ну значит у клона либо пины работают не так, либо таймер где то не совпадает. Логично же.

Если припомнить, то я в свое время что то напутал с пином OE (мне так кажется). Если мне память не изменяет, то там на OE есть два варианта: РВ0 и РВ1. Так вот я их перепутал и получил такую же черезполосицу.

Но это не точно, давно было, я вопрос решил и забыл.

А вы разве не эту же картинку видите:

Я тут вижу абсолютно четкое, я бы сказал ИДЕАЛЬНОЕ изображение, в котором равномерно светятся все строки.

Как бы там ни было - с альтернативными чипами я пока не работал...

Показал стрелками

извиняюсь, слепой.

тогда вопрос в другом - что за матрица высотой 32 строки? или это несколько матриц и просто швов не видно? Сколько матриц и как расположены

Напишите, пожалуйста, какую версию библиотеки и какие пины использованы

Это обычные матрицы Р10. Экран 3*2.
 

Последняя версия библиотеки

//   for SPI(1) CLK = PA5  R_DATA = PA7

Хм... а тут в итоге половина строк пропущена или строки показаны все, но растянуты по вертикали вдвое? То есть это какой размер букв планировался - на одну матрицу высотой или на две?

И если временно заменить контроллер на стандартный stm32F103 - проблема решается?