picc18 и TMR0

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Hi All !

Будьте внимательны!
Компилятор при заполнении двухбайтовых переменных сначала заполняет младший
байт, а потом старший.
Hу и что, скажете вы. И будете иногда неправы.
Потому что скажем при пользовании TMR0 в 16-битном режиме (PIC18F452) перенос
данных из регистра-защелки в старший байт происходит в момент записи в младший.

То есть, при команде
TMR0 = N;
в старший байт TMR0 попадет совсем не старший байт числа N. А то, что было
защелкнуто во время предыдущей такой команды.

Выход: не лениться и отдельно заполнять байты нужными данными:
TMR0H = lowbyte (N);
TMR0L = highbyte (N);

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

Может, и еще где есть критичные к порядку заполнения величины.


         WBRgrds
                   Ruslan



Re: picc18 и TMR0
Здраствуйте Ruslan,
*26.12.03* *11:55:50* Вы писали в *RU.EMBEDDED*
сообщение к *All*
о *"picc18 и TMR0"*.

 RM> Выход: не лениться и отдельно заполнять байты нужными данными:
 RM> TMR0H = lowbyte (N);
 RM> TMR0L = highbyte (N);

А причем тут лениться: контроллер то 8-разрядный и все SFR'ы тоже 8-разрядные.

 RM> Я тут на это нарвался и не сразу понял в чем дело.
 RM> Может, и еще где есть критичные к порядку заполнения величины.

Да все остальное вроде не больше 8 бит.


С уважением, Den


picc18 и TMR0
Hi Ruslan, hope you are having a nice day!


26 Дек 03, Ruslan Mohniuc wrote to All:

 RM> Компилятор при заполнении двухбайтовых переменных сначала заполняет
 RM> младший байт, а потом старший. Hу и что, скажете вы. И будете иногда
 RM> неправы. Потому что скажем при пользовании TMR0 в 16-битном режиме
 RM> (PIC18F452) перенос данных из регистра-защелки в старший байт
 RM> происходит в момент записи в младший.

Дело в том, что компилятору глубоко наплевать, в какую ячейку памяти он пишет.
Он ничего не знает о таймерах и т.п.
И это правильно.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

picc18 и TMR0
Mon, 29 Dec 2003 22:56:30 +0300 Alexey V Bugrov wrote to Ruslan Mohniuc:


AV> 26 Дек 03, Ruslan Mohniuc wrote to All:

RM>> Компилятор при заполнении двухбайтовых переменных сначала заполняет
RM>> младший байт, а потом старший. Hу и что, скажете вы. И будете иногда
RM>> неправы. Потому что скажем при пользовании TMR0 в 16-битном режиме
RM>> (PIC18F452) перенос данных из регистра-защелки в старший байт
RM>> происходит в момент записи в младший.

AV> Дело в том, что компилятору глубоко наплевать, в какую ячейку памяти он
AV> пишет. Он ничего не знает о таймерах и т.п.


AV> И это правильно.
    ^^^^^^^^^^^^^^^

    А вот с этим трудно согласиться. Ведь от этого ничего, кроме
дополнительного головняка, нет. И, например, ИАРовский компилятор (для АВР) при
работе с таймерными регистрами соображает, что для целостности данных нужно
соблюдать порядок обращения к половинкам регистра, что он и делает.

--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: picc18 и TMR0
Hi Harry, hope you are having a nice day!


31 Дек 03, Harry Zhurov wrote to Alexey V Bugrov:

 AV>> т.к. действительно провоцирует ошибки _использования_, если бы
 AV>> были только декларации TMR0L и TMR0H, такой проблемы бы не было.

 HZ>     Это было бы так, если бы таймерные (и другие SFR) регистры были
 HZ> действительно задекларированы как ты описал, т.е. ничем бы не
 HZ> отличались от обычных переменных в памяти.

Именно так они задекларированы и они действительно не отличаются от остальных
переменных.

extern volatile near unsigned char       TMR0L;
extern volatile near unsigned            TMR0;
extern volatile near unsigned char       TMR0H;

Объявления производятся в асм-файле, который оттранслирован в объектник с
жесткой привязкой к физическим адресам, и
лежит в lib'е вместе со стартапом.

 HZ> Hо поскольку сами по себе
 HZ> SFR являются расширениями, не входящими в язык, то и поддержка их, и
 HZ> работа с ними тоже являются расширениями, и компилятор, разработанный
 HZ> для embedded процессора, по хорошему, должен бы их поддерживать.

