menzoda писал(а):
А на что еще тратить процессорное время? Наверное круто сделать все через DMA и вообще не использовать вычислительные мощи ядра, но зачем? Даже Cortex-M0 на 50 МГц сможет спокойно управлять двигателем, используя ШИМ 20 КГц (а больше и не нужно), навскидку потратив не более 20% своих мощностей.
Можно и ШИМ использовать программный...
Правда для расчета векторов с учетом динамики двигателя требуется полноценное ДСП ядро...
Как то не очень понятно почему не использовать простой и эффективный инструмент, тем более, что он есть в наличии?
Ну хотя бы из эстетических соображений...
Я ведь уже сказал почему. uk8amk не надо особо управлять двигателем, поэтому можно DMA. Мне же всегда приходилось довольно активно им управлять, поэтому DMA я просто не мог использовать. Вот мне и непривычно видеть данное решение данной проблемы.
Если интересно, почему я в своих задачах не мог воспользоваться DMA, то скажи - я напишу, обсудим плюсы/минусы. Может я ошибаюсь и его можно было и там применить.
Теперь UEV генерируется только один раз за период.
Хотел про режимы ШИМ спросить: обычный и центральный.
У первого возможны косяки/всплески на граничных значениях счетчика(например 0 и 255), второй свободен от них, но частота в 2 раза ниже. Есть ли еще существенные различия? На рисунках больше различий не обнаружил.
На осциллографе будет линия(логич 1) с короткими иголками. Кстати тоже самое и на AVR.
Я вот сколько даташитов и апнотов прочитал, но так и не понял почему именно для двигателей надо использовать центральный ШИМ и чем он так кардинально отличается от обычного кроме двойного прохода.
Насчет симметричной и асимметричной ШИМ - ерунда, делай что легче. Вот отрывок из техасовского документа:
It has been shown that symmetric PWM signals generate fewer harmonics in the output currents and voltages.
То есть всего лишь будет меньше гармоник на выходе, обмотки будут меньше греться. Да и то, скорее всего вклад этих гармоник будет пренебрежимо мал по сравнению со всеми остальными.
UPD Насчет иголок. Ты про то, что при задании, например, нулевого значения в регистре сравнения таймера, на выходе не будет постоянного нуля, а будут "единичные" иголки каждый период ШИМ? Или что-то другое?
Не совсем понял про противофазный сигнал! можно поконкретнее? это я нарисовал сигнал одной фазы моста плюс и минус одной обмотки! формирует его один таймер.
optima писал(а):Не совсем понял про противофазный сигнал! можно поконкретнее? это я нарисовал сигнал одной фазы моста плюс и минус одной обмотки! формирует его один таймер.
Два сигнала никак не могут быть отнесены к одной фазе. Если речь идет о питании ОДНОЙ КАТУШКИ двигателя, то схема питания этой ОТДЕЛЬНО ВЗЯТОЙ катушки может быть однотактной или двухтактной (полумостовой или мостовой). Мостовая и полумостовая схемы получают АППАРАТНО СФОРМИРОВАННЫЕ сигналы ОДНОГО ШИМ-канала. И дед-тайм формируется так же аппаратно. К центральному расположению дьюти-цикла внутри периода ШИМ это не имеет ровно никакого отношения.
Вы пытаетесь использовать инструмент не по назначению.
Мостовое питание не требует никакой центровзвешенности. Оно формируется независимо от настроек самого ШИМа. Чисто аппаратно.
Управляйте чем угодно.
Вот картинки из даташита:
Первые две относятся к расположению OCxREF ВНУТРИ периода ШИМ, а третья показывает как соотносятся сигналы КОМПЛЕМЕНТАРНОГО выхода OCx и OCxN с сигналом OCxREF.
Для формирования мостовой схемы нужно ДВА КОМПЛЕМЕНТАРНЫХ ВЫХОДА. Где будут расположены комплементарные сигналы внутри периода ШИМ абсолютно безразлично. Пока это не касается ФУНКЦИОНАЛЬНОГО СИНТЕЗА СИГНАЛОВ с помощью ШИМ. Вот там центровзвешенность определит искажения синтезируемого сигнала на минимальном уровне...
Ну это всего лишь рисунки даташита!
А вот осциллограммы реально работающего драйвера
Подопытный ШД с углом поворота 0,9 режим полный шаг, контролируемый ток 3,2А напряжение 29 вольт, замер непосредственно на обмотке двигателя, синий луч + желтый -
первая осциллограмма двигатель стоит, остальные в первом ряду вращение 5 об.сек
второй ряд осциллограмм вращение 30 об.сек. И обратите внимание на отсутствие коммутационных помех!
В своей разработке я управлял шим программно. Времени предостаточно. Нужно учитывать инерцию якоря и всего механизма. А там постоянные времени единицы-десятки миллисекунд. Быстрое изменение шим не является необходимым.
подскажите по такому сообщению IAR
Fatal Error[Li004]: file "C:\ARMdemo\Debug\Obj\main.o" is not an object or archive file
Кто виноват и что дальше делать.
Стоит иар 6.5, отдельно копировал cmsis в папку с проектом наплясался с бубнами. Остался вот этот ерор - куда копать не знаю.
Здравствуйте!
Написал наконец первую программу к STM (диодиком мигать с кнопки) .
Она заработала, но по не совсем понятным для меня причинам (ибо делалась по шаблону от STMF1xx.).
Вот код:
#include "stm32f0xx.h"
#include "stm32f0xx_rcc.h"
#include "stm32f0xx_gpio.h"
void initAll()
{
//Объявляем переменную port типа GPIO_InitTypeDef
GPIO_InitTypeDef port;
//Это функция из файла stm32f10x_rcc.c, включает тактирование на GPIOA
//GPIOA сидит на шине APB2
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);
//Про эту функцию напишу чуть ниже
GPIO_StructInit(&port);
//Заполняем поля структуры нужными значениями
//Первый вывод – вход для обработки нажатия кнопки – PA1
port.GPIO_Mode = GPIO_Mode_IN;
port.GPIO_Pin = GPIO_Pin_1;
port.GPIO_Speed = GPIO_Speed_2MHz;
//А про эту функцию мы уже говорили
//Отметим только что один из параметров – указатель(!) на
//нашу структуру
GPIO_Init(GPIOA, &port);
port.GPIO_Mode = GPIO_Mode_OUT;
port.GPIO_Pin = GPIO_Pin_1;
port.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(GPIOB, &port);
}
/*******************************************************************/
int main()
{
//Объявляем переменную для хранения состояния кнопки
uint8_t buttonState = 0;
initAll();
while(1)
{
//С помощью функции из SPL считываем из внешнего мира
//состояние кнопки
buttonState = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_1);
if (buttonState == 1)
{
GPIO_SetBits(GPIOB, GPIO_Pin_1);
}
else
{
GPIO_ResetBits(GPIOB, GPIO_Pin_1);
}
}
}
Обязательно ли делать void initAll()? В CVAVR я просто после объявления переменных проводил инициализацию и всё...
Вот момент настройки пина1 порта B:
То есть, сначала мы проводим саму настройку, а потом объявляем порт, к которому эти настройки будут отнесены (GPIO_Init(GPIOB, &port);)?
А вообще, стоит ли использовать SPL? Раньше я как-то битами всё делал, и понятно всё было (это в АВР ), а тут ещё и библиотеку изучать приходится... Но вроде говорят удобно в дальнейшем...
Ах да... И ещё... Как заставить КЕЙЛ показывать мне состояние переменных во время отладки?