Форум программистов
 
Регистрация на форуме тут, о проблемах пишите сюда - alarforum@yandex.ru, проверяйте папку спам! Обязательно пройдите активизацию e-mail, а тут можно восстановить пароль.

Как купить рекламу на форуме


Вернуться   Форум программистов > Delphi программирование > Общие вопросы Delphi
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме 20000 рублей в месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 24.03.2021, 23:32   #101
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

Цитата:
Сообщение от 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; 25.03.2021 в 00:35.
sergey.serg-72 вне форума Ответить с цитированием
Старый 24.03.2021, 23:43   #102
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

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

Цитата:
Сообщение от BDA Посмотреть сообщение
Запись шапки не помечена как необязательная, так что лучше добавить.
Согласен .

Цитата:
Сообщение от BDA Посмотреть сообщение
По документации строго S9 завершает записи S1, S8 - записи S2, S7 - записи S3.
Да, действительно Вы правы, сейчас перечитал это факт.

Последний раз редактировалось BDA; 25.03.2021 в 01:49.
sergey.serg-72 вне форума Ответить с цитированием
Старый 25.03.2021, 00:03   #103
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

Цитата:
Сообщение от BDA Посмотреть сообщение
Так ведь, наоборот, складывается даже меньше полей, чем в HEX. В HEX еще и поле типа прибавлялось, а в SREC - нет.
а разве не одинаково что там 6, что там ?
Изображения
Тип файла: jpg форматы srec и hex.JPG (35.4 Кб, 40 просмотров)
sergey.serg-72 вне форума Ответить с цитированием
Старый 25.03.2021, 00:05   #104
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

Цитата:
Сообщение от 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

Последний раз редактировалось BDA; 25.03.2021 в 02:15.
sergey.serg-72 вне форума Ответить с цитированием
Старый 25.03.2021, 22:06   #105
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

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 дня найти не могу где и спец не сталкивался с ним....
Изображения
Тип файла: jpg ошибка.JPG (11.4 Кб, 32 просмотров)

Последний раз редактировалось sergey.serg-72; 25.03.2021 в 22:14.
sergey.serg-72 вне форума Ответить с цитированием
Старый 27.03.2021, 18:41   #106
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

Цитата:
Сообщение от BDA Посмотреть сообщение
Или смотреть максимально возможный адрес (длина файла + смещение) и выбирать тип. Или упростить себе жизнь и сразу выдавать только в формате s37.
Сегодня экспериментальным путём ,(было не легко признаться) удалось выяснить с каким максимальным размером файла, работает определённый тип записи.
Получилось следующие (может кому пригодится) а то в википедии не всё описано.

формат s19 идёт строго от 0 до 65536 байт .

формат s28 идёт от 65537 до 16777216 байт .

формат s37 идёт от 16777217 байт и до ...... (просто гигантские размеры файлов должны быть) трудно представить где такие могут быть...
Зато стало ясно окончательно, почему так популярны s1, s2 (самые ходовые получаются ) особенно s2. И такой редкий s37.

Последний раз редактировалось sergey.serg-72; 27.03.2021 в 18:46.
sergey.serg-72 вне форума Ответить с цитированием
Старый 27.03.2021, 22:54   #107
BDA
МегаМодератор
СуперМодератор
 
Аватар для BDA
 
Регистрация: 09.11.2010
Сообщений: 6,119
По умолчанию