Hету в mcc18 никаких расширений, кроме near/far и rom/ram. А в PIC16/17/18 все
SFR отмаплены в память (регистровый
файл).

 HZ> ИАРовский поддерживает. Там кроме прочего при декларации SFR еще
 HZ> указан их физический фиксированный адрес с помощью оператора @ (в
 HZ> более старых версиях использовались ключевые слова sfrb, sfrw
 HZ> и присваивание адреса с помощью обычного '='). Это дает, во-первых,
 HZ> возможность использовать более эффективные команды для работы с SFR (в
 HZ> АВР имеются специальные команды, которые эффективнее, чем команды
 HZ> работы с памятью), во-вторых, дает возможность прозрачно и безопасно
 HZ> работать с некоторыми SFR, как в случае с таймерными регистрами.

Hету никаких специальных команд в PICxx, начиная с PIC16. С точки зрения
пользователя это обычные ячейки памяти, хоть
на си, хоть на асме.

 HZ>     В итоге, при работе на EWAVR можно спокойно писать выражения типа:

 HZ>     OCR1A += 1000;

 HZ>     word t = TCNT1 + 100;

 HZ>     не опасаясь, что возникнут коллизии из-за несоблюдения порядка при
 HZ> попеременном считывании/записи половинок регистра, т.к. компилятор
 HZ> "знает" к какому регистру он обращается и как правильно с ним
 HZ> работать. За все время работы с EWAVR компиляторами еще с версии 1.30
 HZ> ни разу не возникло даже намека на какие-то проблемы - механизм
 HZ> обеспечивает прозначность работы в сочетании с безопасностью и без
 HZ> потери эффективности.

Хех. Просто это разные концепции. В случае с mcc18 компилятору ничего не нужно
знать о конкретном процессоре до тех
пор, пока архитектура памяти и система команд у него остается неизменной. И с
появлением новых процессоров далеко не
обязательно искать обновление.

 HZ>     Вот это я и имел в виду: компилятор должен поддерживать такие
 HZ> вещи, "и это правильно" (с)  :). Если тот, что указан в сабже, не
 HZ> поддерживает, то остается только посочувствовать его пользователям.

Hу это кому как. Мне нравятся компляторы без расширений и которые генерят
прозрачный код без лишнего интеллекта. :)

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

picc18 и TMR0
Fri, 02 Jan 2004 15:24:39 +0300 Alexey V Bugrov wrote to Harry Zhurov:

[...]

HZ>>     В итоге, при работе на EWAVR можно спокойно писать выражения типа:

HZ>>     OCR1A += 1000;

HZ>>     word t = TCNT1 + 100;

HZ>>     не опасаясь, что возникнут коллизии из-за несоблюдения порядка при
HZ>> попеременном считывании/записи половинок регистра, т.к. компилятор
HZ>> "знает" к какому регистру он обращается и как правильно с ним
HZ>> работать. За все время работы с EWAVR компиляторами еще с версии 1.30
HZ>> ни разу не возникло даже намека на какие-то проблемы - механизм
HZ>> обеспечивает прозначность работы в сочетании с безопасностью и без
HZ>> потери эффективности.

AV> Хех. Просто это разные концепции. В случае с mcc18 компилятору ничего не
AV> нужно знать о конкретном процессоре до тех
AV> пор, пока архитектура памяти и система команд у него остается неизменной. И
AV> с появлением новых процессоров далеко не
AV> обязательно искать обновление.

    На ИАРе ничего не мешает писать по mcc18'шному. Просто работаешь с
половинками точно также. Но с целыми регистрами работать удобнее. И не
ошибешься в отличие от.

HZ>>     Вот это я и имел в виду: компилятор должен поддерживать такие
HZ>> вещи, "и это правильно" (с)  :). Если тот, что указан в сабже, не
HZ>> поддерживает, то остается только посочувствовать его пользователям.

AV> Hу это кому как. Мне нравятся компляторы без расширений и которые генерят
AV> прозрачный код без лишнего интеллекта. :)

    Да, тут у нас предпочтения не совпадают: мне нравятся компиляторы, которые
генерят код, близкий к тому, который я сам написал бы руками. Пусть они даже
используют при этом "лишний интеллект". Но без дополнительных головняков с моей
стороны. В случае с таймерными регистрами это так.

    Кроме того, в эхотаге без расширений никак нельзя - возьми хотя бы
прерывания. Да и языковые сегодня volatile и const появились отнюдь не от
языкового пуризма, а исключительно для поддержки аппаратных особенностей
процессоров. И сегодня для поддержки размещения данных и работы с ними в ПЗУ на
процессорах с Гарвардской архитектурой просто необходимы соответствующие
расширения, и они есть. И сейчас развитие эхотажных компиляторов кроме
поддержки новых процессоров и улучшения кодогенерации идет по пути появления
расширений для поддержки тех или иных особенностей применения - например, для
поддержки тех же прерываний в вытесняющих ОС очень нужно расширение для
подавления пролога/эпилога. Такое расширение есть, например, в GCC (naked) и
должно скоро появиться в ИАРовских компиляторах. Т.ч. без расширений нам тут
никак не обойтись.

    Кстати, у ИАРа есть компилятор нового поколения для 18-х пиков, по отзывам,
