attiny13 таймер то работает, то нет

[oleg_4rk]

Ну я так понимаю, что это может решиться переходом на хотя бы 4.6MHz. А лучше 9.6.

[Adrift]

[uquote="oleg_4rk",url="/forum/viewtopic.php?p=4642707#p4642707"]Ну я так понимаю, что это может решиться переходом на хотя бы 4.6MHz. А лучше 9.6.[/uquote]
Без разницы, хоть 9.6GHz будет, все равно пока прерывания выключены в обработчик не попадешь, но задержки будут реже и меньше.

[oleg_4rk]

О. Класс. Закомментировал pin_write() в программе и собрал с библиотекой. Вот такая фигня:



Третья строка это PB3. Касательно его в программе ничего нет.

Добавлено after 1 minute 6 seconds:
А нет. Утром добавил DDRB |= _BV(3); в начало, когда проверял sbi/cbi. Если это убрать, то перестаёт и таймер работать . Если вернуть, то картина как выше. Что за чудеса ?

Добавлено after 15 minutes 42 seconds:
[uquote="Adrift",url="/forum/viewtopic.php?p=4642709#p4642709"]Без разницы, хоть 9.6GHz будет, все равно пока прерывания выключены в обработчик не попадешь, но задержки будут реже и меньше.[/uquote]

Ну это да. Но, на arduino uno, которая с atmega328p на 16MHz, я не ловил такие задержки. У меня там и делитель побольше и OCR0A побольше (что бы те же 100мк сек были) и, если я правильно понимаю, тактов процессора хватает, что бы разрулить тело while() до срабатывания прерывания таймера (по крайней мере повторного).

[Adrift]

[uquote="oleg_4rk",url="/forum/viewtopic.php?p=4642710#p4642710"]Ну это да. Но, на arduino uno, которая с atmega328p на 16MHz, я не ловил такие задержки.[/uquote]
Разве на mega328 отключались прерывания? Да даже если отключались, на меге 16MHz, а на tiny13, я так понял, 2.4 MHz, значит задержки должны быть меньше в 6.7 раз.

[oleg_4rk]

Хм. Да. Ты прав. Давай ща попробую там.

UPD. Да. Всё норм. Чёткий меандр .

Добавлено after 20 minutes 47 seconds:
[uquote="Adrift",url="/forum/viewtopic.php?p=4642718#p4642718"]на меге 16MHz, а на tiny13, я так понял, 2.4 MHz[/uquote]

У меня дефолтная - 1.2MHz. Но провалы хрен бы с ним. Оно понятно. Выставлю 9.6 и норм будет. Тут же непонятная нестабильность, когда может вообще не быть тиков.

[Adrift]

[uquote="oleg_4rk",url="/forum/viewtopic.php?p=4642720#p4642720"]У меня дефолтная - 1.2MHz.[/uquote]
Тем более, разница в 13.3 раза, уменьши во столько раз провал и попробуй его разглядеть ) Выставь на меге в CLKPR деление на 16 и все станет видно.

[oleg_4rk]

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

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

        DDRB |= _BV(0)|_BV(1)|_BV(2);
        DDRB |= _BV(3);

        TCCR0B &= ~(1 << WGM02);
        TCCR0A &= ~((1 << WGM01) | (1 << WGM00));
        TCCR0A |= 2 << WGM00;
        TCCR0A &= ~((1 << COM0A1) | (1 << COM0A0));
        TCCR0A |= 0 << COM0A0;
        TCCR0B &= ~(3 << CS00);
        TCCR0B |= 2 << CS00;
        TIMSK0 &= ~(3 << TOIE0);
        TIMSK0 |= 2 << TOIE0;
        // ~100us
        OCR0A = 15;
        sei();
        asm("sbi %[io], %[bit]" :: [io] "I" (_SFR_IO_ADDR(PORTB)), [bit] "I" (3));
        while (1) {
                if (bit_is_set(SREG, 7))
                        PORTB |= _BV(1);
                else
                        PORTB &= ~(_BV(1));

                if (pwm_width > pwm_width_on)
                        pin_write(PIN_D2, 1);
                else if (pwm_width < pwm_width_off)
                        pin_write(PIN_D2, 0);
        }

Даёт такое:


Провалы большие - это я питание выключал. Такая фигня забавная в 3й строке(PB3). Выключишь/включишь - работает. А бывает и нет . От чего оно вкл/выкл делает я хз. В коде к нему обращение только до while 1 раз.

Добавлено after 4 minutes 35 seconds:
Во как надёргал питание :



Добавлено after 3 minutes 19 seconds:
Это что такое может быть в программе, что то так, то сяк выходит...

[Adrift]

