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

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

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

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


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


ТВ выход на bascom avr

Сообщений 241 страница 270 из 421

241

А отправляется то?
Там всё это настраивается, тут можно сказать - это самое сложное, подобрать нужный режим (из 4-х, по мимо приоритетности передачи данных), если до вечера не разберешься, то могу позжее кинуть настройки как я с АЦП 16 разрядным общался.

0

242

Операторами Iput не получится принять, у меня много прерываний и они мешают, придётся альтернативу искать получения 3х байт.

0

243

Прием по прерываниям или с помощью DMA не подходит?

0

244

Пётр написал(а):

Прием по прерываниям или с помощью DMA не подходит?

Теперь уже и по DMA  :D

Код:
Config Dma = Enabled , Doublebuf = Disabled , Cpm = Rr
Config Dmach0 = Enabled , Burstlen = 4 , Chanrpt = Enabled , Ctr = Disabled , Singleshot = Disabled , Tci = Lo , Eil = Lo , Sar = None , Sam = Fixed , Dar = Transaction , Dam = Inc , Trigger = &H8A , Btc = 3 , Repeat = 1 , Sadr = Varptr(spie_data) , Dadr = Varptr(spi(1))

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

0

245

Какая скорость приема по SPI? Видимо контроллер сильно занят и не успевает принять все данные. Если очень большая скорость не нужна, решением может быть замена SPI на I2C. Преимущество в том что ведомый не успевая принять и обработать данные, сообщает об этом ведущему удерживая линию SCL в низком состоянии до тех пор пока не будет готов принять следующий пакет данных.

В том случае, когда ведомому необходимо дополнительное время на обработку принятого бита, он имеет возможность удерживать линию SCL в низком состоянии до момента готовности к приёму следующего бита.

https://ru.wikipedia.org/wiki/I²C
Это снизит скорость обмена, но позволит не потерять данные.

0

246

IC2 это жестоко, лучше наверно USART использовать.
Непонятные глюки, но они есть, Пробовал реализовать и через регистры и так и свяк и через DMA.
Данные отсылает-принимает, но как-то искаженно, глюк просто жестокий, если отослать код буквы "G" то принимается "g", а если отослать "g", то вообще шляпу принимаю - и так со всеми буквами. Как-то странно теряются биты.
В Xmega бит прерывания по приёму/передачи сбрасывается автоматически если вызвано (ушло) по прерыванию или сбрасывается автоматически при его чтении из регистра STATUS. Получается, оператор INPUT не будет работать в прерывании On SPIE_INT, он просто зависнет, так как бит уже сброшен уходов в перывание.
Так-же в прерывании не прокатит код, который ждёт окончание приёма:
Do
Loop until SPIE_Status.7=1
Можно в программе заколхозить, но опять-же биты теряются.
Так-то получается приём на всех скоростях, скорости передачи не зависят, так как какая разница с какой скоростью регистру сдвигаться. Тут главное успеть в приёме взять байт до следующей передачи.
DMA принимает только последний байт, как не настраивал, но не может он принять три байта, принимает последний принятый байт и пихает в три байта А(1)-А(3), даже разочарован тем, что DMA не имеет инструмента ждать приёма, хотя настроил его по разному, в том числе и с запуском источника SPI, в ручную и автоматически, вообщем никак.
Такое ощущение, что SPI случайно остался на кристалле как побочный элемент. В документации всё просто написано, там даже шаманить не надо, легче чем USART.
Завтра через USART регистр сдвига буду двигать, задвигать  :hobo:

Отредактировано Ev3658 (2016-12-26 19:37:28)

0

247

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

IC2 это жестоко

Чем?

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

лучше наверно USART использовать

Тогда потребуется аппаратное управление потоком (CTS, RTS и т. д.) иначе есть вероятность потери данных если вовремя их не прочитать из регистра приема.

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

если отослать код буквы "G" то принимается "g"

Помех нет? Вот как эти буквы выглядят в двоичном виде.

G - 01000111
g - 01100111

Появилась лишняя единичка в 5 бите.

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

Получается, оператор INPUT не будет работать в прерывании

Считывание из регистра данных будет работать.

0

248

Пётр написал(а):

Помех нет?

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

0

249

И так, добрался до компа...
Кусок/пример чтения через SPI ADC LTC1865.

Инициализация:

Код:
Config Spic = Hard , Master = Yes , Mode = 1 , Clockdiv = Clk4 , Data_order = Msb , Ss = None
Open "SPIC" For Binary As #10
Config Portd.4 = Output                                     ' SS - not used
Config Portd.5 = Output                                     ' MOSI (DATA)
Config Portd.6 = Input                                      ' MISO - not used
Config Portd.7 = Output                                     ' CLK (BCK)
Dim Adc_word As Word

Чтение:

Код:
Input #10 , Adc_word
Swap Adc_word

В общем ожидаемо и у меня всё работает. Если читается не ожидаемое, то надо поиграться "Mode", но 1 режим как правило используется в большинстве случаев.

+1

250

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

0

251

