Создание собственной системы стабилизации
Всем привет. Имеется проблема. В инете ответа не нашел. Поэтому спрошу здесь у уважаемых коллег. Есть 407 процик. Подключен к нему через fsmc дисплей ssd1963(800x480). Имеется флеш память w25q128?, повешенная на spi1. Хотелось бы использовать dma для пересылки картинок на дисплей.
При выводе на экран получается, как будто на каждый байт принимаемый из spi принимается еще один байт и отправляется в дисплей. В итоге картинка в 2 раза больше и цвет конечно неправильный. Пробую из spi1 to Ram, а затем из Ram to Fsmc- по все отлично работает, но скорость увы падает. Заранее благодарю за помошь. Процедуру отправки прилагаю.
void stm32_dma_transfer( uint32_t Len )
{
uint32_t rw_workbyte[] = { 0xffff };
DMA_InitTypeDef DMA_InitStructure;
SPI_Cmd(SPI1, DISABLE);
DMA_DeInit(DMA2_Stream2);
DMA_DeInit(DMA2_Stream3);
while (DMA_GetCmdStatus(DMA2_Stream2) != DISABLE){}
while (DMA_GetCmdStatus(DMA2_Stream3) != DISABLE){}
DMA_InitStructure.DMA_Channel = DMA_Channel_3;
DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)(&(SPI1->DR));
DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte;
DMA_InitStructure.DMA_PeripheralInc= DMA_PeripheralInc_Disable;
DMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_Single;
DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord;
DMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single;
DMA_InitStructure.DMA_BufferSize = Len;
DMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
DMA_InitStructure.DMA_Priority = DMA_Priority_High;
DMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Disable;
DMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;
DMA_InitStructure.DMA_Memory0BaseAddr =0x60020000;
DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralToMemory;
DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Disable;
DMA_Init(DMA2_Stream2, &DMA_InitStructure);
DMA_InitStructure.DMA_Memory0BaseAddr = (uint32_t)rw_workbyte;
DMA_InitStructure.DMA_DIR = DMA_DIR_MemoryToPeripheral;
DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Disable;
DMA_Init(DMA2_Stream3, &DMA_InitStructure);
DMA_Cmd(DMA2_Stream2, ENABLE);
DMA_Cmd(DMA2_Stream3, ENABLE);
SPI_Cmd(SPI1, ENABLE);
SPI_I2S_DMACmd(SPI1, SPI_I2S_DMAReq_Tx, ENABLE);
SPI_I2S_DMACmd(SPI1, SPI_I2S_DMAReq_Rx, ENABLE);
while (DMA_GetFlagStatus(DMA2_Stream2,DMA_FLAG_TCIF2) == RESET) { ; }
DMA_Cmd(DMA2_Stream2, DISABLE);
DMA_Cmd(DMA2_Stream3, DISABLE);
SPI_I2S_DMACmd(SPI1, SPI_I2S_DMAReq_Rx | SPI_I2S_DMAReq_Tx, DISABLE);
DMA_ClearFlag(DMA2_Stream2,DMA_FLAG_TCIF2);
DMA_ClearFlag(DMA2_Stream3,DMA_FLAG_TCIF3);
}
DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte;
DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord;
я бы поковырялся в этом направлении
я бы поковырялся в этом направлении
Я в нем как раз и ковырялся, но выхода годного пока нет. Думал может кто то напрямую уже лил картинки и это работает. Короче буду копать дальше. Есть идея на время дма транзакции спиай переводить в 16 битный режим. Нужно попробовать сегодня.
Всем привет. Имеется проблема. В инете ответа не нашел.
Мне лично вот это не понятно:
DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Disable;
DMA_Init(DMA2_Stream3, &DMA_InitStructure);
картинка в одной ячейке памяти находится? Чтоб выгрузить массив из ОЗУ надо включить инкремент.
Мне лично вот это не понятно:
картинка в одной ячейке памяти находится? Чтоб выгрузить массив из ОЗУ надо включить инкремент.
Картинка принимается из спи и отправляется через fsmc на дисплей. Проблему решил - расширил спи до 16 бит и все поехало. Экран заливается за 150 мс. Причем если заливать из внутреннего флеша , то за 73мс . Так что проблему решил.
Картинка принимается из спи и отправляется через fsmc на дисплей.
Собственно наверно в этом проблема и была - синхронизация 2 потоков ПДП.
идея системы стабилизации.
мультиротор в форме гриба.
с ярко выраженным смещенным вниз центром тяжести.
все моторы работают от одного канала управления, через регуляторы оборотов хеликоптерного типа с говернором (стабилизатором оборотов)
для осуществления маневрирования используется поворот несущей части (шляпки гриба) как у дельтоплана. Поворот может осуществляться сервоприводами.
плюсы подобной системы в том что такая система будет проста и не завязана на глюки чип гироскопов и ошибки в коде полетных контроллеров.
вобщем некий такой мультироторный дельтоплан
😃
идея системы стабилизации.
мультиротор в форме гриба.
Алексей, в чем новизна? Собсно все игрушечные верты на этом принципе построены, за исключением того, что у них автомат перекоса.
Алексей, в чем новизна? Собсно все игрушечные верты на этом принципе построены, за исключением того, что у них автомат перекоса.
маштаб наверное только.
возможно будет экономичнее изза отсутствия необходимости перегазовок для достижения стабилизации
возможно использовать один или несколько двс
возможно будет экономичнее изза отсутствия необходимости перегазовок для достижения стабилизации
Дык это ничего не мешает делать в классической схеме коптера - ЦТ максимально вниз. Уменьшит перегазовки - увеличит КПД. Единственный минус - снижение манёвренности, но это актуально только для мелких, для которых КПД не так важен.
возможно использовать один или несколько двс
Это уже сложно, дорого и сильно специфично - проще использовать ДВС-вертолет.
проще использовать ДВС-вертолет.
у вертолетов свои проблемы.
все что больше 450 уже при малейшем соприкосновении с препятствием разлетаясь в куски представляет для себя смертельную угрозу для окружающих
слабое место - нужны надежные быстрые сервы, отказ любой приводит к полному уничтожению аппарата
много сложных тонких узлов требующих регулярного осмотра и обслуживания
Дык это ничего не мешает делать в классической схеме коптера - ЦТ максимально вниз. Уменьшит перегазовки - увеличит КПД. Единственный минус - снижение манёвренности, но это актуально только для мелких, для которых КПД не так важен.
точно, надо сделать такой мелкий
Господа, присматриваюсь к полетным контроллерам.
Поскольку я электронщик, имею желание сделать свой контроллер на STM32 и залить в него портированную под STM32 Multiwii прошивку.
Сравнивая параметры современных гироскопов, акселерометров и магнитометров, я обнаружил, что есть такая штука от ST - LSM9DS0 - гироскоп+акселерометр+магнитометр. У магнитометра чувствительность 80 мкГаусс против 5 мГаусс у HMC5883
Параметры акселерометра такие же как у MP6050, а вот гироскоп немного проигрывает - 8.5 гр/сек против 7.5 гр/мсек.
Что лучше взять? Стоит ли гнаться за крутейшим магнитометром?
есть такая штука от ST - LSM9DS0
Штука интересная, цена обнадеживает. Гдето видел сравнение шумов гиросокопа в покое с 6050 - чуток повыше, чем у MPU. Важнее думаю насколько восприимчив этот сенсор к вибрациям. Нужно пробовать.
Сергей, спасибо, но я видимо не поставил в своем посте акцент так как хотел. Магнитометр для чего нужен? Ведь не для удержания же положения, а для ориентации по курсу? Возможно для компенсации накопившейся ошибки гироскопа? Я вникаю в текст Multiwii, но пока этот момент мне неясен.
Сергей, спасибо, но я видимо не поставил в своем посте акцент так как хотел.
Хороший магнитометр всегда плюс, но хороший гироскоп и акселерометр важнее.
Господа, присматриваюсь к полетным контроллерам. Поскольку я электронщик, имею желание сделать свой контроллер на STM32 и залить в него портированную под STM32 Multiwii прошивку.
naze32 - ф103, у меня в гит под ф4 github.com/SergDoc/…/Release да и в самом вие там есть и под ф103 и под ф4 (ветка отдельная)
Параметры акселерометра такие же как у MP6050, а вот гироскоп немного проигрывает - 8.5 гр/сек против 7.5 гр/мсек.
аксель никто не тестировал - не скажу, но что-то мне подсказывает, что лучше мпу ставить)))
Мне вот интересно, разработчики Naze32 периодически обновляют версию платы. Они только разводку меняют? Ведь они разработчики только железа и они его подстраивают под уже имеющуюся прошивку. Или они ее допиливают? Ведь чтобы похвастаться чем-то новым нужно ее изменить. А если добавиь на плату что-то новое - то чтобы это заработало, прошивку по любому нужно менять.
Даташиты и схемы подключени на датчики есть. Что и как подключено к STM321F103 - можно понять из текста прошивки.
У кого-нибудь есть схема Naze32 - просто хочется глянуть, что у них там за ноу-хау?
P.S. Меня просто убила фраза на одном из форумов:
- Что купить SUPERPUPER (не помню название) или Naze32?
- ПОкупай SUPERPUPER - и ты получишь японское мегакачество.
Прошивка одна, контроллер один и тот же (кстати не японский) и датчики те же самые. Особых выкрутасов в разводке не требуется (частота сигнала всего 400 кГц. Чем Япония может быть лучше?
naze32 - ф103, у меня в гит под ф4 github.com/SergDoc/…/Release да и в самом вие там есть и под ф103 и под ф4 (ветка отдельная)
Скажите, а в чем необходимость портировать под F4?
Неужели F103 не справляется?
На 103 нет FPU.
Поскольку я электронщик, имею желание сделать свой контроллер на STM32 и залить в него портированную под STM32 Multiwii прошивку.
Дежавю, помниться эта ветка примерно с этого начиналась 😉 Правда, тогда про STM32 речи не было.
P.S. Меня просто убила фраза на одном из форумов:
- Что купить SUPERPUPER (не помню название) или Naze32?
- ПОкупай SUPERPUPER - и ты получишь японское мегакачество.
Женек, путаешь NAza и Naze32. В поиске увидишь, что это разные вещи.
Скажите, а в чем необходимость портировать под F4?
Необходимость (точнее желаемость 😉) в одном - не грустить о невозможности запустить (продвинутый) алго на существующем железе, когда ты его нашёл\понял\реализовал\придумал 😃 STM32F4 на сегодня наиболее подходящий проц (хотя я и f3 пользуюсь в полный рост 😉)
У кого-нибудь есть схема Naze32 - просто хочется глянуть, что у них там за ноу-хау?
Взял себе для изучения RaspberyPI B+, (stm надоел 😃), штучка прикольная… наверно будущее контроллеров полёта за такими (довольно небольшими по размеру/весу) платками, уравляющую программу теперь можно прям на “бортовом компьютере компилить” и не париться с прошивками/средами разработки, теперь только придется линукс ковырять…