Форум РадиоКот

Здравствуйте!

Решил построить себе гексапода (что-то типа паука с шестью ногами), этой штуке нужно аж 18 сервоприводов — по три на ногу. Также пришел к выводу, что нагружать основное "сердце" устройства (к слову, миникомпьютер на debian) задачами типа какой ногой дёргать совсем не комильфо, по этому решил сделать промежуточное устройство на atmega32, которое бы владело бы всеми сервоприводами, а уже информацию о необходимых действиях получало бы по UART.
Мало того, захотелось сделать еще круче — не сообщать микроконтроллеру какую ногу куда подвинуть, а загрузить в него N анимаций, в которых указаны таймкоды и позиции для нужных ног, а потом проигрывать их, в том числе одновременно. Вопрос с UART снят, написал небольшую библиотеку, которая пакетами шлёт команды.

Вопрос: Как хранить полученные анимации? Ведь у контроллера RAM всего-навсего 2КБ. Или попробовать не жадничать, и тесниться в этих 2х тысячах байт? Ладно инфу о ногах (типа имена ног) можно в EEPROM хранить, а как сохранить только-что полученные по UART анимации себе в flash? Получается, это самопрограммирование? Возможно ли такое? Добавлять микросхемы — не вариант, устройство уже законченное.

Спасибо!

desertkun писал(а): Получается, это самопрограммирование?

Если я правильно понял задачу, это не изменение алгоритма работы, а обработка имеющимся алгоритмом, в зависимости от полученных данных. То есть изначально возможные комбинации описаны в программе. И происходит ветвление по условиям, полученным из вне. А самопрограммирование, это когда МК будет сам себе менять исполняемую часть. Типа переписывать часть hex файла, загруженного в него при программировании. Причем не область памяти или констант, а именно управление. Геморройная штука до не могу.

vem566 писал(а):это когда МК будет сам себе менять исполняемую часть.

А если предполагается, что эта самая исполняемая часть не будет "исполняться", а лишь будет источником данных? Например, если это возможно, объявить константу размером, скажем, в 16 кб, писать данные прямо в нее? (изменять константу, ага ) Если я правильно понял, можно ведь объявлять константы во flash? Ведь где еще в МК найдешь сколько памяти, как не во flash?

desertkun писал(а):Как хранить полученные анимации?

Прежде, чем думать, как хранить, вначале нужно продумать структуру данных, чтобы определиться с их объемом.
Вы пишете - по три сервопривода на ногу. Хорошо. Сколько байт данных нужно на один сервопривод? Сколько у него будет положений?

Хочу сделать так:

Анимация.
1. Байт на кол-во сервоприводов, которые в ней участвуют.

Далее идет "таблица сервоприводов"

Таблица серв.
1. ID сервопривода (1 байт по маске 0xEF), который используется. Старший бит — признак того, что анимация должна быть зациклена.
2. Кол-во ключевых кадров для сервы (K, 1 байт)
3. K слов (по 2 байта каждое) — адрес данных для каждого ключевого кадра из массива ключевх кадров.

Затем следует "Массив ключевых кадров"

Массив ключевых кадров.
{
1. Положение сервопривода в градациях от 0 (0 градусов) до 255 (180 градусов) — 1 байт.
2. Продолжительность действия ключевого кадра в мс — 2 байта.
3. Тип интерполяции (линейная, cos, sin) — 1 байт
4. Возможны другие данные, специфичные для конкретного типа интерполяции.
}

Итого, если, например, сделать анимацию ходьбы, в которой участвуют все ноги, и на каждой ноге по 4 ключевых кадра (что очень мало):
1 + (1 + 1 + 2 * 4) * 18 + 18 * 4 * ( 1 + 2 + 1) = 469 байт для одной бедненькой анимации. Анимация на 8 ключевых кадров уже займёт половину RAM.

В идеале хочу сделать экспортёр из 3DsMax, дабы можно было сделать все там.

А может сделать в твоём микрокомпьютере так, чтоб он кадры отправлял не названиями кадров, а сразу ячейками таблицы? Т.е. таблица в нём, ему то не трудно. Он удмает только над номером ячейки, и бездумно отправляет её по ЮАРТУ. А МК ловит и передаёт сервам.

Хочу по максимум возложить работу с сервоприводами на драйвер сервоприводов , чтобы основной компьютер не думал о сервах. Компьютер быстрый — 500 МГц, но ему, к сожалению, будет о чём подумать.

UPD. Созрел совсем другой формат, более компактный:

Заголовок.
1. Количество используемых сервоприводов (N) (1 байт).
2. Массив из N структур такого типа:
{
ID сервопривода (1 байт),
Указатель на начало исполнения в "куче" данных (2 байта)
}

"Куча" данных — свалка из разнообразных данных такого типа:
{
Угол поворота (1 байт),
Задержка (2 байта по 0x0FFF) в миллисекундах умножить на 10 (от 10 мс до 40 сек) и Тип интерполяции (0xF000)
Указатель на следующий кадр из этой же кучи или 0xFFFF, если это конец.
}

"Вектор" сервоприводов инициализируется данными из заголовка, а потом в процессе исполнения каждый из элементов вектора то и дело туда-сюда скачет.

Если подсчитать, для 18 сервоприводов на 4 кадра: 1 + 18 * (1 + 2) + 18 * (1 + 1.5 + 0.5 + 2) = 145 байт, аж в 4 раза меньше, можно задуматься о RAM.