Може ли в иара, указателите към функции да са 2 байта? Дата модела съм го сложил на малък, но указателите към функции са си пак по 3 байта .

Е не съм в час с ИАР за ПИК, ама датата и да ти е малка - какво от това. Указателя към функцията е по скоро CODE. Т.е според мен модела на кода трябва да е малък. На микрочипския компилатор двете неща са различни и моделите се задават отделно. При малък модел за кода, се простираш в 64К и указателите са двубайтови.

В момента се чудя с какъв копилатор да се захвана. Правя сравнение между различните(IAR,CSS,C18,CC8E и т.н.т.) . Интересно ми е каква е цената на микрочипския, че неможах да я изровя. Комилатора е важно да поддържа даннов стек, реентрантни функции и да не ползва много временни данни. Добри оптимизации и удобни типове данни (освен стандартните 8,16,32 битови, добре ще е да има и 24 битови). Пък и не на последно място прилична цена, щото като видях цената на ИАР-а, напрао ми призля.

Значи когато е Small default size ti e 2 баита.
И е толкова ако си декларираш поинтера така
int __bank1 * p; това е 2 баита но е указател само към банк1.
Проблема с 3те баита не идва от IAR а от организацията на лаиняните пикове.
int *p си е три баита щото се пази и банката.

От компилаторите с наи много екстри е IAR. От всички IAR среди само за PIC16 е по недъгава и неразвита. За PIC18 аз лично предпочитам IAR.
Но наи добре се ориентираи към по истински процсори ако не искаш да ти побелее косата преждевременно.

Ако ще купуваш, тогава IAR просто е прекалено излишен лукс според мен. Аз лично ползвам C18. Отначало беше торба с бъгове, ама постепенно влезе в час. Даннов стек има, реентрантни функции не обичам да ползвам, но ако се налага - става. Само че то винаги трябва да си с едно на ум, щото пиковете не страдат от изобилие от РАМ, и всички тия неща ядат ценните ресурси. Не си спомням колко струва, но ми се мота нещо около 500$.

има си тип short long (24 бита).

Никола, въпросът ми беше за указателите към функции, това с указателя към банка1 не го разбрах. Нали за указател към рама са достатъчни 2 байта, от които се ползват само 12-бита (4 бита номер на банка и 8 бита адрес). Цецо разгледах документацията на микрочипския компилатор, но неможах да разбера какво е съдържанието на section .tmpdata и section MATHDATA. Инетересуваме колко са големи, и как да разбера къде се намират.

Маи не съм ти прочел поста внимателно.
Ами за указателите към функции няма май никакви настроики. Малко съм се борил с Iar za picи може и да пропускам нещо.
А указването на банка ва рамките на която да сочи указателя го прави мисля че само 1 баит,но компилатора може да реши и 2 баита да е понякога ако е по добре за оптимизацията на кода. Но сочи само към банката която си му задал. Слагаш си всички променливи с които работиш с този указател в една и съща банка и така намаляваш обема на кода и подобряваш бързодеиствието.
Аз лично при PIC избягвам да ги ползвам указателите към функции. Абе общи линии наи добре е да се избягват самите пикове. Много криво нещо са.

1. Колко са големи? Знам ли. Динамични са, т.е всичко зависи от конкретното приложение което компилираш.

2. Къде се намират? Ами също много неясно - май имаше някакъв начин да разбереш, ама не помня.

Общо взето тия две неща са едно от най-слабите места в документацията. Това е и причината поради която не съм се опитвал да подкарам RTOS върху тоя компилатор. Факт е че такива RTOS съществуват, значи проблема е решен някак, ама...

А и предвид, малко шашавата архитектура на пика, не съм сигурен, че при останалите компилатори нещата са по добре решени.

Гледах FreeRTOS как се справят с проблема. Значи всички темпове на компилатора според тях се намират в началото на аксес бнак. Но това едвали е валидно ако се използва екстендед мод. C18 подържа ли inline функции и ако да как става че нещо немога да зацепа.

Хм и това незнам. Май няма такова нещо при тоя компилатор. Защо са ти?

Аи стига бе еба ти компилатора да няма inline. То вярно че рзправят че е много дървен ама чак пък толкова,сигурно има.

Абре inline май няма. Като гледам микрочеповете го правят с макроси:
#define ClrWdt() {_asm clrwdt _endasm}

Цецо, защо при interrupt функция в началото има едно movf POSTINC1,F и в края movf POSTDEC1,F. FSR1 сочи върха на стека, но за какъв дявол го правят това нещо. Да не е свързано нещо с някоя бъг при някои пикове?

P.S. Тия от freertos, казват че след компилация трябва да се провери map-файла да се види къде са .tmpdata и MATHDATA, за да се провери месторазположението и големината им дали отговарят на кода за task context saving/restoring.

Ха, ха ти направо уби всичко детско в мен. За първи път я виждам тая инструкция. Определно фигурира в сорса.
Ама защо идея си нямам. Не виждам много смисъл, но сигурно има. Да копираш регистъра в себе си - ползвал съм го само при проверки на флагове. Но тука случая не е такъв. И го има и при двете нива на прекъсване. Странно.

Сега като се замисля идеята явно е да мръдне с едно ниво стека. Направо си мяза на презастраховка срещу някой бъг. Другото е това мъртво ниво да трябва за нещо на компилатора - никъде не съм срещал документация по въпроса.

То че има бъг в прекъсванията на 18-ките, има, но това определено не е от методите за заобикалянето му.
Или?...

Цецо с коя версия си на компилатора. Аз тествам 3.00. Интересно в по-старите весии пак ли прави такова напред/назад със стека.