Опитвам се да се боря със C за микроконтролери ... чувството е ужасно, но това е друга тема.

Интересува ме какво се използва когато трябва да се дефинира променлива с големина точно два байта. Понеже не съм разглеждал много компилатори за контролери ми се ще отсега да свикна да пиша по-съвместим код. Първото ми налучкване е short. int май може да е различно за различните процесори. Така че:
char - а така ... интересно как се интерпретира char в 16 и 32 битовите контролери
int - зависи от процесора (чух че за някои компилатори е 1 байт)
short - 2 байта за всички компилатори и контролери
short long - това май не е толкова универсално, а?
long - 4 байта навсякъде

П.П. микрочипското C е боза. има 3 грешки на кръс и през по-вечето време показва syntax error - като BASIC едно време ... при това 3 реда по-надолу или нагоре от реда на който е грешката...

Точно поради факта че различните компилатори третират различно тия декларации, хората са създали и стандартизирали един хедър stdint.h: http://en.wikipedia.org/wiki/Stdint.h
Всеки читав компилатор го има. Най-чисто е да ползваш неговите дефиниции за променливите.

... изглежда PIC C18 не е читав компилатор

edit: ще си го направя този файл за да е съвместим кода

Чети описанието на конкретния компилатор, че стават грешки ...

Не всеки С-сомпилатор е ANSI С - съвместим.
Ядох дебелия със CCS C, когато почнах с PIC24-ките.
Той нали е всичко в едно - за 8 и 16-битовите и лесно се бърка при преминаване от 8 към 16-битови контролери.
Че int при първите е един байт, а при вторите - 2 е ясно.
Проблема ми дойде от това, че 8-битовата версия по дифолт всичко е unsigned, а при 16-битовата - обратно (без char).

Мда аз за това питах. Направих си stdint.h и го сложих в глобална директория. "make" файла (така де, проекта) е само за pic18 и директорията в която се намира този файл е към проекта. Ако портвам код ще си вземе stdint.h от съответния компилатор или ако няма такъв пак ще направя (мерси kiiid).

Казвам ви аз да пишете на Паскал, ама кой да слуша...

Да пишем на какво?

Не на какво а на кого, бре!

Пиковете просто не са мислени за C програмиране, затова и компилаторите за тях са извратени. Колкото и да са нови и лъскави, всичките носят в себе си онова ядро на 16C54 с всичките му щурави концепции вътре. Прекрасни са за много неща, ама не и за писане на ANSI С компилатор. Чак MIPS-овия е нещо по различно.

Та ако искаш да учиш C за микроконтролери - зарежи малките пикове - взимаш или MIPS или АРМ.

Просто не са истински процесори.

Да. Трябва да ги ре-категоризират в графа "полупроцесори"

От чисто любопитство да запитам а вие по какво познавате дали някой процесор е мислен за С или не?

1. Методи за достъп до стека.
2. Размер на стека.
3. Организация на паметта.
4. Процесорна архитектура ( фон Нойман vs Харвард ).
5. ...

А трябва ли и защо?

те нали с това се биеха в гърдите микрочип, че 18-ките били оптимизирани за C - може би са имали в предвид extended режима и индиректното индексиране с WREG офсет.
А глупавият им компилатор дори не следи банките - за всяко присвояване прави movlb ... да не говорим че за access RAM-a прави movlb 0 ... за какви оптимизации говорим ....
Аз за това се бъхтех на асемблер, но от известно време се опитвам да ги вържа двете и се получава. Прекъсванията ми са на асемблер и няколко по-дребни функции, а останалото е на C. Малко е досадно да сравняваш на асемблер и да ползваш ROM таблици (масиви) ...