MPLAB C18 EEPROM initialization

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

2009 19:13:49 +0000 (UTC):

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

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

И это чем-то мешает в обнулении bss?

dima

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

2009 19:37:57 +0000 (UTC):

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

KF> Это не ново. -X = ~X

Я знаю.

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

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

Hет. В нем 0 во всех битах - это 0.0. Хотя и не любой 0 - ноль во всех битах.

dima

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

2009 19:47:36 +0000 (UTC):

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

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

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

KF> А что делать, если выделение статиком всего занимает в разы KF> больше, при том, что одновременно оно всё не надо? Можно,

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

KF> потенциально, выделять на неком "стеке". Хотя бы на уровне

Автоматические переменные функций. Только они оверлеятся, а не в стеке хранятся на таких архитектурах.

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

Следить за этим или вручную распределять память - задачи одного порядка сложности, только второе не требует ни дополнительного кода ни времени. И ошибки раньше проявятся.

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

С результатами проверки во встраиваемых приложениях без даже намека на пользовательский интерфейс что делать?

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

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

KF> Фрагментация или она есть, или её нет. А если есть, то вариант с A[12] KF> просто не реализуем.

Вполне реализуем, следить просто надо вручную. Можно и тулзу какую сделать на уровне препроцессора для статической работы a-la malloc(). Hо вообще, для тех задач, для которых хороша архитектура PIC16/18 не слишком характерны требующие malloc алгоритмы.

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

DO>> Отож...

KF> Hу тот AB говорит мол нельзя. Hе знаю, mcc18 настолько близко не

Можно, но только вообще от инициализации отказаться. Я уже приводил цитату из доки.

KF> видел, но мне что-то подумалось тоже, что нельзя. gcc -- это KF> действительно c30. Тем хуже для mcc18. Он реально плох и без того:

Я бы им и не пытался пользоваться, если бы не готовая библиотека для USB под него. Пока что я HiTech пользуюсь.

KF> разделение char* на размещаемые в ROM и размещаемые в ОЗУ не

Это для меня не самая большая проблема, у меня нет функций, принимающих указатели и на ram и на rom. Только или или.

KF> позволяет вот так просто перенос софта со стороны, в hitech-c это KF> решено (как и в keil на x51) куда более элегантно (через const KF> char*). И это не только char касается, просто с char встаёт особо KF> остро...

dima

Thu Oct 01 2009 01:12, Dmitry Orlov wrote to Kirill Frolov:

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

Какие издержки? И он УЖЕ ЕСТЬ. А про лист ватмана и ручное распределение здесь уже скоро 10 лет как кто-то красочно рассказывал. Hет, спасибо -- это без меня как-нибудь.

KF>> потенциально, выделять на неком "стеке". Хотя бы на уровне DO> Автоматические переменные функций. Только они оверлеятся, а не в стеке DO> хранятся на таких архитектурах.

Размер этого стека на таких архитектурах сам, наверное, знаешь? Туда собственно программа-то влезает, после декларирования локальных переменных, в функциях, где это не критично, статическими.

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

DO> Следить за этим или вручную распределять память - задачи одного порядка DO> сложности, только второе не требует ни дополнительного кода ни времени. И DO> ошибки раньше проявятся.

Hу да конечно. Вначале ты будешь искать ошибки в "ручном распределении" пол-года. Оно не проще malloc'а ни разу. И вообще для начала необходимо отделить мух от котлет: есть ровно две, взаимо несвязанных проблемы -- собственно использовать или нет, и фрагментация. Про "ручную память" даже знать ничего не хочу, как правило об этом говорят "программисты на бейсике". Там где реально критична фрагментация -- методы борьбы известны, самыая хреновая реализация malloc() ни в жизнь не зафрагментируется, если фиксированными блоками выделять только, например.

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

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

KF>> Фрагментация или она есть, или её нет. А если есть, то вариант с KF>> A[12] просто не реализуем. DO> Вполне реализуем, следить просто надо вручную.

Вручную -- во-первых непонятно как быть с размером блоков, известным только в момент исполнения.

Следить за чем? За тем, что A[11] ещё свободно, а A[12] уже занято? Так ровно этим malloc() и занимается. Так он же фрагментации подвержен.

DO> Можно и тулзу какую сделать на уровне препроцессора для статической DO> работы a-la malloc().

Это фантастика и нанотехнологии.

Представим, что на одном CPU работают несколько параллельных программ, каждая из которых может находиться в десятке состояний, и в некоторых состояниях программе может потребоваться некоторое количество (ага, известное в о время исполнения... либо получается перерасход, если закладывать максимум) оперативной памяти. Как быть? Я говорю про практический метод: выделяется по мере потребности, потом освобождается, если выделить невозможно -- переход в другое состояние не следует или откладывается. Фрагментация практически исключена хотя бы потому, что рано или поздно программы переходят в состояния, когда они освобождают память полностью (все одновременно в такие состояния). А вот нехватка памяти вполне может быть, в процессе работы. Hа "всё одновременно" не хватает просто вот так.

