Что-то такая конструкция никак не согласуется с утверждением
> Одно неосторожное действие с указателем - и всем п##ц.
Я этого не писал.
Прошу прощения. Это писАл Commodore .
const char tabPOINT[] = {'0','1','1','2','3','3','4','4','5','6','6','7','8','8','9','9'};
...
result = tabPOINT [fractional & 0x0F];
Вы реально скомпилите 😉, ну и result у Вас память, а не регистр W. Так и будете пихать туда-сюда данные
Си результы всегда пихает в переменные (которых и так не много), а потом достает их оттуда, когда без этого вполне можно обойтись. Сишный код всегда будет длиннее :IMHO.
Мы, вроде, на ты были?
Попробовал. Только у меня для ПИКов нет компилятора. Работал с ними давно уже. Тогда и компилеров не было.
Вот для АВР. Оказался свободным R8, туда компилер даже без подсказки и оптимизации засунул. Или я мог явно указать "register".
// 31 __flash char tabPOINT[16] = {'0','1','1','2','3','3','4','4','5','6','6','7','8','8','9','9'};
tabPOINT:
DB 48, 49, 49, 50, 51, 51, 52, 52, 53, 54, 54, 55, 56, 56, 57, 57
...
// 85 Temp = tabPOINT[Temp];
LDI R30, LOW(tabPOINT)
LDI R31, (tabPOINT) >> 8
CLR R9
ADD R30, R8
ADC R31, R9
LPM R8, Z
А с оптимизацией он вообще этот кусок выкидывает, поскольку, реально, переменная больше нигде не используется.
Реально - размер кода процентов на 10..15 побольше. Но результат того стоит.
Про ядро тоже забыть не могу. Более корявого ядра чем в ПИК12/16/18 отыскать практически невозможно. И такое построение таблиц в памяти - это отнюдь не фича ядра, а безысходность. Ради интереса, попробуй соорудить таблицу с 16-ти разрядными значениями.
Ну не знаю, у меня 16 разрядные в eprom и ram валяются и без проблем используются.
Речь шла про таблицу 16-ти разрядных констант в _памяти_ процика. Попробуй...
Конечно, но ПРОЩЕ изучить хорошо даташит и освоить ассемблер, чем даташит + ассемблер + Си. Си это верхний уровень, для правильного и искуссного владения которым нужно отлично знать что под ним :IMHO. Когда я осваивал пики я тоже временно пропустил asm и в результате тот код, который получался был мягко говоря пухлее и корявее, чем можно было написать в асме. Упершись в ресурсы перешел на асм. Писать чуть дольше, но результат нравцца :~).
Скорее нужно знать не ассемблер, а архитектуру собственного процика и тогда все будет хорошо. Кроме, собственно, более долгого писания еще, ИМХО, очень тяжело сопровождать. Несколько раз было так, что просят внести небольшие изменения в прогу, написанную некоторое время назад на АСМе - а я смотрю, как баран на новые ворота, на свою собственную программу... А начинаешь патчить - вылезают такие глюки, которых раньше не было. Просто забыл/непрочитал в комментариях какие-нибудь ньюансы... На ЯВУ сопровождение проще.
Где-то выше, я писал, что не хочу ввязываться в религиозные споры C vs ASM. И не буду.
Ваше устройство очень интересно, давайте обсудим, что оно должно делать и какую инфу давать по CAN. Отпишите подробности по нему и как двигается проект.
Вечером, там http://www.reaa.ru/cgi-bin/yabb/YaBB.pl?num=1204111077 напишу.
