Создать копию бинарного файла в формате txt, с разбивкой строк и адресацией.

[sergey.serg-72]

Сообщение от BDA

Не очень понял, что от чего отнимать.

Имел ввиду заменить операции с div , mod на простое минус ...- + /
С ними не понятно не видишь какие числа делят и трудно представить.
В общем для меня камнем преткновения они стали, может из за того, что новое и делать не приходилось.

[sergey.serg-72]

Сообщение от BDA

Тогда уж в 8 символов.

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

[BDA]

Сообщение от sergey.serg-72

вот файл после конвертера

Да, окончания строк #10.

Сообщение от sergey.serg-72

заменить операции с div , mod на простое

В принципе, можно, но если есть удобные команды div и mod, то записывать их в несколько действий нет смысла. Хотя в данном случае правильнее использовать and и shr вместо mod и div, так как делители являются степенями двойки.

    cur_high_addr := (fbin.Position + offset) shr 16;
    if cur_high_addr <> high_addr then
    begin
      high_addr := cur_high_addr;
      sum := 6 + high_addr and $FF + high_addr shr 8;
      sum := -sum;
      s := Format(':02000004%.4x%.2x%s', [high_addr, sum, sLineBreak]);
      ftxt.Write(s[1], Length(s));
    end;
    count := fbin.Read(b[0], BYTES_IN_LINE);
    sum := count + low_addr and $FF + low_addr shr 8;

Сообщение от sergey.serg-72

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

Правильное ограничение, это не fbin.Size проверить на непревышение размера. Нужно узнавать размер файла до его загрузки в поток. Но проще обернуть весь код в Try блок и обработать все возникающие ошибки с выводом своих окошек-сообщений.

[sergey.serg-72]

Сообщение от BDA

В принципе, отличия минимальные (https://en.wikipedia.org/wiki/SREC_(...SREC_Chart.png). Добавить стандартную шапку "S00600004844521B", вывести весь файл записями S3, добавить запись S5 (хотя HxD не стал ее добавлять, да и запись помечена как опциональная, так что можно не добавлять), завершить стандартной записью конца "S70500000000FA".

Я бы не сказал что минимальные, геморрой ещё тот этот srec....
Шапку добавить не проблема и конец файла.
вывести весь файл записями S3 : S3 это уже не s19 (16 бит)- 2 байта в адресе , s2 это уже s28 (24 бита ) 3 байта в адресе , а s3 это , уже получается S37 (32 бита) 4 байта в адресе.
Значит какая то разница есть между ними? я имею ввиду как я понял для микроконтроллеров есть разница 8,16 и 32 битные. иначе бы смысл какой в этом s19,s28, s37? значит один может работать на одном микроконтроллере , а другие уже нет.
И я честно говоря не видел конвертеров s37, только редакторы и то один автоматом переключает.

Всё ведь зависит от размера файла, какая длина файла такая s будет 19, маленькие размеры файла и соответственно и адреса не большие , 28 уже на много больше и в адресах три байта, ну и 37 это уже гиганты наверное с огромной адресацией.
запись S5 , да редакторы её игнорят , да и те, что есть конверторы у меня тоже игнорят.Это не обязательные записи, как и шапка к стате.
Можно и s7 завершить она как раз для 32 битной адресации, хотя обычно полный конец s9.
s5, это количество записей в файле (кроме шапки).
Тип записи в начале, потом количество данных (адрес включительно) количество байт в строке скажем 13 =19 включает 13+ адрес+сами данные пересчитал и от $FFFF отнял полученное. Вот и контролка. Это что нормально? зачем считать запись данных и адрес в подсчёт контролке, за чем?, почему не сделать как в hex? Я вообще не понимаю за чем такие сложности, просто адрес записи (зависит от размера файла) , данные и контролка строки с данными и всё, за чем такой гимор , я не понимаю. Сейчас прогеры записывают и сверяют записанное с буфером записи, если всё окей, выводится окно, если ошибка, нажал на перезапись и перезаписал всё. Не считают прогеры контролку строки, они данные записывают и сверяют с буфером по байтно.

Нет и srec трудней hex однозначно. Это только видимость что похожи, я тоже с начало нахрапом навалился стал писать и потом понял, фиг там..... 1) определить тип записи , это надо явно с адресацией увязывать , а на каком размере ? как я понял уже после 65535 байт уже s2, больше s3. Далее тип записи адрес (2 байта, три, или 4 байта ) в адресе, потом данные , а уж потом считать контролку. А в контролку входит как я уже говорил количество байт, адрес, а потом сами данные. Значит надо перво, на перво по размеру файла определится с адресацией 16, 24, или 32 битный адрес как с этим решил вырисовывается тип s19, s28, s37, далее как определились с типом, надо пересчитать данные и пересчитать данные + адрес и записать это в счётчик, а в заключении пересчитать контролку и записать в конец строки.
А с адресами я так и не понял до конца с div, mod мне проще по размеру определится файла если больше, или меньше 65535 то s19 и.тд.
Так что нахрапом не выщло, не тот у меня уровень ещё и не те знания к сожалению.
Это ещё Ботану нашему да, легче на много , пока попросили его заняться , пока он сам тупит, ждём пока.
Чтоб я врубился сам , мне построчное, по шаговое объяснение нужно, чтоб я уловил до конца, а у меня провалы по некоторым моментам . Описываю вроде правильно, потом смотрю что то не то... А раз не допонял , значит не уяснил.

