|
2 страниц
1 2 >
|
 |
Ответов
(1 - 23)
|
May 31 2008, 14:30
|
Участник

Группа: Новичок
Сообщений: 30
Регистрация: 15-05-06
Пользователь №: 17 123

|
Может, чисто формально, и есть какая-то сруктура, но для загузчика - все едино: надо просто загрузить весь файл в ПЛИС. По поводу порядка следования бит лучше почитать datasheet. Я делал такое на AT89S51 + 29Fxxx через UART в режиме shift register. Да, после загрузки всего файла надо выдать не менее 10 холостых импульсов DCLK для приведения ПЛИС в рабочее состояние. И при создании файла выбрать "rbf (sequental) ". Через SPI тоже должно работать.
|
|
|
|
|
Jun 1 2008, 05:24
|
Участник

Группа: Участник
Сообщений: 39
Регистрация: 18-10-07
Пользователь №: 31 472

|
Спосибо за ответы. В понедельник пойдуопробую все варианты.
Главне что я узнал, ято весь .rbf файл надо залить в Плис и никаких разделтелей и заголовков там нет.
|
|
|
|
|
Jun 3 2008, 13:44
|
Участник

Группа: Участник
Сообщений: 39
Регистрация: 18-10-07
Пользователь №: 31 472

|
Все получилось отлично. Сделал прошивку для процессора. Написал программу на VC++6.0 которая брала данные из .rbf файла прошивки ACEX добавляла к прошивке АТМеги. А в АТМеге программа загрузчик которая эти данные сливает в ПЛИС используя свой SPI. Все работает как часы.
Правда былы некоторые трудности с тем что при подаче питания на ПЛИС надо подождать ~10 мкс (время работы аппаратного сброса по вкл. питания [POR] ПЛИСки), а только потом ее загружать. Этой инфы там где основные тайминги процесса загрузки ПЛИСа нет тка что пришлось голову по ломать что бы понять что же не так.
Так что все тема закрыта все большое спасибо.
|
|
|
|
|
Jun 13 2008, 06:50
|

Местный
  
Группа: Участник
Сообщений: 318
Регистрация: 21-07-06
Из: Минск
Пользователь №: 18 986

|
Цитата(Илья_ @ 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); }
--------------------
|
|
|
|
|
Apr 14 2011, 11:36
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 10-02-11
Пользователь №: 62 860

|
Подскажите, пожалуйста, а можно ли каким-нибудь образом разбить файл .rbf на несколько частей меньшего объема, причем чтобы в коде программы контроллера ссылаться на ttf ? (то есть чтобы несколько раз ссылаться на ttf, который будет содержать в себе поочередно тот или иной кусок дробленного .rbf)
Моя проблема в том, что надо конфигурировать EP1K50 (Acex 1K), файлы .rbf проекта весят 98кбайт, а пытаюсь конфигурировать Атмегой 32.... Хочу попробовать разбить rbf и по кусочкам заливать его в микросхему памяти (at45db). А потом из памяти уже в ПЛИС.
Сообщение отредактировал Sonya - Apr 14 2011, 11:41
|
|
|
|
|
Apr 14 2011, 18:14
|
Местный
  
Группа: Свой
Сообщений: 351
Регистрация: 17-09-05
Из: Москва
Пользователь №: 8 660

|
Цитата(Sonya @ Apr 14 2011, 15:36)  Моя проблема в том, что надо конфигурировать EP1K50 (Acex 1K), файлы .rbf проекта весят 98кбайт, а пытаюсь конфигурировать Атмегой 32.... Хочу попробовать разбить rbf и по кусочкам заливать его в микросхему памяти (at45db). А потом из памяти уже в ПЛИС. Просто порезать на куски любого удобного размера. А откуда Вы его будете брать "по кусочкам"? Кто будет программировать ПЗУ?
|
|
|
|
|
Apr 15 2011, 05:46
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 10-02-11
Пользователь №: 62 860