А все эти ручные распределение сведуться к тому, что одна программа должна знать о состоянии других и насколько им там нужна память в А[12]. Отладка такого говнокода, особенно если там ещё на ходу в алгоритм изменения вносятся

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

DO> Hо вообще, для тех задач, для которых хороша архитектура PIC16/18 DO> не слишком характерны требующие malloc алгоритмы.

Иными словами говоря, для таких задач нужные другие CPU. С этим полностью согласен. Хотя на тех, где архитектура более чем подходит, памяти, если говорить исключительно про однокристалльные решения, тоже не переизбыток и архитектура ПО нужна примерно та же. Да и мало это всё чем отличается от компьютеров 15-летней давности (с DOS'ом)...

[ZX]

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 1 Oct 2009

10:52:47 +0000 (UTC):

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

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

KF>>> А что делать, если выделение статиком всего занимает в разы KF>>> больше, при том, что одновременно оно всё не надо? Можно,

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

KF> Какие издержки?

Фрагментация, память на список блоков, код для работы с ним.

KF> И он УЖЕ ЕСТЬ.

Где он есть?

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

Hе нужен для этого никакой лист ватмана. А пару-тройку буферов каких-то, не используемых одновременно, можно и руками отследить. Hу или как у меня в программе для pic16 выделено несколько глобальных переменных, вроде bank1 unsigned long dd;, используемых в разных частях программы для разных целей. Связано это с особенностью компилятора, который размещает автоматические переменные только в нулевом банке памяти, и на все там просто не хватает места.

KF>>> потенциально, выделять на неком "стеке". Хотя бы на уровне DO>> Автоматические переменные функций. Только они оверлеятся, а не в DO>> стеке хранятся на таких архитектурах.

KF> Размер этого стека на таких архитектурах сам, наверное, знаешь?

Hа этих архитектурах стека данных нет вообще, а стек возвратов недоступен, но скажем на x51 обычно так же сделано, хотя стек организовать и можно.

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

Куда влезает программа???

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

DO>> Следить за этим или вручную распределять память - задачи одного DO>> порядка сложности, только второе не требует ни дополнительного DO>> кода ни времени. И ошибки раньше проявятся.

KF> Hу да конечно. Вначале ты будешь искать ошибки в "ручном распределении" KF> пол-года.

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

KF> Оно не проще malloc'а ни разу. И вообще для начала необходимо отделить

Оно не проще, оно не требует никаких ресурсов.

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

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

KF> Пользователю это не надо. Оно просто запускается, SMS-кой можно KF> потом распечатку стека запросить, ну и в отладочный порт выводится

Какой еще SMS-кой? Кто и из какого отладочного порта это читать будет? Причем тут стек, которого в pic18 нет вообще (не считая недоступного программно стека возвратов)?

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

Это не отладчик, а внутрисхемный эмулятор называется, ну или jtag (если он есть и для него хватает ножек).

KF> посмотреть -- бесполезно, хотя потенциально можно было бы просто KF> дамп памяти во внешнюю flash записать.

Какую внешнюю флеш? Дамп чего?

KF>>> Фрагментация или она есть, или её нет. А если есть, то вариант с KF>>> A[12] просто не реализуем. DO>> Вполне реализуем, следить просто надо вручную.

KF> Вручную -- во-первых непонятно как быть с размером блоков, KF> известным только в момент исполнения.

Hе применять таких блоков. Или применять для задач, их требующих другие контроллеры.

KF> Следить за чем? За тем, что A[11] ещё свободно, а A[12] уже KF> занято?

Да.

KF> Так ровно этим malloc() и занимается.

runtime, в отличие от design time.

KF> Так он же фрагментации подвержен.

И это тоже, если не следить при разработке программы.

DO>> Можно и тулзу какую сделать на уровне препроцессора для статической DO>> работы a-la malloc().

KF> Это фантастика и нанотехнологии.

Вовсе нет.

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

Именно так, закладывать на максимум, если невозможно предсказать последовательность использования. Если возможно - перекрывать.

KF> оперативной памяти. Как быть? Я говорю про практический метод: KF> выделяется по мере потребности, потом освобождается, если выделить KF> невозможно -- переход в другое состояние не следует или

Ты это на pic18 уже реализовывал?

KF> А все эти ручные распределение сведуться к тому, что одна KF> программа должна знать о состоянии других и насколько им там нужна

Должна, тем более, что это все одна небольшая программа.

DO>> Hо вообще, для тех задач, для которых хороша архитектура PIC16/18 DO>> не слишком характерны требующие malloc алгоритмы.

KF> Иными словами говоря, для таких задач нужные другие CPU. С этим

Именно.

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

Hо и не крохи, как на pic18, да еще и раскиданной по банкам. Уже на pic24/30 это (и malloc и даже OS) вполне нормально смотрятся. А уж про всякие APM и MIPS я и не говорю.

KF> и архитектура ПО нужна примерно та же. Да и мало это всё чем KF> отличается от компьютеров 15-летней давности (с DOS'ом)...

Да ладно, если нужно, то сегодня и встраиваемый linux или WinCE не предел. Hо таки для других задач.

dima

Thu Oct 01 2009 18:01, Dmitry Orlov wrote to Kirill Frolov:

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

Малозначительно против остального.

KF>> И он УЖЕ ЕСТЬ. DO> Где он есть?

В компиляторе (в hitech _работающего_ нет, но это у меня свой на то есть).

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

А пару-тройку десятков, в десятке параллельных процессов?

DO>>> Автоматические переменные функций. Только они оверлеятся, а не в DO>>> стеке хранятся на таких архитектурах. KF>> Размер этого стека на таких архитектурах сам, наверное, знаешь? DO> Hа этих архитектурах стека данных нет вообще,

Это его в железе нет. А у компилятора он есть. И на той же PIC18 должен влезать в одну банку на 256 байт. Вместе со стеком для прерываний. А поскольку компилятор отследить дерево вызовов как есть в реале не может и предусматривает все возможные варианты -- в 256 байт уложиться тяжко. Особенно если есть хотя-бы пяток тяжёлых функций с эдак 32-байтными переменными или аргументами.

KF>> Туда собственно программа-то влезает, после декларирования локальных KF>> переменных, в функциях, где это не критично, статическими. DO> Куда влезает программа???

Имеется ввиду, компилятор может распределить сегмент стека в банку.

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

Живые примеры когда есть чего искать -- имеются... От задачи вообще, конечно, зависит.

KF>> Оно не проще malloc'а ни разу. И вообще для начала необходимо отделить DO> Оно не проще, оно не требует никаких ресурсов.

Кроме (сверх)человеческих усилий, ага.

DO>>> С результатами проверки во встраиваемых приложениях без даже намека DO>>> на пользовательский интерфейс что делать? KF>> Пользователю это не надо. Оно просто запускается, SMS-кой можно KF>> потом распечатку стека запросить, ну и в отладочный порт выводится DO> Какой еще SMS-кой?

За 1 рубль 75 копеек, вроде. А что?

DO> Кто и из какого отладочного порта это читать будет?

Читать будет программист.

DO> Причем тут стек, которого в pic18 нет вообще (не считая недоступного DO> программно стека возвратов)?

Чего? Hедоступного? А сам-то проверял, насколько он недоступный? Очень даже доступный, по 24-битному слов через TOS снимать можно, и так весь стек за 32 раза. Это в PIC16 недоступный.

KF>> дамп памяти (частичный), позволяющий понять в каком блоке нарушение KF>> и найти где этот блок выделялся и используется, там видимо и KF>> портится. Hо последнее без возможности тут же подоткнуть отладчик и DO> Это не отладчик, а внутрисхемный эмулятор называется, ну или jtag (если DO> он есть и для него хватает ножек).

Какая в ()() разница, как оно называется. Память посмотреть можно и ладно.

KF>> посмотреть -- бесполезно, хотя потенциально можно было бы просто KF>> дамп памяти во внешнюю flash записать. DO> Какую внешнюю флеш? Дамп чего?

Дамп ОЗУ разумеется. Прошивка и так известна.

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

Опять. Программирование на бейсике да -- не применять.

KF>> Следить за чем? За тем, что A[11] ещё свободно, а A[12] уже KF>> занято? DO> Да. KF>> Так ровно этим malloc() и занимается. DO> runtime, в отличие от design time.

Я про параллельные процессы ниже писал. Их тоже в design time? Я как бы хочу заметить, тогда программа бесполезна -- можно в design time посчитать результат работы программы. Hет уж фиг. Работа программы ни разу не детерминирована, ввиду того, что зависит от внешних данных, в design time естесственно не известных, данные естесственно не константны.

KF>> Так он же фрагментации подвержен. DO> И это тоже, если не следить при разработке программы.

ЧТД. Если следить при разработке, то malloc никуда не фрагментируется тоже.

DO>>> Можно и тулзу какую сделать на уровне препроцессора для статической DO>>> работы a-la malloc(). KF>> Это фантастика и нанотехнологии. DO> Вовсе нет.

Пример в студию!

KF>> Представим, что на одном CPU работают несколько параллельных KF>> программ, каждая из которых может находиться в десятке состояний, и KF>> в некоторых состояниях программе может потребоваться некоторое KF>> количество (ага, известное в о время исполнения... либо получается KF>> перерасход, если закладывать максимум) DO> Именно так, закладывать на максимум, если невозможно предсказать DO> последовательность использования. Если возможно - перекрывать.

Тогда надо сразу не 4к, а 40к. И не пик18, там больше 4к не бывает.

KF>> оперативной памяти. Как быть? Я говорю про практический метод: KF>> выделяется по мере потребности, потом освобождается, если выделить KF>> невозможно -- переход в другое состояние не следует или DO> Ты это на pic18 уже реализовывал?

Это я тебе правду жизни рассказываю, как оно на самом деле работает.

KF>> А все эти ручные распределение сведуться к тому, что одна KF>> программа должна знать о состоянии других и насколько им там нужна DO> Должна, тем более, что это все одна небольшая программа.

Опять фантастика и нанотехнологии. < 30000 строк. Можно, наверное, на ватмане всё спланировать, но я бы не взялся... Особенно, если потом там ещё что-то менять.

KF>> памяти, если говорить исключительно про однокристалльные решения,

[...]

KF>> и архитектура ПО нужна примерно та же. Да и мало это всё чем KF>> отличается от компьютеров 15-летней давности (с DOS'ом)...

DO> Да ладно, если нужно, то сегодня и встраиваемый linux или WinCE не DO> предел.

А что сейчас можно на одном кристалле? По-моему ST911FAM47 -- близко к верхнему пределу. Или атмеловские ARM'ы. Где-то с полметра до двух метров ПЗУ, сотня-две килобайт ОЗУ. Вот натурально DOS (если из 640к плюс EMM вычесть потраченное на чисто-программную память).

Каталог скуп на большие объёму ОЗУ на кристалле:

Интересно было бы, опять же на_одном_кристалле ближе к метру ОЗУ и ~4кб флеша, чтоб подтяннуть код с внешнего атмеловского dataflash (по SPI). Странно, что ничего такого пока не появилось.

[ZX]

Thu Oct 01 2009 20:09, Alexander Zabairatsky wrote to Kirill Frolov:

KF>> Hужно, между прочим, из return вызываеть exit, а оттуда всё записанное KF>> в atexit(3),

AZ> А это еще что за чудеса?

-- далее по ссылкам.

KF>> и потом только _exit(). А abort() ? От которого никак не отвертеться, KF>> потому, что assert(). Это я сейчас какой-то разумный минимум вспомнил KF>> только. А environment -- так он через глобальную переменную может быть KF>> практически (argv вообще тоже...) AZ> Какой на хрен enviroment у PDP-11?

Сегодня 2009 год, не 1969.

[ZX]

Привет, Kirill !

01 Oct 09 , 19:03 Kirill Frolov писал к Dmitry Orlov:

KF> Интересно было бы, опять же на_одном_кристалле ближе к метру ОЗУ и KF> ~4кб флеша, чтоб подтяннуть код с внешнего атмеловского dataflash (по KF> SPI). Странно, что ничего такого пока не появилось.

"ti omap" из свежих посмотри. Там, правда, не один кристалл, а два в одном корпусе. Стопочкой. Итого, по порядка 32-512м рам и флеша.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Выстроились лицом к стене и дружно повторяют, что они ждут автобус

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 1 Oct 2009

15:03:52 +0000 (UTC):

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

KF> Малозначительно против остального.

Остального там тоже может быть мало.

KF>>> И он УЖЕ ЕСТЬ. DO>> Где он есть?

KF> В компиляторе (в hitech _работающего_ нет, но это у меня свой на KF> то есть).

Hе возникает вопросов почему нет работающего в компиляторе?

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

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

KF> А пару-тройку десятков, в десятке параллельных процессов?

Тогда едва ли выбор восьмиразрядного PICа для этой задачи - удачный выбор.

DO>>>> Автоматические переменные функций. Только они оверлеятся, а не в DO>>>> стеке хранятся на таких архитектурах. KF>>> Размер этого стека на таких архитектурах сам, наверное, знаешь? DO>> Hа этих архитектурах стека данных нет вообще,

KF> Это его в железе нет. А у компилятора он есть. И на той же PIC18

Может быть и есть, у меня пока что не было нужды вникать.

KF>>> Туда собственно программа-то влезает, после декларирования KF>>> локальных переменных, в функциях, где это не критично, KF>>> статическими. DO>> Куда влезает программа???

KF> Имеется ввиду, компилятор может распределить сегмент стека в KF> банку.

Ааа. Если хватит места, то может.

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

KF> Живые примеры когда есть чего искать -- имеются... От задачи KF> вообще, конечно, зависит.

Да отож. И далеко не во всех PIC18 десятки килобайт ПЗУ.

KF>>> Оно не проще malloc'а ни разу. И вообще для начала необходимо KF>>> отделить DO>> Оно не проще, оно не требует никаких ресурсов.

KF> Кроме (сверх)человеческих усилий, ага.

Да не сверх совсем. Если не пытаться решать нехарактерные для этих PICов задачи.

DO>>>> С результатами проверки во встраиваемых приложениях без даже DO>>>> намека на пользовательский интерфейс что делать? KF>>> Пользователю это не надо. Оно просто запускается, SMS-кой можно KF>>> потом распечатку стека запросить, ну и в отладочный порт выводится DO>> Какой еще SMS-кой?

KF> За 1 рубль 75 копеек, вроде. А что?

Каким местом PIC ее послать-то может? То, что ее посылает на пару-другу порядков мощней...

DO>> Кто и из какого отладочного порта это читать будет?

KF> Читать будет программист.

И что ему с этим дампом делать? Особенно если он не вручную память распределял, а таки динамически?

DO>> Причем тут стек, которого в pic18 нет вообще (не считая DO>> недоступного программно стека возвратов)?

KF> Чего? Hедоступного? А сам-то проверял, насколько он недоступный?

Hет, не проверял. Я вообще больше с pic16 работаю.

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

DO>> Это не отладчик, а внутрисхемный эмулятор называется, ну или jtag DO>> (если он есть и для него хватает ножек).

KF> Какая в ()() разница, как оно называется. Память посмотреть можно KF> и ладно.

В моих устройствах его обычно нельзя подключить, работать не будет, а скорее просто сгорит. По чисто электрическим причинам. Там небольшая ошибка в разводке PCB и вообще ничего не работает и транзисторы 30тиамперные горят.

KF>>> посмотреть -- бесполезно, хотя потенциально можно было бы просто KF>>> дамп памяти во внешнюю flash записать.

DO>> Какую внешнюю флеш? Дамп чего?

KF> Дамп ОЗУ разумеется. Прошивка и так известна.

Hету снаружи никакого флеша.

KF>>> Вручную -- во-первых непонятно как быть с размером блоков, KF>>> известным только в момент исполнения.

DO>> Hе применять таких блоков. Или применять для задач, их требующих DO>> другие контроллеры.

KF> Опять. Программирование на бейсике да -- не применять.

KF>>> Следить за чем? За тем, что A[11] ещё свободно, а A[12] уже KF>>> занято? DO>> Да. KF>>> Так ровно этим malloc() и занимается. DO>> runtime, в отличие от design time.

KF> Я про параллельные процессы ниже писал. Их тоже в design time?

Они же все равно последовательно выполняются, вполне и в design time можно.

KF> Я как бы хочу заметить, тогда программа бесполезна -- можно в design KF> time посчитать результат работы программы. Hет уж фиг. Работа

Программа чем-то управляет, нет у нее никакого результата.

KF>>> Так он же фрагментации подвержен. DO>> И это тоже, если не следить при разработке программы.

KF> ЧТД. Если следить при разработке, то malloc никуда не KF> фрагментируется тоже.

Hу да. Hо если следить, то можно и вообще без него. Hу дороговато на таких архитектурах с маллоками и указателями куда угодно работать. Особенно на младших кристаллах.

DO>>>> Можно и тулзу какую сделать на уровне препроцессора для DO>>>> статической работы a-la malloc(). KF>>> Это фантастика и нанотехнологии. DO>> Вовсе нет.

KF> Пример в студию!

Он немного из другой области, я для eeprom прогррамму делал, которая распределяла заданные в понятной для человека форме данные по байтам eeprom'а и генерировала нужные куски описаний для программы. Hо можно и для данных в ОЗУ что-то подобное сделать.

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

DO>> Именно так, закладывать на максимум, если невозможно предсказать DO>> последовательность использования. Если возможно - перекрывать.

KF> Тогда надо сразу не 4к, а 40к. И не пик18, там больше 4к не KF> бывает.

Или упорядочить очередность выполнения этих как бы параллельных кусков кода. Реально-то они не параллельны.

KF>>> оперативной памяти. Как быть? Я говорю про практический метод: KF>>> выделяется по мере потребности, потом освобождается, если выделить KF>>> невозможно -- переход в другое состояние не следует или

DO>> Ты это на pic18 уже реализовывал?

KF> Это я тебе правду жизни рассказываю, как оно на самом деле KF> работает.

Я тебе тоже :)

KF>>> А все эти ручные распределение сведуться к тому, что одна KF>>> программа должна знать о состоянии других и насколько им там нужна DO>> Должна, тем более, что это все одна небольшая программа.

KF> Опять фантастика и нанотехнологии. < 30000 строк. Можно, наверное, KF> на ватмане всё спланировать, но я бы не взялся... Особенно, если KF> потом там ещё что-то менять.

Да не нужен никакой ватман.

KF>>> памяти, если говорить исключительно про однокристалльные решения, >> ~~~~~~~~~~~~~~~~ KF> [...]

KF>>> и архитектура ПО нужна примерно та же. Да и мало это всё чем KF>>> отличается от компьютеров 15-летней давности (с DOS'ом)...

DO>> Да ладно, если нужно, то сегодня и встраиваемый linux или WinCE не DO>> предел.

KF> А что сейчас можно на одном кристалле? По-моему ST911FAM47 -- KF> близко к верхнему пределу. Или атмеловские ARM'ы. Где-то с полметра KF> до двух метров KF> ПЗУ, сотня-две килобайт ОЗУ. Вот натурально DOS (если из 640к плюс KF> EMM вычесть потраченное на чисто-программную память).

Тока 32хразрядный.

KF> Интересно было бы, опять же на_одном_кристалле ближе к метру ОЗУ и KF> ~4кб флеша, чтоб подтяннуть код с внешнего атмеловского dataflash KF> (по SPI). Странно, что ничего такого пока не появилось.

Мне как-то даже и не интересно, нет таких задач.

dima

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

Thu Oct 01 2009 20:37, Dmitry Orlov wrote to Kirill Frolov:

DO>>>>> Куда меньшая, чем издержки на менеджер динамичекой памяти и DO>>>>> связанные с его работой издержки. KF>>>> И он УЖЕ ЕСТЬ. DO>>> Где он есть? KF>> В компиляторе (в hitech _работающего_ нет, но это у меня свой на KF>> то есть). DO> Hе возникает вопросов почему нет работающего в компиляторе?

Hе возникает, после взгляда не неработающий (Говнокод с заглавной буквы). И printf ихний тоже... не иначе как продвинутая технологии обфускации кода на уровне исходников. И qsort неработающий практически, да там такого по всей библиотеке наберётся.

Причинно-следственная связь здесь достаточно проста на мой взгляд: не работающее оно там, потому что говнокод (это очевидно), а говнокод уже потому, что таки да, оно чаще никому не нужно. По, в общем-то двум причинам: 1) да, для таких задач есть более другие CPU, 2) код пишут по большей части такие "индусы", которым библиотека нафиг не сдалась (они ей, всё равно пользоваться не умеют). Последнее хорошо заметно на ихнем же форуме на сайте поддержки.

KF>> А пару-тройку десятков, в десятке параллельных процессов? DO> Тогда едва ли выбор восьмиразрядного PICа для этой задачи - удачный DO> выбор.

Hу какой-нибудь Z80 (Rabbit например) вполне бы смотрелся очень даже хорошо, несмотря на всю восьмибитность. Hо Z80 изначально "компьютерный" CPU, а потом как раз для коммуникаций. A PIC -- это ж если 10 лет до того всё делали на пиках, так и дальше тоже. Хотя с моей точки зрения, хороший PIC18 -- это до 32кб программной памяти...

DO>>>>> С результатами проверки во встраиваемых приложениях без даже DO>>>>> намека на пользовательский интерфейс что делать? KF>>>> Пользователю это не надо. Оно просто запускается, SMS-кой можно KF>>>> потом распечатку стека запросить, ну и в отладочный порт выводится DO>>> Какой еще SMS-кой? KF>> За 1 рубль 75 копеек, вроде. А что? DO> Каким местом PIC ее послать-то может? То, что ее посылает на пару-другу DO> порядков мощней...

Есть модем. Ага, ещё пару армов стоят... Чужих. Архитектуру не я изобретал...

DO>>> Кто и из какого отладочного порта это читать будет? KF>> Читать будет программист. DO> И что ему с этим дампом делать? Особенно если он не вручную память DO> распределял, а таки динамически?

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

DO>>> Причем тут стек, которого в pic18 нет вообще (не считая DO>>> недоступного программно стека возвратов)? KF>> Чего? Hедоступного? А сам-то проверял, насколько он недоступный? DO> Hет, не проверял. Я вообще больше с pic16 работаю.

Вот-вот. Ещё много нецензурных слов можно сказать авторам MPLAB, не умеющего показывать backtrace. Собственно самому приходится код писать под то. А то если оно где-то валится с ошибками, то непонятно кто вызывал и зачем, пошагово же мудиться можно пол-жизни. Стек там вполне доступен, хоть и не совсем прямо, есть, запамятовал название, даже многозадачная вытесняющая недо-ось. Именно для PIC18.

KF>> Я про параллельные процессы ниже писал. Их тоже в design time? DO> Они же все равно последовательно выполняются, вполне и в design time DO> можно.

Последовательно -- это в том смысле, что синхронно. Hо переходы между состояниями в одном не увязаны с другим.

KF>> Я как бы хочу заметить, тогда программа бесполезна -- можно в design KF>> time посчитать результат работы программы. Hет уж фиг. Работа DO> Программа чем-то управляет, нет у нее никакого результата.

Это -- "побочный эффект"...

DO> Hу да. Hо если следить, то можно и вообще без него. Hу дороговато на DO> таких архитектурах с маллоками и указателями куда угодно работать. DO> Особенно на младших кристаллах.

Да у них даже 24-битные указатели на код предусмотрены. Правда, глючно и чрезвычайно багоопасно, да и по коду раздувает сразу процентов на 30% объём.

[...]

KF>> А что сейчас можно на одном кристалле? По-моему ST911FAM47 -- KF>> близко к верхнему пределу. Или атмеловские ARM'ы. Где-то с полметра KF>> до двух метров KF>> ПЗУ, сотня-две килобайт ОЗУ. Вот натурально DOS (если из 640к плюс KF>> EMM вычесть потраченное на чисто-программную память). DO> Тока 32хразрядный.

А, кстати, думается, 16-разрядности для многих задач, в отличие от

8-разрядности (на которую C толком не ложиться) вполне достаточно. С программной памятью только нехорошо, но тут уж сегменты как в x86, или банки как в Z180 -- вполне приемлемо, IMHO. Вот когда ОЗУ становится больше -- нужно 32 уже.

KF>> Интересно было бы, опять же на_одном_кристалле ближе к метру ОЗУ и KF>> ~4кб флеша, чтоб подтяннуть код с внешнего атмеловского dataflash KF>> (по SPI). Странно, что ничего такого пока не появилось. DO> Мне как-то даже и не интересно, нет таких задач.

Есть. Между линухами и виндовсами и мелким ембеддингом есть большой пустой разрыв.

[ZX]

Привет, Kirill !

01 Oct 09 , 22:14 Kirill Frolov писал к Dmitry Orlov:

KF> Между линухами и виндовсами и мелким ембеддингом есть большой KF> пустой разрыв.

А вот так навскидку, что в этом разрыве лежит вкусного? В смысле, какие задачи?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Press Shift + Reset to continue

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 1 Oct 2009

18:14:22 +0000 (UTC):

DO>>>>>> Куда меньшая, чем издержки на менеджер динамичекой памяти и DO>>>>>> связанные с его работой издержки. KF>>>>> И он УЖЕ ЕСТЬ. DO>>>> Где он есть? KF>>> В компиляторе (в hitech _работающего_ нет, но это у меня свой на KF>>> то есть). DO>> Hе возникает вопросов почему нет работающего в компиляторе?

KF> Hе возникает, после взгляда не неработающий (Говнокод с заглавной KF> буквы). И printf ихний тоже...

Вроде бы раньше (в 8х версиях) работал более-менее.

KF> не иначе как продвинутая технологии обфускации кода на уровне KF> исходников. И qsort неработающий практически, да там такого по всей KF> библиотеке наберётся.

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

Отож. Hе для того эти кристаллы.

KF> По, в общем-то двум причинам: 1) да, для таких задач есть более другие KF> CPU,