Штатный SPI весьма убог, у него большие задержки между данными. Я уже писал, что пробовал организовывать прием через асм, становилось по лучше, но задержка всегда будет присутствовать. По этому "DMA - наше всё!". :D
У меня через DMA принимать тоже на скорую руку не получилось, надо рыть инет в этом направлении.
Впрочем если шина одна и она занята другим потоком DMA, то всё равно будут задержки и придется как-то оперировать приоритетностью выполнения задач. Кстати говоря, порой из-за этого (неправильная расстановка приоритетов выполнения кода) бывает вообще ничего не работает, тут надо четко понимать физику...

0

252

Видимо не работает по этой причине:

XMEGA A MANUAL wrote:

    20.6 DMA Support
    DMA support on the SPI module is only available in Slave mode. The SPI Slave can trigger a DMA transfer as one byte has been shifted into the Data Register. It is possible to set up the XMEGA USART in SPI mode to have DMA support for master mode, for details refer to Section 21.10 (USART in Master SPI Mode on page 247).

Поддержка DMA на модуле SPI доступна только в режиме ведомого. Ведомого SPI может инициировать передачу DMA, как один байт был перенесен в регистр данных. Можно настроить XMEGA USART в режиме SPI, чтобы иметь поддержку DMA для мастер-режиме, подробнее см раздел 21.10 (USART в режиме Master SPI на странице 247).

0

253

Так я то принимаю данные в ведущем режиме, ведущий генерирует сигналы исправно, осциллографом проверил даже биты, всё в норме.
Предполагаю, что отправка видео данных через Usart в прерывании нарушает приём данных через SPI. Шина данных не успевает. Такое ощущение, что появляется ложный бит о принятии данных.

0

254

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

Так я то принимаю данные в ведущем режиме

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

0

255

Так я о чем говорю, ты данные пытаешься принимать как сервер/мастер, а DMA работает только в режиме клиента/подчиненного. Но надо пробовать.

0

256

Не, мастер не видео карта, видео карта ведомая.
Походу это Bascom глючит.
Стоит только Wait (любой ms, us),  сразу прекращается передача данных  %-)
Надо как-то включить работу от кварца в Bascom 2.0.7.1, версия 2.0.7.8 местами не предсказуемая.

0

257

Эх... надо  :smoke:  DMA.
Попутал пакеты с блоками и повторами, такую кашу замутили.

Код:
Config Dmach0 = Enabled , Burstlen = 1 , Chanrpt = Enabled , Ctr = Disabled , Singleshot = Enabled , Tci = Lo , Eil = Off , Sar = None , Sam = Fixed , Dar = Transaction , Dam = Inc , Trigger = &H8A , Btc = 3 , Repeat = 0 , Sadr = Varptr(spie_data) , Dadr = Varptr(spdat(1))

Burstlen - размер пакета в байтах (отнимает шину данных у ЦП и держит пока не передаст)
Repeat - кол-во повторов пакетов (а пакет может быть из 1-2-4-8 блоков)
Btc - кол-во байт в пакете - вот где насявкает мозг!!! (на три байта нужен 1 блок)
DMA принимает SPI, но глюк с малыми буквами остался и исправить его не могу.

Вот так вот мозгуешь, а тем временем Микрочип поглотил бедную Атмел и теперь неизвестно, что будет  :(

Отредактировано Ev3658 (2016-12-27 18:56:20)

0

258

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

неизвестно, что будет

Ну, пока наблюдается только улучшения в плане АВР, так или иначе, они успели за это время выпустить ряд моделей (правда не назову, что они чем либо сильно интересные), наблюдается движуха. Раньше они на АВР вообще забили и штамповали свои АРМы, которые по отзывам на форумах, не пользовались большим спросом.

0

259

Пришел к выводу.
Если не использовать EBI (аппаратное расширние памяти), то ресурсов контроллера не хватает на приём и чтоб осободить немного, придётся лишиться знакогенератора.
Пробовал выводить через DMA видео строку и принимать данные через SPI - всё упирается в прерывания и одну общую шину данных.

0

260

Скорее всего, основная проблема с общей шиной.
А на счет EBI - наконец ты это понял (я об этом давно говорил и не однократно). Кое-как ещё знакогенератор вывести получится, но на этом всё.

Отредактировано RDW (2016-12-28 14:49:46)

0

261

Опять пахнет ЛУТом, но уже после праздничных дней, так как двигатель надо менять в машине, выспаться...
С SPI получается, но как не крутил, сдвиг строк хоть и маленький, но хочется идеальной картинки.
Буду делать с шиной данных, чей лучше LCD 640x480 чем LCD 128x64.
Может быть даже рисование линий и окружностей реализую  :rolleyes:

0

262

Лут отЛутил, сделал 8 бит шину данный + 2 бита адреса + 1 бит готовности и того 11 бит управление.
Получилась плата, которую можно заставить работать за место любого LCD дисплея. Но тут надо мозг ломать.
Я же постараюсь оставить знакогенератор на борту. Если всё получится, то будет хорошая скорость вывода информации.
http://s0.uploads.ru/t/y42ew.jpg
Могу ЛУТ выложить, если кто желает повторить. Он простой.

0

263

Непонятная сетка координат точки, выглядит как-то ограничено.
В тексте непонятно, как ты ухитрился в 4 бита впихнуть а-ж 40 значение позиции по Y.
А вообще, картинка управления как-то выглядит весьма сложно (математика бит/секторов) - ИМХО.
Ну и если там всё правильно, хотелось бы знать производительность вывода точек/текста.

0

264

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

Могу ЛУТ выложить, если кто желает повторить. Он простой.

Можно.

0

265

Ща, работа только начинает разрабатываться  :)
Сейчас в плане:
-Опробовать передачу данных через 8 бит + 3 бита.
-Опробовать передачу данных через регистр сдвига в Usart
-Опробовать передач данных через регистры сдвига HC595
Чисто теоретически, можно имитировать любой LCD дисплей.

