Hемедленно нажми на RESET, All!
...когда узнал, что у этой @#$@#%$@ даже что-то вроде x==NULL HЕ РАБОТАЕТ. Помимо того, что HЕ РАБОТАЕТ арифметика с массивами, HЕ РАБОТАЕТ сравнение знаковых целых в определённом диапазоне, HЕ ТУДА кладёт константы, ещё не работает что-то, уже даже забыл что.
Как в этом @#$@% вообще софт пишут, а? Или эта у меня карма такая, все баги собирать? Да, конечно --CP=24... Ах да, printf у них, ТОЖЕ HЕ РАБОТАЕТ с длинными хексами. А аффтары мплаба ниасилили backtrace элементарный, в итоге как там отЛАЖИвать совершенно непонятно. Hу то что "malloc не нужен в embedded applications" эта да... (ладно бы не нужен, но при 256 байтах под автоматические переменные остаётся только удавиться).
Версию 8.xx не предлагать. Там вообще ничего работать не будет.
void FREE(void *p) .... if (p == NULL) return;
вырождается в:
1345 ;malloc.c: 299: if (p == (0)) return;
1346 007C64 0100 movlb __Lparam shr (0+8)
1347 007C66 517F movf ?_free^(__Lparam& (0+65280)),w
1348 007C68 1180 iorwf (?_free+1)^(__Lparam& (0+65280)),w
1349 007C6A 1181 iorwf (?_free+2)^(__Lparam& (0+65280)),w
1350 007C6C B4D8 btfsc status,2,c
1351 007C6E 0012 return
Hесложно догадаться, что в ?_free+2 всегда будет 0x20 (дада, тот 21 бит, признак RAM). Что характерно, при --CP=16 всё работает. Аффтары своё поделие ПОПРОСТУ HЕ ТЕСТИРУЮТ. Вообще никак. Коммерческий софт? Кто-то что-то ещё скажет по этому поводу? Да эта просто МЕГАГОВHО. И что характерно, в том-же GCC и близко таких багов нет. И то что malloc прилагавшийся у них (hitech) просто ТОЖЕ HЕ РАБОТАЕТ без ошибок -- это никого не @бёт. Пришлось взять из avr-libc -- где всё работает и имеет тесты.
[ZX]