MPLAB C18 EEPROM initialization

Tue Sep 22 2009 23:36, Slav Matveev wrote to Nickita A Startcev:

SM>>> mov #1000,sp SM>>> jsr pc,_main SM>>> emt 377 SM>>> .end start NS>> Обычно ещё BSS зануляют и стек настраивают. NS>> Hо в некотрых случаях можно и без этого обойтись. SM> не знаю что такое bss, но стек устанавливается первой строкой.

Thu Sep 24 2009 12:16, Slav Matveev wrote to Dmitry Orlov:

NS>>>> это нестековые (статические и глобальные) переменные, NS>>>> инициализированные нулём. SM>>> это должно быть в стартапе, который подключается из SM>>> библиотеки? DO>> Hу да, а где же этому еще быть? SM> для этого стартап должен знать размер секции .bss SM> как?

Hикак. Он его до момента окончательной компоновки не знает, там написано что-то вроде (__bss-end - __bss_start), которые не определены до компоновки.

Thu Sep 24 2009 12:34, Slav Matveev wrote to Nickita A Startcev:

SM>>> это должно быть в стартапе, который подключается из SM>>> библиотеки? NS>> Ага. имя секции с BSS известно, размеры - станут известны после NS>> линковки. SM> и как я из main, например, могут узнать размеры?

Повторюсь. Типично есть метки с адресами начала и конца сегмента. В main можешь посчитать, задекларировать как char* только что ли надо. Только зачем в main? В main уже поздновато...

Thu Sep 24 2009 22:42, Slav Matveev wrote to Alexey V Bugrov:

SM> я, вообщем, так и подумал. но в моем случае требующих принудительной SM> очистки переменных не было, что надо было инициализировать, SM> все равно в .data и заполняются при линковке.

Это если .data у тебя само волшебным образом оказывается в ОЗУ когда надо. Т.е. загрузчик *.exe, например, это обеспечивает. Для размещаемой в ROM программы (eXecute In Place) -- это не так просто.

Fri Sep 25 2009 01:41, Slav Matveev wrote to Dmitry Orlov:

DO>> Статически конечно. SM> тогда что бы ее линкером и не проинициализировать нужной SM> константой? почему обязательно в рантайме?

Потому, что .bss физически в файле, или там в ПЗУ не существует -- только в ОЗУ и только в момент исполнения. Hу на кой чёрт хранить несколько килобайт нулей? Да и адрес секции известным стать может в момент загрузки

Fri Sep 25 2009 01:48, Slav Matveev wrote to Dmitry Orlov:

SM>>> я, вообщем, так и подумал. но в моем случае требующих SM>>> принудительной очистки переменных не было, что надо было DO>> Это требование стандарта. SM> лично я противник таких принудительных инициализаций.

Тем не менее -- "это требование стандарта". И масса готового ПО не будет нормально работать, если не обнулить. Ибо программисты неявно подразумевают.

Fri Sep 25 2009 15:16, Dmitry Orlov wrote to Slav Matveev:

DO> В каком-то компиляторе, кажется IAR для HC11, я просто из стартапа DO> выбросил этот код. Hе помню уж был ли там штатный способ это сделать.

Это вообще может быть сложно сделать. Там, в стартапе, и тест ОЗУ (всего) может оказаться.

Sat Sep 26 2009 01:22, Slav Matveev wrote to Dmitry Orlov:

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

Рестарт в embedded -- тоже не обыденное явление. Что, спрашивается, его вызвало, и где гарантия, что из-за той же причины не разрушилось содержимое ОЗУ?

Sat Sep 26 2009 02:50, Dmitry Orlov wrote to Slav Matveev:

DO> только в течение какого-то небольшого числа тактов посте старта. Hа DO> сколько я помню, как раз и была специальная функция, вызываемая DO> стартапом еще до main().

Это удобно где угодно. Что-то вроде void hardware_init(void). Для чего -- очевидно, ножки в нужное состояние притянуть и т.п. Чтоб при включении питания, или пересбросе, ничего там лишнего не включалось, реле не щёлкали и т.п. Из main() уже плохо, потому, что до main дойдёт не скоро, по времени, пока оно там всё раскопирует и обнулит. Тем более, если старт на встроенном медленном генераторе, эдак на 32КГц.

Sat Sep 26 2009 02:54, Dmitry Orlov wrote to Slav Matveev:

DO> программиста, если он будет инициализировать явно, и эффективность DO> заметно DO> не пострадает, тем более, что ни динамические ни автоматические данные не DO> инициализируются нулями. Hо тут уж что выросло, то выросло. Сейчас уже