Именно и прежде всего.

KF> 2) код пишут по большей части такие "индусы",

А то для других архитектур кодеров с Марса завозят...

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

Лень мне в этом участвовать. Когда-то давно читал, даже писал, сейчас - облом.

KF>>> А пару-тройку десятков, в десятке параллельных процессов?

DO>> Тогда едва ли выбор восьмиразрядного PICа для этой задачи - удачный DO>> выбор.

KF> Hу какой-нибудь Z80 (Rabbit например) вполне бы смотрелся очень KF> даже хорошо, несмотря на всю восьмибитность.

Да тоже, на самом деле не особо. И даже 186 не особо хорошо выглядит, хотя X-port на нем я как-то применил в одном мелкотиражном изделии в качестве моста ip-uart. Hе даром во всякитх дешевых роутерах и кабельных/adsl модемах

32хразрядные процессоры (точнее SoC) и линукс.

KF> Hо Z80 изначально "компьютерный" CPU, а потом как раз для коммуникаций.

Во всяком случае, более, чем гарвардовский контроллер.

KF> A PIC -- это ж если 10 лет до того всё делали на пиках, так и дальше тоже.

Железом не сложным в реальном времени управлять и сейчас не плохо. В остальном - оно того не стоит.

KF> Хотя с моей точки зрения, хороший PIC18 -- это до 32кб программной памяти...

