Програмирование pic на СИ.

[Аlex]

А если вас не затрудняет и имеете 9,71 - проиграйте.

Нет, хайтека не имеем. Уже давно. Перешёл на XC8.

[botchin]

Ну, я написал то, что наблюдал, делал и т.д. Уверяю вас, указатели могут иметь разнъе размеръ в HI-TECH 9-71a. И для меня ето бъло непонятно.

Если кто-то попробует - пусть напишет.

[Аlex]

Попробовал XC8. Да, действительно
Кот:

Код:

#include    <xc.h>

char *s1,*s2,*s3, ss [10];

void main(void){
   s1 =  ss ;
   s2 =  ss ;
   s3 =  ss ;

   #asm
      movlw _s3
   #endasm

*s2=10;
*s3=10;

while(1);
}


Дизасм :

Код:

1:                 #include    <xc.h>
2:                 
3:                 char *s1,*s2,*s3, ss [10];
4:                 
5:                 void main(void){
  07ED    3070     MOVLW 0x70
6:                    s1 =  ss ;
7:                    s2 =  ss ;
  07EE    00FC     MOVWF s2
8:                    s3 =  ss ;
  07EF    3070     MOVLW 0x70
  07F0    00FA     MOVWF s3
  07F1    3000     MOVLW 0
  07F2    00FB     MOVWF 0x7b
9:                 
10:                   #asm
11:                      movlw _s3
  07F3    307A     MOVLW 0x7a
12:                   #endasm
13:               
14:                *s2=10;
  07F4    087C     MOVF s2, W
  07F5    0086     MOVWF FSR1L
  07F6    300A     MOVLW 0xa
  07F7    0187     CLRF FSR1H
  07F8    0081     MOVWF INDF1
15:                *s3=10;
  07F9    087A     MOVF s3, W
  07FA    0086     MOVWF FSR1L
  07FB    087B     MOVF 0x7b, W
  07FC    0087     MOVWF FSR1H
  07FD    300A     MOVLW 0xa
  07FE    0081     MOVWF INDF1
16:               
17:                while(1);
  07FF    2FFF     GOTO 0x7ff


Очевидно, что для s3 используется 2 байта под адрес.
Причём, если убрать АСМ-вставку - используется 1 байт

Добавлено after 5 minutes 18 seconds:
Шайтанамэ

[botchin]

Я подумал, что хорошо будеть, если знаем об етой особености.
И как решают когда 1 байт и когда 2?
Да еще и не дали програмисту возможность указать каким бъть указателя!!!!

[Аlex]

Меня вот ещё что смущает.

Код:

  07EF    3070     MOVLW 0x70
  07F0    00FA     MOVWF s3
  07F1    3000     MOVLW 0
  07F2    00FB     MOVWF 0x7b


До этого момента, в аккумуляторе находится значение 0x70, зачем его ещё раз туда загонять ?
И для очистки 0x7B - две команды, вместо одной.

Вот тебе и PRO-оптимизация
Старый добрый хайтек STD-версий и то оптимизировал лучше.

[botchin]

Ето "не PRO" програмер сделает одной командой, а "PRO" двумя.

Лично я видел одно умножение на 1,2 (НДС) расписанное на 22 (двадцать две) страниц кода. А програмер написавшии ето бъл хорошим програмером.

[Zhuk72]

Доброго дня, коты!
Спаял я себе испытательный стенд на базе 18F14K50 в виде платы с МК, так называемым дисплеем от Nokia 3310 (который конечно же им не является), энкодер, фоторезистор и прочая мелочевка. В МК сидит загрузчик, соответственно прошивку гружу прямо с USB со смещением 0х1000. Все работает, дисплей рисуется, энкодер декодится, кнопки нажимаются.
Для чего мне это всё? Просто отработать некоторые навыки и получить алгоритмы, которые помогут и в дальнейшем послужить готовыми кусками, ну и в плане дальнейшего изучения Си.

Вот, например, хочется мне выводить на экран показания фоторезистора в какой-то определенной позиции, данные от ИК диода в другой и т.д. Графику умным образом порисовать. И хочется освоить структуры, юнионы. Как вы думаете, логично ли использовать их для задания знакоместа, координат, для индикации освещенности в виде прогресс-бара? Я пока только собираюсь это расписывать в виде кода и не хочется сразу попасть в тупиковую ветвь.

Спасибо!

Задача вывода на дисплей любой информации на самом деле универсальная в плане освоения, так что годится.
Я вот например встроенным отладчиком не пользуюсь, если подключен дисплей - всё что меня интересует вывожу на него.

[КРАМ]

хочется освоить структуры, юнионы. Как вы думаете, логично ли использовать их для ....

struct и union удобно использовать там, где имеются данные разных форматов, но относящихся к одному программному объекту и/или области памяти.
То есть на самом деле имеет место быть лишь улучшение читабельности кода, а не получение неких новых его свойств.

[Zhuk72]

То есть на самом деле имеет место быть лишь улучшение читабельности кода, а не получение неких новых его свойств.

Именно это и интересует, т.к. расписать код длиной с портянку могу и без структур (что, собственно говоря, и делаю пока). Но хочется извращенной компактности

[Аlex]

Ещё, плюс объединений переменных в структуры - обработка в функциях. Можно передавать указатель, как аргумент, вместо кучи переменных.

[ARV]

а еще плюс структур и объединений в том, что при использовании качественных IDE требуется помнить меньше имен переменных, т.к. IDE подсказывает их. например, если вы для своего проекта храните какие-то параметры в 10 переменных, вы сами должны помнить их имена, чтобы в нужных местах использовать. если же все они объединены в структуру, предположим, с названием config, то помнить вам надо только это имя, а поля структуры вам подскажет IDE сразу же после того, как введете точку (или стрелочку, если через указатель) после этого имени

[Аlex]

Ну да. Остаётся только поработать стрелочками и нажать энтер
Лень - двигатель прогресса

[Zhuk72]

а еще плюс структур и объединений в том, что при использовании качественных IDE требуется помнить меньше имен переменных, т.к. IDE подсказывает их.

Кстати да, я заметил это, когда использовал STATUSbits, сразу после точки мплаб предлагает список.
Стало быть и с пользовательскими объединениями так же будет? Надо заюзать, спасибо, хорошая наводка!

Добавлено after 8 minutes 50 seconds:
Попробовал, мне понравилось
Еще раз спасибо!

Добавлено after 27 minutes 21 second:
Однако поторопился я, не все так просто и радужно, т.к. компиляция не прошла.
В хелпе на ХС8 написано, что структуры не поддерживают тип bit, возможно только использование битовых полей. Углубляюсь в чтение.

[Аlex]

Поле можно сделать любого размера, хоть 1 бит, хоть 5, хоть 25 ....

[ARV]

структуры не поддерживают тип bit

если вас не прижмет реальность так сильно, что невозможно будет обойтись без НЕСТАНДАРТНЫХ типов для Си, - никогда их не используйте! bit - это нестандартный тип, в Си его не существует.

[Zhuk72]

Поле можно сделать любого размера, хоть 1 бит, хоть 5, хоть 25 ....

Можно, но такое struct leds {unsigned char cnt, pause; bit flash;}; написание он не воспринимает. Говорит, что "taking sizeof bit is illegal".

В другом проекте сейчас проверил struct pos {unsigned char x, y;}; у которого только байты.
На это объявление он смотрит благосклонно, а ругается на pos.x = 0 b pos.y = 0:

main.c:30: error: (192) undefined identifier "pos"
main.c:30: error: (196) struct/union required

ХС8 в качестве примера приводит такое написание:

struct {
unsigned lo : 1;
unsigned dummy : 6;
unsigned hi : 1;
} foo;

И в примечании указывает, что "Accessing bit-fields larger than a single bit can be very inefficient", что вполне логично.
Так что я наверное буду в таких структурах объявлять только битовые флаги.

bit - это нестандартный тип, в Си его не существует.

Я в курсе этого. Но тем не менее жить без них не могу
В Keil приходится обходится без него, но ХС8 с ним в ладах, потому и использую.

[Siarzhuk]

Стало быть и с пользовательскими объединениями так же будет? Надо заюзать, спасибо, хорошая наводка!

При прочих равных, union использовать кроме как для получения разных представлений для одних и тех-же данных я бы не рекомендовал. Проблема в неявности модификации - когда структуроподобные вызовы u.f1 = 1; и u.f2 = 2; выглядят как модификация разных полей, но на самом деле меняют одни и те-же данные. Если объёмы памяти позволяют - всему должно быть своё место. Даже если оригинальный автор и оптимизировал таким образом свою программу твёрдо зная что данные в union-е не пересекаются по времени - нет никакой гарантии, что в будущем тот-же автор не отрефакторит своё творение и данные пересекутся - подарив ему возможность провести "выходные в отладчике". А уж что и говорить за тех, кто будет рефакторить после него - уж они-то точно не преминут откопать эти грабли.

В хелпе на ХС8 написано, что структуры не поддерживают тип bit, возможно только использование битовых полей.

bit - в печку. Про битовые поля имейте ввиду, что под структуру будет выделено целое число байт даже если задействован один бит:

Код:

struct iS { int i : 1; } // sizeof(iS) == sizeof(int)
struct cS { char i : 1; } // sizeof(cS) == sizeof(char)


Ну и помните, что при оптимизации битовыми полями сегмента данных - страдает сегмент кода (читай производительность), за счёт большего количества операций по доступу к полям. Мало того - в зависимости от позиции битового поля в структуре - размер операций тоже может быть разным. Т.е. если с каким-то полем чаще работаем - можно также сэкономить байтики двигая поле в более выгодную позицию.

Добавлено after 9 minutes 26 seconds:

main.c:30: error: (192) undefined identifier "pos"

pos это не переменная, и даже не тип (в С) - а именно что НеизвестнАЯ ИдентификАтыръ.

Я в курсе этого. Но тем не менее жить без них не могу

Кстати, компилятор склеивает глобальные переменные типа bit в несколько более заметные для линкера сущности. Т.е. обращение с ними несёт такие-же накладные расходы как и с битовыми полями.

[Zhuk72]

bit - в печку. Про битовые поля имейте ввиду, что под структуру будет выделено целое число байт даже если задействован один бит

Это я знаю. В принципе если я объявляю bit start1, stop2, wait254, imho323; то в итоге компилятор размещает их в одном байте. Идея объединить их в структур только для того, чтобы помочь склерозу, т.к. иной раз приходится лезть в объявления, чтобы вспомнить имя переменной.

Ну и помните, что при оптимизации битовыми полями сегмента данных - страдает сегмент кода (читай производительность), за счёт большего количества операций по доступу к полям. Мало того - в зависимости от позиции битового поля в структуре - размер операций тоже может быть разным.

Ну об этом я писал, вернее цитировал, выше. Но это в случае большего, чем 1, размера поля.
В случае однобитого поля код скомпилируется в обычные bsf/bcf и btfss/btfsc.

[ARV]

struct iS { int i : 1; } // sizeof(iS) == sizeof(int)

это на самом деле так? не 1 байт?

Кстати, компилятор склеивает глобальные переменные типа bit в несколько более заметные для линкера сущности. Т.е. обращение с ними несёт такие-же накладные расходы как и с битовыми полями.

скорее всего он задействует для этой цели аппаратные фичи кристалла. про PIC не скажу, а в MCS51 есть особые области ОЗУ с побитовой адресацией, и соответствующие однобитовые команды ассемблера. так что и тут речь скорее всего об этом - линкер отдыхает.