суббота, 10 сентября 2016 г.

D3D12

Решил поломать код движка, да перевести на DX12. На удивление туго пошло осознание нового АПИ, пришлось потратить 4 вечера на минимальный порт. А вот и свежие восхитительные пиксели, отрендеренные на D3D12:



воскресенье, 12 июня 2016 г.

Работа с EEPROM 24C16 на STM32 контроллере

Понадобилось по-быстрому запилить простой "программатор" EEPROM микросхемы, да чтоб читать/писать память её можно было через юзерское приложение в Windows. И что-то я подзатупил изначально с адресацией памяти.

Для работы с EEPROM (и не только) в STM32CubeF4 библиотеке есть функции HAL_I2C_Mem_Read и HAL_I2C_Mem_Write, инициализацию I2C генерит приложение STM32CubeMX, в общем-то халява, осталось использовать функции, передать данные из/в компьютер и девайс готов. Однако меня сбил с толка параметр функций uint16_t MemAddSize, который может быть равен I2C_MEMADD_SIZE_8BIT или I2C_MEMADD_SIZE_16BIT.  В моей микросхеме 2048 байт памяти и логично предположить, что мне нужен вариант I2C_MEMADD_SIZE_16BIT,  т.е. 16 бит на адрес,ибо 8 бит хватит только на адресацию 256 байт.


А вот и нет. Память "побита" на блоки по 256 байт, выбор ID блока происходит через запись соответствующего ID в биты 1,2,3 байта адреса устройства:









Их можно трактовать как ID 256-байтного блока или просто как старшие дополнительные 3 бита адреса памяти (как в таблице и указано). То есть адресация здесь 11 битная.

Собственно, адрес _устройства_ получаем таким образом:  0xA0 | ((memory_address >> 7) & 0xE).  Нулевой бит по идее контроллируется библиотекой и делать операцию битового чтения & 0xF по идее не нужно. Но опыт подсказывает, что доверять библиотеке Cube от ST не стоит )

Вдруг кому сэкономит время )

суббота, 9 апреля 2016 г.

HDMI на FPGA Cyclone II

Запилил на своём борде с Cyclone II генерацию HDMI сигнала. Всё сделано так же как и в проекте HDMI для платы Марсоход3, только у меня разрешение картинки 800x600x60Hz


Для генерации разрешения 800x600 необходимо во-первых заменить параметры таймингов в файле HDMI_1280.v на эти

always @(posedge pixclk) DrawArea <= (CounterX<800) && (CounterY<600); 
always @(posedge pixclk) CounterX <= (CounterX==1055) ? 0 : CounterX+1; 
always @(posedge pixclk) if(CounterX==1055) CounterY <= (CounterY==627) ? 0 : CounterY+1;
always @(posedge pixclk) hSync <= (CounterX>=840) && (CounterX<968);
always @(posedge pixclk) vSync <= (CounterY>=601) && (CounterY<605);

А так же сгенерить свою PLL с 2 выходами клоков на 40MHz и на 200MHz. 40MHz - частота тактования пикселей, с ней всё ясно, а вот 200 MHz это частота тактования TMDS энкодеров (в HDMI применяется TMDS 10 битное кодирование), они тактоваться должны на частоте в 10 раз быстрее пиксельклоков, однако т.к. используются DDR выходы ПЛИС-а, частота тактования TMDS делится на 2, итого (40*10)/2 = 200MHz

четверг, 7 января 2016 г.

Симулятор квадрокоптера: симуляция щёточных DC моторов

Решил немного поразвлечься и запилить симуляцию щёточных моторов постоянного тока в Unity для виртуального квадрокоптера и не только.

Не думал о подобном ранее, но чуток покопавшись понял, что всё достаточно просто )
(Я далеко не физик/электронщик и могу что-то сам не так понимать или описывать, но тем не менее)

Щёточный DC схематически можно представить так:




R - сопротивление обмотки ротора.
L - индуктивность обмотки ротора
e - обратная ЭДС обмоток ротора.
J - момент инерции ротора

Из за вращения ротора в статичном магнитном поле в его обмотках появляется обратная ЭДС, создающая обратное напряжение в обмотках, которое ограничивает максимальные обороты движка (но не только оно ограничивает). Зависит линейно от угловой скорости ротора.

Так же есть ЭДС самоиндукции, появляющаяся при изменении тока, проходящего по обмоткам.
E = - L* (dI/dt)
- как видно тут участвует производная тока и самоиндукция будет влиять на работу мотора только когда ток меняется, КЭП.

e - величина линейная, зависит от угловой скорости ротора, равна k_e * w. k_e - константа обратной ЭДС.

Пользуясь вторым правилом Кирхгофа можно записать уравнение напряжения в моторе:

Vs = R*I + L*(dI/dt) + e;

тут Vs - напряжение питания мотора.

Не сложно переписать уравнение так, что бы выразить производную тока:

dI/dt = (Vs - (R*I) - e) / L;

Уже хорошо, но кроме тока нам интересны ещё и обороты движка, и крутящий момент же.
Для начала можно описать, так сказать, уравнение равновесия крутящих моментов:

Me = Mm + Mf + Ml

Me = электрический крутящий момент, т.е. момент, сгенеренный обмотками ротора.
Mm - механический момент ротора,  J* (dw/dt) где J - момент инерции ротора, кг*м^2
Mf - момент трения ротора, линейно зависит от угловой скорости, k_f * w,
Ml - момент внешней нагрузки на ротор.

