Администрация форума не несёт ответственности за достоверность информации и оставляет за собой право редактировать или в особых случаях даже удалять посты без предупреждения. Спасибо за понимание.

Программирование ATMEL в BASCOM.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Программирование ATMEL в BASCOM. » Вопросы - ответы » ТВ выход на bascom avr


ТВ выход на bascom avr

Сообщений 271 страница 300 из 405

271

Ev3658 написал(а):

он на радостях завалит в этот USART все байты за один раз, в итоге USART передать не сможет

Помнишь я видюшку показывал, как у меня там картинка дергалась, но логика просматривалась? Так вот, порт нормально данные отправляет через DMA, всё идет четко последовательно. Тогда данные выкидывались из RAM МК, которых очень мало (у меня) и раз картинку было видно, жестко держалась линия - это всё подтверждает.
Проблема была в том, что между строками очень мало процессорного времени на подготовку следующего буфера (из RAM) данных. По этому мне нужна была возможность откуда брать данные, большой буфер. DMA как раз может адресовать 64К потока, следовательно аппаратно оно могло без проблем выводится (и пофиг, что на это время весь МК будет занят делом). Да, там будет проблема с обновлением этого буфера и причем не маленького, но это был бы уже ЦЕЛЫЙ КАДР (хоть и без цвета, монохром), т.е. картинку синхрить и отображать уже не проблема. Тут либо при обновлении буфера просто можно тушить экран (сделать "бланк") или его заполнять медленно, пока есть "черные дыры" в паузах вывода межкадровой.

Отредактировано RDW (2017-01-19 17:57:47)

0

272

RDW написал(а):

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


И опять же та-же самая проблема, DMA и процессор используют одну и туже шину данных.
DMA хороша тем, что как-то она ухватывает свободную шину и использует её.
Если просто копировать кусок памяти из внешней памяти во внутреннюю, то проще настроить пакетом, тогда DMA как только поймает освободившуюся шину данных, захватит на выбранное в настройках кол-во пакетов. Но при этом процессор упустит тоже такты и не сможет ничего сделать.

То-есть принцип озадачить аппаратный механизм очень удобен, но он хоть и работает сам по себе, к времени исполнения не привязан, так как неизвестно кол-во раз освобождения шины процессора. Как-то надо процессор не занимать, чтоб DMA сделала своё дело.

Общая шина данных всё портит  :rain:

Картинку без проблем, текст без проблем, но вот беда. Прерывание не стабильно работает в рабочем куске кода. Опоздания на 20-30 тактов - это много (высчитал по показаниям таймера строки).
Пробовал сделать мини калибровку, но не прокатывает.
Выбора нет, как опуститься до 320х200 точек  :(
Там хоть и цвет реализовать можно и все вкусности.

Отредактировано Ev3658 (2017-01-19 19:00:50)

0

273

Ev3658 написал(а):

Если просто копировать кусок памяти из внешней памяти во внутреннюю

Как раз это лишнее, DMA вроде умеет с внешней памяти сразу выплёвывать (зря чтоли там контроллер памяти стоит).

Ev3658 написал(а):

Как-то надо процессор не занимать, чтоб DMA сделала своё дело

Угу - это делается легко при помощи FPGA+SRAM+BUFF. :D
Или взять две ХМеги, засинхрить их (общим тактовым генератором) и заниматься махинациями с задержками...

Отредактировано RDW (2017-01-19 19:03:19)

0

274

RDW написал(а):

Как раз это лишнее, DMA вроде умеет с внешней памяти сразу выплёвывать (зря чтоли там контроллер памяти стоит).
...

Но исключительно через свободную шину, которую в любой момент может отжать крутой авторитетный процессор  :(

0

275

Кто бы ему это разрешил сделать! :D

0

276

Atmel его крышует, прям так и написали: Процессор главней и всё, что достанется DMA не больше 1 байта или 2-4-8 байтов за 1 отжатие шины данных (размер пакета).

0

277

По секрету тебе скажу, Атмела уже давно нет, всех крышует Микрочип.)
Да и вообще, ты сам DMA уже давно не используешь, работаешь напрямую, а с таким подходом, можно перейти и на более дешевые МК, типа атмеги328п и тогда можно использовать не один кристалл, а скажем два или 8!!! :D Каждый для своей строки.

0

278

Не, ну я пробовал DMA и были успехи, изучил его от и до. Пришлось отказаться из-за нестабильности DMA канала, не стабильность передачи данных на скорости в два раза меньше тактовой ЦП.
В этом случае стабильней написать кусок когда, который имеет больший приоритет у ЦП. Так бы ничего, но программа вне прерываний смещает такты прерывания и это вызывает сдвиги на 0-30 тактов.

Уже опробовал в момент прерывания вывода строки записывать или читать один байт из памяти, тем самым программа вне прерываний ожидала этого действия. Но это не дало никакого результата.
Пробовал при каждом прерывании запоминать предыдущие адреса памяти и восстанавливать их после отрисовывания строки, чтоб программа вне прерываний могла работать с памятью.
Если память забить и программы убрать, картинка вообще без помех, чёткая, ровная, идеальная.


Можно сделать нормальную карту, но нужно две памяти и шинный разъединитель, а так-же второй контроллер для работы с памятью запись/чтение пока другой контроллер выводит другую память. Но схематично это очень дико.

0

279

Не пробовали осуществлять прием из USART через DMA? Тогда прерывания не понадобятся.
Пусть DMA из USART пересылает во внутреннюю память МК, а МК в свободное время, перебросит данные из внутренней памяти во внешнюю.

0

280

Ev3658 написал(а):

имеет больший приоритет у ЦП

Пляши от обратного, когда рисуешь картинку, вообще всё что есть стоит и ждёт...
Точнее так, общее тело программы, которое ждёт, когда ДМА всё перебросит и разрешит ей дальше подгружать данные.

0

281

RDW написал(а):

Пляши от обратного, когда рисуешь картинку, вообще всё что есть стоит и ждёт....

Это даже странно, не получалось никак и даже с приоритетами, в чём секрет?  :huh:

0

282

У меня уже начинает складываться впечатление, что я в воздух говорю. :shine:
С твоим подходом/алгоритмом, светит только подгрузка данных извне по команде и как можно быстрее и что ты тут ща не придумаешь, обеспечить "одновременную" передачу картинки (рефрешь) и сбор данных - не получится. Следовательно остается все внешние прерывания жестко контролировать. Почему я завел разговор про UART? Да потому, что он аппаратный (регистр крутиться, может работать параллельно относительно DMA). Так вот, попробуй такой механизм:

- ставишь макс приоритет на работу DMA (рефрешь картинки и всё что для него надо);
- ниже приоритет прерывание назначаешь на UART;
- UART назначаешь работу обязательно по RTS/CTS (почитай, что это такое в RS232) - это нужно, чтобы данные не пропадали между работой DMA;
- следовательно UART, данные из его буфера забираются только по условию свободного времени от DMA. А когда работает DMA, выставляешь запреты RTS/CTS (можно попробовать для убыстрения воспользоваться VPORT).

Логику для теста можно придумать наипростецкую: DMA - рисует, UART - по готовности, потихоньку получает данные для заполнения памяти на отправку данных по DMA (просто сделать цикличный адрес и потихоньку менять данные).

0

283

В XMega UART аппаратно не поддерживает работу с RTS/CTS? Это значительно все упростило бы.

0

284

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

0

285

Когда, в какой момент, ты запускаешь программу, которая вне прерываний? Только код не выкладывай, словами.

Отредактировано RDW (2017-01-25 12:04:55)

0

286

Если есть тело программы, которое работает само по себе, его постоянно прерывает прерыванием строчной развёртки. Если тело программы состоит просто:
Do
Nop
Nop
Nop
Loop
То это практически не влияет на начало прерывания строчного вывода.
Некоторые операторы и куски когда могут занять процессор на несколько тактов, это вызывает нестабильность включения прерывания, так как шина данных ещё не освободилась.

Остаётся только одно, в прерывании в котором рисуется строка, принимать данные и обрабатывать. Генератор шрифта уже вызывает нестабильность.

Не могу придумать способ передачи и приёма информации. Одной шины данных и 3х битов дополнительно не хватает.
Нужно принять три бита данных, которые рисуют точку. Можно было бы передавать сразу байт данных, но тогда понадобится обратная связь для эффекта наложения, а это лишние такты.

Картинка вообще эталонная, не шевелится, чёткая и ясная, если вообще не написать программу и не ставить: END
Если будет выводится 1 точка в строку, уже производительности хватит. Но как в коне строки воспользовавшись бордюром - ухватить три байта информации?
Хорошо, если есть три шины 8 бит, так бы вообще в лёгкую. Но свободно остаётся не так много, да и контроллер VGA работает быстрей (не хочется разгонять главный контроллер 44мГц против 32мГц).

0

287

Надо соблюдать два правила:

- не пытаться пихать данные при выводе строки (только в паузах кадра);
- если пихаем, то не до упора, а заранее перестаем это делать, до запуска рисования (значения можно подобрать опытным путём).

Вообще очень странно, что на всё так влияет обычный поток кода между: Do, Loop, End. Он имеет наименьший приоритет и прерывается моментально по приходу прерывания. Подвиснуть может только на несколько тактов (самую тяжелую команду можно подглядеть в АСМе справочнике, если ну очень интересно). В общем, если это происходит, то скорее всего, ты что-то начинаешь юзать, что в общей схеме останавливает всё ядро. Может где запрет прерывания в коде с оператора генерится в компиляторе - не знаю.

0

288

Играл с приоритетами, много чего пытался, даже сделать некую автокалибровку.
У меня всё без DMA, но и с DMA я тоже делал - эффект всё тот-же.
Перепробовал всё, кварцы даже разные, делители, разные места и методы, как только не колдовал, всё равно программа может прерываться с малой задержкой и эта вроде как малая задержка в один-два такта выводится нестабильностью строк.
Так-то бы можно было вообще всё в контроллере реализовать, рисование линий, окружностей, заливка и т.п., но никак, всё упирается в эту шину данных, которая всё-же хаотично освобождается.
Даже Do:Loop без NOP даст нестабильность.

0

289

Эй! Не вешать нос! Отвлекись на что-нить природное, варенья покушай, в парк прогуляйся, киношку глянь...глядишь светлая мысль посетит, только руки не опускай. А то с таким результатом, светит только установку обычного, мелкого экрана с резистивным сенсором.

0

290

RDW написал(а):

Эй! Не вешать нос! Отвлекись на что-нить природное, варенья покушай, в парк прогуляйся, киношку глянь...глядишь светлая мысль посетит, только руки не опускай. ....

Свернутый текст
Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

Загвоздка оказалась не вывести VGA сигнал, проблема в приёме данных.
Я не знаю, как можно стабильно принять три-четыре бита за вывод одной строки и ещё при этом записать их, только так производительность рисования на экране будет приемлемой для внешнего знакогенератора.

0

291

Ev3658 написал(а):

Я не знаю, как можно стабильно принять три-четыре бита за вывод одной строки

Повторяю ещё раз, ненужно этого делать. Точнее, выводить надо не в момент строки, а попробуй выводить/загружать данные только когда есть пауза межкадровая. Т.е. идея такова:

- все прерывания связанные с передачей данных переводишь на флаги (можно даже не битовые, сразу байтом), т.е. когда приходит прерывание от UART, что там есть данные, ты не пытаешься сразу принять данные, а тупо выставляешь флаг, что данные там есть и в дальнейшем их можно забрать, когда появится случай;
- дальше приходит прерывание от UART, выставил флаг, запретил бит приёма данных порта и всё;
- основное тело программы ждет появления "окна" (пауза межкадровая), когда это окно появилось, то она смотрит флаг от UART, если всё выставлено, то забирает данные. Тут сразу обязательно нужно использовать RTS/CTS биты для порта, чтобы внешняя железка понимала, когда можно отправлять новые данные,а когда нет (иначе они просто будут пропадать (данные).

0

292

RDW написал(а):

Повторяю ещё раз, ненужно этого делать. Точнее, выводить надо не в момент строки, а попробуй выводить/загружать данные только когда есть пауза межкадровая. ....

Я уже всё пробовал. Паузы не достаточно для разделения одного байта на биты.
Да и три байта в одной паузе не получить. Uart привязан к тактовой частоте, его сложно согласовать. Если SPI использовать, тоже не получается ловить ровно без потерь.
Контроллер VGA очень быстрый, но тупит между видимой частью строк.
Вот так вот сейчас пытаюсь отправить три байта:

Код:
Bitvgasr = 1
Bitvga = 0
Do
  Datavga = Vgadat(bitvgasr) 'порт вывода в VGA контроллер
  Do 'ждём совпадения адреса
     Bitvga.0 = Bit0vga
     Bitvga.1 = Bit1vga
  Loop Until Bitvga = Bitvgasr
  Incr Bitvgasr  'переходим на следующий адрес

Loop Until Bitvga = 3 'когда отправлено три байта, продолжаем
Strobvga = 1 'стробирем пином
Do
Loop Until Bit0vga = 0 And Bit1vga = 0 'ждём выполнения рисования точки
Strobvga = 0 'и так много раз

Return

Примерно выглядит так:
-VGA контроллер каждую строку генерирует адрес двумя битами и запоминает те данные, что уже в порту.
-Управляющий контроллер ждёт совпадение адреса двух битов и меняет данные в порту под нужный бит.
-Когда управляющий передаст всё, он делает строб сигнал третим битом и ждёт, когда VGA контроллер обнулит адрес.
-VGA контроллер обнаружив строб бит, переходит в выводу точки.
Этот процесс вроде как должен безошибочно передавать данные, но нет.
Так-то уже 4 строки вывода уходит на 1 точку.

Вот кусок приёма:

Код:
Bit0vga = Bytevga.0 'включаем бит адреса
Bit1vga = Bytevga.1 'включаем бит адреса
Incr Bytevga 'прибавляем адрес
If Bytevga = 4 Then Bytevga = 1 'сбрасываем адрес в начало
Vgadat(bytevga) = Datavga 'запоминаем то, что запихнул управляющий контроллер в порт

Отредактировано Ev3658 (2017-01-26 18:02:02)

0

293

Можно попробовать вариант как я ранее предлагал, способ весьма грубый, но хоть что-то.
На момент загрузки/подготовки данных для отображения, просто выводи "бланк" (пустой экран), синхронизация строк сама рисуется нонстопом. Дальше как данные получил, с синхротактом начинаешь отображать новые данные.
Любопытно как такой подход будет раздражать глаз.

0

294

Народ, мож кто видел, тут человек даже игру наклепал. Работает на 12мгц, описал алгоритмы Ссылка

Отредактировано Yuriy.pv (2017-01-26 18:56:30)

0

295

Yuriy.pv написал(а):

Народ, мож кто видел, тут человек даже игру наклепал. Работает на 12мгц, описал алгоритмы Ссылка

Отредактировано Yuriy.pv (Сегодня 18:56:30)

Ага, но это не 640х480 точек. Цвет только по байтам, не по пикселам.  Хотя после полученного опыта, читать текст становится более приятно )))).


