LCD ILI9325 глюки в работе дисплея

Здравствуйте!
Подключил дисплей ILI9325 и запустил с помощью CooCox к STM32F407VG используя библиотеку производителя LCD.
Библиотека написана под uKeil, поэтому для CooCox пришлось переделывать, особенно неприятным оказалось то что
китайские разработчики использовали какую-то свою кодировку в которой даже латинские символы CooCox(ом) не воспринимались. Причём сами символы отображались корректно. Пришлось конвертировать кодировку.
Вобщем дисплей запустился, но после 1-2 обновлений экрана зависает.
Собственно как пытался решать проблему.
1. изменял тактовую частоту процессора;
2. изменял скорость передачи данных FSMC (практически это тоже что и 1)
3. пробовал различные варианты инициализации (думаю где то здесь надо искать инициализация или передача данных).

Вобщем, в совокупности, удалось добиться 5-7 обновлений экрана.
Но даже значительном понижении частоты FSMC лучших результатов добиться не удаётся,
максимум 10-12 обновлений экрана и дисплей зависает.
Обновлениями экрана, я называю примерное время за которое заполняется весь экран.
Причём с этой же китайской LCD библиотекой под uKeil дисплей нормально работает.
Вопрос: кто сталкивался с подобными проблемами, есть ли идеи, предложения?
Благодарю за ответы

Код LCD
LCD.zip

0

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

У вас там назначение кода дисплея, а потом его чтение. Если считалось неправильно, всё пойдёт наперекосяк.

1

Не поддержу. Написанная для компилера рабочая библиотека - это отличное место зацепиться за готовое решение и не углубляться в "кишки" fsmc, такты, частоты и т.д. Учитывая, что разница между KEIL и CooCox - в компиляторе и в стартовых функциях - уделите внимание правильной инициализации частот шин. Если есть нестабильность - очевидно, что дисплей или МК работает на каких-то граничных параметрах.

0

Не соглашусь. Рабочая библиотека это нечто готовое от надёжного поставщика, типа uC/Gui, например.
А здесь поделка от китайцев, предназначенная только показать работоспособность электроники дисплея, который они продают. Захотите надёжной работы - придётся переписать; захотите оставить этот код - огребёте проблем, типа тех что в первом посте темы.
У ардуины тоже якобы куча рабочих библиотек на все случаи жизни, только качество их на уровне плинтуса.

0

ТС, пробежавшись по коду - нашел пару вещей:

1) Функция delay_ms() имеет совершенно частный случай подсчета времени, причем, зависящий от компилера и уровня его оптимизации. И это помимо частоты процессора и места размещения кода (Wait-States).
Компилеры имеют привычку выкидывать пустые циклы, а у вас задержка выполнена именно на этом принципе. Вариантов решений несколько - либо заставить компилятор работать с пустым циклом (например, добавить "volatile" к объявлению переменной), либо использовать какой-нить таймер (RTC например) для подсчета времени.

2) inline-функции в GCC и KEIL также могут иметь разные воплощения. Для GCC можно добавить "__attribute__((always_inline))", чтобы заставить в любом случае заинлайнить функцию. Потому что есть случаи, когда этого не происходит.

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

0