[Sonya 0]

Спасибо! Я и не знала, что есть редакторы, работающие с двоичными данными. Скачала WinHEx, буду изучать, чего он умеет.

Дело в том, что в будущем (надеюсь ближайшем) атмега будет получать данные из CAN-сети, поэтому не хочу сейчас заморачиваться с другими интерфейсами. В данный момент хотелось бы просто проверить будет ли альтера прошиваться или нет. Вот. Буду пытаться резать ttf :)

[SergeyF 0]

Спасибо! Я и не знала, что есть редакторы, работающие с двоичными данными. Скачала WinHEx, буду изучать, чего он умеет.

Это, конечно, полезно :). Но я имел в виду другое. Как обойтись без редактора, умеющего работать с двоичными данными.

Вот кусок .rbf: FF FF 62 FF 36 00 FF (то, что записано в файле в двоичном виде по байтам)

Вот кусок .ttf: 255,255, 98,255, 54, 0,255, (текст)

Но данные одни и те же. Просто из .rbf легко получить .hex или .bin для программирования. А из ttf проще копировать данные для инициализации массивов в C. Вам нужно второе.

[Sonya 0]

Ага, только у меня ttf весит 394639 байт, а rbf 98023 байта. В WinHex есть такая функция "C source" - класс :) Копирует из rbf не только данные в том виде, который нужен, но и код добавляет, сразу получается:

unsigned char data[625] = {

0xFF, 0xFF, 0x62, 0xFF, 0x3C, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,

}

Вещь! Но я, дабы не загромождать код программы, хотела бы конечно делать: #include и ttf-файл. Правда не совсем пока понимаю, как сопоставить ttf и rbf если пытаться дробить ttf... Получается что байт данных в rbf равнозначен примерно 4 байтам в текстовом представлении. Но об чем говорят еще 2547 байт ttf-файла непонятно (394639-98023*4=2547)....

В принципе может и так вставлю массив из rbf C-source'ом :) Если ниче больше в голову не придет

[ViKo 1]

unsigned char data[625] = {

0xFF, 0xFF, 0x62, 0xFF, 0x3C, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,

}

Вещь! Но я, дабы не загромождать код программы, хотела бы конечно делать: #include...

Так сделайте отдельный файл из вашего data[625] и включите с помощью #include в свой файл программы.

Посмотрел ttf. Там каждый байт данных представлен в виде трех десятичных цифр и запятой - вот вам и 4 байта вместо одного.

И еще встречаются переводы строки 0D 0A - это прибавка к размеру.

На что вам сдался этот ttf?

[Sonya 0]

Я и хочу включить файл с помощью include, но так прокатит подключить только ttf, на rbf-файл компилятор жалуется. Только оба эти файла слишком здоровые для памяти моей атмеги, поэтому и возникла проблема их раздробить на более мелкие (и поочередно писать в dataflash контроллером). WinHex помог :)

[ViKo 1]

Я и хочу включить файл с помощью include, но так прокатит подключить только ttf, на rbf-файл компилятор жалуется.

Ничего не понимаю! На это -

unsigned char data[625] = {
0xFF, 0xFF, 0x62, 0xFF, 0x3C, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 
}

- жалуется? Или все же - "вещь!"?

Да и с чего бы компилятору жаловаться на массив?

[Sonya 0]

Вы предлагали rbf-файл подключить с помощью include, а не массивом. На массив естественно компилятор не жалуется, просто, имхо, массив размером 30кб в коде программе выглядит не эстетично. Поэтому и хочу задействовать ttf-файл, разбить его и подключать с помощью include.

[ViKo 1]

Вы предлагали rbf-файл подключить с помощью include, а не массивом. На массив естественно компилятор не жалуется, просто, имхо, массив размером 30кб в коде программе выглядит не эстетично. Поэтому и хочу задействовать ttf-файл, разбить его и подключать с помощью include.

Я предлагал rbf-файл подключить с помощью include в виде массива, полученного с помощью WinHex. В отдельном файле массив на 30kB выглядит вполне прилично. Точнее, совсем не "выглядит", не путается под мышкой (каламбурчик). :)

Именно так я поступил с файлом шрифта на 50kB, например.

[Sonya 0]

А, до меня дошло :D Если в отдельном файле сделать массив с помощью WinHex, то да, всё хорошо будет.