picc18 и TMR0

Hi All !

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

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

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

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

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

WBRgrds Ruslan

Reply to
Ruslan Mohniuc
Loading thread data ...

Здраствуйте 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

Reply to
Den Y. Borisov

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

Reply to
Alexey V Bugrov

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> И это правильно. ^^^^^^^^^^^^^^^

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

Reply to
Harry Zhurov

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

Reply to
Alexey V Bugrov

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 ни разу не возникло даже намека на какие-то проблемы - механизм обеспечивает прозначность работы в сочетании с безопасностью и без потери эффективности.

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

Reply to
Harry Zhurov

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

Reply to
Alexey V Bugrov

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-х пиков, по отзывам, вроде, очень неплохой. Если ты его еще не смотрел, может стОит обратить внимание?

Reply to
Harry Zhurov

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

Reply to
Alexey V Bugrov

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

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

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

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

formatting link

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

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

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 и качественную документацию. Для людей сделано... Единственно, вопросы могут быть к кодогенерации, но это уже надо смотреть.

Reply to
Harry Zhurov
4-Jan-04 08:24 Harry Zhurov wrote to Alexey V Bugrov:

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

wbr,

Reply to
Oleksandr Redchuk

Hi Harry, hope you are having a nice day!

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

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

HZ>

formatting link

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

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

WBR, AVB

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

Reply to
Alexey V Bugrov

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

Reply to
Alexey V Bugrov

Здраствуйте Alexey,

*05.01.04* *13:23:25* Вы писали в *RU.EMBEDDED* сообщение к *Oleksandr Redchuk* о *"picc18 и TMR0"*.

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

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

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

Reply to
Den Y. Borisov

Hello Alexey!

08 Jan 04 19:26, Alexey Boyko wrote to Harry Zhurov:

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

Roman

... Haven't you got a riff - haven't you got a song

Reply to
Roman Gorbunov

Привет, 12 января 2004 г., 21:52:00, ты писал(а):

RG> Речь шла о том что скажем в AVR кривой порядок записи в RG> 16-разрядные регистры таймеров. Т.е. нужно сначала писать в RG> старший а затем в младший.

Если бы только это. Я был неприятно удивлен случайно узнав, что адреса возвратов в аппаратном стеке хранятся в формате big-endian.

RG> А EWA90 как раз об этом знает. Дело не RG> в концепции, а в исключении для конкретных р-ров.

Всего хорошего.

Reply to
Alexey Krasnov

Здраствуйте Ruslan,

*30.12.03* *12:54:48* Вы писали в *RU.EMBEDDED* сообщение к *Den Y. Borisov* о *"picc18 и TMR0"*.

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

DB>> А причем тут лениться: контроллер то 8-разрядный и все SFR'ы тоже DB>> 8-разрядные. RM> Чего? Извини, я не понял что ты сказал и при чем здесь это?

Я говорил о том, что АЛУ контроллера может оперировать только 8-битными данными, и, не смотря на то, что компилятор Си может групировать некоторые регистры в один операнд (например TMR0L и TMR0H в TMR0), на самом деле данные будут записываться порциями по 8 бит.

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

Reply to
Den Y. Borisov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.