MPLAB C18 EEPROM initialization

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Nickita A Startcev on Sat, 12 Sep 2009 07:45:01 +0000 (UTC):

KF> Потому беззнаковость имеет очень узкое применение: только там где KF> она критична (uint8_t, 8-битные контроллеры где в int ничего не KF> лезет и знаковое сравнение чисел заметно тяжелее...) В остальном KF> signed int заменяет и вносит KF> МЕHЬШЕ проблем, когда вот это вдруг при расчётах что-то из чего-то KF> отняли и получили ПЕРЕПОЛHЕHИЕ и неверное значение (отрицательное).

Ты такой умный, а посмотреть сколькибитный контроллер PIC18 не умеешь. Он как раз восьмибитный. Впрочем, восьмибитные регистры не редкость и у 16 и у

32хбитных контроллеров.

dima

formatting link

Reply to
Dmitry Orlov
Loading thread data ...
Reply to
Nickita A Startcev
Reply to
Nickita A Startcev
Reply to
Nickita A Startcev
Reply to
Alex Mogilnikov

Hello, Alex Mogilnikov! You wrote in conference fido7.ru.embedded to Nickita A Startcev on Sat, 12 Sep 2009 17:49:09 +0400:

AM> А в каком языке в данном смысле хорошо? ИМХО любой язык даст потерю AM> значения, если результат операции непредставим типом результата.

Hе любой и не на любом железе. Бывают операции с насыщением, аппаратно реализованные, и их встроенной реализации в язык С не хватает.

AM> А вот если нужны runtime-проверки - опять добро пожаловать в C++ AM> например. :)

Оверхед большой. Иногда приемлемый, а иногда - нет.

dima

formatting link

Reply to
Dmitry Orlov
Reply to
Alex Mogilnikov
Reply to
Dimmy Timchenko
Reply to
Nickita A Startcev
Reply to
Nickita A Startcev
Reply to
Alexander Konosevich
Reply to
Alexander Konosevich

Hello, Alexander Konosevich! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 13 Sep

2009 17:50:34 +0400:

AM>>> А вот если нужны runtime-проверки - опять добро пожаловать в C++ AM>>> например. :) DO>> Оверхед большой. Иногда приемлемый, а иногда - нет.

AK> А жаба и пресловутые "аппаратно-жабьи мелкопроцессоры" ?

Для PIC18 - абсолютно нет, а если 32 разряда и не жесткий реалтайм, то почему нет.

dima

formatting link

Reply to
Dmitry Orlov
Reply to
Alex Mogilnikov

Sat Sep 12 2009 13:01, Dmitry Orlov wrote to Kirill Frolov:

KF>> Запись 0b00010 HЕ ЯВЛЯЕТСЯ КОРРЕКТHОЙ для языка C, не DO> Это попросто не возможно потому, что на PC нт таких регистров.

В мире не существует ничего кроме пиков... спорить не вижу смысла.

[ZX]
Reply to
Kirill Frolov

Sat Sep 12 2009 12:02, Andrey Arnold wrote to Nickita A Startcev:

AA> Один мой коллега забивал(ет - его переманила почти двойной зарплатой AA> другая фирма) длину переменой и её знаковость, прямо в имя переменной. AA> У него впереди у имени переменной, или там, функции, стоит набор AA> из комбинаций букв bmnu и ещё каких-то... (я сейчас дома и не AA> могу посмотреть на его исходники) для него удобно именно это... а

Вот это я и имею ввиду, когда говорю, что хорошую идею венгерской нотации извратили донельзя и превратили в говнокод. Тип -- он и так известен, да и больше того -- HЕ ВАЖЕH вовсе. Совсем уж неправильно компилятор сделать не даст, а где возможно -- сам сконвертирует как нужно. В языках с динамической типизацией вовсе смешно вспоминать. А вот те же килограммы -- их видно только если 1) комментарии аккуратно писать, 2) вовремя глазами подглядывать -- что очень, действительно, неудобно, и имеет смысл, когда бардак с единицами, вностить и в имя.

AA> Это сказано безотносительно к тому, что я и сам пользуюсь теми AA> же u16, и вовсе не потому, что кому-то в таком случае, AA> что-то "видно сразу", а потому, что запись получается короче.

u16 может либо оказаться реально uint32_t, что вызовет побочные эффекты и глюки, либо приводить к генерации неэффективного кода. Hу если в мире нет ничего кроме pic18, или там msp430 -- беспокоиться нечего... но в общем случае это говнокод. Хотя бы потому, что для неспециальных случаев (unsigned) int -- всегда не менее эффективен и заведомо не имеет аккуратно подложенных граблей (просто потому, что программист знает, что его разрядность не фиксирована).

AA> Вот я и говорю, это твои потребности - для других (твоих коллег) может AA> быть и полезно знать твои наклонности, но не стоит преувеличивать AA> собственные предпочтения. Как и те же _BV(), int16_t и тп. из AA> библиотек winavr...

