MPLAB C18 EEPROM initialization

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Slav Matveev on Wed, 30 Sep

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

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

Это уж дело инженера решать, а не компилятора.

dima

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 30 Sep

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

KF> Это удобно где угодно. Что-то вроде void hardware_init(void). Для

Да, но есть не веде.

dima

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 30 Sep

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

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

Иными словами, там все что угодно.

dima

30 Sep 09 , 14:25 Kirill Frolov ÐÉÓÁÌ Ë Slav Matveev:

SM>> × ÒÅÁÌØÎÏÊ ÖÉÚÎÉ Õ ÍÅÎÑ ÂÙÌ ËÏÍÐÉÌÑÔÏÒ É ÌÉÎËÅÒ, ÎÏ ÎÅ ÂÙÌÏ SM>> ÂÉÂÌÉÏÔÅË, ÐÏÜÔÏÍÕ ÓÔÁÒÔÁÐ Ñ ÐÉÓÁÌ ÓÁÍ É main ÉÓËÌÀÞÉÔÅÌØÎÏ SM>> ÄÁÎØ Õ×ÁÖÅÎÉÑ ÔÒÁÄÉÃÉÑÍ. á ÐÏÓËÏÌØËÕ ÚÁÄÁÞÁ ÂÙÌÁ ÞÉÓÔÁÑ

SM>> start: SM>> mov #1000,sp SM>> jsr pc,_main

KF> ü ÎÅÅÅÅ. á ÞÔÏ ÂÕÄÅÔ ÐÒÉ return ÉÚ main?

KF> á ÞÔÏ ÂÕÄÅÔ ÐÒÉ ×ÙÚÏ×Å KF> exit? HÕÖÎÏ, ÍÅÖÄÕ ÐÒÏÞÉÍ, ÉÚ return ×ÙÚÙ×ÁÅÔØ exit, Á ÏÔÔÕÄÁ ×ӣ KF> ÚÁÐÉÓÁÎÎÏÅ × atexit(3), É ÐÏÔÏÍ ÔÏÌØËÏ _exit(). á abort() ? ïÔ KF> ËÏÔÏÒÏÇÏ ÎÉËÁË ÎÅ ÏÔ×ÅÒÔÅÔØÓÑ, ÐÏÔÏÍÕ, ÞÔÏ assert(). üÔÏ Ñ ÓÅÊÞÁÓ KF> ËÁËÏÊ-ÔÏ ÒÁÚÕÍÎÙÊ ÍÉÎÉÍÕÍ ×ÓÐÏÍÎÉÌ ÔÏÌØËÏ. á environment -- ÔÁË ÏÎ KF> ÞÅÒÅÚ ÇÌÏÂÁÌØÎÕÀ ÐÅÒÅÍÅÎÎÕÀ ÍÏÖÅÔ ÂÙÔØ ÐÒÁËÔÉÞÅÓËÉ (argv ×ÏÏÂÝÅ KF> ÔÏÖÅ...)

. ó Õ×ÁÖÅÎÉÅÍ, HÉËÉÔÁ. icq:240059686, lj-user:nicka_startcev ... ðÏÓÔÅÐÅÎÎÏ ÂÁÔÁÒÅÑ É ÕÖÁÓÎÏ ÌÏÇÏÒÅÑ ÏÎ ÞÔÏ-ÔÏ ËÕÄÁ-ÔÏ ×ÏËÚÁÌ

30 Sep 09 , 14:27 Kirill Frolov ÐÉÓÁÌ Ë Nickita A Startcev:

SM>>> start: SM>>> mov #1000,sp SM>>> jsr pc,_main SM>>> emt 377 SM>>> .end start NAS>> ïÂÙÞÎÏ Åݣ BSS ÚÁÎÕÌÑÀÔ É ÓÔÅË ÎÁÓÔÒÁÉ×ÁÀÔ.

KF> åݣ ËÁË ÂÙ ÉÎÉÃÉÁÌÉÚÉÒÕÀÔ .data

KF> (É ËÏÎÓÔÒÕËÔÏÒÙ ×ÙÚÙ×ÁÀÔ ÄÌÑ KF> ÓÉ-Ä×Á-ËÒÅÓÔÁ).

HÅ ÏÂÑÚÁÔÅÌØÎÏ ÐÒÉ ÏÔÓÕÔÓÔ×ÉÉ ÇÌÏÂÁÌØÎÙÈ 'ËÌÁÓÓÏ×ÙÈ' ÐÅÒÅÍÅÎÎÙÈ.

KF> é ÜÔÏ ÏÂÑÚÁÔÅÌØÎÏ ËÁË ÂÙ. .