вроде, очень неплохой. Если ты его еще не смотрел, может стОит обратить
внимание?

--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: picc18 и TMR0
Hi Harry, hope you are having a nice day!


03 Янв 04, Harry Zhurov wrote to Alexey V Bugrov:


 HZ>     Кстати, у ИАРа есть компилятор нового поколения для 18-х пиков, по
 HZ> отзывам, вроде, очень неплохой. Если ты его еще не смотрел, может
 HZ> стОит обратить внимание?

Пока не смотрел. Он умеет писать реентерабельный код, как mcc18? Для меня это
очень важно и именно поэтому я использую
именно его, а не хайтек.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

picc18 и TMR0
Sat, 03 Jan 2004 18:43:46 +0300 Alexey V Bugrov wrote to Harry Zhurov:

HZ>>     Кстати, у ИАРа есть компилятор нового поколения для 18-х пиков, по
HZ>> отзывам, вроде, очень неплохой. Если ты его еще не смотрел, может
HZ>> стОит обратить внимание?

AV> Пока не смотрел. Он умеет писать реентерабельный код, как mcc18? Для меня
AV> это очень важно и именно поэтому я использую
AV> именно его, а не хайтек.

    Достоверного ответа (по понятным причинам) у меня нет, но уверен, что
реентерабельный код он генерить умеет (все иаровские компиляторы, которые я
знаю, умеют это). Хотя лучше посмотреть в натуре... Посмотрел, вот фрагмент с

http://www.iar.com/Products?name=EWPIC18


    про компилятор

*******************************************************

C / Embedded C++ Compiler

- ISO/ANSI standard C and Embedded C++ Compiler

- Multiple levels of optimizations for code size and execution speed

- Extended keywords specific for the PIC18

- Built-in advanced chip-specific optimizer including data flow analyzer

- Easy and fast interrupt handling directly in C/EC++

- Static overlay and stack based code models

- Re-entrant code generation option

- User control of register usage for optimal performance

- Mixed C/EC++ and assembler listings

*******************************************************


    На их сайте лежит 30-дневный полнофункциональный триал (лекарство тоже
имеется). Ссылка на него на этой же странице. Пользоваться пакетом очень
легко - там простая оболочка с интуитивно понятным интерфейсом. Т.ч. в течение
максимум получаса можно сгородить тестовый проект и посмотреть и кодогенерацию,
и реентерабельность и другие фичи. Пакет включает в себя оболочку, ассемблер,
компилятор, линкер, библиотекарь, RTL и качественную документацию. Для людей
сделано... Единственно, вопросы могут быть к кодогенерации, но это уже надо
смотреть.

--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Re: picc18 и TMR0
4-Jan-04 08:24 Harry Zhurov wrote to Alexey V Bugrov:


HZ>     На их сайте лежит 30-дневный полнофункциональный триал (лекарство
 Есть заказ компакта, мне пришёл через недели две-три после заказа
(с месяц назад), там все софты (EWB, MakeAPP, VisualSTATE) для всех
процессоров.
 Если хочется "вразвалочку познакомиться", то это лучше, чем качать :-)

wbr,

--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: picc18 и TMR0
Hi Harry, hope you are having a nice day!


04 Янв 04, Harry Zhurov wrote to Alexey V Bugrov:


 HZ>     Достоверного ответа (по понятным причинам) у меня нет, но уверен,
 HZ> что реентерабельный код он генерить умеет (все иаровские компиляторы,
 HZ> которые я знаю, умеют это). Хотя лучше посмотреть в натуре...
 HZ> Посмотрел, вот фрагмент с

 HZ> http://www.iar.com/Products?name=EWPIC18


 HZ>     про компилятор

Угу, спасибо. Попробуем выкачать.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

Re: picc18 и TMR0
Hi Oleksandr, hope you are having a nice day!


04 Янв 04, Oleksandr Redchuk wrote to Alexey V Bugrov:

 HZ>>     Hа их сайте лежит 30-дневный полнофункциональный триал
 HZ>> (лекарство
 OR>  Есть заказ компакта, мне пришёл через недели две-три после заказа
 OR> (с месяц назад), там все софты (EWB, MakeAPP, VisualSTATE) для всех
 OR> процессоров.
 OR>  Если хочется "вразвалочку познакомиться", то это лучше, чем качать
 OR> :-)