SetLength(b, BYTES_IN_LINE); здесь всё ясно считали в массив данные по 16 байт для строки, вопросов нет , всё ясно что делается.
Далее, с форматом разобрался это форматирование строки при чём и hex и числовые данные и строковые, это действительно вещь хорошая, в формате
s := Format(':02000004%.4x%.2x%s', [high_addr, sum, sLineBreak]); всё ясно : начало записи ,02000004% тоже ясно шапка , 4x% адрес из 4 байт 2x%s' тоже ясно строка , ну и адрес идёт сумма и перенос строки тоже ясно .
count := fbin.Read(b[0], BYTES_IN_LINE); тоже всё ясно переменной присвоили прочитанный массив данных, здесь тоже ясно.
data_s := data_s + IntToHex(b[i], 2);
Inc(sum, b[i]); с этим тоже всё ясно.
ftxt.Write(s[1], Length(s)); с этим тоже всё ясно.

Пошли провалы :

low_addr := fbin.Position + offset; // здесь ясно что переменной low_addr word(2 байта) присваиваем позицию в файле + offset данные смещения из edit
cur_high_addr := (fbin.Position + offset) div $10000; дальше почти тоже самое только другой переменной и делим что позицию + смещение на $10000 ? для чего?
if cur_high_addr <> high_addr then здесь тоже не совсем понятно, данные адреса одной переменной не равны данным адреса другой , а какие данные? Когда не видишь то трудно представить. Если скажем требуется делением от 30, получить 6, то тут ясно что 30/ 6=5 это ясно, потому что видишь данные и понимаешь что на что , надо делить.

sum := 6 + high_addr mod $100 + high_addr div $100; далее тоже не понятное действие почему к 6 прибавляем ? откуда 6 взято? $100- это очевидно деление по модулю . 256, далее опять делим но уже с помощью div а что на выходе ?

sum := count + low_addr mod $100 + low_addr div $100; тоже самое не понятно, кроме того, что переменной sum мы присваиваем буфер данных прочитанных из файла , дальше прибавляем адрес и делим опять..... провал...

Понятно что первый блок в коде обрабатывает адреса и готовит тип записи , это понятно.
Но mod, div + адрес, затем делим по модулю 256 не ясно какие данные, цифры мы делим.
По этому провал и заминка...

А в srec уже всё по другому надо формировать.

https://ru.qaz.wiki/wiki/SREC_(file_format)

[BDA]