Цитата:
Сообщение от sergey.serg-72
Так что и это не гарантия.
Это гарантия от случайной порчи, а не целенаправленных изменений.
Цитата:
Сообщение от sergey.serg-72
спросит почему s37 ?, такой редкий и не популярный , выбрал ?
Всё зависит от задания. Если нужно просто реализовать Bin -> Srec, то s37 вполне удовлетворяет. Но если есть какие-то еще критерии: нужен распространенный формат, или чтобы принимался определенными программами (программаторами, конвертерами), или обосновать выбор типов записей - то это другое дело.
Цитата:
Сообщение от sergey.serg-72
Просто привычней : if fbin.Size > .....? then
Я был не совсем прав. Так можно проверять размер файла, если перейти на использование TFileStream вместо TMemoryStream. С такими исправлениями программа спокойно преобразовала avi файл 1,39 ГБ (1 502 787 584 байт) в hex файл 3,93 ГБ (4 226 979 920 байт) за 1320 секунд (22 минуты). Notepad++ даже отказался открывать получившийся hex - слишком большой размер. Содержимое не проверил на правильность, но размер похож на верный. Скорость преобразования уперлась, на мой взгляд, в процессор - одно ядро было занято на 100%, а запись была всего лишь 3 мегабайта в секунду.
Цитата:
Сообщение от sergey.serg-72
с каким максимальным размером файла, работает определённый тип записи.
Не совсем согласен с размерами. Эти размеры верны, если s19 используется для 16битного микроконтроллера, а s28 - для 24битного. Но, например, если сохранять в формат s19 для 24битного, то можно взять начальное смещение $F, файл размера 65772 байт и использовать записи с количеством полезных данных 252. Тогда у последней записи S1 будет адрес $FFFF, а конец файла фактически будет иметь адрес больше $FFFF. В примере мог ошибиться с точными числами. К сожалению, в описании нигде не нашел, действительно ли хвост может вылезать, или это запрещено. Для простоты можно запретить это.
Цитата:
Сообщение от sergey.serg-72
просто гигантские размеры файлов должны быть
Необязательно файл должен быть большим. Размер может быть маленьким, но адреса, куда отображена флеш-память, большие.
Пишите язык программирования - это форум программистов, а не экстрасенсов. (<= это подпись )
BDA на форуме Ответить с цитированием
Старый 28.03.2021, 01:54   #108
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

Цитата:
Сообщение от BDA Посмотреть сообщение
Это гарантия от случайной порчи, а не целенаправленных изменений.
Бывали случаи, как объяснил знающий ,с соседнего потока (я в этом 0) что данные искажались так, что совпадала контролка, например байты переворачивались в процессе записи...
Как он объяснил что 100% гарантии нет , но побайтное сравнение с буфером , либо в процессе записи, либо после , самый верный способ. На этом все современные прогеры стоят сейчас.

Цитата:
Сообщение от BDA Посмотреть сообщение
Необязательно файл должен быть большим. Размер может быть маленьким, но адреса, куда отображена флеш-память, большие.
Вот этого не знал, я с микроконтроллерами пока на Вы, только вот в процессе этого srec стал сталкиваться, говорят это целая наука.

Цитата:
Сообщение от BDA Посмотреть сообщение
Не совсем согласен с размерами. Эти размеры верны, если s19 используется для 16битного микроконтроллера, а s28 - для 24битного. Но, например, если сохранять в формат s19 для 24битного, то можно взять начальное смещение $F, файл размера 65772 байт и использовать записи с количеством полезных данных 252. Тогда у последней записи S1 будет адрес $FFFF, а конец файла фактически будет иметь адрес больше $FFFF. В примере мог ошибиться с точными числами. К сожалению, в описании нигде не нашел, действительно ли хвост может вылезать, или это запрещено. Для простоты можно запретить это.
Вполне может быть, а почему бы и нет ? В описании нет действительно некоторых, важных моментов.Я его уже перечитал раз 50, в разных вариантах. А пересчитывать по байтно пришлось, чтоб понять на каком размере переключается на другую запись.
Зато теперь знаем то, чего нет в википедии.

Цитата:
Сообщение от BDA Посмотреть сообщение
Я был не совсем прав. Так можно проверять размер файла, если перейти на использование TFileStream вместо TMemoryStream. С такими исправлениями программа спокойно преобразовала avi файл 1,39 ГБ (1 502 787 584 байт) в hex файл 3,93 ГБ (4 226 979 920 байт) за 1320 секунд (22 минуты). Notepad++ даже отказался открывать получившийся hex - слишком большой размер. Содержимое не проверил на правильность, но размер похож на верный. Скорость преобразования уперлась, на мой взгляд, в процессор - одно ядро было занято на 100%, а запись была всего лишь 3 мегабайта в секунду.
Можно исправить на так :

fbin: TFileStream;
ftxt: TMemoryStream;

fbin := tfilestream.Create(dlgOpen1 .FileName,fmopenReadWrite or fmShareDenyNone);
ftxt := TMemoryStream.Create;
if fbin.Size + offset > High(LongWord) then....

А можно наверное просто , ни чего не менять, а просто ещё одну переменную добавить, чисто для проверки на размер , так можно ?

var
f: TFileStream;
fbin: TMemoryStream;
ftxt: TMemoryStream;


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

