Темброблок/спектроанализатор на ATmega16, TDA7439 и SG12864

kloker

в WIN10-x64 arm-avr-compilerV2.0 ARM компилит.
такой вопрос, если юзается жисплей SPI или I2C, то аппаратные SPI1 и USART2 ремапятся на другие пины? в коде не нашел. жалко их под кнопками хоронить

Реклама

WiseLord

Если используется дисплей SPI, то как раз SPI1 (PA15, PB2-PB4) и используется. Под кнопками PA4-PA7 его уже нет.
При I²C дисплее занят I2C2, на другие нужды (аудио, радио) I2C1 остаётся.

Так что из-за кнопок теряется только USART2. Но тут ничего уже не поделать, его заремапить нельзя. Но и без того есть незанятый USART1.

Вообще, планируемую разводку я выкладывал, но пусть будет ещё раз.

Реклама

kloker

[uquote="WiseLord",url="/forum/viewtopic.php?p=3445853#p3445853"]Вообще, планируемую разводку я выкладывал, но пусть будет ещё раз.[/uquote]
спасибо, я в этот файл и смотрел,
там не все столбики подписаны, потому сразу и не понятно, что это ремап интерфейсов. USART вроде на BlueTotch дистанку в AVR проекте уходил.
планирую вместо блютуза WiFi "удлинитель" 232\485 поставить на esp8266 модуле , как автономное устройство работает относительно стабильно, с водомера показания снимаю.

mixa232323

WiseLord

Добавил еще 2 дисплея 400х240. Добавте на git.

Реклама

WiseLord

Горшочек, не вари...

Давайте Вы сами на github запушите это? Есть опыт работы с git?

Реклама

mixa232323

нет опыта

Реклама

WiseLord

mixa232323 писал(а):Добавте на git

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

Потому и ратую за то, чтобы это было не архивами, а патчами. Git в этом плане проще всего для получения изменений в коде.

P.S. Хочу посоветоваться со всеми заинтересованными по поводу управления с передней панели. В целом, оно будет подобно таковому в варианте на ATmega32, но, поскольку кнопок сейчас 6 (плюс энкодер), некоторые отличия по-любому будут.

Поэтому и хотелось бы обсудить, как бы этим всем комфортно управлять.

Пока что задействованы кнопки:
0 - включение/выключение (ждущий режим), длинное нажатие - переход на экран яркости

2 - показать часы, далее - переход в настройки времени.

5 - показать громкость, далее - прочие аудиопараметры

Кнопки 3-4 (или может было бы лучше 2-3, а часы сдвинуть на кнопку 1?) планируется использовать для функций вроде "назад-вперёд", как-то переключение радиостанций и т.п.

В общем, если есть идеи, как сделать управление максимально удобным, буду рад выслушать.

mixa232323

Я думаю лучше реализовать все функции а потом думать как их по кнопкам распихать. Там виднее будет когда всё готово.

WiseLord

Поскольку в STM32 нет eeprom, а хранить данные (громкость, вход, радиостанции и т.п.) где-то надо (20-ти байт "батарейной" памяти явно маловато), начал изучать вопрос использования flash в качестве eeprom, благо STM-ка позволяет писать в свою память программ.

И наткнулся на интересное явление - похоже, при заявленных 64кБ памяти у STM32F103C8T6 её на самом деле 128кБ. По крайней мере, попытка записать и прочитать байт во вторую половину якобы несуществующей памяти проходит вполне удачно.

Так что хотелось бы попросить mixa232323 и других, если кто-то ещё тоже пытается компилить/прошивать текущий код. Протестируйте свои МК на этот счёт. На кнопку 1 (вторую по сути, я считаю с нуля), повешен вход в тестовый режим. Должно отобразиться две строчки "FFFFFFFF". При повторном длинном нажатии МК попытается записать по адресам в 1-кБ страницах 60 и 120. И выводить новые данные из этих же адресов. В моём случае это "FFFF0060" и "FFFF0120" - ровно то, что и записывалось. То есть работает и "бонусная" половина Flash-памяти.

Вот ссылка на исходный вход с этой тестовой функцией.

Просто если действительно в этих МК не 64кБ, а 128кБ памяти, это открывает гораздо больший простор для внедрения разных фич. Те же шрифты затем можно большие (занимающие довольно много ценного места) для цветных экранов сделать, вместо масштабирования маленьких, как оно сейчас сделано.

И да, чтобы снова стереть и потестировать ещё раз, можно просто выполнить "make erase" - через OpenOCD (должен быть установлен) сотрётся всё, а "make flash" снова можно прошить прошивку.

mixa232323

