picc18 и TMR0

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

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

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

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

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

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

Hi Ruslan, hope you are having a nice day!

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

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

WBR, AVB

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

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

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

Hi Harry, hope you are having a nice day!

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

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

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

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

WBR, AVB

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

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

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

Hi Harry, hope you are having a nice day!

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

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

Hi Harry, hope you are having a nice day!

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

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

WBR, AVB

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

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

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

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

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

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

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

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

wbr,

Hi Harry, hope you are having a nice day!

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

HZ>

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

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

WBR, AVB

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

Hi Oleksandr, hope you are having a nice day!

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

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

WBR, AVB

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

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

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

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

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

Hello Alexey!

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

Roman

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

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

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

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

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

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

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

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

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

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

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