w - угловая скорость ротора [рад/с]

т.е. Me = J*(dw/dt) + k_f*w + Ml;

Тут есть важная штука: "электрический" момент линейно зависит от тока на обмотках якоря и его коэффициент является одной из важнейших характеристик моторов. То есть "электрический" момент (Me) = k_t * I;

k_t * I = J*(dw/dt) + k_f*w + Ml;

Выразим производную угловой скорости ротора:

dw/dt = (k_t*I - k_f*w - Ml) / J

Теперь у нас есть 2 дифференциальных уравнения, которые можно проинтегрировать и получить графики работы движка.

Для проверки себя я заскринил реальный график реального движка, подложил в юнити в виде плоскости с текстурой под свой рисуемый график.

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

Что бы график сошёлся идеально, необходимо было крутить несколько коэффициентов. Это достаточно геморно и потому я использовал алгоритм оптимизации Левенберга-Марквардта для автоматической подстройки параметров ))) Критериями ошибок стали максимумы и производные графиков тока и оборотов мотора, а так же разница между идеальными и реальными экстремумами графиков мощности и эффективности, вот что получилось:




Тут gizmo используется для отрисовки графиков, под ними подложка с текстурой реальных графиков. Всё вполне совпадает )

А вот график по времени. Сначала включается питание мотора и потом по достижению максимальных оборотов питание отключается. Видны 2 всплеска на графиках - большой пусковой ток и выброс в отрицательную сторону при выключении.  Синий график - обороты, красный - ток.

воскресенье, 8 ноября 2015 г.

Коптер

   Начал совсем недавно пилить свой квадрокоптер. За основу пока взят мой борд STM32VLDISCOVERY. У него на борту не очень крутой контроллер STM32F100RBT6: 24MHz, 128Kb FLASH, 8Kb RAM, однако пока что его даже много )

   Что успел запилить:
Напаял железки на борд! 2 RFM70 радио модуля пока на 1 общий SPI, акселерометр BMA280 на отдельный SPI, собрал узел контроля оборотов коллекторного мотора, схемка вышла не сложная ) Через полевой транзистор IRLML2803  ШИМ-ом включаю/отключаю питание у мотора, скважностью пульса регулируются обороты, так же добавлен диод Шоттки в качестве шунта мотора, резистор на 100К что бы не происходило произвольного открывания затвора транзистора если WPM пин в подвешенном состоянии.


И для удобства запилил простенький командный интерфейс через виртуальный COM порт, могу теперь устанавливать "обороты" движка через консоль.

   Так же завёл акселерометр, что, в общем то, не сложно, используя стандартную библиотеку от BOSCH https://github.com/BoschSensortec/BMA2x2_driver.  Хотя конечно некоторые вещи в нём не очевидны! Например, у него в bma2x2.c файле в глобальной переменной u8 V_BMA2x2RESOLUTION_U8 = BMA2x2_14_RESOLUTION; захардкодена битность показаний осей акселерометра, всегда 14 бит. И это странно тем, что мне нужно менять чужой драйвер что бы получить другую битность.
   А ещё одна корявость состоит в том, что у них же в файле-примере bma2x2_support.c есть семплы имплементации функций чтения/записи SPI и чтение осей акселерометра. Акселерометр позволяет последовательно читать несколько регистров за раз! И для этого в семпле используются буферы и их размер задефайнен как #define SPI_BUFFER_LEN 5 чего не хватает для работы с функцией bma2x2_read_accel_xyz которая в этом же семпле и используется. Я изначально внимание не обратил и долго думал, почему у лежащего горизонтально акселерометра ускорение 0 )  Оказалось ось Z просто не вмещалась в буфер!

   Радио пока через RFM70. Для реального применения в квадрокоптере этот радио модуль не подходит из за малого радиуса действия (метров 10), но хоть что-то. Будет использоваться для передачи команд с пульта на коптер.






среда, 4 ноября 2015 г.

Мелкий апдейт движка

Добавил систему ввода, поддерживаются множество клавиатур, мышей, джойстиков, всё крайне просто и достаточно удобно.

auto keyboards = Input::instance()->keyboards();

if(keyboards[0]->get_key_state(0x57)){
gameObject->transform->set_local_position(gameObject->transform->get_local_position() + gameObject->transform->forward() * (deltaTime * move_speed));
}

Так же начал прикручивать AMP рендереры, пока что для параметрических поверхностей, чуть позже сделаю биндинги к полигональным моделям. Таким образом можно будет делать гибридный рендер стандартный (растеризацией полигонов) и Path Tracing-ом.

Сложнейший рендер: сферка отрендеренная трассировщиком пути, в цвете выведены нормали.


понедельник, 25 мая 2015 г.

Unity Killer :D

Пописываю параллельно с остальными проектами "убийцу Unity" :D

Что уже есть:
Компонентная система сущностей, иерархии трансформов, шейдеры, система материалов удобная, класс для рисования Gizmo, меши с сабмешами, рендеринг из нескольких камер в кадре и так ещё всякие мелочи)   Скоро добавлю загрузку текстур и мешей.

воскресенье, 5 апреля 2015 г.

Атмосфера

Запилил по-быстренькому атмосферу для планеты в Unity