как быть? помнить о неявном приведении типов операндов в выражениях. ну и разбить сложную цепочку вычислений на несколько отдельных строк - оптимизатор все равно уберет избыточность, а свои ошибки найти будет проще. к тому же многократное обращение к функции чтения EEPROM - зачем?! можно же один раз считать в промежуточную переменную и затем ее использовать везде заодно и быстродействие повысится
запомните простые правила преобразования типов (вместо умножения любой арифметический знак):
int * int = int
int * char = int
char * char = int * int с последующим приведением к char
long * char = long
long * int = long
10 = int
10L = long
то есть для нужных переменных просто укажите подходящие типы, чтобы результат выражений не искажался в результате приведения типов, и проблема пропадет.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
ARV писал(а):разбить сложную цепочку вычислений на несколько отдельных строк <..> к тому же многократное обращение к функции чтения EEPROM - зачем?! можно же один раз считать в промежуточную переменную и затем ее использовать везде заодно и быстродействие повысится
Да, приведенный код можно считать хрестоматийным и на нем учить новичков : вот так не делайте
#define F_CPU 8000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#define DDR_SPI DDRB
#define MOSI 3
#define SCK 5
void SPI_MasterInit(void)
{
/* Установка MOSI, SS и SCK на вывод, все остальные на ввод */
DDR_SPI |= (1<<MOSI)|(1<<SCK);
/* Разрешение SPI в режиме мастера, установка скорости связи fck/4 */
SPCR |= (1<<SPE)|(1<<MSTR)|(1<<SPIE)|(1<<CPOL)|(1<<CPHA);
}
void SPI_MasterTransmit(char cData)
{
/* Запуск передачи данных */
SPDR = cData;
/* Ожидание завершения передачи данных */
while((SPSR & 0x80) != 0x80 );
}
int main(void)
{
sei();
_delay_ms(10);
SPI_MasterInit();
_delay_ms(1);
SPI_MasterTransmit(0xAA);
SPI_MasterTransmit(0xBB);
_delay_ms(1);
}
так тоже самое, похоже после первой отправки происходит зацыкливание передачи, + на SCK длительность одного из 8-ми импульсов плавающая
убрал прерывания, вроде заработало, но почему нет стабильности в длительности импульсов на SCK?
день добрый. как сделать разные задержки(разную скорость моргания) на двух портах, ставлю разные задержки в итоге получается поочередное мигание. частота стоит 4Мгц. Спойлер#include <avr/io.h>
#include <util/delay.h>
Ну так естественно, ведь в maine() обе функции мигания светодиодами вызываются по очереди одна за другой, с той только разницей, что у светодиодов будет отличаться время свечения/гашения.
По вопросу - если нужно действительно независимое мигание, надо избавляться от _delay_ms() и переходить к аппаратному таймеру.
Если без таймера, то делать delay, например, порядка сотой доли от времени зедаржки, а между вызовами этой delay декрементировать счетчики задержек каждого светодиода
Я имею ввиду чтобы не нужно было несколько раз писать имена переменных - сначала объявляя их в объявлении структуры, а потом опять писать их присваивая значения... или чтобы не было так: переменные перечисляются в одном месте, а присваивание в другом...
В общем, чтобы было наглядно, переменная и тут же присваивание...
Последний раз редактировалось shads Пт ноя 07, 2014 12:18:51, всего редактировалось 1 раз.
я вообще не понял, в чем смысл этой структуры - работать с ней все равно неудобно.
имхо, меню должно строиться на обезличенном наборе (массиве, списке) пунктов, а каждый пункт уже описывается структурой с полями "имя", "номер" и т.п.
в этом случае работа с любым пунктом меню из массива/списка ведется совершенно одинотипно. а в вашем случае уже нельзя, например, циклом перебрать все пункты и вывести их на дисплей...
возможно в силу своей ограниченности я чего-то недопонимаю, но покажите пример кода функции, которая по номеру пункта выберет из вашей структуры нужные поля...
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
ARV писал(а):возможно в силу своей ограниченности я чего-то недопонимаю, но покажите пример кода функции, которая по номеру пункта выберет из вашей структуры нужные поля...
Хе... возможно в силу своей ограниченности я чего то неправильно предполагаю ...
Но представлял себе это как то так: функция берет адрес начала структуры и перебором находит первый 0, это будет конец текста первой менюшки, соответственно к этому адресу прибавляем количество информационных байт (в нашем случае 2) и попадаем на начало второй менюшки... ну и т.д.
Хотя тут возможны грабли с особенностями четного выравнивания в AVR... но думаю и это можно разрулить...
А для чего весь этот ананизм ?
Создайте свой тип-структуру с данными, указателями на строки, и всякими другими свойствами. Объявите массив с этим типом и выбирайте из него по индексу необходимую структуру.
Собственно, это любезно продемонстрировал ARV несколькими постами выше.
shads писал(а):функция берет адрес начала структуры и перебором находит первый 0, это будет конец текста первой менюшки, соответственно к этому адресу прибавляем количество информационных байт (в нашем случае 2) и попадаем на начало второй менюшки... ну и т.д.
чем-то напоминает процесс вырезания гланд через прямую кишку...
когда-то я этими меню был маленько озабочен... если нужно - гуглите на моем сайте "TUI" - Text User Interface - делал библиотечку для меню на текстовом ЖКИ... среди основных фич:
- почти любая вложенность "подменю" (ограничение - объем памяти)
- возможность динамически менять текст пунктов меню (например, "подсветка вкл" на "подсветка выкл")
- возможность встраивания в меню числовых изменяемых параметров (например, "яркость 15%") - параметр меняется прямо в пункте меню
- ориентация на WinAVR
что-то там еще было, сейчас уже и не упомню...
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Спасибо, гляну...
Просто я и структуры особо не юзал и вложенные структуры (как вы предложили) не особо представляю как использовать... Вот то что пришло в голову, и выдал
В общем - попробую это правильно сделать... а не через прямую к....
ARV писал(а):"TUI" - Text User Interface - делал библиотечку для меню на текстовом ЖКИ...
Посмотрел... Сложновато честно говоря, для 0216 дисплея...
Может оно и универсально конечно, но у меня совершенно не нашлось сил вникать... лентяй наверное... или просто не привык вникать в чужую писанину ..
По твоему предложению - минус в том что поле uint8_t name[10]; должно быть равно максимально длинной записи... а я все это затеваю для NOKIA3310 дисплея... там как известно страница = 84 байта... я конечно буду применять уплотнение, но тем не менее, как то не оптимально получится если на каждую страницу будет отводится одинаково большое неэффективно используемое поле...
Например в моем случае эта проблема как раз решается тем что каждая строка индивидуальна... что в этом плане подскажете?
И еще вопросик... зачем у вас поле id ? Ведь порядковый номер пункта меню итак следует из нумерации в массиве...
Последний раз редактировалось shads Пт ноя 07, 2014 21:28:40, всего редактировалось 1 раз.
Аlex писал(а):Заюзать указатель на строку, вместо массива.
Это - да.... более менее компромиссный вариант...
но возникает неудобство редактиования\удаления\добавления страниц меню... т.к. тексты и параметры страниц - будут сгруппированы в разных местах...
В моем случае тоже есть две сущности, это 1) нумерация страниц (enum) и 2) само наполнение страниц с параметрами (по крайней мере все для каждой отдельной менюшки - держится в кучке)... Тоже конечно не фантан из-за enum... Но по крайней мере при редактировании одного параметра легко видны зависимости, т.к. все в кучке...
В идеале можно было бы (я имею ввиду мой случай) и от enum освободится и оставить только структуры с наполнением... и обращаться к ним через указатели... но в таком случае не организуешь в оперативке динамические массивы с переменными для каждой менюшки, все ручками придется прописывать...
shads писал(а):но в таком случае не организуешь в оперативке динамические массивы с переменными для каждой менюшки, все ручками придется прописывать...
А что если замучить malloc() / free() ?
Ведь даже в плюсах всякие классы, на подобии String, основаны на том же динамическом выделении/освобождении памяти.