|
|
|
|
Vladikas: #bit GO/DONE = ADCON0.2 попробовал у себя. Ругается. Если убрать слэш - работает. |
|
|
Логично. Знаки арифметики в именах еще нигде употреблять не додумались |
|
|
Провёл несколько эксперементов. Получается примерно так, если определить в одном хидере и биты и байты, то он не компилится. Так же компилятор ругается на слэши. Если сделать два отдельных хидера и прописать оба в си файле, то всё вроде как получается кроме одного но! Строчки си файла: #include <16F873.h> #include <PIC16F873A_registers_byte.h> #include <PIC16F873A_registers_bit.h> #device ADC=10 //Ругается на эту строчку, если подключить PIC16F873A_registers_byte.h #use delay(clock=10000000) #fuses HS, NOWDT #byte ADCON0 = 0x1F #byte ADRESL = 0x9E int n; int_AD ............. Ругается так *** Error 23 "D:\1\ULevel\ULevel.c" Line 4(8,9): Can not change device type this far into the code *** Error 48 "D:\1\ULevel\ULevel.c" Line 4(9,12): Expecting a ( *** Error 43 "D:\1\ULevel\ULevel.c" Line 4(13,15): Expecting a declaration Если не подключать PIC16F873A_registers_byte.h или подключить этот хидер, но заремить строчку #device ADC = 10, то всё компилится. Тут я впадаю в ступор... -------------- Прилагаю проект. Путь d:\1\ULevel\ 158310.zip |
|
|
А если перенести строчку #device ADC=10 до инклюдов? (проект посмотреть пока не могу, я с кпк) |
|
|
Кстати, а в 16F873.h что? Не те же самые биты и байты? |
|
|
Так, кой чего прояснилось #include <16F873.h> #device ADC=10 #include <PIC16F873A_registers_byte.h> #include <PIC16F873A_registers_bit.h> Так компилится без ошибок. 16F873.h тоже содержит всякую полезную шнягу, но отличается от этих хидеров (в основном там дефайны, а не регистры). Настройка прерываний, таймеров, вачдога, компаратора... Пока не понимаю чем отличается #locate CCPR1 = 0x015 от #byte CCP_1= 0x15. Первое в моём хидере. По своему опыту знаю, что одни и те же байты можно называть по-разному в одной программе (хотя это ошибка, я так лажался). Тут получается то же самое. Стандартный хидер #byte CCP_1=0x15 #byte CCP_1_LOW= 0x15 #byte CCP_1_HIGH=0x16 #byte CCP_2=0x1B #byte CCP_2_LOW=0x1B #byte CCP_2_HIGH=0x1C Мой #locate CCPR1 = 0x015 #byte CCPR1H = 0x016 #locate CCPR2 = 0x01B #byte CCPR2H = 0x01C |
|
|
Vladikas: *** Error 23 "D:\1\ULevel\ULevel.c" Line 4(8,9): Can not change device type this far into the code .......................... но заремить строчку #device ADC = 10, то всё компилится похоже он не любит, когда директивы такого типа прячут во внешние файлы (нельзя изменить тип этой директивы издалека - что-то вроде того) А я вожусь с сообщением: Error 71 "F:\Electronic\Display\PCLCD.c" Line 597(0,1): Out of ROM, A segment or the program is too large MAIN Seg 00045-007FF, 0466 left, need 07A4 Seg 00800-00FFF, 0800 left, need 0844 Seg 01000-017FF, 0800 left, need 0844 ... Порылся в интернете и нашел упоминание директивы #separate, которая разрешает разбивать(?) функцию на сегменты в памяти МК (у меня МК PIC16F877A с длинной функцией main. Память МК занята на 20%). Посмотрел примеры: ... #separate void send_pulses() { ... но когда я пишу по аналогии у себя: .... #separate void main(void) { .... компилятор ругается: *** Error 166 "F:\Electronic\Display\PCLCD.c" Line 331(1,2): Invalid overload function MAIN пробовал убирать void, но результат тот же. Для других функций работает, а для main не хочет |
|
|
Почистил....... -------------- Сергей К: *** Error 166 "F:\Electronic\Display\PCLCD.c" Line 331(1,2): Invalid overload function MAIN Это выше моего понимания. Примерно как для средневекового человека молекулы... |
|
|
Сергей К: прячут во внешние файлы Так эта директива была в си файле, то есть в основном. Я вот ещё не проверял протеусом, работает ли прога. Может заодно мне кто подскажет как в MPLAB подать на ножку аналоговый сигнал, чёт у меня не получается это без протеуса. --------------- Проверил, работает всё. Все три хидера подключены, прога компилится, в протеусе работает. |
|
|
Vladikas: Может заодно мне кто подскажет как в MPLAB подать на ножку аналоговый сигнал Если посмотреть детальней в MPLAB-симуляторе, то можно увидеть примечание "не вся переферия моделируется, например АЦП" |
|
|
|
|