Таковая частота: 48 MHz (12 MIPS)
VGA: 256×200 пикселей, 15 цветов
Видимая область игрового поля: 16×12 клеток

Если в текст перевести, то 16х12 букв примерно., зато цветных.

На Xmega при 44мГц удалось вывести примерно 80х40 букв, но одноцветных:



P:S: Извини, хотел плюс нажать за пос, а ткнул случайно не туда  :(

Отредактировано Ev3658 (2017-01-26 23:02:34)

0

296

Удалось в одной строке в невидимой части принять три байта и записать точку. То-есть рисование одной строки ставит точку.
Теоретически 525 строк = 525 точек * 54 кадра = 28350 в секунду.

Быстрей не знаю как сделать, и так уже вместо 80 байт строки вывожу 73

0

297

Точки это хорошо, только для отрисовки векторной графики - это очень медленно.
А текст будет быстрее обновляться? Для текста такая скорость очень даже неплохо. Тогда можно графику в шрифты заранее пихать и ей строить/рисовать.

0

298

С текстом ничего так, нормально, сойдёт  :yep:

Ещё немного, вот бы ког оптимизировать, чтоб 80 байт в строке вывести и проект выложу.

0

299

А что часть экрана не используется?! Не, так дело не пойдёт! Мы тут боремся за честные 640х480!  :D

0

300

RDW написал(а):

А что часть экрана не используется?! Не, так дело не пойдёт! Мы тут боремся за честные 640х480!

Оптимизация надеюсь поможет. Вывод строки по горизонту половина секунды, это много.
Так, как для эффекта наложения нужна обратная связь, я решил не отсылать байт, а управлять пикселем, указывая на наложение, стирание и т.п.
Самое ужасное то, что ускорив контроллер, ускоряется и вывод строки.

0


Вы здесь » Программирование ATMEL в BASCOM. » Вопросы - ответы » ТВ выход на bascom avr