Jump to content

    

Salamander

Участник*
  • Content Count

    554
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Salamander

  • Rank
    Знающий

Recent Profile Visitors

2034 profile views
  1. Поковырялся - заработала вторая микросхема, но все равно какая-то лажа. Пишет нормально. А вот при чтении данные одной микросхемы смещены относительно данных другой. На один байт. Иными словами, DummyCycles в норме должен быть 8. Тогда нормально читается первая микросхема. Если поставить 6, то вторая микросхема начинает выдавать данные несмещенные, но при этом смещение возникает в первой микросхеме.....
  2. Друзья, вчитайтесь в описание ситуации: Контроллер STM32H743, на контроллере установлена QSPI W25Q128 - работает как одна микросхема, так и в режиме DualFlash. Меняю память на MT25QL128. Микросхемы разные, но я настроил параметры так, чтобы они были универсальны - то есть, без изменений в коде меняешь W25Q на MT25Q - все работает. Но почему-то это прокатывает только для режима одной микросхемы. В режиме DualFlash работает только W25Q, если меняю на MT25Q - вторая микросхема работать отказывается, выдает 0x88. Думал, что неисправна микросхема - менял местами первую и вторую, как выяснилось - сбоит не конкретная микросхема, а конкретное место, то есть Flash_ID 2. Грешил на проблемы в контроллере или плате - повторюсь, стоит снять обе микросхемы Mt25Q и поставить w25q - все работает. В чем может быть проблема?
  3. Вычислять размер зума не умеет. Собственно так и сделал. 2 часа ковыряний, 2 чашки кофе и все работает, не без косяков пока, но принципиально задача с зумом решена. Теперь у меня как в том ролике
  4. Ахахах, уписаться можно)))) Сделал я как вы сказали - с численными значениями координат все нормально. Они меняются как надо. А смена направления вращения - это ИЛЛЮЗИЯ! Камера при переходе через горизонт почему-то переворачивается на 180 градусов вокруг оси, соответствующей направлению взгляда. И кубик, который только что "падал" от нас, начинает на нас "заваливаться". Да.... с этой то проблемой я разобрался, теперь нужно лезть в библиотеку и искать где там настройки поворота камеры.
  5. А вот и нет. Входной параметр у меня в норме. Смотрю его отладчиком Вот окончательный вариант dsp3D_setCameraPosition(10*arm_sin_f32(zenital)*arm_cos_f32(azimuthal), 10*arm_cos_f32(zenital), -10*arm_sin_f32(zenital)*arm_sin_f32(azimuthal)); // Перемещаем камеру (при этом сама камера всегда смотрит в точку 0,0,0) dsp3D_setLightPosition(10*arm_sin_f32(zenital)*arm_cos_f32(azimuthal), 10*arm_cos_f32(zenital), -10*arm_sin_f32(zenital)*arm_sin_f32(azimuthal)); // Перемещаем камеру (при этом сама камера всегда смотрит в точку 0,0,0) Смена направления у меня происходит как раз, когда значение zenital переходит через ноль. Блин.... так все правильно - Z у меня рассчитывается по формуле sin*sin, при отрицательном угле зенита оба синуса отрицательные, в произведении это дает плюс. Я понял.... надо в зависимости от полярности зенитного угла менять полярность Z
  6. Помогите мне разобраться с детекцией ZOOM in и ZOOM out. Вот даташитик https://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x16_registers.pdf Как засекать этот самый зум понятно - читаю GEST_ID по адресу 0x01, микросхема распознает оба направления зума. Возникает вопрос - как определить дельту, то есть насколько мы прозуммировали. И вот тут первый вопрос - я правильно понял, что микросхема это вычислять не умеет? Если нет, то ткните носом. Если не умеет, тогда как это сделать ручками? Вот предположим, прочли мы в регистре, что имеет место быть ZOOM in, прочли текущие координаты двух точек касания. А как понять, насколько проскользили пальцы, до момента детекции? Чтобы было с чем сравнивать и рассчитывать масштаб зума..... Есть у микры такой параметр - порог детекции ZOOM - он равен 50, то есть зум детектируется если пальцы скользят более чем на 50 точек по направлению друг к другу (или наоборот). Проскользили еще на 50 - еще одно событие зума. Но меня такой зум, с разрешением в 50 точек не устраивает. Одно дело порог распознавания 50, и совсем другое - разрешающая способность. У кого есть опыт? Ах, да, забыл. Странным кажется то, что если самому в непрерывном режиме мониторить координаты двух точек касания, то не составляет труда самому поймать событие ZOOM. Спрашивается - зачем тогда эта функция присутствует в микросхеме на аппаратном уровне? Так может все таки как-то можно величину зума вытащить из микросхемы?
  7. Вы уверены, что в этом случае будут какие-то проблемы помимо неправильного положения объекта перед камерой? Точнее в ошибке поворота, составляющей 90 градусов? Смотрите, я отклоняю камеру в зените на некий угол - отклоняю бесконечно, и неважно, что у меня идет после 360 - 361 или 1 - камера должна идти по кругу. У меня же почему то движение только в пределах полупериода, в следующем полупериоде направление движения меняется. Она самая http://900igr.net/up/datas/183262/021.jpg
  8. Сделал, работает. Не совсем так как думалось изначально - если камеру поднять высоко, то она по азимуту описывает воронку - но так даже лучше. Но все равно с зенитом фигня - не хочет камера подныривать по горизонтальную плоскость. То есть угол в -1 градус воспринимается как угол в 1 градус и так далее. Угол в 181 градус воспинимается как угол в 179 градусов
  9. Ага.... разница в том, что в моей библиотеке ось Z смотрит на экран, а в формуле - вверх. Переставил оси - вроде заработало почти как надо. Только вот зенит почему-то работает только в пределах 0-180 градусов.... пытаешься заглянуть под объект, при пересечении 0 или 180 градусов начинается вращение в обратную сторону. Это как побороть? dsp3D_setCameraPosition(10*arm_sin_f32(zenital)*arm_sin_f32(azimuthal), 10*arm_cos_f32(zenital), 10*arm_sin_f32(zenital)*arm_cos_f32(azimuthal)); Вот такая на данный момент формула
  10. Плоскость XY смотрит на меня Из нее же на меня направлена ось Z. В этом случае отличие способа отсчета должно сказаться лишь на том, куда будет смотреть камера при угле, скажем, 0 градусов - на "фасад" или на "крышу". Но на вращение то это не должно влиять. Вот видео поведения куба. Посмотрите как меняется его вращение при изменении азимута, вначале он наклоняется вокруг горизонтальной оси, а потом почему-то вращается вокруг вертикальной. https://cloud.mail.ru/public/whtu/BXQvRUxSV
  11. Добрый день, друзья. Есть у меня 3D библиотека, настроил я ее, нарисовал кубик. Теперь хочу его покрутить (при помощи сенсорного экрана). Вначале я крутил сам кубик, но не получил желаемого результата - стоит его горизонтальным движением пальца повернуть вокруг вертикальной оси, вместе с ним поворачивается и горизонтальная (что естественно), а когда после этого начинаешь водить пальцем вверх-вниз, он не заваливается взад-вперед относительно наблюдателя, а крутится вокруг изменившей свое пространственное положение горизонтальной оси (что, опять-таки, естественно). Я решил поступить по другому - вращать не объект, а перемещать камеру вокруг кубика. То есть точка прицела камеры всегда в координатах 0,0,0, а сама камера гуляет по поверхности сферы радиусом 10. Иными словами - ведешь по экрану вверх-вниз - меняется зенитный угол, ведешь вправо-влево - меняется азимут. Высчитываю по вот такой формуле В коде это выглядит так: azimuthal+=(float32_t)d_evt.getDeltaX()/495; // Преобразуем горизонтальный пробег пальца по экрану в приращение азимута zenital+=(float32_t)d_evt.getDeltaY()/445; // Преобразуем вертикальные пробег пальца по экрану в приращение зенитного угла dsp3D_setCameraPosition(10*arm_sin_f32(zenital)*arm_cos_f32(azimuthal), 10*arm_sin_f32(zenital)*arm_sin_f32(azimuthal), 10*arm_cos_f32(zenital)); // Перемещаем камеру (при этом сама камера всегда смотрит в точку 0,0,0) Вращение камеры почему-то неадекватное. Даже трудно описать в чем, но чем дальше поворачивается кубик, тем неадекватнее его реакция на движение. проверял отладкой преобразование пробега пальца по экрану в параметры azimuthal и zenital - оно адекватное. Саму камеру перемещал вверх-вниз, вправо-влево - тоже адекватно. Но она при этом движется во фронтальное плоскости перед объектом, что не соответствует желаемому. А желаемое - двигаться в пределах сферы, окружающей объект. В упор не вижу ошибки, в чем она может быть? взглянем, к примеру на формулу расчета Z - из нее вытекает, что Z зависит только от зенитного угла, но ведь это не так! Если камера, не меняя зенита, будет "водить хоровод" вокруг объекта, Z ведь должен меняться...
  12. Зачитано до дыр. У меня есть проект, сгенерированный кубом, на HAL. С этим проектом при миграции с W25Q на MT25Q нужно просто перепаять микросхему и, кажется, поменять DUMMY_CYCLES. Алогритм, то есть шаблон, работает с несколько другим кодом. Мне кажется, что проблема в самой библиотеке, а не в тактике работы с микросхемой. Короче, в новом кейле версии 5.33, есть DFP версии 2.7.0. А там наконец-то появились и алоритмы под H747 и исходники. Копну там.
  13. 3 день бьюсь, мозги уже опухли Вот функция void QSPI_WriteEnable(void) { QUADSPI_ComConfig_InitTypeDef QUADSPI_ComConfig_InitStructure; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_FMode = QUADSPI_ComConfig_FMode_Indirect_Write; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_DDRMode = QUADSPI_ComConfig_DDRMode_Disable; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_SIOOMode = QUADSPI_ComConfig_SIOOMode_Disable; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_DummyCycles = 0; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_ABSize = QUADSPI_ComConfig_ABSize_8bit; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_ADSize = QUADSPI_ComConfig_ADSize_24bit; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_DMode = QUADSPI_ComConfig_DMode_NoData; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_ADMode = QUADSPI_ComConfig_ADMode_NoAddress; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_ABMode = QUADSPI_ComConfig_ABMode_NoAlternateByte; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_IMode = QUADSPI_ComConfig_IMode_1Line; QUADSPI_SetFIFOThreshold(0); QUADSPI_SetDataLength(0); QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_Ins = WRITE_ENABLE_CMD ; QUADSPI_ComConfig_Init(&QUADSPI_ComConfig_InitStructure); while(QUADSPI_GetFlagStatus(QUADSPI_FLAG_BUSY)==SET); QUADSPI_AutoPollingMode_Config(0x02,0x02,QUADSPI_PMM_AND); QUADSPI_AutoPollingModeStopCmd(ENABLE); QUADSPI_SetDataLength(0x00); QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_FMode = QUADSPI_ComConfig_FMode_Auto_Polling; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_ADMode = QUADSPI_ComConfig_ADMode_NoAddress; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_DMode = QUADSPI_ComConfig_DMode_1Line; QUADSPI_ComConfig_InitStructure.QUADSPI_ComConfig_Ins = READ_STATUS_REGISTER_CMD; QUADSPI_ComConfig_Init(&QUADSPI_ComConfig_InitStructure); while(QUADSPI_GetFlagStatus(QUADSPI_FLAG_SM)==RESET); // ВОТ ТУТ ВИСНЕТ QUADSPI_ClearFlag(QUADSPI_FLAG_SM); QUADSPI_ClearFlag(QUADSPI_FLAG_TC); while(QUADSPI_GetFlagStatus(QUADSPI_FLAG_BUSY)==SET); } Виснет при проверке одного и флагов.... while(QUADSPI_GetFlagStatus(QUADSPI_FLAG_SM)==RESET); Сразу оговорюсь - эта функция прекрасно работала на связке F746+w25Q128 А я решил переехать на STM32H743+MT25QL128 - виснет, хоть ты тресни. Пока удалось только инициализировать память и включать MappedMode. Как с этим бороться?
  14. Но если вы, обратили внимание - эта ошибка во вех строках, в том числе и последующих, где нет base и bank volatile uint32_t *GPIOx_base = (volatile uint32_t *)((uintptr_t)base + (bank - 'A') * 0x400); volatile uint32_t *GPIOx_MODER = (volatile uint32_t *)((uintptr_t)GPIOx_base + 0x00); volatile uint32_t *GPIOx_OTYPER = (volatile uint32_t *)((uintptr_t)GPIOx_base + 0x04); volatile uint32_t *GPIOx_OSPEEDR = (volatile uint32_t *)((uintptr_t)GPIOx_base + 0x08); volatile uint32_t *GPIOx_PUPDR = (volatile uint32_t *)((uintptr_t)GPIOx_base + 0x0C); ПРокатило! Спасбио. Осталось проверить, работает ли)
  15. вот так void gpio_set(void *base, char bank, uint8_t port, uint8_t otype, uint8_t mode, uint8_t ospeed, uint8_t pupd) {