Hi-tech для PIC10/12/16. Поиск лекарства

[PupaJr]

testerplus - Это хорошо что вы знаете подробно о глюках, а начинающему достаточно трудно понять в чём дело - явно правильный и компилируемый код отказывается работать - а просмотр дизассемблерного листинга целое дело... Хотя это у нас уже ОФФТОП.. Вот мой пример в главной программе:
if (V_sim)
{ тут код если этот бит =1 то..., а ставится этот бит в процедуре таймера
};

if (GPIO1) V_sim=1 // если пин =1 то бит его =1 - эта строка в проц. таймера

Так вот - если в главной ставлю не if (V_sim) а if (GPIO1) то в контролере неработает!!!! а естественно компилится нормально.

и ещё -
пишу кусок от общего кода:

TRISIO1=0;
TRISIO2=0;
TRISIO3=1;
GPIO1=1;
GPIO2=0;

получаю код длиной 768 байт, а если так:

GPIO1=1;
GPIO2=0
TRISIO1=0;
TRISIO2=0;
TRISIO3=1;

то код 780 байт!!!!!! это как так?????? причём в разных частях программы похожие участки дают разное число байт+-!!! А в 9.70 всего на 1 байт прироста давал. Смотрел листинг - он там крутит банки регистров, читает порты... короче полная дребедень... Может конечно я такой кривой ...
Так вот, новая версия всетаки получше будет...

[testerplus]

Так вот - если в главной ставлю не if (V_sim) а if (GPIO1) то в контролере неработает!!!! а естественно компилится нормально.

"Не клевещите на пса". Вряд ли это вина компилятора. Я много работал с PICC, такой косяк я бы не пропустил. Надо в код смотреть (скиньте в личку, если не жалко)

и ещё - пишу кусок от общего кода:

TRISIO1=0;
TRISIO2=0;
TRISIO3=1;
GPIO1=1;
GPIO2=0;

получаю код длиной 768 байт, а если так:

GPIO1=1;
GPIO2=0
TRISIO1=0;
TRISIO2=0;
TRISIO3=1;

то код 780 байт!!!!!! это как так?????? причём в разных частях программы похожие участки дают разное число байт+-!!!

Это не глюк. (К тому же я у себя проверил на 9.60pl3 - размер изменился на 1 слово, так что надо смотреть, что там вокруг этого кода). Вообще же хайтековские компияторы любят банки переключать по 10 раз, но это нельзя назвать глюком, т.к. выдаваемый код - рабочий. Вот в ранних версиях был люк:

if (TMR2IF && TMR2IE) ...

В условии проверялись биты из разных банков, после чего компилятор не восстанавливал RP0, и программа не работала.

Так вот, новая версия всетаки получше будет...

Версия 9.70 - нерабочая, под ней можно собирать небольшие программы для тестов, но закладывать ее в коммерческий проект не стоит. Чуть позже, если будет время, накидаю пару примеров, где он сбоит (у меня лицензия 45 дней закончилась, надо попытаться переустановить и поиграться в Standart-режиме).

[lyk]

Нельзя в PICC v.9.70 побитово к защелкам порта обращаться.
ключик от про версии PICC 9.70

[PupaJr]

testerplus, Я сейчас переписал код. Нашёл у себя некоторые неточности в логике работы программы, кое что добавил и убрал - оптимизировал короче говоря... глюки уши, компилится нормально и работает в чипе тоже как надо, видимо компилятор путался в моих наворотах хотя и компилил.... Именно в логике программы а не правильности написания кода.... 9.60pl5 есть у меня - она как? рабочая или глючная? можно её ставить?

[testerplus]

9.60pl5 есть у меня - она как? рабочая или глючная?

Это ПРО, она нерабочая

[Pheliks]

бррррр...совсем запуталсо... то в той версии глюки, а в той маленькие глючики

пните носом в рабочую версию для начинающих (чтобьі не качать всё подряд) для 10/12/16... имею на борту МРLAB IDE 7.10..асм компилирует даже отдельно в винде, но программировать в нем не силен

нарыл уже Universal_Toolsuite для того чтобы приклеить PICC к MPLABу, осталась версия компилятора

[PupaJr]

Качайте 9.60pl3 9.65pl5 - я их проверял, работают, тема для глюков отдельная, если явно рабочий код неработает в чипе а в симуляторе работает, я делаю так: 1)для начала перегружаю комп - блин, чудо, неменяя ни строчки иногда помогает - или винда или компилятор - ХЗ... 2)меняю местами соседние команды или разбиваю/объединяю некоторые команды с ASM кодом, 3) принципиально меняю алгоритм или команды - на языке С++ можно всякие навороты делать - вот компилятор и блудит-глючит(это моё личное мнение). Если заработал алгоритм то потом уже оптимизируеш - иногда опять начинает глючить - возвращаешся к рабочему варианту... Сам только осваиваю...

[picavr]

1. работе с указателями на переменные, расположенные вне 0-го банка, не восстанавливаются FSR.5 и FSR.6
2. В PIC16'х после обращения к таблицам данных в ROM при возвращении не восстанавливаются PCLATH.3 и PCLATH.4
3. При входе в прерывание не всегда сохраняется FSR.

Охренеть... а как с этим борются?
мне особено понравилось о FSR прерываниях и PCLATH

[testerplus]

Охренеть... а как с этим борются?
мне особено понравилось о FSR прерываниях и PCLATH

Все не так страшно. Ситуации довольно редкие.
FSR в большинстве случаев сохраняется (чтобы не сохранился, кажись, надо вызвать из прерывания функцию, которая этот FSR меняет явно, т.е. "вручную"; и то не всегда получается). Для надежности я всегда сохраняю/восстанавливаю FSR при входе/выходе из прерывания.

С PCLATH тоже точные условия несохранения установить не удалось. Вот тут я приводил короткий пример с ошибкой. Если поменять местами какие-нибудь строчки в этой программке, то ошибка пропадает.

[picavr]

FSR в большинстве случаев сохраняется (чтобы не сохранился, кажись, надо вызвать из прерывания функцию, которая этот FSR меняет явно, т.е. "вручную"; и то не всегда получается).

С PCLATH тоже точные условия несохранения установить не удалось. Вот тут я приводил короткий пример с ошибкой. Если поменять местами какие-нибудь строчки в этой программке, то ошибка пропадает.

ведь неизвестно когда компилятор задействует FSR. значит в любом прерывании пишем?:

unsigneg char temp_fsr
//В начале прерывания
temp_fsr=FSR;
//в конце прерывания
FSR=temp_fsr;

Если честно, то я пока не понимаю...как в СИ, следить за востановлением регистров.. ведь неизвестно что,как скомпилируется и куда ЭТО компилятор засунет... хоть потом дизасемблируй и вставляй команды уже в ассемблере ...

это когда в асемблере пишешь,всё понятно, там ведь сам всё планируешь...
а в дизасемблере компилятора... ууууууууууууу..
там так всё запуущено...