Главная страница -> VRTP -> Texнологии -> Микропроцессоры. -> Другие микроконтроллеры.

Ну и пруф конечно же:








Следующий шаг - запуск SDRAM и её тестирование.

Это сообщение отредактировал Gospodin_Riba - Mar 3 2019, 10:26 AM

Разобрался с PLL (файлы проекта PLL.c/PLL.h), выставил такой режим:

частота ядра: 456 МГц
частота шины EMIFB: 152 МГц (SDRAM)
частота шины EMIFA: 91.2 МГц (пока свободна)

Проинитил SDRAM (файлы проекта EMIFB.c/EMIFB.h) MT48LC16M16 на частоту 152 МГц (6.5 нс).
Это максимальная частота шины по даташиту на C6745. Сама память ещё более быстрая 166 МГц (6 нс).

---

Накатал тест памяти (файлы проекта MemTest.c/MemTest.h).

Несколько тестов: запись словами по 8,16,32,64 байт.

16 типов шаблонов:

Вначале идёт заполнение всеми шаблонами по-очереди, затем заполнение отдельным шаблоном.

А также дополнительный тест - запись псевдо-случайными числами.
Код функции Random() такой:

Seed перед использованием Random32() надо проинитить простым числом (используется 0x7FFFFFFF).

Тест всей памяти идёт около 4 минуты 20 секунд (последние тесты с Random вносят задержку).

Если что-то не так, то тестирование памяти прекратится и светодиод на порте GP0[0] будет быстро моргать (интервал 100 мс).
Если всё ОК и тест пройден, то светодиод будет медленно мигать (интервал 1 с).

Кеширование кода и данных естественно - не задействовано(выключено), чтобы работа с SDRAM была не в пакетном режиме.
Адресное пространство SDRAM (32 МБ) объявлено как volatile, что исключает оптимизацию компилятора - для гарантированного обращения к каждой ячейке памяти.

---

При написании программ усердно курю Reference Manual на C6745 и поглядываю на следующие сорцы:

c6000-evi-lib-master.zip и C6745-master.zip (оба качаются с GitHub).

В первом проекте регистры периферии почему-то объявлены без VOLATILE, что приводит к неправильной работе программы, когда она Release, а не Debug и со включенной оптимизацией.

В частности при настройке PLL без volatile повисало на втором цикле:

В моих исходниках все хедеры с регистрами исправлены, всё работает на максимальном уровне оптимизации.

Во втором проекте автор не выложил хедеры.

---

Обнаружил, что размер данных unsigned long int не 4, а 8 байт. В ARM 4 байта, а тут 8!

Протестил остальные типы:

При портировании это надо учитывать!

---

Токи потребления на частоте ядра 456 МГц, SDRAM 152 МГц при выполнении MemTest:

Ядро 1.3V: 210 мА - пиковое значение
Периферия 3.3V: 90 мА - пиковое значение

C6745 и SDRAM слегка тёплые.
LDO на 1.3V сильно тёплый - пиковая рассеиваемая мощность на нём 0.777 Вт = (5 V - 1.3 V)*0.21 A

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


Присоединённое изображение

Сорец проекта под CCS для тестирования SDRAM.
В папке Release готовый bin для загрузки по UART (сгенерен AISgen-ом).

Присоединённый файл ( Кол-во скачиваний: 100 )
 Blink.zip

Тест проходит успешно, по вопросам приобретения печатных плат - пишите мне в личку.



Это сообщение отредактировал Gospodin_Riba - Mar 4 2019, 06:03 AM

Есть tms320c6713, а вот насчёт корпусов и расположения выводов - большой вопрос. Так бы взял платку, если подойдёт. С McBSP поиграццо и миди-синтезатором.

Доработал тестилку SDRAM, на другом форуме подсказали, что память ещё надо протестить на корректность рефреша и с включенным кешированием.

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

Тест с рефрешем успешно проходится.

С кешированием пришлось повозиться. Задействовал пока кеширование данных.
Архитектура C6745 имеет в 2 раза больше кеша - 32 кБ против 16 кБ у STM32.
А так же есть кеш второго уровня - L2 - до 256 кБ.
так что STM32 курят

Ниже функция, для кеширования областей SDRAM - ничего сложного: курение референс-мануала делает своё дело:

Включение кеша первого уровня L1D - дало ускорение в 3..3.5 раза (в зависимости от теста)
Включение кеша второго уровня 128 кБ - L2 дало ускорение на 20..25%


Ниже сорец усовершенствованной тестилки SDRAM:

Присоединённый файл ( Кол-во скачиваний: 107 )
 SDRAM_Test_C6745.zip