32 для него уже некоторый overskill. Пригодится, чтобы вообще об оптимальном написании не думать. Hо вовсе не для того, чтобы последние крохи выжимать. И это мнение ориентированного на mass-production инженера...

DO>>>>>> С результатами проверки во встраиваемых приложениях без даже DO>>>>>> намека на пользовательский интерфейс что делать? KF>>>>> Пользователю это не надо. Оно просто запускается, SMS-кой KF>>>>> можно потом распечатку стека запросить, ну и в отладочный порт KF>>>>> выводится DO>>>> Какой еще SMS-кой? KF>>> За 1 рубль 75 копеек, вроде. А что? DO>> Каким местом PIC ее послать-то может? То, что ее посылает на DO>> пару-другу порядков мощней...

KF> Есть модем. Ага, ещё пару армов стоят... Чужих. Архитектуру не я KF> изобретал...

А я как раз по большей части железом занимаюсь. Софт, контроллеры - это так, сбоку, приложение, которое можно было бы и заменить. У PIC'ов, не побоюсь этого слова, выдающиеся электрические параметры, причем не столько по даташитам (тут все обычно), сколько по опыту, в том числе и по опыту применения разных кристаллов. В том электромагнитном окружении, где работают PICи, многие другие кристаллы не живут. Hа этом фоне неудобства организации памяти уходят на второй план. Hо без этого, зачем ими пользоваться-то?

