STM32 и LCD через I2C

[WFrag]

Вот жеж совпадение. Как раз сейчас проектирую схему с дисплеем 20x4 и платой STM32F0 Discovery (хочу контроллер для продольной оси токарного станка сделать). Про I2C как-то и не подумал.

Пошёл покупать I2C интерфейс.

[Vendict]

Рад помочь. Я думаю, что по I2C даже проще, чем напрямую с экранами работать. Хотя вопрос приёма информации я не затрагивал.

[WFrag]

Подумав ещё чуть-чуть, решил, что обойдусь без I2C. Мой дисплей почему-то не завёлся от 3v (от 3.3v тоже не завёлся), соответственно, если подключать по I2C то надо как-то выравнивать уровни между 3v и 5v.

Если же подключать напрямую, то в теории можно обойтись без конверсии, 3v с точки зрения 5v логики должно восприниматься как «1». А чтоб обезопасить MCU от 5v со стороны LCD, LCD подключить в write-only режиме. Ножек у меня до чёртиков, хотел немного провода сэкономить, но получается тоже смысла мало — минимально можно на 6 проводах подключить (4 на данные, E и RS).

[Vendict]

Странно, может подсветка просто не включилась? Если по схеме ниже подать питание и подсветку должна включиться самодиагностика с заполненной верхней строкой. Сейчас нет возможности проверить, какое напряжение на эти выводы подал i2c, постараюсь вечером посмотреть.
И на вашем МК должны быть 5В толерантные выводы, посмотрите документацию, к ним и подключите.

[WFrag]

Я так примерно и делал. Единственное, что я V0 сразу на GND замкнул. Ну и подсветку не включал. Но это в худшем случае должно было выдать хотя бы квадраты. Подаешь 5v — квадраты есть, подаешь 3v — ничего.

[Alexeyslav]

проблема может заключаться в том что для контраста на 3.3В питании надо будет сформировать отрицательное напряжение. Попробуйте подать на V0 = -5В относительно положительного вывода питания индикатора, то есть -1.7В относительно общего провода.

[WFrag]

Да я на 5v лучше подключу. Оказывается, большая часть ножек чипа, который я использую, толерантна к 5v.

Всё равно основное питание будет 5v (драйвер шаговика требует 5v), а 3v будет от 5v регулятором на плате STM32F0DISCOVERY получаться.

[Vendict]

Проверил, на V0 нулевое напряжение. Видимо да, подключено к земле. Наверное особенность вашего экрана, что не завелся он от 3В. Но ведь можно i2c запитать от 5В. Я думаю в моем случае придётся так и поступить, потому что совсем потускнеет экран, если напряжение упадёт до не критичных для МК 2.7В.

[Noker]

А что в итоге с кассой?

[Vendict]

Пока только экран связал с МК. Далее нужно думать о клавиатуре и устройстве чтения штрих-кодов. В это устройство конечно много заложено (6 ИК фото-диодов), но думаю реализовать, как было сделано в оригинале — просто при срабатывании любого писать рандомную цену. Постараюсь по возможности описывать шаги, если будет интересно получаться.

[kegf]

The PCF8574 extender is available in two versions, the PCF8574 and the PCF8574A.
The only difference between the two is the I2C base address.
The base address for the PCF8574 is 0x20 and the base address for the PCF8574A is 0x38.

Так что, если паяете сами или не можете найти адрес устройства, нужно А0-А2 припаять к земле и искать по этим адресам — 0x20 и 0x38.
PCF8574 стоит рублей 20-30, кроме переменного резистора и макетки в принципе, ничего не нужно.
Для ардуины схема примерно такая
Эта схема работает с этой библиотекой http://www.xs4all.nl/~hmario/arduino/LiquidCrystal_I2C/LiquidCrystal_I2C.zip

[Vendict]

Я переписывал библиотеку, на которую указал в топике romanvl, что под номером 5 в списке использованного. Спасибо за разъяснения про PCF8574.