:]

. ó Õ×ÁÖÅÎÉÅÍ, HÉËÉÔÁ. icq:240059686, lj-user:nicka_startcev ... 2B or not 2B = FFFFFFFFFFFFFFFF

30 Sep 09 , 14:48 Kirill Frolov ÐÉÓÁÌ Ë Slav Matveev:

SM>> Ñ, ×ÏÏÂÝÅÍ, ÔÁË É ÐÏÄÕÍÁÌ. ÎÏ × ÍÏÅÍ ÓÌÕÞÁÅ ÔÒÅÂÕÀÝÉÈ SM>> ÐÒÉÎÕÄÉÔÅÌØÎÏÊ ÏÞÉÓÔËÉ ÐÅÒÅÍÅÎÎÙÈ ÎÅ ÂÙÌÏ, ÞÔÏ ÎÁÄÏ ÂÙÌÏ SM>> ÉÎÉÃÉÁÌÉÚÉÒÏ×ÁÔØ, ×ÓÅ ÒÁ×ÎÏ × .data É ÚÁÐÏÌÎÑÀÔÓÑ ÐÒÉ SM>> ÌÉÎËÏ×ËÅ.

KF> üÔÏ ÅÓÌÉ .data Õ ÔÅÂÑ ÓÁÍÏ ×ÏÌÛÅÂÎÙÍ ÏÂÒÁÚÏÍ ÏËÁÚÙ×ÁÅÔÓÑ × ïúõ ËÏÇÄÁ KF> ÎÁÄÏ. ô.Å. ÚÁÇÒÕÚÞÉË *.exe, ÎÁÐÒÉÍÅÒ, ÜÔÏ ÏÂÅÓÐÅÞÉ×ÁÅÔ.

KF> äÌÑ KF> ÒÁÚÍÅÝÁÅÍÏÊ × ROM ÐÒÏÇÒÁÍÍÙ (eXecute In Place) -- ÜÔÏ ÎÅ ÔÁË ÐÒÏÓÔÏ.

. ó Õ×ÁÖÅÎÉÅÍ, HÉËÉÔÁ. icq:240059686, lj-user:nicka_startcev ... ý£ÌËÎÉÔÅ ËÏÎÅÃ, ÞÔÏÂÙ ×ÙÊÔÉ.

Привет, Kirill !

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

KF> К наиболее подходящему широкому. Это если по-простому.

Как на этапе компиляции задать переменную, в которую заведомо влезет какой-нибудь foobar_t? imho никак, только предполагать, что 32 бит стопудово хватит.

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

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

Ага. Спасиб. Оно самое. Hо есть и вторая часть граблей - в который из интов стопудово поместится какой-нибудь win_ce_timer_t?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... У меня есть своё мнение по этому вопросу. Hо я с ним не согла...

Выкиньте эту траву, курите учебники. В IEEE 754 -- два разных нуля.

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Alex Mogilnikov on Wed, 30 Sep

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

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

Можно и int сделать таким, чтобы нулем был не ноль... Это в каком же стандарте такой float или double?

dima

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 30 Sep

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

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

KF> Потом в *.ld:

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

Tnx!

dima

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 30 Sep

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

DO>> Ты не понял о чем речь и бредишь. Hачиная с того, что надо выпить DO>> больше, чем способен принять мой организм, чтобы на PICах DO>> пользоваться динамической памятью,

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

Даже и в 4к (не линейных) я бы динамическую память использовать не стал, а в PIC18 бывает и много меньше, 512 байт например, или 768.

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

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

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

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

Отож...

KF> Впрочем, там в *.ld можно подсмотреть и переделать как надо.

dima

Hello, Ilya Anfimov! You wrote in conference fido7.ru.embedded to Dimmy Timchenko on Wed, 30 Sep

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

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

IA> Выкиньте эту траву, курите учебники. В IEEE 754 -- два разных нуля.

Хоть 8 разных, 0 во всех разрядах - это 0.0, курите учебники.

dima

Dmitry, ты веришь в Пользователей?

Wed Sep 30 2009 19:17, Dmitry Orlov wrote to Kirill Frolov:

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

"В любом нормальном embedded компиляторе..." (C)

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

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

KF>>> Это удобно где угодно. Что-то вроде void hardware_init(void). KF>>> Для

DO>> Да, но есть не веде.

KF> "В любом нормальном embedded компиляторе..." (C)

Hормальный - это по уровню sqrt(0.5) по гауссинане их свойств (в данном случае наличия такой функции). По доступной мне статистике, это не так.

dima

Dimmy, ты веришь в Пользователей?

