Salamander

Еще подкину мысль - библиотека использует библиотеку arm_math.h Может с ней есть какие танцы и бубны? Все-таки вычисления..... Условий использования библиотеки от Фабио (которые должен выполнить пользователь и которые могут повлиять на скорость) всего два 1. Вставить функцию вывода точки 2. Подключить arm_math.h В первом условии накосячить сложно, да и по факту - всего 7 тактов занимает запись точки. Значит библиотека arm_math работает медленно? У меня не привязано. Еще вопрос - серия F7 имеет аппаратную поддержку плавающей точки? Наверное да. Если так, то может быть такое, что у меня эта функция отключена?

Крамольный вопрос, но все же - может найдется энтузиаст с платой на быстром STM32, например на F7, который эту библиотеку подключит и попробует у себя? В main нужно всего-то вставить #include "dsp3D.h" и float32_t dsp3dModel[122] = {8,12, // VERTEXES // coords normals 1, 1, 1, 0,0,1, // 0 1, 1,-1, 0,-1,0, // 1 1,-1, 1, -1,0,0, // 2 1,-1,-1, 0,0,-1, // 3 -1, 1, 1, 1,0,0, // 4 -1, 1,-1, 0,1,0, // 5 -1,-1, 1, 0,0,0, // 6 -1, -1,-1, 0,0,0, // 7 // FACES // Indexes RGB 0,1,2, 255,255,255, 1,2,3, 255,255,255, 0,1,4, 255,255,255, 1,4,5, 255,255,255, 0,4,6, 255,255,255, 0,2,6, 255,255,255, 2,3,6, 255,255,255, 3,6,7, 255,255,255, 1,3,7, 255,255,255, 1,5,7, 255,255,255, 5,6,7, 255,255,255, 4,5,6, 255,255,255, }; dsp3D_init(); dsp3D_setCameraPosition(0,0,10); dsp3D_setLightPosition(0,0,10); dsp3D_setCameraTarget(0,0,0); while(1) { meshRotation[0]+=0.01; meshRotation[1]+=0.01; meshRotation[2]+=0.01; dsp3D_renderFlat(dsp3dModel); TFT_FillRectangle(0,0,1024,600,0x00); }