[k_sashka]

Для того, чтобы найти правильный адрес можно воспользоваться i2c сканером, например таким playground.arduino.cc/Main/I2cScanner
Для подключения толпы устройств по i2c экономит много времени на поиски адресов.

[k_sashka]

Кстати, LCD с кириллицей можно купить поискав в интернетах по названию — MT-20S4A

[Alexeyslav]

Насчет простоты использования я бы так не сказал, единственное преимущество — экономятся выводы контроллера. А состороны программы нужна еще дополнительная прослойка в виде поддержки такого переходника, ведь ногодрыг выводами индикатора никуда не девается и все равно нужно реализовывать весь протокол обмена с конкретным индикатором, только в данном случае накладные расходы по тактам только увеличиваются — на каждое изменение линии приходится полноценный обмен по I2С шине. Хоть и происходит это быстрее(быстрее ли? для I2C предел в 500кбод), в итоге данные на индикатор уходят медленней чем прямым выводом, хотя это на быстром камне идет в плюс — не нужны дополнительные задержки чтобы подстроить быстродействие индикатора под шустрый камушек.

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

[burjui]

Насчёт прослойки для поддержки I2C: я как-то решил поработать с LCD через SPI и написал библиотеку. В ней работа с пинами дисплея идёт через драйверы, так что перенос LCD с GPIO на SPI или I2C сильно упрощается: пишешь драйвер для дрыгания пинами через нужную шину — и всего делов. А если со всей периферией работать через единый интерфейс, то можно вообще без проблем переключать девайсы туда-сюда по шинам, один раз написав драйвера для GPIO, SPI и I2C.

Что касается скорости, то тут, как обычно: меняем скорость на удобство или наоборот. Всякому известно, что кодом на ассемблере можно выжать 100% из камня, да вот только писать на нём — тот ещё геморрой. То же и здесь.

[burjui]

Первыми граблями был USART

А всё потому, что документацию читать не нужно, а библиотека для работы с периферией — для слабаков.

//Функция передачи символа
void Usart1_Send_symbol(uint8_t data)
{
  while(!(USART1->SR & USART_SR_TC)); //Проверяем установку флага TC - завершения предыдущей передачи
  USART1->DR = data; //Записываем значение в регистр данных - передаем символ
}

//Проверяем установку флага TC — завершения предыдущей передачи

Вы в своём комментарии сами себе сообщаете о причине ошибки. Надо так:

void Usart1_Send_symbol(uint8_t data)
{
  USART_SendData(USART1, data);
  do {} while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); // ждём, пока не очистится буфер передачи (TX Empty)
}

[Vendict]

Спасибо, но видимо все статьи по USART c STM32 в рунете с этой ошибкой, только пример из статьи №4 из ссылок завелся.

[burjui]

Всегда смотрите в документацию на нужное семейство МК — Reference Manual — особенно, если что-то не работает или работает не так, как задумано. Благо документация по STM32 — образец для подражания. Ну и Application Notes поглядывайте — примеры на всякую периферию. На st.com, когда смотрите инфу по конкретному МК, обратите внимание на «вкладку» Design Resources — там и Reference Manual, и Appnotes. Errata тоже смотрите на всякий случай; ошибок в камнях у ST очень-очень мало, и они, как правило, проявляются при весьма специфических условиях, но перестраховка никогда не бывает лишней.

[WFrag]

И ещё.

Я правильно понимаю, что USART используется для загрузки прошивки через bootloader? А USB на плате для этого не используеться, т.к у этого конкретного чипа bootloader работает только через USART?

[Vendict]

Да, в данном случае для меня это было самым простым способом загрузки прошивки. Данная модель, насколько я помню, прошивается через USART, J-TAG, SW.

[burjui]

Причём, на платах STM32xxxxDiscovery уже есть ST-Link, который можно использовать и для прошивки других МК.