Если в задании сказано просто SREC и не уточнено, какой из вариантов строго, то, для упрощения переделки, лучше равняться на s37. Мне кажется, для микроконтроллеров главное, чтобы адреса в файле не вылезли за размеры памяти микроконтроллера, а не битность адреса.

Сообщение от sergey.serg-72

Всё ведь зависит от размера файла

Еще и от желаемого смещения.

Сообщение от sergey.serg-72

не обязательные записи, как и шапка к стате

Запись шапки не помечена как необязательная, так что лучше добавить.

Сообщение от sergey.serg-72

хотя обычно полный конец s9

По документации строго S9 завершает записи S1, S8 - записи S2, S7 - записи S3.

Сообщение от sergey.serg-72

почему не сделать как в hex?

Так ведь, наоборот, складывается даже меньше полей, чем в HEX. В HEX еще и поле типа прибавлялось, а в SREC - нет.

Сообщение от sergey.serg-72

Не считают прогеры контролку строки, они данные записывают и сверяют с буфером по байтно.

И зря. Мало ли как данные в файле изменили перед заливкой. А так хоть гарантия того, что потрудились и контрольные суммы под свои изменения тоже поправили.

Сообщение от sergey.serg-72

вырисовывается тип s19, s28, s37

Или смотреть максимально возможный адрес (длина файла + смещение) и выбирать тип. Или упростить себе жизнь и сразу выдавать только в формате s37.

Сообщение от sergey.serg-72

считали в массив данные по 16 байт для строки

Это не так. SetLength устанавливает размер динамического массива "b" в BYTES_IN_LINE элементов. А чтения в массив это "count := fbin.Read(b[0], BYTES_IN_LINE);".

Сообщение от sergey.serg-72

s := Format(':02000004%.4x%.2x%s', [high_addr, sum, sLineBreak]);

Тут места подстановки чуть съехали. "%.4x" - адрес, "%.2x" - контрольная сумма, "%s" - строка.

Сообщение от sergey.serg-72

count := fbin.Read(b[0], BYTES_IN_LINE);

Нет, в переменной count количество реально прочитанных байтов. А сами данные в массиве "b".

Сообщение от sergey.serg-72

low_addr word(2 байта) присваиваем позицию

Сумма позиции и смещения является 8байтовым числом, а при записи в 2хбайтовую переменную старшие байты отбросятся, а останутся младшие.

Сообщение от sergey.serg-72

на $10000 ? для чего?

Чтобы узнать старшие 2 байта адреса. Весь 4хбайтовый адрес разделяется на младшие (low_addr) и старшие (cur_high_addr) два байта.

Сообщение от sergey.serg-72

а какие данные?

У каждого прочитанного кусочка данных из файла свой полный адрес, который растет при каждом новом чтении на 16. Вот как только младшие 2 байта адреса "переполнятся", то изменяются старшие 2 байта. Простой пример для десятичных чисел: 00, 01, 02, ..., 09, 10. После 9 идет 10 - ноль сменился на единицу в старшем разряде. Вот это событие нужно поймать.

Сообщение от sergey.serg-72

откуда 6 взято?

Потому что считаем контрольную сумму строки "02000004DDDDCC", т.е. 2 + 0 + 0 + 4 + DD + DD. Адрес 2хбайтовый - к сумме нужно прибавить старший и младший байты.

Сообщение от sergey.serg-72

переменной sum мы присваиваем буфер данных прочитанных из файла

Это не буфер, а поле количества данных (в документации LL).

[sergey.serg-72]

Сообщение от BDA

Если в задании сказано просто SREC и не уточнено, какой из вариантов строго, то, для упрощения переделки, лучше равняться на s37. Мне кажется, для микроконтроллеров главное, чтобы адреса в файле не вылезли за размеры памяти микроконтроллера, а не битность адреса.

