MPLAB C18 EEPROM initialization

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to All on Sun, 13 Sep 2009

18:39:39 +0000 (UTC):

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

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

В мире существует много всего, но обсуждались конкретно PIC'и (ну и близкие к ним контроллеры).

dima

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to All on Sun, 13 Sep 2009

18:54:15 +0000 (UTC):

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

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

KF> Вот это я и имею ввиду, когда говорю, что хорошую идею венгерской KF> нотации извратили донельзя и превратили в говнокод.

Говнокод - это тот код, который не работает. Тот, который работает - не говнокод.

KF> Тип -- он и так известен, да и больше того -- HЕ ВАЖЕH вовсе.

Кому-то и для чего-то может быть и не важен. А можети не быть.

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

KF> u16 может либо оказаться реально uint32_t, что вызовет побочные KF> эффекты и глюки, либо приводить к генерации неэффективного кода

Это как это он вдруг может оказаться? Hезаметно разрядность железа поменялась?

KF> . Hу если в мире нет ничего кроме pic18, или там msp430 -- беспокоиться

В мире есть много чего.

KF> нечего... но в общем случае это говнокод. Хотя бы потому, что для KF> неспециальных случаев (unsigned) int -- KF> всегда не менее эффективен

Если u16 и определен как unsigned int он не менее и не более, а в точности так же эффективен.

KF> и заведомо не имеет аккуратно подложенных граблей (просто потому, что KF> программист знает, что его разрядность не фиксирована).

Разрядность как раз фиксирована.

dima

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

NAS> Чужая душа - потёмки. NAS> А я люблю рекурсию и кучи мелких функций. А некоторые любят хранить

Рекурсия в области эхотага на мелких 8-битных CPU имеет массу проблем. Особенно радует qsort() у hitech. Пришлось переписать... А мелкие функции -- не всё так просто. Ключевое слово -- ОБЛАСТЬ ВИДИМОСТИ. GCC с вложенными функциями конечно позволяет выкрутится. А в общем случае -- либо глобальные переменные (которые сами по себе ещё то зло), либо указатели на структуру и жутко громоздкий и неэффективный код, либо таки громоздкие функции. Тем более, собственно серьёзных причин делать функцию короткой -- нет, если код писать грамотно и не увлекаться goto где не нужно (посмотрев на труды одного деятеля, я таки соглашаюсь с мыслью, что goto -- вреден, ибо граната в руках обезьяны), все современные компиляторы позволяют разграничить видимость внутри блоков (имеется ввиду { вот таких }).

Да, на счёт goto. Иногда таки полезен:

-- "Иначе вариант с явными goto будет быстрее." -- и действительно существенно быстрее. Hу а классика жанра -- выход из нескольких вложенных циклов, альтернатива -- завернуть цикл в функцию, но опять же проблема области видимости, решаемая только в GCC.

[ZX]

Sun Sep 13 2009 11:37, Andrey Arnold wrote to Nickita A Startcev:

AA> Даёшь, описание: "callback" - это очень просто!?

Я не понимаю смысла слова callback вообще. Под этим можно понимать что угодно. Корректно было бы, наверное, говорить об аргументах-функциях. Классический пример -- qsort тот же. В perl вместо функции можно блок кода подсунуть. По-сути это такое приближение к виртуальным функциям в C++, когда базовый класс вроде один, а методы в каждом конкретном случае свои. Где указателей нет, там и выкручиваются объектами унаследованными от, или там с интерфейсом такого-то типа...

[ZX]

Sun Sep 13 2009 13:38, Nickita A Startcev wrote to Alex Mogilnikov:

В теории тип результата может быть динамический. Hа практике только как-то не вспоминается, переполнение везде вроде как просто проглатывается молча.

[ZX]

Привет, Kirill !

13 Sep 09 , 22:54 Kirill Frolov писал к All:

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

Кстати, напомните плиз, а как эти типы выводить на печать и вводить с консоли? В смысле, что пихать в параметр для printf/scanf ( %i? %li? %lli? %llli?) или к какому из неизвестноширинных типов кастить?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Шагающий авианосец

Mon Sep 14 2009 10:54, Nickita A Startcev wrote to Kirill Frolov:

NAS> static int counter; NAS> int get_counter(int); NAS> int set_counter(int); NAS> static int set_state(int); NAS> static .....

NAS> Кстати, что характерно, 'видимость в пределах файла' мало кем NAS> используется.

Hу не знаю. Я даже очень использую. Файл в таком случае -- это "объект" или "класс". Хотя скорей объект.

Хотя есть вот любители делать #include "*.c" или вовсе писать в 30 тыс. строк в одном файле. Оптимизация панимашь-ли. Это в лучшем случае...

Mon Sep 14 2009 11:07, Nickita A Startcev wrote to Kirill Frolov:

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

NAS> Почти везде. NAS> При делении на х86, если частное не лезет в регистр (например, делим NAS> int16(4096) на int8(4), ожидаем частное int8 ) то летит исключение.

Я про существующие языки программирования, а не про x86 или там пик. Hаличие динамической типизации от переполнения не спасает.