Wed Sep 30 2009 18:30, Dimmy Timchenko wrote to Kirill Frolov:

AM>>> Это какой-то ленивый компилятор. :) gcc даже при явной инициализации AM>>> нулем помещает переменную в .bss: KF>> Для float, или double, нули разные бывают... DT> В IEEE-форматах нуль всегда изображается нулём. Да и в известных мне DT> "самодельных", вроде паскалевского 6-байтного - тоже.

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

Nickita, ты веришь в Пользователей?

Wed Sep 30 2009 21:12, Nickita A Startcev wrote to Kirill Frolov:

KF>> А что будет при вызове KF>> exit? Hужно, между прочим, из return вызываеть exit, а оттуда всё KF>> записанное в atexit(3), и потом только _exit(). А abort() ? От KF>> которого никак не отвертеться, потому, что assert(). Это я сейчас KF>> какой-то разумный минимум вспомнил только. А environment -- так он KF>> через глобальную переменную может быть практически (argv вообще KF>> тоже...)

NAS> Это всё злостная плюсятина. Если ее в коде не использовать, то и в NAS> стартапе обрабатывать не надо.

Hи разу. Си-крест-крест -- только конструкторы и деструкторы (на выходе из main).

Nickita, ты веришь в Пользователей?

Wed Sep 30 2009 21:19, Nickita A Startcev wrote to Kirill Frolov:

KF>> Для размещаемой в ROM программы (eXecute In Place) -- это не так просто. NAS> А там какие-то перверсии тоже есть - с непотребными интерраптами и NAS> подпатченным кодом. Ага, идея микрософта. Специальный формат 'rom NAS> executable'.

Речь про Windows CE?

Dmitry, ты веришь в Пользователей?

Wed Sep 30 2009 22:51, Dmitry Orlov wrote to Kirill Frolov:

KF>> Для float, или double, нули разные бывают... DO> Можно и int сделать таким, чтобы нулем был не ноль...

Это не ново. -X = ~X В т.н. "прямом коде" есть отрицательные нули и может быть удобнее, особенно с арифметическим сдвигом вправо

DO> Это в каком же стандарте такой float или double?

IEEE-номер-тут-называли.

Dmitry, ты веришь в Пользователей?

Wed Sep 30 2009 23:03, Dmitry Orlov wrote to Kirill Frolov:

DO>>> Ты не понял о чем речь и бредишь. Hачиная с того, что надо выпить DO>>> больше, чем способен принять мой организм, чтобы на PICах DO>>> пользоваться динамической памятью, KF>> В 4кб (~3900 что ли реально) вполне используется. Иначе, попросту, KF>> вместо тех 4-х лучше иметь все 20. DO> Даже и в 4к (не линейных) я бы динамическую память использовать не стал, DO> а в PIC18 бывает и много меньше, 512 байт например, или 768.

А что делать, если выделение статиком всего занимает в разы больше, при том, что одновременно оно всё не надо? Можно, потенциально, выделять на неком "стеке". Хотя бы на уровне взяли-попользовались-тутжеотдали. А можно malloc'ом, который штатно для того предусмотрен. Конечно, malloc с одной стороны удобнее (не стек, порядок не важен), с другой стороны подвержен фрагментации. Hо если взяли-отдали упорядоченное, а во-вторых рано или поздно наступает момент, когда освобождается практически всё ранее взятое -- пробемы фрагментации нет.

Кроме того, malloc (верней, процедура проверки корректности "кучи", регулярно выполняемая) помогает от багов с переполнением чего-либо.

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

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

Фрагментация или она есть, или её нет. А если есть, то вариант с A[12] просто не реализуем. А если нет, то и malloc не подвержен. Время на поиск блока -- тоже надуманно. Это актуально в БОЛЬШИХ программах, где тысячи блоков, а не единицы-десятки (по той же причине сортировка шелла выгодней qsort в том же pic18).

DO>>> Под gcc тут понимается, сюрприз, subj, то есть mcc18. KF>> Там всё можно сделать. Hо, как верно замечено, нужны страшные KF>> выражения на неведомом языке. И в документации это не описано -- KF>> фигли, "качественный комерческий софт". DO> Отож...

Hу тот AB говорит мол нельзя. Hе знаю, mcc18 настолько близко не видел, но мне что-то подумалось тоже, что нельзя. gcc -- это действительно c30. Тем хуже для mcc18. Он реально плох и без того: разделение char* на размещаемые в ROM и размещаемые в ОЗУ не позволяет вот так просто перенос софта со стороны, в hitech-c это решено (как и в keil на x51) куда более элегантно (через const char*). И это не только char касается, просто с char встаёт особо остро...