Да не уточнял и это факт ! но вот в чём загвоздка, сегодня искал материал, где применяется этот формат s37, не нашёл ни чего конкретного. Облазил разные ресурсы, все говорят о s19 и s28.
Какие то программаторы Usbdm, которые работают только с s19, другой не загрузишь ...
Конверторы по srec это s1 и s2 s3 кроме как в редакторах нигде нет. Не пойму тогда, за чем он вообще нужен. s19 работает с максимальным размером файла в 65536 байт, это потолок, если размер превышает , хоть на один байт то уже идёт s28 (s2). И как я понял самый универсальный это s28 (s2) от 65537 байт и до огромного размера , таких микроконтроллеров , точней памяти просто быть не должно, редакторы зависают от размера, а какой программатор выдержит ?
А s37 вообще не понятно для чего нужен, нет таких микроконтроллеров , с таким объёмом памяти.
Зачем он нужен вообще и где его применяют , я так и не нашёл.
Я думаю что s2 для всех задач за глаза..... А что касается, чтоб главное адреса не вылезли не знаю, с программаторами дел не имел пока, но тогда почему многие софты программаторов так критичны и требуют именно s19, или s2 ? Значит этот момент , как то проверяется, может по адресу в файле как раз? не знаю ? Тогда чтоб не заморачиваться ,сразу универсальный бы делали s37 и всё, за чем s19, s28 тогда ? В принципе можно сделать s37, но подписывать выходной файл как s19, если какой то прогер чисто по подписанному формату файла принимает , тогда обмануть можно переименовав , а если проверяет как раз данные типа записи 1,2, или 3? количество байт в адресе 2,3 , а 4 уже не примет? тогда не обманешь.
Трудно сказать, но я так и не нашёл где применяют s37. Видимо очень специфично и узко направленное применение.

[sergey.serg-72]

Сообщение от BDA

Еще и от желаемого смещения.

Если смещение задаётся то да, а если файл не очень большой и запись с 0 адреса и чисто размер то не нужно смещение.

Сообщение от BDA

Запись шапки не помечена как необязательная, так что лучше добавить.

Согласен .

Сообщение от BDA

По документации строго S9 завершает записи S1, S8 - записи S2, S7 - записи S3.

Да, действительно Вы правы, сейчас перечитал это факт.

[sergey.serg-72]

Сообщение от BDA

Так ведь, наоборот, складывается даже меньше полей, чем в HEX. В HEX еще и поле типа прибавлялось, а в SREC - нет.

а разве не одинаково что там 6, что там ?

[sergey.serg-72]

Сообщение от BDA

И зря. Мало ли как данные в файле изменили перед заливкой. А так хоть гарантия того, что потрудились и контрольные суммы под свои изменения тоже поправили.

Ну да, если кто то нарочно в файле, подправил данные в блокноте то да , прогер не отловит.
Хотя контролка не спасёт, можно испортить данные так, чтоб подогнать под контрольную сумму строки. А сами данные испортить. Тем более как подсчитывается сумма строки не секрет.
Так что и это не гарантия.

Сообщение от BDA

Или смотреть максимально возможный адрес (длина файла + смещение) и выбирать тип. Или упростить себе жизнь и сразу выдавать только в формате s37.

Да, упростить это было бы классно. Я обеими руками только за !. Да вот как ранее говорил, а возьмёт ли софт программатора такой файл, даже, если в выходной прописать как s19? Не проверяет ли тип записи и байты адреса?

Сообщение от BDA

Это не так. SetLength устанавливает размер динамического массива "b" в BYTES_IN_LINE элементов. А чтения в массив это "count := fbin.Read(b[0], BYTES_IN_LINE);

Вы правы я это и имел ввиду, не так выразился.

Сообщение от BDA

Нет, в переменной count количество реально прочитанных байтов. А сами данные в массиве "b".

Понял !.

Сообщение от BDA

Сумма позиции и смещения является 8байтовым числом, а при записи в 2хбайтовую переменную старшие байты отбросятся, а останутся младшие.

Теперь понял .

Сообщение от BDA

