Просмотр полной версии : Определить размер программы
Доброго времени суток, форумчане.
Четвертые сутки я думаю и гуглю в свободное время о проблеме определения размера программы. Есть у меня проц, память, блок ПЗУ на 24C256 в роли диска... На этом "диске" хранятся программы. Диск разбивается на сектора по 256 байт. Если в начале сектора встречаем преамбулу - это файл. Далее его имя, тип и размер. Все работает замечательно. Программы пишу на большом компе и в листинге я вижу занимаемый объем. Тоже никаких проблем.
Но. Если я загрузил программу или даже просто текстовик и потом в оперативке его решил изменить... Если он увеличится - ничего страшного, т.к. перед загрузкой я освобождаю ОЗУ и по большому скоплению нулей (пусто) могу почти всегда определить его конец. А если уменьшится? После его логического конца может оставаться большой объем данных, более не нужных для дальнейшего сохранения на "диск". Дописывать в конце программы преамбулу тоже получается только на большом компе. Может кто-то сталкивался с подобными проблемами? Система у меня не на Z80, но разницы я особо не вижу...
Alex Rider
17.11.2016, 11:49
Для каждой платформы и языка программирования на ней существуют (или не существуют) свои методы определения размера программы. Поделись, пожалуйста, с нами этими сведениями.
по большому скоплению нулей:biggrin:
Счас заплюёте))) MCS-51 и переписанный PAULMON-2. 0000H-7FFFH - EEPROM (PSEN) и RAM (WR/RD), 8000H-FCFFH - NVRAM, дальше периферия. I2C для 24C256 на порту 1 (GPIO, по сути). Программа или просто текст (или исходный код) переносится из I2C EEPROM в RAM с 2000H и выше. Потолок, получается 7FFFH. И вот когда я файл в ОЗУ переписал (к примеру, текст), я еще в курсе где его конец, а когда я его укоротил - уже не знаю.
На большом компе в заготовке под эти программы в конце у меня записано что-то типа:
ret ; Возврат в монитор
ORG 55H, AAH, FFH, FEH ; Преамбула
END.
И при загрузке в ОЗУ это, конечно, отбрасывается. Заводить счетчик введенных символов (и удаленных), мне кажется не лучшим выходом.
- - - Добавлено - - -
Да понимаю я, что эти нули могут быть нужны... Но пока программ всего несколько, так что я справлюсь и ручным подсчетом. Но хотелось бы прям кнопочку Save и файл улетел в EEPROM.
- - - Добавлено - - -
Чтоб еще лучше представлять девайс:
http://zx-pk.ru/threads/26190-proshu-sozdat-fajl-dlya-gal16v8.html Тут я его начал делать. Тогда софтом был просто бейсик. Позже мне его стало мало и я подзабросил платку. Потом нашел PAULMON-2 и интерес снова проснулся. Пишу "драйвер" "файловой системы"))) Читать получается, записывать тоже. Но адреса приходится вводить каждый раз. Иногда, просматривая память для определения фактического конца файла. Сейчас девайсина выглядит уже страшнее: https://yadi.sk/i/6oLZ4fzXypkFSДобавил два порта GPO, Два GPI, USB-COM (CH340G), декодер адреса и LCD 256*64 с графическим и текстовым режимами на основе LC7981. Там с текстом тоже беда приключилась, но это тема отдельной статьи...
Заводить счетчик введенных символов (и удаленных), мне кажется не лучшим выходом.
Ну а как без счетчика? Вот только надо хранить не это, а указатель на последний байт программы - это ведь всего лишь два несчастных байта.
Инкремент при вводе символа, декремент при удалении.
Это позволит и от костыля с поиском "большого количества нулей" избавиться, т.к. точный размер программы всегда можно получить в одно вычитание, неважно, увеличился он или уменьшился.
Ну, похоже, так и придется делать... Сама проблема-то в платформе - у 51-го не так много внутреннего ОЗУ, к которому быстрый доступ есть. А внешнее через DPTR, да с его 12-ю тактами на команду... Чую, придется переходить на проц. МК для таких целей - не лучшее решение(
James DiGreze
17.11.2016, 13:55
При 12МГц не так уж и плохо 12 тактов на команду, которых не так много для обращения к ОЗУ. А не пробовал НЕ отбрасывать "преамбулу", и по ней вычислять окончание?
Вообще подход к работе с ОЗУ в MCS-51 не такой, как в микропроцессорах.
Если ее не отбрасывать, то придется сдвигать при изменении размера, что еще дольше, чем считать введенные/удаленные символы. Я понимаю, что подход другой, Z80 мне знаком. Ладно, спасибо за советы. Будем делать.
Ну, похоже, так и придется делать... Сама проблема-то в платформе - у 51-го не так много внутреннего ОЗУ, к которому быстрый доступ есть. А внешнее через DPTR, да с его 12-ю тактами на команду... Чую, придется переходить на проц. МК для таких целей - не лучшее решение(
Если не склероз: есть же 51 с 4 и меньше тактами. У того же атмела (пользуюсь - но не люблю). или у максима (в девичестве даллас). И внутренняя память ОЗУ до килобайта (примерно) и пару DPTR регистров итд...
Лежит у меня MCS-251. Там примерно так же - пара DPTR, адресация шире, RAM больше и по даташиту "До 15 раз быстрее обычных MCS-51". Кроме того, в примененном мною P80C32UFPN, оказывается, тоже пара DPTR. Но, так как я эту плату сделал как раз для изучения семейства, я об этих нюансах узнал лишь недавно. Переделывать под MCS-251 пока не хочется. Задрать частоту до допустимых 33МГц желание есть, но не уверен в работоспособности UART. Пока у меня автоопределение BAUDRATE. Кажись переписывать придется. Либо цеплять внешнюю 16C550 или Z8523016. И тех и других - горсть. Но всё не покидает чувство, что надо использовать проц, а не МК и не страдать фигней))) Останавливает только удобный монитор. Под Z80 я такого пока не нашел, не говоря уж о других процах.
- - - Добавлено - - -
И еще огромный запас P80C552EBA, 74HC573 и кварцев на 11,0592)))))
James DiGreze
17.11.2016, 14:55
Если ее не отбрасывать, то придется сдвигать при изменении размера, что еще дольше, чем считать введенные/удаленные символы.
Вопрос: предполагается добавление текста не только в конец файла, или только в конец?
Лежит у меня MCS-251. Там примерно так же - пара DPTR, адресация шире, RAM больше и по даташиту "До 15 раз быстрее обычных MCS-51". Кроме того, в примененном мною P80C32UFPN, оказывается, тоже пара DPTR. Но, так как я эту плату сделал как раз для изучения семейства, я об этих нюансах узнал лишь недавно. Переделывать под MCS-251 пока не хочется. Задрать частоту до допустимых 33МГц желание есть, но не уверен в работоспособности UART. Пока у меня автоопределение BAUDRATE. Кажись переписывать придется. Либо цеплять внешнюю 16C550 или Z8523016. И тех и других - горсть. Но всё не покидает чувство, что надо использовать проц, а не МК и не страдать фигней))) Останавливает только удобный монитор. Под Z80 я такого пока не нашел, не говоря уж о других процах.
- - - Добавлено - - -
И еще огромный запас P80C552EBA, 74HC573 и кварцев на 11,0592)))))
Лично мне не нравятся АРМ и еже с ними (звук не ламповый). 51 семейство обширное и много разных видов одного типаразмера (что дип что плсс - пин-то-пин), на асме писать просто. куча встроенной периферии + озу+флеш (не мегобайты - но всё же). Вот "сейчас" надо доработать программу 15-летней давности. 8кб кода на асме. Изделие работает по 24 часа 365 дней в году (утрировано).
семейство 251 загнулось на корню - его практически никто не "скопировал". а 51 живо и здорово нынче.
Конечно, добавление и удаление может быть в любой части памяти (файла).
Мне после AVR, STM тоже понравился 51-й. Особенно тем, что работает, как процессор. Пусть и с костылём (RD || PSEN)
James DiGreze
18.11.2016, 05:21
Тогда в любом случае идёт довольно обширное копирование внутри памяти.
Почитай тему Как организовать память для текстового редактора? (http://zx-pk.ru/threads/21012-kak-organizovat-pamyat-dlya-tekstovogo-redaktora.html). В зависимости от подхода к организации памяти будет понятно, как эффективнее определять размер получившегося файла.
Офигеть! А про редактирование-то я вообще не думал, оказывается... Задача оказывается более сложной, чем кажется(
James DiGreze
18.11.2016, 16:40
Если изначально ввести ограничение на максимальный размер файла, всегда заведомо меньший объёму ОЗУ, то задача вполне посильная. И уж точно производительности "полстапервого" с кварцем "110592" вполне за глаза.
ram_scan
25.11.2016, 10:59
Задача на самом деле тривиальная.
Часть текста до курсора хранится в начале памяти, часть после - в конце. Посередине дырка.
Текст на экране отрисовывается от курсора вниз, и от курсора вверх. Вставка текста происходит в дырку. При навигации по тексту дырка перемещается вместе с курсором. При добавлании - добавляется в начало дырки, и дырка уменьшается, при удалении символов - дырка увеличивается.
Всего геморроя - указатель на начало текста, указатель на конец текста, указатель на начало дырки, указатель на конец дырки. Ну и при навигации дырку эту правильно по памяти возить (перекидывать порции текста из начала дырки в конец и обратно). Поскольку человек жмет кнопки гораздо медленнее чем процессор работает, а дальше чем на один экран зараз листать текст нет смысла, то все работает очень шустренько. Медленно только в начало и в конец документа переход будет работать, там надо дырку далеко двигать и много данных перемещать. Но это операция нечастая.
При выгрузке документ просто склеивается из двух кусков, чтобы дырки не было.
Вся проблема в том, то оперативы у 51-го маловато. Просто указатели я хранить постоянно не могу - DPTR всего два и то, это далеко не у всех 51-ых. Можно хранить в регистрах и подгружать в DPTR при необходимости, конечно, но это дополнительные телодвижения. Короче, я попробую. По-любому вопросы возникнут - напишу)
blackmirror
25.11.2016, 17:48
alm604, два DTPR это более чем достаточно, с одним DTPR конечно придётся сначала пройтись по начальной или конечной половине текста, чтобы выяснить сколько байт нужно копировать, а затем уже копировать заталкивая по нескольку байт в стек или регистры. Вообще при прокрутке назад всё равно сначала нужно узнать сколько символов в предыдущей строке чтобы правильно выставить курсор в случае когда длина предыдущей строки больше ширины экрана. Хотя от предварительного прохода назад можно избавиться если вместо символа перевода строки в начальном блоке хранить длину строки перед символом перевода, а в конечном блоке длину строки после символов перевода, для текущей строки разумеется должна быть известна длина до и после курсора. Такой вариант позволит при предварительном проходе для прокрутки на одну строку или страницу не просматривать каждый символ строки а вычислить копируемую область на основе длин строк.
James DiGreze
26.11.2016, 08:17
Даже одного DPTR более чем. Просто не нужно стесняться делать "телодвижения" - производительности хватит за глаза.
Alex Rider
27.11.2016, 15:36
Это точно тема для "Программирования" в разделе ZX Spectrum Software? Может, перенести ее туда, где больше почитателей 51-й серии найдется?
Согласен. Я только не особо понял структуру форума(
Barmaley_m
11.12.2016, 01:40
Правильно ли я понял, что стоит задача организовать в ПЗУ файловую систему, т.е. определить формат служебной и полезной информации о хранящихся в этом ПЗУ файлах?
Если да, то нужно хоть немного почитать матчасть о построении файловых систем.
Самый простой пример файловой системы - TR-DOS. В TR-DOS достигнута предельная простота, но файлы не могут менять свой размер. Можно только стереть файл и записать на диск новый - пока не исчерпается свободное место. Место, которое занимали стертые файлы, просто так повторно использовать нельзя. Чтобы вернуть его "в оборот", необходимо двигать файлы по диску, чтобы их уплотнить. Эта операция может быть довольно долгой. Но не смертельной. Многие из присутствующих "жили" под TR-DOS с реальными дисководами.
Примеры чуть посложнее - Apple ][ DOS, CP/M. В этих файловых системах файл может быть фрагментирован - т.е. разбросан кусками по диску. Место, занимаемое стертыми файлами, может быть использовано для записи кусков новых файлов.
Еще более продвинутая ФС - Microsoft FAT12. Здесь тоже файлы могут быть фрагментированы. Но реализовать полноценную MS FAT12 довольно сложно из-за того, что в ней могут быть длинные файлы (которые не влезут в твое ОЗУ), а также поддерживаются вложенные подкаталоги. Можно на базе идей FAT сделать что-нибудь упрощенное, вроде файловой системы ADS от Andrew Strikes Code (используется в музыкальном редакторе ASM).
Определять же начало файла по "преамбуле" или конец файла по "скоплению нулей" - значит напрашиваться на неприятности. Что, если в каком-нибудь файле встретится такая же последовательность байт, как в преамбуле? Это приведет к ложному обнаружению файла, т.е. к сбою файловой системы. То же касается "скопления нулей" - если такое скопление они вдруг окажется частью какого-нибудь файла - то это приведет к ложному детектированию конца файла.
В некоторых древних файловых системах конец файла определяется по определенному байту (0x1A), но при этом гарантируется, что этот байт нигде в файле не встретится, а только в его конце. Такой подход накладывает ограничения на содержимое файлов.
Размер сектора 256 байт - это как-то многовато для накопителя объемом 32Кб. Как бы так не вышло, что накопитель будет неэффективно использоваться. У этой флеш-памяти есть минимальный размер страницы для стирания или записи? Какой он имеет размер? Лучше сделать размер сектора равным размеру минимального блока, который можно за раз стереть.
Спасибо за развернутую подсказку. ФС TR-DOS даже не рассматривал, только сейчас почитал о ней. И вот какая мысль крутится у меня в голове уже довольно длительное время - а не отдать ли часть работы ЦП какому-нибудь быстрому МК, например STM8S207, который как раз имеется. Сделать его частью адресного пространства, а уже в МК реализовать поддержку ФС. Можно даже FAT32. 51-й (и, вроде, 8085) выдают старшую часть адреса с самого начала обращения к памяти, так что МК, работая на 24МГц, должен успеть защелкнуть адрес. Я понимаю, что использование в составе системы на старой элементарной базе современных МК сильно не приветствуется в Вашем сообществе, т.к. их скорости сильно выше тех же Z80, 8051 и прочих. Но несомненный плюс для меня заключается в том, что 51-й может исполнять загружаемый в ОЗУ код и объемы этого ОЗУ сильно больше даже некоторых ARM. С AVR такое не прокатит, с STM8 тоже. STM32 мне пока без боя сдаваться никак не хотят(
Вернусь к идее. Все в курсе как выглядит CF или HDD IDE со стороны проца? Несколько регистров и все. Аналогично хочу сделать с STM. У нее много ног, она нафарширована всякими АЦП и таймерами. Цепляю к ней клавиатуру от нетбука (уже в наличии и я вызвонил ее схему), RTC, SD карточку, дисплей. Одна нога МК пойдет на ногу прерывания 51-го. В обработчике 51-й спросит у МК номер прерывания (что именно вызвало) и обработает. Сейчас обдумываю таблицу регистров и их назначения. Единственное, что меня тревожит - успеет ли МК ответить, вписаться в стандартный цикл чтения/записи 51-го. Особенно, если я позже решу задрать ему частоту повыше 11.0592. Проблемы с RS232 не будет, т.к. это теперь тоже головные МК)
Barmaley_m
11.12.2016, 21:20
И вот какая мысль крутится у меня в голове уже довольно длительное время - а не отдать ли часть работы ЦП какому-нибудь быстрому МК, например STM8S207, который как раз имеется.
Можно, но зачем? Быстродействия 8051 хватит за глаза для реализации файловой системы (хоть FAT32) не то, что в флешке, а даже на реальном дисководе, где быстродействие программы критично. Лишь бы только мозгов программиста хватило на реализацию необходимых процедур. Я бы начал с реализации ФС на языке C, а потом либо компилятор нашел под нужную платформу, либо вручную перевел на ассемблер. Программу можно изначально писать на обычном компе. Отлаживать ее в свое удовольствие, а потом адаптировать отлаженный алгоритм к целевой платформе.
Я понимаю, что использование в составе системы на старой элементарной базе современных МК сильно не приветствуется в Вашем сообществе, т.к. их скорости сильно выше тех же Z80, 8051 и прочих.
За все сообщество не скажу, а мне в принципе все равно, на какой элементной базе реализовано решение, лишь бы оно работало.
Когда медленный МК управляет быстрым - это получается "хвост вертит собакой", выглядит некрасиво. Но иногда даже на PC встречается подобное. Например, видеокарта быстрее, чем процессор, решает некоторые задачи. Тем не менее она работает как периферия, а ведущее устройство в системе - процессор.
Единственное, что меня тревожит - успеет ли МК ответить, вписаться в стандартный цикл чтения/записи 51-го. Особенно, если я позже решу задрать ему частоту повыше 11.0592.
У некоторых МК для этих целей имеется периферия под названием "Parallel Slave Port". Это аппаратное устройство может выдержать очень жесткие рамки циклов чтения-записи, буферирует данные и ослабляет нагрузку на центральный процессор МК.
Я пробовал использовать fatfs от Чена как раз на STM8. Довольно шустрая либа. Вот только флеша она сожрала больше 20 КБ. В описании библиотеки я видел, что она может использоваться и на 51-ых, но не встречал в интернете реализации. Сам адаптировать не пробовал. Для такой подпрограммы потребуется подмена ПЗУ. В принципе это реализуемо даже без использования GAL или CPLD. Просто я не нашел это изящным решением, видимо. К тому же еще хочу и клавиатуру подключить, и часы... В общем тут прям просится периферийный контроллер. Но, в любом случае, спасибо за советы. Очень помогает взгляд на архитектуру со стороны.
James DiGreze
12.12.2016, 14:34
В общем тут прям просится периферийный контроллер.Для 51-го - избыточно.
Для такой подпрограммы потребуется подмена ПЗУ. В принципе это реализуемо даже без использования GAL или CPLD.
Для чего? Дрыгать двумя лапками на SD можно даже программно, а уж если есть внутренний SPI, то вопрос вообще можно не рассматривать. Поддержка FAT32 отнимет 4-5 Кб ПЗУ на ассемблере, и ещё 2-3 Кб ОЗУ под буферы, если не хочется лишних тормозов. На мой взгляд, было бы разумным в ПЗУ содержать только загрузчик основных программ с SD в ОЗУ, а уже развёрнутые процедуры, например, полноценной работы с FAT, запускать в ОЗУ, благо 51-й может код исполнять из него.
P.S. Любопытно взглянуть на схему имеющегося прототипа.
Написать поддержку FAT32 на асме для меня - что-то маловероятное. Тем более утолкать его в 4-5 КБ. Как я упоминал, уже написанная библиотека (правда почти с полными возможностями ФС - создание файлов, папок и прочим) заняла более 20 КБ. А у меня ПЗУ сейчас только 8 КБ отведено. Это чтоб увеличить объем ОЗУ из которого можно выполнять программу. И хотелось бы его еще уменьшить. Так что дело не в ногах.
Схемы я еще толком не рисовал. Так, наброски. А плату сделал. Ну бывает у меня так. Вот я фото выкладывал: http://zx-pk.ru/threads/26190-proshu-sozdat-fajl-dlya-gal16v8/page2.html.
И вторая плата сверху ставится: https://yadi.sk/i/oxgQOZK033EWiM. На ней пара GPI и пара GPO, плюс дисплей. Схемы тоже нет) не рисую, если тут всего несколько микросхем.
Для 51-го - избыточно.
Его я выбрал из соображений возможности выполнения кода из ОЗУ и потому, что у меня их очень много. Еще есть Z80 пара штук, 8080, 8085 (по одному каждого), MB89, MB90, H8, XA-G3(очень интересный камешек), SH2, SH4, ВМ86, Am186, 80286, 80196. Это те, которые каким-либо образом могут выполнять код из ОЗУ. Но для большинства из них нет сред разработки и программаторов, сложные для меня архитектуры. Для 51-го есть готовый и мощный бейсик, хороший, документированный монитор, который я легко могу переписывать под свои нужды. Конкурентом ему вижу пока только Z80, для которого тоже уйма ПО есть, но так вышло, что для 51-го я уже плату макетную сделал. К тому же, видел много SBC на Z80, а на 51-м всего с десяток и те работают по терминалу или на LCD 2*16, что для меня как-то несерьезно. ПК, как таковых на 51-ых не собирали.
James DiGreze
14.12.2016, 06:58
Его я выбрал из соображений возможности выполнения кода из ОЗУПо-этому то я и говорю, что избыточно.
Ведь в случае прикошачивания STM придётся изобретать протокол обмена между оным и MCS51, что порой чревато ещё большими трудностями, которые могут быть изначально не на поверхности.
С другой стороны, это лишь моё личное видение решения задачи, сообразно моему личному опыту работы с 51-м семейством. Не обращайте внимания на брюзжание, не опускайте рук, делайте - это как минимум интересно ;)
тема сумбурнейшая, обсуждаем вопросы:
1. как управлять свободной памятью в PAULMON Monitor;
2. какую файловую систему применять для rom-disk;
3. реализация периферийного сопроцессора для mcs51 на ARM-е;
помоему пора слить ее в раздел "для начинающих" и назвать типа как - "самопал на mcs-51, софт и железо"
Alex Rider
14.12.2016, 20:45
помоему пора слить ее в раздел "для начинающих" и назвать типа как - "самопал на mcs-51, софт и железо"
Вопрос к автору темы.
Да, перенесите, пожалуйста.
Alex Rider
18.12.2016, 19:54
Готово
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot