Сам не разбираюсь в программировании, но очень болею за идею нового софта!
По работе общаюсь с программерами, если нужна помощь, могу передавать им вопросы, пересылать их ответы.
Pavel155, твой вопрос уже отправил.

Pavel155 писал(а):Подскажите литературу где почитать по посылке данных в МК.

При создании проекта настроить аппаратный модуль usart, после этого просто читать данные из буфера и использовать по своему усмотрению. Посмотреть пример можно здесь http://proavr.narod.ru/z5.htm

Pavel155 писал(а):Подскажите литературу где почитать по посылке данных в МК.

Про USART валом всего написано - гугл в помощь. Вот тебе кусок кода. В нем инициализация и простой обработчик прерывания, который по приходу байта записывает его в переменную curr_byte. Выдрал из своей программы, но вроде ничего не забыл.

Код: Выделить всё

volatile unsigned char curr_byte;    //Прерывание USART, байт пришел.  ISR(USARTRXC_vect)  {  curr_byte = UDR;  return;  }    //Основная программа  
int main(void)  {  //Иницилизация USART. Передача отключена.  #define XTAL 14745600L  #define baudrate 115200L  #define bauddivider (XTAL/(16*baudrate)-1)  #define HI(x) ((x)>>8)  #define LO(x) ((x)& 0xFF)    
UBRRL = LO(bauddivider);  UBRRH = HI(bauddivider);  UCSRA = 0;  UCSRB = 1<<RXEN|0<<TXEN|1<<RXCIE|0<<TXCIE;  UCSRC = 1<<URSEL|1<<UCSZ0|1<<UCSZ1;  }

(Добавление)
Вот пример получше нарыл. В зависимости от величины полученного однобайтного числа (00h-FFh) зажигает от одного до восьми светодиодов. Можно например профайлер сконфигурить на отправку оборотов в ком порт и будет шкала типа как в формуле 1. Я когда-то видос выкладывал. Только надо отправлять не абсолютную, а относительную величину. Реально можно скомпилировать и пробовать. Писал на авр студии.

Удачных экспериментов!

Код: Выделить всё

#include <avr/io.h>
#include <avr/interrupt.h>
#define RPMPort   PORTA
volatile unsigned char curr_byte;    
//Прерывание USART, байт пришел.
ISR(USARTRXC_vect)  {  curr_byte = UDR;  return;  }
void ShowRPMBar(unsigned char tr)  {  tr /= 0x1C;  char o;  o = 0xFF;  RPMPort = ~(o << tr);  }
int main(void)
{
#define XTAL 14745600L
#define baudrate 115200L
#define bauddivider (XTAL/(16*baudrate)-1)  #define HI(x) ((x)>>8)  #define LO(x) ((x)& 0xFF)    
UBRRL = LO(bauddivider);  UBRRH = HI(bauddivider);
UCSRA = 0;
UCSRB = 1<<RXEN|0<<TXEN|1<<RXCIE|0<<TXCIE;  UCSRC = 1<<URSEL|1<<UCSZ0|1<<UCSZ1;
DDRA = 0xFF;
PORTA = 0;
sei();    
while(1) {  ShowRPMBar(curr_byte);  }
}


Вот еще ссылочка http://chipenable.ru/index.php/p...-usart-uart.html


(Добавление)
У меня есть вариант временного решения. Основная задача я так понял - избавиться от "раскачек", которые возникают за счет некорректной работы обратной связи или за счет люфтов. В случае если используются асинхроники с редукторами, в идеале использовать считыватель с вала самого двигателя. Я уже использую энкодер и платку ардуино уно для снятия показаний с вала редуктора. Как уже писал есть минусы - при включении/выключении платформа должна быть в исходном состоянии, есть вероятность накапливания ошибок (если плата "пропускает" несколько сигналов с энкодера, а их всего 15 на 180гр.)

Хочу доработать программу и закрепить энкодер на вал асинхроника.
По моим расчетам 1500 об/мин=25 об/сек=25Гц, контроллер работает на 200 Гц низкая частота позволяет отфильтровывать дребезг и изменение положения вала энкодера не должно пройти незаметно.

Диапазон первичного вала редуктора 20х360=7200 гр, вторичного 180гр.
Что с энкодером - на 360 гр он выдает 15 импульсов (30 щелчков), т.е. на один импульс - 24гр. За 20 оборотов 300 импульсов
Диапазон контроллера 256 импульсов (от 0 до 255).
За шаг берем 1.
Диапазон первичного вала 24х256=6144 гр, вторичного 153,6гр. с точностью позиционирования 0,6 гр - вроде неплохо...