Я знаю про 128кб памяти. Но есть вероятность что код в вторых 64кб ядром выполняться не будет но хранить инфу в них можно. Так делают умельцы на stm32f100 но код в верхнем участке ядро не видит и не выполняет.И не забывайте что число перезаписи во флеше ограниченно.
И вот еще 1 облом при любом изменении в переменных придется писать весь блок и износ памяти будет диким. А вот шрифты и цветные иконки запихать туда хорошая идея я об этом уже думал.
Так что без EEPROM на i2c никак.

WiseLord

mixa232323 писал(а):И вот еще 1 облом при любом изменении в переменных придется писать весь блок и износ памяти будет диким[/quote
mixa232323 писал(а):Так что без EEPROM на i2c никак.

Всё не так печально.

Заимплементил эмуляцию EEPROM на базе алгоритма из AN2594, но чуть проще. Вроде как работает и никаким износом не пахнет.

Идея следующая:
Есть две страницы в Flash памяти - одна VALID, другая - ERASED. Тип таблицы определяется по её заголовку. Размер заголовка, как и размер любого элемента - 4 байта.
Каждый элемент - это "виртуальный" двухбайтовый адрес и двухбайтовые данные.

Итого, при размере страницы, например, 1024байта мы можем там хранить 255 элементов (плюс 1 - заголовок таблицы).

Если пользователь хочет сохранить некоторый параметр, который изменился, VALID странице просто добавляется новый элемент. Если параметр не изменился - ничего не добавляем.

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

Новые элементы будут добавляться уже в новую VALID страницу.

Ну и наглядный пример, что происходит. Допустим, нам нужно хранить три параметра - VOLUME, INPUT, FREQ, а размер страницы всего 8 элементов

Спойлер

Код: Выделить всё

#define VOLUME   0
#define INPUT    1
#define FREQ     2

Начальное состояние таблиц

Код: Выделить всё

VALID       ERASED
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(VOLUME, 0x18); - Добавляется значение громкости

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(VOLUME, 0x13); - Добавляется новое значение громкости

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(INPUT, 0x00); - Добавляется новое значение входа

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
0001.0000   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(VOLUME, 0x15); - Добавляется новое значение громкости

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
0001.0000   FFFF.FFFF
0000.0015   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(INPUT, 0x01); - Добавляется новое значение входа

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
0001.0000   FFFF.FFFF
0000.0015   FFFF.FFFF
0001.0001   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(VOLUME, 0x15); - Громкость не обновляется, так как равна предыдущей

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
0001.0000   FFFF.FFFF
0000.0015   FFFF.FFFF
0001.0001   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(VOLUME, 0x12); - Добавляется новое значение громкости

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
0001.0000   FFFF.FFFF
0000.0015   FFFF.FFFF
0001.0001   FFFF.FFFF
0000.0012   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(FREQ, 0x9950); - Добавляется новое значение частоты

Код: Выделить всё

VALID       ERASED
0000.0018   FFFF.FFFF
0000.0013   FFFF.FFFF
0001.0000   FFFF.FFFF
0000.0015   FFFF.FFFF
0001.0001   FFFF.FFFF
0000.0012   FFFF.FFFF
0002.9950   FFFF.FFFF

eeUpdate(FREQ, 0x8470); - Таблица переполнена, копируем данные в новую, старую стираем

Код: Выделить всё

ERASED       VALID
FFFF.FFFF   0000.0012
FFFF.FFFF   0001.0001
FFFF.FFFF   0002.8470
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

eeUpdate(VOLUME, 0x12); - Громкость не обновляется, так как равна предыдущей

Код: Выделить всё

ERASED       VALID
FFFF.FFFF   0000.0012
FFFF.FFFF   0001.0001
FFFF.FFFF   0002.8470
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF
FFFF.FFFF   FFFF.FFFF

В проекте размер "EEPROM" установлен в 2 * 1кБ (512 элементов), сохраняться будет не более сотни параметров (учитывая радиостанции). Причём подавляющее большинство параметров меняются достаточно редко. Так что переполнение и стирание таблицы будет происходить достаточно редко. Вряд ли за день это произойдёт хотя бы раз, особенно если учесть, что обновление происходить будет только при уходе в ждущий режим.

Плюс в МК есть ещё 20 байт батарейной (BKP) памяти, в неё можно сохранять самые часто меняющиеся параметры, вроде последней частоты радио, уровня громкости, текущего входа. Тогда запись в EEPROM вообще будет редко происходить.

mixa232323

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

kloker

по поводу юзабельности кнопок и дисплейных меню.
кнопки скрола по списку вверх вниз годный вариант, особенно когда дисплеи 320х240. список фм станций с названиями, если RDS считался при скане диапазона, меню сетап с настройками, теущие настройки баланса тембров и громкости на одном экране с прогресбарами.
ну и главный экран с иконками, раз флеши 64 к под хранение.

mitre

Привет из Болгарии.
Будет ли етот дисплей работать?
https://ru.aliexpress.com/item/1-8-Inch ... 33edg7Ag5E

WiseLord

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

deop

[uquote="WiseLord",url="/forum/viewtopic.php?p=3448462#p3448462"]Поскольку в STM32 нет eeprom, а хранить данные (громкость, вход, радиостанции и т.п.) где-то надо (20-ти байт "батарейной" памяти явно маловато), начал изучать вопрос использования flash в качестве eeprom, благо STM-ка позволяет писать в свою память программ.
...И наткнулся на интересное явление - похоже, при заявленных 64кБ памяти у STM32F103C8T6 её на самом деле 128кБ. По крайней мере, попытка записать и прочитать байт во вторую половину якобы несуществующей памяти проходит вполне удачно.
....Просто если действительно в этих МК не 64кБ, а 128кБ памяти, это открывает гораздо больший простор для внедрения разных фич. Те же шрифты затем можно большие (занимающие довольно много ценного места) для цветных экранов сделать, вместо масштабирования маленьких, как оно сейчас сделано.
.[/uquote]

Наткнулся на отзыв покупателя когда приценивался к чипам STM32F103C8T6, это не тот вариант на 128кб чипов с Ali?

mixa232323

[uquote="mitre",url="/forum/viewtopic.php?p=3449023#p3449023"]Привет из Болгарии.
Будет ли етот дисплей работать?
https://ru.aliexpress.com/item/1-8-Inch ... 33edg7Ag5E[/uquote]

Тут сейчас 2 проекта обсуждают на atmega32 и stm32f103c8t6. Вам на каком контролере?

Добавлено after 1 minute 45 seconds:
Re: Темброблок/спектроанализатор на ATmega16, TDA7439 и SG12864
Добавлено after 11 minutes 51 second:
[uquote="deop",url="/forum/viewtopic.php?p=3449073#p3449073"][uquote="WiseLord",url="/forum/viewtopic.php?p=3448462#p3448462"]Поскольку в STM32 нет eeprom, а хранить данные (громкость, вход, радиостанции и т.п.) где-то надо (20-ти байт "батарейной" памяти явно маловато), начал изучать вопрос использования flash в качестве eeprom, благо STM-ка позволяет писать в свою память программ.
...И наткнулся на интересное явление - похоже, при заявленных 64кБ памяти у STM32F103C8T6 её на самом деле 128кБ. По крайней мере, попытка записать и прочитать байт во вторую половину якобы несуществующей памяти проходит вполне удачно.
....Просто если действительно в этих МК не 64кБ, а 128кБ памяти, это открывает гораздо больший простор для внедрения разных фич. Те же шрифты затем можно большие (занимающие довольно много ценного места) для цветных экранов сделать, вместо масштабирования маленьких, как оно сейчас сделано.
.[/uquote]

Наткнулся на отзыв покупателя когда приценивался к чипам STM32F103C8T6, это не тот вариант на 128кб чипов с Ali?[/uquote]

stm32f103c8t6 и stm32f103cbt6 это один и тот же контролер с разным заявленным объёмом памяти. Но по факту на борту 128кб. Не факт что в stm32f103c8t6 ядро может выполнять код с верхней половины памяти но там можно хранить инфу которая не является частью кода (шрифты и тд ).

WiseLord

Я сейчас попробовал в скрипте линкера отправить .text секцию (код программы) в "бонусную" половину памяти - всё вполне себе работает. Ну и массивы шрифтов тоже туда попробовал положить.

Вот как это можно сделать, а вот код, который можно проверить.

.bin файл в hex-редакторе при этом выглядит забавно - в начале только таблица прерываний, а дальше вплоть до 64кБ одни нули. И ничего, работает.

kloker

[uquote="WiseLord",url="/forum/viewtopic.php?p=3449166#p3449166"]Я сейчас попробовал в скрипте линкера отправить .text секцию (код программы) в "бонусную" половину памяти - всё вполне себе работает. Ну и массивы шрифтов тоже туда попробовал положить.

Вот как это можно сделать, а вот код, который можно проверить.

.bin файл в hex-редакторе при этом выглядит забавно - в начале только таблица прерываний, а дальше вплоть до 64кБ одни нули. И ничего, работает.[/uquote]

может ST-Link читать бонусный кусок не хочет? считал ID чипа и обрезал размеры под шаблон. в компилере та-же байда может быть.

как-то странно, матрица для печати чипа на 128кб, а логика CPU видит 64кб.

такой способ лока Nvidia практикует, один чип на игровой и work платформах, дрова и биос обрезаны ID устройств, и 2мя номиналами резисторов на пинах ключа первичной инициализации GPU. перепайка резюков превращает карту из GTI в Quadro

WiseLord

Про STLink не знаю, я OpenOCD пользуюсь. Он тоже прошивать такую прошивку не хотел, пока принудительно в конфиге 128K не выставил.