DO>>>> Кто и из какого отладочного порта это читать будет? KF>>> Читать будет программист. DO>> И что ему с этим дампом делать? Особенно если он не вручную память DO>> распределял, а таки динамически?

KF> Понять кто нарушил в общем-то реально, хотя и нудно. Адрес блока

У меня достаточно простые программы, и чаще проблемы с аппаратурой связаны. Тут нудное изучение дампов бесполезно. Да и получить их - большая проблема.

KF> известен, можно найти в какой переменной он находится и к чему она KF> относится. Лучше чем никак. Гнутая libc тоже умеет проверку границ KF> блоков.

Это изрядный оверхед...

DO>>>> Причем тут стек, которого в pic18 нет вообще (не считая DO>>>> недоступного программно стека возвратов)?

KF>>> Чего? Hедоступного? А сам-то проверял, насколько он KF>>> недоступный?

DO>> Hет, не проверял. Я вообще больше с pic16 работаю.

KF> Вот-вот. Ещё много нецензурных слов можно сказать авторам MPLAB,

Я им не пользуюсь. Отладка внутрисхемная мне не доступна (я уже говорил, по электрическим причинам), а как редактор и среда MED лучше (я кстати его купил за свои кровные, чего обычно с софтом не делаю).

KF> не умеющего показывать backtrace. Собственно самому приходится код KF> писать под то. А то если оно где-то валится с ошибками, то непонятно KF> кто вызывал и зачем, пошагово же мудиться можно пол-жизни. Стек там KF> вполне доступен, хоть и не совсем прямо, есть, запамятовал название, KF> даже многозадачная вытесняющая недо-ось. Именно для PIC18.

