Определить размер программы

[alm604]

Доброго времени суток, форумчане.
Четвертые сутки я думаю и гуглю в свободное время о проблеме определения размера программы. Есть у меня проц, память, блок ПЗУ на 24C256 в роли диска... На этом "диске" хранятся программы. Диск разбивается на сектора по 256 байт. Если в начале сектора встречаем преамбулу - это файл. Далее его имя, тип и размер. Все работает замечательно. Программы пишу на большом компе и в листинге я вижу занимаемый объем. Тоже никаких проблем.
Но. Если я загрузил программу или даже просто текстовик и потом в оперативке его решил изменить... Если он увеличится - ничего страшного, т.к. перед загрузкой я освобождаю ОЗУ и по большому скоплению нулей (пусто) могу почти всегда определить его конец. А если уменьшится? После его логического конца может оставаться большой объем данных, более не нужных для дальнейшего сохранения на "диск". Дописывать в конце программы преамбулу тоже получается только на большом компе. Может кто-то сталкивался с подобными проблемами? Система у меня не на Z80, но разницы я особо не вижу...

[Advertiser]

[Alex Rider]

Для каждой платформы и языка программирования на ней существуют (или не существуют) свои методы определения размера программы. Поделись, пожалуйста, с нами этими сведениями.

[PATHNK]

по большому скоплению нулей

[alm604]

Счас заплюёте))) 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...a-gal16v8.html Тут я его начал делать. Тогда софтом был просто бейсик. Позже мне его стало мало и я подзабросил платку. Потом нашел PAULMON-2 и интерес снова проснулся. Пишу "драйвер" "файловой системы"))) Читать получается, записывать тоже. Но адреса приходится вводить каждый раз. Иногда, просматривая память для определения фактического конца файла. Сейчас девайсина выглядит уже страшнее: https://yadi.sk/i/6oLZ4fzXypkFSДобавил два порта GPO, Два GPI, USB-COM (CH340G), декодер адреса и LCD 256*64 с графическим и текстовым режимами на основе LC7981. Там с текстом тоже беда приключилась, но это тема отдельной статьи...

[Eltaron]

Заводить счетчик введенных символов (и удаленных), мне кажется не лучшим выходом.

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

[alm604]

Ну, похоже, так и придется делать... Сама проблема-то в платформе - у 51-го не так много внутреннего ОЗУ, к которому быстрый доступ есть. А внешнее через DPTR, да с его 12-ю тактами на команду... Чую, придется переходить на проц. МК для таких целей - не лучшее решение(

[James DiGreze]

При 12МГц не так уж и плохо 12 тактов на команду, которых не так много для обращения к ОЗУ. А не пробовал НЕ отбрасывать "преамбулу", и по ней вычислять окончание?
Вообще подход к работе с ОЗУ в MCS-51 не такой, как в микропроцессорах.

[alm604]

Если ее не отбрасывать, то придется сдвигать при изменении размера, что еще дольше, чем считать введенные/удаленные символы. Я понимаю, что подход другой, Z80 мне знаком. Ладно, спасибо за советы. Будем делать.

[AlexG]

Ну, похоже, так и придется делать... Сама проблема-то в платформе - у 51-го не так много внутреннего ОЗУ, к которому быстрый доступ есть. А внешнее через DPTR, да с его 12-ю тактами на команду... Чую, придется переходить на проц. МК для таких целей - не лучшее решение(

Если не склероз: есть же 51 с 4 и меньше тактами. У того же атмела (пользуюсь - но не люблю). или у максима (в девичестве даллас). И внутренняя память ОЗУ до килобайта (примерно) и пару DPTR регистров итд...

[alm604]

Лежит у меня MCS-251. Там примерно так же - пара DPTR, адресация шире, RAM больше и по даташиту "До 15 раз быстрее обычных MCS-51". Кроме того, в примененном мною P80C32UFPN, оказывается, тоже пара DPTR. Но, так как я эту плату сделал как раз для изучения семейства, я об этих нюансах узнал лишь недавно. Переделывать под MCS-251 пока не хочется. Задрать частоту до допустимых 33МГц желание есть, но не уверен в работоспособности UART. Пока у меня автоопределение BAUDRATE. Кажись переписывать придется. Либо цеплять внешнюю 16C550 или Z8523016. И тех и других - горсть. Но всё не покидает чувство, что надо использовать проц, а не МК и не страдать фигней))) Останавливает только удобный монитор. Под Z80 я такого пока не нашел, не говоря уж о других процах.

- - - Добавлено - - -

И еще огромный запас P80C552EBA, 74HC573 и кварцев на 11,0592)))))