MPLAB C18 EEPROM initialization

Loading thread data ...
Reply to
Nickita A Startcev

Hello, Kirill !

Once (Thursday October 01 2009) at 19:03 someone named Kirill Frolov wrote to Dmitry Orlov. So, look here:

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

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

=== Cut ===

formatting link
Cut ===

Reply to
Wiktor Martyshenko

Hello, Slav Matveev! You wrote in conference fido7.ru.embedded to Alexander Torres on Fri, 02 Oct

2009 01:37:27 +0400:

AT>> Hет никакого "диска," код находится в ПЗУ процессора.

SM> в этом коде не присутствуют начальные значения переменных?

const и data присутствуют, а bss - нет, зачем?

dima

formatting link

Reply to
Dmitry Orlov

Fri Oct 02 2009 01:34, Dmitry Orlov wrote to Kirill Frolov:

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

printf там единственное что не пришлось трогать, ибо работает. Hо внутрь смотреть реально страшно. Hет вру, пришлось, но это уже ввиду собственно багов в 9.51pl2

formatting link
KF>> 2) код пишут по большей части такие "индусы", DO> А то для других архитектур кодеров с Марса завозят...

"AVR -- контроллер любительского уровня" Хотя уровень libc в составе avr-gcc (avr-libc) куда менее индусский, чем у hitech-c. Оттуда просто можно массово воровать полезные функции, они даже с тестами.

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

Вот и сошлись примерно на одном (другим на заметку).

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

Hет, не salvo. У salvo кооперативная. Там вообще одну чудную вещь сделали, сами не догадываются, очень полезную. Хотели они просто псевдомногозадачность а-ля protothreads. Hо ихняя реализация заставляет _вручную_ метки определять, куда можно в функцию вернуться после возврата управления "задаче". Так вот тот факт что вручную -- это, фактичеки, программирование с явным выделением состояний (аналог методики им. А. А. Шалыто). Это мега-полезно потому, что позволяет уйти от массы алгоритмических ошибок, потому, что заставляет программиста вначале проектировать автомат, потом код писать (в данном случае не совсем явно, но вынуждает к тому).

DO> Hа pic16 программа за 90% кода занимает,

По-моему это очень плохая идея. Для "mass-production". Hу, по крайней мере, до момента пока проект не закрыт совсем. Я бы думал о <70%, треть под на всякий случай.

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

Это получается через ()() и плохо кончается. Архитектура ПО должна определяться свыше, а не подгоняться на ходу по месту. Я теперь вообще имею мнение, что в embedded development начинать надо С СОФТА, а не традиционно...

[ZX]
Reply to
Kirill Frolov
Reply to
Alexander Torres

Fri Oct 02 2009 12:35, Wiktor Martyshenko wrote to snipped-for-privacy@fk0.pp.ru:

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

formatting link
Внешний флеш с 8-ю ножками или параллельная шина на пол-платы размером -- вот в чём разница. Поэтому внутренний флеш на пару килобайт -- очень хочется.

[ZX]
Reply to
Kirill Frolov
Reply to
Dimmy Timchenko

Привет, Kirill !

02 Oct 09 , 12:54 Kirill Frolov писал к Dmitry Orlov:

KF> Я теперь KF> вообще имею мнение, что в embedded development начинать надо С СОФТА, KF> а не традиционно...

Ээ.. С какого именно софта? С компилятора?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... 2B or not 2B = FFFFFFFFFFFFFFFF

Reply to
Nickita A Startcev

Привет, Kirill !

02 Oct 09 , 12:58 Kirill Frolov писал к Wiktor Martyshenko:

KF> Внешний флеш с 8-ю ножками или параллельная шина на пол-платы KF> размером -- вот в чём разница. Поэтому внутренний флеш на пару KF> килобайт -- очень хочется.

Посмотри по приколу какой-нибудь 'spartan 3e'. вдруг устроит?

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

Reply to
Nickita A Startcev
Reply to
Alexander Torres

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

08:54:39 +0000 (UTC):

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

KF> printf там единственное что не пришлось трогать, ибо работает. Hо KF> внутрь смотреть реально страшно. Hет вру, пришлось, но это уже ввиду KF> собственно багов в 9.51pl2

formatting link
В 9х printf'ом еще не приходилось пользоваться (у меня сейчас 9.63PL1).

KF>>> 2) код пишут по большей части такие "индусы", DO>> А то для других архитектур кодеров с Марса завозят...

KF> "AVR -- контроллер любительского уровня" Хотя уровень libc в

C AVR примерно 10 лет назад я IAR использовал, потом лет 5 назад тоже, с тех пор я этой архитектурой не пользовался.

KF> составе avr-gcc (avr-libc) куда менее индусский, чем у hitech-c. KF> Оттуда просто можно массово воровать полезные функции, они даже с KF> тестами.

Учту.

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

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

KF> Вот и сошлись примерно на одном (другим на заметку).

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

DO>> Salvo кажется. Hа фиг, мне оно не нужно.

KF> Hет, не salvo. У salvo кооперативная.

А какая же тогда?

DO>> Hа pic16 программа за 90% кода занимает,

KF> По-моему это очень плохая идея. Для "mass-production". Hу, по KF> крайней мере, до момента пока проект не закрыт совсем. Я бы думал о KF> <70%, треть под на всякий случай.

Hу так оно в начале так и было :) Разраслось.

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

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

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

KF> Это получается через ()() и плохо кончается. Архитектура ПО должна KF> определяться свыше, а не подгоняться на ходу по месту. Я теперь KF> вообще имею мнение, что в embedded development начинать надо С KF> СОФТА, а не традиционно...

У меня традиционно с железа все начинается.

dima

formatting link

Reply to
Dmitry Orlov

Hello, Kirill !

Once (Friday October 02 2009) at 12:58 someone named Kirill Frolov wrote to Wiktor Martyshenko. So, look here:

KF> Внешний флеш с 8-ю ножками или параллельная шина на пол-платы KF> размером -- вот в чём разница. Поэтому внутренний флеш на пару KF> килобайт -- очень хочется.

Hа вскидку глянул один из даташитов, оказалось, что там "4 Kbyte boot ROM", а кроме того "I2C interface that allows booting from EEPROM devices" так что, видимо это как раз то, что надо.

Reply to
Wiktor Martyshenko
Reply to
Michael Belousoff
Reply to
Alexander Torres

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.