Изучение PIC C Compiler(CCS C)

[Wiza_]

Частенько встречаю выражения вида (1‹‹2). Особенно в прогах под АВР. В чем прикол? Не проще ли просто написать 4?

Это ANSI C. Стандарт известный любому компилятору. (в отличии от PORTB.0 например). 4 написать проще когда ядро 8 бит, а когда 32 бита и регистры тоже битовые - переучиваться или продолжать считать ?

Я еще могу понять вот такое: CSS = 1‹‹CS1;. А что будет, если переменная имеет значение больше 8?

Правильное использование типов переменных никто, нигде и никогда не отменял. Будьте внимательны чтобы не вылезти за пределы. В этом случае CS1 скорее всего константа. А выражение - установка пина или бита в регистре. Обратное ему: CSS &= ~(1‹‹CS1);

Одним словом подстановка результата сразу - не читабельна. Оцените по вложению - это конфигурирование одного пина у Cortex-M3 процессора

[Old_Monster]

У меня тут непонятка образовалась. Правда, скорее из плохого знания языка вероятного противника, нежели CCS.
Связываю ШИМ и аналоговый компаратор, чтобы ШИМ глушился по сработке компаратора.
Ну ладно, глушится.
Но когда компаратор возвращается в исходное состояние - шим не запускается.
Вот вопрос - так и должно быть?
12F1822

[Old_Monster]

Всё, сам нашел. Должен быть установлен P1RSEN

[Old_Monster]

Задача: дергаем ногой B0(GP0)
камень: 10F206
CCS: 4.130

#define SW PIN_B0
.....
5:                output_low(SW);
   058     CFB     MOVLW 0xfb
   059     006     TRIS 0x6
   05A     406     BCF 0x6, 0
46:                ..........
......
47:                output_HIGH(SW);
   05F     CFB     MOVLW 0xfb
   060     006     TRIS 0x6
   061     506     BSF 0x6, 0

В деталях: при попытке дрыгнуть B0 или B1 командой output_H/L(pin) нихрена не происходит, т.к. Перед сбросом/установкой в TRIS грузится 00001011 (MOVLW 0xfb + TRIS 0x6, левая "f" не играет, там неприменимые биты)
Обошел

void SW_ON(void)
{
#asm
BSF 6,0
#endasm
}
void SW_OFF(void)
{
#asm
BCF 6,0
#endasm
}

void main()
{
...
#ASM      
MOVLW 4 ;ручками, 0100-›W
TRIS 6     ;W-›TRIS
#endasm

Однако, с ногой B2 такого не происходит - см что загоняет в трис компилятор.

Тем не менее,
проверьте, пожалуйста кто-нибудь - получается ли после компиляции то же, что и у меня.
============================
решено, спасибо Eddy71. Надо использовать #USE_STANDART/FIXED/FAST

[Eddy71]

А компаратор кто отключать будет?

[Old_Monster]

по барабану. Но вообще-то не совсем идиот - отключен

[Eddy71]

Тогда гляньте, чего у Вас с настройками портов в шапке программы. Я про #use fixed_io, fast_io, standard_io.. Если стоит fast или fixed, компилятор не будет Ваши tris-ы трогать. Если standard, то при выводе будет настраивать на выход, при вводе на ввод самостоятельно. Сколько с мелкими игрался - никаких проблем с ногами не было. Для начала можно визард запустить а-ля моргание светодиодом, а затем модифицируя работающий проект своё чего-то сделать.

[Old_Monster]

Да, действительно, #USE_STANDART/FIXED/FAST решает проблему.
До этого момента ими не пользовался, как-то нормально всё работало.
Спасибо.

[vlad_ru]

Подскажите с таймером:
Частота кварца : 12800000
прескалер : setup_timer_2(T2_DIV_BY_16,21,15);
т.е . 16
частота 1 такта : 1/(12800000/4/16)= 5 микросекунд
Если у меня (фрагмент):
#int_CCP1 //// захват сигнала
void CCP1_isr(void)
{
time = CCPR1L;
TMR1L = 0; // очистить таймер1 (младший байт)
TMR1H = 0; // очистить таймер1 (старший байт)
и дальше
if((time›=30)&&(time‹=84))
то время : 30 это 30*5=150 микросекунд
84 это 84*5= 420 микросекунд
я правильно понимаю???

[Prototup]

Вернётся-ли значение порта в таком примере:

unsigned int8 data=0; //переменная содержащая значение порта В
OUTPUT_B(0b11110000);
data = input_b();

т.е будет ли data=0b11110000
а то чёго-то я зациклился