CodeVision AVR в вопросах и ответах

[ARV]

ЗЫ: Вообще, как уже говорилось выше, правильным вариантом будет - использование своего отдельного буфера для индикации.

да ерунда эти советы

[Аlex]

Вот ещё вариант, попробуйте

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

void ind_update (void)
{
     static unsigned char count = 0; 
     
     PORTB = 0x00;
     
     PORTD = adc_data[count>>1];                                // выводим в порт код цифры (сегменты)

     if (count == 0) PORTB = (1<<0);             // определяем какой разряд должен гореть (ИМХО, тут копать нужно)
     if (count == 2) PORTB = (1<<1);             
     if (count == 4) PORTB = (1<<2);
     if (count == 6) PORTB = (1<<3);

 
     if(++count>=8)  count=0;                     // включаем следующий разряд
}

Тут уж точно есть гарантия, что пройдёт много времени между включениями индикаторов
Только частоту в 2 раза увеличьте, если мерцания будут.

[ARV]

Вот ещё вариант, попробуйте

Alex, это совет диверсанта или вы просто поторопились и наделали ошибок?

[Аlex]

Была только одна ошибка, уже её исправил
Ну а вообще, пример - как идея организации индикации со скважностью 50% Ну а "допилить" ТС'у код никто не мешает

[DataLife]

рассмотрим работу функции:
1. вход в функцию: индикатор отображает 0-й разряд, count = 1.
2. PORTB = 0; - гасим индикатор
3. цепочкой if-ов ВКЛЮЧАЕМ СЛЕДУЮЩИЙ разряд, т.е. зажигаем в 1-ом разряде то, что выводилось ранее в PORTD, т.е. инфу для 0-го разряда!!! это и есть подсветка соседнего знакоместа
4. PORTD = adc_data[count]; - обновляем сегменты, т.е. теперь в 1-ом знакоместе светится то, что и должно
5. вычисляем count для следующего знакоместа.

таким образом в предлагаемом алгоритме ГАРАНТИРУЕТСЯ подсветка сегментов!!!

Первая строчка в функции - объявленная переменная равна 0.
Пробовал я заменить выборку из if-ов на switch. Всё так же не работает.

Спойлер

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

void ind_update2 (void)
{             
PORTD = 0x00; // гасим все сегменты
PORTB = (1 << count); //выбираем следующий разряд
switch (count)
{
case 0:
PORTD = adc_data[0];             
break;
case 1:
PORTD = adc_data[1];
break;
case 2:
PORTD = adc_data[2]; 
break;
case 3:
PORTD = adc_data[3]; 
break;
}
count++;
if (count == 4) count = 0;
}

Этот фрагмент взят мной с другого кода, где индикация работает нормально.

По поводу этого кода:

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

static char count = 0;
// гасим все 
PORTB=0;
// вычисляем следующую позицию
if(++count >= 4) count = 0;
// обновляем сегменты
PORTD = adc_data[count];
// включаем индикацию
PORTB = 1 << count;

Попробовал ... "ноль на массу"...
Это уже ни в какие ворота не попадает ... Я всё больше становлюсь похож на свою аватарку...
Кто-то сглазил мой индикатор ...

PS. Аlex, а Ваш вариант работает. Засветок от соседних разрядов нет.

[Pink-Pank]

Я всё больше становлюсь похож на свою аватарку...

DataLife, я ж Вам сказал, сделайте прерывание от того же таймера по совпадению. В регистр сравнения внесите значение, к примеру, 0xCFFF. И в прерывании по совпадению выключайте все индикаторы

[Аlex]

PS. Аlex, а Ваш вариант работает. Засветок от соседних разрядов нет.

Какой конкретно ?

[Pink-Pank]

Скорее всего последний. 50/50 который

[Goodefine]

Ого, какой консилиум и все из-за неатомарности доступа
И еще, чего за бред:

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

volatile unsigned int ADC_volt; 
...
ADC_volt=(float)adc_tmp*4645/10000;
...
data_convert(ADC_volt);

где

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

void data_convert(unsigned int value)

?

[ARV]

Ого, какой консилиум и все из-за неатомарности доступа

где вы ее нашли? неатомарность могла бы визуально проявляться в засветке соседнего знакоместа "иногда"... а тут регулярная засветка - см. отчет о тесте со "счетчиком"

[Goodefine]

А вы не нашли? Подсказываю, что будет, когда в теле функции (места выбрать по желанию, благо их там много)

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

void data_convert(unsigned int value)
    {
     unsigned char tmp;   // переменная для временного хранения данных преобразования
     
     tmp = value / 1000;
     adc_data[0] = SEGMENTE[tmp];
     tmp = value % 1000 / 100;
     adc_data[1] = SEGMENTE[tmp];
     tmp = value % 100 / 10;
     adc_data[2] = SEGMENTE[tmp];
     tmp = value % 10;
     adc_data[3] = SEGMENTE[tmp];
     
    }

которая периодически вызывается из вечного цикла, будет срабатывать асинхронное по отношению к ее вызову прерывание с

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

