надо же... и я сделал аналогичные макросыCOKPOWEHEU писал(а): DDR_0( ENCODER_PIN1 ); //это мои хитрые макросы для расшифровки макроопределений наподобие (B,1) в PORTB, DDRB, PINB, 1
DDR_0( ENCODER_PIN2 ); //если кому будет надо скину их.
но, как мне кажется, мои поудобнее ваших будут. посмотрите сами (выкладываю файл целиком, но только начало у него более-менее завершенное, а остальное пока в стадии обдумывания целесообразности, хотя сам уже активно пользуюсь):
Код: Выделить всё
// Вспомогательные макросы для работы с AVR
#ifndef AVR_CONST_H_
#define AVR_CONST_H_
// вспомогательные общие макросы
#define _CONCAT_(x,y) x ## y
/// вспомогательный макрос слияния символов
#define CONCAT(y,x) _CONCAT_(y,x)
#define DDR(x) CONCAT(DDR,x)
#define PORT(x) CONCAT(PORT,x)
#define PIN(x) CONCAT(PIN,x)
/// макрос для определения функции-инициализатора (вызывается автоматически в секции .inix)
#define INIT(x) static void __attribute__((naked, used, section(".init" #x))) CONCAT(init, __COUNTER__) (void)
#define AUTOINIT() INIT(2)
/// макрос для определения компактной версии функции main()
#define MAIN() int __attribute__((OS_main)) main(void)
#define NOINIT __attribute__((section(".noinit")))
// совместимые типы для целых чисел
typedef uint8_t U8;
typedef uint16_t U16;
typedef uint32_t U32;
typedef int8_t S8;
typedef int16_t S16;
typedef int32_t S32;
// делители тактовой для АЦП
#define ADC_DIV_2 _BV(ADPS0)
#define ADC_DIV_4 _BV(ADPS1)
#define ADC_DIV_8 (_BV(ADBP0) | _BV(ADPS1))
#define ADC_DIV_16 _BV(ADPS2)
#define ADC_DIV_32 (_BV(ADPS0) | _BV(ADPS2))
#define ADC_DIV_64 (_BV(ADPS2) | _BV(ADPS1))
#define ADC_DIV_128 (_BV(ADPS0) | _BV(ADPS1) | _BV(ADPS2))
// события для автозапуска АЦП
/// непрерывный автозапуск
#define ADC_TRIG_FRUN 0
/// аналоговый компаратор
#define ADC_TRIG_ACOMP _BV(ADTS0)
/// запрос внешнего прерывания INT0
#define ADC_TRIG_INT0 _BV(ADTS1)
/// сравнение канала А нулевого таймера
#define ADC_TRIG_T0_COMPA (_BV(ADTS0) | _BV(ADTS1))
/// переполнение нулевого таймера
#define ADC_TRIG_T0_OVF _BV(ADTS2)
/// сравнение канала В первого таймера
#define ADC_TRIG_T1_COMPB (_BV(ADTS2) | _BV(ADTS0))
/// сравнение канала В нулевого таймера
#define ADC_TRIG_T0_COMPB ADC_TRIG_T1_COMPB
/// переполнение первого таймера
#define ADC_TRIG_T1_OVF (_BV(ADTS2) | _BV(ADTS1))
/// изменение состояния пинов
#define ADC_TRIG_PCI ADC_TRIG_T1_OVF
/// захват первого таймера
#define ADC_TRIG_T1_CAPTURE (_BV(ADTS2) | _BV(ADTS0) | _BV(ADTS1))
// каналы АЦП
#define ADC_0 0
#define ADC_1 1
#define ADC_2 2
#define ADC_3 3
#define ADC_4 4
#define ADC_5 5
#define ADC_6 6
#define ADC_7 7
#if defined(__AVR_ATmega88__) || defined(__AVR_ATmega48__) || defined(__AVR_ATmega168)
#define ADC_BANDGAP 15
#define ADC_GND 16
#endif
#if defined(__AVR_ATmega128__)
#define ADC_0_DIF_0_G10 8
#define ADC_1_DIF_0_G10 9
#define ADC_0_DIF_0_G200 10
#define ADC_1_DIF_0_G200 11
#define ADC_2_DIF_2_G10 12
#define ADC_3_DIF_2_G10 13
#define ADC_2_DIF_2_G20 14
#define ADC_3_DIF_2_G200 15
#define ADC_0_DIF_1_G1 16
#define ADC_1_DIF_1_G1 17
#define ADC_2_DIF_1_G1 18
#define ADC_3_DIF_1_G1 19
#define ADC_4_DIF_1_G1 20
#define ADC_5_DIF_1_G1 21
#define ADC_6_DIF_1_G1 22
#define ADC_7_DIF_1_G1 23
#define ADC_0_DIF_2_G1 24
#define ADC_1_DIF_2_G1 25
#define ADC_2_DIF_2_G1 26
#define ADC_3_DIF_2_G1 27
#define ADC_4_DIF_2_G1 28
#define ADC_5_DIF_2_G1 29
#define ADC_BANDGAP 30
#define ADC_GND 31
#endif
#if defined(__AVR_ATtiny26__)
#define ADC_REF_AVCC 0
#define ADC_REF_EXTERNAL _BV(REFS0)
#define ADC_REF_INT_NO_ECAP _BV(REFS1)
#define ADC_REF_INT_WITH_ECAP (_BV(REFS1) | _BV(REFS0))
#else
#define ADC_REF_EXTERNAL 0
#define ADC_REF_AVCC _BV(REFS0)
#define ADC_REF_INT_WITH_ECAP (_BV(REFS1) | _BV(REFS0))
#endif
// аналоговый компаратор - момент возникновения прерываний
#define AC_INT_ON_TOGGLE 0
#define AC_INT_ON_FALLING _BV(ACIS1)
#define AC_INT_ON_RISING (_BV(ACIS1) | _BV(ACIS0))
// таймеры
// предделители тактовой
#define TIMER_CLK_DIV_1 1
#define TIMER_CLK_DIV_8 2
#define TIMER_CLK_DIV_64 3
#define TIMER_CLK_DIV_256 4
#define TIMER_CLK_DIV_1024 5
#define TIMER_CLK_EXT_FALL 6
#define TIMER_CLK_EXT_RISE 7
#define TIMER_CLK_DIV(x) CONCAT(TIMER_CLK_DIV_,x)
// режимы работы выходов OCx - вместо параметра t ввести номер канала таймера,
// например 0 - нулевой таймер, 1А - первый таймер канал А
#define TIMER_OC_NONE(t) 0
#define TIMER_OC_TOGGLE(t) _BV(COM ## t ## 0)
#define TIMER_OC_CLEAR(t) _BV(COM ## t ## 1)
#define TIMER_OC_SET(t) _BV(COM ## t ## 0) | _BV(COM ## t ## 1)
// внешние прерывания - условия срабатывания
// вместо i поставить номер запроса прерывания 0 или 1
#define EXINT_LOWLEVEL(i) 0
#define EXINT_CHANGE(i) _BV(ISC ## i ## 0)
#define EXINT_FALLING(i) _BV(ISC ## i ## 1)
#define EXINT_RISING(i) _BV(ISC ## i ## 0) | _BV(ISC ## i ## 1)
// делители тактовой SPI
#define SPI_CLK_DIV_4 0
#define SPI_CLK_DIV_16 _BV(SPR0)
#define SPI_CLK_DIV_64 _BV(SPR1)
#define SPI_CLK_DIV_128 _BV(SPR0) | _BV(SPR1)
// модуль TWI
// предделитель тактовой
#define TWI_CLK_DIV_1 0
#define TWI_CLK_DIV_4 _BV(TWPS0)
#define TWI_CLK_DIV_16 _BV(TWPS1)
#define TWI_CLK_DIV_64 _BV(TWPS0) | _BV(TWPS1)
#endif /* AVR_CONST_H_ */
Код: Выделить всё
#include <avr/io.h>
#include "avr_helper.h"
#include "lcd.h"
#include "stdio.h"
MAIN(){
printf("Hello,\nWorld!");
}
Похожие у меня есть, но мне удобнее задавать букву и номер одним макросом, а не несколькими. Макросы настроек частот SPI, АЦП и т.д. конечно полезны, но я бы, наверное, вынес в отдельный файл. Можете посмотреть использование, да и реализацию моей версии.#define DDR(x) CONCAT(DDR,x)
#define PORT(x) CONCAT(PORT,x)
#define PIN(x) CONCAT(PIN,x)
Так явным образом и было, надо было только заглянуть под спойлер.COKPOWEHEU писал(а):но пнуть явным образом все равно лучше.
Ну, раз уж вы оба решили забежать вперед, приведу для Мikа свои пояснения.COKPOWEHEU писал(а):С объявлениями переменных вопрос сложный. Если уж делить логику на несколько файлов, стоит минимизировать количество связей, а это тоже непросто. Кстати, именно в данном случае может иметь смысл обойтись без *.c-файла, оставив всю логику в заголовке. Как я уже говорил, это применимо только когда этот заголовок подключается только в один файл исходного кода.
Код: Выделить всё
sr595.c -----------------------------------------------
// сообщаем, что текущий файл - это исходник модуля:
#define __SR595_MOD__
// теперь включаем объявления модуля:
#include "sr595.h"
----------------------------------------------- sr595.c
sr595.h -----------------------------------------------
...
#ifndef __SR595_MOD__
#define __Vstorage extern
#else
#define __Vstorage
#endif
__Vstorage unsigned char Encoder_State;
__Vstorage signed char Encoder_Summ;
__Vstorage unsigned char Encoder_NewState;
...
----------------------------------------------- sr595.h
вангую, что вы еще используете макросы для установки, сброса или переключения бита?COKPOWEHEU писал(а):но мне удобнее задавать букву и номер одним макросом, а не несколькими
тут, к сожалению, я противник такого подхода, потому ограничиваюсь только минимумом макросов. В некоторых случаях это допустимо. Скажем, дергать переферию из нескольких разных файлов исходного кода лично мне не представляется хорошей идеей. Кроме того, учитывая настройку портов через макросы, одинокий заголовочный файл подключать к нескольким проектам проще, чем парный (*.c + *.h). Впрочем, один раз я уже наступил на эти грабли, хотя пока и не выработал оптимальный для меня способ обхода.А вот насчет помещения кода в заголовочные файлы ("в данном случае может иметь смысл обойтись без *.c-файла, оставив всю логику в заголовке") - я принципиально против этого.
Прошу прощения, действительно проглядел первый пункт.Так явным образом и было, надо было только заглянуть под спойлер.
жизнь слишком коротка, чтобы рассматривать все кодыCOKPOWEHEU писал(а):А чего ванговать когда я пример кода выложил. Возьмите и посмотрите удобно это или нет.
Это субъективная оценка - без абсолютных, независимых от т.з. оценивающего, фактов. Я привел свои причины, по которым отказываюсь от таких "упрощений", и теперь каждый может примерить их к своей практике.COKPOWEHEU писал(а):В некоторых случаях это допустимо.
Не вижу связи с выделением функций работы с неким периферийным устройством в отдельный модуль. Более того, такое выделение именно затем и осуществляется, чтобы "дергать переферию" кодом, обособленным от остальных функций.COKPOWEHEU писал(а):Скажем, дергать переферию из нескольких разных файлов исходного кода лично мне не представляется хорошей идеей.
Вообще не понимаю в чем трудность: что включить в проект еще один файл, что вписать еще один #iclude - дело нескольких секунд, а разработка длится днями, неделями и даже месяцами... в чем экономия-то?COKPOWEHEU писал(а):одинокий заголовочный файл подключать к нескольким проектам проще, чем парный (*.c + *.h)
Кстати, там нужно транспонировать матрицу, на которой основан массив encoder_arr[16], так как координаты в матрице поменяны местами.COKPOWEHEU писал(а):когда я пример кода выложил
Код: Выделить всё
#include "Encoder.h"
...
Encoder();
А, так вот где эти goto понатыканы.Мikа писал(а):Далее хотелось бы несколько усложнить с программой динамической индикации, а именно при вызове функции передавать в неё переменную, которую необходимо разделить на отдельные символы и в последствии вывести их на индикатор.
Да, это конечно делается не так. Не видел той замены, но на первый взгляд, объем не д.б. вырасти.Мikа писал(а):Как я говорил, я заменил там goto на while и по занимаемой памяти оказалось больше, ...
Это "влечет за собой что-то страшное" не в языке Си, а в голове программиста.Мikа писал(а):И все же я не понимаю, почему это считается таким плохим, это же просто перевод программы на другую строку, или в Си это влечет за собой что-то страшное?
Структурное программирование - это результат большой работы по борьбе за создание такого процесса программирования, который приводит к наименьшей головной боли, как для создателя исходного кода, так и для тех, кто потом этот код будет поддерживать. Каждый элементарный кусок алгоритма должен быть переведен в соотвествующий ему элементарный оператор, что не только упрощает понимание логики программы, но и снижает вероятность внесения ошибки в алгоритм, во время его изменения. Вот Вы уже захотели выделить часть кода, формирующего число для отображения, в отдельную функцию (пусть она будет называться FormNum) - что если во время модификации, в тело функции будет перетащен этот участок кода без самой первой метки? Было так:Код: Выделить всё
int main()
{
unsigned int KoefficientSEC = Koefficient;
...
Sotni:
if (KoefficientSEC >= 100)
{
KoefficientSEC = KoefficientSEC - 100;
Sotni++;
goto Sotni;
}
Desyatki:
if (KoefficientSEC >= 10)
{
KoefficientSEC = KoefficientSEC - 10;
Desyatki++;
goto Desyatki;
}
Edinici:
if (KoefficientSEC >= 1)
{
KoefficientSEC = KoefficientSEC - 1;
Edinici++;
goto Edinici;
}
...
}Код: Выделить всё
void FormNum(uint16_t Counter)
{
if (Counter >= 100)
{
Counter = Counter - 100;
Sotni++;
goto Sotni;
}
Desyatki:
if (Counter >= 10)
{
Counter = Counter - 10;
Desyatki++;
goto Desyatki;
}
Edinici:
if (Counter >= 1)
{
Counter = Counter - 1;
Edinici++;
goto Edinici;
}
}
int main()
{
...
Sotni:
FormNum(Koefficient);
...
}Код: Выделить всё
int main()
{
...
Edinici = Desyatki = Sotni = 0;
while ( (Koefficient -= 100) >= 100 ) ++Sotni;
while ( (Koefficient -= 10) >= 10 ) ++Desyatki;
while ( (Koefficient -= 1) >= 1 ) ++Edinici; // а точнее : Edinici = Koefficient;
...
}Если уж заинтересовались, могли бы и посмотреть. К тому же код простой. Впрочем, дело ваше.жизнь слишком коротка, чтобы рассматривать все коды
Именно поэтому я не говорю так категорично: "нет так делать нельзя никогда и точка".Это субъективная оценка
В противном случае придется городить семафоры или еще какие способы разделения доступа, чтобы два куска не полезли одновременно.Не вижу связи с выделением функций работы с неким периферийным устройством в отдельный модуль.
А разница, если все равно не известно какой из выводов должен замыкаться раньше? Кому надо будет поменяет местами выводы или знак результата. Ну и использовал я не вашу матрицу, а пересчитал свою. Если они совпадают - хорошо, значит все правильно.Кстати, там нужно транспонировать матрицу, на которой основан массив encoder_arr[16], так как координаты в матрице поменяны местами.
Тогда бы уж ассемблерную вставку сделали, если гонитесь за оптимальностью.Как я говорил, я заменил там goto на while и по занимаемой памяти оказалось больше, т.к.к у меня были смнения, влезет ли программа в 2к флеш, я оставил как было
Хотелось бы посмотреть на результат.А это означает, что самое время перейти к "причесыванию" программы.
Код: Выделить всё
/*
* EncoderExternal.c
*
* Created: 04.04.2016 0:01:35
* Author : Михаил
*/
#include <avr/io.h>
#include "Encoder.h"
int main(void)
{
// Port D init
DDRD = 0x00;
getEncoderState(); // Получить состояние энкодера в первый раз
while (1)
{
Encoder();
}
}
Код: Выделить всё
#ifndef __Encoder_H__
#define __Encoder_H__
// Здесь нет никаких переменных, потому что функция пользууется только локальными переменными
void getEncoderState(void);
void Encoder(void);
#endif
Код: Выделить всё
#include <avr/io.h>
#include "Encoder.h"
static unsigned char Encoder_State = 0;
static signed char Encoder_Summ = 0;
static unsigned char Encoder_NewState = 0;
void getEncoderState(void) // Это нужно для того чтобы получить первое значение состояния энкодера при пуске программы
{
Encoder_State = PIND & 0x3;
}
void Encoder(void)
{
Encoder_NewState = PIND & 0x3;
if(Encoder_State != Encoder_NewState)
{
asm("cli"); //!
switch(Encoder_State)
{
case 2:
{
if(Encoder_NewState == 3) Encoder_Summ++;
if(Encoder_NewState == 0) Encoder_Summ--;
break;
}
case 0:
{
if(Encoder_NewState == 2) Encoder_Summ++;
if(Encoder_NewState == 1) Encoder_Summ--;
break;
}
case 1:
{
if(Encoder_NewState == 0) Encoder_Summ++;
if(Encoder_NewState == 3) Encoder_Summ--;
break;
}
case 3:
{
if(Encoder_NewState == 1) Encoder_Summ++;
if(Encoder_NewState == 2) Encoder_Summ--;
break;
}
}
if (Encoder_Summ == 4) // Увеличение значения числа
{
// Выполняемое действие 1
// В прицнципе здесь должна увеличиться или уменьшиться переменная, передаваемая из основновной программы, но как это сделать пока что не знаю
Encoder_Summ = 0;
}
if (Encoder_Summ == (-4)) // Уменьшение значения числа
{
// Выполняемое действие 2
// В прицнципе здесь должна увеличиться или уменьшиться переменная, передаваемая из основновной программы, но как это сделать пока что не знаю
Encoder_Summ = 0;
}
Encoder_State=Encoder_NewState;
asm("sei")
// Код здесь выполнится в любом случаае
}
}
Я для перевода чисел в двоичную систему нашёл программу TheLucentHexCalс простая прога, но гораздо удобнее калькулятора. Установки не требует. Для быстрого запуска закинул ярлык в папку system32 и вызываю её через Win+R.Мikа писал(а):..........
L.O.D, относительно перевода чисел в уме - я мел ввиду именно десятичные в двоичные. .......
Какое "два куска полезли одновременно", если цель выделения всей логики работы с периф.у-вом в отдельный модуль как раз в том и состоит, чтобы никто другой к этому п/у не обращался напрямую? Что-то Вы не договариваете, оттого я не могу понять, в чем состоят Ваши опасения и contra.COKPOWEHEU писал(а):В противном случае придется городить семафоры или еще какие способы разделения доступа, чтобы два куска не полезли одновременно.
Разница в том, что Вы пишете конкретному человеку (Mika) и он еще далеко не как рыба в воде в наших с Вами примерах кода, призванных помочь ему написать его функции правильнее, оптимальнее и т.д. Взяв Ваш вариант, он обнаружит, что все заработало строго наоборот и решит, что снова допустил ошибку, станет ее искать, потратит еще два дня неизвестно на что...COKPOWEHEU писал(а):А разница, если все равно не известно какой из выводов должен замыкаться раньше? Кому надо будет поменяет местами
На Си. Язык должен соответствовать задаче, а потому применять язык с высоким уровнем абстракции для программирования довольно простого контроллера - неадекватный подход. Кроме того, приступать к ООП, не освоившись еще с ФОП, несколько нерационально и самонадеянно. Как однажды сказал Иоанн Кронштадтский - глупо пытаться освоить высшую математику, не владея арифметикой. Он, правда, привел такое сравнение, говоря не о программировании, но мысль остается справедливой по отношению к любой области человеческой деятельности.Мikа писал(а):а на чем лучше писать программы для AVR? С или С++ ?
Он просто запрограммировал самостоятельно то, что делает компилятор, когда работает с двумерными массивами. Не во всех ситуациях правильно брать на себя эту работу, но для Вас будет правильно сначала понять мой код, заменяющий switch'и на извлечение из массива, а потом уже убедиться в том, что код COKPOWEHEU является разновидностью этой замены и увидеть тот хинт, который он применил. Не раскусите сами - стучитесь, но лучше сделать это самому - больше пользы, да и интеллектуальное удовлетворение получите.Мikа писал(а):файлы, в которых реализован Энкодер от COKPOWEHEU, там мало понятного для меня
Лично я настолько не сплю, что придется отложить рассмотрение на вечер.Мikа писал(а):Надеюсь, вы еще не спите
А с чего вы взяли что заработает наоборот? Я лично не возьмусь вот так, без исходных данных, гарантировать, что при подключении первого вывода энкодера (ага, первого с какой стороны?) к ENCODER_PIN_1 положительное направление будет соответствовать вращению по часовой стрелке (кто сказал что это удобнее?). Тут достаточно собрать схему и уже в железе смотреть чему соответствует вращение, при необходимости инвертировав программно.Взяв Ваш вариант, он обнаружит, что все заработало строго наоборот
Грубо говоря, да. Вот только битовая магия работает гораздо быстрее, чем "честная" работа с двумерным массивом. Правда, при составлении кода я шел немного с другой стороны. Чтобы определить направление вращения нужно знать текущее состояние (2 бита) и предыдущее (еще 2 бита). Комбинация этих четырех байт в 75% случаев однозначно соответствует углу поворота (переходы 00<->11 и 01<->10 правильно декодировать невозможно). Собираем эти две пары в одно четырехбитое число и используем его в качестве индекса массива. По сути тоже самое, но о двумерном массиве я тогда и не думал.Он просто запрограммировал самостоятельно то, что делает компилятор, когда работает с двумерными массивами.
Сравните с исходным кодом Mika и убедитесь.COKPOWEHEU писал(а):А с чего вы взяли что заработает наоборот?
Не о магии сейчас нужно заботиться, а о том, как Mika в этом разбираться будет.COKPOWEHEU писал(а):битовая магия работает гораздо быстрее, чем "честная" работа с двумерным массивом.