Proteus общие вопросы

[Halex07]

Остается тогда только вопрос №2.

2. Возможно ли оперативно переключать baud rate модели COMPIM из внешней программы? Или же в модели выставлять максимальную, а в программе менять на любую?

То ли я написал фигово??? То ли... кто то читает по диагонали через десять строк одну. Ну, то, что оперативно переключать невозможно, это наверное и ежу ясно. А где Вы в асинхронном интерфейсе видели изменение скорости в процессе обмена, что-то не припомню... Я вроде и примеры привел - что при этом произойдет (скриншот Рис.10-4-4). И еще про скорость из Вашего вопроса: "Или же в модели выставлять максимальную, а в программе менять на любую?" Приколюсь: в модели - это где и которую (их две) и в программе - это в какой, которая "внутри" или которая "снаружи".
ЗЫ Релевантность - если не понятен термин в переводе.

[Hmuryj_Mik]

hubble, Думаю, что правильнее найти другое решение, чем манимулировать скоростью обмена. Либо использовать "мост". Меня удивляет применение ISIS для решений в "лоб". Или это самоцель?

[hubble]

... и в программе - это в какой, которая "внутри" или которая "снаружи".

В программе, которая снаружи. Подсмотрел здесь. Ну да ладно. Скорее всего, действительно, по другому пути пойду.
Всем спасибо.

[JekaKey]

Всем привет!
Прошу помощи в нахождении истины работы с таймером TMR0 в pic16.
Какую бы частоту срабатывания я не назначил, итоговая частота срабатываний как-то отличается от нужной в меньшую сторону...
Вот например расчет для таймера на 12MHz.

Расчетная частота прерываний 60.000 Гц.
Настройка таймера следующая:

    //Timer0 config
    PS2 = 0; //Prescaler 1/2
    PS1 = 0;
    PS0 = 0;

    PSA = 0; // Prescaler Assignment bit for T0
    T0CS = 0; //Internal clock 

Код выполнения прерывания:

//See interrupt from timer0
    if (T0IE && T0IF) {
        RC4=~RC4; //Invert RC4 state
        TMR0 = 231; //60000Hz
        T0IF = 0; 

    } 

Однако если использовать любые инструменты анализа в протеусе, частота получается сильно меньше нужной.
Вот например картинка частотомера:

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

[Halex07]

Скорее всего, действительно, по другому пути пойду

Компас в дорогу...
Еще один... с крючком на линя.
А вообще, мониторинг 1-wire через COM-порт начинался еще во времена существования Dallas SemiКОНДУКТОРА. Вот еще одна статья многоуважаемого Л. Ридико десятилетней давности. Да и сейчас на сайте Максима полно всего по 1-wire, в том числе и SDK для разработчика. Ими же выпускался и готовый адаптер DS9097 под COM и тот самый мост DS2480B, про который уже чуть раньше упоминалось. Так что то, что Вы только "подсмотрели" известно уже более десятилетия.
ЗЫ Да, забыл добавить... А на хрена Вам для этих целей Протеус сдался? Эмулировать работу пары диодов и самой DS-ки, которой цена на любом китайском углу в пределах 1 голого Абамы? Это уже извращение в стиле российской стоматологии, ИМХО удаление зубов через ж..у.

[mimuh64]

Прошу помощи в нахождении истины работы с таймером TMR0 в pic16.

Посмотри вот это применительно к Протеусу. Скачай примеры.
Вот что еще (самое главное), при определенных (высоких) частотах прерывания, когда длительность периода соизмерима со временем выполнения самого прерывания добиться нужной частоты прерывания невозможно - это нужно учитывать.

[Halex07]

Подскажите где может быть косяк?

А каким он был по счету, и чем "заряжен", если по-вашему неоспоримо следующее:

У нас происходит инвертирование выхода 60000 раз в секунду, соответственно частота должна быть показана ровно 30000

И потом, экстрасенсов и собак натасканных на наркотики здесь нет, поэтому точно вычислить - где спрятан недокуренный косяк, может только тот, кто его заныкал. Когда наступит "просветление", ну или косяки закончатся, подумайте над следующими проблемами:
1. Как происходит вход-выход в прерывание. Пока вы считаете, что это нуль-транспортировка, ИМХО мгновенно...
2. В обработчике прерываний присутствуют некие "поползновения" - чё-то сравниваем, корячим порт, устанавливаем флаги. Видимо, по вашему, это тоже происходит супер-мгновенно, т.е. за 0.0 микро(нано-пико)секунд.
Ну и решайте сами, то-ли по дедушке Ленину "учиться, учиться и учиться", тогда в доки по PIC, то-ли косяки с анашой "курить, курить...", тогда в итоге к наркологу.

[JekaKey]

Halex07, спасибо, с упоением почитал ваш трактат о собаках, ленине и вреде курения =)
Собственно я именно поэтому и написал, что прошу помощи в том, что бы понять что я делаю не так. Я конечно понимаю, что все это не происходит мгновенно, однако я рассчитывал на то, что выполнение большинства команд занимает примерно 330 наносекунд, и получить четкую частоту в 31250 (именно к ней я стремлюсь) не будет такой большой проблемой, потому что это в 100 раз меньше чем время выполнения машинного цикла. Получается, сильно ошибался...
Таким образом не понятны так же реализации программный UART, где частоту таймера выставляют в 3 раза больше желаемой частоты UART (в моем случае мне прием не нужен, только передача), ведь при такой скорости дрейф таймера будет еще более значителен, и попасть в интервалы uart будет просто нельзя...

mimuh64, спасибо, полезная информация!

[Halex07]

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

При 12МГц тактовой да, но каких команд (???) - ассемблерных. Вы пишете на Asm? Что-то по коду не похоже... А значит компилятор с языка высокого уровня Ваши строчки разложит в элементарные команды своим, одному автору компиллятора известным способом, и не всегда самым коротким, что тоже не добавит скоропульности.
Еще раз подчеркиваю - прочитайте , ну хотя бы здесь раздел 11 про таймер 0. Я вижу по расчетам у Вас большие непонятки с тем, что Вы делаете. Обратите особое внимание на 11.4 и ответ 2 в 11.7.

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

А что Вы его так страшитесь? Во-первых ни о каком значительном дрейфе самого таймера речи быть не может при кварцованной частоте МК на передающей/приемной стороне. Все будет достаточно стабильно. Во-вторых если не "грузить апельсины бочками", т.е. передавать инфу короткими пакетами, то тем более не страшно. Не забывайте, что у Вас имеется стартовый и стоповый (-е) биты, которые маркируют начало-конец кадра. А набег, ну или по вашему "дрейф", фазы от бита к биту внутри кадра (вот тут он между приемником и передатчиком точно будет) не успеет превысить критического значения, когда начнут теряться биты.

[viczai1]

Для описания всех функций ног у мк STM32 не хватает знакомест для букв, приходится их дописывать как текстовые. Поднимал вопрос здесь, возможно не в этой теме, но на сайте, посоветовали убавить размер букв, но это не то. Для объяснения прикладываю фрагмент разрисовки схемы с STM32. Можете сами попробовать убавить размер или добавить букв в описании функций ноги какой нибудь.