У каждого прочитанного кусочка данных из файла свой полный адрес, который растет при каждом новом чтении на 16. Вот как только младшие 2 байта адреса "переполнятся", то изменяются старшие 2 байта. Простой пример для десятичных чисел: 00, 01, 02, ..., 09, 10. После 9 идет 10 - ноль сменился на единицу в старшем разряде. Вот это событие нужно поймать.

Понял, разобрался теперь.

Сообщение от BDA

Чтобы узнать старшие 2 байта адреса. Весь 4хбайтовый адрес разделяется на младшие (low_addr) и старшие (cur_high_addr) два байта.

понял.

Сообщение от BDA

Потому что считаем контрольную сумму строки "02000004DDDDCC", т.е. 2 + 0 + 0 + 4 + DD + DD. Адрес 2хбайтовый - к сумме нужно прибавить старший и младший байты.

Вот теперь понял.

Сообщение от BDA

Это не буфер, а поле количества данных (в документации LL).

Да, это я неправильно выразился .

Сообщение от BDA

В принципе, можно, но если есть удобные команды div и mod, то записывать их в несколько действий нет смысла. Хотя в данном случае правильнее использовать and и shr вместо mod и div, так как делители являются степенями двойки.

Согласен лишние действия , просто and и shr знакомы , а div и mod, новенькое.
Но лучше тогда их использовать, чтоб не повторять действия.

Сообщение от BDA

Правильное ограничение, это не fbin.Size проверить на непревышение размера. Нужно узнавать размер файла до его загрузки в поток. Но проще обернуть весь код в Try блок и обработать все возникающие ошибки с выводом своих окошек-сообщений.

Это конечно правильней , тут и не поспоришь.
А , если до загрузки ?

if dlgOpen1.Execute then
begin

Просто привычней : if fbin.Size > .....? then
begin
ShowMessage('Недопустимый размер файла, строго до ..... байт !');
fbin.Free;
exit;
end
else
begin

[sergey.serg-72]

sergey.serg-72,

Сегодня на соседнем потоке , нашли человека, он увлекается электроникой , программы пишет для микроконтроллеров, у него куча прогеров и он спец по прошиваниям всяким электроники.
Попросили проверить мою версию , оказывается что srec, это для программирования в основном микроконтроллеров от фирмы MOTOROLA. В основном, у нас в Стране используют три программатора для этих целей, один Штатовский, второй Китайский и третий от Нашего производителя. Самые популярные размеры, в пределах 65536 и 98304 байта + - , по факту это и есть s1 и s2. В общем в редакторе сделали s37, переименовали как s19 . Из трёх программаторов два сразу при загрузке файла в ошибку и загружать отказались такой файл. Третий, отечественный загрузил, но человек побоялся прошивать им, так как у него отладочная плата нужна на данный момент... В общем рисковать не стал, сказал что позже попробует.
Как этот человек утверждает, что в работе (а он продвинутый, в теме), сколько этим делом занимается , не разу s3 (37) не попадались. И софты прогеров, максимум сохраняют в s2, хотя подписывают как s19. Вывод: Два софта, отказались брать s37 (это фирменные программаторы) , переименование помогает при s2 , s1 . S3 переименование не помогает софт не принимает.
Опытный Чел, ни разу не сталкивался с s3, хотя MOTOROLA у него гость частый.
Как он объяснил, что есть 8 разрядные (уходят уже в прошлое) 16 и 32 разрядные микроконтроллеры. Но не смотря на то, что 32 разрядные должны подходить под s3, на самом деле софты сохраняют как s19, хотя по факту там s2, s3 отказываются загружать. Значит я прав оказался, софты как то проверяют, обмануть не получается и второе это видимо специфичный s37. В большинстве случаев, с ним не сталкиваются, те кто этим занимается.

А если Джонс спросит почему s37 ?, такой редкий и не популярный , выбрал ? Чем руководствовался ? Г де этот формат применяется ?, а я за 2 дня найти не могу где и спец не сталкивался с ним....