Попробую ка я посчитать через какие промежутки времени эта функция вообще вызывается. Оставьте этот путь, все нормально с дисплеем, TOuchGFX порхает Сделал это так void dsp3D_drawPointDepthBuffer(int32_t x, int32_t y, float32_t z, color32_t color) { if((x > -1) && (x < SCREEN_WIDTH) && (y > -1) && (y < SCREEN_HEIGHT)) { int32_t index = (x + y * SCREEN_WIDTH) * 3; // if(dsp3D_LL_readFromDepthBuffer(index) < z) // return; dsp3D_LL_writeToDepthBuffer(index, z); // dsp3D_LL_drawPoint(x, y, color); // убрал вызов функции низкоуровневого вывода точки, заменил ее на то, что ниже delta_tick=DWT->CYCCNT-last_tick; // считаю разницу. last_tick=DWT->CYCCNT; обновляю счетчик. *(__IO uint32_t*)(0xD0000000 + index)=color; } } Получаю значение 345-380. То есть функция вывода точки вызывается раз в 345 тактов. То есть 552630 точек в секунду, не так ли? Маловато.... Разрешение у меня 1024х600 точек. Я не думаю, что каждый пиксель отрисовывается... Теперь делаю так last_tick=DWT->CYCCNT; *(__IO uint32_t*)(0xD0000000 + index)=color; delta_tick=DWT->CYCCNT-last_tick; то есть, считаю, сколько тактов занимает запись в память. Получаю 7-10 тактов. Я правильно считаю?

Включил 3 уровень (до этого был 0) - не помогло

Перенес вывод непосредственно в тело библиотеки. ТАм тоже есть проверка границ. Отрубил ее. Убрал умножение. Все равно медленно void dsp3D_drawPoint(int32_t x, int32_t y, color32_t color) { //if((x > -1) && (x < SCREEN_WIDTH) && (y > -1) && (y < SCREEN_HEIGHT)) *(__IO uint32_t*)(0xD0000000 + (y * SCREEN_WIDTH + x))=color; //dsp3D_LL_drawPoint(x, y, color); }

небольшое ускорение есть - перевел в режим wireFrame - движения стали более плавными. цвет 24 битный. в TFT_FillRectangle() тоже было умножение. Скорее всего. Буду копать....

Вот так void dsp3D_LL_drawPoint(uint32_t x, uint32_t y, color32_t color) { /* if(x < minX) minX = x; if(x > maxX) maxX = x; if(y < minY) minY = y; if(y > maxY) maxY = y; */ // YOUR IMPLEMENTATION //TFT_FillRectangle(x,y,x+1,y+1,color); //videoBuf[y * SCREEN_WIDTH + x] = color; *(__IO uint32_t*)(0xD0000000 + 3*(y * SCREEN_WIDTH + x))=color; } это нафиг? Если да, то медленно

Я вместо организации буфера сделал такой вариант void dsp3D_LL_drawPoint(uint32_t x, uint32_t y, color32_t color) { if(x < minX) minX = x; if(x > maxX) maxX = x; if(y < minY) minY = y; if(y > maxY) maxY = y; // YOUR IMPLEMENTATION *(__IO uint32_t*)(0xD0000000 + 3*(y * SCREEN_WIDTH + x))=color; } То есть, тупо, атомарно пишу в память. Скорость не увеличилась ни на грамм. Значит тормозит само API? Сейчас попробую проверку minX,minY выкинуть. нет.... проверка границ ни при чем, все равно медленно...

Хорошая идея. Мне кажется, она согласуется с тем фактом, что в библиотеке есть еще функции void dsp3D_LL_switchScreen(void) { // YOUR IMPLEMENTATION } void dsp3D_LL_writeToDepthBuffer(uint32_t pos, float32_t value) { // YOUR IMPLEMENTATION } для двойной буферизации. Но вот беда, мой keil не знает , что такое __no_init . Как с этим быть? За собой он оставил только то, что в функциях, в названиях которых есть LL Вот есть товарищ, который запустил библиотеку недурака Фабио

Какого API? 3d библиотеки? Так она платформонезависима, в ней чистый сишный код, который сам все делает и в фундамент программы нужно только заложить функцию вывода точки, потому как библиотека не знает, на каком железе это будет запускаться. функция dsp3D_LL_drawPoint вызывается в самом конце расчета, когда цвет точки уже ясен, осталось ее только вывести. Это как в FatFS - весь код независим, нужно только прописать функции записи и чтения секторов. Вот основной файл библиотеки https://github.com/FabioRM/dsp3D/blob/master/src/dsp3D.c по идее, код в нем не нуждается в редакции прописать низкоуровневые йункции нужно только здесь https://github.com/FabioRM/dsp3D/blob/master/LowLevelTemplate/dsp3D_LL_template.c

Так я и нарисовал графическим примитивом - прямоугольником. Вы посмотрите, сколько там вычислений и операций. Понятно, что оно грузит процессор. полюбуйтесь https://cloud.mail.ru/public/DGUX/TZoRw7stw А вот как работает на том же STM32F746 у автора библиотеки

Господа, я с месяц назад создавал тут тему, с вопросом по 3d библиотеке https://github.com/FabioRM/dsp3D под STM32 Дошел до отрисовки в режиме Wireframe, с режимом Flat забуксовал и забросил малость. Сейчас разобрался и обнаружил что у меня отрисовка идет очень медленно. Это вопрос не к самой библиотеке - в ней есть функция void dsp3D_LL_drawPoint(uint32_t x, uint32_t y, color32_t color) { if(x < minX) minX = x; if(x > maxX) maxX = x; if(y < minY) minY = y; if(y > maxY) maxY = y; // YOUR IMPLEMENTATION } Где нужно прописать свой код вывода точки. Я вывожу прямоугольник с размерами 1х1 oid TFT_FillRectangle(uint16_t x1, uint16_t y1, uint16_t x2, uint16_t y2, uint32_t color) { #define swap(a,b) {int16_t t=a;a=b;b=t;} if(x1>x2) swap(x1,x2); if(y1>y2) swap(y1,y2); uint32_t addr=0; addr = hltdc.LayerCfg[0].FBStartAdress + 3*(y1*hltdc.LayerCfg[0].ImageWidth+x1); hdma2d.Init.Mode = DMA2D_R2M; hdma2d.Init.OutputOffset = hltdc.LayerCfg[0].ImageWidth - (x2-x1); if(HAL_DMA2D_Init(&hdma2d) == HAL_OK) { if(HAL_DMA2D_Start(&hdma2d, color, addr, x2-x1, y2-y1) == HAL_OK) { HAL_DMA2D_PollForTransfer(&hdma2d, 10); } } } Скажите, как можно сделать вывод точки рациональнее и изящнее?

Ужо разобрался. Следующий вопрос. Опять таки, если кто знает. Массив я создал - забил в него вертексы, назначил их граням, в режиме Wireframe рисует отлично. Хочу теперь запустить имеющуюся функцию отрисовки в режиме Flat и Gouraud. Для этого в массив к каждому вертексу нужно добавить нормали. Именно к вертексу, а не к грани. ДЛя вычисления нормали к грани там есть своя функция, но для этого в нее нужно ввести нормали вертексов.

Тихо сам с собою.... массив точек разбит на группы (FACES) по 3 точки, каждая группа - это треугольник. vertex_a, vertex_b, vertex_c - вершины треугольников a,b,c - некие индексы, которые показывают под каким номером в текущем FACE располагается точка. Но скажите, зачем это нужно для треугольника? Нет нужды указывать какая точка с какой соединяется, если их ТРИ. Кто что думает?

Черт.... помогите понять задумку автора библиотеки. С режимом точечной визуализации все понятно: numVert = dsp3dModel[0]; for(i = 0; i < numVert; i++) { vertex[0] = dsp3dModel[2 + i * 6 + 0]; vertex[1] = dsp3dModel[2 + i * 6 + 1]; vertex[2] = dsp3dModel[2 + i * 6 + 2]; dsp3D_projectVertex(vertex, coord); dsp3D_drawPoint((int32_t)coord[0], (int32_t)coord[1], LCD_COLOR_WHITE); } dsp3dModel - массив, в который записывается модель. dsp3dModel[0] - количество точек, dsp3dModel[2,3,4] - координаты первой точки, dsp3dModel[8,9,10] - координаты второй точки и так далее.... А вот с режимом WireFrame уже хитрости.... float32_t vertex_a[4]; float32_t vertex_b[4]; float32_t vertex_c[4]; numVert = dsp3dModel[0]; numFaces = dsp3dModel[1]; for(i = 0; i < numFaces; i++) { a = dsp3dModel[2 + numVert * 6 + i * 6 + 0]; b = dsp3dModel[2 + numVert * 6 + i * 6 + 1]; c = dsp3dModel[2 + numVert * 6 + i * 6 + 2]; RGBr = dsp3dModel[2 + numVert * 6 + i * 6 + 3]; RGBg = dsp3dModel[2 + numVert * 6 + i * 6 + 4]; RGBb = dsp3dModel[2 + numVert * 6 + i * 6 + 5]; vertex_a[0] = dsp3dModel[2 + a * 6 + 0]; vertex_a[1] = dsp3dModel[2 + a * 6 + 1]; vertex_a[2] = dsp3dModel[2 + a * 6 + 2]; vertex_b[0] = dsp3dModel[2 + b * 6 + 0]; vertex_b[1] = dsp3dModel[2 + b * 6 + 1]; vertex_b[2] = dsp3dModel[2 + b * 6 + 2]; vertex_c[0] = dsp3dModel[2 + c * 6 + 0]; vertex_c[1] = dsp3dModel[2 + c * 6 + 1]; vertex_c[2] = dsp3dModel[2 + c * 6 + 2]; vertex_c[3] = 0.0; dsp3D_projectVertex(vertex_a, coord_a); dsp3D_projectVertex(vertex_b, coord_b); dsp3D_projectVertex(vertex_c, coord_c); dsp3D_drawLine(coord_a[0], coord_a[1], coord_b[0], coord_b[1], ASSEMBLE_ARGB(0xFF, RGBr, RGBg, RGBb)); dsp3D_drawLine(coord_b[0], coord_b[1], coord_c[0], coord_c[1], ASSEMBLE_ARGB(0xFF, RGBr, RGBg, RGBb)); dsp3D_drawLine(coord_c[0], coord_c[1], coord_a[0], coord_a[1], ASSEMBLE_ARGB(0xFF, RGBr, RGBg, RGBb)); } Из кода понятно, что мы имеем дело уже не с массивом точек, а массивом поверхностей, каждая из которых описана 3-мя точками. Мне не совсем понятен смысл переменных a,b,c - для чего они? Я так понимаю, записаны они, судя по всему, в конце фрагмента, описывающего Face, перед цветом... По идее, для стройности массива они должны быть равны 0,1,2 соответственно? Тогда зачем под них выделены ячейки массива? Почему под каждый Vertex выделено 4 ячейки, а не 3?

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

Нарыл на просторах вот такую простую 3D библиотеку для STM32. Хотя она, в общем-то платформонезависимая, но автор запускал ее на STM32. Вот отличное видео Как подключить библиотеку, я думаю, разберусь, но вот что меня ввело в ступор, так это файл, заявленный как "утилита для импорта модели". Вот ссылка на нее, внутри код, на питоне что ли.... https://github.com/FabioRM/dsp3D/blob/master/utils/io_export_dsp3D.py Во что скормить этот файл, чтобы получить модельку?

Ну хорошо, а есть варианты железо+софт, которые можно купить и поставить на свою механику?

А что с ним не так? НУ если в двух словах, чего жизненно насущного он не способен осуществить? Какие ограничения? Грубо говоря, опишите плату, которую он не может "собрать"

Вот и я подумал.... у меня 3д принтер на ремнях - вроде бы ровную гладкую вертикальную стенку печатает. Да и при установке ведь погрешность допустима, за счет выравнивания при оплавлении.

Иногда задумываюсь о самоделке.. Есть же OpenPNP проект - софт, прошивки все есть. Головы, механика, все это покупается и собирается так же как и 3d принтер.... По крайней мере в этом случае точно знаешь, что за комплектующие стоят. Но мы отвлеклись - так это действительно правда, что ремни - не для 0402 и 0201?

Большинство бюджетных да и не очень бюджетных установщиков имеют привод на ремнях. Слышал такое мнение, что для установки компонентов 0402 и 0201 у ременных приводов принципиально низкая повторяемость и нужно искать установщик на ШВП. Правда ли это? P.S. Размышляя на эту тему, я пришел к мысли, что у ШВП может и высокая повторяемость, но может иметь место неравномерность по длине, чего принципиально не может быть у ременного привода (ну разве что шкив по окружности кривой) У кого какой опыт?

Настройки кубовские или, ваши?

Ну а если крайний вариант - серийник является ключом к шифру. И апдейт уникален. Тогда что?

Уникален не апдейт. Уникален бутлодер. Апдейт просто так не установишь в контрлллер, он зашифрован, а потому его можно выкладывать в сети. Расшифровывает прошивку бутлодер, его и нужно защитить. То есть мы делаем уникальным бутлодер, причем делаем это на этапе изготовления, один раз. Спаяли плату, бутлодер считал серийники флешки и контроллера, и поженил их. То есть записал по некоему адресу контрольную сумму из этих серийников. И если контроллер вздумает совершить прелюбодеяние с другой флешкой, то... То есть имеем дамп бутлодера, дизассемблируем и отламываем? В принципе, это просто, если догадаться, что она есть. Одно дело, когда у нас на экране компа выдается требование ввести пароль и мы знаем, что отлаживать и что перехватывать. Другое дело тут. Но это вопрос времени наверное.