Добрый день господа инженеры.
Мне тут задали задачу сделать загрузчик для микросхемы ACEX 1K на микропроцессоре ATMega128.
В принципе ничего сложного, я прочел рекомендайии ALTER-ы по этому поводу и решил делать так.
Хранить прошивку ACEX-a (он ~20К) в памяти программ Меги ( 128К).
Поточнее так в меге создаю массив размера 20К туда записываю данные из файла .RBF(прошивки ACEX), потом по SPI отправляю в ACEX при включении питания.
Я прочел что .RBF файлы хранят 8-ми битные данные и посчитал, что это как раз то что надо , потому что у МЕГИ 8-и битный регистр SPI.
Прошу ответить мне уважаемые специалисты в .RBF файлах храняться только биты которые надо передать в ПЛИС или еще какието разделители, знаки форматирования?????
И еще прошу покритиковать тот способ которым я хочу восспользоваться и мои методы, ну и подсказать кое что из своего опыта.
Всем заранее большое спасибо.
Полная версия этой страницы: Какую структру имеют файлы прошивки формата .RBF?
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
В rbf битовый поток. Никаких разделителей там нет. Про порядок битов почитайте в даташите. Для загрузки читайте PS конфигурацию и воспроизводите вайвформу. Не факт что у вас получится это сделать через SPI.
Структра у RBF все же есть, что-то типа :
sync start -> заголовок -> блок1 -> ... блокX -> sync stop
в конце кажного блока расположена некая контрольная инфа, которая проверяется заливаемым чипом. заливка по SPI работает, на форуме пробегало
sync start -> заголовок -> блок1 -> ... блокX -> sync stop
в конце кажного блока расположена некая контрольная инфа, которая проверяется заливаемым чипом. заливка по SPI работает, на форуме пробегало
Может, чисто формально, и есть какая-то сруктура, но для загузчика - все едино: надо просто загрузить весь файл в ПЛИС. По поводу порядка следования бит лучше почитать datasheet. Я делал такое на AT89S51 + 29Fxxx через UART в режиме shift register. Да, после загрузки всего файла надо выдать не менее 10 холостых импульсов DCLK для приведения ПЛИС в рабочее состояние. И при создании файла выбрать "rbf (sequental) ". Через SPI тоже должно работать.
Несколько лет назад делал подобную вещь - грузил в ACEX rbf файл с помощью ATiny28. Брал байт по I2C из внешней флешки и потом кидал этот байт ( правда не по SPI, сам изображал сигналы на выводах порта ) в ACEX и так много раз. НА SPI получится обязательно. Перерывы в подаче данных на ACEX делать можно, если клоки стопорить между посылками. Но datasheets читать внимательно - есть дополнительные сигналы взаимодействия. А дополнительные тактовые импульсы после загрузки можно выдавать с запасом - лишние не воспринимаютя ( это надо проверить - давно было, могу напутать ). И настройки проекта для микросхемы влияют, например сигнал INIT DONE может использоваться или нет.
Спосибо за ответы.
В понедельник пойдуопробую все варианты.
Главне что я узнал, ято весь .rbf файл надо залить в Плис и никаких разделтелей и заголовков там нет.
В понедельник пойдуопробую все варианты.
Главне что я узнал, ято весь .rbf файл надо залить в Плис и никаких разделтелей и заголовков там нет.
делал загрузчики для 1-ых циклонов и стратиксов. Временные диаграммы формировал сам, из rbf-файла брал только данные. Если нужно, могу поискать C++ функции...
Все получилось отлично.
Сделал прошивку для процессора. Написал программу на VC++6.0 которая брала данные из .rbf файла прошивки ACEX добавляла к прошивке АТМеги. А в АТМеге программа загрузчик которая эти данные сливает в ПЛИС используя свой SPI. Все работает как часы.
Правда былы некоторые трудности с тем что при подаче питания на ПЛИС надо подождать ~10 мкс (время работы аппаратного сброса по вкл. питания [POR] ПЛИСки), а только потом ее загружать.
Этой инфы там где основные тайминги процесса загрузки ПЛИСа нет
тка что пришлось голову по ломать что бы понять что же не так.
Так что все тема закрыта все большое спасибо.
Сделал прошивку для процессора. Написал программу на VC++6.0 которая брала данные из .rbf файла прошивки ACEX добавляла к прошивке АТМеги. А в АТМеге программа загрузчик которая эти данные сливает в ПЛИС используя свой SPI. Все работает как часы.
Правда былы некоторые трудности с тем что при подаче питания на ПЛИС надо подождать ~10 мкс (время работы аппаратного сброса по вкл. питания [POR] ПЛИСки), а только потом ее загружать.
Этой инфы там где основные тайминги процесса загрузки ПЛИСа нет
тка что пришлось голову по ломать что бы понять что же не так.
Так что все тема закрыта все большое спасибо.
Цитата(Илья_ @ Jun 3 2008, 15:44) 
Написал программу на VC++6.0 которая брала данные из .rbf файла прошивки ACEX добавляла к прошивке АТМеги.
Типа мы не ищем легких путей? А линкер на что? Или просто прямо HEX файлы c прошивкой и RBF склеить.
Цитата(Илья_ @ Jun 3 2008, 16:44)
Написал программу на VC++6.0 которая брала данные из .rbf файла прошивки ACEX добавляла к прошивке АТМеги.
Можно проще. Файл прошивки можно указать прямо в исходнике в качестве инициализатора массива, если использовать формат ttf:
Код
const __hugeflash char FPGA_Config[]={
#include "..\Altera\MyProj.ttf"
};
;SPI Init:
SPCR = (1<<SPE) | (1<<DORD) | (1<<MSTR); //SPI enable, LSB first, master
SPSR = (1<<SPI2X); //double SPI speed
bool FPGA_Configurate(void)
{
Port_nCONFIG_0; //nCONFIG <- 0
Delay_us(100); //delay 100 uS
if(Pin_nSTATUS) return(0);
Port_nCONFIG_1; //nCONFIG <- 1
Delay_us(100); //delay 100 uS
if(!Pin_nSTATUS) return(0);
for(long i = 0; i < sizeof(FPGA_Config); i++)
{
Spi(FPGA_Config[i]);
if(!Pin_nSTATUS) return(0);
if(Pin_CONF_DONE) break;
}
if(!Pin_CONF_DONE) return(0);
Delay_us(100); //delay 100 uS
Port_nCLR_1; //release nCLR
return(1);
}
char Spi(char dat)
{
SPDR = dat;
while(!(SPSR & (1 << SPIF)));
return(SPDR);
}
#include "..\Altera\MyProj.ttf"
};
;SPI Init:
SPCR = (1<<SPE) | (1<<DORD) | (1<<MSTR); //SPI enable, LSB first, master
SPSR = (1<<SPI2X); //double SPI speed
bool FPGA_Configurate(void)
{
Port_nCONFIG_0; //nCONFIG <- 0
Delay_us(100); //delay 100 uS
if(Pin_nSTATUS) return(0);
Port_nCONFIG_1; //nCONFIG <- 1
Delay_us(100); //delay 100 uS
if(!Pin_nSTATUS) return(0);
for(long i = 0; i < sizeof(FPGA_Config); i++)
{
Spi(FPGA_Config[i]);
if(!Pin_nSTATUS) return(0);
if(Pin_CONF_DONE) break;
}
if(!Pin_CONF_DONE) return(0);
Delay_us(100); //delay 100 uS
Port_nCLR_1; //release nCLR
return(1);
}
char Spi(char dat)
{
SPDR = dat;
while(!(SPSR & (1 << SPIF)));
return(SPDR);
}
Подскажите, пожалуйста, а можно ли каким-нибудь образом разбить файл .rbf на несколько частей меньшего объема, причем чтобы в коде программы контроллера ссылаться на ttf ? (то есть чтобы несколько раз ссылаться на ttf, который будет содержать в себе поочередно тот или иной кусок дробленного .rbf)
Моя проблема в том, что надо конфигурировать EP1K50 (Acex 1K), файлы .rbf проекта весят 98кбайт, а пытаюсь конфигурировать Атмегой 32.... Хочу попробовать разбить rbf и по кусочкам заливать его в микросхему памяти (at45db). А потом из памяти уже в ПЛИС.
Моя проблема в том, что надо конфигурировать EP1K50 (Acex 1K), файлы .rbf проекта весят 98кбайт, а пытаюсь конфигурировать Атмегой 32.... Хочу попробовать разбить rbf и по кусочкам заливать его в микросхему памяти (at45db). А потом из памяти уже в ПЛИС.
Цитата(Sonya @ Apr 14 2011, 15:36)
Моя проблема в том, что надо конфигурировать EP1K50 (Acex 1K), файлы .rbf проекта весят 98кбайт, а пытаюсь конфигурировать Атмегой 32.... Хочу попробовать разбить rbf и по кусочкам заливать его в микросхему памяти (at45db). А потом из памяти уже в ПЛИС.
Просто порезать на куски любого удобного размера. А откуда Вы его будете брать "по кусочкам"? Кто будет программировать ПЗУ?
В том и состоит суть вопроса, как порезать rbf так, чтобы получить файлы ttf, указывающие на куски rbf, дабы использовать эти куски в прошивке атмеги как писал Леонид Иванович:
const __hugeflash char FPGA_Config[]={
#include "..\Altera\MyProj.ttf"
};
Другими словами я хочу несколько раз перепрошить атмегу, прописывая ttf, указывающие на разные куски rbf, и выставляя в каждой новой прошивке атмеги новые адреса для записи в датафлэш at45db (чтобы уместить 98килобайтный rbf в датафлэш)
Можно ли так сделать вообще? Если нет, то какие пути решения этой проблемы есть? (кроме того, чтобы взять микроконтроллер с большим объемом внутр. флэш).
О каком ПЗУ идет речь? Флэш атмеги программирую AVRISP, dataflash at45db программирует атмега, ПЛИС не имеет ПЗУ
Но ее программировать будут по SPI at45db напару с атмегой.
const __hugeflash char FPGA_Config[]={
#include "..\Altera\MyProj.ttf"
};
Другими словами я хочу несколько раз перепрошить атмегу, прописывая ttf, указывающие на разные куски rbf, и выставляя в каждой новой прошивке атмеги новые адреса для записи в датафлэш at45db (чтобы уместить 98килобайтный rbf в датафлэш)
Можно ли так сделать вообще? Если нет, то какие пути решения этой проблемы есть? (кроме того, чтобы взять микроконтроллер с большим объемом внутр. флэш).
О каком ПЗУ идет речь? Флэш атмеги программирую AVRISP, dataflash at45db программирует атмега, ПЛИС не имеет ПЗУ
Но ее программировать будут по SPI at45db напару с атмегой.
Цитата(Sonya @ Apr 15 2011, 08:46)
Другими словами я хочу несколько раз перепрошить атмегу, прописывая ttf, указывающие на разные куски rbf, и выставляя в каждой новой прошивке атмеги новые адреса для записи в датафлэш at45db (чтобы уместить 98килобайтный rbf в датафлэш)
Можно ли так сделать вообще?
Можно ли так сделать вообще?
А по RS-232 передавать весь файл целиком почему не хотите?
Я так и делал. Передавал пачками, ждал подтверждения, после записи страницы в ПЗУ передавал следующую страницу и т.д.
Теперь имею достаточное количество ОЗУ, передаю весь файл целиком, еще раз передаю для верификации, потом записываю целиком, потом проверяю, что записано правильно.
А rbf - это просто сырые байты, байт за байтом, которые нужно заслать в ПЛИС. Любым редактором, работающим с двоичными данными, можно порезать на части. Например, WinHex, наверное.
ttf и rbf - близнецы. Просто один в двоичном виде, другой в текстовом. Копируйте из текстового редактора ttf кусками, вставляйте в исходник для atmega и редактируйте длину и начальный адрес записи этого блока.
Но это странно. Действительно, как говорит ViKo - лучше написать программу, которая принимает данные по RS-232 и программирует at45db.
Но это странно. Действительно, как говорит ViKo - лучше написать программу, которая принимает данные по RS-232 и программирует at45db.
Спасибо! Я и не знала, что есть редакторы, работающие с двоичными данными. Скачала WinHEx, буду изучать, чего он умеет.
Дело в том, что в будущем (надеюсь ближайшем) атмега будет получать данные из CAN-сети, поэтому не хочу сейчас заморачиваться с другими интерфейсами. В данный момент хотелось бы просто проверить будет ли альтера прошиваться или нет. Вот. Буду пытаться резать ttf
Дело в том, что в будущем (надеюсь ближайшем) атмега будет получать данные из CAN-сети, поэтому не хочу сейчас заморачиваться с другими интерфейсами. В данный момент хотелось бы просто проверить будет ли альтера прошиваться или нет. Вот. Буду пытаться резать ttf
Цитата(Sonya @ Apr 15 2011, 14:59)
Спасибо! Я и не знала, что есть редакторы, работающие с двоичными данными. Скачала WinHEx, буду изучать, чего он умеет.
Это, конечно, полезно
. Но я имел в виду другое. Как обойтись без редактора, умеющего работать с двоичными данными.Вот кусок .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'ом Если ниче больше в голову не придет
Копирует из 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'ом
Если ниче больше в голову не придет
Цитата(Sonya @ Apr 15 2011, 15:58)
unsigned char data[625] = {
0xFF, 0xFF, 0x62, 0xFF, 0x3C, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
}
Вещь! Но я, дабы не загромождать код программы, хотела бы конечно делать: #include...
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?
Я и хочу включить файл с помощью include, но так прокатит подключить только ttf, на rbf-файл компилятор жалуется. Только оба эти файла слишком здоровые для памяти моей атмеги, поэтому и возникла проблема их раздробить на более мелкие (и поочередно писать в dataflash контроллером). WinHex помог
Цитата(Sonya @ Apr 15 2011, 18:48)
Я и хочу включить файл с помощью include, но так прокатит подключить только ttf, на rbf-файл компилятор жалуется.
Ничего не понимаю! На это -
Код
unsigned char data[625] = {
0xFF, 0xFF, 0x62, 0xFF, 0x3C, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
}
0xFF, 0xFF, 0x62, 0xFF, 0x3C, 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
}
- жалуется? Или все же - "вещь!"?
Да и с чего бы компилятору жаловаться на массив?
Вы предлагали rbf-файл подключить с помощью include, а не массивом. На массив естественно компилятор не жалуется, просто, имхо, массив размером 30кб в коде программе выглядит не эстетично. Поэтому и хочу задействовать ttf-файл, разбить его и подключать с помощью include.
Цитата(Sonya @ Apr 17 2011, 13:36)
Вы предлагали rbf-файл подключить с помощью include, а не массивом. На массив естественно компилятор не жалуется, просто, имхо, массив размером 30кб в коде программе выглядит не эстетично. Поэтому и хочу задействовать ttf-файл, разбить его и подключать с помощью include.
Я предлагал rbf-файл подключить с помощью include в виде массива, полученного с помощью WinHex. В отдельном файле массив на 30kB выглядит вполне прилично. Точнее, совсем не "выглядит", не путается под мышкой (каламбурчик).
Именно так я поступил с файлом шрифта на 50kB, например.
А, до меня дошло :D Если в отдельном файле сделать массив с помощью WinHex, то да, всё хорошо будет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.