Наверняка бывают энкодеры на 24 щелчка, с таким диапазон можно приблизить к 180гр.

int brightness = 128; // начинаем с половины диапазона
int fadeAmount = 1; // шаг изменения
unsigned long currentTime;
unsigned long loopTime;
const int pin_A = 12; // pin 12
const int pin_B = 11; // pin 11
unsigned char encoder_A;
unsigned char encoder_B;
unsigned char encoder_A_prev=0;

void setup() {
// declare pin 9 to be an output:
pinMode(9, OUTPUT); // устанавливаем pin 9 как выход
pinMode(pin_A, INPUT);
pinMode(pin_B, INPUT);
currentTime = millis();
loopTime = currentTime;
}

void loop() {
currentTime = millis();
if(currentTime >= (loopTime + 5)){ // проверяем каждые 5мс (200 Гц)
encoder_A = digitalRead(pin_A); // считываем состояние выхода А энкодера
encoder_B = digitalRead(pin_B); // считываем состояние выхода А энкодера
if((!encoder_A) && (encoder_A_prev)){ // если состояние изменилось с положительного к нулю
if(encoder_B) {
// выход В в полож. сост., значит вращение по часовой стрелке
// увеличиваем напряжение на 9 ноге, не более чем до 255 импульсов
if(brightness + fadeAmount <= 255) brightness += fadeAmount;
}
else {
// выход В в 0 сост., значит вращение против часовой стрелки
// уменьшаем напряжение на 9 ноге, но не ниже 0
if(brightness - fadeAmount >= 0) brightness -= fadeAmount;
}

}
encoder_A_prev = encoder_A; // сохраняем значение А для следующего цикла

analogWrite(9, brightness); // устанавливаем напряжение на 9 ножку

loopTime = currentTime;
}
}

Осталось добиться, чтобы контроллер "помнил" состояние после снятия питания.
Мне подсказали библиотеку EEPROM:

#include <EEPROM.h>
int addr = 0; //адрес в EEPROM

void setup()
{
byte val = EEPROM.read(addr); // считываем значение из EEPROM
EEPROM.write(addr, val+1);// записываем значение в EEPROM
}

void loop()
{

}

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

AlexVr
Тока мне кажется это скетч для ардуино. Соответственно к ней оно и прикручивается. По поводу работы с энкодерами есть несколько отличных статей c реальными примерами на easyelectronics.ru.

Второй вопрос по поводу сохранения положения. От лукавого это. Если сие когда нить реализуется, то проблем с этой примочкой будет навалом,а если сим большой - то и травм .... гы-гы. Не проще ли просто при включении в одну сторону крутануться, а потом в другую и поделить это на два? Времени займет немного зато все надежно и без всяких глючных еепромов.

null писал(а):Тока мне кажется это скетч для ардуино.

Так у меня и есть ардуино.

null писал(а):Второй вопрос по поводу сохранения положения. От лукавого это. Если сие когда нить реализуется, то проблем с этой примочкой будет навалом,а если сим большой - то и травм .... гы-гы. Не проще ли просто при включении в одну сторону крутануться, а потом в другую и поделить это на два? Времени займет немного зато все надежно и без всяких глючных еепромов.

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

AlexVr писал(а):В моей конструкции травм при глюках не будет

Вот поэтому я в эту ветку и не писал, хотя я ее начал. У одного три мотора, у другого четыре энкодера, третий пишет еще че-та .... кароч каждый на себя тянет. Таким образом нормальные вещи не делаются. А по мне либо сделать хорошую вещь, либо за нее не браться вообще и пользоваться поделкой от Таноса. Что в общем я пока и делаю. У меня все работает и так.

AlexVr писал(а):Концевики тоже вещь, не добавляющая надежности.

Инженеры которые проектируют станки с ЧПУ об этом не знают

null писал(а):У меня все работает и так.

Можно только позавидовать.

Разве плохо, когда вариантов решения одной проблемы несколько?
Я сюда пишу в надежде, что это кому-то будет полезно, ну или по крайней мере моих ошибок не повторят. Сколько людьми грабель-то собрано на поделке Таноса, подвиг которого тем не менее никто еще не повторил.

Если в этой ветке нужны только готовые, проверенные решения - извините, не буду писать.

По концевикам - сам эксплуатирую 26 аттракционов в Сити-парке Град. Везде стоят сдвоенные безконтактные датчики, но бывают случаи... спасает механический буфер и отключение по току...

AlexVr писал(а):Если в этой ветке нужны только готовые, проверенные решения - извините, не буду писать.

