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

Это, конечно, полезно . Но я имел в виду другое. Как обойтись без редактора, умеющего работать с двоичными данными.
Вот кусок .rbf: FF FF 62 FF 36 00 FF (то, что записано в файле в двоичном виде по байтам)
Вот кусок .ttf: 255,255, 98,255, 54, 0,255, (текст)
Но данные одни и те же. Просто из .rbf легко получить .hex или .bin для программирования. А из ttf проще копировать данные для инициализации массивов в C. Вам нужно второе.

Ага, только у меня 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'ом Если ниче больше в голову не придет

Так сделайте отдельный файл из вашего data[625] и включите с помощью #include в свой файл программы.
Посмотрел ttf. Там каждый байт данных представлен в виде трех десятичных цифр и запятой - вот вам и 4 байта вместо одного.
И еще встречаются переводы строки 0D 0A - это прибавка к размеру.
На что вам сдался этот ttf?

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

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

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

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

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

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