[torik 0]

Вот какие дела: быть плата простенькая отладочная Циклон2стартеркит... Создал простенький проект, который изображение из флеша выводит на экран монитора, при этом ЦАП всего 4 бита на цвет. VGA RGB короче. Изображение загружаю с компьютера, предварительно сохраняя в формате BMP "X1 R4 G4 B4".

Проблема - при выводе на экран монитора искажаются цвета довольно заметно. В файле нет bitmap-а...

 

Подскажите, пожалуйста, когда я при сохранении в фотошопе выбираю

BMP "X4 R4 G4 B4', "R5 G6 B5", "X1, R5, G5, B5", то это простой RGB или все-таки цветоразностный?

 

Если цветоразностный, то надо преобразовать его в RGB. Планирую просто таблицей перекодировки (карта цветов) - тогда как для нее расчитать значения правильно?

 

Простите, что немного оффтоп

 

Собственно, что обсуждалось на форуме:

 

http://www.xilinx.com/bvdocs/appnotes/xapp283.pdf

ftp://ftp.xilinx.com/pub/applications/xapp/xapp283.zip

 

это методы перекодировки, в том числе таблицей.

 

Итого, остаются вопросы:

- какой же там формат

- чем состряпать такую таблицу чтоб не писать руками.

[Flood 13]

Это все простые RGB форматы. Цветоразностные обычно имеют в названии буквы Y и U.

Корректный 16 битный цвет - это только RGB565.

RGB555 - 15-и битный. Старший бит не используется.

Цифры после букв указывают количество бит на цвет в "упакованном" 16-битном слове.

 

Чтобы использовать непакованный BMP в качестве чистого битмапа (RAW), от него нужно отрезать заголовок. Сколько именно байт - как раз в заголовке и указано. Также там есть вся информация о формате - размеры, упаковка (индексный, прямой цвет или компрессия), и тд. Формат заголовка смотреть в MSDN или Windows SDK Help.

[torik 0]

формат файла я знаю. заголовок просто убираю.

Почему цвета искажаются не понимаю, потому и подумал на цветоразностные.

[rv3dll 0]

формат файла я знаю. заголовок просто убираю.

Почему цвета искажаются не понимаю, потому и подумал на цветоразностные.

 

ты на цап на этот смотрел??? посмотри на схему и всё встанет на свои места.

там даже не R-2R

[torik 0]

Мдя, действительно. Ну ничего, потом попробую на TFT панели, когда она придет...

 

Там другую проблему надо решать нафиг, откуда-то данные выскакивают левые, словно память SDRAM неустойчиво читается.

 

Как-то можно покрутить фазовый сдвиг PLL не перекомпилируя весь проект в Quartus-е?

[torik 0]

И все-таки подскажите, как мне оперативно поменять фазу одного из выходов PLL не перекомпилируя проект в квартусе?

Это необходимо, чтобы настроить сдвиг фазы для SDRAM

[rv3dll 0]

И все-таки подскажите, как мне оперативно поменять фазу одного из выходов PLL не перекомпилируя проект в квартусе?

Это необходимо, чтобы настроить сдвиг фазы для SDRAM

 

врят-ли

 

а какой контроллер памяти для видео используете?

[torik 0]

Использую стандартный альтеровский контроллер SDRAM, в SOPC Builder. PLL фазу покрутил тупо перекомпиляцией несколько значений и сделал вывод, что она у меня была выбрана правильно.

При неправильно выбранной фазе данные из памяти вообще не читаются (да и не грузятся процессором), а у меня другой глюк - пропадание данных случайным образом раз в секунду, две.

Тогда, пытаясь добиться каких либо изменений, поменял рассчет адреса чтения.

 

Было:

assign    address_0 = (SW[8] == 1'b0) ? address_0_w : address_0_r;                                

always    @(posedge CLOCK_50_f) address_0_r = (VGA_VS == 1'b1) ?
        (((read_n == 1'b0)&&(waitrequest == 1'b0)) ? address_0_r + 2'd2 : address_0_r + 2'd0) : 24'h000000;

 

Стало:

assign    address_0 = (SW[8] == 1'b0) ? address_0_w : address_0_r;                                

always    @(posedge CLOCK_50_f) address_0_r = (VGA_VS == 1'b1) ?
        (((read_n == 1'b0)&&(waitrequest == 1'b0)) ? address_0_r + 2'd2 : address_0_r + 2'd0) : start_adr; 

wire            [23:0]    start_adr;
assign start_adr = (SW[1] == 1'b0) ? ((SW[0] == 1'b1) ? 24'hC00000 : 24'h000000) : 24'h810000;

address_0 - то что подается на модуль билдера, а address_0_r соответсвенно адрес чтения.

Иными словами, численное значение 24'h000000 я заменил на wire start_adr... В результате картинка стала стабильной.

 

Почему это повлияло так сильно, чем отличается использование wire от просто константы, поясните?

[rv3dll 0]

к сожалению я не знаю что за язык (сам пишу на vhdl и ввиде схем)

[dvladim 0]

А что же вы хотите? В этих двух кусках кода, описана разная логика. В зависимости от значения SW[1] и SW[0].

Изменено 27 декабря, 2007 пользователем den_realan

[sazh 5]

always @(posedge CLOCK_50_f) address_0_r = (VGA_VS == 1'b1) ?

address_0 - то что подается на модуль билдера, а address_0_r соответсвенно адрес чтения.

Иными словами, численное значение 24'h000000 я заменил на wire start_adr... В результате картинка стала стабильной.

 

Почему это повлияло так сильно, чем отличается использование wire от просто константы, поясните?

 

Константа wire описывается. А как иначе?

wire [3:0] constant = 4'd5;

 

always @(posedge clk)

begin

if (s_load) count <= constant;

else count <= count + 1'b1;

end

 

Конечно же условия поменялись. И глубина мультиплексирования. Но так как усе это фиксируется по фронту клока, то дело наверно все же в использовании в процессе по клоку оператора блокирующего присваивания переменной =

При использовании такого оператора при синтезе регистров, задержек нп регистрах по клоку становиться важным порядок следования такого оператора в процессе по клоку.

используйте неблокирующий оператор <=

Ведь имеено его вы и имеете ввиду при поведенческом описании схемы

(Если не задумали в поведенческом описании порядок следования поведения)

[torik 0]

Спасибо, я понял куда копать.

Как это ни смешно, но я до сих пор не очень четко представляю когда необходимо использовать блокирующее и неблокирующее присваивание, надо бы почитать про это дело...

[des00 25]

wire [3:0] constant = 4'd5;

 

 

/me посмотрел свои исходники

 

Скажите пожалуйста а что localparam уже не синтезируется ? :))

 

 

С наступающим!!!