PORTD = adc_data[count];

И правда, никакой неатомарности ))) А индикация молотит быстро, и на каком разряде это случится - чистая вероятность. И добавить возможное неявное приведение типов и связанные с этим эффекты. А так, все хорошо... все хорошо

[ARV]

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

я имел ввиду не наличие неатомарности доступа, а ее влияние.

допустим, в массив выведено 1234, а новое значение 5678. индикация уже отработала 12, в этот момент выводится новое значение... то есть на один цикл индикации мы увидим 1278, которое уже в следующем цикле сменится на 5678. в силу инерции зрения мы можем увидеть засветку старых показаний новыми, т.е. наблюдать (в течение доли секунды!) некую смесь из сегментов 1234 и 5678. однако автор программы утверждает, что у него имеется закономерность в засветке, причем регулярная, а не в момент смены показаний!

я по необходимости в течение нескольких лет сделал штук 15 проектов с 7-сегментной индикацией, никогда вопросу неатомарного доступа к массиву "экранной области" не уделял внимания, и никаких побочных эффектов не получал. это надуманная проблема: если смена показаний происходит с комфортной частотой (2 раза в секунду или менее), то из-за этого эффекта не наблюдается никакого дискомфорта. а если обновление показаний происходит чаще, то это раздражает существенно сильнее, особенно при смене показаний 2000-1999 (дрожание младшего бита)

[Goodefine]

допустим, в массив выведено 1234, а новое значение 5678. индикация уже отработала 12, в этот момент выводится новое значение... то есть на один цикл индикации мы увидим 1278, которое уже в следующем цикле сменится на 5678...

Я бы не стал так уверенно говорить, что там и как будет отображаться - компилятор вполне может использовать элементы массива и под промежуточные вычисления (деление и прочее), выкинув при этом переменную temp вообще. Добавьте неявное приведение типов (бред с флоатом). И не забыли какой компилятор? )) Насчет засветки - "фантомы" уже окончательно перешли в нее?

я по необходимости в течение нескольких лет сделал штук 15 проектов с 7-сегментной индикацией...

Тем не менее, это не дало вам возможности найти проблему здесь, по крайней мере быстро. А в электронике чудес не бывает, хотя в этой дискуссии уже прослеживается оспаривание данного факта.

[ARV]

Тем не менее, это не дало вам возможности найти проблему здесь, по крайней мере быстро. А в электронике чудес не бывает

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

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

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

[Аlex]

Тему вычистил без разборов, не смотря на какие-то информационные посты - разбираться в этом г... не хочется.
2 Pink-Pank. Ничего личного, но ещё раз будут подобные выходки с таким лексиконом, на Вас будут возложены "санкции" по запрету входа на форум ( страна, как раз соответствующая ). Если хотите языком потрепать и какого-нибудь куда-нибудь послать - идите в раздел "МЯУ", тут технический раздел, а не придворовая базарная скамейка.

Всем приятного времяпровождения на форуме

[HHIMERA]

Может не в тему...
Вот за что мне и нравятся STM32... Настроил ДМА и таймер... и забыл... Ни мерцаний, ни подсветки-засветки, ни гашений-зажиганий, никаких прерываний... Забил буфер данными и хоть кури... хоть спать ложись...

[amd9800]

А в чем особенность ДМА

[HHIMERA]

ДМА это Прямой Досуп к Памяти... Порты у STM32 адресуются как память... нужно только событие, которое инициирует процесс пересылки ДМА из памяти в порт... Для этого и нужен таймер... которым и определяется время регенерации...
Порты у STM32 16-ти битные... т.е. на один порт можно повесить семисегментник до 8-ми разрядов включительно... Т.к. сегменты и разряды на порт выплёвываются одновременно, то и гасить/зажигать смысла нет... В буфере порядок включения разрядов прописан изначально и не меняется... меняются только данные сегментов, при необходимости...
Вот и получается... свободнобегущий таймер пинает ДМА... а ДМА по кругу выплёвывает буфер в порт... всё...

[Onkel]

моему вопросу "повезло" - попал под безразборную разборку. повторю
atmega8a, codevision 2/03/4
включен прием uart по прерыванию, буфер 8 байт.
посылка данных идет по 8 байт.
примерно 1 на 50000 посылок имею следующий трабл
прерывание на 8 байт из посылки 8 байт не срабатывает по окончанию передачи этого байта, а срабатывает после передачи первого байта следующей посылки, смотрел по таймеру. От скорости и времени между посылками зависимости не обнаружено. Если отключить все в коде, кроме приема байтов, то все нормально - такого трабла нет. запретов прерывания в коде нет, только в самих сгенерированных codevision функциях get и char.
голову сломал, может это прирожденный баг code vision - один раз на 400 000 байт примерно не вызывается прерывание по приходу байта в uart?

[amd9800]

ДМА это Прямой Досуп к Памяти...

А какой средой разработки пользуйтесь под STM32

и есть библиотеки для протеуса с данным микроконтроллером ?