|
В том и состоит суть вопроса, как порезать rbf так, чтобы получить файлы ttf, указывающие на куски rbf, дабы использовать эти куски в прошивке атмеги как писал Леонид Иванович: const __hugeflash char FPGA_Config[]={ #include "..\Altera\MyProj.ttf" }; Другими словами я хочу несколько раз перепрошить атмегу, прописывая ttf, указывающие на разные куски rbf, и выставляя в каждой новой прошивке атмеги новые адреса для записи в датафлэш at45db (чтобы уместить 98килобайтный rbf в датафлэш) Можно ли так сделать вообще? Если нет, то какие пути решения этой проблемы есть? (кроме того, чтобы взять микроконтроллер с большим объемом внутр. флэш). О каком ПЗУ идет речь? Флэш атмеги программирую AVRISP, dataflash at45db программирует атмега, ПЛИС не имеет ПЗУ  Но ее программировать будут по SPI at45db напару с атмегой.
|
|
|
|
|
Apr 15 2011, 09:24
|

Универсальный солдатик
     
Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362

|
Цитата(Sonya @ Apr 15 2011, 08:46)  Другими словами я хочу несколько раз перепрошить атмегу, прописывая ttf, указывающие на разные куски rbf, и выставляя в каждой новой прошивке атмеги новые адреса для записи в датафлэш at45db (чтобы уместить 98килобайтный rbf в датафлэш) Можно ли так сделать вообще? А по RS-232 передавать весь файл целиком почему не хотите? Я так и делал. Передавал пачками, ждал подтверждения, после записи страницы в ПЗУ передавал следующую страницу и т.д. Теперь имею достаточное количество ОЗУ, передаю весь файл целиком, еще раз передаю для верификации, потом записываю целиком, потом проверяю, что записано правильно. А rbf - это просто сырые байты, байт за байтом, которые нужно заслать в ПЛИС. Любым редактором, работающим с двоичными данными, можно порезать на части. Например, WinHex, наверное.
|
|
|
|
|
Apr 15 2011, 10:59
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 10-02-11
Пользователь №: 62 860

|
Спасибо! Я и не знала, что есть редакторы, работающие с двоичными данными. Скачала WinHEx, буду изучать, чего он умеет. Дело в том, что в будущем (надеюсь ближайшем) атмега будет получать данные из CAN-сети, поэтому не хочу сейчас заморачиваться с другими интерфейсами. В данный момент хотелось бы просто проверить будет ли альтера прошиваться или нет. Вот. Буду пытаться резать ttf
|
|
|
|
|
Apr 15 2011, 11:46
|
Местный
  
Группа: Свой
Сообщений: 351
Регистрация: 17-09-05
Из: Москва
Пользователь №: 8 660

|
Цитата(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. Вам нужно второе.
|
|
|
|
|
Apr 15 2011, 12:58
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 10-02-11
Пользователь №: 62 860

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

Универсальный солдатик
     
Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362

|
Цитата(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... Так сделайте отдельный файл из вашего data[625] и включите с помощью #include в свой файл программы. Посмотрел ttf. Там каждый байт данных представлен в виде трех десятичных цифр и запятой - вот вам и 4 байта вместо одного. И еще встречаются переводы строки 0D 0A - это прибавка к размеру. На что вам сдался этот ttf?
|
|
|
|
|
Apr 16 2011, 10:59
|

Универсальный солдатик
     
Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362

|
Цитата(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, } - жалуется? Или все же - "вещь!"? Да и с чего бы компилятору жаловаться на массив?
|
|
|
|
|
Apr 17 2011, 10:36
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 10-02-11
Пользователь №: 62 860

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

Универсальный солдатик
     
Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362

|
Цитата(Sonya @ Apr 17 2011, 13:36)  Вы предлагали rbf-файл подключить с помощью include, а не массивом. На массив естественно компилятор не жалуется, просто, имхо, массив размером 30кб в коде программе выглядит не эстетично. Поэтому и хочу задействовать ttf-файл, разбить его и подключать с помощью include. Я предлагал rbf-файл подключить с помощью include в виде массива, полученного с помощью WinHex. В отдельном файле массив на 30kB выглядит вполне прилично. Точнее, совсем не "выглядит", не путается под мышкой (каламбурчик).  Именно так я поступил с файлом шрифта на 50kB, например.
|
|
|
|
|
Apr 18 2011, 09:14
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 10-02-11
Пользователь №: 62 860

|
А, до меня дошло :D Если в отдельном файле сделать массив с помощью WinHex, то да, всё хорошо будет.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|