Далее я попробовал грузиться не по UART, а через SPI EEPROM.

В наличии оказалась CAT25256 в DIP-корпусе. Встал вопрос о её прошивке, можно было шить самим C6745, но для этого пришлось писать прошивку для работы с SPI и UART и хост-программу для ПК. Это долго, а хочется как можно быстрее увидеть результат!

Поэтому было решено приспособить для этого программатор USB ASP v2.0, имевшийся в наличии.
Дефолтная прошивка программатора работает только с AVR-контроллерами.

Но умельцы (кстати, большое им спасибо! ) смогли доработать софт программатора для прошивки микросхем памяти.

Подробнее тут: http://plc-blog.com.ua/usbasp-flash-25xxx

Пришлось искать комп с LPT портом и шить USB ASP самопальным программатором:

Присоединённое изображение

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

Присоединённое изображение

Cмострячил небольшую приблуду для SPI EEPROM:

Присоединённое изображение

Всё работает, что радует!

Пошагово, как грузить C6745 с SPI EEPROM.

1) Создаем AIS-образ для заливки в SPI EEPROM:

Присоединённое изображение (Нажмите для увеличения)

2) Открываем софт программатора (ссылку кидал выше) , открываем в нем файл прошивки и выбираем нужную память:

Присоединённое изображение (Нажмите для увеличения)

3) Прошиваем!

Присоединённое изображение (Нажмите для увеличения)

4) Переставляем перемычки B0,B1,B2,B7 как накартинке ниже - для загрузки с SPI EEPROM:

Присоединённое изображение

Подаем питание и смотрим последствия автономной загрузки с SPI памяти!

Как вы наверное догадались, что в SPI EEPROM в будущем будет свой собственный загрузчик, который будет инитить нужную периферию игровой приставки и загружать с SD-карты эмуляторы и игры в SDRAM !

При этом следует упомянуть, что часть периферии возможно настроить в самом AISgen.

Ниже готовый образ для SPI EEPROM с целью проверки работоспособности платы - на GP0[0] мигающий светодиод. В целях минимизации потребления тока, частота ядра тут 24 МГц и всё отключено.

Это сообщение отредактировал Gospodin_Riba - Mar 5 2019, 02:56 PM

Присоединённый файл ( Кол-во скачиваний: 135 )
 Blink_SPI0_EEPROM.bin

Следующим шагом, наверное будет размещение кода в SDRAM и его выполнение.
Настройка кеша кода (L1P) и замер скоростей выполнения программ с кешированием и без.

1.8v М/c eeprom SPI шил по LPT (напаиванием проводков),
этого планшетно-сенсорного уродца на Atom Z3735F
напрямую (без буфера), через подтягивающие резюки

программой SPIPGMW
Стояла 8метровая GigaDevice GD25Q64. Скорости оч. дикие:
запись 3минуты, чтение 4

Хотя USB ASP оч.самобытен, своей ногодрыговой эмуляцией USB протокола...

Саму прогу пришлось патчить (ибо не определяла eeprom-ку), благо она
такая маленькая (50кб).. что была мысль ее реверснуть и насадить на USB->COM шнурок
(на базе PL2303). Однако первые прогоны мигания и ногодрыга , показали нижеплинтуснейшие скоростя для подобных применений..

Это сообщение отредактировал microxa - Mar 5 2019, 08:13 PM

А какие хорошие кодеки в него подойдут?
А то смотрю I2S вроде как есть (без подробностей):