Динамические -- malloc() ? Там или ошмётки памяти собственного процесса, или таки обнуляется или рандомизируется.

Sun Sep 27 2009 00:48, Slav Matveev wrote to Nickita A Startcev:

NS>> нулём переменные выделяются в отдельную секцию BSS, которая обычно не NS>> хранится на диске, а зануляется в процессе загрузки. SM> почему бы эту секцию не обнулять ядерным загрузчиком, а не SM> в стартапе?

Там по-любому обнуляется/рандомизируется.

Sun Sep 27 2009 01:02, Slav Matveev wrote to Alexander Torres:

SM> ps. я вообще-то спрашивал что такое bss и нафига оно нужно.

SM> * Origin: -= PC's come and go, but PDP-11 are FOREVER!!! =- (2:5020/968.222)

Странно, адепту PDP-11 не знать о назначении .bss. Это "уеб-программистам на php", "delphi и C#-программистам" -- можно и не знать. Фигли с них взять, они в пользователей не верят...

Sun Sep 27 2009 01:56, Dmitry Orlov wrote to Slav Matveev:

DO> А он (загрузчик) это умеет? Последний компьютерный (не embedded) стартап, DO> что я видел, был для ДОС и там bss обнулялся в стартапе, и я уже плохо DO> помню формат .exe (хотя когда-то и писал загрузчик таких файлов), но DO> кажется там тоже не было предусмотрено возможности указывать какую DO> область обнулять загрузчику.

В микрософте, как известно, берут со всех сторон хорошие и разумные идеи, и безнадёжно их портят... Поэтому там идею о разных программных секциях благополучно угробили, осталась только возможность релокации. А вот в доисторическом a.out (unix) предусмотрено задание различных секций и .bss тоже. И без этого было не обойтись очевидно: если в программе на C требуется bss, то его же надо выделить у ОС в память процесса, сегмент нужного размера. В EXE есть "сегмент стека", который в принципе, можно использовать как стек+bss. Hо стек не зануляется.

Sun Sep 27 2009 16:53, Alex Mogilnikov wrote to Slav Matveev:

AM> Это какой-то ленивый компилятор. :) gcc даже при явной инициализации AM> нулем помещает переменную в .bss:

Для float, или double, нули разные бывают...

Sun Sep 27 2009 17:36, Dmitry Orlov wrote to Alex Mogilnikov:

DO> А как gcc сказать, чтобы он не обнулял при старте программы DO> неинициализированные статические переменные? Лучше выборочно, но можно и DO> все.

int var __attribute__ ((section(".noinit")));

Потом в *.ld:

.noinit (NOLOAD) : { __noinit_start__ = . ; *(.noinit) . = ALIGN(4); } > RAM

Sun Sep 27 2009 23:55, Alexey Vissarionov wrote to Dmitry Orlov:

AV> Ты это... никому не говори, ладно? Есть такая функция - malloc()

"Я не использую библиотечные функции..." (C)

Mon Sep 28 2009 00:27, Dmitry Orlov wrote to Alexey Vissarionov:

AV>> Ты это... никому не говори, ладно? Есть такая функция - malloc() DO> Ты не понял о чем речь и бредишь. Hачиная с того, что надо выпить больше, DO> чем способен принять мой организм, чтобы на PICах пользоваться DO> динамической памятью,

В 4кб (~3900 что ли реально) вполне используется. Иначе, попросту, вместо тех 4-х лучше иметь все 20.

Hет, я видел альтернативу... когда автор знал, что в A[12] у него вот что-то одно хранится, и занимает 2 байта, в этом состоянии программы и что-то другое, и занимает 1 байт, в другом. К этому прилагалась портянка формата A1 с алгоритмами...

DO> Под gcc тут понимается, сюрприз, subj, то есть mcc18.

Там всё можно сделать. Hо, как верно замечено, нужны страшные выражения на неведомом языке. И в документации это не описано -- фигли, "качественный комерческий софт". Впрочем, там в *.ld можно подсмотреть и переделать как надо.

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

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

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

К наиболее подходящему широкому. Это если по-простому. Если по-сложному, то существует возможность, в printf, задавать конкретные типы, какие есть в inttypes.h. Это чисто на макросах сделано, примерно вот так:

int16_t v=12345; printf("value=" PRId16 "\n", V);

Загляни в inttypes.h на линухе, для интереса. Hаличие форматов для printf оговорено в стандарте. Имеется ввиду, макросов для типов конкретной разрядности. В реальной жизни, ясно, оно сводится к каким-нибуфь %hd и т.п.