О, это уже интереснее. Попробую заказать, может пришлют. А то 25 метров по
диалапу выкачивать тяжко.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

Re: picc18 и TMR0
Здраствуйте Alexey,
*05.01.04* *13:23:25* Вы писали в *RU.EMBEDDED*
сообщение к *Oleksandr Redchuk*
о *"picc18 и TMR0"*.

 AVB> О, это уже интереснее. Попробую заказать, может пришлют. А то 25 метров
 AVB> по диалапу выкачивать тяжко.

А если с компайлером Си, то и все 65 :(

С уважением, Den


Re: picc18 и TMR0
Hi Harry, hope you are having a nice day!


30 Дек 03, Harry Zhurov wrote to Alexey V Bugrov:


 AV>> Дело в том, что компилятору глубоко наплевать, в какую ячейку
 AV>> памяти он пишет. Он ничего не знает о таймерах и т.п.

 AV>> И это правильно.
 HZ>     ^^^^^^^^^^^^^^^

 HZ>     А вот с этим трудно согласиться. Ведь от этого ничего, кроме
 HZ> дополнительного головняка, нет. И, например, ИАРовский компилятор (для
 HZ> АВР) при работе с таймерными регистрами соображает, что для
 HZ> целостности данных нужно соблюдать порядок обращения к половинкам
 HZ> регистра, что он и делает.

Посмотри на проблему с другой стороны. Компилятор генерирует объектный файл,
где будут расположены переменные он не
знает. Для него регистр таймера всего лишь декларация переменной extern
volatile и не более. Ошибкой было декларировать
_целый_ 16-битный регистр таймера в стандартном хидере процессора, т.к.
действительно провоцирует ошибки
_использования_, если бы были только декларации TMR0L и TMR0H, такой проблемы
бы не было.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

picc18 и TMR0
Wed, 31 Dec 2003 01:14:34 +0300 Alexey V Bugrov wrote to Harry Zhurov:

AV>>> И это правильно.
HZ>>     ^^^^^^^^^^^^^^^

HZ>>     А вот с этим трудно согласиться. Ведь от этого ничего, кроме
HZ>> дополнительного головняка, нет. И, например, ИАРовский компилятор (для
HZ>> АВР) при работе с таймерными регистрами соображает, что для
HZ>> целостности данных нужно соблюдать порядок обращения к половинкам
HZ>> регистра, что он и делает.

AV> Посмотри на проблему с другой стороны. Компилятор генерирует объектный
AV> файл, где будут расположены переменные он не
AV> знает. Для него регистр таймера всего лишь декларация переменной extern
AV> volatile и не более. Ошибкой было декларировать
AV> _целый_ 16-битный регистр таймера в стандартном хидере процессора, т.к.
AV> действительно провоцирует ошибки
AV> _использования_, если бы были только декларации TMR0L и TMR0H, такой
AV> проблемы бы не было.

    Это было бы так, если бы таймерные (и другие SFR) регистры были
действительно задекларированы как ты описал, т.е. ничем бы не отличались от
обычных переменных в памяти. Но поскольку сами по себе SFR являются
расширениями, не входящими в язык, то и поддержка их, и работа с ними тоже
являются расширениями, и компилятор, разработанный для embedded процессора, по
хорошему, должен бы их поддерживать. ИАРовский поддерживает. Там кроме прочего
при декларации SFR еще указан их физический фиксированный адрес с помощью
оператора @ (в более старых версиях использовались ключевые слова sfrb, sfrw и
присваивание адреса с помощью обычного '='). Это дает, во-первых, возможность
использовать более эффективные команды для работы с SFR (в АВР имеются
специальные команды, которые эффективнее, чем команды работы с памятью),
во-вторых, дает возможность прозрачно и безопасно работать с некоторыми SFR,
как в случае с таймерными регистрами.

    В итоге, при работе на EWAVR можно спокойно писать выражения типа:

    OCR1A += 1000;

    word t = TCNT1 + 100;

    не опасаясь, что возникнут коллизии из-за несоблюдения порядка при
попеременном считывании/записи половинок регистра, т.к. компилятор "знает" к
какому регистру он обращается и как правильно с ним работать. За все время
работы с EWAVR компиляторами еще с версии 1.30 ни разу не возникло даже намека
на какие-то проблемы - механизм обеспечивает прозначность работы в сочетании с
безопасностью и без потери эффективности.

    Вот это я и имел в виду: компилятор должен поддерживать такие вещи, "и это
правильно" (с)  :). Если тот, что указан в сабже, не поддерживает, то остается
только посочувствовать его пользователям.

--
H.Z.

P.S. Пользуясь случаем: Всех с Новым Годом, до которого осталось (у нас) меньше
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline