forummailandlogin

Пользовательские строки должны быть объявлены в опциях проекта во вкладке параметры. и тогда '.имя_парамтра' выведет эту строку.

тут и тут

Спасибо. Начал переделывать. Один символ - один файл. Посмотрим что выйдет.

Вот об этом и речь, текстовый формат более восприимчив для глаза, и внести изменения можно долго не вникая. Но FAT остаётся и значит не секторы, а кластеры и получается одна буква на файл. Остаётся компромисс между txt и bin.

В настройках платы надо разрешить использовать строковые параметры.

All, увеличение памяти программ и расположения там шрифтов это естественно самый быстрый способ, но здесь не рассматривается. МК не меняется, память программ к нему физически нельзя припаять. Бинарный вид я так понимаю это данные которые попадают напрямую в процедуру отрисовки миную преобразование из 0x0000 в 0, и без прочих знаков форматирования так? Вида: Ну это в общем то не проблема, поковыряться в блокното-подобной программе и получится хоть и ценой читабельности. Но как найти конкретный символ в файле пока остаётся загадкой.

x893, буфер в SRAM стандартный 512 байт, можно конечно увеличить вдвое, но не хотелось бы больше 1 кБ - СТЕК и другие нужды. Вот именно, но пере тем как букву считать, её надо найти. Так что пока самый перспективный вариант это куча файлов:"А,а,Б,б,В,в..." и в них уже символы вырисовывать. Файлы искать проще чем строки в файлах.

evgen.05, ни чего не прикручено, всё на ассемблере, всё рукописно. Если бы шрифт был бы моножирный, все бы символы одинаковое количество байт бы занимали, то да. Можно конечно решение в лоб попробовать - поиском по буковкам, но времени и памяти отнимет дикое количество. Или скажем кучу файлов создать:"А,а,Б,б,В,в..." и в них уже символы вырисовывать.

x893, если есть что почитать, прошу поделиться.

aaarrr, не. Хотелось бы сохранить исходное форматирование файла со всеми знаками табуляции и комментариями, а не исходник+компилятор=бинарник. Но предположим, что воспользуюсь этим совет. Сейчас если шрифт внутри МК, то я имею следующее (картинка 1): Таблица tImageDataSymbols содержит адреса структур sImageDataFont_0xXX, которые в свою очередь содержат адреса и параметры изображений выводимых на экран символов cImageDataFont_0xFF. Получая код скажем буквы "ю" равный 0xFE, я забираю поэтому индексу из таблицы tImageDataSymbols адрес структуры sImageDataFont_0xFE и так далее. Но это вам и так понятно, не первый раз меня на мысль наводите. А что будет содержать *.bin файл? Ни разу с ними дело не имел. Упаковщик хорошо, но придётся писать распаковщик. И он не решает первой проблемы.

STM32F0+графический дисплей. Работает без проблем, но шрифт занимает всю память. Посему решил шрифты поместить во внешнюю память. STM32F0+графический дисплей+SDCard. Карта форматирована в FAT32. Файл со шрифтом найден, но как обучить МК правильно интерпретировать данные из него пока не пойму. Вот фрагмент файла со шрифтом. Когда шрифт вшит в память МК, все адреса известны и поиск нужного изображения символа не представляет труда. А вот когда файл снаружи МК - адреса изображений не существуют вообще. Нужен какой-то особый подход. Вот фрагмент файла, как он виден для МК. Может кто идейку подкинет, как тут быть.

В настройках проекта, вкладка матрица соединений.

А где для него место???????

На само деле всё просто. Действительно в FAT32 Root Directory является таким же файлом, а значит информация о нём находится в FAT. Минимальный размер Root Directory как у всех - 1 кластер. как только количество каталожных записей превысит границу кластера, то в FAT на его месте появится номер кластера где искать продолжение. Таким образом и узнаём размер Root Directory что бы не вылетить за его пределы при поиске по нему.