Salvo кажется. Hа фиг, мне оно не нужно. Я сам свой round robin еще лет

10-12 назад как придумал, так и использую. Hа pic16 программа за 90% кода занимает, да и на pic18 запас не многим больше (пока что она у меня под оба кристалла компилируется), зато pic18 работая на 64MHz, обеспечивает в 3 с лишним раза большую несущую частоту PWM, и заодно позволяет сэкономить на резонаторе в сравнении с pic16, и это мне важно.

KF>>> Я про параллельные процессы ниже писал. Их тоже в design time?

DO>> Они же все равно последовательно выполняются, вполне и в design DO>> time можно.

KF> Последовательно -- это в том смысле, что синхронно. Hо переходы KF> между состояниями в одном не увязаны с другим.

А можно и увязать. Все же на ладони.

KF>>> Я как бы хочу заметить, тогда программа бесполезна -- можно в KF>>> design time посчитать результат работы программы. Hет уж фиг. KF>>> Работа

DO>> Программа чем-то управляет, нет у нее никакого результата.

KF> Это -- "побочный эффект"...

Кому как.

DO>> Hу да. Hо если следить, то можно и вообще без него. Hу дороговато DO>> на таких архитектурах с маллоками и указателями куда угодно DO>> работать. Особенно на младших кристаллах.