Three Multichannel Audio Serial Ports (McASPs):
- TMS320C6745 Supports 2 McASPs
- Supports TDM, I2S, and Similar Formats [ZKB

Помнится в AWE32 стояла 8лапая i2s TDA1387, звучание было с нее кристально чистое
и волшебное (в него гналось даже FM/OPL аж с реверберацией)..

В "мобильных" х86, новый тренд - технология Intel SST(вмест мраковой HD) и все тотже рылотек:

The ALC5640 is a high performance, low power, dual I2S interface audio CODEC.
Two 24bit/8kHz ~ 192kHz I2S/PCM interface for each mono DAC and stereo DAC
Two 24bit/8kHz ~ 192kHz I2S/PCM interface for stereo ADC
I2C control interface

Представляете? вконец шизанулись, распихая его на 100500 пинов
И как бы я не заморачивался с jack-детект, так и не вышло отыметь стерео вход.
Ток моно... с микрофона... (впрочем что еще было ожидать от косоглазых 3.14д@р@сов)

да уж

Присоединённое изображение (Нажмите для увеличения)

АЦП AK5394 можно

Нормальное решение. Ведь сделать программатор - не самоцель, а вспомогательный инструмент.

Да всё что угодно! Я ещё не определился, что будет для звука. Хочется проще что-нибудь. Нужен только вывод звука. Микрофон не нужен.

Запустил кеш инструкций и программу в SDRAM. Полет нормальный.

Включение кеша L1P:

В SDRAM программа загружается AISgen-ом, если секции программы объявить что они в SDRAM (править CMD-файл в проекте).

Попробовал принудительно отключать кеши и сделал замеры:

Попутно перешёл на CCS v.6, которая поддерживает обновление через интернет и скачал свежую версию компилятора C6000 8.3.3 которая как оказалось, понимает диалект C99, и я этому очень рад!!!

Ну и с выкидыванием мёртвого кода разобрался.

Наткнулся на любопытный манускрипт (начало нулевых),
https://www.veron.nl/wp-content/uploads/201...Demodulator.pdf
ориентирован еще на старенький
Signal Processor TMS320C6711, в котором его описывают как

и чего на них персоналок не делали..
только платки с LPT (ляпота)
https://www.picclickimg.com/d/w1600/pict/12...Development.jpg
Можно сказать, гигафлопсник(и без радиаторов охлаждения).

Сколькож тогда дури в TMS320C6745..

полезный донор от мерседеса радар, часто водой заливают, за бампером 2 стоят





Это сообщение отредактировал kotu - Mar 10 2019, 01:46 AM

Монополия!

Даташит!

Это сообщение отредактировал Gospodin_Riba - Mar 10 2019, 04:33 PM

Один БГА, другой слабачок.
В чём их полезность в контексте темы форума?

Приобрёл TFT LCD такой:
https://www.electrodragon.com/product/3-5-3...8-bit-parallel/
3.5” 320x480 TFT LCD Arduino Shield, 8-bit Parallel, ILI9486

По качеству картинки оказался таким же говном как и мой аруиновский дисплей 320x240, недостатки всё те же:
http://vrtp.ru/index.php?showtopic=30174&v...ndpost&p=786821
Пикча:
http://vrtp.ru/index.php?act=Attach&type=post&id=786821

Но для первого старта пойдёт.

Решил увеличить разрешение, чтобы с краёв не срезать, так как эмуляторы Capcom Play System имеют более широкий кадр, чем 320x240

Подключил его ко второй(точнее -первой) параллельной шине EMIFA (8 бит).
На второй шине EMIFB (16 бит) висит SDRAM на 32 МБ.

Составил программу, настроил кеширование, проинитил шины, клоки,,,..... Разместил всю программу в SDRAM, вроде всё работает:

Присоединённое изображение

Сейчас отрисовкой занимается C6745. С применением DMA или PRUSS - отрисовка становится параллельной и не мешает C6745 и SDRAM (шины раздельные и одновременно).

PRUSS - это ещё 2 процессора внутри TMS-ки - работают на частотах вдвое меньшей, чем 6745.
По сути на них можно сбацать графический фильтр и рендерер, что здОрово разгрузит основной процессор!

Про PRUSS с чем их едят:
http://processors.wiki.ti.com/index.php/Pr..._Unit_Subsystem



Это довольно вещь в себе, для них отдельная системакоманд и свои компиляторы (ассемблер).
Сильными стараниями находятся доки, компиляторы и примеры как программировать.

Видео, отрисовка картинок размером 1/4 площади дисплея. Тут используется 64-битная передача данных в порты LCD:

В будущем, планирую искать другой дисплей 480x320 с лучшим качеством картинки. Может кто подскажет модели телефонов из которых можно снять дисплей с таким разрешением?

Появилась проблема с загрузкой программ по UART0. То грузится, то нет. Выдаёт ошибку таймаута по COM-порту.

Пока проблему обошёл сменой UART, теперь гружусь с UART2 - с ним загрузка идёт стабильно.

Карта соединений такая:

UART2_RXD - GPIO 5.12
UART2_TXD - GPIO 5.13

Положение перемычек на плате Mini6745, чтоб грузиться с UART2:

B2=0
B7=1
B0=0
B1=1


Присоединённое изображение

Про результаты подключения LCD 320x480 смотрим на предыдущей странице!

Карта подключений дисплея к EMIFA:

EMIFA GPIO
D0 .. D7 0.0 .. 0.7
A12 1.12
!WE 2.3
!CS2 2.5
!OE 2.7
! RESET 5.10

Ниже исходник всего проекта с дисплеем (контроллер ILI9486).
Загружается UART Boot Host-ом в SDRAM.

Присоединённый файл ( Кол-во скачиваний: 96 )
 LCD_ILI9486.zip