Я не пытаюсь обидеть или упаси боже устранить кого либо с этого форума, наоборот форум существует для обмена идеями и опытом. В этой ветке я пытался объеденить участников для решения общего вопроса, а по итогу получается иначе. Например на первой странице мы определялись со средой разработки, а по итогу Павел решил что кодвижн круче, а ты решил что ардуино это проще и быстрее. В результате вы оба не имея опыта в программировании, пытаетесь решить одну и ту же проблему разными путями и инструментами, не имея возможности помочь друг другу. В общем так и выходит, каждый за себя.

а по итогу Павел решил что кодвижн круче

(((
На самом деле я так пытаюсь познать алгоритм контроллеров. Использование программы для меня не принципиально. А так как ветка встала на уровне разговоров, мне показалось, что всех устроил Танос. И я начал делать свою программу вместо Profiler.
Теперь время дошло для МК.

p.s. Если интересно, могу написать простую тестовую прогу, которая будет выдавать данные вместо сендера+профилера. (двигаешь ползунок, получаешь данные от 0 до 1024).

AlexVr писал(а):Я сюда пишу в надежде, что это кому-то будет полезно, ну или по крайней мере моих ошибок не повторят. Сколько людьми грабель-то собрано на поделке Таноса, подвиг которого тем не менее никто еще не повторил.

Если в этой ветке нужны только готовые, проверенные решения - извините, не буду писать.

Ни в коем случае не прекращай писать о процессе поиска альтернативной реализации сима. Твой сим - очень интересен, я- так слежу за изменениями, всё время что то новое. Это значит, что сим чем то не устраивает, или работает не как хотелось бы. Я верю, что в результате - будет результат!

дальше IMHO : ветка флеймовая получилась изначально, потому как симы разные у всех, и очень трудно найти вариант, устраивающий всех симеров.

Из полезного в этой ветке, пока понятно, что энкодер, самое лучшее решение (ты показал, что это работает).
С этим фактом не поспоришь - аналоговые решения (потенциометры, датчики холла) тут проигрывают по любому.
За калибровку при старте сима - я тоже согласен. проще калибровать запуск, когда будут всегда достоверные значения с простыми алгоритмами (посчитать текущие значения/2).

Техническое задание программисту пока выглядит- смутно, но, может быть, попробовать последовательно разработать его? Например, минимальный код:
1. Получить 1 параметр с тестовой проги/сендера (есть подспорье: тестовую прогу Pavel155, я уверен, - напишет).
2. Мигнуть светодиодом направления на контроллере.

Дальше будет проще, уже будет готовая "болванка" программы..

потом дописывать остальное.
Это, скорее всего, будет важный шаг в направлении задачи реализации альтернативного контроллера.

ОК! Разобрались

что-то не могу сделать UART на atmegu 8535

#include <avr/io.h>
#include <avr/iom8535.h>
#include <hd44780.h>


//#define F_CPU 1843200 // Частоста кварца
#define BAUD 115200 // Скорость порта
#define MYUBRR (((184320/(16*BAUD)))-1)

volatile unsigned char ReceivedByte;


int main(void)
{

/* Set baud rate */
UBRRH = (MYUBRR >> 8);
UBRRL = MYUBRR;
/* Enable receiver and transmitter */
UCSRB = (1<<RXEN)|(1<<TXEN);
/* Set frame format: 8data, 1stop bit */
UCSRC =(0<<USBS)|(3<<UCSZ0);

lcd_init();
lcd_clrscr();
lcd_puts("TEST UART");
lcd_goto(0x40);

while ( !( UCSRA & (1<<UDRE)) )
{
ReceivedByte = 'A';
lcd_puts(ReceivedByte);
}

;
UDR = ReceivedByte;

}

Pavel155
Правильность инициализации усарт и остального не проверял. Сразу бросается в глаза то, что при выходе из цикла while ты присваеваешь UDR значение переменной, а не наоборот. После чего выполнение программы завершается что тоже неверно, т.е. должен быть какой-то общий цикл. Кроме того по логике, после присвоения должна быть операция вывода на ЖК, а ее там нет. Т.е. ничего не происходит.

Второе это не совсем правильно тупо опрашивать регистры при каждом выполнении цикла - это слишком часто и отнимает лишнее время у процессора. Я тебе дал рабочий вариант на прерываниях, воспользуйся им. Если нужны пояснения - спрашивай.

UCSRC = 1<<URSEL|1<<UCSZ0|1<<UCSZ1;

Почему тут используется 2 bit на стоп ?

ShowRPMBar(curr_byte);
я так понимаю эта функция выводит текущий байт оборотов на порт А ?