0

266

Вообщем, оказалось сложно передать информацию в условиях нестабильного времени приёма.
Хуже того,  никак не получается избавиться от мелкого дрожания пикселей при интенсивном приёме.  Провалы примерно на 4 такта.

Алгоритм передачи простой.
Управляющий: Отсылаем адрес переменной в 8 битный порт и включаем ещё 1 бит (другой вывод), указывающий на приём адреса.
Видеокарта: Принимает байт из порта и делает строб.
Управляющий: Отсылаем данные переменной в 8 битный порт и отключаем бит (другой вывод).
Видеокарта: Записывает содержимое в переменная(адрес)=данные
Управляющий: Отсылаем конечный адрес переменной в 8 битный порт и включаем бит (другой вывод).
Видеокарта: смотрит то, что приняла и выводит действие.

0

267

Из далека выглядит очень даже прикольно. ;)

Думаю надо отказаться от параллельной передачи данных в этой ситуации. Это всё надо возложить на аппаратную реализацию, а что у нас есть аппаратное ещё? Правильно UART, он может данные принимать и дергать прерывание, приоритет которого ты можешь настроить сам. Следовательно весь протокол построить вокруг него.

Ну или параллельный протокол обмена построить так, чтобы он не накладывал ограничения/задержки на основной цикл вывода видео информации. Т.е. данные как бы накапливаются потихонечку в МК (возможно ввести что-то типа сигнального выхода похожий на CTS как у RS232, чтобы данные не пропадали), в имеющиеся окна простоя.

0

268

Тут загвоздка, между строками очень мало тактов остаётся. Можно вместо шины и регистр сдвига использовать (внешний, внутренний - без разницы).
Проблема в том, что контроллер весь занят выводом строки, самое большее время, это после 480 строк. Собственно на видео можно ускорить в два раза, но тогда теряется кадровая синхронизация. На видео буквы появляются в конце каждой отрисованной по точкам строки.
DMA использовать вообще смысла нет, так как оно отсылает по байту и чтоб взять каждый байт, требуется свободная шина данных, буфера не предусмотрено.
Сейчас вся сложность в том, что прерывание вывода строки происходит в любой момент, к примеру в момент записи точки в память при выводе шрифта или точки. Прерывание запоминает состояние адресов, режима порта и данных и после выполнения вывода строки восстанавливает обратно.
Если делать вывод только в конце кадра, то это всего 54-60 букв/точек в секунду.

0

269

На самом деле, я это давно понял, по этому под это дело получилось только купить камень А1, но это опять эксперименты не дающие реальной ясности, что "получится". Чтобы всё это заработало, DMA должна давать возможность хотя бы с внешней RAM данные выплёвывать...

0

270

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

На самом деле, я это давно понял, по этому под это дело получилось только купить камень А1, но это опять эксперименты не дающие реальной ясности, что "получится". Чтобы всё это заработало, DMA должна давать возможность хотя бы с внешней RAM данные выплёвывать...

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

Код:
Usartd0_data = Datain
            Nop : Incr Lowadres
            Do
            Loop Until Usartd0_status.6 = 1

            Usartd0_data = Datain
            Nop : Incr Lowadres
            Do
            Loop Until Usartd0_status.6 = 1

            Usartd0_data = Datain
            Nop : Incr Lowadres
            Do
            Loop Until Usartd0_status.6 = 1

Это работает лучше, чем через DMA.
Я уже не раз писал, что DMA использует одну и туже шину данных с процессором и процессор имеет приоритет. Есть конечно возможность у DMA ухватить шину данных не на 1 байт, а на пакет байтов, но при отправке в USART это не прокатит, так как пакет он разом не впихнёт из-за отсутствия буфера, да и получится так, что запуск DMA канала будет по сигналу окончания передачи данных USART, тут если выбран не 1 байт, а пакет байтов, то он на радостях завалит в этот USART все байты за один раз, в итоге USART передать не сможет.

Поможет только тактвоая частота в 4ре раза превышающая передачу данных. Это когда 20мГц пиксел и 80мГц процессор, тогда можно уже шиковать.
Проблема то не с выводом сигнала, его можно сделать вообще идеальным, стабильным и глаз-радующим )))). Успеть записать в память - вот проблема.

0


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