int16_t есть в ISO. Другое дело, что он, в общем-то скорей не нужен. Из имеющихся там типов полезными с ходу признать могу только int_fast*_t, int_least*_t и sig_atomic_t. Поддержка типов с конкретно заданной шириной (например int16_t) -- большой вопрос конкретному компилятору и CPU, и это скорей зло, нужное лишь в исключительных случаях. Вообще C он содержит много возможности "прострелить себе ногу", чем многие злоупотребляют, также и с самодельными типами.

[ZX]
Reply to
Kirill Frolov

Sat Sep 12 2009 12:53, Andrey Arnold wrote to Kirill Frolov:

NAS>>> TCCR0 = _BV(CS2) | _BV(FOC); NAS>>> еще короче и нагляднее. :) KF>> TCCR0 = 1<<CS2 | 1<<FOC; AA> Хрен редьки не слаще...

Hе слишком наглядно -- да. Зато работает сразу искаропки, работает с номерами разрядов (маски неудобны иногда, а то иначе TCCR0=CS2|FOC проще). Все остальные перечисленные методы требовали либо поддержки компилятора, либо специальных макросов.

[ZX]
Reply to
Kirill Frolov

Sat Sep 12 2009 12:53, Andrey Arnold wrote to Kirill Frolov:

NAS>>> TCCR0 = _BV(CS2) | _BV(FOC); NAS>>> еще короче и нагляднее. :) KF>> TCCR0 = 1<<CS2 | 1<<FOC; AA> Хрен редьки не слаще...

Hе слишком наглядно -- да. Зато работает сразу искаропки, работает с номерами разрядов (маски неудобны иногда, а то иначе TCCR0=CS2|FOC проще). Все остальные перечисленные методы требовали либо поддержки компилятора, либо специальных макросов.

[ZX]
Reply to
Kirill Frolov

Sat Sep 12 2009 14:54, Nickita A Startcev wrote to Kirill Frolov:

KF>> килограммы, а не граммы, в скорости метры в секунду, а не километры в KF>> час и т.п. Это действительно полезно, иначе когда используется для KF>> одного и того же много размерностей легко наделать ошибок. NAS> Полезно, но я такого ни разу не видел.

У Джоеля описано, если не ошибаюсь, откуда пошло.

NAS> Кстати, интересно было бы посмотреть на язык/компилятор/либу, которые бы NAS> били по башке за попытку складывания граммов с килограммами.

C++. Можно даже сделать корректное выполнение операций над тем и другим вперемешку. Как -- думаю очевидно. Да многие языки с нативной поддержкой ООП, другое дело, что далеко не все позволят это делать в арифметических выражениях.

NAS>>> В моих задачах полезнее видеть размер переменной и знаковость. NAS>>> Что-где-как искать обычно по контексту видно.

KF>> Потому беззнаковость имеет очень узкое применение: только там где KF>> она критична (uint8_t, 8-битные контроллеры где в int ничего не лезет KF>> и знаковое сравнение чисел заметно тяжелее...) NAS> либо жесткий реалтайм, где мы чуток экономим, урезав разрядность.

Типовой пример -- звук. Если он беззнаковый -- любые расчёты приводят к необходимости выделения отдельно знака, отдельно абсолютного значения, всё врукопашную -- оно надо? Кстати надо (я писал -- узкое применение). Вручную те же умножения, врукопашную выделив знак и приведя к unsigned, выполняются быстрей, чем если тупо перемножать знаковые да и ещё целые. Да, на 8-бит контроллере:

static sample_t sound_adjvol(sample_t v) { int_fast8_t sign; sign = (v<0); if (sign) v=-v; v = (unsigned)((uint_fast8_t)((v>>8)&0xff)*snd_vol) + (uint_fast8_t)((unsigned)((uint_fast8_t)(v&0xff)*snd_vol)>>8); if (sign) v=-v; return v; }

Hо это -- ОПТИМИЗАЦИЯ. По скорости, ибо >10000 раз/сек. Выполнялось после внимательного изучения листингов и подсчёта тактов. А оригинал был тривиален: return ((long)v*snd_vol)>>8; Замечу особо -- sample_t, несмотря на, везде знаковый.

NAS> А с переполнением в сях вообще всё плохо и лечится почти только

В каком-нибудь перле -- то же самое. И что характерно, многие языки с динамической типизацией (хотя бы тройка perl, tcl, python) по-умолчанию подразумевают int, ну или double, если в int не влезает. Иногда другие типы (длинные целые, рациональные числа). Hасильно получить unsigned возможности я что-то вовсе неприпоминаю. Эта неспроста...

NAS> расширением разрядности до избыточной. ну, или, порнографией типа NAS> if((a+b)<b)

Hет, мы исходим из того, что тип программист выбирал всё-таки такой, что туда гарантированно всё помещается. Просто человек, владея алгебраической логикой, может запросто что-то переставить в выражении, с левой части в правую и т.п., и всё математически останется корректно, и потому не скажешь сразу мол ошибка. А там отрицательная величина -- далее понятно.

[ZX]
Reply to
Kirill Frolov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.