А pin_write() в предварительно скомпилированной либе?

[oleg_4rk]

Ага. Таким же Makefile'ом.

[Adrift]

У меня два вопроса... Зачем это делать когда прога нормально не работает? И зачем это делать вообще когда-либо? ) Сначала добейся нормальной работы собирая все напрямую из исходников.

[oleg_4rk]

Зачем выносить общие часто используемые функции в библиотеку ?
Проект изначально делался для другого МК, побольше и тестился на нём (по разным причинам), но т.к. он достаточно прост и мал, то сейчас решено его перенести на attiny13. До этого он нормально работал. И т.к. всплыли глюки, то начали копаться, убирать лишнее. То, что осталось - здесь. А что, есть какие-то известные проблемы у avr-gcc с линковкой с библиотеками? Так-то с точки зрения компилятора разницы быть не должно вынимать .o из библиотеки или брать тут рядом, от слова совсем. И теперь уже вопрос в том, что это за глюк. Ибо если дело в либе, то ошибка и в других проектах с другими МК тоже.

Добавлено after 6 minutes 16 seconds:
[uquote="Adrift",url="/forum/viewtopic.php?p=4642772#p4642772"]Сначала добейся нормальной работы собирая все напрямую из исходников.[/uquote]

На данный момент, без библиотеки, всё работает нормально.

[Martian]

Ошибка точно не в "либе". Она не может быть у того, кто начальную инициализацию делает через ИЛИ и три страницы мусолит пустяковую проблему, возникшую по вине столь всего многого

[oleg_4rk]

Дурачок ты конечно, Martian, такой, что пипец... Что ты доеб#лся до этих ИЛИ? Чего они тебе покоя не дают? Ошибка в них? Нет. Ну и какого рожна ты до них докопался. Ты совсем дурак что ли? Там вначале был другой код. Там были мои pin_mode(), там было куча всего и я выбросил лишнее и развернул pin_mode() и заменил на код, который внутри был(за выбросом лишнего), что бы придурки разные мне потом не говорили, что настолько оно херовое и ошибка точно в нём. Что бы не тратили ни своё, ни моё время. Но, как видишь, не помогло.

три страницы мусолит пустяковую проблему

Говорить что это пустяковая проблема можно только после того, как она известна. Пока не понятно где тут проблема.

[Adrift]

На данный момент, без библиотеки, всё работает нормально.

Значит у тебя есть два листинга на ассме, рабочей и не рабочей программы, осталось понять в чем отличия )

[oleg_4rk]

Ну типа того . Ща попробую проверить.

Добавлено after 6 minutes 43 seconds:
Пока ещё не проверял ассемблерный код, но заметил, что если убираю __attribute__((packed)) у структуры и enum'а, то вроде как всё норм становится.

[Adrift]

Структура pin_t состоит из 4-х uint8_t, там нет просветов и нечего упаковывать, а на enum этот атрибут в принципе не влияет.

Добавлено after 8 minutes 50 seconds:
А нет, там указатели, тогда да, packed влияет.
Кстати, вот почему там вызов функции длинного умножения появляется, из-за упаковки приходится множить на 7, а не 8, для тиньки возможно будет лучше без упаковки.

[oleg_4rk]

[uquote="Adrift",url="/forum/viewtopic.php?p=4642829#p4642829"]а на enum этот атрибут в принципе не влияет.[/uquote]

Влияет. Без этого enum будет 2х байтный. С packed, если кол-во элементов не превышает 256 - однобайтным (uint8_t).

[Adrift]

[uquote="oleg_4rk",url="/forum/viewtopic.php?p=4642899#p4642899"]Влияет. Без этого enum будет 2х байтный.[/uquote]
Действительно. Я уже забыл как это в С было, в С++ по умолчанию минимально возможный тип выбирается, помимо того, что его можно явно указать.

[oleg_4rk]

Проверил. Сравнил дизассемблерный вывод двух бинарников. Один с pin_write()/pin_toggle() в одном файле с main() и второй, где они отдельным .o-файлом. Размеры разные и расположение в файле разное, но сам код pin_write(), pin_toggle(), ISR, main() один в один (кроме некоторых адресов при переходах). main() даже по одному адресу и там и там расположен. При этом, первый бинарник работает как надо, второй нет . Хрень какая-то.
Сейчас бы дебаггер. Но платы для jtag или debugwire у меня нет, к сожаленью.

[Adrift]

[uquote="oleg_4rk",url="/forum/viewtopic.php?p=4643063#p4643063"]Сравнил дизассемблерный вывод двух бинарников. Один с pin_write()/pin_toggle() в одном файле с main() и второй, где они отдельным .o-файлом.[/uquote]
Покажи, может я что-то найду.