Цитата:
Сообщение от BDA Посмотреть сообщение
Всё зависит от задания. Если нужно просто реализовать Bin -> Srec, то s37 вполне удовлетворяет. Но если есть какие-то еще критерии: нужен распространенный формат, или чтобы принимался определенными программами (программаторами, конвертерами), или обосновать выбор типов записей - то это другое дело.
Нет, критериев к счастью он не задавал просто srec .
Это я , в процессе изучения этого srec по разным ресурсам, к такому выводу пришёл.
Вот и подумал , для чего s37 конкретно идёт? , а так и не нашёл ни чего.
Но я с Вами согласен , если есть возможность переделки с минимальными усилиями то надо это и реализовать. По крайней мереи это лучше, чем ничего и не зачёт совсем.
В конце, концов такой hexполучился отличный, что многие конвертеры позавидуют.
То что Джонс будет hex доволен, это к бабке не ходи...Жалко не мне выпал он.
Пусть будет s37, а с какого кода лучше переделывать , у нас варианта три набралось уже?
Может последний самый? а для проверки размера просто ещё в переменные добавить
f: TFileStream; и не заморачиваться ?

Последний раз редактировалось BDA; 30.03.2021 в 00:27.
sergey.serg-72 вне форума Ответить с цитированием
Старый 28.03.2021, 03:00   #109
BDA
МегаМодератор
СуперМодератор
 
Аватар для BDA
 
Регистрация: 09.11.2010
Сообщений: 6,119
По умолчанию

Лучше все-таки перейти на TFileStream и для ввода, и для вывода. Тогда можно обрабатывать 4гигабайтовые файлы и никак не ограничивать пользователя. А еще версия с TFileStream работает в 2 раза быстрее, чем с TMemoryStream. Текущий вариант:
Код:
const
  Limit32 = $FFFFFFFF;
  Limit24 = $FFFFFF;
  Limit16 = $FFFF;
  Limit8 = $FF;

implementation

{$R *.dfm}

procedure TForm1.BeforeConvert(Sender: TObject; barMax: Integer);
begin
  Bin2Hex.Enabled := False;
  Bin2Srec.Enabled := False;
  ConvBar.Max := barMax;
end;

procedure TForm1.AfterConvert(Sender: TObject);
begin
  Bin2Hex.Enabled := True;
  Bin2Srec.Enabled := True;
  ConvBar.Position := 0;
end;

procedure TForm1.getOffset(var offset: Int64);
begin
  if Edit1.Text = '' then
  begin
    offset := 0;
    Exit;
  end;
  offset := StrToInt64Def('$' + Edit1.text, -1);
  if offset = -1 then
    raise Exception.Create('Введен некорректный адрес, с которого производить запись в файл!');
  if offset > Limit32 then
    raise Exception.Create('Слишком большой адрес!');
end;

procedure TForm1.Bin2HexClick(Sender: TObject);
const
  BYTES_IN_LINE = 16;
var
  fbin, ftxt: TFileStream;
  s, data_s: string;
  b: TBytes;
  offset: Int64;
  i, count, high_addr, cur_high_addr: integer;
  sum: byte;
  low_addr: word;
  start_conv, end_conv: TDateTime;
begin
  fbin := nil;
  ftxt := nil;
  try
    try
      getOffset(offset);
      if not dlgOpen1.Execute then
        exit;
      fbin := TFileStream.Create(dlgOpen1.FileName, fmOpenRead or fmShareDenyWrite);
      if fbin.Size > Limit32 then
        raise Exception.Create('Слишком большой файл!');
      if fbin.Size + offset > Limit32 then
        raise Exception.Create('Слишком большой адрес конца файла!');
      dlgSave1.Filter := 'Intel HEX File (*.hex)|*.hex';
      dlgSave1.FileName := ChangeFileExt(dlgOpen1.FileName, '.hex');
      if not dlgSave1.Execute then
        exit;
      ftxt := TFileStream.Create(dlgSave1.FileName, fmCreate or fmShareDenyWrite);
      start_conv := Now;
      BeforeConvert(Sender, fbin.Size div BYTES_IN_LINE);
      SetLength(b, BYTES_IN_LINE);
      high_addr := -1;
      while fbin.Position < fbin.Size do
      begin
        ConvBar.Position := ConvBar.Position + 1;
        Application.ProcessMessages;
        low_addr := fbin.Position + offset;
        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;
        data_s := '';
        for i := 0 to count - 1 do
        begin
          data_s := data_s + IntToHex(b[i], 2);
          Inc(sum, b[i]);
        end;
        sum := -sum;
        s := Format(':%.2x%.4x00%s%.2x%s', [count, low_addr, data_s, sum, sLineBreak]);
        ftxt.Write(s[1], Length(s));
      end;
      s := ':00000001FF' + sLineBreak;
      ftxt.Write(s[1], Length(s));
      AfterConvert(Sender);
      end_conv := Now;
      s := Format('Файл успешно преобразован и записан за %d секунд(ы).', [SecondsBetween(start_conv, end_conv)]);
      Application.MessageBox(PAnsiChar(s), 'Converter', MB_Ok + MB_ICONINFORMATION);
    except
      on E : Exception do
        Application.MessageBox(PAnsiChar(E.Message), 'Converter', MB_Ok + MB_ICONERROR);
    end;
  finally
    fbin.Free;
    ftxt.Free;
  end;
