А что, где-то эта проблема еще актуальна? Мне казалось, она канула в лету со 176й серией. Или я неправ? Ответьте, кто сталкивался.

При работе с ЖКИ Мэлт MT16S2D (или H) индикатор немедленно вышел из строя после небольшого статического щелчка от прикосновения пальцем к металлической рамке его дисплея (которая соединяется с GND сего девайса).
Микроконтроллер (уже не помню, PIC это был или AVR) при этом никак не пострадал.
Эти ЖКИ практически не имеют антистатической защиты. С ними надо быть особенно осторожным.

Использую Болиминовские, двухстрочные, непомню имя. Ни разу не было проблем, специально не проверял, но собранные контроллеры лежат на складе как попало (я увидел и ахнул), кнопки выламывали, было, а в остальном... Я потому и спросил, что ни разу не сталкивался.

У нас тут один товарищ при запуске ПЛИС (алтера EPM240...) решил проверить не греется ли, "молния" между чипом и пальцем была весьма внушительная, чип потом выкусывали.

Решил запостить сюда, не стал создавать новую тему, чтобы не засорять форум своими вопросами...

Запутался с типами данных применительно к ARMам.
Оказывается, и int, и long имеют совершенно одинаковый размер - 32 бита.
Но для чего тогда нужен этот long? Для совместимости?
Наверное, его можно не использовать в программе, ведь достаточно будет int?

Помню что есть какая-то зависимость размера указателя и разрядностью шины адрса. Т.е. AVR int - 16 бит, хотя сам он 8-битный. А ARM - 32 бита. Может и вру.

Для определенности.

Просто четко выражайте мысль в каждом конкретном случае. Там, где явно всегда независиимо от
платфрмы нужет будет 32bit - так и пишите long /ulong. Ну а для расходных целей, типа из функции возвратить пару-тройку-сотню... кодов ошибок - естественно int. При таком подходе будет меньше напрягов как для Вас, так и для контроллера (поскольку int это макcимально "естественный" и "удобный" для микроконтролера тип) при портировании на разные платформы.

char - 8
short - 16
long - 32

short <= int <= long - для разных платформ по-разному, как правило int == "битности" процессора

(Это из наблюдений. точной формулировки - почему так - не помню)

А еще лучше написать себе .h типа такого:

И там где нужен точный размер использовать эти typedef.
При переносе - проверить только эти несколько строчек.

Всем спасибо большое, теперь знаю

Платка SAM7-P256 приехала, начинаю заниматься

Для 8-ми биток 16-ти разрядный int не особо то естественный.

Такого требования (16bit) ограничения в общем случае не существует.
Стандарт "C" накладывает только следующие ограничения
sizeof( char ) <= sizeof( short ) <= sizeof( int ) <= sizeof( long )
Компиляторы для 8bit контроллеров которые принимают sizeof( int ) = 16 не слишком хорошо поступают
Хотя естественно ничего не нарушают и более того - им не приходится вводить дополнительно "лишний" 16bit тип. Лично мне по названой ранее причине много больше нравится "естественый для процессора" тип int. К счастью это условие как правило выполняется для контролеров начиная с 16bit.
Если писать на "C" для 8bit-ников, то для переносимости стоит заводить свой специальный tinyint
(а не использовать char !), который при портировании на большие контроллеры дефинируется как простой int.

Простите, а можно подробнее.
Дело в том, что определением "int" я вообще не пользуюсь, потому, как для разных платформ оно имеет разное значение.
Но мне непонятно, как "char" может даже на больших контроллерах быть интерпретирован как "int". Приведите пример, плиз.
Вопрос имеет чисто познавательное значение.

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

Почему не понятно? Ограничений нет. Реальные компиляторы? Под 8bit на "C" крайне мало писал, но под Z80 компилятор с управляемым размером int встречал, как и модификатор "small int".

Для решения этих проблем с С99 были введены int_least8_t и до кучи int_fast8_t типы.
В stdint.h хидерах они естественно теперь есть, но я еще ни разу не видел что кто-нибудь пользовался

Непонятно. Засада в том, что даже АВР-овские компилеры (IAR, например) интерпретируют "int" как 16-бит, что, в общем-то, неправильно, но это факт. Я, правда, на С не делал ни одного реального проекта для 8-бит процессоров, но, по-моему, использование типа "int" порождает больше проблемм, чем удобств пользования. Посему считаю его изжившим себя. Если не прав - поправьте.
Далее, согласитесь, что перенос фирмваре с одной платформы на другую (а, тем более, другой разрядности), бывает весьма редко, и для этого кому-то приходится совершать подвиг, который вовсе не ограничивается преобразованием типов.
И ещё. По-моему, АРМ с 8 (или 16) бит справится не хуже, чем с 32.

Стоп-стоп. Здесь речь идёт, вроде, о "больших" контроллерах. Но в данном курятнике я не разу не встречал интерпретации "char" как простой "int" (о специальных типах не говорим). Может, конкретный пример приведёте?

Ну мне, как Вы поняли это тоже кажется не слишком правильным, но "чаще всего встречающимся"
как написали Атмеловцы.

Совсем наоборот! C постепенным уходом даже из embedded восьмибитных контроллеров с их
тупо используемым принципом "чаще всего встречается" (а почему чаще всего тоже ясно - "C" компиляторы на 16bit расцвели, вот и "чаще" оказались на момент прихода их на 8bit платформы)
int становится НОРМАЛЬНО применимым типом. Именно по этой причине, полагаю, и ранее упомянутые типы введеные С99 никому нахрен и не понадобилитсь, ибо int он и есть тот самый и "не менее X" и "быстрый".

Отнюдь! У мения, например, контролер самая мелкая микросхемка, как правило и львиная доля наработанного кода относится к многочисленной периферии. Вот и портирутся наработки в 8bit (8085->51) на
186 -> 486 -> ARM. Да и чужой код тоже портируется - буквально на прошлой неделе MicroChip-овские
8bit исходники для работы с ENC28J60 частично использовал (точнее пытался, ибо дерьмом в общем-то оказались - в результате один header остался) для 32bit ARM.


Хуже , даже НЕ рисковый процессор типа x86 имеющий полный набор команд для работы c 8-16-32 битными значениями как в регистрах, так и в памяти хуже( медленнее) справляется с не родными размерами переменных не выровнянными на разрядность шины.

Тоже стоп! Я не говорил и "больших" (в смысле 16-32 битных?) контроллерах с 8bit int! Только о том,
что для восьмибитных int может быть и вполне логичен, допустим стандартом и я встречал компилятор для 51 контроллера (поставлялся в начале 90x для заказных коммуникационных чипов с ядром 51 ).
Компилятор, скорее всего (продукт были Израильский и контролеры и управляющие машины там все Intel/USA ) был или базировался на чем-то от Intel-овском. Все было вполне естественно, размерность int
могла быть и 8 и 16 bit на усмотрение пользователя.