На 8 бит платформах (например AVR которым Вы не пользуетесь из-за большой нелюбви к
Atmel) int 16 бит.
На MSP430(которым вы пользуетесь, судя по Вашим постам) int тоже 16 бит

Дык как обстоит дело с портированием на 16бит платформы ?
и в частности на MSP430 ? нужно использовать least8_t, или все-таки как-то по другому ?

Не надо передергивать - я не пользуюсь AVR, поскольку для контроллеров ценовой категории от нескольких баксов применение AVR может быть обусловленно только каким-то специфическим свойством, типа высокой нагрузочной способностью по выходам. По той-же самой причине я уже не пользуюсь 51 контроллерами в том числе и "любимого" NXP. Совершенно ничего личного
По причине почти полного отказа от 8-bit польза от ...least8_t для меня сильно снижена.

По причине очень больших наработок и привычек именно к 16-bit я в своих исходниках рассчитываю на int размерностью не более 16-bit. Для 32-bit (как и 64-bit) всегда использую явные указания. В таком применении проблемы портирования 16<->32 нет. На 8-bit c 16/32 бит лично я портирую мало, исходники ввиду использования мелких восьмибитовиков невелики и тогда уже их по необходимости правлю под универсальные типы.

для примера mega8 от 5 баксов
Ну и кто из нас передергивает ?
Тока не нужно расказывать про контроллер светодиодов, ладно ?
Эээ... ну тогда поясните мне какие проблемы могут возникнуть при портировании с/на
8 бит архитектуру если int у Вас всегда не больше 16 бит ?

Чего-то Вам глаза застилает . Повторяю медленно и печально - в ценовой категории контроллеров стоимостью порядка 5 баксов и выше применение AVR8 становится нецелесообразным.

Не буду - я их не делаю, но совершенно уверен, что их пока еще дешевле делать на даже не самом дешевом 8-bit, нежели на самом дешевом ARM. Какие проблемы?

В собственно тупом портировании - никаких, а вот с эффективностью проблемы. На восьмибитовике какой-нибудь банальный счетчик цикла без всякой на то надобности будет прокручиваться в двух регистрах или в двух ячейках памяти, или занимать регистровую пару.... Попробуйте в обсуждаемом ранее AES алгоритме поменять byte на int - вопросы отпадут. Попробуйте откомпилировать с замененными на int под ARM - положительный эффект подскажет ответ на обратный вопрос.
При портировании int на 32-bit - ну ровным счетом никаких проблем, о чем и писал уже несколько раз.

очень жаль, что Alex_inventor так прореагировал, мне его пример понравился и я с радостью бы посмотрел подобные, максимально упрощенные, полностью самописные и комментированные.

теперь о примерах к книжке:
купил, попытался запустить, напоролся на теже грабли, понял что книжка lpc2000 является простым переводом книжки insiders guide и примеры в них одинаковые, скачал примеры к оригиналу и они-то как раз скомпилились нормально ( http://rapidshare.de/files/39331428/lpc210...amples.zip.html ).

Пожалуйста посоветуйте какие программные средства нужны для разработки на основе LPC2103 - перебигаем с AVR в связи с ростом их цены. Планируем купить IAR for ARM 5.50, для отладки и прошивки исползовать Free-проект HJTAG. Хочется услышать что посоветуют специалисты.

Не специалист - в загашнике один простенький проектик на LPC2103. А почему не использовать новенькие Cortex LPC11xx, LPC13xx, LPC17xx? Если купить IAR есть деньги. то почеу не купить под него нормальный дебагер. IAR (имхо) правильный выбор. Однако я использовал ломаный Imagecraft си компилятор для арм, потому что там (на сайте) были для LPC2103 хорошие примеры - мне очень помогло. Сейчас пытаюсь осваивать LPC11xx - хочу использовать GCC.

Почему не Кейл?