end;
Но пока не проверял, что будет при "плохих" ситуациях (файл ввода или вывода кем-то захвачен в эксклюзивный доступ).
Пишите язык программирования - это форум программистов, а не экстрасенсов. (<= это подпись )

Последний раз редактировалось BDA; 28.03.2021 в 03:14.
BDA на форуме Ответить с цитированием
Старый 28.03.2021, 18:25   #110
sergey.serg-72
Форумчанин
 
Регистрация: 12.03.2019
Сообщений: 114
По умолчанию

Цитата:
Сообщение от BDA Посмотреть сообщение
procedure TForm1.Bin2HexClick(Sender: TObject);
const
BYTES_IN_LINE = 16;
var
fbin, ftxt: TFileStream;
s, data_s: string;
b: TBytes;
offset: Int64;
i, count, high_addr, cur_high_addr: integer;
sum: byte;
low_addr: word;
start_conv, end_conv: TDateTime;
begin
fbin := nil;
ftxt := nil;
try
try
getOffset(offset);
if not dlgOpen1.Execute then
exit;
fbin := TFileStream.Create(dlgOpen1.FileNam e, fmOpenRead or fmShareDenyWrite);
if fbin.Size > Limit32 then
raise Exception.Create('Слишком большой файл!');
if fbin.Size + offset > Limit32 then
raise Exception.Create('Слишком большой адрес конца файла!');
dlgSave1.Filter := 'Intel HEX File (*.hex)|*.hex';
dlgSave1.FileName := ChangeFileExt(dlgOpen1.FileName, '.hex');
if not dlgSave1.Execute then
exit;
ftxt := TFileStream.Create(dlgSave1.FileNam e, fmCreate or fmShareDenyWrite);
start_conv := Now;
BeforeConvert(Sender, fbin.Size div BYTES_IN_LINE);
SetLength(b, BYTES_IN_LINE);
high_addr := -1;
while fbin.Position < fbin.Size do
begin
ConvBar.Position := ConvBar.Position + 1;
Application.ProcessMessages;
low_addr := fbin.Position + offset;
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;
data_s := '';
for i := 0 to count - 1 do
begin
data_s := data_s + IntToHex(b[i], 2);
Inc(sum, b[i]);
end;
sum := -sum;
s := Format(':%.2x%.4x00%s%.2x%s', [count, low_addr, data_s, sum, sLineBreak]);
ftxt.Write(s[1], Length(s));
end;
s := ':00000001FF' + sLineBreak;
ftxt.Write(s[1], Length(s));
AfterConvert(Sender);
end_conv := Now;
s := Format('Файл успешно преобразован и записан за %d секунд(ы).', [SecondsBetween(start_conv, end_conv)]);
Application.MessageBox(PAnsiChar(s) , 'Converter', MB_Ok + MB_ICONINFORMATION);
except
on E : Exception do
Application.MessageBox(PAnsiChar(E. Message), 'Converter', MB_Ok + MB_ICONERROR);
end;
finally
fbin.Free;
ftxt.Free;
end;
end;
С этим всё понятно, без вопросов, код для Hex, но уже на TFileStream;
sergey.serg-72 вне форума Ответить с цитированием
Ответ
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Нужно создать "батник", вырезать из "2.txt" первых n строк и вставить их в "1.txt" temphard Помощь студентам 2 03.09.2013 15:03
Удаление первых n-строк из txt-файла Neksion Помощь студентам 2 10.07.2013 17:12
Создать чтение из файла и запись в файл txt на С++ skifre Фриланс 0 01.06.2012 15:16
поиск и выципление строк из txt файла D_e_n_n Помощь студентам 7 04.02.2011 05:39
C# Представление txt файла как массива строк asheb Помощь студентам 7 20.04.2010 11:51



Проекты отопления, пеллетные котлы, бойлеры, радиаторы
интернет магазин respective.ru
Пеллетный котёл Emtas
котлы EMTAS