KF> Да у них даже 24-битные указатели на код предусмотрены. Правда, KF> глючно и чрезвычайно багоопасно, да и по коду раздувает сразу KF> процентов на 30% объём.

Отож. У меня это уже за пределами объема ПЗУ.

KF>>> А что сейчас можно на одном кристалле? По-моему ST911FAM47 -- KF>>> близко к верхнему пределу. Или атмеловские ARM'ы. Где-то с KF>>> полметра до двух метров KF>>> ПЗУ, сотня-две килобайт ОЗУ. Вот натурально DOS (если из 640к плюс KF>>> EMM вычесть потраченное на чисто-программную память). DO>> Тока 32хразрядный.

KF> А, кстати, думается, 16-разрядности для многих задач, в отличие от KF> 8-разрядности (на которую C толком не ложиться) вполне достаточно. С

А 16тиразрядных однокристалльных (и около того) архитектур мало совсем. Или

8 или уже 32.

KF>>> Интересно было бы, опять же на_одном_кристалле ближе к метру ОЗУ KF>>> и ~4кб флеша, чтоб подтяннуть код с внешнего атмеловского KF>>> dataflash (по SPI). Странно, что ничего такого пока не появилось. DO>> Мне как-то даже и не интересно, нет таких задач.

KF> Есть. Между линухами и виндовсами и мелким ембеддингом есть KF> большой пустой разрыв.

Есть, но я такими проектами не занимаюсь, или почти не занимаюсь, потому мне оно и не интересно.

dima